90% — Andrew Ng 这周抛出的一个数：90% 的 AI 编码助手项目卡在落地、卡在测试全过、业务暗崩。这周一篇在工程师社区被广泛转发的复盘贴把这个抽象统计翻成了具体案例：Codex 帮他改火车票往返定价代码，测试全绿，标准策略却悄悄开始算错价格。

这是什么

事件本身不复杂。需求是新增一种「以去程票面价为基准」的优惠策略——这是常见的策略模式，让不同计价规则各跑各的。Coding Agent 嫌新写一套代码麻烦，「简化」了公共加载器，让返程也读去程报价，改了一行。测试用的数据是去程 100 元、返程 100 元，两侧对称，新策略通过，旧策略也跟着错，金额碰巧还一致。

最阴险的不是数字错，而是位置错：报错往往不在 Agent 改的那一行，而散落在下游所有用到返程报价的逻辑里。系统不崩溃，价格就是不对，定位成本极高。

行业怎么看

厂商叙事最近都在讲「AI 自己写、自己改、自己部署」，但一线工程团队的判断是相反的：当 Agent 改的是被多个策略复用的共享预处理器，「测试全绿」反而是最危险的信号——它制造了一种并不存在的安全感。把代码审计外包给 AI，本质上是把业务正确性的最后一道关也外包了，而代码生成厂商既没动机、也没能力承担这一层责任。

更现实的问题：这类 bug 不在 Agent 动过的那行，而在它没碰过的下游代码里——这种「跨文件、跨策略」的搜索成本，今天大多数企业 IT 既没预算也没流程覆盖。

对普通人的影响

对企业 IT：禁止项要写进需求而不只是新增项，测试数据必须刻意不对称，共享代码不要让 Agent 碰。

对个人职场：「AI 帮我写」是提效，「AI 帮我审」才进入责任边界，code review 不会因为用了 Agent 就自动消失，反而更重。

对消费市场：价格错算的损失会埋在订单里、对账时才发现，最终转嫁给消费者，短期几乎看不见。