《软件工程经济学》④

AI 最大的风险，不是写错代码

有一种 Bug ，我怀疑以后会越来越常见。它不是代码写错，甚至测试全部通过，问题从代码生成之前，就已经发生了。

一个电商团队的退款规则是这样的：正常商品七天无理由，预售和定制商品不适用；退款要扣除已使用优惠券的折算部分；余额提现过的用户二次退款需要走审核。

他们把这套规则交给 Agent 。代码生了，测试补了，构建全绿，验收用例跑通。

上线之后，退款金额开始出错。

不是所有情况。只有当用户同时持有两张不同类型的优惠券、只用了其中一张的时候。

排查了半天，问题不在代码。是没有人想到过这种组合。Agent 用自己推断的最合理方式补全了这个从未被提及的情况。测试一样跑通。

这不是孤例。另一个团队让 Agent 做权限模型改造，需求文档里写的是"管理员拥有所有权限"。

而系统里其实有管理员和超级管理员两类角色——测试全部通过，上线一段时间后才发现，两类权限被悄悄合并成了一套。

Agent 没有写错代码，它只是忠实执行了一份没有区分两者的描述。

有没有发现，这两个 Bug 很像？

代码没有逻辑错误。测试全部通过。构建全部成功。

问题不在实现，而在理解。

这种 Bug 和传统的代码 Bug 不一样。传统的 Bug ，你能在代码里找到出错的行。但这种 Bug ，你找到的每一行代码都是"对的"——它正确地实现了一个错误的理解。

为什么这种事在过去不那么容易一路带到上线？

过去，需求和代码之间，总有一个人。

程序员不只是写代码的。他还有一个很少被正式承认的角色——需求的持续质疑者。

产品经理说"订单可以修改"，程序员在实现过程中，脑子里的追问会自然冒出来：支付中的能改吗？已发货的呢？修改哪些字段？

这些问题没人要求他问。是实现过程逼出来的。

Agent 不一样。

Agent 收到描述，直接走到执行。它不会在实现过程中停下来问"这里是不是还有没说清楚的地方"。不是因为它不能问。而是质疑不是它的默认工作模式。执行才是。

这里真正变化的，不是模型能力。而是理解和实现，不再发生在同一个地方。

过去，它们都发生在程序员脑子里。今天，它们被拆开了。

他理解需求，然后实现需求。理解过程中产生的问题，会自然影响实现。发现不对，就停下来，回来问，需求被修正，再继续。

理解和实现之间存在一个天然的反馈回路。理解错了，实现过程中会暴露。暴露了，就修正。

当理解和实现开始由不同主体完成，这个反馈回路就断开了。AI 只是第一次把这种断裂放大到了整个工程过程。

今天，你描述意图，Agent 理解意图，Agent 实现意图。理解和实现被分开了，交给两个不同的主体。中间那个"理解过程中发现不对就停下来问"的环节，没有了。

不是 AI 不如人仔细。是理解和实现被解耦之后，那个天然存在的纠错机制，不再自动运行了。

所以，同样一个理解偏差，过去和今天的后果完全不同。

过去，偏差只影响几十行代码，实现过程中就暴露了，修复成本不高。

今天，同样的偏差可能被 Agent 在几分钟内扩展成几千行代码、几十个文件、完整的测试套件。全部内部自洽。全部能够运行。全部建立在同一个误解之上。

真正危险的，不是一个错误理解产生了错误的代码。而是一个错误理解，被高质量地实现了。

还有一件事。

Agent 默认相信它收到的信息。如果文档说一条规则是这样，注释说是那样，Agent 会做出选择，然后执行。它不会停下来问"这些信息互相矛盾，我需要人来确认"。

当执行能力足够强，忠实执行本身就变成了一种风险——如果输入不可靠的话。

所以，软件工程真正在变化的事情，也许不是"代码怎么写"。

而是：

过去，我们最怕代码写错。

以后，我们更应该怕理解错。

但如果这些"理解"所依赖的上下文——文档、注释、决策记录、历史讨论——本身就已经过期、冲突或者失真了呢？

下一篇，聊这件事。

最后留一个问题。

你的团队里，有没有一种情况：代码完全没问题，但上线之后才发现，大家从一开始对需求的理解就不一样？