AI 编程最迷人的地方，也是最危险的地方，是它能很快给你一个“看起来已经完成”的东西。

页面能跑，接口能通，测试也许还能过。团队开会一看，进度喜人。但 Jonathan Beard 在《The 80% Problem》里提醒的，正是这个反常点：AI 把前 80% 变便宜了，却把最后 20% 藏得更深、更贵。

这不是说 AI 永远只能完成 80%。更准确地说，在模型熟悉的问题上，它很擅长生成可运行初稿。可系统能不能上线、扛压、长期运行，常常由剩下那一截决定。

快的是 demo，慢的是生产环境

老程序员都听过“90/90 法则”：前 90% 代码花掉 90% 时间，剩下 10% 再花掉另一个 90% 时间。数字荒唐，经验准确。

AI 没有取消这个规律，只是把它换了个外壳。

AI 很快补上的常被漏掉的最后 20%真实影响
happy path 逻辑幂等、重复请求处理用户多点一次，账单、库存、任务可能乱掉
基础脚手架退避、抖动、限流流量一抖，服务互相拖死
能跑的接口熔断、部分故障处理一个依赖慢，全链路跟着慢
简单迁移脚本迁移锁、长表锁风险一次发布卡住整张表
基本日志结构化日志、可诊断性凌晨 3 点只剩猜谜

开发环境不会替你模拟真实世界的坏脾气。并发、流量尖峰、网络半断、脏数据、数据量从一千行变一千万行，才是系统真正的考场。

所以最后 20% 不是润色，不是代码洁癖，也不是“再优化一下”。它是生产环境里的生死线。

这对软件工程师很直接：用 AI 起项目没问题，但不能把“能跑”当“能交付”。PR 里要补失败路径、重试策略、日志字段、迁移回滚、压测假设。少一项，省下来的时间迟早会在线上还。

对技术负责人更直接：采购 AI 编程工具可以继续，但别只看代码产量。真正该延后的不是工具采用，而是那种“人少了、评审薄了、on-call 也轻了”的幻想。AI 能提速，不能替团队兜底。

问题不在 AI 不会写，而在它太像懂了

Beard 给了一个很有用的词：synthetic competence，合成能力。

意思是，产物有理解的表面纹理，但人和系统未必真的理解。

过去，不懂通常表现为写不出来。现在不一样了。AI 可以写出漂亮的设计文档、像样的迁移方案、整洁的 PR、语气笃定的事故总结。表面能力涨得很快，底层判断未必跟上。

这才麻烦。

编译器和测试还能抓住一部分错误。但架构建议、风险判断、故障预案，很多时候没有外部裁判。输出越流畅，审查越容易松手。看起来越像答案，越需要有人问一句：它会怎么坏？

这里有个现实约束：AI 生成的东西，最容易在熟悉模式里显得可靠。CRUD、脚手架、常规接口，它确实能省很多时间。可一旦进入业务约束、历史债务、线上流量、跨团队依赖，它就需要人把上下文补齐。

这和早期铁路、电力系统有一点像，但不完全一样。技术扩张带来效率，事故也会把隐藏约束暴露出来。那时考验的是调度、维护和制度；今天考验的是审查、观测和接管能力。

“兵无常势。”AI 给的是起手式，不是战场指挥。真正危险的不是用 AI 写代码，而是把 AI 生成的 80% 当成已经穿过现实检验的 100%。

最该观察的不是生成速度，而是接管能力

1983 年，认知心理学家 Lisanne Bainbridge 写过《自动化的讽刺》：自动化越可靠，人越少练习；可一旦自动化失败，人又必须在最罕见、最困难的时刻接管。

这几乎就是 AI 编程的今天。

资深工程师之所以能审 AI，是因为他们过去亲手踩过坑：追过竞态，修过脏数据，处理过线上迁移，熬过 on-call。问题是，下一代工程师的这些“笨练习”正在被自动化压缩。

别轻易说初级工程师会消失。更准确的风险是：初级工程师还在，但形成判断力的路径变窄了。

接下来最该观察两个变量。

观察变量好信号坏信号
代码审查怎么改评审失败模式、回滚方案、可观测性只看风格、命名、是否能跑
新人怎么训练保留 on-call、故障演练、迁移和排障任务只让新人拼 AI 输出、改提示词、补样式

解法不是拒绝 AI。那既不现实，也不聪明。真正该重做的是训练机制。

代码审查不能只看风格，要追问失败模式。on-call 不能被当成纯成本，它是工程判断的学校。故障复盘要训练人预测系统如何崩，而不只是补文档。学徒制要保留必要的硬活，让新人接触边界、约束和脏现实。

这也是技术管理者要做的取舍：短期看，AI 让团队更快出活；长期看，如果所有脏活都被隐藏，团队会失去培养资深工程师的梯子。

AI 让写代码更快，这是好事。但行业别顺手把培养工程师的土壤也铲平了。

这篇文章真正提醒的，不是“AI 不行”。恰恰相反，是 AI 已经够好，好到会制造一种危险错觉：系统已经完成，团队也已经理解。

前 80% 越便宜，最后 20% 越不能靠运气结账。