写代码不再是瓶颈：Anthropic FDE 的 AI 代码现代化六步实战法

还有什么不可以

写代码不再是瓶颈：Anthropic FDE 的 AI 代码现代化六步实战法

这是 Anthropic 两位 FDE Jonah Ezekiel 和 Lexie Tonelli 于 2026 年 9 月 23 日发表的"实战笔记"（Notes from the Field）系列文章，标题为《如何为 AI 驱动的代码现代化项目做准备》。



From claude.com


核心论点：瓶颈发生了根本性转移



文章的全部逻辑建立在一个判断上：代码现代化（code modernization）曾经是按“年”规划的工程，现在可以被 Agent 压缩到几个月甚至几周，但组织流程没有跟上。银行的变更管理流程默认“每一处改动由人写、每一个 diff 由人审”，当 Agent 的产出速度超过人审速度时：

“一旦 Agent 加速了变更的编写，瓶颈就从‘产出变更’转移到了‘围绕变更动员组织’。”

这句话是全文的题眼。它意味着 AI 时代代码现代化的准备工作，重点不在写代码本身，而在预先设计好验证、审批和组织协同的机制。文章给出的六步流程，本质上就是把“组织动员”这一瓶颈提前拆解、逐一化解。

六步流程解读



第 1 步：定义目标（Define the Target）

文章把现代化分为三类，这是全文最实用的分类框架之一：

类型	定义	典型例子	适用前提
Uplift（升级）	同技术栈的版本跃迁	C++11 → C++20	栈本身没问题，只是版本落后（EOL 运行时、安全补丁缺失）
Transform（转换）	跨栈重写，行为保持不变	COBOL → Java	栈本身就是问题所在
Reimagine（重塑）	绿地重建，行为也会改变	—	想借机偿还技术债、纳入新需求

文章坦率地指出了一个常见的组织矛盾：生产团队倾向 Transform（把行为风险隔离掉），而熟悉代码库历史的工程师和业务方倾向 Reimagine（想一次性解决技术债、加上新需求）。作者的关键洞察是——如果这个分歧不解决，它不会消失，而是会在项目后期以“这个改动到底对不对”的争议形式反复浮现。所以前期花时间达成共识是值得的：“在路径选择上建立共识会增加初始摩擦，但会简化整个项目。”

这一步还包括用 Claude 的代码现代化插件做代码库测绘（依赖图、挖掘被遗忘的业务规则），但作者很诚实地提醒：插件生成的地图只是“好的起点”，大型老旧代码库还需要结合构建日志、import 分析、运行时追踪做更深入的前期测绘。另有金句：“前期情报收集可能耗时，但这些上下文的质量决定了后续工作流每一个决策的质量。”

关于立项论证，作者明确提出：风险削减（网络攻击面、无人维护的运行时、专家逐渐流失）往往比成本削减更重要，这在受监管行业尤其成立。

第 2 步：定义“证书”（Define the Certificate）

这是全文最具原创性的概念。所谓 certificate，是一组机器可校验的通过条件，每一处变更必须满足的客观标准，通常包括：

•原有测试套件通过；Claude 编写的测试通过且覆盖率达到阈值

•性能基准在允许范围内

•独立的“对抗性”Claude 审查（用全新上下文窗口充当红队）未发现阻塞问题

•通过 computer use 做 UI 回归检查

•新旧版本“相同输入 → 相同输出”（可用线上流量、录制流量或 Claude 生成的输入做差分测试）

•状态和线上传输格式可往返（round-trip）无损

•预发布环境浸泡期，错误率/延迟/告警无回归

•静态分析、安全扫描、构建、类型检查全部干净

证书的验收标准也很精妙：和审查者共同设计，最终检验是“审查者是否愿意仅凭证书上的证据就合并这个变更”。这个设计实际上把人工审查前置转化成了标准制定，审查者不再是流水线上的关卡，而是规则的设计者。

