00摘要：九条核心论断
以下每一条论断都可以被证据证伪，报告正文即为论证。每条后附证据强度：一手案例 > 大样本调查 > 行业分析 > 单一实践。
「用 AI 全部重写一个全新系统」是本项目最大的风险，而不是解决方案。25 年重写史（Netscape、Borland、Chandler）表明大爆炸式重写默认失败——不是代码写不出来，而是旧代码里 13 年积累的未成文业务规则会静默丢失。证据强度：多案例交叉验证 + Gartner 预测过度押注生成式 AI 的迁移项目 70% 以上不达预期。
AI 真正改变的是「理解与翻译」环节的成本曲线，不是「验证」环节。一手案例显示代码考古、文档提取、测试生成提速 60–90%（Salesforce 33 个 API 迁移：231 人天 → 13 天；LG CNS：2913 个 API 99.1% 自动转换），但最后 10–15% 的业务规则人工验证不可压缩。证据强度：厂商一手案例，注意厂商有利益相关。
你们最大的资产不是 73 万行代码，而是系统 13 年来的实际行为。508 个手写 SQL、合同域 928 个文件、2013 年至今的生产修复，都是未成文业务规则的唯一载体。迁移第一步是「表征测试 + 双跑对账」把行为锁定成可执行的规约，之后才谈得上动代码。证据强度：工程方法论（Michael Feathers 表征测试 + 金融业影子运行实践）。
三轨数据访问是理解成本的最大黑洞，也是 AI 考古的第一切面。MyBatis 508 个手写 XML（业务规则的最大藏身处）+ reed-grail 元数据 ORM（规则在元数据和数据库对象里）+ Hibernate 3（pigeon 工作流专用）——业务规则散落三处，任何只读 Java 代码的考古都会漏掉一半以上。证据强度：基于系统画像的结构性推断 + CAST 死代码研究。
迁移顺序由业务域波次决定，不由技术栈决定。对 3412 个文件按业务价值 / 耦合度 / 变更频率做 A/B/C 分级：从边缘、高频变更的域试点，contract 域按子模块最后分批切换。金仓 A/B/C 分级迁移与 Salesforce 波次制都是可直接抄的作业。证据强度：厂商一手实践 + 单一案例。
目标架构首选「模块化单体」，微服务不是必选项。为 73 万行系统直接上微服务会放大「第二系统效应」；先按 DDD 边界做模块化（Maven 多模块 + 接口隔离），服务化按需演进。508 个 MyBatis XML 里的 SQL 大部分是可以复用的资产而非负债。证据强度：行业方法论（DDD + 绞杀者模式共识）。
AI 工程化的核心是「修流程，而不是修生成的代码」。Salesforce 与 Anthropic 的一手方法论一致：用规则文件（CLAUDE.md / markdown 规约）+ 阶段门 + 自动验证回路 + PR 反馈回写，让每一次失败沉淀进流程。无门禁的 AI 生成代码只是把技术债换成概率性缺陷。证据强度：厂商一手案例。
数据迁移是与代码重写同等重要的独立工程。oracle.dmp 不只是数据，里面有存储过程、视图、触发器和 grail 元数据——是第四条考古线索。迁移走「全量 + 增量同步 + 三级校验 + 单写双轨」路线，银行级验收线是校验通过率 99.99%、TPS 不低于旧库基线 95%。证据强度：厂商实践 + 银行案例。
组织因素比技术选型更能预测成败。对 78 个企业现代化项目的研究显示：技术改造与组织转型双轮驱动的项目 91% 达成业务目标，纯技术驱动的只有 43%。懂合同业务的专家必须全程坐在迁移闭环里。证据强度：学术研究（WJARR 2025，n=78，单篇期刊、中等强度）。
01你的处境：系统解剖与真实风险评估
先冷静地看清楚手里有什么。这套系统的技术栈确实老了，但它的真正价值和真正风险都不在「老」上。
1.1 规模画像
1.2 分层解剖
这套系统的特殊之处在于：业务代码只是冰山露出水面的一半，另一半藏在 reed 自研平台的元数据里。理解这一点对后面所有决策至关重要。
1.3 风险清单与真实紧迫性
| 风险项 | 等级 | 事实与影响 |
|---|---|---|
| JDK 1.7 已停止公开更新（2015 年起） | 高 | 十年无安全补丁，等保 / 审计 / 客户安全问卷都是硬伤；新依赖库全部无法引入。 |
| Spring 3.2 / Hibernate 3 EOL | 高 | 已知漏洞（如 Spring 相关反序列化类 CVE）不再修复；招不到也留不住会用这些栈的工程师。 |
| reed 平台知识集中在少数人 | 高 | grail / pigeon / brick 的设计意图只存在于原作者脑中（巴士系数 = 1–2）；这是比技术老 10 倍的风险。 |
| Oracle 许可与迁移被锁 | 中 | 许可成本与议价能力逐年恶化；若有信创要求则成为硬性约束。 |
| 业务规则未成文 | 中 | 13 年的需求变更、政策适配、客户特例全部沉淀为代码补丁，没有任何系统外文档能还原。 |
| 单体全量发布 | 低-中 | 若当前发布节奏尚可接受，此项不构成重写的充分理由——只构成模块化的理由。 |
一个关键自问：这套系统现在每月出几次生产事故？新需求交付周期多长？如果答案是「偶尔出事、改需求很痛苦但可控」，那么问题本质是演进能力受限，解法是受控迁移；如果答案是「随时可能崩溃、没人敢动」，解法是先做行为锁定（第 06 章）再谈其他。两种情况都不是「全部重写」。
02范式判定：为什么「推倒重来」是最危险的答案
「我有源代码和 dmp，让 AI 重写一个全新系统」——这个直觉必须先被认真质疑一次。过去 25 年，这种做法杀死公司的案例远多于成功案例。
2.1 Netscape 的教训：重写杀死的不是代码，是知识
1998 年 Netscape 决定将浏览器推倒重写：3 年没有任何有竞争力的版本发布，IE 吃掉市场，公司消亡。Joel Spolsky 2000 年的《Things You Should Never Do》把它定义为「软件公司所能犯的最糟糕的战略错误」。核心洞察是：那些看起来丑陋的老代码，每一行怪异的条件判断都是一次生产事故后的修复。扔掉代码 = 扔掉 13 年无人记录的业务知识，然后等着把每一个坑重新踩一遍。
2.2 失败墓园与幸存者
失败墓园
| 案例 | 结局 |
|---|---|
| Netscape 浏览器重写 | 3 年无发布，市场归零，公司消亡 |
| Borland dBase / Quattro Pro | 两个产品同时重写，双双被竞品抢滩 |
| Chandler PIM（2002–2008） | 6 年、数千万美元，只产出勉强可用的预览版；Google Calendar 免费解决了同一个问题 |
共同点：大爆炸、旧系统冻结、工期 2–3 倍超支、未成文规则丢失、竞品全速前进。（Spolsky 2000；Brooks《人月神话》第二系统效应；potapov.dev 25 年案例综述）
幸存者
| 案例 | 做法 |
|---|---|
| Twitter 2008–2013 | Rails 单体 → 组件逐个替换（消息队列 → 存储 → 服务化），5 年不停服 |
| LG CNB 韩企系统 | MiPlatform → React + 云原生，API 转换率 99.1%，7 个月、约一半成本 |
| 某保险企业核心系统 | 绞杀者模式单体 → 微服务，2 年，零业务中断 |
共同点：旧系统全程在线、逐波替换、每波都有验证与回滚。（Anthropic 官方案例；CSDN 架构实践综述）
2.3 什么时候全量重写才是对的？（判别式）
「永远不要重写」同样是一种懒惰。以下四个条件同时满足时，重写才是合理选项：
| 判别条件 | 本系统的情况 |
|---|---|
| ① 平台/语言已死且无法过渡（如 COBOL、无法迁移的框架） | 不满足。Java 语言是活的，只是版本老；Spring 3.2 → Boot 3 有成熟升级路径。 |
| ② 原架构在结构上无法承载目标业务（不是「难受」，是「不可能」） | 不满足。合同/经营管理这类 CRUD + 工作流 + 报表系统，是现代技术栈最成熟的领域。 |
| ③ 旧系统没有生产风险包袱（可以停机、可以慢慢对齐） | 不满足。13 年生产系统，合同数据是公司命脉，不可能「重写完再对」。 |
| ④ 无人能理解旧系统，且维护成本已超过重建 | 部分满足。reed 平台知识确实在流失——但这恰恰是第 05 章 AI 考古要解决的，而不是重写的理由。 |
本报告判断
四条判别式三条不满足、一条部分满足。正确定义你们的项目不是「重写」，而是「AI 加速的演进式重建」：新系统在旧系统旁边一个域一个域地长出来，旧系统每个域验证通过后退役。AI 的作用是把这个过程从「10 年」压缩到「18–30 个月」，而不是允许你们跳过过程本身。Gartner 2026 年预测：过度依赖生成式 AI 承担主要工作的大型机迁移项目，70% 以上无法产生预期效益——AI 是转型工具箱里缺失的一件工具，不是工具箱本身。
03AI 改变了什么、没改变什么：证据全景
这一章回答一个问题：把「AI 能力」放进第 02 章的框架里，哪些环节的成本结构真的变了？每个数字标注来源与证据强度。
3.1 一手案例：AI 在迁移各环节的实测产出
| 案例 | 场景 | 结果 | AI 承担的环节 | 证据强度 |
|---|---|---|---|---|
| Salesforce（2026 官方） | 33 个 API 端点迁往云原生架构 | 估算 231 人天 → 13 天完成（约 18 倍）；最大单 PR 21 个端点、100% 测试覆盖；同时期事故率反降 5% | 规则框架 + 自治 build-fix-validate 循环 + 并行生成 | 一手（有利益相关） |
| LG CNS（Anthropic 官方案例） | 韩国企业系统现代化：2913 个 API + 1340 个屏幕（MiPlatform → React） | 99.1% API 转换率（2888/2913），7 个月、约为传统重建一半成本；随后推广到 200 人团队 | 遗留分析 + 代码转换 + 屏幕迁移 | 一手（有利益相关） |
| Morgan Stanley DevGen.AI | 900 万行过时代码解读 | 节省约 28 万开发者小时 | 代码理解与翻译 | 一手 |
| Fiserv | 大型机现代化 | 预计 29 个月 → 17 个月（-41%）；AI 生成测试套件捕获人工遗漏的边界用例 | 测试生成 + 代码转换 | 厂商披露 |
| Sanlam / BBD | COBOL 地址管理 → Spring Boot 微服务 | 核心功能迁移从约 2 个月 → 3–4 天（提速 90%+）；路径是「COBOL → 业务文档 → API」两步法 | 文档提取 + 代码生成 | 厂商披露 |
| Deluxe（2026 CIO 100） | 50 年历史大型机整体迁云 | 约 12 个月完成、无重大故障，预计年省 490 万美元；同口径 Gartner 预测多数同类项目不达预期 | 重写 + 文档 + 测试生成 | 厂商披露 |
| AWS Transform（Twitch） | 913 个仓库 AWS SDK v1 → v2 | 节省约 2876 开发者日（11 人年），提速 70% | 规模化机械转换 | 一手（有利益相关） |
3.2 反证：AI 没有改变的部分
| 反证 | 对你们的含义 |
|---|---|
| Gartner（2026 预测）：过度依赖生成式 AI 的迁移项目 70%+ 不达预期；分析师明确指出「代码转换类工具尚无广泛成功先例，作为业务转型一部分的项目效果更好」 | AI 必须嵌在第 02 章的受控迁移框架内使用，而不能替代框架本身。 |
| Stack Overflow 2025 开发者调查（n≈4.9 万）：84% 开发者在用或计划用 AI，但信任其准确性的比例从 40% 降至 29% | 「AI 说改好了」不是验收标准；行为对账（第 06 章）才是。 |
| Adidas RPG 系统案例：自动化转换完成 85% 后，剩余 3 万行需要 4 名专家 3 个月人工修复（Sogeti 2026 评估：最后 15% 须人工） | 按 73 万行等比推算，最后一公里仍有数千行硬骨头；工期估算必须给「最后一公里」单列预算。 |
| Forrester 2026（转述）：失败项目 47% 源于「未知依赖」 | 依赖地图（第 05 章）的质量直接决定成败，这是 AI 考古的第一产出物。 |
| CAST 研究：大型 COBOL 遗产中死代码可占 25%；Java 遗产通常也有可观死代码 | 73 万行未必都是有效资产。考古阶段先剥离死代码，可能直接减掉 10–15 万行的迁移量。 |
本章结论（论断 2 的展开）：AI 把三件事的成本打掉了 60–90%——代码理解与文档化、机械翻译、测试用例生成。它没有改变三件事——业务规则的最终裁决权在业务方手里、边界行为必须与生产对账、组织必须学会管理一个「高产出但需要门禁」的新成员。把「AI 重写」理解为「把 Netscape 式重写的风险用更快的速度重新踩一遍」，是本报告最想阻止的一件事。
04总体路线图：五阶段，18–30 个月
综合绞杀者模式、金仓五阶段迁移法与 Salesforce 波次制，你们的项目可以拆成五个阶段。每个阶段有明确的产出物和退出标准——不达标不进下一阶段。
4.1 各阶段目标与退出标准
| 阶段 | 核心动作 | 关键产出物 | 退出标准（不达标不进入下一阶段） |
|---|---|---|---|
| ① AI 评估与考古 第 05 章展开 | AI 代码考古（Java / 三轨数据访问 / dmp 数据库对象三线并行）；死代码剥离；A/B/C 业务域分级 | 业务规则目录、依赖地图、A/B/C 分级与波次计划、死代码清单 | 合同域至少 1 个子模块的业务规则经业务专家逐条确认；依赖地图覆盖全部对外接口 |
| ② 行为锁定 第 06 章展开 | 对试点域生成表征测试；搭建双跑对账设施；确定哨兵指标 | 表征测试基线库、新旧系统对账平台、差异分类规则 | 试点域表征测试覆盖全部对外接口与核心分支；对账平台在生产影子流量上运行且差异可解释 |
| ③ 试点域迁移 第 07 章展开 | 选一个边缘、高频变更、边界清晰的域，用 AI 规则流水线重建到新架构，灰度切流 | 新架构骨架、AI 迁移流水线（规则文件 + 阶段门）、试点域 100% 切流 | 试点域 30 天生产运行零 P1 事故、对账差异率收敛到约定阈值、回滚演练通过 |
| ④ 波次迁移 | 按 A/B/C 分级分波推进；每波复用③打磨的流水线；每波结束复盘并把经验写回规则文件 | 每波次的验收报告；持续更新的迁移规则库 | 每波独立验收；contract 域按子模块（台账→起草→审批→履约→归档）拆成 3–5 个波次 |
| ⑤ 数据双轨与割接 第 09 章展开 | 全量迁移 + 增量同步 + 三级校验；单写双轨；择机割接 | 数据校验报告、割接手册、回滚预案 | 校验通过率 ≥99.99%；新库性能 ≥ 旧库基线 95%；故障注入演练通过 |
| ⑥ 旧系统退役 | 按域逐个关闭旧入口；数据归档；reed 平台知识文档化封存 | 退役清单、归档库、复盘报告 | 每个域在旧系统关闭前有 30 天 clean run 记录 |
为什么不是「先定新架构再动手」？传统做法会花 3–6 个月写新架构方案，然后发现方案里一半的假设不成立。绞杀者模式把这个顺序反过来：用试点域的真实迁移来逼出架构决策。第 08 章给出的目标架构是「预置立场」而非「最终裁决」——试点波次结束时回头修订它。
05阶段一：AI 代码考古——四条线索挖出全部业务规则
评估阶段的目标只有一个：把散落在四处的业务规则变成一份「人可审、AI 可用」的业务规则目录。这是整个项目 ROI 最高的阶段——行业共识是：过去这类「发现与分析」吃掉现代化预算的一半，AI 把它压缩了 60–80%。
5.1 四条考古线索，缺一不可
| 线索 | 里面藏着什么 | AI 考古方法 |
|---|---|---|
| ① Java 源码 3412 文件 / 73 万行 | Service 层业务逻辑、校验规则、状态流转、计算公式；contract 域 928 个文件是重点 | 按域分批投喂 AI（agentic 工具可全程自主遍历），产出：模块清单、调用关系图、业务规则候选列表（每条带源码位置引用） |
| ② MyBatis 508 个 mapper XML | 手写 Oracle SQL 是规则密度最高的地方：报表口径、权限过滤、特殊 join、UNION 里的业务分支、ROWNUM 分页里的隐含语义 | 逐个 mapper 提取 SQL → AI 解释每条 SQL 的业务意图 → 与 Java 层规则交叉对照。经验上这一步会挖出大量「代码里看不出来、只有 SQL 才知道」的规则 |
| ③ reed-grail 元数据 | 业务对象定义、字段约束、页面配置（brick）、流程定义（pigeon）——平台是元数据驱动的，一半业务逻辑不在 Java 里而在元数据表里 | 从 grail 元数据表导出对象模型 → AI 重建 ER 图与对象关系；从 brick 配置表还原页面清单与字段级规则 |
| ④ oracle.dmp 数据库对象 | 存储过程 / 函数 / 触发器 / 视图（若存在，核心财务与状态计算很可能在这里）；序列初始值；历史数据本身的分布规律 | 把 dmp 还原到一个隔离测试库（expdp → impdp），提取全部 PL/SQL 对象 → AI 逐个解释业务意图并标注「待迁移 / 可废弃 / 需业务确认」 |
最容易踩的坑：只让 AI 读 Java 代码。对本系统而言，②③④加起来的规则占比很可能不低于 40%——三轨数据访问 + 元数据驱动平台意味着「源代码考古」这个词本身就不完整。 dmp 文件不是「等新系统好了再导数据」的备份，它是要在第一周就还原、就分析的活体。
5.2 考古的五类产出物
a. 业务规则目录（最重要）
每条规则一条记录：规则描述 / 源码位置（文件+行号或 SQL id）/ 生效场景 / 最后修改原因（可考时）/ 置信度。AI 初筛 + 业务专家逐条确认——确认过程本身就是把老人脑子里的知识显性化，这一步的价值独立于迁移项目存在。
b. 依赖地图与接口清单
对外系统接口（银行、税务、OA、邮件…）、内部模块耦合点、定时任务清单。失败项目 47% 死于未知依赖（Forrester 转述），这份清单是保险单。
c. 死代码清单
无入口、无配置引用、无调用的模块。CAST 研究显示大型遗产死代码可达 25%——先删后迁，每删 10% 就少迁一个波次的工作量。删除动作本身也要有灰度（先下线观察一个季度再物理删除）。
d. A/B/C 域分级 + 波次计划
按业务影响、数据敏感性、耦合度三维分级（金仓方法论）：A 类核心域最后动但投入最多，C 类边缘域先动练手。输出波次表（第 07 章）。
e. 风险热力图与改造工作量清单：每个域的「AI 可自动转换比例 / 需人工比例 / 需业务确认比例」预估，作为全项目工期的量化基础。注意第 03 章教训：自动化比例按保守口径报（大型项目 40% 的压缩率是优秀水平，别按试点口径拍胸脯）。
5.3 AI 考古的操作纪律
- 规则文件法（Salesforce 一手经验）：把「本公司的命名规约、领域术语表、已确认的业务规则」维护成 markdown 规则库，每次 AI 会话都带上。每轮人工纠错都回写规则库——AI 的产出质量随规则库增长而复利式提升。
- 每条 AI 结论必须带源码引用，业务专家按引用抽查。无引用的结论视为不存在。这对应 AWS Transform 的「全链路可追溯」设计：业务规则 → 源码行 → 需求 → 新代码，审计链完整。
- 保密边界先谈好：内部信息化系统涉及合同与经营数据。三个选项：合规的企业级 SaaS（数据不用于训练、可部署在指定区域，参照 Pictet 在瑞士银行业的做法）；私有化部署开源模型（能力有折损）；或「代码脱敏 + 混合」策略。这个决策要在阶段①开始前完成，而不是出事之后。
06阶段二：行为锁定——迁移前必须先给旧系统做「行为公证」
表征测试（characterization tests，Michael Feathers 提出）的哲学只有一句话：不测试代码「应该」做什么，只记录它「实际」做什么。旧系统虽然代码丑，但它是「正确行为」的唯一权威来源——哪怕那些行为当年是 bug，只要下游已经依赖，它就是事实契约。
6.1 三层验证各自的分工
| 层 | 抓什么 | 抓不到什么 | 实施要点 |
|---|---|---|---|
| 表征测试（离线、每个波次都跑） | 函数/服务级逻辑等价；罕见分支（闰年、季度末、汇率精度） | 端到端集成差异；数据状态相关行为 | AI 生成 + 人工审核边界用例；测试即「可执行的业务规约」，进版本库、进 CI |
| 双跑对账（上线前、每域 4–8 周） | 真实生产流量下的全链路差异，包括环境、数据、并发引出的行为 | 切流后的运维类问题；长周期才暴露的问题（年结） | 差异必须三方分类：新实现错 / 基线漏 / 旧系统真实缺陷（此类的裁决权在业务方） |
| 灰度切流（切流中持续） | 性能、并发、运维、用户体验层面的回归 | —— | 1%→10%→50%→100%，每档设观察期与回滚红线；回滚必须是配置变更而非「救火」 |
论断 3 的工程落地：对你们的系统，合同域 928 个文件不可能也不需要 100% 表征覆盖。按二八律：优先锁定「对外接口 + 金额计算 + 状态流转 + 权限判定」四类高价值行为，这通常只占代码量的 20–30%，却覆盖绝大部分事故面。金仓银行项目的同类实践是三级校验（行数与校验和 → 关键字段抽样 → 业务逻辑轧差如账户余额勾稽），可直接借鉴到合同台账场景（合同金额、履约状态、审批流水的勾稽关系）。
07阶段三：波次迁移——先动哪个域、后动哪个域
顺序错误是迁移项目最常见的死法之一：一上来就动 contract 核心，卡住后进退两难。正确顺序由业务属性决定，不由技术难度决定。
7.1 建议波次表（以本系统画像为输入的草案）
| 波次 | 范围 | 理由 | 特别注意 |
|---|---|---|---|
| W1 试点 | 报表/查询类模块，或 operation 域单一子模块 | 只读为主、无资金风险、边界清晰；高频变更意味着迁完立刻减负，是向管理层证明价值的最佳载体 | 本波次的真正产出是流水线本身：AI 规则库、阶段门、对账平台。工期允许超预期 30%，学费交在这里 |
| W2 | operation 域其余部分（623 文件） | 第二大域、非资金核心、口径类规则密集，正好检验三轨数据访问的迁移方法 | 报表口径是「双跑对账」的重灾区——新旧系统报表数字必须分毫不差，提前和财务/经营部门约好仲裁人 |
| W3 | contract 域前半：合同台账、起草、归档 | 合同域拆解后的低风险部分：偏 CRUD，审批流以外的逻辑可机械迁移为主 | 合同模板与条款库的结构化迁移；历史合同数据的归属切换 |
| W4 | contract 域后半：审批流、履约、变更、用印/收付款联动 | 全系统风险最高部分：pigeon 工作流状态机 + 金额计算 + 权限交织 | 表征覆盖最全、双跑期最长（8 周+）、灰度最细（1% 起步）；需要业务专家驻场 |
| 贯穿 | pigeon → 现代工作流引擎；tiger → 新安全体系；brick → 新前端方案 | 基础件不能「最后一起换」：W1 试点就必须用新工作流引擎跑通一个审批流，否则 W4 会被平台层卡死 | 流程定义迁移（pigeon 流程 XML/元数据 → BPMN 2.0）本身是独立子项目，安排在 W1–W2 之间 |
灰度切流的实现：reed 的 runway 聚合层正好可以改造成过渡期网关——按域、按用户组、按比例把请求路由到新/旧系统。回滚 = 改一行路由配置。这就是「回滚是配置变更，不是救火演习」的全部含义。切流节奏参考行业实践：每档观察 3–7 天，合同域关键操作（审批提交、金额变更）单独设置更长的 1% 观察期。
08目标架构：模块化单体优先，reed 平台能力的现代替代
新架构的核心决策只有一个：单体还是微服务？对 20–50 人规模、内部信息化场景，答案几乎是确定的。
8.1 单体 vs 微服务
| 考量 | 模块化单体 | 微服务 |
|---|---|---|
| 团队规模匹配 | ✅ 一个内部团队即可开发运维 | ❌ 需要平台工程能力（服务治理、链路追踪、分布式事务），通常 3–5 个以上团队才回本 |
| 事务一致性 | ✅ 本地事务够用（合同审批 + 台账更新天然是同一事务） | ❌Saga/最终一致性，复杂度暴涨且正是事故来源 |
| 与绞杀者模式的配合 | ✅ 每个域是新单体里的一个 Maven 模块，边界用接口隔离，将来可拆出 | ⚠️ 过早拆分 = 第二系统效应的最大放大器 |
| 演进路径 | ✅ 模块边界先立住，哪块真有独立扩缩/团队需求再拆（Twitter 也是先拆组件后拆服务） | —— |
结论（论断 6）：新系统 = Spring Boot 3.x / JDK 21 LTS 的模块化单体，按 DDD 划分模块（contract / operation / workflow / platform-security / reporting…），模块间只经接口通信、数据库 schema 按模块分 schema。服务化留作远期选项，不进本期目标。
8.2 reed 平台五组件的替代映射
一个常见误区是「新系统要连平台一起自研」。reed 平台的五个能力，2026 年全部有成熟开源或轻量方案，自研平台是 2013 年的正确决定、2026 年的错误决定。
| reed 组件 | 能力 | 现代替代 | 迁移要点 |
|---|---|---|---|
| grail 建模 | 元数据驱动的业务对象 ORM | JPA/MyBatis + 代码生成器；或保留「元数据表 + 解释器」模式但用新栈重写 | grail 元数据表是重要资产：考古阶段已结构化导出，可生成新系统的实体类与 DDL 初稿 |
| pigeon 工作流 | 审批流引擎（Hibernate 3） | Flowable / Camunda 8（BPMN 2.0 标准） | 存量流程定义迁移为 BPMN；在途流程实例选择「走完旧流程或冻结快照迁移」二选一，切流窗口对齐 |
| brick 页面设计器 | 配置式页面生成 | Amis / Formily 等开源低代码 JSON Schema 方案，或纯前端 + 代码生成 | brick 配置表 → JSON Schema 的转换器是个一次性的小工具，AI 可全自动完成 80% |
| tiger 安全 | 用户/角色/权限/组织 | Spring Security + OAuth2/OIDC；或轻量方案（Sa-Token 类）+ 数据权限层自研 | 权限模型迁移要先做「权限语义对账」：旧系统的数据权限过滤藏在 508 个 SQL 里（见第 05 章②） |
| runway 聚合 | 门户/集成/聚合入口 | API 网关（Nginx / APISIX）+ 前端微加载或单体前端 | 过渡期兼任新旧系统流量路由器（第 07 章） |
8.3 技术栈建议表
| 层 | 建议 | 理由 |
|---|---|---|
| 运行时 | JDK 21 LTS（虚拟线程可用） | 当前 LTS 主力，生态与 AI 工具支持最全 |
| 框架 | Spring Boot 3.x | 从 Spring 3.2 的编程模型演进路径清晰，团队经验复用度最高 |
| 数据访问 | 保留 MyBatis（升级到 mybatis-spring 3.x）+ 新代码用 JPA 或 MyBatis-Plus | 论断 4 的直接推论：508 个 XML 里的 SQL 是资产。SQL 90% 兼容可平移（Oracle 方言若换库则见第 09 章），比让 AI 重写 SQL 然后逐条对账便宜得多 |
| 前端 | Vue 3 / React + TS，表单密集页面配 Amis/Formily | 替换 brick 的配置式开发体验；国内生态 Vue 更厚 |
| 工作流 | Flowable（BPMN 2.0） | Java 生态原生、社区活跃、与 Spring Boot 集成成熟 |
| 数据库 | PostgreSQL（首选）或国产库（若有信创要求） | 迁移路径见第 09 章；若现有 Oracle 许可成本可接受，也可「先换应用、缓换库」，分两步降低风险 |
| CI/CD | 流水线内置：编译 → 静态扫描 → 表征测试 → 安全扫描 → 部署灰度 | 第 10 章的门禁就长在这里 |
关于「AI 原生架构」的克制建议：不要为了「AI 重写」而让新系统采用团队不熟悉的花哨架构（如全事件溯源、CQRS）。新系统要优化的是未来 10 年你们团队维护它的成本，不是本次迁移的新鲜感。用团队最熟的方式表达业务，AI 工具链反而能发挥最大作用——AI 对主流模式的理解远好于对自创架构的理解。
09数据迁移专项：dmp 的正确打开方式
数据迁移失败没有「回滚重试」的余地——数据错了就是经营事故。国产数据库厂商与银行业在过去几年沉淀了一套高度工程化的方法，可直接借用。
9.1 先做一个关键决策：新系统用什么库？
| 选项 | 适用条件 | 对迁移的影响 |
|---|---|---|
| A. 保留 Oracle（先换应用后换库） | 许可成本可接受、无信创硬指标 | 数据层零迁移，风险大减；508 个 SQL 原样可用；把换库推迟为独立二期项目 |
| B. PostgreSQL / 开源库 | 想摆脱 Oracle 锁定、无信创要求 | SQL 方言转换是主要工作量（CONNECT BY → 递归 CTE、ROWNUM、NVL/DECODE、序列语法）；AI 辅助方言转换 + 逐条对账 |
| C. 国产库（达梦/金仓/OceanBase 等） | 有信创合规要求 | 主流国产库主打 Oracle 兼容，DMP 可直导或近原生导入；但 PL/SQL 对象仍需逐个验证（金仓实践：127 个存储过程 + 43 个函数 + 89 个复杂视图是典型改造清单量级） |
本报告的建议：若非硬性约束，选 A。「换应用」与「换数据库」是两个高风险变更，叠加在一起出事时无法归因。分开做，每一步都可验证、可回滚。
9.2 五步迁移法（银行业 / 信创实践综合）
- 对象盘点与分级：从 dmp 还原到测试库，盘点全部表 / 视图 / 存储过程 / 触发器 / 序列 / 同义词，生成兼容性报告与改造工作量清单。按 A/B/C 分级：核心交易表优先，归档历史数据延后。
- 全量迁移：expdp 导出 → 目标库分片导入（大表延迟建索引）。全量迁移可在项目中期就做——它不干扰生产。
- 增量同步 + 单写双轨：切换窗口前，用 Oracle LogMiner / goldengate 类工具或目标库自带同步链路，把增量变更秒级同步到新库。红线：双轨期间写操作只走一端（旧库），另一端只读——双写会让数据不一致无限放大，这是所有银行案例一致强调的铁律。
- 三级校验：①行数与校验和逐表比对；②关键字段抽样比对（金额、日期、状态）；③业务逻辑校验——合同台账场景即：合同金额 vs 审批单金额 vs 收付款流水轧差、履约状态 vs 审批记录勾稽。验收线：通过率 ≥ 99.99%。
- 割接与回滚预案：选业务最低谷窗口（凌晨/周末）；流程 = 停旧写 → 增量追平 → 终态快照比对 → 切连接 → 冒烟验证 → 放量。割接手册 + 回滚预案 + 监控指标清单三份文档缺一不可；连接池初始化数、validation 查询（
SELECT 1）这类细节提前演练——它们是割接夜里最常见的翻车点。
性能验收（别忘了）：新库性能不得低于旧库基线——TPS ≥ 基线 95%、P99 延迟不劣化。用负载回放引擎录制真实交易回放验证，并做故障注入（杀主节点、断网络）验证高可用切换。功能跑通 ≠ 迁移完成。
10AI 工程化与治理：让 AI 成为「有门禁的高产员工」
AI 不是一次性引入的工具，而是要进团队编制的「新员工」：给它岗前培训（规则库）、给它工作规范（阶段门）、给它绩效考核（对账差异率）。这一章讲怎么管。
10.1 工具格局（2026 年中）
| 层 | 代表工具 | 对本项目的适配判断 |
|---|---|---|
| 确定性机械转换层 | OpenRewrite / Moderne（Java 配方式重构） | 处理「已知且可枚举」的变更：JDK 升级、javax→jakarta、依赖 bump。确定性 100%，优先于 AI 使用——凡配方能表达的，不用 AI |
| Agentic 编码层 | Claude Code / Copilot / 开源 agent 框架 | 主力工具：代码考古、表征测试生成、业务逻辑迁移、测试补齐。配合规则文件（CLAUDE.md / 规约库）与 MCP 接内部系统 |
| 云厂商迁移服务 | AWS Transform / GitHub Copilot app modernization / watsonx | 绑定云厂商生态（AWS Transform 目标是把你迁去 AWS）；若不上公有云则参考其方法论（评估→试点→规模化→持续学习四段式），不必绑定产品 |
| 架构分析 | vFunction / CAST 类知识图谱 | 单体拆分边界发现、死代码检测；HCLTech 试点显示「确定性知识图谱 + AI」比纯 AI 准确率更高——预算允许可引入，预算紧张则 AI 考古 + 人工复核可覆盖 80% 价值 |
行业综述（dev.to 2026）的关键结论：失败项目大多「拿为一层设计的工具去打另一层」——用配方工具做架构拆分，或用 AI 做 RGB 机械升级。先分层，再选工具。
10.2 门禁分层：AI 产出进主干必过的六道关
10.3 三条治理纪律
- 修流程，不修代码（fix the process, not the code）：AI 第 N 次犯同类错误时，正确动作是改规则文件、加自动检查 hook，而不是人肉改掉这次的输出。团队的核心资产从「代码」变成「规则库 + 验证设施」——这也是为什么第 04 章说 W1 试点真正的交付物是流水线本身。
- 数据不出域：合同与经营数据是敏感资产。参照 Pictet（221 年历史瑞士私人银行）的落地方案：企业级合约（数据不训练模型）、部署区域约束、按角色分阶段放开。若有条件，用「脱敏后的代码 + 结构」做 AI 分析，真实数据只在隔离环境流转。
- 信任但有验证：Stack Overflow 2025：开发者信任 AI 输出的比例已从 40% 降到 29%——这不是 AI 变差了，是用过的人变多了。把「验证成本」显性编入工期（第 03 章：大型项目按 40% 压缩率做计划，而非试点的 90%），信任问题就从情绪问题变成了排期问题。
11组织与度量：决定成败的「非技术因素」
WJARR 2025 对 78 个企业现代化项目的研究结论：技术改造 + 组织转型双轮驱动的项目 91% 达成业务目标，纯技术驱动的只有 43%。差距不在代码里。
11.1 团队构成建议
| 角色 | 人数参考 | 职责与要点 |
|---|---|---|
| 迁移专项小组（全职） | 4–8 人 | 禁止兼职——兼职的迁移永远排不上优先级，这是行业血泪共识。构成：2–3 名熟旧系统的工程师 + 2–3 名新栈工程师 + 1 名 AI 工程化负责人（管规则库/流水线/门禁） |
| 业务专家（in the loop） | 每域 1–2 人 | 合同管理员/财务/经营口。职责：确认业务规则目录、裁决对账差异、验收灰度。给他们算工时、进项目组——不是「有空时帮忙」 |
| 旧系统守护者 | 1–2 人（可兼职） | 迁移期间旧系统照常运转：修 bug、上必要的政策性需求。明确「冻结 vs 维持」边界：默认维持（绞杀者模式的前提），只冻结重构性改动 |
| reed 原作者/资深维护者 | 至少 1 人 | 巴士系数风险的最大对冲。若已离职，第 05 章考古产出就是唯一替代——更要确保业务专家确认环节严格执行 |
11.2 度量体系（防 Goodhart）
| 指标 | 健康线 | 防扭曲说明 |
|---|---|---|
| 波次交付周期（每域从开工到 100% 切流） | 逐波缩短 | 只统计「切流完成」不统计「代码写完」——防止为赶进度跳过双跑 |
| 双跑对账差异率 | 收敛且可解释 | 差异必须三方归因；「差异率为 0」若出现太早，先怀疑对账覆盖面不足而非完美迁移 |
| 旧系统代码量（活跃入口数） | 单调下降 | 真正的北极星：新系统代码量无意义，旧系统的消亡速度才是项目进度 |
| 生产事故（P1/P2） | 不高于基线 | Salesforce 数据显示 AI 加速与质量可以兼得，但前提是门禁真实生效——事故率抬头先查门禁是否被绕过 |
| 规则库覆盖率（已确认规则 / 目录规则） | 核心域 100% | 防「AI 说了算」：未经业务确认的规则不得作为迁移依据 |
反 Goodhart 原则：任何单一指标被考核，它就会撒谎。以上指标成组看，永远不设「AI 代码占比」这类 vanity metric 考核。
12反模式清单：别人已经踩过的 12 个坑
每一条都来自真实案例。用法：每两周拿这张表过一遍项目现状，命中任何一条立即纠偏。
战略层
| 反模式 | 症状 | 修正 |
|---|---|---|
| ①「先重写后切换」 | 新系统闷头开发一年，旧系统照常演进，差距越拉越大 | 绞杀者模式：新功能在新系统长，旧系统只维持（第 02 章） |
| ② 把 AI 当项目主角 | 方案 PPT 第一页是「AI 自动重写 73 万行」，没有验证与回滚章节 | AI 是加速器不是方法论；Gartner：这类项目 70% 不达预期（第 03 章） |
| ③ 按技术栈切波次 | 「先把所有前端换了，再换后端」——业务断裂，没法对账 | 按业务域垂直切波（第 07 章） |
| ④ 大而全的新架构设计 | 3 个月架构评审，微服务/中台/AI 原生全家桶 | 模块化单体 + 试点域逼出架构决策（第 08 章） |
| ⑤ 无限期并行 | 新旧双轨跑了两年谁也不敢切 | 每个域设硬性退役时限；30 天 clean run 即关旧入口（第 06 章） |
| ⑥ 应用与数据库同时切换 | 割接夜出事，无法归因是代码还是 SQL 方言 | 两个高风险变更分开做（第 09 章） |
工程层
| 反模式 | 症状 | 修正 |
|---|---|---|
| ⑦ 只考 Java 代码 | 考古报告没有 SQL / 元数据 / 存储过程章节 | 四线考古（第 05 章）——本系统三轨数据访问是高危点 |
| ⑧ 无表征基线就迁移 | 新系统测试全绿但生产对账差异不断 | 先行为公证再动代码（第 06 章） |
| ⑨ AI 产出免检进主干 | 「AI 写的测试都过了」 | 六道门禁；信任比例 29% 的教训（第 10 章） |
| ⑩ 不删死代码直接迁 | 给 25% 的死代码买全票 | 考古阶段剥离 + 灰度下线观察（第 05 章） |
治理层
| 反模式 | 症状 | 修正 |
|---|---|---|
| ⑪ 兼职迁移团队 | 「大家抽空搞」，半年无产出 | 全职专项小组 + 业务专家算工时（第 11 章） |
| ⑫ 敏感数据裸奔给 AI | 把生产库直接丢给公有云模型 | 数据不出域方案先行（第 05/10 章） |
13结论：如果你的团队只记住五句话
- 这不是重写项目，是受控迁移项目——AI 把 10 年的绞杀者迁移压缩到 18–30 个月，但没有取消「行为验证」这个环节。
- 先花 6 周做四线考古（Java / 508 个 SQL / grail 元数据 / dmp 数据库对象），产出业务规则目录——这是全项目 ROI 最高的投入。
- 先行为公证，后动代码：表征测试 + 双跑对账 + 灰度切流，是每一波都可控的机制保证。
- 从边缘域试点，contract 域最后分模块切；试点真正的交付物是 AI 流水线与验证设施本身。
- 组织先行：全职专项小组 + 算工时的业务专家 + 六道门禁。双轮驱动 91% vs 纯技术 43% 的差距，全部在这句话里。
参考来源（按证据类型分组）
厂商一手案例（有利益相关，数字按保守口径采信）
- Anthropic 官方：LG CNS 案例研究（2913 API、99.1%、7 个月）；Pictet 案例研究（银行业 AI 治理与数据驻留）；Cognizant 合作公告（legacy modernization 实践框架）
- Salesforce 官方《How Engineering Became Agentic》（2026）：33 API 迁移 231 人天→13 天、规则框架法、事故率 -5%
- AWS：AWS Transform 官方文档与 FAQ（四段式方法论、全链路可追溯、Twitch/Coupang/Air Canada 案例）
行业调查与分析
- Stack Overflow Developer Survey 2025（n≈4.9 万）：AI 使用率 84%、信任度 40%→29%
- Gartner（2026，经 CIO/D1Net 转述）：生成式 AI 依赖型大型机迁移 70%+ 不达预期；AI-ready data 警示
- Stripe Developer Coefficient：开发者每周约 17 小时用于维护类工作
方法论与学术
- Joel Spolsky《Things You Should Never Do, Part I》（2000）——Netscape 案例原文论证
- Fred Brooks《人月神话》（1975）——第二系统效应；Martin Fowler——Strangler Fig Application（2004）
- WJARR 2025《Legacy Application Modernization: A Strategic Framework》（n=78，86% 绞杀者成功率、91% vs 43% 双轮驱动结论；单篇期刊、中等强度）
- Michael Feathers《Working Effectively with Legacy Code》——表征测试概念源头
工程实践与厂商技术博客
- 电科金仓：某省交通集团 Oracle 全栈迁移纪实（五阶段、三级校验、A/B/C 分级）；华为云社区：银行核心 6 步迁移法（单写双轨、99.99%、TPS≥95% 基线）
- Kellton：Shadow Execution 框架（golden master 双跑 4–8 周、0.00 哨兵值案例、三层验证）；HCLTech：iLIT-AI + CAST 知识图谱两步转换试点（2026-03，900 万行）；BBD/Sanlam：COBOL→文档→Spring Boot（90% 提速）
- 腾讯云开发者社区：遗留系统微服务改造系列（房地产 CRM 100 万行案例）；dev.to：2026 遗留 Java 现代化工具格局综述（确定性层 vs 纠缠层）
- Deluxe 大型机迁移（2026 CIO 100，12 个月、年省 490 万美元；D1Net 报道）
证据边界声明：厂商一手案例的数字存在天然的选择性披露偏差，本报告已在每处标注证据强度并按保守口径采信（如工期压缩按大型项目 40% 做计划而非试点口径 90%）。Forrester「47% 失败源于未知依赖」与部分工具对比数字来自二手转述，仅作方向性参考。所有涉及本系统的具体波次划分、工期与人数均为基于系统画像的推演草案，须经第 04 章阶段①的实际考古结果修正。