本页目录10
- 现代化项目分三类：Uplift（同技术栈升级版本）、Transform（跨技术栈重写但行为不变）、Reimagine（行为也重新设计的全新构建），先明确目标类型再动手
- 先写「certificate」（可自动验证的通过条件，如测试覆盖率、性能基准、对抗性复审、输出对齐等），再让 Claude 按此标准自证改动是否合格
- 「promotion policy」决定人工评审的分级路径，应尽早让领域专家（SME）介入并根据变更影响范围/置信度设计轻重不同的评审通道，而不是把评审都堆到后期
- 落地前要准备好远程执行环境、测试基础设施、依赖与许可证核查、最小权限访问、PII/密钥清理、变更可追溯（关联 agent 会话记录）等前提条件
- 先用小范围代码分区跑通端到端流程并验证 workflow 本身，再逐步扩大规模；出问题优先修 workflow 而不是逐条改动
- 成本主要由代码读取/改动比例、certificate 验证复杂度、测试修复量决定；可用 Sonnet 处理机械性工作，把更强模型留给复杂改写和对抗性复审，并在开销大的验证前加便宜的预检查
本文是对官方文章「How to prepare for AI-driven code modernization projects」的中文要点摘要，完整内容以原文为准：https://claude.com/blog/how-to-prepare-for-ai-driven-code-modernization-projects
核心观点
用 Claude Code 做代码现代化改造，原本要数年的迁移项目可以压缩到数周或数月完成。但文章强调：技术产出变快了，组织层面的协调工作量并没有变少——真正的瓶颈从「怎么改代码」转移到了「怎么把团队、评审、合规流程组织起来接住这些改动」。文章给出一套六步框架来应对这个转移。
第一步：定义目标（Define the Target）
先明确「现代化」到底要达到什么终态技术栈和行为要求。文章把项目分成三类：
| 类型 | 说明 | 典型场景 |
|---|---|---|
| Uplift | 同一技术栈内升级版本 | 如 C++11 → C++20，运行时/版本过旧 |
| Transform | 跨技术栈重写，但行为保持不变 | 如 COBOL → Java |
| Reimagine | 从零重建，行为也需要调整 | 系统本身需要做行为层面的改变 |
实践建议：先梳理代码库、记录现有工作流，再通过代码分析结合干系人访谈写出「行为规格说明」。可以用**代码现代化插件（code modernization plugin）**的 assess、map、extract-rules 命令来挖掘业务规则。项目立项理由应重点强调「降低风险」，而非单纯的效率提升。
第二步：写「certificate」（验收标准）
Certificate 是一组可自动化验证、不需要人工介入的通过条件，可以来自：
- 原有测试套件全部通过
- 新增测试覆盖率达标
- 性能基准达标
- 让 Claude 在全新上下文中做「对抗性复审」
- 新旧版本输出一致性（parity）
- 状态/线上数据格式可来回转换（round-trip）
- 灰度/staging 期观察
- 静态分析、安全扫描
- 构建通过、类型检查通过
关键建议：这份 certificate 必须和未来负责评审、批准上线的人一起写，而不是技术团队闭门定义。
第三步：定「promotion policy」（晋级/评审策略）
根据变更的影响范围（blast radius）和 agent 的置信度，设计分级的人工评审路径，还要考虑：
- 对高频出现的问题标记做根因分析而非逐条修补
- 把输出格式优化成方便评审者阅读的样子
- 给高风险改动预留足够的领域专家（SME）时间
文章特别提醒：SME 的参与要前置，而不是留到项目后期才让专家来把关；一旦早期样本被验证可信，可以为高置信度的改动设计更轻量的评审通道。评审策略也要和项目周期匹配——工期紧就要接受更快、风险容忍度更高的策略；周期宽松则可以做更深入的评审。
第四步：前提条件准备（Prerequisites）
分四个方面：
- 环境：专用的远程执行主机、能满足 certificate 要求的测试基础设施、生产环境遥测和并行部署方案
- 代码库/CI-CD：通过构建日志和 import 分析做依赖映射、制定依赖包处理方案、在 CI/CD 里加兼容性检查、如果是就地升级需要有代码冻结策略、以及对开发者的沟通计划
- 团队/评审：跨团队就参与方式和签字流程达成一致，预留评审时间
- 安全/合规：确认模型访问源码已获批、workflow 采用最小权限（只能写入现代化专用分支）、清理分支中的 PII 和密钥、保证变更全程可追溯（关联到 agent 的会话记录）、对依赖做许可证和漏洞检查
第五步：搭建 agentic workflow
建议从代码现代化插件起步，把目标定义、certificate、promotion policy、代码库和数据源都放在 Claude 可访问的文件系统里；抽取出的业务规则要先经过 SME 复核才能用于下游。通过在小规模代码分区上反复试跑来打磨 workflow。文章给出一条原则：出问题时先改 workflow 本身，而不是逐个手动修补每一处改动。
第六步：正式运行现代化改造
先在一小段代码上跑通完整流程，通过 promotion policy 评审并落地，验证可行后再逐步扩大规模。如果是就地升级（in-place uplift），建议按叶子到根的顺序对代码库分区，每次只冻结一个分区，并在 CI/CD 中设置门禁防止回退。确认试点效果后再推广到全代码库。
成本怎么算
主要成本驱动因素：
- 代码「读取量」与「实际改动量」的比例
- certificate 验证本身的复杂度
- 测试编写和修复的工作量
- 与并行进行的开发工作做协调、合并的成本
优化思路：
- 先在试点阶段测量 token 用量，再按比例推算全量运行成本，把意外出现的工作量当作未知风险单独对待
- 找出 workflow 中消耗 token 最多的环节
- 在开销大的验证步骤前面加一层便宜的预检查作为门槛
- 机械性、可完全自动验证的工作交给 Sonnet 这类更经济的模型
- 把更强的模型留给复杂改写和对抗性复审这类高价值场景
- 监控重试率，比较「多次便宜尝试」和「一次昂贵尝试」哪种更划算
配套资源
文章提到了几个可以配合使用的资源：代码现代化插件（含 assess、map、extract-rules 等命令，托管在公开的 GitHub 插件仓库）、代码现代化 playbook 和针对 COBOL 迁移的专门指南，以及 AI-Native SDLC playbook。
项目之外：沉淀可复用资产
文章最后建议，项目结束后应该把这次积累的 workflow、写好的 certificate、被各方接受的 promotion policy，以及全过程的证据链都沉淀下来，作为组织后续再做类似现代化项目时可复用的能力资产，而不是一次性用完就丢。