给大家讲讲看这个https://claude.com/blog/how-to-prepare-for-ai-driven-code-modernization-projects

Joye，这篇值得看的地方，不是“Claude 能把老系统重写得多快”，而是：当 Agent 写代码的速度上来以后，组织有没有能力验证、审核并上线这些改动？ 它讨论的是旧系统现代化：升级过时技术栈、跨语言迁移，或者重新设计老系统。尤其针对银行等不能随便出错、需要严格审计的场景。 整篇文章的主线可以概括成一句话： 不要先让 Agent 批量改代码，再想怎么验收；先把“改成什么、怎么证明改对了、谁允许它上线”设计好。 一、先统一目标：你到底是在升级，还是重新发明业务？ 文章区分了三种项目。 第一种，同一技术栈升级，比如 C++11 升到 C++20。主要改变版本和依赖，原有业务行为尽量不变。 第二种，跨技术栈迁移，比如 COBOL 改成 Java。实现可以换，但业务行为要保持一致。 第三种，重新设计。架构换了，业务行为也要调整。这就必须先有明确的新需求规格，不能只拿旧系统当答案。 这个区分看起来普通，实际非常关键。 举个假设：迁移一个计费系统，Agent 发现旧代码的金额舍入方式“不够合理”，顺手改得更优雅了。 如果目标是保持行为不变，这可能就是严重错误；如果目标包含修改计费规则，它才可能是正确实现。 所以，“代码变好了”不等于“迁移做对了”。目标不统一，后面每个 PR 都可能变成需求争论。 文章也提醒：Agent 可以从代码里梳理依赖、提取业务规则，但不能假设读完代码就理解了全部业务。业务人员的经验、文档和实际运行情况仍然要补进来。 二、最重要的概念：给每次改动定义一套“验收凭据” 原文叫 certificate。 这里不是数字证书，也不是 Agent 写一句“我检查过了”，而是一组事先约定、能被执行和检查的验收条件。 仍以刚才的计费系统为例，可以要求： 同一批经过脱敏的输入，旧系统和新系统算出的账单一致。 历史边界情况能通过，比如跨月、退款、金额舍入。 新旧版本能够正确读取约定的数据格式。 性能没有超出允许的退化范围，安全扫描没有新增问题。 这些条件共同构成“为什么可以相信这次修改”的证据。 不同迁移类型，证据来源也不一样。 同栈升级，原来的测试通常还能继续用。 跨语言迁移，原来的测试未必能直接运行，更需要回放输入、比较新旧输出，或者让新系统并行运行但暂不接管真实业务。 重新设计，因为行为本来就要变，不能要求全部输出与旧系统一致，只能更多依赖新规格及其对应测试。这也是最难验证的一类。 文章还提到，让另一个全新上下文里的 Claude 做对抗性审查。 但这里要注意：换一个上下文，不等于获得了绝对独立、绝不会重复犯错的审查者。模型审查是补充证据，不能替代业务事实和可执行测试。 三、验证通过和允许上线，是两件事 文章把后者叫 promotion policy，可以理解为“改动进入生产环境的放行规则”。 为什么要单独设计？ 因为 Agent 一天能产生很多改动，不代表人类一天能认真看完同样数量的 diff。如果仍要求所有改动都由专家逐行审核，写代码变快了，整体交付却不一定变快。 它建议按风险分层。 影响范围小、验证证据充分的改动，可以采用事先批准的较轻审核流程。 涉及核心业务、关键数据或大范围影响的改动，仍然保留完整人工审查。 自动验证失败、证据不足、存在争议的改动，则转交人处理。 重点不是“让 AI 免审”，而是让有限的专家时间集中在真正高风险的地方。 而且，验收条件必须和审核者一起制定。不能开发团队自己造一套检查，最后要求业务、安全和发布团队无条件相信。 四、多 Agent 在这里怎么干活？ 文章不是建议“拉十个 Agent，一起重写整个仓库”。 它提出的是围绕目标、验收条件和放行规则，搭建适配这个代码库的工作流，再拆成多个较小的子 Agent 工作流。 为了便于理解，可以把它想成这样一条流水线： 先理解依赖和业务规则，把任务切成边界清楚的小块。 子 Agent 负责具体改动，完成后运行规定的检查。 检查失败就继续修复；无法满足要求或遇到不明确的业务决策，就标记出来交给人。 通过之后，提交的不只是代码，还包括验证结果和可追溯的执行记录，再进入对应的审核流程。 这是对文章思路的示意，不是原文给出的一套固定 Agent 角色配置。 这里并行的是可以拆开的工作，不是取消依赖关系。两个模块存在接口约束，就不能各改各的，最后祈祷能够拼起来。 文章对“原地升级、同时保持日常开发”的场景，还给了更具体的办法：沿依赖关系从叶子模块向内推进，每次冻结和升级一个分区，再用 CI 防止后续提交重新引入旧的不兼容写法。 五、真正该反复修的，是工作流，而不只是某一次输出 这是我觉得文章里很有价值的一点。 假如连续十个迁移任务都漏掉同一类兼容性问题，你当然可以人工把十个 PR 分别改好。 但这只修复了十份结果，没有解决第十一次还会出错的问题。 更有效的做法是追查： 是不是业务规则没提供完整？ 是不是任务拆分漏掉了依赖？ 是不是验收条件根本没有检查这类错误？ 然后修正工作流、上下文或者检查机制，让后续任务能够自动避免或发现同样的问题。 所以，小范围试跑的目的不只是展示“Agent 成功改了一块代码”，而是验证整条链路能不能跑通： 生成改动、验证、人工审核、合入，以及按约定的发布流程落地。 只跑通代码生成，不算跑通现代化项目。 六、成本和安全，不能等最后再补 文章强调，Agent 应当使用最小权限：只写迁移分支，不给生产凭据；敏感信息要脱敏；每个 PR 要能追溯到执行过程和验收证据。 成本上，它也没有给一个“每百万行代码多少钱”的万能报价。 需要读取多少代码、验证有多复杂、要补多少测试，以及日常开发不断合入带来的协调工作，都会影响成本。 尤其在严格受控的环境里，文章指出，验证往往比写改动消耗更多。 因此要用小规模试跑估算，但把试跑没覆盖到的成本保留为未知项，不能把局部数字直接包装成完整预算。 它还有两个很实际的建议：先跑便宜的检查，通过后再跑昂贵验证；别只看单次模型调用便宜不便宜，多次失败重试可能比一次较贵但成功的调用更费钱。 我的看法 这是一篇 Anthropic 交付团队的实践指南，不是证明所有旧系统都能“几年变几周”的普遍实验结论。 真正值得带走的，是它对工程瓶颈的判断： 以前稀缺的是写出改动的能力；当 Agent 提高了产出速度，稀缺的就可能变成定义正确、提供证据和承担发布责任的能力。 所以，成熟的 Agent 工程不是让模型不停地产出代码，而是让每份产出都有明确目标、有可信证据，并且有一条组织能够接受的落地路径。