ARTICLE · 1087227
AI 改写代码库之前:来自 Anthropic 一线部署工程师的实战笔记
过去，代码现代化改造常被视为耗时数年的全员工程；如今借助 Agent，几个月甚至几周就能跑完。但技术加速只解决了一半问题，对银行核心系统这类关键系统的每一次变更，依旧要经过变更管理、审查和批准。当然，这很有必要，因为监管、审计和业务方都需要一个稳健而可信的基础。但这个基础需要建立在两个假设上，一是每个变更都由人类编写，二是每个 diff 由人类审查。
当 Agent 提升了编写的速度，瓶颈就从写代码转移到了"围绕变更调动组织资源"。本文涵盖企业在现代化改造开始前必须完成的工作，我们将它分解为下面这六步。
一、先定义目标，再谈工具
现代化的终点长什么样，决定了你做的是哪一种现代化。组织内部往往对此有分歧，最接近生产环境的人希望只换技术栈、保持行为不变，以控制风险（转换型）；而长期与代码库共处的工程师想借机偿还技术债（提升型）；还有业务方希望能借此机会提出新需求（重构型）。这几种立场都有道理，但若这个问题悬而不决，它会在后期以"这个变更到底对不对"的争论重新爆发。
理解当前系统通常是定义目标的第一步。先把当前系统摸清楚，提取旧代码到底做了什么，列出当前行为的清单，才能判断哪些该改、哪些该删，也更容易暴露那些没人记得为什么存在的业务逻辑和边界情况。Claude 可以通过梳理依赖、把无人记得构建过程的工作流文档化，完成大部分发现工作；代码现代化插件的 assess、map、extract-rules 命令能挖出业务规则并附上来源引用，交给工程师审查。
二、给每次变更发一张"证书"
证书是每一次现代化变更都必须满足的条件或测试集合。每一项都要能在无人干预的情况下被自动检查，这样 Agent 工作流才能自己迭代变更，直到满足证书，或在无法满足时标记为需要人工审核。
证书的内容取决于目标，但通常来自一份通用清单：
原始测试套件通过；
新增测试全部通过；
覆盖率达标；
性能基准不退化；
独立的对抗性审查没发现阻塞性问题，UI 无回归；
相同输入产生相同输出；
持久化状态与线路格式可往返；
在预发布环境跑约定时长无错误率、延迟或告警回归；
静态分析和安全扫描无新问题；
编译干净、类型检查通过。
最重要的是证书要和被你改变的代码库打交道的人一起写，包括当前依赖这段代码的开发者、用户群体、业务负责人。他们的专业知识塑造了证书的衡量内容，他们的早期参与，是变更进入审查时愿意放行的基础。
三、提前设定晋升策略
Agent 产生变更的速度，远超任何人类团队逐 diff 审查的节奏。晋升策略就是一条提前书面约定的分层审查路径，它设定了变更的人工审查深度，让现代化能在可接受的时间线上完成。
和证书一样，这一步要和审查者一起做，并尽量融入组织既有的变更管理流程。几条普遍适用的规则：
按影响范围和智能体置信度对变更分层，关键路径保留完整人工审查； 在源头修复反复出现的标记，同一种标记反复出现时，去改工作流或证书的根因； 与审查者共同设计输出格式，约定什么信息、什么格式让审查最快，什么信号比其他信号更能给信心； 有效分配领域专家时间。领域专家不会阅读每一个最终 diff，但要能直接进入最高风险层级的变更，以及每一层中被标记的智能体决策。
四、落实前置条件
这一步很多工作要靠现代化团队之外的团队完成：平台或基础设施团队提供主机，QA 或发布工程团队提供测试能力，安全和合规团队负责审批。每个团队都有自己的待办和审批流程，所以要尽早开启对话，通常在第 1 到第 3 步进行时就要动起来。
需要准备的东西包括：
一个专用远程主机跑工作流；
证书所需的测试能力，以及能强化证书的生产遥测、并行部署或回放数据；
代码库的依赖映射；
面向活跃开发者的沟通计划，涵盖代码冻结和新的兼容性要求；
安全与合规侧，则要打通经批准的 Claude Code 模型访问路径、给智能体工作流最小权限（只写现代化分支、无生产凭证）、清除或遮蔽密钥与个人信息、让每个变更可追溯（PR 链接到智能体记录和证书证据）。
五、构建并打磨智能体工作流
用 Claude Code 开发定制化的动态工作流来现代化代码库。建议从代码现代化插件起步，并把工作流需要的一切都放在文件系统上或通过 MCP 提供——目标、证书、晋升策略、代码库、文档，以及证书所需的任何数据源或工具。
让领域专家按需审查 Claude 的工作，包括任何代码库特定的技能或提取出的规则，在下游依赖它们之前就先审。先用代码库的一小部分验证你构建的东西，由领域专家审查它产生的变更、智能体的过程，以及证书被满足的证据。出了问题，你应该修改的是工作流，不是每一个变更。
六、先小步验证，再全面铺开
先在代码库的一小部分上端到端完成现代化——包括走完晋升策略、把变更落地。成本还低的时候修复所有不工作的地方，重复这个过程直到你有信心，再扩展到整个代码库。
转换型和重构型现代化，通常是在现有系统旁边构建目标系统，完成后切换；而"提升型"现代化有第二个选项，在开发继续的同时，对活着的代码库进行原地现代化。当系统不能停机、或代码库变化太快难以保持单独副本最新时，这是常见选择。有效的做法是把代码库从叶子向内划分为逻辑分区，一次冻结并现代化一个分区，并对 CI/CD 设门控，使新提交无法撤销已现代化的分区。
关于成本
常被问到这样的现代化要花多少 token。每个项目都不同，但主要成本驱动包括：
代码库里有多少需要读取而非修改；
证书的复杂程度（在受监管环境里，验证往往比编写更贵）；
证书要求编写和修复多少新测试；
运行中其他团队围绕你合并会产生多少协调工作。
建议在代码库的一小部分上完成现代化时测一次 token 用量，再据此推算整体，把试点看不到的协调成本当作未知项，这样你可以估计出整个现代化成本的下限。
真正的产出，不只是改完的代码
现代化后的代码库只是产出之一。同样重要的还有产生它的工作流、关于什么算正确的书面证书、变更管理流程已经接受的晋升策略，以及每个落地变更的证据链。把这套方法固化为可复用的资产，下一次升级或重写时，模式就已经就位。
原文：Anthropic《How to prepare for AI-driven code modernization projects》（Notes from the Field）链接：https://claude.com/blog/how-to-prepare-for-ai-driven-code-modernization-projects