00摘要：十条核心论断
如果你只读一页，读这一页。每条论断都可以被证伪，并标注了主要证据的类型。
- 「用 AI 重新开发一个全新系统」这个提问方式本身是错的。大样本 + 多案例
正确的目标定义是行为迁移（Behavior Migration）——把交付标准从「新系统写完了」改成「新系统在约定业务边界内，与老系统行为等价，且这一点被证据证明」。代码只是行为的载体；你真正要搬走的是 13 年里长在生产环境里的判定逻辑。蚂蚁在支付宝生活缴费 60 万行系统上的原话是：把重构目标「从迁移代码转变为迁移行为」。
- AI 在遗留系统上失败，95% 死在同一层：认知层。大样本观察
Meta 内部对 4100+ 遗留改造任务的统计显示，AI 能独立完成的只有约 5%。原因不是它不会写代码，而是「为什么这段逻辑要这么写」根本不在文件里——它在十年前的邮件、离职同事的脑子里、在没人写下来的口头约定里。对你这套 2013 年起步的系统，这是最致命的一层。
- 编码能力早已不是瓶颈，判断力才是。基准测试 + 生产统计
SWE-bench Verified 上顶级模型已达 78–88%，但更接近真实工作的 SWE-bench Pro 只有 23%，Senior SWE-Bench（欠规格、多服务、长周期）约 24%；生产环境真实 PR 采纳率约 35–50%。把它理解为：AI 能完成「定义清楚的小任务」，不能完成「定义本身」。
- 大爆炸式重写失败率 70–88%，且主因是组织性的。多来源统计（口径不一）
失败原因排序：范围从「替换」膨胀成「重建」、特性冻结在第 4 个月被业务打破、懂老系统的工程师在第 18 个月流失、缺少并行运行期。全部与框架选型无关。这不是技术问题，是节奏问题。
- 第零步不可跳过：先把 13 年资产变成 AI 可读的东西。方法论 + 多案例共识
三件套缺一不可：代码知识图谱（AST + 调用图 + 反向依赖 + CODEOWNERS）、决策日志/ADR（把「为什么」从人脑搬到 git）、特征测试（把「现在长这样」固化成可验证的不变量）。不做这三件事，后面所有 AI 动作都是在沙地上盖楼。
- 验证体系的建设成本必须前置，它是决定成败的单一最大投入。单一深度案例
蚂蚁案例：60 万行、单接口分支超 8000 个、有效验证耗时 2–3 小时、在传统验证环境上 AI 的验证成功率只有约 60%。解法是 Golden Set 场景集（PERS 建模）+ 影子流量回放 + 差分验真，专门为 AI 重造可验证的工程地基。你这套系统的合同域（928 文件）分支密度大概率同级甚至更高。
- 「AI 生成占比」和「AI 独立完成占比」是两个完全不同的数，混淆会致命。大厂自报数据
Google 内部新代码 AI 生成占比 2024 年 25% → 2026Q1 约 75%，看着震撼；但同一时间 Meta 的 AI 独立完成占比只有 5%，DX 测到真正合入主干的 AI 代码约 22%。前者衡量杠杆，后者衡量能力边界。汇报时只报前者，是在自欺。
- 代码转换 ≠ 应用现代化。厂商方法论 + 工程共识
把 73 万行 Java 1.7 翻译成 Java 21 + Spring Boot 4，如果领域边界、数据模型、接口契约全没变，你只是把技术债换了个更贵的新版本，还额外背上了「AI 生成的代码没人真正理解」的认知债。语言升级是副产品，不是目标。
- 数据层是最硬的骨头，且唯一必须「先建双轨、再切」的部分。工具链实证
你的三轨数据访问（508 个 MyBatis 手写 SQL + reed-grail 元数据 ORM + Hibernate 3 工作流）意味着业务逻辑同时寄生在 Java、XML、数据库元数据三层。自动转换工具（ora2pg / AWS SCT / 国产库迁移链）只能覆盖 90%，剩下 10% 的硬逻辑（层次查询、包级状态、自治事务、空串当 NULL）吃掉项目大部分时间。
- AI 会引入一种新负债：认知债（Cognitive Debt）。行业雷达 + 咨询共识
Thoughtworks Technology Radar v34 的核心警告：AI 生成代码量越大，人与系统之间的理解鸿沟越宽。而对遗留系统重构这个场景，认知债是致命的——因为你的目标恰恰是让人重新理解这个系统。所以本报告把「可解释、可审查、可回滚」当成硬约束，而不是加分项。
一句话结论
不要启动「AI 重写项目」，启动「行为迁移工程」：先用 3–6 个月把 73 万行代码 + 508 个 mapper + Oracle 数据字典变成 AI 可读的知识基座，再用特征测试和影子流量织一张验证网，然后从 contract 域（928 文件）里划出最小的一条业务闭环做端到端试点，一个域一个域地绞杀。AI 在这条路径上的角色不是「写代码的」，而是认知放大器 + 确定性子任务的执行器。
01范式判定：什么才算「用 AI 重新开发」
在开工之前必须先分清三种被混为一谈的做法。它们的目标、成本、失败率和验收标准完全不同，而绝大多数「AI 重构」项目翻车，都是因为嘴上说的是第三种，实际做的是第一种。
1.1 三种范式的分野
1.2 判别式：三个问题定路径
问题一：业务规则还在变吗？
如果 contract 域近 12 个月仍在按新业务需求改动，说明它的业务规格还活着——重写风险极高，因为你追的是一个移动靶。此时应选「模块化 + 增量绞杀」。
问题二：运行时还受支持吗？
Spring 3.2 + JDK 1.7 早已 EOL，安全补丁缺失是真实的合规风险（尤其涉及合同、金额、经营指标）。这是唯一能构成「必须动」的硬理由——但它支持的是分层升级，不是全量重写。
问题三：数据模型挡住业务了吗？
只有当 Oracle 里的表结构（而非代码结构）主动阻塞新产品能力时，全量重写才被行业共识认可。注意：「表设计很丑」不构成理由，「表达不了业务」才构成。
给你系统的初判
问题一：合同全生命周期 + 经营指标，13 年持续演进，业务规则必然仍活跃 → 重写风险高
问题二：JDK 1.7 / Spring 3.2 / Hibernate 3 全部 EOL，是真实的驱动因素 → 必须动，但可按层动
问题三：需要你补一个事实——Oracle 数据模型是否阻塞了新业务表达。这是本报告唯一无法替你判断的输入。
综合建议：走范式 C，目标架构倾向模块化单体（Modular Monolith）而非微服务。原因见 05 章：你的团队不具备成熟 SRE/可观测体系时，微服务的运维复杂度会吃掉全部收益。
02理论根基：为什么必须是这个形状
这一章不堆比喻。每一条理论都会推导出一个具体的工程动作——这是它存在的唯一理由。
2.1 阿姆达尔定律：为什么「给团队发 AI 工具」在你的系统里感觉不到效果
最大整体加速比 = 1 / (1 − P)，其中 P 是能被 AI 加速的部分占整体的比例。在个人小项目里 P 可以到 0.9，加速比轻松 10×。但在一个 73 万行、13 年历史、跨部门交付的系统里，写代码这件事本身可能只占全生命周期的 20–30%；剩下的是读懂祖传逻辑、跨团队对齐接口、等评审与合规、跑全量回归、协调发布窗口。
推导出的工程动作：
- 让理解更便宜 → 建代码知识图谱 + 为每个核心模块写「持久上下文」（边界、契约、已知坑、对接人），一次写清、会话自动加载，删掉「反复向 AI 解释仓库」这道串行工序。
- 让验证更便宜 → 特征测试 + 影子流量回放 + 差分比对。注意方向：目标不是让评审更快，而是让验证不需要评审。评审是最贵的串行环节。
- 让协作更短 → 明确的模块边界（模块化单体），让接口变更不必跨 5 个团队对齐。
2.2 知识的分布：为什么「读懂代码」比「写新代码」难一个量级
遗留系统研究里有一条反复被验证的经验律：源码中只有 20–30% 能对应到真正的业务规则，其余 70–80% 是与具体技术环境耦合的胶水代码（通信中间件、数据库宏、框架适配、日志、异常兜底）。这也是为什么「把遗留代码整体迁移到新平台」在学术上被明确判定为不明智——你会把 80% 的历史技术债原样搬进新系统。
更麻烦的是，那 20–30% 的业务规则不局限在单个模块内：一个判定条件可能在 A 模块计算，在 C 模块消费，中间经 B 模块裁剪。提取工具必须能跨模块追踪执行路径。
2.3 遗留代码困境与特征测试：为什么必须「先锁行为，再让 AI 碰它」
Michael Feathers 给出的困境是：安全地改代码需要测试，而建立测试往往需要先改代码。遗留系统的定义就是「没有测试的代码」——你的 73 万行全部符合这个定义。
破解办法是特征测试（Characterization Test，也叫 Golden Master / Approval Test）：目的不是验证代码正确，而是记录代码的实际行为。它的算法很朴素但极其有效：
- 写一个调用目标单元的测试，断言一个你明知是错的值（例如随便填
expected = 0，而实际返回值尚未可知）。 - 运行，从失败输出里读到真实值。
- 把期望值改成观察到的真实值。
- 用描述行为的名字重命名测试。重复下一个输入。
关键纪律：所有期望值必须来自实际执行。来自文档、注释、提交历史或推测的期望值，记录的是猜测，不是系统行为。
一条会被反复引用的原则
「当系统进入生产，它在某种程度上就成为了自己的规格说明书。」Old code is the spec.
—— 一个 COBOL→Java 的实测案例中，LLM 一次性转换后「连 1994 年就存在的保费进位错误都完整保留了下来」，而这并不是失败，而是正确结果：会计部门的工作流是围绕这个误差建立的。迁移阶段不要要求 AI「顺手优化」，否则你会丢掉自己都不知道依赖了的行为。修 bug 是迁移完成之后独立的、被审批过的工作。
2.4 认知债：AI 时代新增的一类系统性风险
Thoughtworks Technology Radar v34（2026）把「认知债」列为核心议题：AI 生成的代码量越大，人与系统之间的理解鸿沟越宽。技术债影响的是「改起来贵不贵」，认知债影响的是「还有没有人能改」。
对遗留系统重构而言这是致命的悖论：你引入 AI 的目的是让人重新理解系统，但如果 AI 只是加速了代码产出而没有加速理解，你最终会得到一个「代码更新、但更没人看得懂」的系统——比原系统更糟，因为它连历史惯性都没有了。
推导出的硬约束（贯穿本报告后续所有章节）：
- 每个由 AI 生成的模块，必须同时产出该模块的「决策记录 + 持久上下文文档」，与代码同 PR 合入。没有文档的 AI 代码不允许进主干。
- 禁止把「通过测试」当作唯一验收。必须回答：这段代码是否符合本仓库既有约定？是否重复实现了已存在的抽象？资深评审是否会打回？（这就是 Senior SWE-Bench 强调的「tasteful solve」）
- 汇报指标里必须包含「AI 独立完成占比」，而不仅是「AI 生成占比」。
03系统画像：你面对的东西到底特殊在哪
在全世界公开的遗产现代化案例里，绝大多数是 COBOL 大型机、或者「标准框架 + 标准架构」的 Java 老系统。你这套系统属于第三类，也是最难被现成方法论直接覆盖的一类：自研平台 + 高业务密度 + 三层业务逻辑寄生。
3.1 量化基线
属于中型规模，但业务密度极高
最大业务域：合同全生命周期
经营指标
手写 Oracle SQL，非生成
连续演进，无重写历史
MyBatis / reed-grail / Hibernate 3
3.2 平台层画像：五个自研组件
| 组件 | 职责 | 技术实质 | 重构风险 |
|---|---|---|---|
| grail | 建模 / 元数据 ORM | 自研元数据驱动的对象映射，承载业务对象 | 极高 业务模型寄生于此，且无外部对标物 |
| pigeon | 工作流引擎 | 基于 Hibernate 3 实现，独立技术栈 | 高 流程状态机是隐性规格，且 Hibernate 3 已 EOL |
| brick | 页面设计器 | 元数据驱动的界面描述 | 中 UI 层需重建，但业务语义相对独立 |
| tiger | 安全 | 认证 / 授权 / 审计 | 中 可对标标准 RBAC/ABAC，但历史权限数据是硬约束 |
| runway | 聚合 | 跨模块数据聚合 | 可控 相对独立，适合作为首个试点域 |
全文最重要的一个判断：自研平台是 AI 的盲区
所有公开的 AI 现代化方法论都隐含一个前提：目标框架是主流开源框架（Spring Boot、Java 17、PostgreSQL），AI 在训练数据里见过成千上万个样本，能补全语义。
但你面对的是 reed / grail / pigeon / brick / tiger / runway——这些名字在公开语料里的出现次数是零。这意味着：
① AI 无法通过迁移学习理解 grail 的元数据语义，你必须显式地把平台规格喂给它；
② 不存在任何现成的「reed → 现代框架」转换工具，工具链必须自建；
③ 这恰恰是 AI 最擅长的场景——不是让它猜，而是在你提供完整规格后，让它做确定性的转换与验证。
结论：本项目第零步的核心交付物，是一份人类专家与 AI 都能读的《reed 平台语义规格》。这份文档的质量，直接决定后续所有 AI 动作的上限。
3.3 数据访问三轨制：业务逻辑寄生在三个地方
这是你系统里最容易被低估的结构性风险。同一个业务规则可能同时存在于三个地方，而且在 Java 代码里看不出来：
<if> / <choose> / <foreach>）是业务逻辑，不是查询优化——在合同域这种多机构、多类型、多状态的场景里，单个 mapper 可能包含几十个分支，它们共同定义了一份「查询语义规格」。迁移时漏掉任何一个 <if> 都等于丢业务行为。3.4 开工前必须采集的事实清单
行业数据显示，现代化项目最常见的超支原因是「集成面未知」——不知道老系统有多少未被记录的下游消费者。以下清单建议在两周内完成采集，它同时是后续所有估算的输入：
代码侧事实
- 508 个 mapper 的 SQL 语句总数、动态分支数、跨表关联深度分布
- Oracle 专有构造清单（
CONNECT BY/DECODE/ROWNUM/(+)外连接 / 分析函数 /MERGE）及各自出现次数 - 存储过程 / 函数 / 触发器的数量、总行数、依赖关系图
- grail 元数据定义文件（建模产物）全量导出与结构分析
- pigeon 工作流定义：流程数、状态数、状态迁移条件
- tiger 权限模型：角色数、权限点、数据行级权限规则
- 跨域引用矩阵：contract 与 operation 之间的双向依赖清单
运行侧事实（更关键）
- 接口契约清单：对外暴露的 API / 页面入口 / 批处理作业 / 报表 / 数据导出，全量枚举
- 下游消费者清单：谁在读你的库、调用你的接口、解析你的文件（这一项决定成败）
- 近 12 个月的变更热点：哪个模块改动最频繁（改动频率 ≈ 业务价值密度）
- 近 12 个月的生产事故清单：出过问题的地方就是规则最密的地方
- 关键人物清单：每个模块「还能说清为什么」的人是谁、是否在职
- 数据量基线：核心表行数、日增量、批处理窗口时长
- Oracle 授权成本与合规要求（合同 / 财务数据的出境与外部处理限制）
04第零步：把 13 年资产变成 AI 可读的东西
这是整个项目的前置条件，也是唯一一个「不做就一定失败」的环节。Google 的经验是 Context is all you need；对巨系统而言，context 不是 prompt 里的几行字，而是一整套基础设施。第零步的目标只有一个：让 AI（以及新人）能在不打扰老兵的前提下，回答「这段逻辑为什么这样」。
4.1 三件套总览
4.2 工序一：代码知识图谱
为什么纯向量检索不够：代码不是散文。「谁调用了这个函数」「哪个接口依赖这个服务」「改这里的影响面多大」是关系问题，不是相似度问题。纯相似度检索会把同一个工具类的多个副本召回，却漏掉真正解释行为的那条调用链。
2026 年的工程共识架构是「双索引」：向量索引负责语义邻域（找到候选），图索引负责结构扩展（决定哪些邻居必须一起带上），再用 token 预算封顶。
建图的技术要点
- 解析层：用 Tree-sitter 做增量解析，只重算变更文件。公开基准显示该方案可在约 3 分钟内索引 2800 万行 / 7.5 万文件的 Linux 内核（M3 Pro，厂商自测数据）。你的 73 万行属于轻量级。
- 节点类型：project / package / file / class / method / interface / **mapper / SQL 语句 / 表 / 字段 / 存储过程 / 工作流状态**——后四类是本项目的特殊扩展，通用工具不提供，需自建。
- 边类型：CALLS / IMPORTS / IMPLEMENTS / INHERITS / **READS_TABLE / WRITES_TABLE / RESOLVES_TO_SQL / DEFINES_FLOW / GRANTS_ROLE**。
- 切块粒度选择方法级——文件级太粗（问一个方法返回整个大文件）、类级仍偏粗（一个类 20 个方法时臃肿）。每个 chunk 只含一个方法 + 签名 + 注解 + Javadoc，类级摘要作为元数据保留。
- 索引治理是架构的一部分：文件重命名/删除时必须同步移除或重新索引旧向量，否则失效路径会持续占据检索位。
本项目的三个特殊扩展（自建）
- SQL 子图。把 508 个 mapper XML 解析为图节点：每个
<select>/<update>是一个节点，其动态分支、引用表、引用字段成为边。这样「哪些 mapper 依赖CONTRACT_MAIN表」变成一条查询而不是一次搜索。 - 元数据子图。把 grail 建模产物（业务对象 → 表 → 字段映射）导入图谱，打通「业务对象」与「物理表」两套命名体系。这是让 AI 理解 grail 的唯一途径。
- 平台语义层。为 reed 五个组件各写一份规格文档（见 4.5），作为图谱的「注释节点」，检索时强制随主节点一起带上。
4.3 工序二：决策日志与 ADR
Meta 那 5% 的根因就是「reasoning lives outside the files」——逻辑背后的理由不在文件里。治本的办法是把「为什么」从人脑搬到 AI 能读的结构化位置：
- 为现存系统补写「追溯型 ADR」。不要试图一次补齐 13 年，只补高风险 + 高变更频率的模块。格式固定五段：背景 / 当时的约束 / 选择 / 放弃了什么方案 / 今天还成立吗。注意最后一段——很多历史决策的前提已经消失了，这正是清理与简化的机会。
- 设立「知识守门人」角色。专人负责图谱维护、向量库、检索管道、上下文清理。把领域专长外化成 AI 能读的结构，这本身就是护城河。
- 新决策强制 ADR。从现在起，任何影响跨模块接口、数据模型、权限模型的决策，必须与代码同 PR 合入 ADR。规则简单：没有 ADR 的重构 PR 不允许合入。
4.4 工序三：特征测试网
这是三件套里最需要投入、也最直接产生回报的一件。要点：
- 优先级排序，不做全量。只覆盖「高风险 + 高变更频率 + 高业务价值」的模块。行业经验：特征测试覆盖率到 60–70% 通常已经能拦住绝大多数回归。
- 粒度从粗到细。先做端到端场景级（一次业务动作的输入输出），再做方法级。场景级成本低但覆盖面大。
- 命名必须可识别。测试名里显式带
characterises标记，文件名用独立后缀。目的：让未来的人和 AI 一眼看出这是「记录现状」而非「断言正确」，并且知道它是临时脚手架、将在重构后被行为测试替换。 - 可疑行为要显式标记，不要偷偷放过。当特征测试捕获到一个看起来像 bug 的行为时，在测试里加注释标记
SUSPICIOUS并说明——原样记录、单独升级评审。绝不在迁移阶段顺手修。 - 用 AI 批量生成，但要验证「测试有效」。两道自检：跑覆盖率找出从未被触及的输入；人为注入一个 bug，确认至少有一个测试能抓住它。做不到这两点，测试网就是装饰。
一个会被忽略但很关键的细节
特征测试的期望值必须来自实际执行输出。让 AI「看着代码推理出预期值」是反模式——那记录的是 AI 对代码的理解，而不是代码的行为。正确做法是：把老系统跑起来，喂真实输入，捕获真实输出（生产日志是最佳样本来源），再用这些输入输出对作为黄金样本。这也是影子流量回放（第 06 章）能无缝衔接的原因——它们是同一套样本基础设施。
4.5 第零步的交付物清单
| 交付物 | 内容 | 验收方式 | 建议周期 |
|---|---|---|---|
| 代码知识图谱 | 含 Java / mapper / 元数据 / 平台语义四层子图的查询库 + 检索接口 | 任取 20 个真实问题（如「改 X 影响谁」），图谱答案 vs 老兵答案一致率 ≥ 80% | 6–10 周 |
| 《reed 平台语义规格》 | grail / pigeon / brick / tiger / runway 五份规格：概念模型、约定、扩展点、已知坑 | 新人 + AI 仅读规格即可理解一个中型模块，无需老兵解释 | 4–8 周 |
| Top 20 模块持久上下文 | 每模块一页：边界、契约、已知坑、对接人、相关 ADR 链接 | 会话自动加载后，AI 首次回答的准确率显著提升（可做 A/B） | 3–4 周 |
| 追溯型 ADR 集 | 高风险模块的历史决策记录，含「今天还成立吗」判断 | 每份 ADR 由该模块原负责人签字确认 | 持续 |
| 特征测试网 | 高风险模块的黄金样本测试，含 SUSPICIOUS 标记 | 注入式 bug 检出率 ≥ 90%；语句覆盖率纳入看板 | 8–12 周 |
| 事实清单 | 第 03.4 节全部条目 | 下游消费者清单须经业务与运维双向签字 | 2 周 |
05路径选型：五条路对比与决策树
行业里真正可用的现代化路径只有五条。先把它们放在同一张表上，再走决策树排除。
5.1 五条路径的硬对比
| 路径 | 做法 | 风险 | 业务连续性 | 成功率证据 | 成本量级 |
|---|---|---|---|---|---|
| A 代码翻译 工具驱动 |
用转换工具 / LLM 把代码逐层升级到新语言版本与新框架，架构基本不动 | 中 依赖与方言陷阱多 | 阶段性停机或双跑 | 高（机械部分）。Amazon 自报：数万个生产应用 Java 8/11 → 17，单应用从约 50 天降至数小时 | 低–中 |
| B 增量绞杀 Strangler Fig |
在老系统前加路由层，一个能力一个能力切到新系统，老系统持续缩小直至退役 | 低 每片可停可回滚 | 零中断 | 高。对比数据：增量迁移超支/取消率 28%，大爆炸重写 76% | 中（可分期） |
| C 模块化单体 就地重构 |
不换代码宿主，但把内部按领域切成严格模块，模块间只走明确接口 | 低 | 零中断 | 中高。公认的「先看清真实边界，再决定是否切服务」的前置步骤 | 低–中 |
| D 全量重写 Big Bang |
冻结特性，从头建新系统，一次性切换 | 极高 | 长期双系统并行 + 一次性高危切换 | 低。失败率 70–88%（多来源，口径不一）；大型项目成功率 <10%（CHAOS 报告口径） | 高（中位 140 万美元量级 / 22 个月） |
| E 平台替换 / 重托管 Re-platform |
代码基本不动，换运行时/数据库/部署形态（如去 O、上容器） | 中 | 短窗口切换 | 中。中位 5 个月、成本量级 24 万美元（行业内统计）；但「换完还是老系统」 | 低 |
5.2 决策树
5.3 目标架构：为什么推荐模块化单体而非微服务
行业统计里最刺眼的一个数字：单体 → 微服务的中位成本约 250 万美元、周期 18–36 个月，成功率约 40%。而模块化单体的核心价值在于：它让你在不付微服务运维代价的前提下，先看清真实的领域边界。
模块化单体的定义与收益
- 定义：单一可部署应用，内部按领域切成严格模块，每个模块拥有自己的领域切片（合同 / 履约 / 结算 / 对账 / 经营指标…），模块间只通过明确接口交互，禁止伸进对方内部。
- 数据库通常仍然共用，但表按模块分组，跨模块泄漏被主动遏制。
- 运维简单：一套部署管道、一个运行时、协调成本远低于服务集群。这对尚不具备成熟 SRE / 可观测 / 值守体系的团队是关键优势。
- 暴露真实边界：当你在单体内部强制模块边界时，会看到哪些模块总是一起改、哪些藏着隐性业务规则、哪里真的需要自治——这些信息在拆分前是拿不到的。
- 给未来留门：模块边界清晰后，若某个模块确有独立扩容或独立交付需求，再单独抽出为服务，代价远低于盲目先拆。
什么信号才支持真的拆服务
- 某个模块出现明显的独立扩容压力（不是均匀的）
- 某个模块需要独立的交付节奏（不同团队、不同发布窗口）
- 领域边界已经清晰且稳定
- 团队具备分布式系统的运维成熟度：CI/CD、监控、自动化测试到位
- 有真实的业务理由，而不是技术趋势
判据：六条里少于三条成立时，拆服务带来的运维复杂度会吃掉收益。你当前的状态大概率是 0–1 条。
5.4 工具与 AI 的分工：什么交给机器，什么必须交给人
这是整个选型里最实用的一张表。核心原则：确定性的重复改动交给确定性工具（recipe / AST 转换），需要判断的地方才用 AI，架构与领域设计永远由人主导。
| 任务类型 | AI / 工具适用度 | 推荐手段 | 说明 |
|---|---|---|---|
| 替换废弃 API | 高 | OpenRewrite recipe | 确定性、可重复、零幻觉 |
| 升级重复的依赖 | 高 | OpenRewrite + 依赖矩阵 | 机械劳动，工具比 LLM 更可靠 |
| 生成测试 | 高 | LLM + 特征测试框架 | 但期望值必须来自实际执行 |
| 解释陌生类 / 模块 | 高 | 知识图谱 + LLM | 第零步的核心收益 |
| 重构重复代码 | 高 | LLM + 人工评审 | 需要「符合本仓库约定」的判断 |
| 更新配置 | 高 | 规则引擎 + LLM 兜底 | 注意属性重命名会静默失败 |
| 应用服务器模式转换 | 中高 | LLM + 集成测试 | 需要大量回归验证 |
| 单体边界分解 | 中 | 人主导 + AI 辅助分析 | AI 提供依赖证据，人做边界决策 |
| 领域架构重设计 | 人主导 | 人 + Event Storming | AI 无法承担业务判断 |
| 目标架构定义 | 人主导 | 架构委员会 | 涉及组织与长期取舍 |
AI 与代码图谱的实证效果（可作为立项依据）
有一项针对企业级代码迁移的对比研究值得注意：标准向量 RAG 与分层上下文驻留图（HCRG，基于 AST + 属性图 + 上下文缓存）相比，后者在多项指标上显著更好——API 幻觉率从 56.4% 降至 16.2%，依赖解析质量从 34.8% 升至 65.9%，父子一致性从 26.7% 升至 45.5%。代价是引入了一定的「防御性过度设计」（圈复杂度一致性从 71.6% 降到 46.7%）。
这条证据同时说明两件事：① 图结构检索对代码迁移是实质性的改进，不是噱头；② 它会带来新的副作用（过度抽象），需要人工评审兜住。
06行为迁移工程：把「等价」变成可证明的工程动作
这一章是本报告的技术核心。它解决的问题是：当新老两套代码结构完全不同时，你凭什么说新系统是对的？行业里最成熟的公开答案是蚂蚁在支付宝生活缴费 60 万行系统上的双 Loop 体系——它的规模、技术栈、业务密度与你的系统高度可比，因此本报告把它作为主要参照。
6.1 起点：把重构的验收标准从「代码」换成「行为」
传统交付方式——代码评审 + 补充用例 + 上线观察——只能发现局部实现问题，无法证明新系统在预期业务边界内保持了老系统的关键行为。原因很直接：代码评审通过、生成用例 PASS、覆盖率上升，这些都只说明「部分实现得到了检查」，不能证明「目标业务分支真的被执行过」。
因此需要换一个可计算的等价性定义：
6.2 双 Loop：提取什么，验证什么
两个 Loop 相互校验，各自回答一个不可省略的问题。
6.3 路径压缩：从上千分支到可管理的场景集
以合同域为例：合同类型 × 机构差异 × 状态 × 权限 × 时点 × 特殊条款，组合爆炸。行业公开案例中的对照数字是「2B 侧 600+ 技术接口、千家机构异构；单接口分支超 8000 个」。你的系统不会更简单。
压缩策略（按优先级）：
- 等价类合并：把「同一个
<if>分支内、参数取值不同但走完全相同的执行路径」的输入合并为一类。判据不是参数值，而是最终执行到的路径标识。 - 决策路径覆盖优先于参数覆盖：目标不是覆盖参数空间，而是覆盖决策路径集合。这直接把问题从「指数级」降到「分支数级」。
- 真实流量反哺：从生产日志里聚类高频路径，用真实分布决定压缩后的场景权重。生产流量天然包含那些没人想得起来的边缘场景——这是它比人工设计用例强的地方。
- 高价值低频场景单独保留：金额、结算、税务相关路径，哪怕一天只跑一次，也必须单列。低频高价值场景正是灰度放量后翻车的高发区。
必须警惕的「假覆盖」（False Coverage）
这是 AI 生成用例最危险的失败模式：用例看起来覆盖了目标分支，覆盖率指标上升了，但实际执行路径发生了偏移，目标分支从未被真正执行。
典型表现：AI 根据代码文本推理出「这段逻辑应该走 A 分支」，于是构造了一个看起来能触发 A 的输入；但由于上游某个校验先拦住了请求，实际执行到的是 B 分支（或提前 return）。测试 PASS，覆盖率 +1%，业务行为完全没有被验证。
破解手段只有一个：在 Loop 2 里采集「实际执行路径」并与预期路径比对，而不是只看返回值。这要求新系统具备运行时路径埋点能力——这属于第 08 章的 Harness Engineering 范畴，必须在试点阶段就建设，不能等。
6.4 影子流量与差分验真
场景回放解决的是「已知路径的等价性」；影子流量解决的是「未知路径的覆盖率」。两者互补，缺一不可。
6.5 差异治理：把差分结果变成发布决策
差分结果的用途不是「报告」，而是决策。建议把差异按四级分类，并为每一级预设动作：
| 差异等级 | 典型情形 | 预设动作 | 决定权 |
|---|---|---|---|
| L1 行为缺失 | 老系统产生了副作用（写流水 / 触发流程），新系统没有；或反向 | 立即阻断，不计入差异率统计，直接定位 | 工程负责人 |
| L2 结果不一致 | 核心返回字段值不同（金额、状态、单号、日期） | 阻断放量，逐个定位后重新验收 | 工程 + 业务双签 |
| L3 非核心差异 | 日志文本、中间态字段、非业务性排序 | 必要时显式配置忽略规则（须记录理由），否则视为缺陷 | 工程负责人 |
| L4 已知历史缺陷 | 老系统 13 年积累的、被业务绕过的错误行为 | 按老系统行为复制，纳入「待修复清单」单独排期，不在迁移期修 | 业务负责人 |
6.6 一条重要的反直觉纪律
不要在迁移阶段要求 AI「优化」
给 AI 的指令必须是范围受限、输出格式已定义、运行环境已锁定、不得引入任何「改进」的。原因：遗留系统的现有行为就是规格——会计流程可能是围绕某个历史误差建立的，下游系统可能依赖某个看起来错误的排序。
公开案例中的做法值得照抄：把测试集与历史错误记录一起塞进上下文，让模型知道「这段代码为什么长成这样」；用文件级流水线（读一段 → 生成新类 → 编译 → 跑测试 → 报 diff），只有 diff 数超过阈值时才叫人。该案例中 AI 仍然幻觉出两处新的 off-by-one 错误——是被静态分析步骤拦下的。
结论：AI 复制老 bug 是它理解了契约的证明；测试网才是用来确认它没有发明新 bug 的。真正的风险不是 AI 抄错了，而是它悄悄生成了新的错误，同时把老代码显得很干净。
07数据层攻坚：三轨数据访问与 Oracle 的正确打开方式
如果你只从这份报告里拿走一条战略建议，就是这一条：把「应用现代化」和「数据库替换」解耦，不要同时做。这是唯一能让你把项目风险从「乘积」降成「相加」的操作。
最重要的一个战略判断：数据库可以延后
绝大多数「AI 重写 + 去 O」项目失败，是因为把两个独立的极高风险变量绑在了一起：既要重构 73 万行应用逻辑，又要重建数据模型和全部 SQL。任何一个出问题都无法归因，回滚也没有干净的边界。
建议路径：
① 第一阶段（0–18 个月）：新系统继续使用 Oracle。数据访问层用标准 JDBC / JPA / SQL 抽象隔离，SQL 保持 Oracle 方言。目标是先把应用逻辑与行为等价性做出来。
② 第二阶段（18 个月后）：当新系统稳定运行、且已建立起完整的 SQL 清单与影子验证能力后，把数据库替换作为一个独立的、有明确边界的项目来做，届时它已经从「600 个未知」变成了「一份已知清单」。
只有一种情况例外：合规或授权成本构成硬约束。如果去 O 是政策要求而非技术选择，那它有自己的时间表，此时应把数据库替换当作独立工作流并行推进，但绝不让它成为应用重构的前置依赖。
7.1 Oracle 专有构造：转换难度分三档
公开工具链的实测边界很明确：自动化工具能完整转换 90%+ 的数据库代码，剩余不到 10% 需要人工。问题在于，这 10% 吃掉了项目的大部分时间。所以关键是提前知道这 10% 在哪——工具的评估报告（迁移成本评分）就是这张地图。
7.2 工具链选型
| 工具 | 定位 | 自动转换率 | 适合与不适合 |
|---|---|---|---|
| ora2pg | 开源（Perl），schema + 部分 PL/SQL | schema 全覆盖；PL/SQL 仅简单逻辑 | 适合 预算敏感、目标 PG 系；不适合 复杂 PL/SQL、CONNECT BY |
| AWS SCT / DMS | 商业，schema 转换 + 数据搬迁 + CDC | 完整转换 90%+ 数据库代码 | 适合 云迁移、需要一体化的全量+CDC；不适合 不想上云的场景 |
| 国产库迁移链 金仓 / OceanBase 等 | 信创场景，含 Oracle 兼容模式 | 厂商自报 80–95%（视产品路线） | 适合 有信创要求；注意 高级特性（UTL_FILE、CONNECT BY 等效性）仍有差异，需实测 |
| Istio / 网关流量镜像 | 流量复制，不做数据转换 | 不适用 | 适合 影子验证阶段；与上述工具互补而非替代 |
| LLM 辅助重写 | 处理第二 / 三档的人工部分 | 视上下文质量而定 | 适合 语义重写 + 生成对照测试；严禁 单独作为迁移唯一手段 |
7.3 数据切换三阶段
7.4 508 个 mapper XML 的处理工序
这是你系统里最特殊的一块，公开方法论很少直接覆盖。建议按下列工序处理：
- 解析为结构化数据（而非文本）。把每个 mapper 解析为：语句 ID、类型、引用表、引用字段、动态分支树、Oracle 专有函数清单、结果映射。产出一份可查询的台账，这是后续一切自动化的输入。
- 区分「查询语义」与「实现细节」。动态
<if>/<choose>的分支条件属于业务语义，必须逐条确认并纳入 Golden Set 的场景枚举；而<where>拼接、字段别名、排序写法属于实现细节，可以自由重写。 - 按「引用表」而不是「按文件」聚类。同一个业务实体（如合同主表）往往被几十个 mapper 交叉引用。按表聚类能让迁移后的模块边界自然浮现，也是模块化单体划分的数据侧依据。
- 用真实执行计划做交叉验证。从 Oracle 的共享池 / AWR 里导出历史 SQL 的实际执行记录与执行计划，与静态解析结果比对。静态解析会漏掉运行时动态拼接的 SQL——而这正是最容易出生产事故的部分。
- 生成对照测试。对每个语句，用老库数据构造输入、捕获输出，形成语句级的等价性测试。这比端到端测试便宜得多，且能精确定位差异。
7.5 关于 oracle.dmp 的使用建议
它是你最重要的资产
- 数据字典是唯一的事实来源。表结构、约束、索引、外键、列注释、分区定义——这些决定了真实的数据模型，而不是代码里的假设。
- 列注释常含业务语义，是业务规则挖掘的免费线索。
- 历史数据本身是行为的证据：某些字段的取值分布能反推出被遗忘的业务规则（例如某个状态码只在特定机构出现）。
- 导入一份到隔离环境，作为只读分析库与测试数据来源。
使用它的三条安全底线
- 不得上传到外部 LLM 服务。含真实合同、金额、人员数据的 dmp 属于高敏数据。需要 AI 辅助分析时，只发送脱敏后的结构（DDL + 注释 + 字段统计）。
- 导入环境必须网络隔离，与生产不互通，避免误连。
- 建可重复的脱敏管道：结构保留、值替换、比例保持（分布特征不丢）。这同时解决了「测试数据不真实」和「数据不出域」两个问题。
一个反直觉的提醒
不要试图用 AI 直接「读懂」整个 dump。dmp 是二进制导出格式，不是分析载体。正确顺序是：先导入 → 用数据库自身的数据字典视图导出结构元数据 → 用 SQL 查询导出字段级统计特征 → 把这些结构化、脱敏、体积可控的产物喂给 AI。
这一步做对了，AI 就能回答「哪些表是核心事实表」「哪些字段事实上是枚举且取值有哪些」「哪些外键关系已失效」——这些是模块划分的直接依据。
08AI 工程体系：窄域智能体网络 + 闸门化授权
这一章回答一个具体问题：AI 到底以什么方式接入你的工程流程？答案是：不要追求「一个全能智能体」，而要建一张被既有流程闸门包住的窄域智能体网络，每个只压缩一处瓶颈。
8.1 为什么是「窄域网络」而不是「全能智能体」
全能智能体的幻想
「让 AI 读完整套 73 万行代码，然后重写一个系统」——这是个人小项目的心智模型（vibe coding），放到巨系统里必然失败：
- 上下文装不下（500 万行级别的仓库无法整体进入任何上下文窗口）
- 无法归因（一次跑出来的东西错了，你连是哪一步错都不知道）
- 无法回滚（大块产出没有可回退的粒度）
- 无法信任（没有人能审阅它做的一切）
窄域网络的实际形态
每个智能体只做一件事，且必须同时满足三个条件（巨系统上智能体的安全三件套）：
- 窄——职责边界清晰，输入输出格式固定
- 可评测——有自动化手段判断它做得好不好
- 可回滚——产出是离散的、可撤销的变更单元
符合这三条的典型窄域：依赖升级、API 弃用替换、测试生成、API 文档生成、变更日志、只读问答、根因分析、**SQL 语句级等价性测试生成**。
8.2 四阶段授权模型：智能体永远不绕过人类闸门
这是整个落地路径里最容易翻车的地方：不能让智能体绕过现有的评审、回归、发布闸门。一次幻觉就可能冻住整条发布线。正确做法是借绞杀者模式对智能体也做渐进式授权：
一条关于「假自动化」的判断标准
「95% 准确、剩下 5% 还要人审」叫假自动化——因为那 5% 仍然需要人的注意力，而人的注意力是稀缺资源，它依然是瓶颈。只有把最后那 5% 也推到可自动判定，人力才被真正释放。
因此本项目中「合格」的智能体不是「写得像」，而是「错了能被自动发现」。这也是为什么第 06 章的验证体系和本章的 Harness 建设，优先级高于任何编码类智能体。
8.3 Harness Engineering：把验证环境改造成 AI 可用的
这是公开案例里一个很容易被忽略但极其重要的发现：传统验证环境对 AI 的适配性很差。在一项 60 万行系统的公开实践中，AI 在传统验证环境下的验证成功率仅约 60%，且单次有效验证耗时 2–3 小时。这意味着智能体大部分时间浪费在等待与误判上。
解法是专门为 AI 重建验证基础设施（Harness Engineering）。以下是可直接照做的五项改造：
| 改造项 | 传统做法（对 AI 不友好） | AI 友好做法 | 预期收益 |
|---|---|---|---|
| 调用方式 | 人工点界面 / 填表单触发 | 提供可编程接口（命令行 / API），智能体可直接调用 | 从「人驱动」变「智能体驱动」 |
| 反馈时延 | 一次有效验证 2–3 小时 | 环境常驻 + 增量构建 + 并行执行，压缩到分钟级 | 迭代次数提升一个数量级 |
| 输出格式 | 人读的日志文本 | 结构化输出（JSON：通过/失败、差异字段、证据链接） | 智能体能自己判断对错 |
| 环境状态 | 手工准备数据，状态漂移 | 环境快照 / 可重置，每次验证从干净状态开始 | 消除「上次跑的残留」类伪失败 |
| 失败归因 | 只报「用例失败」 | 附上实际执行路径 + 期望路径 + 差异字段 | 同时解决假覆盖问题（见 6.3） |
8.4 指标设计：防止被好看的数字骗过去
这是本报告里最能直接用在汇报材料上的一张图。
8.5 六条防幻觉机制（可直接写进开发规范）
- 证据强制。任何 AI 给出的结论必须附代码位置 / 执行证据 / 数据出处。无法给出证据的结论一律视为推测。
- 路径校验而非结果校验。验证「实际执行到了哪条路径」，而不只是「返回了什么」。这是防假覆盖的唯一手段（见 6.3）。
- 确定性优先。能用工具链 recipe 解决的不走 LLM。LLM 只处理需要判断的部分（见 5.4）。
- 变更原子化。每次变更必须小到可被一次代码评审完整审阅。大块产出一律拆分。
- 负样本集。除了「正确样本」，还要维护一组「已知错误样本」，定期跑一遍确认智能体能识别它们。没有负样本集的评测是自欺。
- 私有留存集。不要用公开基准判断你的智能体行不行。从你自己的仓库里切出最近 6–12 个月的内部提交作为私有评测集——这个时间段的内容在任何模型的训练语料里都不存在，天然免疫污染。
09组织与治理：决定成败的是这些「非技术」的事
行业统计反复指向同一个结论：大规模现代化的失败主因是组织性的，不是技术性的——范围从「替换」膨胀成「重建」、特性冻结被业务打破、懂老系统的人流失、缺少明确的所有权。这一章处理的就是这些。
9.1 五个必须明确的角色
| 角色 | 唯一职责 | 关键授权 | 常见错误配置 |
|---|---|---|---|
| 现代化总负责人 单一责任人 |
对整体节奏、范围与对外承诺负责 | 可否决范围膨胀；可暂停任一试点 | 设成委员会 → 无人负责，决策瘫痪 |
| 业务行为权威 业务侧 |
裁决「这个行为是业务规则还是历史缺陷」（即 L4 差异的判定权） | 对差异分级有最终裁定权 | 由工程代劳 → L4 差异被当成 bug 顺手改掉，引入隐性回归 |
| 知识守门人 新增角色 |
维护代码知识图谱、决策日志、检索管道、上下文清理 | 对文档质量有门禁权（无 ADR 的重构 PR 不得合入） | 无人负责 → 图谱三个月后就过期，检索质量崩塌 |
| 验证体系负责人 新增角色 |
Golden Set、影子流量、差分引擎、Harness 建设 | 裁定「差异率是否达标」 | 挂靠在测试团队下 → 被视为「测试工作」而非工程地基，投入被砍 |
| 平台架构师 | 目标架构、模块边界、平台语义规格（reed 五组件） | 模块边界最终裁决 | 让 AI 或外部顾问决定边界 → 边界与业务不一致，后续全盘返工 |
9.2 三条不可协商的合规红线
红线一 · 数据不出域
oracle.dmp 与任何含真实合同、金额、人员数据的样本，不得上传至外部大模型服务。需要 AI 辅助时，只发送脱敏后的结构（DDL + 注释 + 统计特征）与合成样本。这是硬约束，不是建议。
红线二 · 智能体最小权限
智能体的权限按第 08 章的四阶段模型逐级授予，默认只读。生产环境的写权限、数据库 DDL 权限、发布权限，必须有独立的、可审计的授权流程。零信任 + 沙箱执行是准入条件，不是加分项。
红线三 · 可审计的产出
每一条 AI 生成的代码都要能追溯到：哪个智能体、什么提示、哪些上下文、谁审阅、依据什么证据合入。审计链断了，后面对任何差异都无法归因。
9.3 投资配比：真正的编码只占四分之一
这是最容易被管理层误解的一条。不要把预算全部按「开发人天」来规划——大规模现代化的成本结构与传统开发完全不同：
9.4 向上汇报的正确口径
应该这样报
- 「已建立代码知识图谱，覆盖 X% 核心模块，变更影响分析自动回答准确率 Y%」
- 「特征测试网锁定 Z 个关键业务行为，注入式缺陷检出率 90%+」
- 「试点域在影子流量下运行 N 周，L1/L2 级差异归零」
- 「AI 独立完成占比从 0% 提升到 M%，事故率未上升」
不要这样报
- 「AI 生成了 80% 的代码」——这是指标 A，不反映能力边界
- 「重构进度 60%」——没有定义「完成」的口径，这个数没有意义
- 「节省了 N 人天」——在人天不是瓶颈的项目里，这个数会被追问倒
- 「试点很成功」——没有差异率与覆盖率数据的成功不是证据
10路线图：90 天 / 12 个月 / 36 个月
节奏设计的核心原则来自公开实践的经验教训：前 12 个月几乎不碰组织结构和发布流程，所有 AI 动作都被既有闸门包住。这样「不影响其他流程顺畅运行」这条红线才始终成立。
10.1 全景甘特图
10.2 第一个 90 天：可直接执行的动作清单
第 1–30 天 · 摸清家底
- 导出并导入 Oracle 数据字典，产出表 / 字段 / 约束 / 索引 / 注释的全量清单
- 静态解析 508 个 mapper XML，产出 SQL 台账（语句数、动态分支数、引用表、Oracle 专有构造计数）
- 导出存储过程 / 触发器 / 序列清单与依赖关系
- 枚举对外接口、批处理作业、报表、导出的全量清单
- 盘下游消费者：谁在读你的库 / 调你的接口（这一步最容易漏，也最致命）
- 拉近 12 个月变更热点 + 生产事故清单，生成「风险—价值」四象限
第 31–60 天 · 选点与准备
- 基于四象限选定试点域（建议：价值高 + 耦合面小 + 可端到端闭环）
- 为 reed 五组件写首版平台语义规格（先写 grail 与 pigeon）
- 搭代码知识图谱 MVP：Java AST + mapper SQL 子图 + 调用图
- 把最痛的 20 个历史决策补成 ADR（只做高风险的，不求全）
- 为试点域写第一批特征测试（目标：锁定 10 条核心业务行为）
- 建立私有评测集：从自有仓库切最近 6–12 个月的提交，作为智能体能力的真实标尺
第 61–90 天 · 首个闭环验证
- 把验证环境改造成可编程调用（Harness 五项改造）
- 对试点域的一条业务闭环做 PERS 建模，产出首个 Golden Set
- 把这一条闭环用新架构重写（只做这一条，不扩范围）
- 搭最小影子流量链路，在真实流量下比对
- 产出第一份差异报告，跑完 L1–L4 分级流程
- 复盘并向管理层汇报「AI 独立完成占比」与「L1/L2 差异率」
90 天结束时的成功标准
不是「写完了多少代码」，而是三件事：
① 事实清单完整——你知道系统有多少接口、多少表、多少下游；
② 一条业务闭环的 PERS 等价性被证据证明——不是「跑通了」，而是「差异率为零且证据可查」；
③ 验证成本显著下降——从「2–3 小时一次」降到「分钟级一次」。
这三条达成，才支持你向管理层申请扩大投入。任何一条没达成，都不应该进入第二阶段——这不是保守，这是把失败成本锁在 90 天以内。
10.3 成熟度阶梯：你的目标不是一步到位
11反模式清单：十五条会让你翻车的做法
建议把这一章单独打印贴出来。每一条都来自公开案例中的真实失败，而不是理论推演。
11.1 战略层（4 条）
| 反模式 | 症状 | 修正 |
|---|---|---|
| ① 范围膨胀 | 从「替换合同模块」变成「顺便重做权限、重做界面、上微服务、换数据库」。范围先翻倍、再翻三倍。 | 锁定功能对等。新需求一律排到迁移完成之后。任何在迁移期加进来的「新想法」都要走独立的、被否决权覆盖的审批。 |
| ② 大爆炸切换 | 单一切换日，所有风险（技术、运营、组织）压在同一天。没有部分回滚，只有 go-live 与事后复盘。 | 改走绞杀者 + 可回滚切片。每一片在并行运行窗口内验证，出问题回滚是路由切换而非数据修复。 |
| ③ 双高风险绑定 | 应用重构与数据库替换同时推进。出错无法归因，回滚没有干净边界。 | 解耦。第一阶段新系统继续用 Oracle（见 07 章）。数据库替换独立立项、独立排期。 |
| ④ KPI 选错 | 用「AI 生成代码占比」作为项目健康度指标。数字漂亮，实际瓶颈毫无改善。 | 改用AI 独立完成占比 + L1/L2 差异率 + 验证反馈时延三个指标（见 8.4）。 |
11.2 工程层（7 条）
| 反模式 | 症状 | 修正 |
|---|---|---|
| ⑤ 让 AI 通读后重写 | 「把整个仓库喂给模型，让它产出新系统」。上下文装不下、无法归因、无法回滚、无人能审。 | 拆成窄域智能体网络，每个只压缩一处瓶颈，且必须窄 / 可评测 / 可回滚（见 8.1）。 |
| ⑥ 用 LLM 做机械转换 | 把本该用 recipe 完成的 API 替换、依赖升级交给 LLM 逐文件处理。成本高、结果不可复现。 | 确定性优先：OpenRewrite 类 recipe 打底，LLM 只处理需要判断的部分（见 5.4）。 |
| ⑦ 迁移期顺手修 bug | 发现老系统一个 13 年的错误行为，顺手「修好了」。业务侧随之上报严重回归。 | L4 差异原样复制，纳入待修复清单单独排期。迁移期同时引入两个变化会让差异归因失效（见 6.5）。 |
| ⑧ 用覆盖率当验证证据 | 「生成用例全 PASS，覆盖率 85%」，但目标业务分支从未被执行——假覆盖。 | 校验实际执行路径，而非只看返回值。要求验证环境输出「实际路径 vs 期望路径」（见 6.3 / 表 7）。 |
| ⑨ 期望值来自 AI 推理 | 让 AI「看着代码推出预期返回值」，然后以此为测试基线。记录的是 AI 的理解，不是系统行为。 | 所有期望值必须来自实际执行。生产日志是最佳样本来源——真实、且天然包含边缘场景。 |
| ⑩ 只分析一轨 | 只做 Java 侧分析，漏掉 508 个 mapper 的动态 SQL 分支与存储过程里的业务规则。 | 三轨全覆盖：Java / mapper XML / 数据库对象。任何单轨分析都会漏行为（见 图 4）。 |
| ⑪ 忽视下游消费者 | 新系统行为「正确地」变了，但某个没人记录的下游系统被打破。这被行业统计列为现代化项目超支的首要原因。 | 开工前完成下游消费者清单，由业务与运维双向签字（见 3.4）。契约变更走兼容层，不直接破坏。 |
11.3 治理层（4 条）
| 反模式 | 症状 | 修正 |
|---|---|---|
| ⑫ 责任委员会化 | 设「现代化推进委员会」，重大决策集体表决。结果是无人对节奏负责，决策周期超过迭代周期。 | 单一责任人对整体节奏负责，委员会只做咨询（见 表 8）。 |
| ⑬ 文档无主 | 知识图谱建得很漂亮，三个月后无人更新，检索质量崩塌，团队重新回去问老兵。 | 设知识守门人角色，并给它门禁权：无 ADR 的重构 PR 不允许合入。 |
| ⑭ 敏感数据外流 | 把 oracle.dmp 或含真实合同 / 金额的样本传给外部大模型服务做分析。 | 建可重复的脱敏管道：结构保留、值替换、分布保持。只传结构与合成样本（见 9.2）。 |
| ⑮ 一次给足权限 | 直接让智能体持有写权限与发布权限，跳过渐进授权。一次幻觉冻住整条发布线。 | 四阶段渐进授权，默认只读，逐级开放，永不绕过既有闸门（见 图 12）。 |
这十五条的共同结构
拆开看，它们其实是三类错误的变体：① 把「理解系统」这件慢活当成可以跳过的前置工作；② 把「验证」当成交付后的动作而不是交付的前提；③ 用好看的过程指标替代真实的能力指标。
换句话说——所有这些坑的共同解法，都可以归结为本报告第 02 章那一句话：不要优化「写代码」这条最快已经很快的路径，去把那些又慢又贵的路径变便宜。
12结论与判断
12.1 六条明确判断
以下标注为「观点」的部分是我的判断，不是行业共识，请按此权重理解。
判断一 · 不要让「重写」成为立项词 观点
立项文件里出现「重写」二字，就会不断吸引范围膨胀。把它写成「行为迁移」或「渐进现代化」，不只是措辞——它会改变团队对「完成」的定义。
判断二 · 第零步是唯一不可压缩的环节 强观点
如果预算只够做一件事，做知识图谱 + 平台语义规格。它本身就能立刻降低新人上手成本、降低变更风险、减少对特定人员的依赖——即使后续不再推进重构，它也是净收益。
判断三 · 数据库先不动 强观点
除非有硬性合规要求，第一阶段保留 Oracle。把两个高风险变量解耦，是把项目从「乘法风险」降成「加法风险」的唯一操作。这一条能显著提高项目存活率。
判断四 · 试点要选「能端到端闭环」的，不是「技术最干净的」 观点
试点的目的不是验证技术可行性，而是验证整套方法（提取 → 重建 → 差分 → 切流）能不能走通。一个技术简单但走不通全链路的试点，几乎没有价值。
判断五 · 模块化单体优于微服务 观点
在团队尚不具备成熟 SRE 与可观测体系时，微服务的运维复杂度会吃掉全部收益（行业成功率仅约 40%）。先做模块化单体，看清真实边界，再让「是否拆服务」由真实压力而非趋势决定。
判断六 · 停在 L2 也是一个可接受的结局 观点
如果第零步做完，你已经有知识图谱、决策日志、特征测试网——即使不继续重构，这套资产的收益也是实在的。把第零步当作一个可以独立收口的成果，反而更容易推动它获得预算。
12.2 如果你只记住三句话
12.3 参考来源
按证据类型分组。浏览本报告时请对照正文里的证据标注理解每个数字的可信度：一手研究 > 行业调查 > 单一案例 > 厂商自报 > 建模。
一手研究与学术论文
- Ziftci, C., Nikolov, S., Sjövall, A., Kim, B., Codecasa, D., Kim, M. Migrating Code At Scale With LLMs At Google. FSE Companion '25, pp. 162–173.（arXiv:2504.09691）— 39 项迁移、595 个变更、93 574 次编辑，74.45% 变更与 69.46% 编辑由 LLM 生成；总耗时降约 50%。
- Jimenez, C. E. et al. SWE-bench: Can Language Models Resolve Real-World GitHub Issues? ICLR 2024；及其 Verified / Pro 变体（SWE-bench Pro 由 Scale AI 构建）。
- METR. Measuring AI Ability to Complete Long Tasks（arXiv:2503.14499）— 前沿智能体可自主完成的任务时长约每 7 个月翻倍。
- Beyond Vector Similarity: Hierarchical Context-Aware Graph RAG vs Standard RAG in Enterprise Code Migration（arXiv:2609.12464）— API 幻觉率 56.4% → 16.2%，依赖解析质量 34.8% → 65.9%。
- Ulrich, W. & Newcomb, P. From COBOL to Business Rules — Extracting Business Rules from Legacy Code. — 源码中约 20–30% 与业务规则相关；IRS 重写项目损失约 30 亿美元，根因是业务知识流失。
- Feathers, M. Working Effectively with Legacy Code. Prentice Hall, 2004. — 特征测试（Characterization Test）与接缝（Seam）概念的原始出处。
行业调查与基准统计
- NextGen Coding Company. Legacy Modernization Benchmark 2026. — 大爆炸重写超支/取消率 76%，增量迁移 28%；中位成本与周期对比。
- Standish Group CHAOS Report（转引）— 大型项目成功率低于 10%；31% 的 IT 项目在交付任何功能前被取消。
- DX（Developer Experience）开发者报告与 2025 DORA 报告（转引）— 约 90% 开发者使用 AI、80% 自认提效，但真正合入主干的 AI 代码约 22%。
- Presenc AI. Coding Agent Benchmarks 2026 / cowork.ink SWE-bench Explained / genalphai SWE-bench Pro vs Verified — 生产环境真实 PR 采纳率约 35–50%；Senior SWE-Bench 高质量解率约 24%。
云厂商与咨询机构方法论
- Microsoft Azure Architecture Center. Strangler Fig 模式（含数据库绞杀三阶段图示与回滚窗口说明）。
- AWS Prescriptive Guidance. Strangler fig pattern（Transform / Coexist / Eliminate 三阶段）。
- AWS Documentation. Oracle database schema conversion — AWS SCT 完整转换 90%+ 数据库代码，剩余不到 10% 需人工。
- AWS DevOps Blog. Amazon Q Developer just reached a $260 million dollar milestone — 数万个生产应用 Java 8/11 → 17，节省 4 500 开发年，2.6 亿美元年度成本节省；单应用从约 50 天降至数小时（厂商自报）。
- Huawei. Cloud-Native Meets AI-Native: Huawei Empowers Banks to Build a Resilient Core（2026）— CodeArts 编码智能体平台支撑主机下移，交付效率提升约 50%（厂商自报）。
- Thoughtworks. Technology Radar Vol. 33 / Vol. 34（2025 / 2026）— Vol.33 指出生成式 AI 在理解遗留代码库上的成功应用与 AI 反模式；Vol.34 提出「认知债」与「给编码智能体上缰绳」（spec-driven development、mutation testing）。
- Infosys. Modernizing enterprises: The power of generative AI in code migration — 航空与能源行业案例；八条大规模使用生成式 AI 的建议，含「用规则驱动的确定性与生成式 AI 互补」。
- Techment / Sphere / Coderio / 10Pearls / Dextralabs 等 2026 年企业现代化指南（用于交叉印证趋势判断，非一手数据来源）。
工程实践与一线案例
- 蒋宇（蚂蚁集团 / 支付宝）. 60 万行巨石应用 AI 重构的可验证交付工程. QCon 上海。「Vibe Coding 时代的新质量债」专题。本报告第 06 章主要参照：PERS 建模、Case-Forge 路径压缩、Bubble 回放、Golden Set、影子流量四坑、验证成功率约 60% 与单次验证 2–3 小时。
- OpenCurve. 当 AI Coding 撞上巨型遗留软件 —— 屎山代码全生命周期 AI Agent 体系的落地路线图. 墨天轮, 2026-07。本报告第 08 章四阶段授权模型与第 02 章阿姆达尔定律框架的主要参照；含 Meta 4 100+ 遗留任务中 AI 独立可解约 5%、Google 新代码 AI 生成占比 25%→75%、Microsoft 2030 年 C/C++ 现代化目标等数据（多为转引）。
- Synapse Studios. Characterization Testing（对 Feathers、Fowler、Bache、Cartwright/Horn/Lewis《Patterns of Legacy Displacement》的综合）。
- BPM Institute. Mining Rules From Code: Plan It Well / Extracting Business Rules from Legacy Systems — 业务规则挖掘的六步项目规划法。
- Google Cloud. Mainframe Assessment Tool — Extract business rules — 用 Gemini 智能体把遗留代码逻辑提取为 Gherkin 格式业务规则与可读规格（Objective / Functional Requirements / User Journeys / Glossary）。
- Pretius. Escaping the Oracle ecosystem: Migrating Oracle Forms to PostgreSQL — Oracle→PostgreSQL 工具对比表与 SQL 构造转换清单（CONNECT BY / ROWNUM / NVL / DECODE / ROWID / (+) 外连接 / SYNONYM）。
- Ispirer / labhub / knowledgelib 的 Oracle→PostgreSQL 2026 迁移指南 — PL/SQL 包需重构为 schema、包级变量需重新设计为会话状态、空串与 NULL 语义差异、事务边界差异。
- 华为河图 / 金仓 / CSDN 社区关于央国企 Oracle 国产化替代的实践记录 — 1 200 余处语法差异、双写运行三个月、深层特性依赖（统计信息收集机制）导致查询计划抖动。
- 关于流量镜像与差分验证的工程记录（Istio 流量镜像实践、模型网关影子对比实践）— 异步 fire-and-forget、全量镜像优于抽样、按业务标签拆分差异统计的关键性。
工具链
- OpenRewrite / Moderne — Spring Boot 版本升级 recipe 链（
UpgradeSpringBoot_3_0至_4_0）、MigrateToJakartaEE10等确定性转换。 - ora2pg — 开源 Oracle→PostgreSQL 转换，含迁移成本评分（Simple / Medium / Complex）的评估报告。
- AWS SCT / DMS Schema Conversion / DMS — schema 转换 + 全量装载 + CDC 一体化。
- Tree-sitter + 图数据库（Memgraph / Spanner Property Graph / SQLite 图） — 构建代码知识图谱的通用技术栈；公开基准显示可支撑千万行级仓库的秒级结构查询。
- Istio / Envoy 流量镜像、approvaltests / Verify 系列、Testcontainers — 影子流量与特征测试的落地工具。
关于本报告数据可信度的说明
报告中的数字来自四类不同可靠度的来源，请分级理解：
① 一手研究（Google FSE 论文、SWE-bench、METR）——方法公开、可复核，可信度高，但样本多来自特定组织环境，外推需谨慎。
② 行业统计（CHAOS、现代化基准报告）——方向性参考价值高，但各机构口径不一，绝对值不可直接比较（例如「失败率 70%」中的「失败」可能指超支、延期或被静默取消）。
③ 单一案例（蚂蚁 QCon 分享、COBOL 迁移实测）——细节丰富、极具参考价值，但 n=1，不能当作普遍规律。
④ 厂商自报（AWS、华为、国产数据库厂商的 ROI 数字）——请按显著折扣理解，它们的主要价值在于证明「这件事有人做成了」，而不是证明「你能获得同样收益」。
本报告对你系统的一切具体建议（尤其是第 03、04、07 章），都建立在「未经验证的项目事实」之上——它们需要在第 10 章的前 30 天里被验证或推翻。