如果你从零开始做一个 AI 项目，你可以自由选择技术栈、定义接口契约、设计数据模型。AI 在这个场景里如鱼得水——它擅长在干净的上下文里生成符合规范的代码。
存量项目几乎完全相反。你面对的是一个运行了五年、十年甚至二十年的系统，它没有测试，没有文档，或者有文档但已经和代码严重脱节。它的每一个看似古怪的设计背后，都可能有一个没人记得的生产事故。你不能重写它，因为它承载着正在发生的业务；你也不能不动它，因为它正在成为组织的技术负债。
一个常被引用的数据是：生成式 AI 在绿地项目中带来 30-40% 的生产力提升，但在低复杂度存量系统中降至 15-20%，在高复杂度企业代码库中暴跌至 0-10%。这意味着，你从新建 AI 项目中学到的经验，搬到存量项目上可能完全不成立。
这不是 AI 能力的问题，而是存量系统的本质决定的。
第一，LLM 缺乏领域上下文。
LLM 能识别语法和模式，但它无法理解业务域中的限界上下文。它不知道“这个字段在金融场景下代表本金”还是“在电商场景下代表库存数量”。它也无法推断“对这家企业来说什么才是正确的服务拆分”——因为正确的拆分方式取决于组织结构、团队边界和业务演进方向，这些都不在代码里。
第二，AI 没有运行时感知。
代码助手只“看”静态代码。它看不到这个系统在运行时实际发生了什么——哪些流程在生产中真正被执行、耦合发生在哪里、哪些异常路径实际上每天都在触发。一个静态看起来合理的重构，可能在运行时破坏一条从未被文档化的关键路径。
第三，Token 限制造成“全局视野”碎片化。
即使是强大的代码助手，也无法在上下文中保持百万行级单体系统的完整视图。当它只看到代码库的一个窄片时，它会在更广泛的复杂依赖中产生幻觉或猜测。它不是不够聪明，而是不知道“这个模块的调用方在三个服务之外，且那个调用方有一个隐藏的参数假设”。
这三个根因决定了存量迁移的核心策略：不要试图让 AI 一次性理解整个系统，而是通过诊断、基线、试点、双轨的渐进方式，把系统拆解为 AI 可以安全接管的可控单元。
很多团队在启动迁移时，第一反应是“把旧代码丢给 AI，让它翻译成新代码”。Gartner 的预测给这种做法泼了一盆冷水：超过 70% 在 2026 年启动的大型机退出项目，将因高估生成式 AI 能力而无法实现预期收益。AI 在识别技术债务、整理和补全文档方面有价值，但并不适合将遗留代码自动转换到现代化平台。
正确的路径是四阶段渐进：
诊断：先判断“值不值得迁”和“哪个模块先迁”。诊断的第一步不是评估“怎么迁”，而是判断“值不值得迁”。适用性筛选、架构距离评估、AI 适配度评分，都是诊断阶段的产出。
试点：用评分模型选出 1-3 个模块，在 2-4 周的时间窗内建立最小闭环。试点不是演示，而是验证“AI 在这个模块上能否达到可接受的行为对等”。
双轨：新链路在 Shadow Mode 下与旧系统并行运行，通过流量切分和灰度验证逐步接管。双轨的核心原则是“不赌一把切换”。
推广：把试点验证过的 Harness 配置、提示库、质量门禁和度量体系标准化，从单团队扩展到多团队。
这四个阶段不是线性的。诊断的结论可能推翻试点的假设，双轨的数据可能暴露基线的盲区。但整体方向是明确的：每一步都建立在可验证的证据之上，而不是建立在“AI 应该能做到”的乐观预期之上。
四阶段背后的核心架构模式是 Strangler Fig（绞杀者模式）。它在客户端和旧系统之间引入一个路由层，由路由层决定每个请求走旧链路还是新链路。随着新链路逐步验证，旧链路的流量占比持续下降，最终被“绞杀”下线。
这个模式的价值在于：每次迁移一个可控的功能边界，风险最小化。 它不要求一次性重写全部系统，也不要求在迁移期间停止业务。它允许团队在每一步都保留回退能力。
但 Strangler Fig 也有它的陷阱。行业数据显示，Strangler Fig 的成功率是 76%，显著高于 Big Bang 重写的 50%，然而 68% 的项目在前 90 天内停滞——最常见的原因是团队把注意力转移到别处后，永久地运行着两套系统。前 90 天内提取的功能不足 5% 的项目，失败率高达 92%。这意味着双轨并行最大的风险不是技术问题，而是停在半路上。
这个风险会在第 5 章和第 7 章被反复讨论。
本文提到的 Harness、质量门禁、提示库版本化管理等概念，在第三篇中有更完整的方法论阐述。本文的重点不是重新解释这些概念，而是说明它们如何在存量迁移场景中被应用。
一个简化的定义：
如果你还没有读过第三篇，建议在阅读第 8 章之前先了解这些概念的基础定义。但即使没有读过，本文的每一章都会在需要时给出足够的上下文。
这篇文章面向技术负责人、架构师和迁移团队的实践者。它不解释 AI 的基础词汇，不讨论“什么是 LLM”或“什么是 prompt”。它假设你已经了解这些，关心的是“怎么在真实的老系统上安全地接入 AI”。
阅读建议：
无论从哪一章开始，核心原则是一致的：用证据代替直觉，用数据代替感觉，用渐进代替赌注。
大多数团队在启动迁移时，直接跳到“怎么迁”的问题：选什么工具、用什么模型、怎么配置 Harness。但在存量迁移场景中，更重要的前置问题是：这个模块值不值得迁？
不是所有存量系统都适合 AI 工程化迁移。有些模块的业务规则太复杂，基线 Spec 建了三个月还没覆盖核心路径；有些模块的数据只有一位老员工知道怎么导出；有些模块的业务规则每周都在变，AI 生成的代码还没合并就已经过时了。
诊断阶段的任务，是回答两个问题：
第一个问题用三问筛选解决，第二个问题用 AI 适配度评分解决。
在进入任何深度评估之前，先用三个问题做快速筛选。任何一问不通过，不进入 AI 适配度评分，直接列为前置改造任务。
第一问：能不能在模块外围加代理，拦截并路由调用？
这是 Strangler Fig 模式的前提。如果模块是一个黑盒，跑在一个没人敢碰的中间件里，连请求进去出来是什么样都说不清楚，那连“基线 Spec”都建不起来，迁移无从谈起。
一个实用的判断信号：你能不能在目标模块前面放一个代理，把流量路由到旧系统或新链路？ 如果不能，说明模块边界不清，先做边界梳理或 Branch by Abstraction。
第二问：能不能录制完整请求/响应，并支持回放对比？
AI 要接管的模块，必须能被观测到实际行为——能加日志、能抓请求/响应、能跑特征测试。如果系统是个黑盒，连请求进去出来是什么样都说不清楚，那连“基线 Spec”都建不起来。
判断信号：能不能在不改代码的情况下，对目标模块做一次完整的请求录制和回放？ 如果不能，先做可观测性改造，再考虑 AI 接入。
第三问：有没有人能判断 AI 产出的业务正确性？
AI 生成代码后，需要有人能做业务正确性审查——不是看代码风格，而是判断“这个逻辑是否和旧系统一致”。如果团队里已经没有人真正理解目标模块的业务规则，审查就退化成橡皮图章。
一个自检问题：如果 AI 生成的模块上线后产生了细微的业务偏差，团队里有没有人能在一周内定位到是哪个规则错了？ 如果有，团队基础具备。如果没有，先做知识捕获和文档化。
三问全部通过，才进入深度评估和 AI 适配度评分。任何一个不通过，都不是“放弃”，而是明确了前置改造任务——这本身就是一个有价值的诊断产出。
以下是完整的筛选流程，可以作为诊断阶段的执行工具：
图 2-1 存量模块 AI 迁移适用性筛选流程
蓝色为起点，绿色为通过，黄色为可转化为前置改造任务，红色为暂缓或换模块。
三问通过后，进入深度评估。四个维度决定模块是否具备迁移条件：
业务规则稳定性。 业务规则近 6 个月的变化频率。如果规则还在频繁变化，基线 Spec 会迅速过时，AI 生成的代码会不断被业务需求推翻，返工率会失控。适合迁移的是那些业务规则已经冻结、但技术实现陈旧的模块。
数据可得性。 目标模块的输入/输出数据是否有明确的 schema（哪怕是隐式的），关键业务数据是否可程序化读取（数据库、API、消息队列均可，但不能是“只有某个人知道怎么导出的 Excel”）。是否存在大量隐性业务规则散落在代码注释、操作手册、某位资深员工的记忆里——这是存量迁移特有的风险。
灰度与回退能力。 是否有灰度发布能力？回退成本是否可控？如果模块的数据写入是不可逆的（比如已经扣了款、发了货、改了核心状态），回退就不只是“切回旧代码”，还涉及脏数据补偿。这类模块适合先做 Shadow Mode。
合规与审计要求。 如果涉及金融、医疗等行业，需要评估现有系统是否满足 AI 辅助决策的审计追溯要求。例如 EU AI Act 第 12 条要求高风险 AI 系统在生命周期内自动记录事件日志。现有系统如果未在查询级别做日志，追溯改造可能需要 4-6 个月的工程工作量。
深度评估通过后，用评分模型对候选模块进行排序。以下评分表适合存量迁移场景，权重设计偏向技术可行性和数据可得性，因为这两项的失败会直接导致试点无法启动。
| 维度 | 权重 | 评分要点 | 0-3 分锚定 |
|---|---|---|---|
| 技术可行性 | 2.0 | 模块边界清晰度、可观测性、加代理的难度 | 0=黑盒不可观测；1=可观测但边界模糊；2=边界清晰但需少量改造；3=可直接加代理路由 |
| 业务规则稳定性 | 1.5 | 业务规则近 6 个月的变化频率 | 0=每周变更；1=每月变更；2=季度级稳定；3=半年以上未变 |
| 数据可得性 | 1.5 | 输入/输出数据的可程序化读取程度、schema 清晰度 | 0=只有人肉导出；1=部分可读但 schema 混乱；2=可程序化读取，schema 基本清晰；3=完整 schema 文档 |
| 验证可行性 | 1.5 | 特征测试/Golden Master 的建立成本 | 0=无法捕获行为；1=能捕获但覆盖不全；2=可建核心路径基线；3=已有测试或可低成本补全 |
| 风险可控性 | 1.0 | 出问题时的回退成本和影响范围 | 0=数据写入不可逆；1=可回退但有脏数据风险；2=可回退，影响可控；3=Shadow Mode 即可验证 |
| 团队审查能力 | 1.0 | 是否有人能判断业务正确性 | 0=无人理解业务规则；1=有人了解但未文档化；2=有明确审查者；3=有审查者+文档化规则 |
| 短期可度量性 | 0.5 | 2-4 周内能否产生可比较的成功信号 | 0=无清晰指标；1=有指标但需 6 周以上；2=2-4 周可见趋势；3=2 周内可测 |
总分计算：各维度得分（0-3 分）乘以权重后相加，满分约 27 分。建议 20 分以上进入试点候选，16-20 分列为备选（需先补前置改造），16 分以下暂不进入本轮试点。
这个评分的价值不在于精确排名，而在于把“为什么不选它”变成可讨论的论据。当团队争论“为什么先做 A 而不是 B”时，评分表能指出：B 在数据可得性上得分 0，因为它的核心数据只有一位老员工知道怎么从绿屏终端导出——这不是判断问题，是事实。
在诊断阶段，还有一个容易被忽略但极其重要的维度：知识流失风险。
如果维护关键遗留系统的核心人员离职，恢复需要多长时间？这个指标直接影响迁移的紧迫度优先级。一个模块如果只有一个人能维护，且这个人已经接近退休，那么它的迁移优先级应该被显著提高——即使它的 AI 适配度评分不是最高的。
知识流失风险的评估维度包括：
知识流失风险高的模块，即使迁移难度大，也应该被优先考虑。因为不迁移的风险可能比迁移的风险更大。
诊断阶段结束时，应该产出以下交付物：
诊断不是一次性的活动。随着试点的推进，诊断的结论会被不断修正。但它的核心价值是：在投入工程资源之前，先用系统化的方式排除那些“看起来适合但实际不适合”的候选模块。 这个排除过程本身就是在降低迁移失败的概率。
新建项目的逻辑是：先有需求，再写代码，测试验证代码是否符合需求。三者之间有一条清晰的因果链。
存量项目几乎完全相反。大多数运行了十年以上的系统，没有单元测试，也没有一份能对得上的规格文档。它们不是在实现某个规格，而是在几十年的生产补丁、监管变更和紧急修复中“生长”出来的。每一处看似古怪的写法、每一个没人解释得通的边界处理，都可能在支撑着下游某个看不见的流程。
一个迁移脚本可以在一个下午把 PERFORM 循环转成 for 循环，但它无法告诉你为什么这个循环在某个账户标记被设置时会跳过每第三条记录——因为这条规则从未被写下来，只存在于那段循环本身。
这就是基线 Spec 要解决的根本问题：AI 需要一份关于“旧系统实际行为”的契约，而不是关于“旧系统应该做什么”的猜测。 如果基线本身建立在猜测之上，AI 的每一次生成都在放大这个猜测的误差。
特征测试这个概念来自 Michael Feathers 的《修改代码的艺术》。它的核心原则是：不检查代码是否做了它应该做的事，而是记录代码实际上做了什么事。 从测试的角度看，现有行为就是需求，直到有证据证明它不是。
这与传统测试的思维完全不同。传统测试的失败意味着“代码有 bug”。特征测试的失败意味着“代码的行为变了”——无论变好还是变坏，都是需要人类判断的信号。
具体落地时，优先关注三类“高风险行为”：
边界条件。 空输入、最大值、最小值、类型边界、null 处理。这些是 AI 生成代码最容易“顺手优化”掉的地方，也是旧系统里最可能藏着隐性业务规则的地方。一个智能体可以根据 BSG（行为规范图）约束自动生成边界测试用例，比如“当账户标记为 X 时，跳过每第三条记录”这类规则，测试会直接断言这个行为。
异常路径。 错误码的返回逻辑、异常被吞掉还是被抛出、降级策略是什么。旧系统里常见的模式是“这个异常其实是一个业务信号”，AI 如果不了解这层含义，会把它当成普通错误处理。
隐性副作用。 旧系统经常在做“看起来是查询”的操作时悄悄写了日志、发了消息、更新了缓存。这些副作用在重构时极容易被遗漏，导致上线后下游系统收不到通知，但核心流程的测试全部通过。
特征测试不需要覆盖全部代码。正确的策略是围绕关键流程建立基线，而不是追求覆盖率指标。从一个核心业务入口开始，录制完整的请求/响应，让它成为第一道安全网。
特征测试的工程化落地，最直接的方式是 Golden Master 模式（也叫批准测试或快照测试）。
它的机制非常朴素：
这个过程有一个容易被忽视但至关重要的细节：对于非确定性字段，忽略值但保留格式断言。
时间戳、UUID、自增 ID 这些字段的值本身会变化，不能直接做逐字节对比。但如果简单地忽略整个字段，风险在于——比如序列化器悄悄把 ISO-8601 时间戳变成了 Unix epoch，而没有人注意到。正确做法是断言格式不变，忽略具体值。
黄金文件的存储和组织方式也需要工程化设计。建议按业务流路径组织目录结构，每个黄金文件附带一个元数据文件，记录：
这样当后续出现差异时，工程师能快速判断：是 AI 生成代码引入了偏差，还是旧系统本身在两次捕获之间发生了合法变更。
黄金文件捕获的是行为，但 AI 迁移真正需要的是意图。两者的区别在于：行为快照告诉你“输入 X 得到输出 Y”，但不告诉你“为什么是 Y”。
这一步是基线 Spec 中最难、也最有价值的部分。行业实践中有一个方向值得借鉴：从生成的测试中提炼出显式的业务规则，将“行为测试”转化为“意图测试”。一旦可靠的 Golden Master 测试建立起来，AI 在迁移项目中的角色就会发生根本变化——从“猜测意图的生成器”变成“在已知约束内做转换的执行器”。
一个更结构化的做法是反向文档工程。Reversa 框架提出的多智能体流水线是一个有价值的参考：专门化的智能体分别负责项目表面映射、模块分析、隐性规则提取、架构综合、单元级规格撰写和生成声明审查。在 COBOL 到 Go 的 ATM 迁移案例中，这个流水线产出了 517 条按内部置信度分类的声明、10 个注册的缺口和 53 个 Gherkin 对等场景。
其中最关键的设计是显式置信度标记和缺口保留。不是所有规则都能被自动提取，有些需要人类验证。框架不假装自己知道一切，而是明确标注“这条规则的置信度是低，需要人工确认”。这恰恰是 AI 工程化迁移中应该有的态度：不确定性必须被暴露，而不是被掩盖。
一个常见的诱惑是：既然有 API 文档、设计文档、需求文档，为什么不直接拿它们做基线？
因为存量系统的文档几乎必然与代码脱节。漂移的表现形式包括：
200，实际代码在某个分支返回 204；如果 AI 基于过时文档生成代码，它不是在迁移，而是在用文档的幻想覆盖代码的现实。结果就是上线后行为不一致，而测试如果只验证了文档描述的行为，根本发现不了问题。
正确顺序是：先捕获行为，再对照文档。 如果行为与文档不一致，以行为为准，同时把差异记录下来作为“待人类确认的规则”。人类确认后，文档被修正，或者行为被标记为“历史遗留但必须保留”。
基线 Spec 一旦建立，需要明确的冻结规则：
“解冻”的条件是：迁移完成，新链路通过全部对等验证，旧系统可以下线。此时基线 Spec 完成使命，归档为历史参考。
基线 Spec 不是一份静态文档，它是双轨并行的比较基准。
Shadow Mode 阶段（第 5 章会详细展开）的核心工作，就是把旧系统的输出和新链路的输出与基线进行三方对比：
如果 Shadow Mode 发现偏差，第一件事不是改新代码，而是回查基线：是基线漏掉了这个行为，还是 AI 确实引入了偏差？这个回查动作本身就在持续完善基线 Spec，让它从一个“初始快照”演化为一个“活的行为契约”。
第 2 章的筛选解决的是“哪些模块不能做”，第 3 章的基线 Spec 解决的是“拿什么标准去做”。但即使所有前置条件都满足，仍然有一个更隐蔽的问题：在多个合格候选中，先做哪一个？
这个问题的代价被严重低估。MIT 的调查显示，AI 试点项目从试点到生产的转化率仅约 14%。失败的原因很少是技术本身不行，更多是选了一个“看起来适合 AI 但实际上不适合第一个做”的模块——要么业务太关键，出一丁点偏差就触发紧急回退；要么业务规则太复杂，基线 Spec 建了三个月还没覆盖核心路径；要么没有清晰的成功信号，做了六周没人能判断“这算不算成功”。
Anthropic 在启动 AI 工具推广时的经验值得借鉴：先用一小批已经在使用 AI 工具的超用户作为试点组，验证技术与自有代码库的兼容性、识别有用的工作流、积累内部专家经验。这个策略的隐含前提是：先选人，再选模块。已经有 AI 使用意愿的团队，会比“被要求使用 AI”的团队产生更真实的反馈信号。
选试点模块不能靠“我觉得这个应该可以”。需要一套带权重的评分模型，让候选模块的排序可比较、可复查、可被团队共识验证。
参考 SPARK* 评分模型的思路，它用 7 个维度、0-10 分制、加权求和，总分 65-70 分以上才进入 Go 决策。存量迁移场景需要在此基础上做调整——战略对齐和业务影响仍然重要，但技术可行性和数据可得性在存量场景中的权重应该更高，因为这两项的失败会直接导致试点无法启动。
以下是一个适合存量迁移的试点模块评分表：
| 维度 | 权重 | 评分要点 | 0-3 分锚定 |
|---|---|---|---|
| 技术可行性 | 2.0 | 模块边界清晰度、可观测性、加代理的难度 | 0=黑盒不可观测；1=可观测但边界模糊；2=边界清晰但需少量改造；3=可直接加代理路由 |
| 业务规则稳定性 | 1.5 | 业务规则近 6 个月的变化频率 | 0=每周变更；1=每月变更；2=季度级稳定；3=半年以上未变 |
| 数据可得性 | 1.5 | 输入/输出数据的可程序化读取程度、schema 清晰度 | 0=只有人肉导出；1=部分可读但 schema 混乱；2=可程序化读取，schema 基本清晰；3=完整 schema 文档 |
| 验证可行性 | 1.5 | 特征测试/Golden Master 的建立成本 | 0=无法捕获行为；1=能捕获但覆盖不全；2=可建核心路径基线；3=已有测试或可低成本补全 |
| 风险可控性 | 1.0 | 出问题时的回退成本和影响范围 | 0=数据写入不可逆；1=可回退但有脏数据风险；2=可回退，影响可控；3=Shadow Mode 即可验证 |
| 团队审查能力 | 1.0 | 是否有人能判断业务正确性 | 0=无人理解业务规则；1=有人了解但未文档化；2=有明确审查者；3=有审查者+文档化规则 |
| 短期可度量性 | 0.5 | 2-4 周内能否产生可比较的成功信号 | 0=无清晰指标；1=有指标但需 6 周以上；2=2-4 周可见趋势；3=2 周内可测 |
总分计算：各维度得分（0-3 分）乘以权重后相加，满分约 27 分。建议 20 分以上进入试点候选，16-20 分列为备选（需先补前置改造），16 分以下暂不进入本轮试点。
这个评分的价值不在于精确排名，而在于把“为什么不选它”变成可讨论的论据。当团队争论“为什么先做 A 而不是 B”时，评分表能指出：B 在数据可得性上得分 0，因为它的核心数据只有一位老员工知道怎么从绿屏终端导出——这不是判断问题，是事实。
评分确定了“做什么”，下一步是“怎么开始”。不同团队的节奏和风险偏好不同，启动方式也应该不同。
方式一：沙盒 Hackathon（适合探索期）
Blue Cypress 的做法是：把一群人从日常优先级中隔离出来，给集中时间，只给一个方向（比如“音频 AI”），不给具体产品需求。第一天的指令只有“去实验”。六天后，一个有早期职业的开发者用 ElevenLabs 的客户端工具构建了一个纯语音交互的电脑商店演示，领导层此前甚至不知道这个功能存在。
这种方式的优势是降低心理门槛。团队不会因为“要交付一个正式试点”而选择保守路径。风险是产出可能不可控——但试点阶段本来就不需要控制产出，需要的是发现“原来这个可以这样用”的信号。
方式二：只读试点（适合风险敏感团队）
如果团队对“AI 生成代码接入生产链路”有强烈顾虑，从只读试点开始。让 AI 链路接收真实或脱敏的输入，产生输出，但不写入任何生产系统，只与旧系统的输出做对比。Agentic 迁移的实践建议明确：优先采用边界清晰的独立服务或模块，通过只读试点、灰度、监控和回退减少对核心业务的影响。
只读试点的优势是零生产风险。劣势是它无法验证“AI 生成的代码在写入场景中是否安全”——但作为第一阶段，它足以回答“AI 对这个模块的行为理解是否准确”这个核心问题。
方式三：超用户驱动（适合已有 AI 使用基础的团队）
如果团队中已经有 5-10 人自发在使用 AI 编码工具，可以直接以他们为试点组。给他们一个明确的模块和 2-4 周的时间窗，要求保留无 AI 基线、AI 辅助版和独立复测三份样本。没有这三份样本，就无法判断工具带来的是能力、代做还是返工。
这种方式的最大优势是学习速度快。超用户已经在日常工作中形成了自己的 prompt 习惯和工作流，他们能更快暴露“哪些任务 AI 做得好、哪些做得差”，这些信号比从零开始的培训更真实。
无论选哪种启动方式，试点的范围必须被量化为一个可验证的最小闭环。模糊的“做一个模块试试”是试点失控的前兆。
一个可操作的最小闭环定义：
试点最常见的失败模式不是“做砸了”，而是不结束。团队看到了混合结果，没人写下来“什么算成功、什么算失败、什么时候必须决定”，于是试点无限期延长，订阅费翻倍，但采纳率仪表盘上仍然是零星登录。
在试点开始之前，就必须把退出标准写下来。参考 AI Pilot Exit Criteria 框架，退出标准必须回答四个问题：什么结果值得推广、什么结果必须停止、谁做决定、什么时候必须决定。
具体到存量迁移场景，三档退出标准的量化建议：
Go（进入双轨并行）
No-Go（停止并回退）
Conditional Extend（有条件延长）
这一档最容易失控，必须附加硬性约束。只允许在具名阻断因素存在时延长，例如“集成依赖的外部 API 延期了两周”或“样本量尚未达到统计有效阈值”。延长决定必须附带新的决策日期和不变的成功阈值——不能因为“感觉快好了”就降低标准。延长次数上限建议设为 1 次。
一个关键细节：退出标准必须发布在试点参与者能读到的地方。埋在采购 PDF 里的模糊标准不会约束任何人的行为。参与者在第一天就应该知道“kill date”是哪天。
试点结束时，最重要的产出不是“AI 做到了什么”，而是一套可以被下一个团队复用的证据链。
Agentic 迁移的实践建议把“移交与退出的可验证标准”定义为：交付团队应以“客户能够做什么”而非“已交付多少文档”判断是否可以退出。最低标准包括：团队能定位用例立项卡、风险/影响评估、工作流合约、Skill/Agent 资产、事实卡、Golden Set、回归/发布记录和证据索引。
具体到博客场景，试点毕业至少应留下：
没有失败记录的试点报告是不完整的。失败模式本身就是推广阶段最有价值的参考——下一个团队会知道“别在这个地方用 AI”。
双轨并行不是“旧系统和新系统各自跑各自的”，而是在客户端和旧系统之间引入一个路由层（facade/代理），由它决定每个请求走旧链路还是新链路。这就是 Strangler Fig 模式的核心机制：渐进式替换，而非一次性切换。
具体到工程实现，路由层可以用 Nginx、Spring Cloud Gateway、Traefik 等反向代理工具搭建。关键组件有三部分：路由切换器（判断请求走哪条链路）、请求判别器（根据 URI、Header、Token 或灰度规则分流）、流量镜像与灰度发布机制（部分用户先切过去验证）。
一个最简的路由配置示例：旧接口 /api/v1/orders 保持指向旧服务，新接口 /api/v2/orders 指向新服务。需要灰度时，在路由层增加 Header 判别——带有 Use-New: true 的请求走新链路，其余仍走旧链路。
但需要注意一个关键数据：Strangler Fig 的成功率是 76%，显著高于 Big Bang 重写的 50%，然而 68% 的项目在前 90 天内停滞，最常见的原因不是技术问题，而是团队把注意力转移到别处后，永久地运行着两套系统。更具体的统计显示，前 90 天内提取的 monolith 功能不足 5% 的项目，失败率高达 92%；而成功提取的项目中位年节省成本为 64 万美元。这意味着双轨并行最大的风险是“停在半路上”——本章后面会给出防止停滞的机制。
双轨并行的第一步不是切流量，而是让新链路在影子模式下运行。
Shadow Mode 的核心机制是：新链路接收与旧系统完全相同的输入，产生输出，但不对外提供结果、不写入生产系统。它最适合回答几个关键问题：真实输入是否比离线样本更脏？prompt/工具/检索在真实上下文中是否偏航？AI 的输出和人工结果差多远？成本和延迟在真实流量下是否可接受。
Shadow Mode 与离线回放的本质区别在于：它吃的是真实输入，但不直接制造副作用。离线用例集的天花板是“写用例的人能想到的问法”，而线上真实用户的问法是长尾的——错别字、口语化、多轮上下文、跨领域混合提问。退化恰恰最容易发生在两端和长尾。
Shadow Mode 最关键的设计是明确的对照对象。baseline 可以是人工结果，也可以是旧版本 agent 的输出。如果系统同时在跑多个候选版本，建议把实验路由信息也写进 shadow 记录：json
|
1 2 3 4 5 6 7 |
{ "shadowRunId": "shadow_123", "experimentId": "exp_runtime_v3", "routingKey": "team_a_region_cn", "baselineVersion": "human_v1", "candidateVersion": "agent_v3" } |
这样当差异被发现时，团队能快速定位是某个候选版本的问题，还是某个输入分组的问题。
Shadow Mode 最常见的事故来源是：表面上旁路运行，实际某个工具仍然真的写了数据库或发了 Webhook。
正确的实现方式不是“在业务代码里加一个 if”，而是统一通过执行上下文注入：typescript
|
1 2 3 4 5 |
interface ExecutionModeContext { mode: 'shadow' | 'live'; sideEffectsAllowed: boolean; outboxOnly: boolean; } |
执行上下文进入工具网关后，每个写工具都必须显式声明在 shadow 下的行为。写操作应支持：只读执行、模拟写入 outbox 记录、side effect blocked 标记。如果系统做不到这一点，那不叫 Shadow Mode，只是“带风险的假演练”。
只看最终答案是否相似太粗。更实用的做法是分层评估：
| 层级 | 检查内容 |
|---|---|
| 结构差异 | 是否符合 schema，字段是否齐全 |
| 决策差异 | 是否选了不同工具、不同 nextAction |
| 风险差异 | 是否少了人工确认、少了风险提示 |
| 业务差异 | 如果接管，可能导致什么后果 |
为了避免评估人员各自凭感觉打分，应提前定义差异 rubric，为每个维度分配权重。Shadow Mode 的重点不是追求“完全一样”，而是判断“不同是否可接受”。
Shadow 最大的浪费是团队每天看差异报表，却没有把高价值样本沉淀下来。建议至少单独标记以下四类样本：
这些样本会成为后续 Canary 阶段的回归测试集和提示优化的输入。
Shadow Mode 验证了“AI 的行为是否接近可接管状态”，但它不回答“业务到底会不会接受”。Canary 阶段才开始真正切换流量。
推荐的渐进节奏是：Shadow Mode（只读旁路）→ Canary 5%（早期检测）→ A/B 测试 50/50（统计验证）→ 全量切换 100%（确信部署）。
每一步都设指标门禁，在每步之后运行。如果门禁触发，rollout 在当前的 canary 份额暂停，取消 rollout 并反向运行。一个真实的案例是：Qwen2.5-7B 的 canary rollout 在 10% 流量时，门禁捕获到 P95 延迟回归了 137%，触发自动回滚。
Canary 阶段必须监控的指标包括：
其中 P95 延迟和错误率是最敏感的两个先行指标。一个值得注意的发现是：Canary 和 blue-green 部署中，聚合成功率会掩盖策略回归和恢复回归——在 61%-64% 的升级轮次中仍然放行了有问题的版本。这意味着除了聚合指标外，必须监控子群体指标，否则某些分组的退化会被整体成功率掩盖。
前面两节讲的是流量层面的双轨。但双轨并行真正的底层挑战在数据层：新旧系统必须同时读写一致的信息。
核心思路是“全量迁移 + 增量同步 + 双向回切”。三个关键技术能力环环相扣：
第一，增量数据的实时捕获。 全量迁移完成后，旧系统仍在产生新数据。增量同步的核心是日志解析——Oracle 的 Redo Log、MySQL 的 Binlog、KES 的 WAL，同步工具读取这些日志，解析出行级变更，封装成统一格式发送到目标端。全量迁移结束时有一个精确的 SCN，增量同步必须从这个 SCN 开始捕获，才能保证不漏不重。
第二，双向同步与快速回切。 正向同步阶段：旧系统为主库，新系统为备库。业务切换到新系统后，同步工具自动建立反向链路，新系统的变更实时回传旧系统，旧系统作为热备持续接收更新。一旦新系统出现异常，流量在分钟级内切回旧系统。关键在于反向链路的建立必须是自动的，不能依赖人工配置。
第三，全周期的数据一致性校验。 双轨运行期间，两端数据必须持续保持一致，不能依赖人工抽查，需要系统自动校验和修复。校验分三个阶段：存量数据校验、增量同步中的实时校验、切换前的最终校验。
在真正切换流量之前，必须完成以下检查：
回滚不能等到出了问题再想“要不要回滚”。触发条件必须提前定义并自动化执行。建议设三级触发：
L1 自动熔断（无需人工确认）： 格式异常率超 5% 持续 3 分钟、核心接口 5xx 超 1%、敏感信息检测命中率超 0.1%，满足任一条件自动切回旧版本。
L2 快速回滚（人工确认后执行，目标 15 分钟内完成）： 新模型错误率超过旧模型基线 3 倍、P99 延迟超过 SLA 阈值 1.5 倍、连续 5 分钟出现 5xx 错误。金融系统迁移的实践显示，建立 15 分钟快速回退机制后，投产窗口可以从计划的 48 小时压缩至 26 小时。
L3 完整回切（涉及数据回滚，目标 RTO < 5 分钟）： 停止增量同步，将最后 10 分钟的变更从新系统反向同步回旧系统，修改连接串切回旧系统。
AWS 的 Agentic AI Lens 明确指出一个关键反模式：把回滚当作理论能力，从未演练过，导致第一次使用是在事故中。回滚程序必须在 canary 阶段之前进行刻意演练，确认回退在团队依赖它之前确实有效。
演练的具体要求：
回滚不只是“切回去”，还需要处理三类脏数据：
灰度期间的写入数据。 如果 canary 阶段新链路已经写入了数据，回滚时需要将这些数据同步回旧系统。这依赖前面建立的反向同步链路。
异步任务的 in-flight 状态。 对于有状态系统（如 agent 系统），回滚时需要设计有状态的回滚程序，处理 in-flight 的任务。
部分回滚的隐蔽失败。 聚合指标正常但某个子群体退化的情况下，回滚可能只回滚部分流量。需要确保回滚操作覆盖所有受影响的流量分组。
Strangler Fig 迁移最常见的失败模式不是技术问题，而是停下来。前三个 slice 交付了可见进展后，注意力转移，组织永久地运行着两套系统。
防止停滞的机制包括：
追踪核心指标：旧系统仍服务的流量百分比。 把它作为 headline metric，每周在团队看板上更新。如果这个数字连续 4 周没有下降，触发一次评审——是技术阻塞，还是组织注意力转移了？
设定“双轨窗口”上限。 在试点开始时，就明确双轨并行最多运行多长时间（建议 8-12 周）。超过这个窗口，要么推进切换，要么正式暂停迁移并回退到单一系统。不允许无限期双轨运行。
迁移节奏的硬约束。 前 90 天必须完成至少一个模块的完整迁移（从 Shadow Mode 到全量切换）。如果做不到，不是模块选错了，就是架构距离评估不准确——需要回到第 2 章重新诊断。
ExecutionModeContext，确保所有写操作在 shadow 模式下只产生 outbox 记录，不产生真实副作用。第 5 章解决了“新链路能不能跑对”的问题，但新链路如何进入旧系统的生态，是另一个维度的挑战。
存量系统的集成难点不在于技术工具，而在于暴露面的控制。一个新链路接入旧系统，可能触发的影响面包括：上游调用方的参数假设、下游消费者的数据格式、共享数据库的隐式约束、批处理作业的时间窗口、以及运维人员的心智模型。Gartner 指出，AI 在识别技术债务、整理和补全文档方面具有一定价值，但并不适合将遗留代码自动转换到现代化平台。这意味着集成必须由人类设计、由 AI 辅助执行，而不是反过来。
四种集成方式的风险等级从低到高：API 包装 → 旁路增强 → 渐进替换 → 深度增强。选择哪种，取决于模块的暴露面大小、业务关键性和回滚成本。
适用场景：旧系统有稳定的 API 接口，但接口的语义、协议或数据格式不适合 AI 链路直接调用。
做法：在旧系统 API 前面构建一层新的服务层，将旧接口“包裹”起来，对外暴露为 AI 链路可以消费的格式。这层包装负责协议转换、数据映射、错误码翻译和鉴权适配。
技术实现：MCP 网关是当前比较成熟的路径。它把存量接口的元信息以 Tool 的形式登记在网关里，Agent 调用时由网关把 MCP 请求翻译成 HTTP 请求——两侧互不感知。这种方式的最大优势是零代码改造：旧系统不需要做任何修改，只需在网关侧配置即可。
风险等级：低。旧系统行为不变，包装层可以独立测试、独立回滚。
限制：只适用于“旧系统已经有 API”的场景。如果旧系统的接口是文件交换、屏幕抓取或数据库直连，API 包装不适用。
适用场景：旧系统的核心流程不能改，但需要在旁边增加 AI 能力。
做法：通过异步数据管道（Asynchronous Data Pipeline）从旧系统捕获数据变更，在独立的服务中完成 AI 处理，结果写回旧系统或供下游消费。典型场景包括：对旧系统产生的日志做异常检测、对历史数据做智能分类、对事务记录做风险评分。
技术实现：核心是变更数据捕获（CDC）。CDC 读取旧数据库的预写日志，异步重放变更，将写路径解耦，调优后复制延迟通常低于一秒。相比双写（dual writes）方案，CDC 不会因为部分失败而导致两个系统数据不一致。
风险等级：中低。旧系统的读路径不受影响，但写回时需要处理一致性问题。建议第一阶段只读不写，验证 AI 输出的准确性后再开放写回。
适用场景：旧系统的某个模块可以被完整替换，且有清晰的接口边界。
做法：这是第 5 章 Strangler Fig 模式在集成层面的延伸。通过路由层将部分流量切到新链路，旧模块逐步被“绞杀”。
选择“先替换哪个”的优先级：Strangler Fig 的最佳切入点是上游依赖最少、写面窄、读为主、且位于 facade 可以拦截的接口之后的模块。避免先选最大、最痛的那个模块，因为它通常深嵌在共享表、批处理作业和其他服务依赖的字段中，会在团队还没有跑通过一次完整流程之前就制造最难的协调工作。
数据同步的选型：在迁移重叠期，双写和 CDC 各有取舍。双写实现简单但在负载下容易失败——部分失败会导致一个系统领先而没有记录标明哪个是权威值。CDC 从旧数据库的预写日志读取并异步重放变更，通常引入不到一秒的复制延迟，更适合生产环境。
风险等级：中高。需要处理数据一致性、回滚、以及新旧系统的行为对等验证。
适用场景：多个异构系统需要协同工作，但每个系统都不适合被单独替换。
做法：Agentic Nesting 框架将现有企业应用封装为自主 AI Agent，在分层嵌套结构中组织。它不是平面的互连，而是按照企业生态的组合复杂性构建分层治理拓扑。框架从每个遗留应用提取数字 Agent 代理，使其支持自然语言交互和自主操作，通过中央编排器协调多个 Agent 进行任务分解和动态调度。
这种方式的核心价值在于降低集成耦合。传统的 ESB 架构存在架构耦合高、运维成本攀升、智能能力有限等问题。Agentic Nesting 将集成从“系统间的 API 调用”升级为“Agent 间的任务协作”，在异构系统协调和大规模数据应用场景中有泛化潜力。
风险等级：高。需要完善的权限控制、审计日志和 Agent 行为边界定义。不建议在试点阶段使用。
无论选择哪种集成方式，人机协同的控制平面都必须提前设计。一个完整的控制流参考：task contract → permission scope → sandbox/worktree → action → witness event → provenance sidecar → human review → human gate → release/rejection → rollback/correction route。
核心原则是“没有 Agent 应该拥有超过任务所需的权限”。审批点的粒度取决于任务特征：自包含任务 + 绿地 + 低风险 → 事后审查即可；跨模块任务 + 成熟代码库 + 功能风险 → 需要自然语言审查。
审计日志必须不可变。当 AI Agent 可以修改仓库、生成元数据、准备发布产物时，需要回答的问题包括：Agent 被允许做什么？做了什么变更？谁审查了？谁承担责任？能否回滚？这些都需要不可变的审计日志支撑。
第 5 章和第 6 章解决了“怎么让新链路跑起来”。但在扩大范围之前，必须回答一个前置问题：当前链路到底稳不稳？
很多团队的扩链决策基于“演示看起来不错”或“团队觉得差不多了”。这种判断方式在新建项目里或许可行，但在存量迁移场景中极其危险。Gartner 预测超过 70% 在 2026 年启动的大型机退出项目将因高估生成式 AI 能力而无法实现预期收益，AI 在识别技术债务和整理文档方面有价值，但不适合自动将遗留代码转换到现代平台。这意味着一件事：扩链决策不能基于“AI 能做很多事”的乐观预期，必须基于“当前链路已被验证”的硬数据。
扩链条件是四个阶段的“毕业考试”。考试不通过，回到试点阶段继续验证；考试通过，才允许扩大范围。
定义：AI 生成的代码在合并后 30 天或 90 天内仍留在代码库中的比例，分别追踪 AI 生成和人工编写的代码。
为什么这个指标比“生成速度”更重要：AI 让代码写得更快，但它不保证代码活得更久。一项研究追踪了 AI 生成代码单元的存活情况，从诞生到在开源仓库中被修改的整个过程。如果一个 AI 生成的模块在两周内被大幅重写或删除，那它贡献的不是生产力，而是返工。
扩链门槛建议：AI 生成代码的 30 天存活率应不低于人工编写代码存活率的 80%。如果低于这个阈值，说明 AI 输出的“可保留性”不足，扩链只会放大返工。
定义：一个任务从 AI 首次生成到最终合并之间，经历了几轮“生成 → 审查 → 修改 → 再审查”的循环。
行业基准：行业数据显示，AI 辅助条件下每任务的返工迭代次数从基线的 3.2 次降至 1.3 次才算健康。如果试点模块的平均迭代次数超过 2.5 次，说明 AI 的输出与审查标准之间存在系统性偏差——可能是提示词问题，可能是上下文不足，也可能是验收标准本身不清晰。
扩链门槛建议：连续 5 个任务的返工迭代次数 ≤ 2 次，且趋势稳定或下降。
New Relic 的 2026 年调查报告揭示了一个令人不安的“AI 质量悖论”：94% 的技术领导者认为 AI 生成的代码在审查时质量高于人工编写，但上线后 78% 的受访者报告了更多事故，86% 报告高级员工花在修复代码上的时间增加，74% 报告至少 25% 的 AI 代码需要大量返工。更令人警惕的是，82% 的受访者在过去六个月中至少经历过一次与 AI 生成代码相关的生产故障。
Faros 的工程研究发现，AI 让软件开发更快，但审查缺口、QA 瓶颈和上升的事故量揭示了新的风险——每月事故量上升了 125.4%，修复速度更慢，积压量在重新增长。在某个数据集中，每 PR 的事故率上升了 14.5%。
这些数据说明：扩链之前必须确认“变更失败率没有系统性上升”。扩链门槛建议：
定义：第 3 章基线 Spec 中定义的核心行为，有多少已经被自动化测试覆盖并验证通过。
为什么这是扩链的硬门槛：验收标准覆盖率直接决定了“扩链后的风险是否可控”。如果覆盖率只有 60%，意味着 40% 的行为变更不会被任何测试捕获。扩链把新链路暴露给更多流量时，那 40% 的盲区就是事故的温床。
扩链门槛建议：试点模块的验收标准覆盖率 ≥ 85%。剩余 15% 未覆盖的行为，必须有明确的人工审查流程和回滚预案。
将四个核心指标整合为一个决策矩阵：
| 指标 | Go（扩链） | Conditional（先补短板再扩链） | No-Go（暂停） |
|---|---|---|---|
| 代码存活率 | ≥ 80% 基线 | 60%-80% | < 60% |
| 返工迭代次数 | ≤ 2 次 | 2-3 次 | > 3 次 |
| 变更失败率 | ≤ 基线 | 基线 1-1.5 倍 | > 基线 1.5 倍 |
| 验收覆盖率 | ≥ 85% | 70%-85% | < 70% |
四个指标全部 Go → 进入扩链。任何一项 No-Go → 暂停扩链，回到对应阶段修复。多项 Conditional → 设定整改期限，只允许延长一次。
很多团队把爬坡期理解为“培训”。培训只是其中一部分，而且不是最重要的部分。
爬坡期真正的任务是建设让 AI 持续产生可靠输出的工程基础设施。这包括四件事：Harness 配置、提示库管理、质量门禁接入、度量体系搭建。没有这四件事，培训出来的“会用 AI”很快就会退化成“每个人用自己的方式用 AI”——效率不可比、质量不可控、经验不可复用。
Harness 是指围绕 AI 编程智能体搭建的一整套工程基础设施，由五个子系统组成。核心思想是：AI 不是不够聪明，而是不知道“这个项目的规则”。
一个典型的 Harness 配置包括：
AGENTS.md 或 CLAUDE.md（根目录上下文文件）：用 5 分钟写一份文件，说明“这个项目是做什么的、用什么技术、哪些文件不能动、怎么跑测试”，能避免 90% 的低级重复错误。
Rules（代码规范传递）：将项目的编码约定定义为 Rules。以 Cursor 环境为例，Rules 支持 globs 选项，只在指定路径的文件被操作时才激活对应规则，避免不必要的 token 消耗。
Skills（任务自动化）：将高频操作（如“生成一个符合项目规范的 API 端点”“为这个模块补充特征测试”）封装为可复用的 Skill，支持版本化管理，确保不同项目和团队的 Skill 配置互不干扰。
验证工作流和会话连续性机制：确保 Agent 在多个会话之间保持上下文一致性，不因为会话切换而丢失对项目规则的理解。
提示库不能是一个散落在聊天记录里的文本集合。它应该像代码一样被管理：版本控制、code review、回滚能力。
建议将提示库作为 Git 仓库管理，实现 check-out/check-in 工作流和 commit 消息。每个提示条目应包含：适用场景描述、输入输出示例、已知的失败模式和边界条件、最近一次验证的日期和验证人。
提示库的结构建议：text
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
prompts/ ├── migration/ # 迁移专用提示 │ ├── py2-to-py3.md │ ├── cobol-to-java.md │ └── characterization-test.md ├── review/ # 审查提示 │ ├── security-review.md │ └── business-logic-review.md ├── scaffolding/ # 脚手架提示 │ ├── api-endpoint.md │ └── module-boundary.md └── _shared/ # 共享上下文片段 ├── project-context.md └── coding-standards.md |
第 7 章的扩链条件解决了“什么时候可以继续做”，但扩链之后需要自动化的质量门禁来保证每一次提交都不低于扩链时的质量标准。
质量门禁至少应包含：
安全扫描：SAST 工具作为 AI 辅助提交的强制预合并门禁。New Relic 的报告显示，82% 的组织在过去六个月中至少经历过一次与 AI 生成代码相关的生产故障，安全门禁不是可选项。
验收测试：基于第 3 章基线 Spec 的自动化测试必须在 CI 中通过。未通过验收测试的 AI 提交不允许合并。
变更影响分析：对于跨模块的变更，自动分析受影响的上下游服务，标记需要额外审查的范围。
门禁的分级策略：不是所有变更都需要全量门禁。参考 AI 编程的推荐做法：
传统的 DORA 四项指标（部署频率、变更前置时间、变更失败率、恢复时间）仍然是基础框架，但在 AI 辅助场景下需要扩展。
DORA 2025 报告引入了七个能力，帮助放大 AI 采用的收益，包括清晰的 AI 政策、健康的数据生态系统和以用户为中心的关注。报告还新增了一个关键指标，并取消了精英/高/中/低的分级，转而引入基于八项测量的七种 archetype。
在存量迁移场景中，建议在 DORA 基础上增加三个 AI 特定指标：
| 指标类别 | 传统 DORA | AI 特定扩展 |
|---|---|---|
| 吞吐量 | 部署频率、前置时间 | AI 生成代码的合并率 |
| 稳定性 | 变更失败率、恢复时间 | AI 代码的变更失败率（与人工基线对比） |
| 质量 | — | 代码存活率（30 天）、每任务返工迭代次数 |
| 成本 | — | 每合并变更的 token 成本、AI 代码的审查耗时 |
| 人效 | — | 审查者首次通过率、高级员工修复 AI 代码的时间占比 |
度量体系的目的是发现趋势而非考核个人。如果 AI 代码的变更失败率连续三周上升，说明质量门禁或提示质量需要调整，而不是某个人的问题。
试点毕业的产品是证据链，推广阶段的任务是把这套证据链转化为可复用的基础设施。这个转化的过程需要解决三个问题：知识如何传播、能力如何复制、质量如何统一。
Anthropic 的 Champion Kit 明确了冠军角色的三种相互强化的行为：分享你的发现、成为人们提问的对象、扩大活跃用户的圈子。冠军不是帮助台，而是团队的倍增器——他们分享的每个例子都缩短了后来工程师的学习曲线。
冠军角色的具体行为包括：
冠军角色的时间投入建议控制在每周约 40 分钟：发布胜利和提示约 15 分钟，在共享频道回答问题约 20 分钟，主持每周展示约 5 分钟。关键原则是保持这个角色作为现有工作的倍增器，而不是额外的支持责任。
EPAM 的 Champions of Change 项目是一个企业级参考：他们招募了 50 名区域 Copilot 冠军，统一分散的采用努力，确保跨区域的一致有效推广。冠军获得持续培训和提前访问新项目的权限。Spendesk 则用 13 名 AI Champions 驱动各部门的采用，实现了 93-94% 的月活跃用户和 83% 以上的周留存率。
推广阶段必须产出的标准化资产：
编码规范文件：这不是传统的编码规范文档，而是“活的”规范——在释放 Agent 之前就要发布的、AI 可以读取和遵守的规则文件。包括命名约定、目录结构、依赖管理规则、错误处理模式。
提示模板库：将试点中验证有效的提示词固化为模板，附带适用场景、输入输出示例和已知限制。
审查检查清单：按变更类型（新功能、重构、迁移、修复）分列。每类变更需要检查的维度不同：迁移类变更重点检查行为对等性，新功能类变更重点检查边界条件和错误处理。
MCP 服务器配置模板：如果试点使用了 MCP 网关或类似工具，将配置模板化，让新团队可以快速复制。
推广到多团队时，需要一个平台化的支撑结构。建议分三层：
工具层：IDE 插件、Agent 引擎、路由层、CDC 工具。这一层提供“能用”的能力。
治理层：质量门禁、审计日志、权限管理、合规检查。这一层提供“可控”的保障。
知识层：提示库、上下文文件、编码规范、审查检查清单、失败案例库。这一层提供“可复用”的经验。
三层之间的关系是：工具层让团队开始用，治理层让团队安全地用，知识层让团队高效地用。任何一层缺失，推广都会在某个规模上遇到瓶颈。
推广阶段的度量重点从“单模块的质量”转向“多团队的采纳深度”。
采纳率：不只是“有多少人登录了 AI 工具”，而是“有多少人每周至少使用一次”和“有多少团队有持续使用 AI 完成实际任务的流程”。Spendesk 的数据显示，93-94% 的月活跃用户和 83% 以上的周留存率是一个高水平的参考基准。
深度指标：有多少团队在使用自定义 Agent（而非通用 LLM）？Spendesk 的数据中，40% 以上的消息发送给自定义 Agent 而非通用 LLM，这说明采用已经超越了“把 AI 当更好的 ChatGPT”阶段。
质量一致性：不同团队的 AI 代码变更失败率是否有显著差异？如果某个团队的失败率是其他团队的 3 倍，说明该团队的 Harness 配置或审查流程有问题。
持续改进的机制：每月做一次“失败案例回顾”，收集各团队的 AI 代码问题，分析根因，更新提示库和质量门禁。这不是追责会议，而是集体学习。
表现：基线 Spec 只记录了“正常路径”的行为，边界条件、异常路径和隐性副作用未被覆盖。验收测试看起来在跑，但实际上只验证了 60% 的行为。
后果：AI 生成代码在正常路径上表现良好，审查时被判定为“质量高于人工代码”——这正是 New Relic 报告揭示的悖论：94% 的领导者认为 AI 代码在审查时质量更高，但上线后 78% 报告了更多事故。
根因：Spec 的建立方式出了问题。如果 Spec 是基于文档而非基于行为捕获（特征测试/Golden Master），那么它记录的只是“文档以为系统做了什么”，而不是“系统实际做了什么”。
预防措施：第 3 章的特征测试和 Golden Master 模式是唯一的系统化解法。验收标准的覆盖率必须作为扩链的硬门槛（第 7 章）。
表现：AI 基于过时文档生成代码，结果“合法但错误”——代码可以编译、可以运行，但行为与旧系统不一致。
典型案例：一个日本遗留系统现代化项目中，文档是日语的扫描版 UI 屏幕截图，用代码标识符代替有意义的名称。团队尝试用 AI 直接从旧代码生成 Java/React 代码，但因语言差异大且没有 1:1 映射而失败。文档生成阶段 AI 表现良好（约 90% 的可接受质量），但代码生成阶段无法产出可用的生成器。
根因：文档在存量系统中几乎必然与代码脱节。AI 看不到这种脱节，它只能基于给出的上下文做推断。
预防措施：先捕获行为，再对照文档。如果行为与文档不一致，以行为为准，同时记录差异为“待确认规则”。
表现：AI 生成的迁移代码可以编译、可以运行，但输出与旧系统存在细微差异。更危险的是，当被要求审查自己的输出时，AI 会“言之凿凿地”宣称行为保持不变。
量化数据：一项针对 11 个生产级 LLM 的研究发现，在语义保持漂移的案例中，31.7% 被同一个产生输出的模型默默认可。更令人警惕的是，某些模型在明确描述了导致输出损坏的 Py2/Py3 语义差异后，仍然宣布行为已保留。漂移率在模型能力上呈非单调分布，范围为 5.6% 到 46.7%，与模型大小和价格不干净地相关，表明这是任务结构性问题而非模型规模问题。
根因：AI 的自我审查本质上是在做“语言上合理的解释”，而不是在做“行为验证”。它在检查“这段代码看起来对不对”，而不是“这段代码跑出来的结果对不对”。
预防措施：永远不要用同一个模型审查自己生成的迁移代码。 使用独立的验证流程：Golden Master 对比、特征测试回放、以及人工审查。第 5 章的 Shadow Mode 正是为此设计的。
Red Hat 的研究指出，生成式 AI 在绿地项目中带来 30-40% 的生产力提升，但在低复杂度存量系统中降至 15-20%，在高复杂度企业代码库中暴跌至 0-10%。三个主要原因：上下文碎片化（AI 只能看到代码库的窄片，在更广泛的复杂依赖中产生幻觉或猜测）、返工循环（开发者花在审计、调试和修复错误 AI 代码上的时间超过手动编写）、以及验证税（验证 AI 生成代码满足严格安全、性能和合规标准所需的智力努力往往抵消了初始时间节省）。
根因：LLM 缺乏领域上下文，无法理解应用内部的业务域，也无法推断组织需要的限界上下文；静态建议不够，现代化需要理解系统在运行时如何行为；代码助手偏向绿地工作，而大规模现代化是外科手术式的、跨纠缠依赖的行为保持重构；Token 限制导致百万行级单体系统的全局视图碎片化。
预防措施：Harness 配置提供项目上下文，运行时分析补充静态分析的不足，Strangler Fig 的增量方式避免一次性处理整个系统。
审批疲劳：审批点过多导致人类审查者敷衍了事。当 Agent 一夜之间产生 30 个 PR，而审查轮换的规模是按每天 6 个 PR 设计的，审查质量必然下降。交付看板仍然显示健康——吞吐量上升、故事点上升、前置时间持平——但回滚日志讲述的是另一个故事。
影子 AI：团队成员在未经治理的情况下自行使用 AI 工具修改代码，绕过质量门禁和审计流程。这是审批疲劳的镜像问题——当正式流程太慢时，人们会绕开它。
预防措施：审批点的数量与变更风险成正比。低风险变更用自动化门禁，高风险变更用人工审查。关键不是“加更多审批”，而是“把审批加在对的地方”。
Strangler Fig 迁移最常见的失败模式不是技术问题，而是停下来。迁移通常停在约 80% 完成度，因为剩余的切片是那些没有人预先规划过的部分——具有未文档化副作用的批处理作业、没有人负责的报告管道——而业务已经从旗舰能力上线中获得了收益。
修复方式：通过决策门禁来资助迁移，门禁与旧系统退役挂钩，而不是与新系统的功能对齐挂钩。 追踪迁移为什么停滞，能帮助规划迁移的团队避免同样的陷阱。
决策者清单：
架构师清单：
开发者清单：
冠军清单：
| 指标 | 定义 | 用途 | 健康阈值建议 |
|---|---|---|---|
| 代码存活率（30天） | AI 代码合并后 30 天仍留存的比例 | 判断 AI 输出的可保留性 | ≥ 人工代码存活率的 80% |
| 返工迭代次数 | 从首次生成到合并的审查循环次数 | 判断 AI 输出与审查标准的匹配度 | ≤ 2 次 |
| 变更失败率 | 发布后导致故障的变更比例 | 判断 AI 代码的稳定性 | ≤ 人工基线 |
| 验收覆盖率 | 基线 Spec 中被自动化测试覆盖的核心行为比例 | 判断行为对等的可信度 | ≥ 85% |
| 审查后首次通过率 | AI 生成代码经审查后一次通过的比例 | 判断 AI 输出质量 | 趋势稳定或上升 |
| 每合并变更的 token 成本 | 每次成功合并所消耗的 token 成本 | 判断经济性 | 无异常上升趋势 |
| 周活跃使用率 | 每周至少使用一次 AI 工具的开发者比例 | 判断推广深度 | 持续上升 |
回到博客的开头：存量项目的 AI 工程化迁移，本质上不是“让 AI 替代开发者”，而是把存量系统中隐性的、散落在个人经验中的工程知识，转化为显性的、可验证的、AI 可以遵守的基础设施。
基线 Spec 把行为形式化，Harness 把上下文结构化，质量门禁把标准自动化，度量体系把判断数据化。这些基础设施一旦建成，不仅 AI 能用，新加入的人也能用；不仅这一个模块能用，下一个模块也能用。
Gartner 的警告值得作为全文的收束：AI 在识别技术债务、整理和补全文档方面有价值，但并不适合将遗留代码自动转换到现代化平台。这不是否定 AI 的价值，而是指明它的正确位置——AI 是辅助理解和验证的工具，工程判断仍然在人手中。
迁移的终点不是“AI 接管了旧系统”，而是“团队获得了在 AI 辅助下安全演进系统的能力”。前者是一个技术事件，后者是一个工程能力升级。后者才是值得追求的目标。
| 原用词 | 统一为 | 说明 |
|---|---|---|
| 遗留系统、老系统、旧系统、存量系统 | 存量系统（总称）；旧系统（与“新链路”对比时） | 总称用“存量系统”，具体指代被替换的一侧时用“旧系统” |
| AI 链路、新系统、新链路 | 新链路 | 与“旧系统”对应 |
| 基线 Spec、基线规格 | 基线 Spec | 首次出现可写“基线 Spec（行为契约）” |
| Harness | Harness | 首次出现给中文解释：“围绕 AI 编程智能体搭建的工程基础设施” |
| Shadow Mode | Shadow Mode（影子模式） | 首次出现给中文 |
| Strangler Fig | Strangler Fig（绞杀者模式） | 首次出现给中文 |
| 质量门禁 | 质量门禁 | 保持一致 |
| 代码存活率 | 代码存活率 | 保持一致 |
| 返工迭代次数 | 返工迭代次数 | 保持一致 |
全局替换建议：
| 出处 | 引用目标 | 核对结果 |
|---|---|---|
| 第1章 1.3 | 第5章、第7章讨论“停在半路” | 正确 |
| 第1章 1.5 | 第三篇的 Harness、质量门禁 | 正确，已给简版定义 |
| 第2章 2.2 | 第4章试点评分 | 正确 |
| 第3章 3.7 | 第5章双轨并行、Shadow Mode | 正确 |
| 第4章 4.2 | 第2章筛选出的候选模块 | 正确 |
| 第5章 5.2 | 第3章基线 Spec | 正确 |
| 第6章 6.4 | 第5章 Strangler Fig | 正确 |
| 第7章 7.5 | 第3章基线 Spec | 正确 |
| 第8章 8.4 | 第3章基线 Spec、第7章扩链条件 | 正确 |
| 第9章 9.1 | 第8章爬坡期 | 正确 |
| 第10章 10.1 | 第3章特征测试、第7章扩链门槛 | 正确 |
| 第10章 10.3 | 第5章 Shadow Mode | 正确 |
| 第10章 10.6 | 第5章、第7章 | 正确 |
所有交叉引用均指向正确章节，无需修改。
ASCII 简版：text
|
1 2 3 4 |
诊断 → 试点 → 双轨 → 推广 │ │ │ │ ├─适用性筛选 ├─最小闭环 ├─Shadow Mode ├─标准化 └─适配度评分 └─退出标准 └─Canary/回滚 └─平台化 |
（已在第2章正文中给出 Mermaid 代码）
ASCII 简版：text
|
1 2 3 4 5 6 7 |
客户端 │ 路由层（Facade/代理） ├─ 旧链路 → 旧系统 ├─ 灰度/Canary → 新链路 └─ Shadow Mode（只读旁路）→ 影子执行 → 差异对比 ← 旧系统输出 数据层：旧系统 ↔ CDC/双向同步 ↔ 新链路 |
ASCII 简版：text
|
1 2 3 4 5 6 7 8 |
Harness ├─ AGENTS.md / CLAUDE.md（项目上下文） ├─ Rules（代码规范） ├─ Skills（任务自动化） ├─ 验证工作流（质量门禁） └─ 会话连续性（上下文保持） ↓ AI 智能体 → 可复用输出 |
ASCII 简版：text
|
1 2 3 4 |
核心指标：代码存活率 | 返工迭代次数 | 变更失败率 | 验收覆盖率 审查后首次通过率 | token 成本 | 周活跃使用率 ↓ 扩链决策矩阵 → Go / Conditional / No-Go |
- [ ] 复选框格式，部分平台会自动渲染为可勾选列表；若不支持，改为普通列表。全文约 3 万字，建议拆为 4 篇系列文章：
| 篇次 | 覆盖章节 | 建议标题 | 核心问题 |
|---|---|---|---|
| 第一篇 | 第1-2章 | 存量项目 AI 工程化迁移：先判断值不值得迁 | 全景、失败根因、适用性筛选 |
| 第二篇 | 第3-4章 | 基线 Spec 与试点选择：怎么定义“迁对了” | 行为捕获、Golden Master、试点评分 |
| 第三篇 | 第5-6章 | 双轨并行与集成策略：不赌一把切换 | Shadow Mode、Canary、回滚、集成方式 |
| 第四篇 | 第7-10章 | 扩链、爬坡、推广与失败模式：从单点到多团队 | 扩链指标、Harness、推广、检查清单 |
每篇末尾附“下一篇预告”和系列目录链接。
如果平台更适合长文，也可以拆为 3 篇：第1-3章、第4-7章、第8-10章。
| 章节 | 一句话摘要 |
|---|---|
| 第1章 迁移全景与导读 | 存量迁移比新建更难，根因是领域上下文缺失、无运行时感知、Token 碎片化；四阶段渐进 + Strangler Fig 是主线 |
| 第2章 诊断 | 先用三问筛选适用性，再用 AI 适配度评分排序，最后评估知识流失风险 |
| 第3章 基线 Spec | 用特征测试和 Golden Master 捕获“旧系统实际行为”，而非“文档以为的行为” |
| 第4章 试点选择 | 用评分模型选模块，用退出标准防试点无限延长，产出可复用证据链 |
| 第5章 双轨并行 | Shadow Mode 只读验证 → Canary 小流量 → 全量切换；数据同步与回滚必须演练 |
| 第6章 集成策略 | API 包装、旁路增强、渐进替换、深度增强四种方式，风险等级递增；人机协同审批点必须提前设计 |
| 第7章 扩链条件 | 代码存活率、返工迭代次数、变更失败率、验收覆盖率四指标决定 Go/No-Go |
| 第8章 爬坡期 | Harness 配置、提示库版本化、质量门禁、度量体系是“从能用到好用”的基础设施 |
| 第9章 推广 | 冠军角色制度化、标准化资产、平台三层架构、月度失败案例回顾 |
| 第10章 失败模式、检查清单与指标 | 六种失败模式 + 分角色检查清单 + 核心指标总结；终点是工程能力升级，不是 AI 接管 |
mermaid 语言