Asana把一个原计划要排到五年后的工程项目,用两周搞定了。
要把老旧的React测试框架Enzyme彻底清出代码库,这件事此前的排期是专人啃五年,预算大约600万美元。交给OpenAI Codex驱动的编码agent之后,一个半周的工程投入、跨了两个日历周,花掉的模型和基础设施费用约1.2万美元。这组数字被OpenAI写成了官方客户故事,标题足够抓眼球——但故事讲得越漂亮,越该多问一句:这五百倍的成本落差,是agent真把工程效率炸出了新维度,还是刚好选中了一个天生适合机器来做的任务。
为什么恰好是Enzyme
Enzyme是React生态里用了多年的组件测试库,长期没跟上React新的渲染机制,几乎所有还在用它的公司都欠着这笔技术债。它难维护,但"清空它"这件事,对agent反而是友好任务:目标可以被脚本机械验证——grep一遍代码库看有没有残留引用,跑一遍测试是不是全绿;工作能按文件、按模块拆开,四个agent各拿一份代码库副本互不打扰;"改一处、跑一次、看报错、再改"形成一个确定性反馈循环,agent不需要理解业务逻辑,只需要被测试结果不断纠错。这和重写一段涉及业务判断的旧系统,完全不是一回事。
四个agent,一天审两次
Asana给的初始指令只有五句话。团队试过更精细的编排设计,结果发现效果反而不如简单指令。最多四个编码agent同时跑,各自在独立的代码库副本里干活,工程师每天检查两次进度,对每一条改动逐一审核。agent做执行,人做审核,分工没变,变的只是执行速度。
隔壁公司干过同一件事
这不是行业第一次做这件事。Airbnb几年前也做过Enzyme到React Testing Library的迁移,规模是近3500个测试文件,原计划1.5年,实际用了六周——批量运行四小时自动迁移75%,四天调优到97%,剩下3%工程师手动收尾。同样是清除Enzyme,Airbnb规模大得多,方法也不同,用的是结构化的LLM处理流水线,而不是多agent并行编排,结果是六周而不是两周。
把两个案例摆在一起看,Asana的两周更像是agent在一个规模适中、测试基础设施本身比较完善的代码库里跑出的成绩,不是这类迁移的普适速度。规模一旦上去,耗时会跟着涨,方法论的选择也会跟着变。
600万和1.2万,不是同一种钱
这组对比数字最容易被记住,也最容易被记错。600万美元是此前被放弃方案的估算成本——按团队规模、时薪、工期排出来的一个数字,Asana没有先花掉这笔钱再省下来。1.2万美元是实付的模型和基础设施账单,大概率没算进工程师审核花掉的时间,没算此前让代码库适配agent做的准备工作,也没算后续维护。一个是没发生的假设支出,一个是账单上的一部分真实支出,放在一起算"省了多少倍",本身就是一种headline经济学。
- 风险.1.2万美元很可能只是真实成本的一部分,把它当项目总成本,会低估实际投入。
客户故事不是技术复盘
OpenAI公布的是一篇客户故事,不是独立技术评测。测试文件数量、代码改动规模、agent一次性通过率、返工次数、覆盖率变化,这些能验证成绩的关键指标都没有公开。Asana的CTO自己在引语里留了一句余地:"不是每个持续多年的项目都会压缩成几周。"这句提醒比头条数字更值得被记住。
五百倍的成本落差好算,任务边界在哪难算。
真正该问的问题是这套打法能用在哪。目标能被脚本验证、任务能拆到文件级、有现成测试兜底的迁移,agent确实能跑出比人力排期快得多的速度。涉及业务逻辑判断、缺乏自动化测试覆盖、语义模糊的重写,agent能不能照样交出五百倍的成本落差,现在没人给出过一份独立验证的答案。
- 结论.agent擅长的是可验证的机械劳动,不是需要判断的工程决策,这条边界比600万美元的对比更值得记住。