想象这样一个场景：你的团队有一个迁移项目，已经断断续续推进了三年，各种排期里都挂着它，但每次算下来，距离真正做完还有五年。团队上上下下都知道这事该干，也都默认它只能慢慢磨。突然有一天，有人提了一个「不讲道理」的目标：能不能一周之内把它干完。

两周后，这个项目真的结束了。代码库里的旧测试框架被彻底清空，而整个过程的模型和基础设施成本加起来，大概一万两千美元。

这不是我编的故事，而是 Asana 工程团队最近公开的一个真实案例。他们用 OpenAI Codex，把一份预计还要五年的前端测试迁移工作，压缩到了两周。

五年都磨不完的 Enzyme#

先说说这个「五年」是怎么来的。

Enzyme 是 React 生态里一个老牌的测试库，曾经是主流。但它后来失去了社区维护，和较新版本的 React 兼容性越来越差，而且它鼓励开发者写那种和实现细节强耦合的测试，而不是关注用户真正看到和用到的行为。

Asana 从 2022 年就开始计划，把前端测试从 Enzyme 迁到 React Testing Library（RTL）。RTL 的哲学正好反过来：测行为，不测内部实现。这个迁移一直在推进，好几个多人年的项目都押在上面，各个产品团队也在各自负责的角落慢慢啃。

问题在于，按当时的推进速度，剩下那部分大概还要五年。这类技术债有个共同点：它对工程有意义，但从来不是业务上的头等大事，所以只能一直排在别的需求后面，年复一年地拖。

于是团队定了一个故意不合理的目标：一周之内把整个迁移做完。

他们几乎做到了。实际花了大约一周半的工程时间，跨了两个自然周，Enzyme 从代码库里彻底消失。

五句话的 Prompt，四个并行 agent#

真正让人意外的是，方法简单得近乎「朴素」。

他们用的是 OpenAI Codex，配 frontier 模型、超高推理档位，同时最多跑四个 agent，每个 agent 指向不同的目录。机器不睡眠，agent 白天晚上连轴转，工程师每天早上和晚上各检查一次进度，审阅并合并 PR。

而驱动这一切的 prompt，只有五句话：

/goal We want to migrate the repo from Enzyme tests to React Testing Library style tests. Follow existing norms and best practices in the codebase. Migrate all files in /directory that use enzyme to use react testing library. Test your changes with [test command]. Generally bias for migrating easy-to-convert files first.

翻译过来就是：把仓库的测试从 Enzyme 迁到 RTL 风格，遵循代码库里已有的规范，迁移指定目录下所有用到 Enzyme 的文件，用测试命令验证改动，优先迁容易转的文件。没了，就这五句。

更有意思的是，他们还试过更花哨的玩法：把工作拆成可追踪的 ticket、让 agent 维护一份运行笔记、让 agent 再派生子 agent 进一步并行、写一份更详细的 RTL 约定说明。结果这些几乎全都让事情变得更糟。

简单赢了。

为什么五句话就够#

这是整件事里最关键的部分，也和 OpenAI 之前在 Harness engineering 里写过的观点一致：agent 产出的质量，很大程度上取决于你递给它的「环境」质量。

Asana 的代码库里已经沉淀了多年积累的好品味：当初选择 RTL 的决定、设计良好的测试工具、清晰的代码约定、随手可翻的真实示例。模型不需要你去解释这些，它自己就能读到。团队只需要给出目标，然后放手让 agent 跑。

另一方面，这个任务本身的形状也对路：有一个干净、可验证的「完成」定义（代码库里不再有 Enzyme），还有快速的反馈回路，类型检查、lint、测试、CI 都能立刻抓住错误。

好的脚手架，加上定义清晰的问题，需要的人工引导自然就少。

真正拖后腿的，是人不是模型#

最有意思的反转在这里：整个过程中最大的摩擦，几乎都不是模型的锅，而是团队自己的。

第一，仓库里一些较新的内部文档和 agent 引导，还在把 Enzyme 当成推荐写法，这等于在主动把 agent 往错误方向带。过期文档以前只是小麻烦，现在成了误导每一个读它的 agent 的训练材料。

第二，缓慢又不稳定的工具链。一个 lint 步骤偶尔要跑十几分钟，CI 和本地检查的结果还不一致。这些地方恰恰是团队需要人工介入最多的。

换句话说，瓶颈很少是 agent，往往是团队自己的基础设施。

脚手架才是现在的产品#

这个项目留下的一条更清晰的教训是：AI 没有消灭对工程品味的需求，反而把它放大了。

干净的示例和清晰的约定，会产出干净、规整的结果；别扭的写法也会被原样复制。文档也一样，过时的引导在只有人类读它的时候没多大危害，一旦 agent 开始读，就变成了实打实的负债。

好消息是，这个效应会反过来叠加。好的示例会扩散，清晰的文档能正确引导 agent。投资在「脚手架」上，也就是代码周围的文档、约定和反馈回路，会在未来每一次迁移里持续回本，而不只是这一次。

数字的另一面#

现在说点不那么提气的话。

这个案例在 Hacker News 上引发了相当激烈的讨论，核心质疑集中在「五年」这个数字上。很多人指出：一个测试框架的迁移，本来就不该是一个五年的项目，那个估值本身可能就严重注水。更接近真相的说法也许是，这是「一个人兼职五年、且永远排不上优先级」的活儿，而不是一支专门团队埋头五年。

还有一个诚实的总结值得转述：AI 并没有在两周内凭空造出五年的创新性新功能，它是在两周内做完了五年的枯燥、大规模、可验证的代码迁移技术债。前者是营销话术，后者才是真的。

这恰恰是 AI 目前最擅长的那类工作：机械的、重复的、有明确完成标准、且能靠测试和 CI 快速验证。迁移、重写、移植，这些让人类工程师又累又烦又容易出错的活，正是 agent 的主场。

Asana 自己的账也算得很清楚：模型用了大约一万一千美元，基础设施一千美元，总共一万二。如果按原计划再拖五年、配三个高级工程师，按湾区每人每年三十五到四十五万美元的全成本估算，这条路要花五到七百万美元，还没算这三个工程师不去做产品而浪费的机会成本。一万二对六百万，这就是那个「不讲道理的一周目标」能撬开的差距。

什么样的问题适合这么干#

结合 Asana 的经验和 HN 上的讨论，能这么玩的迁移任务，通常满足几个条件：

  • 有干净、可验证的「完成」定义。Enzyme 消失就是消失了，没有灰色地带。
  • 代码库本身已经有好品味，示例和约定都清晰。模型是在模仿你的既有模式，你的模式越好，它的产出越好。
  • 有快速的反馈回路，类型检查、测试、CI 能在几秒到几分钟内暴露错误，而不是等到人工 review 才被发现。
  • 任务本身是机械的、可迁移的，而不是需要从零设计的创新工作。

反过来，如果你的代码库一团乱、文档过时、CI 又慢又不稳定，那么直接上 agent，大概率会得到一堆复制了你所有坏习惯的输出。

结尾#

Asana 的 CTO 有句话说得挺实在：不是每一个多年的项目都能塌缩成几周，但 agent 能多给工程师留出一些打磨手艺的空间，也能让一些原本「不可能」的工作变得值得一试。

对这个案例，我更愿意记住的，不是「两周 vs 五年」这种反差，而是那个更朴素的问题：你有没有真的在某个周末，把一个 agent 指向那个积压多年的迁移任务，然后看看周一早上它带回来了什么？

很多团队缺的从来不是答案，而是问出这个问题的勇气。

参考来源：