# Anthropic 前线工程师分享 AI 驱动代码现代化项目的六步准备方法 - 来源：Claude：Blog（网页） - 发布时间：2026-09-23 22:33 - AIHOT 分数：63 - AIHOT 标记：精选 - AIHOT 链接：https://aihot.news/items/cmue7dm420pvmroghjxeh5rk3 - 原文链接：https://claude.com/blog/how-to-prepare-for-ai-driven-code-modernization-projects ## 精选理由 来自 Anthropic 前线工程师的实战总结，把智能体驱动的代码现代化拆成可落地的六步组织流程。 ## AI 摘要 Anthropic 在 Notes from the Field 系列中分享管理大型代码现代化项目的经验，称原本需数年的现代化可在数月或数周内完成，瓶颈从写代码转向组织动员。 ## 正文 在我们的Notes from the Field系列中，Anthropic 的前线部署工程师分享源自真实客户部署的最佳实践。在本文中，我们分享管理大型代码现代化项目的经验。 代码现代化曾经被划定为耗时数年、全员投入的工程，如今可以在几个月（甚至几周）内完成，但两侧的组织性工作往往依然如故。 例如，对关键银行系统的每一次变更都必须经过变更管理、审查和审批。这是一套稳健的流程，因为监管机构、审计人员和业务方都要求如此。 正是这些流程让关键系统值得信赖，而它们建立在这样一个假设之上：每一次变更由人编写，每一个 diff 由人审查。一旦智能体加速了变更的编写，瓶颈就从产出变更转移到围绕变更调动整个组织。 本文涵盖企业在现代化真正开展之前必须完成的工作：定义何为完成、一次变更必须携带哪些证据、经过认证的变更将如何进入生产环境，以及必须预先准备哪些环节才能让整个流程得以启动。 我们将这一过程拆解为六个步骤： 定义目标：现代化后的代码必须具备的技术栈和行为。 创建证书：变更必须满足哪些条件，才能被视为在目标状态下是正确的。 设定晋升策略：已认证的变更以何种路径、按其产出速度进入生产环境。 落实前置条件：环境、CI/CD、评审能力以及审批。 构建并完善智能体工作流：定制的 Claude Code 动态工作流，将现代化改造分配到许多更小的并行子智能体工作流中，由它们产出变更。这一工作流围绕目标、证书和晋升策略构建。 运行现代化改造：在代码库的一小部分上端到端验证该工作流，然后再扩大规模。 第 1 步：定义目标 目标是现代化改造的最终状态。期望的最终状态决定了你正在做的是下表中详述的三种现代化改造中的哪一种。 确定现代化改造类型 类型 它是什么 选择时机 目标是 升级 同技术栈的版本升级（例如 C++11 → C++20）。 技术栈本身没问题，但版本已经落后：运行时已停止维护、安全漏洞未修补、依赖项无法再升级。 一个运行时版本和包集合。 改造 跨技术栈重写，同时保持行为不变（例如 COBOL → Java）。 技术栈是需要解决的问题，而行为是可信赖的。 升级所需的一切，外加新代码必须遵循的语言、框架和架构约定。 重新构想 在新架构上进行全新重建，并修改行为。 行为需要与代码一同改变。 改造所需的一切，外加新系统的书面行为规格说明。 决定进行哪种类型的现代化改造，往往会在组织内部引发争论。根据我们的经验，最贴近生产环境的人希望在不改变行为的前提下替换技术栈，以控制风险（转型式现代化改造）。另一方则通常是长期与这套代码库共处的工程师，他们希望借现代化改造来偿还技术债务，此外还有其他业务相关方，想借此机会提出新的需求（重构式现代化改造）。 这两种立场都合理，但如果这个问题悬而未决，它日后就会重新浮现，演变成一场关于某项改动是否“正确”的争论。就选择哪条路径达成共识，会在初期增加一些摩擦，但能让整个项目推进得更顺畅。 梳理代码库并创建行为规格说明 理解当前系统通常是定义目标的一个不错的起点。提取旧代码实际做了什么，并建立一份当前行为的清单，就能轻松判断哪些部分应当修改或舍弃，从而确定这次现代化改造是转型式还是重构式。这往往还能揭示出未知的业务逻辑和边缘情况。 Claude 可以通过梳理依赖关系，并为那些没人记得是谁构建的工作流程编写文档，来完成其中大量的探查工作。代码现代化插件的assess、map和extract-rules命令能够挖掘业务规则，并附上可供工程师随后审查的来源引用。 然而，仅靠 Claude 的发现可能无法完整呈现遗留系统的全部行为。与业务用户和开发人员的访谈，以及内部文档，可以填补这些空白。上下文收集在前期可能需要花一些时间，但上下文的质量会决定该工作流后续所做的每一项决策。 对于重新构想（reimagine）而言，定义目标需要额外的工作：应当写下详细的行为规格说明，并与用户群体达成一致。 来自代码现代化插件的一个交互式依赖关系图示例。 确立项目的合理性与目标 在定义目标的同时，组织还应考虑这项现代化究竟为何值得开展。对遗留系统进行现代化可以减少持续的维护和运营成本，然而，根据我们的经验，降低成本并非大多数现代化项目的主导目标。 降低风险往往是最重要的现代化收益。在讨论是否要开展该项目时，不妨考虑一下不进行现代化所带来的风险。 例如，一个带有未修补漏洞的系统可能意味着一次网络入侵，或一次严重到足以让企业本身陷入险境的停机。不再受支持的运行时，或理解该系统的工程师群体不断萎缩，都会加剧这一风险。 像 Claude Code 这样的智能体编程工具已经缩短了现代化改造的时间线，但预算仍然难以估算，这导致了惰性。我们已经公开了一些大规模现代化改造的成本，其他人也是如此。这些可以作为粗略的基线，我们在本指南底部还提供了关于预算预测的额外指导。 启动这些项目的主要挑战通常在于建立内部共识，并获得拥有该系统的团队以及依赖该系统的团队的承诺。构建商业论证并设定项目目标——通常是在领导层层面——会让这一过程变得更容易。这也有助于为后续的证书和推广政策中的权衡取舍提供锚点。当利益相关方对一项变更可以承载多少风险存在分歧时，不进行现代化改造的风险就是制衡力量。 第 2 步：定义证书 证书是每一项现代化改造变更都必须满足的一组条件或测试。选择那些能提供最强累积证据、证明该变更相对于目标是正确的条件。 每个条件都应该能够在无需人工介入的情况下进行检查，这样智能体工作流就可以对变更进行迭代，直到它满足证书要求；如果无法满足，则将其标记出来供人工审查。 证书中包含哪些内容取决于目标，但通常会从以下列表中选取： 原始测试套件通过 现代化改造期间编写的 Claude 生成测试全部通过 测试覆盖率满足约定的阈值 性能基准保持在约定的范围内 由 Claude 在各自全新的上下文窗口中进行的独立对抗性审查未发现阻塞性问题 对于用户界面，Claude 驱动的计算机使用未发现回归问题 当前版本与目标版本对相同输入产生相同输出，输入可以是实时的、录制的或 Claude 生成的 持久化状态和传输格式在当前版本与目标版本之间可往返转换 变更在预发布环境中运行约定的一段时间，错误率、延迟或告警均无回归 静态分析和安全扫描未发现新的问题 对于编译型目标，构建干净且类型检查通过 与将负责审查和推动变更进入生产环境的人员共同编写证书。在证书和智能体工作流仍在设计阶段时，就引入当前依赖该代码库的开发者、用户群体和业务负责人。 他们的专业判断塑造了证书所衡量的内容，而他们的早期参与正是当变更进入评审阶段时赢得他们认可的原因。对最终证书的一个良好检验是：他们是否愿意仅凭证书中的证据就放心合并。如果他们从中看到了自己的标准，那么第 3 步中的推广策略就可以更宽松。 证书对照什么进行检查、以及如何检查，取决于现代化改造的类型。 对于提升式现代化改造，对标的是原始代码库，原始测试套件可以作为证书的核心。 对于转换式现代化改造，对标的同样是原始代码库，但原始测试套件很少能在新栈上运行。取而代之，生产流量回放、新旧系统之间的差分测试，以及生产环境并行部署承担了大部分工作。 对于重构式现代化改造，证书锚定在行为规格说明上。这是最困难的情况。规格说明不如现有系统那样客观、可供差分对比，因此涉及更大程度的模型判断，这可能导致结果更加多变。在这里，证书依赖于根据规格说明编写的测试、由 Claude 进行的独立对抗性审查（对照规格说明检查每一项变更），以及在新系统保留旧系统行为之处进行的差分检查。要预期随着规格说明的澄清而修订证书：规格说明中的缺口会首先在这里暴露出来。 旧系统往往测试覆盖率低、测试不稳定，且几乎没有遥测数据。定义证书的一部分工作就是识别这些缺口。如果支撑一份强有力的证书会很困难，那么在这一步最有用的做法之一，就是用 Claude 来构建缺失的证据，无论是搭建一个与生产环境平行的环境、构建回放测试框架，还是编写更多测试。 第 3 步：设定晋升策略 智能体产生变更的速度，远超任何人类团队逐条 diff 审查的速度。晋升策略是一条分级审查路径——提前书面写明并达成一致——它规定了针对某项变更的人工审查深度，从而让现代化工作能在可接受的时间线内完成。 与证书一样，这一步要与审查人员共同推进，并尽可能将其融入你组织现有的变更管理流程。具体细节会因组织和其所面临的风险权衡而异，但有几条规则放之四海而皆准： 按影响范围和智能体置信度对变更分级。如果你的组织已有自己的变更或风险分类，就沿用它的。对关键路径保留完整的人工审查。 从源头修复反复出现的标记。对随时间推移被标记的变更进行分组和分析。当同类型的标记反复出现时，应在智能体工作流或证书中修复其根因，而不是逐一审查每一条。 与评审人员共同设计输出格式。就哪些信息和格式能让评审最快完成达成一致，以及哪些信号比其他信号更能带来信心。让他们在第 5 步中评审早期样本输出。 高效分配 SME 时间。SME 不会阅读每一份最终 diff，但他们的判断仍然是稀缺的输入。让他们能够直接跳到最高风险层级中的变更，以及每个层级中被标记的智能体决策，而无需费力翻阅大量 diff。这样，少量专家工时就能覆盖风险最高的那些变更。 这些规则中有许多通过在项目早期就让 SME 参与，将他们的工时前置投入。他们的反馈会在全面现代化开始之前，就校准证书和智能体工作流。 他们对样本的签字确认，也会成为在信心较高之处采用更轻量评审路径的进一步依据。这与传统的非智能体模式正好相反——在那种模式下，评审发生在最后。 一项变更从生成到上线的路径。 晋升策略还应反映该现代化项目在速度与评审深度之间所处的位置。一个正在赶硬性截止日期的现代化项目——例如某个运行时即将失去支持——需要更快的策略，采用更轻量的人工评审，并明确同意每项变更承担更多风险。 在更长的时间线上进行现代化改造，可以承担更深入的人工审查和更缓慢的切换。利益相关方会根据自身的风险偏好和约束条件，落在这一光谱的不同位置上，因此值得在工作开始之前就将其确定下来。 在受监管的环境中，对任何变更采取较轻量的人工审查路径都可能引发切实的不安。个别审批人会犹豫是否签字批准，因为他们承担着不良变更的风险，而管理层则承担着系统老化的更大风险。 根据我们的经验，最好让晋升策略的指令来自组织最高层。最好也事先就此达成一致，这样进入生产环境的 bug 的责任就是共同承担的，而不是被归咎于批准该变更的人。 所有这些仍然取决于一份足够详细的证书，使其能够作为真正的证据，也取决于审查者是否足够理解 Claude 是如何得出某项变更的，从而能够信任它。 第 4 步：将前置条件落实到位 这一步的许多工作要经由现代化改造之外的团队来推进：主机所需的平台或基础设施团队、负责测试容量的 QA 或发布工程团队、负责审批的安全与合规团队。这些团队通常各自都有自己的待办事项或审批流程，所以要尽早开启沟通——一旦你明确了需求就马上开始，往往在第 1 步到第 3 步还在进行时就要着手。 环境 一台专用的远程主机，用于运行该工作流，并让 Claude 能够访问代码库及其他相关来源 按证书要求测试容量 任何能强化证书的东西：生产遥测数据、与生产并行的环境，或用于回放的生产数据 代码库与 CI/CD 一份代码库的依赖关系图，以构建和编译日志、导入分析或运行时追踪为依据。注意：该插件的 map 命令是一个不错的起点，但取决于代码库的规模和年代，可能需要做更多的前期工作 作为目标定义的一部分，对任何依赖项或软件包的既定处理方式 如有需要，一个可随时加入 CI/CD 的兼容性检查 如果你是在原地进行现代化改造，一份商定好的代码冻结策略 一份面向在职开发者的沟通计划，涵盖任何代码冻结和新的兼容性要求 团队与评审 依赖该代码库的其他团队就他们如何参与达成一致，例如签署证书或在晋升政策下进行审查，并预留审查者时间 安全与合规 为 Claude Code 批准一条用于源代码的模型访问路径 为智能体工作流实施最小权限访问：仅可写入现代化分支，且无生产环境凭证 从现代化分支中清除或掩蔽密钥和 PII 每项变更均可追溯，且 PR 关联到智能体记录和证书证据 对新依赖项进行许可证和漏洞检查 第 5 步：构建并完善智能体工作流 使用 Claude Code 开发一套定制化的动态工作流，用于对代码库进行现代化改造。 我们建议从代码现代化插件开始，并把工作流可能需要的一切都放到文件系统上或通过 MCP 提供，让 Claude 能够访问。这包括目标、证书、晋升策略、代码库、文档，以及证书所需的任何数据源或工具。你也可以把本文作为上下文提供给 Claude。这就构成了该项目的核心知识库。 有了这些基础，构建现代化工作流就是容易的部分了。让领域专家（SME）按需审查 Claude 的工作，包括任何针对特定代码库的技能或提取出的规则，然后再让下游环节依赖它们。 通过将其应用于代码库的一小部分来完善你所构建的内容，由领域专家审查它产生的变更、智能体的流程，以及证书已满足的证据。 当问题浮现时，你应该修改工作流，而不是修改每一处变更。目标是确信：一旦规模化，变更几乎在所有地方都能满足证书要求，审查者也会愿意按照晋升策略进行合并。 第 6 步：运行现代化 首先，在代码库的一小部分上端到端地完成现代化，包括通过晋升策略审查并落地这些变更。趁代价还低时修复任何不奏效的地方，重复这一过程直到你有信心，然后再扩展到整个代码库。 虽然“转换式”和“重新构想式”现代化都涉及在现有系统之外构建目标系统、待完成后一次性切换，但“提升式”现代化还有第二种选择：在开发持续进行的同时，直接在线上代码库上原地现代化。 当系统无法停机，或者代码库变化太快、难以为单独的现代化副本保持同步时，这通常是首选方案。在这种情况下，我们看到行之有效的做法是：从叶子节点向内将代码库拆分为逻辑分区；一次冻结并现代化一个分区；并对 CI/CD 设置门禁，使新提交无法在某个分区完成现代化后将其回退。 关于成本的一点说明 我们经常被问到，这样一次现代化改造会消耗多少 token。每次现代化改造的情况各不相同，但主要的成本驱动因素包括： 代码库中有多少部分需要阅读，而不是修改； 认证流程涉及的工作量有多大（在受监管环境中，验证通常比编写变更占据更大的比重）； 认证要求编写多少新测试以及修复多少测试；以及 在运行进行期间，其他团队在你周围合并代码会带来多少协调工作。 在对代码库的一小部分完成现代化改造时，测量 token 用量，并据此推算整个运行过程的消耗。将试点无法覆盖的任何内容——例如在实时代码库上进行的对账——视为未知项。这样你就能估算出完整现代化改造的成本下限。 试点的测量结果还能揭示在哪些环节可以针对成本优化你的智能体工作流。找出工作流中消耗 token 最多的部分，并思考如何让它们更高效。把计算密集型的验证信号移到更廉价的关卡之后，使其只在更简单的检查通过后才运行。 对于证书能够完整校验的机械性、大批量工作，考虑使用 Sonnet 这类兼顾成本与能力的模型。将更智能的模型留给困难的转换以及验证正确性的对抗性审查。 当较便宜的模型无法满足证书要求时，你也可以升级到更昂贵的模型，但在试点期间要仔细分析重试率，因为多次廉价尝试的成本可能超过一次昂贵尝试。如果你让 Claude 同时访问工作流和试点数据，它就能与你一起完成其中大部分分析。 超越现代化改造 现代化改造后的代码库只是其中一项产出。其他产出还包括：生成它的工作流、一份写明何为正确的书面证书、一套你的变更管理流程已经接受的晋升策略，以及每一次落地变更的证据链。把这套操作手册固化为可复用的资产，这样在下一次升级或重写时，这套模式就已经就位。 我们的前沿部署工程师会与客户一起，针对其最关键的系统逐步推进这些步骤。如果你正在筹备现代化改造，请联系我们的团队。 更多资源 Claude Code 的公开 codemod 插件 AI 原生 SDLC 实战手册 代码现代化实战手册 用 AI 实现 COBOL 现代化：打破成本壁垒 视频 · 前往原文观看