Asana 把一个“要做 5 年”的前端迁移压到 2 周：最反常识的细节是 Prompt 只有 5 句话

昨天 OpenAI 公布了一个很适合工程团队研究的 Codex 案例。

Asana 有一个拖了很久的技术债：移除 Enzyme。

Enzyme 曾经是 React 测试生态里非常常见的工具，但随着维护停滞，它逐渐成为现代化前端栈的障碍。

Asana 原来的计划很夸张：

预计至少 5 年
约 600 万美元人员成本

最后用 Codex 做完的实际结果：

约 2 个自然周
约 1.5 周工程投入
模型＋基础设施成本约 $12,000

这种数字很容易被包装成“AI 把 5 年工作变 2 周”。

我不准备这么写。

我更想拆的是这次迁移为什么能成立，以及哪些项目绝对不能照抄。

先看最关键的工程设置

OpenAI 披露的执行方式是：

最多 4 个 Coding Agent 并行
每个 Agent 使用独立代码库副本
工程师每天检查进度两次
所有提出的变更都由工程师 Review

还有一个很反直觉的细节：起始 Prompt 只有 5 句话。

Asana 尝试过更复杂的指令，但最后发现简单指令表现更好。

这和过去两年 Prompt Engineering 的习惯有点反着来。

以前我们总觉得 Prompt 越长、约束越多、结果越稳定。Coding Agent 长任务里未必如此。

因为真正稳定它的，不一定是 Prompt，而是：

仓库
测试
编译器
代码规范
PR Review

也就是环境本身。

为什么 Enzyme 迁移特别适合 Agent

这个项目有几个很重要的特征。

第一，目标明确：

Remove Enzyme

不是“重新设计整个产品体验”。

第二，有大量机械性工作：

• 找旧 API；
• 替换测试；
• 修编译；
• 跑测试；
• 修失败；
• 重复。

第三，结果高度可验证：

代码能不能编译
测试能不能通过
Enzyme 依赖还在不在

这类任务很适合 Coding Agent。

它的目标函数比“设计一个优秀架构”明确得多。

我现在会专门找一个指标：Verification Density

可以粗暴定义：

Verification Density
=
可自动验证的检查数
/
任务规模

例如代码迁移可以用：

编译
Lint
单测
类型检查
依赖扫描
搜索残留

Verification Density 很高。

品牌文案重构只有“感觉是不是更高级”，验证密度就很低。

我判断一个项目适不适合大规模 Coding Agent，不再先看代码量，而先看验证密度。

4 个 Agent 并行并不是“大家一起改同一个分支”

这里也很关键。

每个 Agent 使用独立代码库副本。

这意味着并行阶段避免了：

• 文件锁；
• 工作区互相污染；
• 一边改一边覆盖；
• 临时文件冲突。

真正困难的部分被推迟到 Review 和 Merge。

如果你现在直接让 4 个 Agent 共用同一个 working tree，我非常不建议。

一个最简单的并行 Worker 目录

/workspaces/
├── task-001-agent-a/
├── task-002-agent-b/
├── task-003-agent-c/
└── task-004-agent-d/

每个任务记录：

{
  "task_id": "migration-128",
  "agent": "worker-b",
  "base_commit": "a8d93f1",
  "branch": "agent/migration-128",
  "workspace": "/workspaces/task-002-agent-b"
}

输出不是直接 Push 主分支，而是 Patch、Commit 或 PR。

为什么工程师一天看两次，而不是全程盯着

这也是 Agent 与传统 Copilot 的区别。

Copilot 模式：

人写
AI 补

人一直在线。

Agent 模式：

人定义目标
Agent 执行
人批量 Review

Asana 的工程师每天检查两次，说明工作方式已经从实时 Pair Programming 变成异步监督。

这会带来一个新瓶颈：

Review Throughput

以后团队可能更该测“每天能 Review 多少 Agent 产出”

以前开发效率常看 Story Points、PR 数、Commit、代码行。

现在应该增加：

Agent PR / engineer / day
Review minutes / PR
Reject rate
Rework rate
Merge success
Post-merge defect

如果 Agent 每天生成 50 个 PR，人只能认真看 10 个，Agent 更快也没用。

$12K 和 $6M 不能直接做 ROI 除法

这是这类案例最容易被误读的地方。

不能简单说：

AI 节省 99.8%

因为两个方案的计算口径不同。

原来的 $6M 是长期人员计划估算，$12K 是模型和基础设施成本，没有包含工程师 Review、方案准备、监控、合并、测试、风险和平台成本。

正确比较应该至少是：

Agent方案总成本
=
模型
+ 基础设施
+ 人工 Review
+ 失败返工
+ 平台成本

即便加上这些，差距仍可能很巨大。但工程文章不能为了标题好看把口径混掉。

