5年工程2周干完，省下598万美元？关键一行却没人看
🔍 复盘案例OpenAI 上周发了条客户案例：Asana 用 Codex 干掉了一个 5 年都没干完的活，2 周搞定，花了 1.2 万美元，原计划是 600 万。
我第一反应不是「AI 真强」，是往下翻，想知道他们删的到底是什么东西。
翻到了：Enzyme——一个早就没人维护的前端测试工具。
看到这几个字，我基本就明白了。
这个活能 2 周干完，跟 Codex 有多聪明关系不大。做过老系统改造的人都知道，我们怕的从来不是代码难写，是改完之后没人敢说「对了」。而这个活，恰好是极少数机器自己就能说「对了」的那一类。
这几天这条案例转得很凶。我猜已经有人被老板问了一句，或者自己心里问了一句：AI 都这么强了，我们那堆老系统能不能也让它清一清。
能不能，看三个条件。Asana 那件活三条全占，所以才有那个 2 周。而多数公司手上那堆老代码，大概率一条都不占。
先说结论：不是 AI 变强了，是这个活本来就是那种活
Asana 这次清掉的东西，同时满足三个条件。缺任何一个，2 周都不成立。
第一，它是测试。
测试这东西天生带着一个不需要人拍板的判定标准——跑一遍，绿了就是对的。
第二，它是整块换掉，不是在里面动手术。
目标很干净：把这个工具从代码库里彻底抹掉。不是「改造它，同时还得保持它跟旁边八个系统兼容」。
第三，它已经死了。
按案例的说法，这个工具「已不再被主动维护」。一个不再生长的东西，你改它的时候，它不会在你背后继续变。
三个条件凑齐，才有那个 2 周。
换成一个还活着的、跑着真实业务的、改完只能靠人肉判断对不对的系统，把 Codex 换成任何一家的 AI，结果都不会是 2 周。
这句话不是我说的。Asana 的 CTO 在同一篇案例里就说了：并不是每个多年的项目都能被压缩成几周。
整篇案例里，这句话被引用得最少。
案例里被所有人跳过的那三行
传播到最后只剩四个数字：5 年、2 周、600 万、1.2 万。
但案例里还写了这么几行：
- 起手的提示词只有五句话；
- 最多同时开四个 AI 在干，每个在代码库的一份独立副本里工作；
- 工程师每天检查两次，并且审阅每一处改动。
第三行是这篇案例里信息量最大的一行，也是被跳过得最彻底的一行。后面我们会回来说它。
先把那三个条件拆开，变成你能对着自家任务打钩的东西。
判据一：改完之后，谁说了算
这是三条里最重要的一条。
一件改造工程真正的成本，很少花在写上。花在「怎么证明没改坏」上。
测试库替换这类活特殊在哪？特殊在验收这件事本身是台机器干的。
原来那几千个测试用例，换完之后重跑一遍，全绿就是对的，红了就是哪里不对。整个过程不需要任何人凭经验拍板。
这就意味着 AI 干活的时候，手里一直攥着一个指南针。它改一版、跑一遍、看结果、再改——这个循环里没有人类什么事。
现在换个活试试。
把一套跑了八年的订单结算逻辑重写一遍。写完之后，怎么知道对了？
没有全绿这回事。你只能找几个老同事，一个场景一个场景地对，对到某个程度大家点头说「差不多了」，然后上线，然后祈祷。
这两件事的区别，不在代码难度上，在于有没有一个不需要人点头的判定标准。
有，AI 就能自己跑起来。没有，AI 每交一版你都得从头审一遍——它写得越快，你越累。
所以这一条要这么问自己：这件活干完之后，有没有一个东西能自动告诉我对了？
判据二：是换掉，还是动手术
第二条容易被忽略，但它决定了改造过程中有多少个「需要拿主意」的岔路口。
Asana 那件活的目标形状极其干净：把一个东西从代码库里彻底删掉。
没有中间态，没有「这部分先保留兼容」，没有「这个模块特殊，走老逻辑」。
这种彻底替换的活，AI干起来很顺，因为每一步的目标都一样，不需要判断「这里要不要例外」。
而大多数老系统改造不长这样。它们长这样：
这个模块要改，但那三个还在调它，其中一个是外部合作方在用，动不得；数据格式要升级，但历史数据得能读；新老逻辑还要并行跑一段时间对账。
每一个「但是」，都是一个需要人拿主意的岔路口。
而 AI 在岔路口上做的选择，你事后全都得挨个复核——这时候它替你省下的时间，又还回去了。
所以这一条这么问：这件事的目标能不能一句话说清，中间还有多少个「但是」？
判据三：那个要被换掉的东西，还在长吗
第三条最不起眼，但它是那个 2 周里我认为最被低估的功劳。
Enzyme 已经停止维护了。这意味着在整个改造过程中，它是静止的。没有新版本，没有新用法，也没有别的团队一边改造一边往里加新代码。
目标不动，是这类工程能有确定终点的前提。
反过来，如果要清理的是一套还在天天被人往里加东西的系统，那就成了另一件事：你在追一个正在跑的目标。改到一半，前面改完的部分已经过期了。
这种活即使全交给 AI，也不会有终点，只会有一个持续消耗。
这一条特别容易骗人——因为它跟技术难度完全无关，纯粹是组织问题。一个技术上很简单的清理，只要那个东西还活着、还在被人改，就干不完。
所以：这件活开始之后，那个要被换掉的东西还会不会继续变？
三条对下来，你手上那件活排第几
按占了几条排个序，比纠结「AI 到底行不行」有用得多：
三条全占 —— 现在就可以试。这类活的典型样子是：清理一个已经废弃的东西，验收靠自动化跑，范围能圈死。
占两条 —— 值得做小范围试点，但要提前想清楚缺的那条谁来补。缺验收信号的，先把验收补上再动；缺整块替换的，先把范围切小到能整块替换为止。
只占一条，或者一条不占 —— 现在别碰。不是 AI 不行，是你会把省下的写代码时间全部还到审阅上，而且还多担了风险。
注意第二档里那句话：缺哪条，就先补哪条，而不是直接放弃。
一件活没有自动验收，那就先花两周把验收补出来——补完之后，它就从第三档跳到了第一档。而这件事本身，也是可以让 AI 帮着干的。
真正的瓶颈，已经从「写」挪到了「审」
现在回到那三行里被跳过的第三行：工程师每天检查两次，审阅每一处改动。
这行字说明，这不是一个无人值守的工作流。它是人定节拍、AI 并行干活的混合模式。
而且案例没告诉我们一件关键的事：那 1.5 个工程师周里，有多少是花在审阅上的？原文没拆。
这个没被拆开的口径，恰恰指向我认为这篇案例最有价值的一条推论——
当写代码的成本被压到接近零，瓶颈就整体挪到了审代码上。而审的带宽，是跟人绑死的。
你可以同时开四个 AI，也可以开四十个。但审阅的人还是那几个，一天还是那么多小时。
开到某个数量之后，多开的每一个 AI 只是在给同一批人的待审队列里多塞几份稿子。
能自己判对错的活才轮得到 AI；判不了对错的活，多开几个 AI 只是多出几份需要人看的稿子。
这一条直接决定了试点该选多大：不要按「AI 能干多少」定范围，按「你们一周能审多少」定。
这是两个完全不同的数。
这三条其实不是 AI 带来的新标准
写到这里可以往回退一步看。
验收能不能自动判、能不能整块换、目标还在不在变——这三条听起来像是为 AI 时代新总结的，其实不是。
过去二十年，一个团队敢不敢接一个老系统改造项目，看的就是这三条。
三条都占的，是那种「不难，但一直没人排上」的活；一条不占的，是那种在会议室里被提起过五次、每次都不了了之的活。
AI 没有改变哪些活能干。它改变的是能干的那类活的价格。
原来能干、但因为要占三个人 5 年所以永远排不上号的，现在便宜到可以顺手做掉了。这是真实的、很大的变化——Asana 那件活能被做掉，就是这个变化的一个例子。
但原来不敢干的那些，现在还是不敢干。价格下降没有把它们变成能干的活，因为拦着它们的从来就不是价格。
所以「5 年变 2 周」这句话最准确的读法不是「AI 快了一百倍」，而是：
有一大批被价格挡在门外的活，门票突然变便宜了。
你该做的是回去清点一下自己有多少这样的活，而不是指望那些本来就进不了门的活也跟着进来。
你手上那件活，属于哪一类
最后问一个问题，也是我自己一直想听听别人怎么答的——
你手上有没有那么一件老代码的活，明明知道该清，但一直没人敢动？它卡在哪一条：是改完没法自动验证对错，还是根本没法整块换掉？