如果只能从这本书里带走一句话，我希望是这一句：项目失败的根因，几乎都发生在「某一层不确定性被当成已经收敛」，而不是技术选型错了。

这句话不太好听。它意味着复盘时最舒服的那个结论——「需求没想清楚」「技术还不成熟」「客户太难搞」——通常都不是根因，而是根因被掩盖之后剩下的东西。

三个看起来毫无关系的失败

先看三个场景。它们行业不同、技术栈不同、责任人不同。

场景一：上线三个月，日活七个人。

一家装备制造企业的售后部门，去年做了一套维保知识问答。上线那天演示很顺：工程师问「液压站压力异常怎么排查」，系统三秒给出带步骤的回答，还附了手册页码。三个月后，后台显示的周活跃用户是 7，其中 3 个是项目组成员自己在测。

每一次周会汇报都是「按计划推进」。没有任何一个环节失败，也没有任何一个人犯错。

场景二：第六周，还在加功能。

一个数据看板项目，原定四周交付。第二周客户提出「顺手把区域维度也加上」，第三周加了「能不能导出 Excel」，第四周加了「按产品线拆一下」。第六周，项目组在讨论要不要引入一个新的图表库。

每一件事单独看都合理。客户没有提过分要求，团队也没有推诿，只是没有人算过这些「顺手」的价格。

场景三：验收会上吵了两个小时。

系统跑得没问题，功能也在。争议只有一句话：客户说「准确率不够」，乙方说「我们测的是 91%，达到约定了」。然后双方发现，合同里写的是「准确率不低于 90%」，但没写怎么测、测多少条、谁来出题。

那两小时不是在验收系统，是在补一份两个月前就该写的定义。

三个场景的共同点不在技术，在时间：都有一刻，某件事被默认「已经清楚了」，于是所有人往前走。事后回看，那一刻才是真正的转折点。

收敛：把不确定性降到可以判断的程度

我用「收敛」这个词，而不是「解决」或「消除」。

客户现场的不确定性消除不掉。业务会变、数据会脏、人会换、预算会砍。你能做的，是把某一层的不确定性降到可以依据判据做出判断的程度，然后带着这个判断往前走。

这两者的差别很实际：

• 「消除」是一个不可能达成的目标，所以它永远处于「差一点」的状态，也永远可以往后拖；
• 「收敛」有终点——判据满足就是满足了，可以签字、可以进入下一步。

所以这本书里每一节末尾都有一张判据卡。不是为了显得严谨，是因为没有判据的「已经想清楚了」，和没想过是一样的。

还有一点需要说清：收敛不等于写更多文档。文档是收敛的副产品，不是收敛本身。一份四十页的需求说明书，如果里面没有一句话能让客户用自己的考核指标复述目标，那它一个字都没收敛。

反过来，收敛有时候只需要一句话。「客户要一个问答机器人」是不收敛的；「售后工程师在判断液压故障时，平均要打 2.3 个电话给老师傅，我们的目标是把这个数降到 1 以下」是收敛的——它有一个可以当面否认的数字，也有一个可以被推翻的假设（工程师真的在打电话）。

判据的价值就在这里：它把「我觉得清楚了」变成「你可以现在就反驳我」。

为什么技术更强解决不了这件事

工程师的本能是：出问题了，就加深技术能力。

这个本能在某些层是有效的。数据接不进来，加深工程能力；效果不稳定，加深评测能力。但它对场景一和场景二几乎无效——那两个场景里，技术上没有任何一件事做错了。

原因在于技术能力作用的层次是有边界的。它主要作用在「现实」和「效果」这两层：数据能不能用、系统通不通、模型准不准。而多数项目死在前面的「意图」和「边界」两层——客户到底要什么、这个范围由谁守。这两层不是技术问题，但它们决定了技术要往哪儿使。

一个团队把模型准确率从 88% 提到 94%，如果这个问题本来就不该被解决，那 6 个百分点买到的只是一个更精致的错误。

判据卡：怎么判断你真的在收敛

这一节没有方法，只有一副眼镜。判据就是：你能不能用它看清一个已经发生的失败。

判据项	合格线	不合格信号	处置
归因到层	能指出「哪一层最先失守、当时被归为什么、代价在第几层显现」	结论停在「需求没想清楚」「技术不成熟」「沟通不到位」	重做复盘，这三个词是垃圾桶，不是结论
可复现	把复盘交给一个没参与项目的人，他能得出同样的一层判断	只有当事人听得懂，需要大量口头补充	补事实：时间、谁说了什么、当时依据什么做了决定
三例可落格	上面三个场景都能落进五层中的某一层，且落点不同	三个都归到「需求」或都归到「执行」	说明你还在用单一原因解释所有事
代价可见	能说出这一层没收敛，在几周后以什么形式付了钱	只能说出「项目黄了」这种总量结论	找到具体的那一天、那一次会议、那一笔返工

动手练习

第一题（判定）

以下是四份复盘结论，哪一份属于「机制归因」，其余三份分别属于什么？

• A. 项目延期，主要原因是客户需求变更频繁，且我方人力投入不足。
• B. 上线后使用率低，因为第三周确定范围时，把「谁每天会用这个系统」这个问题跳过了，直接进入了功能设计；代价在第六周的培训会上出现——没人来。
• C. 效果不达标，是模型能力限制，换更强的模型可以解决。
• D. 项目失败，团队执行力有问题。

第二题（找漏）

一个项目：客户要求做合同审核助手，团队两周做出原型，客户说「不错」，于是进入开发。四个月后上线，法务部只用了一周就停用，理由是「它标的疑点我们早看过了，我们要的是它别漏，不是它多说」。

这个项目最先失守的是哪一层？失守的那一刻具体发生了什么？

参考答案

第一题

只有 B 是机制归因：它指出了具体的一层（意图）、失守的时刻（第三周定范围时跳过了「谁每天用」）、以及代价显现的位置（第六周培训会没人来）。

A 和 D 是责任归因——把原因分配给「客户」和「团队」，正确但没用，因为下一单还会这样。C 是技术归因，它甚至可能是对的，但它回答的是「为什么效果不够好」，而不是「为什么这个项目失败」——这个项目的问题不在效果。

第二题

最先失守的是意图层，失守的时刻是客户说「不错」的那一次。

「不错」不是一个成果描述，是一个礼貌的、无法被检验的评价。团队把它当成了确认，于是四个月的工作都建立在「客户认可了这个方向」这个假设上。真正的成果是「不漏」，而原型阶段充分展示的是「多说」——两者是不同的系统。法务部停用时的理由，恰好是四个月前那句「不错」里没有包含的信息。

注意这一题的重点不是「应该多问几句」，而是：在那个时刻，有一个可以被检验的问题没有被问出来——「你们现在漏掉一个疑点，代价是什么」。这个问题有答案，且答案会直接改变产品形态。

自检清单

• [ ] 我能说出自己手上这个项目，目前哪一层最不确定
• [ ] 我能指出这一层如果失守，代价会在什么时候、以什么形式出现
• [ ] 我上一次复盘用的词，不是「需求」「执行」「沟通」这三个垃圾桶
• [ ] 我知道这一节的主张在什么情况下不成立（见下）

本节为原创论述。

关于主张的边界：如果项目失败的原因是纯粹的资源问题（预算被砍、关键人离职、公司战略转向），五熵模型解释力有限——那些不属于「不确定性没收敛」，属于外部约束突变。遇到这类情况，直接承认它，不要硬套模型。这个边界同样适用于全书其余章节。