五十个零件，每个九成半好，整机只有百分之八能转Kerry Ivan Kurian: Exponential Failure

把软件拆成各自讲得清接口的模块，可靠性就能像预算一样被算出来；说不清接口的模块，乘法会把小毛病滚成整机失灵。

1950 年代造导弹时总结出一条规律：如果整台机器必须每个零件都好才能工作，那么整机可靠度就是各个零件可靠度的乘积。这不是比喻，是乘法。

乘法开始咬人

五十个零件，每个九成半可靠，乘下来整机只有约百分之八的时间能正常工作。零件翻到一百个，成功率掉到百分之一以下。

AI 写代码的智能体让「多加一个模块」变得几乎不花力气，零件数于是往上飙。作者 Kerry Ivan Kurian 的结论是：项目失败会更频繁，而且失败得毫无声息——每个零件单看都挺正常，问题出在乘法里。

失败长什么样

不是地下室一声巨响，而是仪表盘上一个没人解释得清的数字，或者修好一处又弄坏另一处。

但乘法本身不知道这些。它把所有故障都当成整机停机来算，小毛病也被按大事故的倍率放大。作者的诊断站得住，论证也扎实，只是绕了四千字，最后给出的解药是「少做点、多做检查」——这句话 1975 年就有人说过了。

他绕过去的那一步

文章末尾轻描淡写地承认：乘法假设零件之间互不影响，而真实软件并不这样。

可这恰恰是整件事的转折点。只有当你能说清一个模块接收什么、吐出什么、什么时候吐，它才算一个模块；说不清，它就只是系统的一个放大切片，坏了会顺着边界传染给邻居。

反过来说，接口写清楚的模块可以对着接口测，而不是对着它今天碰巧干了什么测。它的可靠度能单独算，用的还是跟实现代码不同的检查手段。这样每个模块都可控，乘法就从威胁变成了预算：哪块弱、改一块能提升多少，全都能算。

所以真正的药方不是「少做」，而是「做能讲清楚的东西」。数量会自己降下来，因为认真写一份接口说明是苦活，没人会随手写五十份。

至于谁来检查智能体：让智能体查智能体，盲区是一样的。只有一份精确到可以对着测的说明书，才是它们没法商量、也没法糊弄过去的那道关。