评审会上有一幕，做过复杂需求的人都见过。方案推到墙角了，谁都没有更好的法子，我们把用户某些操作可能引起的问题摆上桌，得到的回复是五个字：
“用户不会这么用。”
会议室一般会安静两秒。不是被说服了，是这话没法反驳。它不是论点，是预言，而预言只能等开奖。
《程序员应知的 97 件事》里有一篇，标题就是答案：你不是用户。
你不是用户，因为你懂得太多了
这篇文章讲的是个老实道理：做系统的人，对系统懂得太多，多到再也没法像用户一样思考。
你知道那个按钮点完要等两秒，所以你从不连点；你知道先建档再录入，所以你从不跳步；你知道列表要刷新才是最新的，所以你从不对着旧数据下手。你在自己的系统里永远走在正确的路径上，不是因为路径设计得好，是因为地图刻在你脑子里。
这在心理学里叫知识的诅咒：一旦你知道了一件事，你就没法想象不知道它的人怎么行动。所以"我觉得用户会怎么用"这句话，从说出口那一刻就是失真的。你不是在模拟用户，你是在模拟一个懂全部实现细节的自己。
我研究生读的是心理学，这里忍不住掉个书袋："用户不会这么用"背后其实叠着两个偏差。知识的诅咒管一头：你懂得太多，回不去"不懂"的状态。虚假共识偏差管另一头：人会系统性地高估别人和自己的相似程度，默认自己的选择就是大多数人的选择。斯坦福有个经典实验，请学生背着广告牌在校园里走一圈，愿意背的人估计多数人都会愿意，拒绝的人估计多数人都会拒绝，双方都真诚地认为自己是主流。放回评审会，"用户不会这么用"的完整翻译是："我不会这么用，而我默认用户都像我。"前半句是事实，后半句是偏差。
麻烦的是，这两个偏差谁也不豁免，学过心理学照样中招，所以光懂道理没用，道理说服不了评审会。能说服评审会的是证据。巧了，我有个证据仓库。
我的铁证仓库：生产告警群
我们的生产环境有个告警群，接口报错就往里推。干了这些年，我对它有了新的理解：这个群的本质，是"用户不会这么用"的开奖记录。
随便捞几条真事（都脱过敏）：
一张休假中的申请单，界面上还显示着取消按钮。评审时的判断是没人会去点它，毕竟单子都在休假状态了。上线后告警说：点的人不止一个。事后想想毫无悬念，用户哪知道你的状态机，他只知道屏幕上有个按钮。
同一条记录被删除两次。听起来很离谱，做起来很容易：手快双击了一下，或者两个管理员前后脚删同一个人。告警准时来报到。
一个申请撤销了又提交，提交了又撤销，来回打转，把几张表的状态转出了不一致。评审时谁会设计这种操作路径？没人。用户不设计路径，用户只是在犹豫。
这些案例攒多了，我总结出三条铁律：能点的，一定会被点；能连点的，一定会被连点；能同时点的，一定会有两个人同时点。界面上存在的每一个按钮都是一份合同，用户签合同的方式就是点它。
为什么这句话总是输
"用户不会这么用"输给现实，输得这么稳定，是有结构性原因的，我数出来三条。
第一，样本错了。说这话的人，想象的用户是自己：熟练、耐心、网络好、注意力完整。真实用户里有第一次打开系统的、着急下班的、网卡到极致的、点到一半接了个电话回来忘了点到哪的。你是千锤百炼的老用户，他们不是。
第二，规模错了。你脑补的是一个用户，生产上是一万个。一万个人每天操作，万分之一概率的怪路径，天天发生。"不会这么用"在个体层面是概率，在规模层面是日程表。
第三，动机错了。你以为用户在"使用系统"，其实用户在"完成任务"。他不读文档，不背流程，不关心状态机，他只想干完活回家。挡在他和回家之间的一切，他都会用你想不到的方式绕过去。
顺便说一句，这毛病不是产品的专利。程序员的版本我也说过："这个分支不可能走到。"后来生产替我走到了。“用户不会这么用"和"这代码不可能走到这”，是同一句话的两种方言，翻译过来都是：我拿自己的认知，给别人的行为画了边界。
架构师的接法：别赌会不会，算赔多少
那评审会上到底怎么接这句话？吵"会不会"是没有意义的，双方手里都没有证据，只有信念。架构师思维的接法是换掉问题：别问会不会发生，问如果发生，赔多少，兜底要多少钱。
算完账，事情通常分成两类。一类是兜底很便宜的：按钮显隐跟着状态走、提交加防重、删除做幂等、关键操作先校验存在性。这类不用等评审吵出结果，顺手做掉，它们不是在防"那个操作"，是在防所有想不到的操作。另一类是兜底很贵的，那就把分歧记下来，让数据裁决。
裁决从来不缺。评审桌上吵不出结果的问题，生产环境都会给出答案，还附带告警时间戳。
最后
"用户不会这么用"这句话，我现在还经常听到。我不反驳了，反驳这句话需要预知未来，而我只是个架构师，不是先知。
我就默默把便宜的兜底写上，然后在告警群里等。一般不用等太久。
你不是用户。你比用户聪明，比用户懂系统，所以你猜不中用户。设计能力的分水岭，不在于能想出用户会怎么用，在于承认想不出之后，让系统在任何用法下都不失体面。
有想进「编程一生」用户交流群的朋友吗？