为什么以前会觉得要 5 年

很多技术债项目并不是持续 5 年全职开发，而是每个季度做一点、优先级不断被业务挤掉、依赖很多、收益不直接，于是自然变成多年项目。

Agent 的价值之一恰恰在这里：它让“很重要，但一直不值得占用大量工程师时间”的任务重新变得经济可行。

我觉得这是比“AI 写代码更快”更大的变化。

我会优先把哪些技术债交给 Coding Agent

第一批：

依赖升级
测试框架迁移
API 批量替换
类型迁移
Lint 修复
Deprecated API 清理
测试补齐
文档和代码同步

第二批：

性能热点重构
跨模块架构调整
数据库迁移
协议替换

需要更多 Review。

最后才是核心业务重新设计，因为验证目标最模糊。

“简单 Prompt 更好”说明了一个成熟方向

一个成熟 Coding Agent 环境，应该尽量把约束从 Prompt 拿出来。

例如“代码必须格式正确”，不要只写 Prompt，用 formatter。

“不能破坏类型”，用 compiler。

“不能让登录挂掉”，用 tests。

“不能改 security 目录”，用 filesystem policy。

“只能修改 20 个文件”，用 diff gate。

这样 Prompt 才能真正变短。

我会给 Coding Agent 加几个硬门

coding_gate:

  max_files_changed: 30

  required_checks:
    - compile
    - unit_test
    - lint
    - dependency_scan

  protected_paths:
    - security/
    - billing/
    - migrations/

  human_review:
    required: true

这些规则比“请谨慎修改代码”靠谱得多。

另一个值得学习的地方：每个变更都 Review

Asana 没有因为 Agent 一次成功率高，就直接开放自动 Merge。

所有提出的变更仍然经过工程师。

这说明至少在这种大规模遗留迁移里：

Agent = 高吞吐贡献者
Human = 最终 Maintainer

这个分工我觉得目前非常合理。

如果要在自己公司复制

我建议先选一个 500 个文件以内、边界清晰、自动验证充分的项目。

第一期不要一上来就说“把 10 年单体系统重构成微服务”。先找一个具体债务，例如移除一个过期依赖，更容易验证任务拆分、Workspace、Agent 并行、PR 合并、测试、Review 和成本。

最后一个判断

Asana 这个案例最有价值的不是“5 年 → 2 周”，而是它重新定义了哪些软件项目“值得做”。

以前有一批任务：

价值有
但不值 20 个工程师干半年

Agent 把执行成本压下来以后，它们突然从 backlog 里的永久债务变成可以尝试的项目。

未来 Coding Agent 最大的影响可能不是每个人每天多写 30% 代码，而是：

公司终于开始清理那些过去永远排不到优先级的技术债。

如果你手里有一个“大家都知道应该做，但算下来永远不划算”的迁移项目，现在确实值得重新估一次。

真要复制 Asana，我会先做任务切片，而不是先加 Agent 数量

四个 Agent 并行的前提，是任务可以拆成相对独立的工作包。

例如 Enzyme 迁移可以按：

目录
组件族
测试类型
依赖层级

拆开。

一个 Task Manifest 可以写成：

task: enzyme-migrate-auth-tests
base_commit: a8d93f1
scope:
  include:
    - src/auth/**
  exclude:
    - src/billing/**
checks:
  - test:auth
  - typecheck
max_files_changed: 40

这样 Worker 的边界是硬的。

如果只是给四个 Agent 同一句：

“你们一起移除 Enzyme。”

最终最麻烦的通常不是模型能力，而是 Merge 冲突。

PR 不宜越大越好

Coding Agent 很容易一次改几百个文件。

机器不累，但人会累。

我更愿意把 Review Budget 也纳入 Agent Task：

Target PR:
20—40 files
15—30 min human review

如果一个 Agent 预计产生 300 文件 Diff，就继续切片。

这其实是在优化：

Human Review Latency

而不是 Agent Runtime。

一个可以实际统计的迁移漏斗

Discovered targets: 3,820
Assigned: 3,820
Agent completed: 3,611
Checks passed: 3,402
Human accepted: 3,290
Merged: 3,248
Post-merge regressions: 7

这组数字比一句：

“Agent 完成率 94%”

有用得多。

因为能看出问题究竟发生在执行、自动验证、人工 Review 还是合并以后。

最值得沉淀的是迁移 Recipe

第一次做 Enzyme 迁移时，需要人设计很多规则。

完成后应该留下：

Detection Rule
Transformation Pattern
Validation Command
Known Exceptions
Review Checklist

下一次类似 Jest、Router、API 或类型迁移就可以复用。

所以 Agent 做技术债，不应该只生产代码，还应该生产一套：

Migration Recipe

这会让第二次任务比第一次更便宜。

更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：

https://www.zyentor.com/