昨天 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 执行 人批量 ReviewAsana 的工程师每天检查两次说明工作方式已经从实时 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:30required_checks:-compile-unit_test-lint-dependency_scanprotected_paths:-security/-billing/-migrations/human_review:required:true这些规则比“请谨慎修改代码”靠谱得多。另一个值得学习的地方每个变更都 ReviewAsana 没有因为 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-testsbase_commit:a8d93f1scope:include:-src/auth/**exclude:-src/billing/**checks:-test:auth-typecheckmax_files_changed:40这样 Worker 的边界是硬的。如果只是给四个 Agent 同一句“你们一起移除 Enzyme。”最终最麻烦的通常不是模型能力而是 Merge 冲突。PR 不宜越大越好Coding Agent 很容易一次改几百个文件。机器不累但人会累。我更愿意把 Review Budget 也纳入 Agent TaskTarget 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这会让第二次任务比第一次更便宜。