给我的三个哲学启发

　　许多互联网公司都会以A/B Test的形式来进行产品决策——通过展现A方案和B方案，通过最终结果来判断哪个方案更好。本文笔者将与大家分享自己对于这种决策方式的一些思考。
　　A/B Test，这是如今互联网行业开发中常用的方法。它的做法很简单，某个问题如果有A和B两个方案，却无法决定哪个更好。那么不要争论，直接投入生产进行测试，把用户分成两群（划分标准可以是时间、地域、消费能力等等各种因素，但要样本足够大，足够有代表性），分别展现A方案和B方案，通过最终结果来判断哪个方案更好。
　　这看起来简单粗暴，但是一种相当有效的方法。据说：今日头条就大量使用A/B Test来进行产品决策，所以迭代速度很快，效率也很高。不过，今天我想换个角度，谈谈A/B Test给我的哲学启发。
　　我接触A/B Test是许多年前，那时候A/B Test的概念还没有流行，当时我甚至没听说过这个概念。但是，这不妨碍我用它的思想来解决问题。
　　当时我们开发的系统里的单据管理页面有个＂大一统＂搜索框，设计初衷很好，希望用户＂一站式＂搜索到想看的内容。
　　但是，单据的属性太多，原有系统的设计又很糟糕，用户在搜索框输入信息之后，程序要对所有属性进行逐一匹配检索，查询的效率特别低。如果遇上多个用户同时查询，系统基本就失去响应了。这个问题让客户非常不满，抱怨声此起彼伏。
　　我们在仔细分析了用户的搜索行为之后发现：用户搜索时，大量输入的只有三个属性——客户代码、日期、订单编号。
　　这三个属性的特征很明显，匹配检索也可以专门优化，速度会大大提升。所以，改进方案也很简单：收到用户提交的搜索请求时，先判断一下是否这三个属性，如果是就走专门优化的渠道。如果检索不到则弹出另一个界面，引导用户进行＂完整搜索＂。
　　据测试：这个方案很有效，响应速度提升很多，我们也非常有信心。但是，临到要上线，却被业务（销售）给叫停了。他们的理由也很充分：这样改动看起来有道理，但是客户已经习惯了原来的逻辑，行为结果会变化（＂你怎么知道我的大客户没有特殊习惯呢？＂）。而且，这个行业的客户大多专注于生意，文化水平不高，最怕的就是系统改了要重新适应。这种改动肯定不会受用户欢迎。
　　一边是系统的运行压力和技术人员的责任心，一边是销售描述的客户的惯性阻力。两边看起来都有道理，到底应该怎么抉择？
　　当时我有了A/B Test的模糊想法——不进行整体硬切换，让不同的用户走不同的逻辑，甚至可以动态调整大客户的搜索逻辑，如果客户不满意随时复原。好说歹说，终于说服了销售，可以上线测试。
　　测试结果显示：绝大部分客户都满意改进之后的搜索逻辑，能感知到速度大大提升，即便有少数客户感觉怪异。但是耐心加以解释，对比了常用搜索的表现之后，他们都比较愿意＂花一点时间学习和适应＂。所以，最终，这次改进的结果相当令人满意。
　　这是A/B Test给我的第一个启发：
　　在解决问题之前，如果有多种方案需要抉择，很可能每种方案都有理由，都有支持的声音，而且理由严密完整，声音铿锵有力。自说自话，总是能自圆其说。但是，评价决策的最终标准不应当是这些理由和声音，而是实际的结果。
　　看看我们周围，有无数热闹的文章在解释世界，在把某种抉择描绘得无比英明。但是，支持真实世界运转的并不是这些炫目的解释，而是现实的逻辑。所以，也才会有＂不看广告看疗效＂的说法。
　　扯远点说，卡尔·波普尔很早就发现：许多炫目的理论之所以让人着迷，是因为它们＂从来都不可能出错＂，即便出了错也能自圆其说。
　　波普尔认为：这些理论其实不是科学的理论，因为科学理论包含必须有出错的风险，只有不断通过＂惊心动魄＂的事实检验，理论的科学性才能得到证明。
　　许多人大概会记得，在前些年小米春风得意的时候，有无数专家在宣称。小米掌握了＂互联网方法论＂，当然能在手机市场上所向披靡，这是致胜的法宝。
　　然后，小米出货量下滑，而oppo和vivo崛起了，于是大家的口风瞬间转变，＂线下胜过线上＂、＂互联网企业做实业根基不稳＂的论调开始大行其道。之后小米扭转了下跌的趋势，为小米歌功颂德的声音又开始躲起来。
　　按照IDC最新的数据：2019年1季度，主攻线下的oppo手机出货量出现了6%的下跌，不知道这些专家又要说什么……
　　不过不管他们说什么，都无法改变一个事实。那就是，如果你只看这些专家的说法，必然会有和许多人同样的困惑——＂看书看来了许多道理，自己仍然不会做决策＂。
　　去年我看了《命运攸关的选择：1940-1941年间改变世界的十个决策》，也很有这方面的意思。比如：对于不列颠之战，如今许多人都在歌颂丘吉尔毫不屈服的坚定意志。但作者要分析的是：当时丘吉尔面临的情境是怎样的？他是如何决策的？如果他不选择抗战，结果大概会是什么样？…… 必须承认，这样的分析视角，会给人更多的启发和收获。
　　回头来说A/B Test，还是许多年前，还是在系统开发中，我又遇到过另一件事。
　　那时候，客户往往需要整批提交格式化的数据。按照日常经验，这种数据显然应当用Excel的格式最合适。用户按照我们给定的模板把数据分门别类录入好，最后在浏览器里上传到作业系统即可。
　　但是这样操作也会有问题。Excel文件的交互能力比较弱，如果一次提交几百上千条记录，某一条又出了错，很难告知准确告知客户错误的位置和类型，修改起来也很不方便。
　　另外，许多客户是一天提交一次Excel的，如果在Excel制作的过程中电脑死机或者文件损坏，很可能前功尽弃，之前的工作成果要全部重新来过。
　　在尝试了几次优化上传界面之后，我们决定彻底废弃之前的做法，直接给客户提供一个客户端软件。客户登录之后，可以逐一录入数据，数据录入时软件会直接和服务器交互进行验证-保存，出错了则即时提示。
　　这种软件开发起来不难，但也很好玩，里面有不少设计需要花点心思，大家也乐在其中。开发完之后，我们信心满满地介绍给销售同事，希望他们能推动客户使用。在我们看来，这是三赢的局面：技术不必反复查错，客户不必反复提交，销售不必反复沟通。
　　不出意外，销售同事第一反应就是质疑，因为客户已经习惯了原有的操作，让他们改变操作习惯，成本太高。不过，因为之前的搜索栏改进的例子，质疑并没有成为反对，大家约定这个改进也来实地测试一番。
　　这次的测试结果大大出乎我们的意料，绝大部分客户在试用新软件之后都不满意，又回到老的Excel的操作方式上来。＂怎么样，说了客户的操作习惯不是那么容易改变的吧！＂ 这一次，获胜的是销售同事了。
　　但是我们并不满意，一方面，对自己开发的软件有足够的信心（和期望），另一方面，＂用户操作习惯不那么容易改变＂并不能成为万金油，总有那么强的说服力。
　　可是，A/B Test的结果又分明证明，确实我们想错了。那么，问题到底出在哪里呢？
　　不甘心的技术人员走出办公室，深入到客户的使用场景去调查，真相才浮出水面：原来，开发时犯了想当然的错误。
　　开发人员的电脑配置比较好，开发使用的是.Net技术框架，而客户的电脑并没有那么新潮，许多仍然在用Windows XP，并没有自带.Net Framework，这就让许多客户望而却步了。即便知道要下载.Net Framework，又面临版本问题，国内各种下载站捆绑其它软件的问题。安装好之后，因为电脑配置低，程序运行起来响应也很缓慢，反而不如Excel干脆利落。
　　找到问题之后就好办了。把软件原有的操作逻辑都保留，.Net实现都废掉，以原生的Visual Basic重写。虽然这样有点折腾，新时代的程序员大多不会写VB了，要重新学习，但结果是非常好的。重新下发的版本在客户的机器上跑得很快，甚至比Excel还要快，迅速赢得了客户的信任，也在销售同事那里找回了面子。
　　这是A/B Test给我的第二个启发：
　　即便一个问题有了最终答案，也不能单纯相信最终答案所依附的那种解释，因为它可能是不对的。尽管这些解释能自圆其说，但也只是牵强附会，或者流于表面。换句话说，A/B Test这样的测试只能证明＂哪种方案好＂，而不能说明＂为什么好＂，不能替代人工的分析。要认清真相，我们不应忘记细致探寻其中的理由。
　　我的第三个例子不是来自自己，而是来自朋友。
　　近些年，A/B Test已经大为流行，会用A/B Test的人也越来越多。对应的，愿意讨论的人也越来越多了。一次吃饭时，有位朋友跟我说了这么个故事。
　　这个朋友开发的用户登录界面里面临一个问题：输入手机号接收短信验证码的界面，是否需要用户先输入图形验证码？如果不要求，则这个界面可能被滥用，别有用心的人可以利用这个界面给其他人发送垃圾骚扰信息。如果要求，正常的用户流程又不够顺畅，凭空多了一重阻拦。
　　因为单纯凭讨论无法决定，他们采用了A/B Test。最终发现：如今大概黑产肆虐，羊毛党猖獗，如果要求输入图形验证码，每天的无效和风险登录次数少了很多，正常用户的登录次数却没有太大的波动。从结果来看，安排图形验证码显然是一个更好的选择。
　　听完这个故事，我现场给他展示了一下登录流程。在输入手机号，满心期待可以等来短信之前，硬生生弹出一个＂请输入图形验证码＂的界面。
　　我问他：＂你作为普通用户，你的体验好吗？＂
　　他老老实实回答说：＂不好。＂
　　所以，从概率上看，A/B Test的结果确实防住了很大一部分黑产、羊毛党，但如果你不幸处于＂不需要防住＂的那一部分，对你来说这个结果就非常悲剧了。
　　你说这个问题确实存在，但是要怎么改进A/B Test呢？
　　实际上，所有这类决策都会有决策成本。按照80-20原则，你抓住了80%，就放弃了20%。何况现实中未必处处都是80-20，有时候你抓住的只是60%，放弃的是40%，甚至抓住的是55%，放弃的是45%。虽然从总数上看是不错的，但实际成本太高，放弃的太多。
　　那么，怎么解决这种问题呢？
　　解决这种问题并不是靠A/B Test，而需要输入更多的信息。
　　如果你的登录界面只输入一个手机号，让用户收一个短信验证码，就是把A/B Test做出花来，也没有什么用。如果你输入的不只有用户的手机号，还有用户的IP、浏览器版本等等信息，如果是在专属App里登录，还可以加上Wi-Fi网络、地理位置、设备ID等等信息……
　　你的信息更丰富了，决策逻辑就可以更复杂，可以调整的空间也更大。如果要做A/B Test也可以做更细致，可以从多层次、多角度来做A/B Test。
　　这位朋友听了之后若有所思，回头找安全、风控等等行业的朋友聊了一圈，得到了更完整的方案。再过几个月我去看他们的系统，已经基本做到了＂对正常用户勿打扰，对风险用户自动验证＂的水平，用户体验比之前粗暴弹出图形验证码好了很多。
　　实际上，这是我前些年思考的结果，也是A/B Test给我的第三个启发：
　　A/B Test不是万能的，不能迷信。
　　它只能教我们如何从给定的选项中择优，但许多时候选项本身的层面不对，或者粒度太粗。所以，即便做了A/B Test，结果也未必尽如人意。许多时候我们需要跳出来，输入更多的信息，或者改进A/B的粒度，往往能取得更理想的结果。
　　如果你有印象大概会记得：2002年8月12日，公安部在北京、天津、深圳、杭州四个城市推行了个性化车牌。个性化车牌有6位，前三位可以由用户自行选择数字或者字母。这种给予极大自由的政策，一经推出就引发民众热捧。不幸的是，政策公布之后还不到两周，就因为＂技术原因＂叫停了。
　　据媒体报道：这项政策被叫停的真正原因在于，许多用户自定的车牌有争议，比如BWM-001、FBI-001、USA-911、PLA-081之类，甚至还有SEX-001等等＂出格＂现象，被认为＂不符合精神文明建设＂。后来还有不少＂专家＂引用这个例子，证明＂社会现阶段不能太过自由，否则就会出各种幺蛾子，影响稳定＂之类的结论。
　　在我看来，这恰恰是个典型的因为粒度过粗、层次不当的例子。如果只是粗放规定＂用户可以选择/不选择个性化车牌＂，对＂个性化车牌中不容许哪些内容＂又没有任何细致的规定，结果当然五花八门，出乎意料。
　　拿它当例子来证明＂社会不能太过自由，否则就会影响稳定＂，就更是匪夷所思——自由从来都是和规定相联系的，没有什么正经的人主张社会需要毫无约束的自由。
　　系统智能与否，体现在它能动用多少信息，对多少情况进行细致的分析，给出对应的处理，而不是一两条简单的if-else万事。
　　同样的道理，解决问题水平的高低，也体现在问题的解决者能够动用多少信息，事先制定多少分门别类的规则，事后依据多少细致的分析，而不是简单粗放得到一个结论了事。
　　最后做个简短总结：
　　A/B Test很好，可以用来戳穿各种貌似合理的奇谈怪论。
　　做A/B Test不只是技术上做点事情就完了，没有细致认真的分析，还是可能走弯路。
　　要想给出更优的解决方案，并不能完全依赖A/B Test，输入更多的信息，掌握更多的计算能力，才可能得到更优的解决方案。