AI 驱动的代码现代化项目怎么做 · Anthropic 博客翻译解读
来源：Anthropic Blog字数 ≈ 5000阅读 ≈ 15 分钟类型：技术博客难度：中
来源：Anthropic Blog — How to prepare for AI-driven code modernization projects
作者：Jonah Ezekiel, Lexie Tonelli（Anthropic 前向部署工程师）
分析完成时间：2026-09-26 18:10:00

AI 驱动的代码现代化项目，该怎么做准备？

这篇文章回答的问题： 当 AI agent 把"写代码"加速 100 倍之后，为什么项目还是慢？——因为瓶颈从产出代码转移到了组织动员，本文给出 6 步准备框架。
这篇文章应该回答但没回答的问题： 由 AI 生成的"证书"（测试+审查）能否真正等价于人类信任的正确性证据？失败案例和真实成本数据在哪？

一句话总结

AI 让代码现代化从"多年全员项目"压缩到"几周~几个月"，但银行级系统的人工审批、变更管理、审计流程一寸没少。Anthropic 的解法：把"什么算完成"（target）、"什么证据算正确"（certificate）、"怎么上生产"（promotion policy）全部前置定义成机器可检查的契约，然后让 agent 流水线朝着证书自我迭代。瓶颈不再是写代码，而是组织能否被动员起来消化这些变更。

