五年代码迁移压到两周，技术债**次值得重新报价

技术债常年排不进计划，不是因为没人知道它有害，而是收益难量化、改动面太大、业务功能永远更急。Asana 的 Enzyme 测试迁移就是这种项目：旧测试工具已经停止活跃维护，阻碍前端技术栈升级，团队多年持续处理，按当时速度仍预计还要大约五年。长期搁置，本质上是旧成本模型下的不经济。

据 Asana 与 OpenAI 的公开案例，团队最多同时运行四个编码智能体，让它们分别处理不同目录，工程师每天早晚检查进度并审查每一项建议变更。最终，Enzyme 在约一点五周工程工作、两个日历周内被完全移除；模型使用约 1.1 万美元，基础设施约 1000 美元。Asana 估算，包含测试覆盖改进和旧测试设施清理在内的同等人工范围约需 600 万美元。这些周期与成本属于厂商及客户自报，不能外推为行业平均。

这组数字真正改变的不是“工程师是否还写代码”，而是某些一直被判定为不值得做的项目，是否应该重新进入投资清单。判断重点不是代理有多便宜，而是项目能否被拆成可验证、可回退的批次。

这次迁移的目标非常明确：把使用 Enzyme 的测试改为 React Testing Library 风格，完成定义是代码库中不再使用 Enzyme。文件可以按目录切开，每个代理在独立代码副本里工作，结果还能通过类型检查、代码规范、测试和持续集成快速反馈。边界清楚、重复量大、结果可自动判定，是成功的三个前提。

企业在重估技术债时，可以先做一张“可机器化地图”。**类是高可切分任务，例如弃用 API 清理、依赖升级、测试框架迁移、格式修复和统一接口替换；第二类虽然能拆，却涉及公共组件、跨仓库版本或不稳定测试，需要更小批次；第三类是目标架构未定、业务语义只在人脑中、缺少回归证据的重写。多开代理不会把第三类问题自动变成**类。

真正的立项指标不是代码行数，而是可自动判定比例。团队应抽样回答：多少文件能独立修改，完成标准能否写成命令，失败是否能定位到单个批次，关键行为有没有可重复的基线。如果代理产出只能靠资深工程师逐行猜测意图，生成速度越快，审查队列反而越长。不可验证的迁移，只会更快制造新的技术债。

还要识别“隐形耦合”。一段测试可能表面只属于一个目录，却依赖共享夹具、全局状态、时间、网络或顺序。试点中应记录跨目录触碰率、公共文件冲突率和不稳定测试数量。冲突不是单纯的执行故障，它是在提醒切分边界画错了。

Asana 案例采用的提示只有五句话。简单指令之所以有效，不是提示词有魔法，而是代码库已经沉淀了清楚规范、测试工具、现有范例和快速反馈。代理可以从环境中读取“好代码长什么样”，工程师才不必把所有惯例重新写进提示。真正的控制面在仓库与测试体系，而不在提示词长度。

如果企业要复制这种工作方式，至少要把五件事固定下来：每个代理拥有独立分支或工作区；目录和允许修改的公共文件明确；完成定义一致；合并前运行相同检查；每个变更都能追到代理、提示、测试结果和审查人。并行的是生成，串起来的是同一套质量标准。

批次大小决定了吞吐是否真实。太大时，代理容易越界、测试时间过长、人工难以理解；太小时，工程师会被大量琐碎合并拖住。可以从一个目录或几十个相似文件开始，根据一次通过率、平均审查分钟、冲突率和回滚成本逐步调整。**并发不是代理数量最多，而是质量闸门没有形成积压。

人工审查也要换一种重点。工程师不必重新手写代理已经完成的机械替换，但要检查行为是否等价、边界条件是否遗漏、共享辅助代码是否被误改，以及测试是否只证明“能运行”却没有证明业务语义。对于安全、性能和关键交互，还要保留专门回归。机器负责扩大处理面，人负责决定什么可以放行。

当代理反复碰触边界外文件、多个工作区修改同一公共组件，或测试开始间歇失败时，正确动作是暂停扩张、重画目录和补测试，而不是继续加并发。生成吞吐必须服从可审查吞吐。

约 1.2 万美元与约 600 万美元形成强烈对比，但经营决策不能只拿令牌费用对比工程师工资。完整成本还包括任务准备、测试补齐、工作区与算力、人工审查、冲突处理、失败返工、合并发布、上线观察和后续维护。代理成本低，不等于总交付成本只剩代理账单。

更合适的核算单位是“一个可放行的迁移批次”。分母可以是完成文件数、清除的弃用调用或通过的测试；分子要纳入代理运行、工程师审查、失败重跑和上线保障。与此同时记录自动检查一次通过率、每百个变更审查时长、回归缺陷、生产撤回和遗留问题。成本必须和可接受质量绑定。

这种口径还能识别伪节省。如果生成费用很低，但团队花了数周补测试、解释巨型改动或修复回归，项目只是把成本从“编码”转移到了“验证”。反过来，即使代理账单不低，只要它让阻塞升级的旧依赖退出、减少未来维护路径，长期价值仍可能成立。重新报价要同时看交付成本、风险下降和被释放的后续选择。

Asana 自己也提醒，并非每个多年项目都会压缩成数周。被重新定价的是一种工作结构：目标清楚、环境规范、反馈快速、变化可回退。智能体改变估算参数，没有取消工程复杂性。

企业可以选择一个已停止维护、文件边界清楚、测试较完整的依赖，先迁移一个目录。启动前保留人工基线：工程师通常处理多少文件、需要多久、常见失败是什么；试点中记录代理费用、运行时长、审查分钟、测试失败、越界修改和回滚；结束后再比较可放行结果。试点目标不是证明智能体会写代码，而是得到下一批可以使用的报价依据。

放行仍由工程负责人承担：验证行为等价、关键路径性能、安全依赖、发布可恢复和责任记录完整。**批成功后，也不要立刻全库铺开，而应把有效提示、仓库规范、失败样本和新增测试沉淀下来，再扩大到相邻目录。每一批迁移都要让下一批的环境更容易被判断。

停止条件同样重要。如果自动检查持续下降、人工审查超过原手工成本、公共组件冲突上升，或团队无法解释变更影响，就应缩小范围或回到人工方案。能及时停止，才叫重新估算，而不是追逐一个醒目的案例数字。

技术债不再只能按旧人力模型排队。当任务可切分、结果可判断、变更可回退，曾经不经济的清理工作就值得重新报价。先用小批次改写估算，再决定是否改写路线图。这既承认编码智能体带来的成本变化，也保留工程组织对质量、风险与长期维护的最终责任。