不同现代化类型对证据的依赖不同：Uplift 主要靠原有测试套件；Transform 靠流量回放、差分测试、生产并行部署；Reimagine 最难，锚点是书面行为规格书（spec），需要更多模型判断，且要预期证书本身会被反复修订。对于老系统测试覆盖薄弱的情况，作者建议直接用 Claude 补建缺失的证据基础。

第 3 步：设定晋升策略（Promotion Policy）

因为 Agent 的产出速度远超逐 diff 人审的消化能力，必须预先约定一套分层审查路径：

•按“影响范围（blast radius）+ Agent 置信度”给变更分层

•反复出现的告警要在工作流和证书层面从源头修掉，而不是在每个变更的审查中重复处理

•与审查者共同设计输出格式

•把稀缺的领域专家（SME）时间分配给最高风险层级和被标记的决策

这里有一个与传统流程相反的模式值得注意：让 SME 尽早介入（参与规则提取和证书签核），换取后端轻量化审查。传统非 Agent 流程是“最后才审”，Agent 时代是“前面重投入、后面靠机制”。作者还提到，在受监管环境中，这项指令应由最高管理层下达并事先取得共识，这样生产事故的责任是共担的，而不是甩给某个团队。

第 4 步：前置条件（Prerequisites）

一份务实的清单，分四个维度：环境（专用远程主机、测试容量、遥测/并行/回放数据）、代码库与 CI/CD（以构建日志或运行时追踪为依据的依赖图、依赖处理计划、兼容性检查、代码冻结政策）、团队（证书签核协议、审查者时间承诺）、安全合规（审批过的模型访问、最小权限——只给现代化分支、不给生产凭据、密钥/PII 清洗、Agent 会话记录与 PR 关联、许可证/漏洞检查）。值得注意的是“Agent 会话记录与 PR 关联”，这是让 Agent 工作可审计的关键设计。

第 5 步：构建并迭代 Agentic 工作流

从公开的 code modernization 插件和 Claude Code dynamic workflows 起步；把目标、证书、晋升策略、文档和数据源放到文件系统或 MCP 上供工作流读取；SME 在规则被下游使用前先审查插件提取出的业务规则；先在代码库的小块上试点。最核心的迭代原则是一句话：“问题浮现时，修改工作流，而不是修改每一处变更。”，这是把“逐个人工修 bug”的传统模式转化为“系统性改进生成机制”。

第 6 步：执行现代化

先在一个小分区上端到端跑通（包括审查和落地环节），迭代后再规模化。Transform/Reimagine 采用“与现有系统并行构建、最终切换”的路径；Uplift 可以原地现代化，把代码库“从叶子向内”切成分区，一次冻结并现代化一个，用 CI/CD 门禁防回归。

成本洞察



文章没有给出具体数字，但指出了几个定性的成本驱动因素，其中最反直觉的一条：在受监管环境中，“验证而非编写变更”通常占据成本的大头。模型选型建议是：机械性工作用 Sonnet，困难转换和对抗性审查用更强的模型；并警惕重试率，多次廉价的失败尝试，总成本可能超过一次昂贵的成功尝试。方法论上，用试点分区的 token 消耗外推成本下限，再持续优化。

读后的感受



文章的价值在于：它不是讲“AI 能写代码”，是讲“当 AI 写代码的速度超过组织消化代码的速度时，工程管理要怎么重构”。 证书（机器可校验的合并标准）、分层晋升策略、“修改工作流而非修改变更”这三个设计，本质上都是把人类判断从“逐件审查”升级为“规则制定 + 抽样监督”，这与传统制造业的质量体系演进（从事后检验到过程控制）逻辑同构，是可信的工程思路。

对从业者的核心启示：如果你在规划类似项目，真正值得提前投入的三件事是 (1) 在项目启动前把三类现代化的选择争论解决掉；(2) 把“什么算改完了”写成机器可校验的证书并与审查者共同签核；(3) 接受“验证成本大于生成成本”这个新常态，把预算和人力 accordingly 配置。项目结束后沉淀下来的工作流、证书、晋升策略和证据链，本身就是下一次升级的资产。