六步框架速览

  • 定义目标（Target）：现代化后的技术栈和行为到底是什么。
  • 定义证书（Certificate）：每个变更被视为"正确"必须满足的可机器检查条件。
  • 设定晋升策略（Promotion Policy）：通过认证的变更以什么分级审查路径进入生产。
  • 备齐前置条件：环境、CI/CD、审查人力、审批、安全边界。
  • 构建并打磨 agentic workflow：用 Claude Code 动态工作流把现代化拆成大量并行 subagent 工作流。
  • 运行：先在小分区端到端跑通，再全量扩展。

    • 逐步解读

    ### Step 1：先决定你在做哪一种现代化

    类型本质适用场景目标包含
    Uplift（升级）同栈版本跳（C++11→C++20）栈没坏，只是版本落后：EOL 运行时、无法打补丁运行时版本 + 包集合
    Transform（转换）跨栈重写、行为不变（COBOL→Java）栈是问题，行为可信Uplift + 语言/框架/架构约定
    Reimagine（重塑）新架构重写、行为也改行为本身要变Transform + 书面行为规格书

    组织内常见的路线之争：贴近生产的人要 Transform（锁行为、控风险），与代码共存多年的工程师和业务方想 Reimagine（顺手还债、加新需求）。两者都有理，但这个争议不提前解决，后面每次都会以"这个变更到底对不对"的吵架形式复活。

    行为盘点可以用 Claude 做：code modernization plugin 的 assess、map、extract-rules 命令能挖出带源码引用的业务规则。但 AI 的发现补不齐全部——业务用户访谈、内部文档仍不可少。前期上下文的质量，决定了后面工作流每一个决策的质量。

    立项理由上，Anthropic 的经验是：降本通常不是主驱动，降风险才是。带未修补漏洞的系统、EOL 运行时、会这门老语言的工程师越来越少——"不现代化的风险"才是推动项目的那个砝码。

    ### Step 2：证书（Certificate）——把"正确"变成机器可检查的合同

    证书 = 每个变更必须满足的条件集合。关键设计约束：每条都必须无人参与即可检查，这样 agent 才能对着证书自我迭代，不达标就升级给人。

    候选条件清单（按目标裁剪）：

  • 原有测试套件全过
  • 现代化过程中 Claude 新写的测试全过
  • 测试覆盖率达到约定阈值
  • 性能基准在约定边界内
  • 多个独立上下文窗口的 Claude 对抗性审查无阻塞问题
  • UI 用 Claude computer use 验证无回归
  • 新旧版本对相同输入（live/录制/AI生成）产出相同输出
  • 持久化状态和线上协议格式新旧往返一致
  • staging 观察期内错误率/延迟/告警无回归
  • 静态分析和安全扫描无新增发现

    • 设计期就把依赖方开发者和业务负责人拉进来。检验证书质量的金标准：如果只看证书证据，他们敢不敢直接 merge？ 敢，说明证书里有他们自己的标准，Step 3 的晋升策略就可以更轻。

    ### Step 3：晋升策略——agent 产出速度 >> 人工 diff 审查速度，怎么办

    Agent 产变更的速度远超人类逐 diff 审查的能力。晋升策略就是一份提前书面约定、自上而下授权的分级审查路径：

  • 满足证书的变更走轻审查快速通道；
  • 被标记的变更进深审查；
  • 同类标记反复出现 → 回头修 workflow 或证书，而不是逐个人审；
  • 约定什么信息格式让审查最快，Step 5 让审查者预审样例输出；
  • SME 时间前移到设计期，反馈用于调证书和 workflow。

    • 速度 vs 审查深度是个光谱：赶 EOL 死线的项目要快政策+轻审查+明示接受更高单变更风险。最好由组织高层下达政策指令，且事前谈妥——这样 bug 进了生产是共同责任，而不是甩锅给"当时点批准的那个人"。

    ### Step 4：前置条件清单

  • 环境与 CI/CD 就绪，证书检查可自动执行
  • 依赖方团队签字：认可证书、按晋升策略出人审查
  • agent 最小权限：只写现代化分支、零生产凭据
  • 密钥和 PII 从现代化分支清洗/脱敏
  • 每个变更可追溯：PR 链接到 agent transcript 和证书证据
  • 新依赖过 license 和漏洞检查

    • ### Step 5：构建 agentic workflow

    用 Claude Code 的 dynamic workflow 定制现代化流水线，从官方 code modernization plugin 起步。把 target、certificate、promotion policy、代码库、文档、证书所需数据源全部放到 Claude 可达的文件系统或 MCP 上——形成项目中央知识库。

    有意思的判断：在这一步之后，"构建现代化工作流"反而是简单的那部分。SME 审查 Claude 的产出（包括提取出的业务规则、codebase 专属 skills），在小块代码上试跑并打磨。

    核心工程原则：问题暴露时修 workflow，而不是修单个变更。 目标是规模化后变更几乎处处达证书、审查者愿意按晋升策略 merge。

    ### Step 6：先小后大

    先在一个小分区端到端完成——包括走完晋升策略的审查和落地。趁便宜修掉所有问题，循环到有信心，再全量。Transform/Reimagine 是并行建目标系统、完成后切换；Uplift 还可以原地升级：从叶子分区向内切，一次冻结一个分区现代化，CI/CD 加门禁防止新提交回退已现代化分区。

    ### 成本：token 花在哪

    主要成本驱动：代码读取量 vs 修改量、证书的复杂度（受监管环境下，验证而不是写变更才是大头）、证书要求的新测试编写与修复量、运行期间与其他团队合并的调和成本。做法：用试点实测 token 用量外推全量，试点看不到的（如活代码库调和）按未知项留白；昂贵验证信号放到便宜检查之后执行；机械高量工作用 Sonnet 这类性价比模型，硬转换和对抗审查留强模型。便宜模型反复重试的累计成本可能高于强模型一次通过——试点期要盯重试率。

    ### 超越现代化本身

    产出的不只是新代码库，还有：可复用的 workflow、书面化的正确性证书、已被变更管理流程接受的晋升策略、每个变更的证据链。把 playbook 固化为资产，下次升级/重写直接复用。

    压力测试：这篇的三个软肋

  • 自己验证自己：证书里大量条件是"Claude 写的测试 + Claude 对抗审查 + Claude computer use 验证"——写代码的和验代码的是同一个厂商的模型，存在系统性盲区共谋风险（同一个训练分布里缺的知识，写和验都发现不了）。
  • 无失败样本：文章全是 forward deployed 成功经验，没有失败率、放弃率、证书返工周期的数据，幸存者偏差未对冲。
  • 利益相关：这是 Anthropic 卖 Claude Code 企业服务的软文框架（结尾"talk to our team"），六步法本身有普适价值，但"certificate 可自动化"这个核心假设正是它产品化的前提——立场决定叙事。

    • 苏格拉底对话

    学生： AI 都能把多年项目压缩到几周了，为什么企业还没全面跑起来？

    老师： 你修过银行核心系统吗？每个变更要走变更管理、审批、审计。这些流程快了吗？

    学生： 没有……那瓶颈到底是什么？

    老师： 写代码。以前 90% 时间在产出变更，10% 在走流程；现在产出被压缩到接近 0，流程占比变成 100%。所以问题从"怎么写"变成"组织怎么消化"。

    学生： 所以 Anthropic 给的解法是把"正确"定义成合同？

    老师： 对。你想想，为什么"证书必须无人可查"是铁约束？

    学生： 因为 agent 要能自己对着证书迭代，一插人就断流。

    老师： 那人类审查者还信任什么？

    学生： ……证书本身。如果证书里有他们的标准，看证据就敢 merge。

    老师： 这就是整套设计的支点——把信任从"审查 diff"前移到"共同设计证书"。那它的最大风险是什么？

    学生： 证书写代码的和验代码的都是 Claude，会不会一起错？

    老师： 会的。所以高价值系统里，真正的独立信号（生产流量比对、真实用户验证）比 AI 对抗审查更值钱。这是这篇文章没说透的地方。

    个性化洞察（对尾巴）

  • QA 背景是这套框架的一等公民：Certificate 本质是"机器可执行的验收标准"，这正是 QA 工程师最擅长的东西。AI 时代 QA 的价值不是点工单，而是设计这种分级验证合同——你可以把这套六步法包装成自己的方法论资产。
  • 直接可复用到自己的项目：wish-tree、happyclaw 这类个人项目虽无银行级流程，但"target → certificate → promotion policy"照样适用，比如给 Codex 定 AGENTS.md 时把"测试全绿 + lint 通过"写成证书，把"post-write-lint + auto-commit"写成晋升策略，本质就是同一套思想的微缩版。
  • 内容选题：「AI 时代 QA/测试工程师的价值迁移：从写用例到设计证书」是一个非常好的技术自媒体选题，能结合你背景形成差异化观点。
  • 模型策略可直接抄：机械高量用便宜模型、硬转换和对抗审查用强模型、盯重试率防止"便宜模型循环烧钱"——这条对日常 Codex 多模型调度同样成立。

    • 金句

    一旦 agent 加速了变更的产出，瓶颈就从产出变更转移到围绕变更动员组织。
    Once agents accelerate writing the changes, the bottleneck shifts from producing changes to mobilizing the organization around them.
    问题暴露时，修改的是工作流，而不是每个变更。
    You should modify the workflow, not each change, when issues surface.
    降风险通常比降成本更重要。争论要不要现代化时，想想不现代化的风险。
    Risk reduction is often the most important modernization benefit. Consider the risk of not doing the modernization.