老系统 AI 原生重建方法论

0核心判断：这不是翻译工程，是考古工程

先纠正一个几乎必然走错的方向，再谈怎么做。

用 AI 重写老系统，最大的误区是把它当成"翻译任务"——把 Java 翻译成新技术栈。
它真正的本质是"考古任务"——从 73 万行代码和 Oracle 数据里，把流失的业务知识挖出来、结构化、再表达。

三个不可回避的事实，决定了整个方法论：

事实	推论（方法论必须回答的问题）
① 业务知识只存在于代码和数据里。10 年的人员更替，文档早已失效，连"懂业务的人"也只懂自己经手的那一块。	唯一可靠的需求来源是代码本身。所以第一要务不是写新代码，而是建立一套从代码中批量提取业务知识的流水线。
② 你不懂业务。你自述没有业务背景，第一个练手模块（项目计划管理）因此无法验证"真实替代"是否可行。	不懂业务没关系，但验收标准不能依赖业务判断，必须设计"不依赖懂业务的验证机制"——答案是对账：让旧系统的数据输出当裁判。
③ "功能相同"不可言说，"数字一致"可以言说。"新系统做得对不对"在不懂业务时无法口头论证，但"新系统算出的金额、数量、状态与旧系统逐条一致"是机器可判定的。	替代性验证的唯一硬标准：平行运行 + 输出对账。做不到对账的模块，就不具备被验证替代的资格——这也是切片选择的准绳。

方法论一句话版本先建知识库（代码 → 业务规格），再定契约（规格 → 可验收陈述），然后选一个可对账的闭环切片做新系统，与旧系统平行对账，通过后按模块逐个绞杀替换。AI 在每个环节的角色是"阅读器、整理者、对账员"，而你是"考古队长与验收官"。

1现状盘点：onesystem 老系统实况

方法论不是空泛的，以下是从 old-src 实际清点出的结构事实，后续所有策略都以此为输入。

1.1 模块规模与业务域

模块	Java 文件数	推测业务域	重建优先级信号
`contract`	928	合同管理（全系统最大模块）	核心业务，复杂度最高，中后期切
`operation`	623	运营管理 / 经营统计	报表口径密集区，替代难点所在
`outsourcing`	453	外包管理	中大型业务域
`purchasing`	375	采购管理	单据流完整，适合作为对账切片候选
`marketing`	306	市场 / 营销	中大型业务域
`humanresources`	195	人力资源	含考勤、人事等高频子域
`finance`	173	财务	金额对账价值最高，但口径最敏感
`general`	94	通用 / 基础功能	基础支撑，先行
`core`	79	核心框架 / 公共组件	含 reed 内部框架依赖，迁移第一道坎
`dailylog`	65	工作日志	简单闭环，可作为早期练手切片
`externalorganization`	46	外部单位 / 客户供应商	主数据类，先行
`reimbursement`	40	报销	单据 + 审批 + 金额，对账切片最佳候选
`cost`	22	成本	口径敏感，依附于上游单据
`operatingStatistic`	12	经营统计	报表型，最后切
`r1`	1	War 打包聚合模块	部署形态参考

1.2 技术形态与风险点

事实	对重建的影响
Spring 3.2 + JDK 1.7 + JSP（仅 54 个 JSP）+ MyBatis + Oracle	典型 2012–2015 年代企业 Java 单体。JSP 少说明大量页面逻辑可能由前端 JS 或 reed 框架渲染，重建时需另行清点前端资产。
依赖内部框架 `reed`（brick / pigeon / tiger / grail / tools 等 10+ 个构件，无外部文档）	最大暗礁。很多"业务行为"实际藏在 reed 的注解、基类、拦截器里（权限、审计、事务、数据权限）。Phase 0 必须专门逆向 reed 的能力清单，否则新系统会漏掉隐形功能。
Quartz 2.1.7 定时任务	定时任务是典型的"没人记得但每天在生产数据"的代码，必须全量清点，否则新旧系统对账时会出现"数据怎么多了一笔"的灵异现象。
CAS 单点登录客户端（cas-client 3.2.1）	账号体系与权限模型是横切所有的地基，属于第一批要重建的规格。
SVN 管理，版本 1.2.4-SNAPSHOT	建议迁移到 Git 并保留全量历史——`git log/blame` 是业务考古的重要线索（某段奇怪的逻辑是哪年、因为什么加的）。
含 `ess(deprecated)` 与 `oracle.dmp`	已有废弃模块与数据库转储文件——后者是业务考古的另一半金矿（见 §11 对你 dmp 工具的评价）。

2总路线：五阶段推进图

每个阶段都有明确的产出物和"完成判据"，不允许裸奔进入下一阶段。

PHASE 0

知识库基建

代码索引、调用链、任务清单——让 3412 个文件可检索、可提问

PHASE 1

业务考古

从代码反推领域模型、单据流、审批流、报表口径

PHASE 2

规格重建

词汇表、能力清单、契约、数据字典——新系统的纸上建筑

PHASE 3

切片验证

选一个可对账的闭环业务，新系统与旧系统平行跑

PHASE 4–5

逐个替换

按模块绞杀式替换、对账达标后退役旧模块

节奏建议 Phase 0–2 共约 6–10 周，期间不写任何新系统业务代码。这违背直觉，但它是本方法论与"拿着 AI 就开始逐文件翻译"的本质区别：你缺的不是开发能力，是业务真相；在真相到手之前写的每一行新代码都是负债。

3Phase 0 · 把代码变成可提问的知识库

目标：让任何一个后续的问题（"报销单谁审批" "这个金额怎么算的"）都能在分钟级得到带代码证据的答案。

知识库基建（约 1–2 周）

完成判据：业务问题可定位到具体类 / 方法 / SQL；所有清单覆盖率 100%

本阶段本质：用 agent 对 3412 个 Java 文件做结构化清点，产出索引层产物。这批产物不只是给人看，更是后续每个 agent 任务的常驻上下文（context）——这是 AI 原生开发的关键动作：先把上下文工程做好，再谈生成。

六张底表（清单即资产）

①

URL → 功能链路表从 JSP / JS / Spring 注解提取全量 URL，映射到 Controller → Service → Mapper → 物理表。这是"系统到底有多少功能"的完整清单。

②

菜单 / 权限点清单菜单树、按钮级权限、角色定义。新系统的权限模型直接从这张表长出来。

③

Quartz 定时任务清单每个 Job 的 cron、触发的 Service、读写了哪些表、产出什么数据。

④

报表与口径 SQL 清单所有统计类 SQL 全文归档。报表口径 = 未来对账的期望值，单独成册。

⑤

表结构数据字典从 Oracle 元数据 + Mapper XML 导出：表、字段、注释、主外键、估算行数。用你已有的 dmp 查看能力自动化产出。

⑥

reed 框架能力清单逆向内部框架：注解、基类、拦截器、隐式行为（审计、数据权限、字段加密如 bcprov）。回答"代码里看不到但系统真在做的事"。

操作要点

批量 agent 阅读，而非自己翻。按模块切分任务（contract 928 个文件可再按包切），每个 agent 负责一块，输出统一 schema 的 JSON/Excel，再汇总。这正是子代理并行擅长的形态。
每条结论带证据锚点。清单里的每一行都要能跳回具体文件与行号（方法论文件中的引用规范同样适用于机器上下文）——防止 agent 编造，也便于人工抽查。
全量入库、持久保存。这批清单放进项目目录（如 knowledge/），并作为后续所有 agent 任务的默认携带上下文。它们是本项目的"业务记忆"，价值随时间递增。
人工抽查 5%。每个清单随机抽 5% 核对原代码，确认 agent 提取准确率；不达标则调整提取 prompt 重跑。这是整个考古流水线的质量阀。

4Phase 1 · 业务考古：从代码反推业务真相

目标：把 Phase 0 的"结构清单"升华为"业务叙述"——领域词汇、单据生命周期、审批流、口径公式。

业务知识提取（约 2–4 周）

完成判据：能用领域词汇向一个不懂代码的人讲清任一单据"从哪来、到哪去、谁批、钱怎么算"

三视角交叉验证法

单个视角都会骗人，三个视角互相印证才能得到可信的业务叙述：

视角	看什么	回答的问题
数据视角	表名、字段、状态字段的取值分布（dmp 里有真实数据）	系统里真实存在哪些业务对象？一个"状态"字段里 0/1/2/3 各出现了多少次、占多少比例？
界面视角	JSP/JS 页面、菜单、按钮文案	用户看到的业务概念叫什么？操作路径是什么？哪些字段是必填、怎么校验？
逻辑视角	Service / SQL / 状态变更代码	单据状态机怎么流转？金额公式是什么？什么条件下允许操作？

四类核心产出

①

领域词汇表（中英对照）如：报销单=reimbursement order，责任单元=responsibility unit。全项目强制统一，消除"同一个东西三个名字"。这是所有 agent 对话与代码生成的地基。

②

单据生命周期 / 状态机图每张核心单据（合同、采购单、报销单…）的状态枚举、迁移条件、触发动作。状态机是从代码反推业务的最高密度载体。

③

审批流清单谁提交、谁审批、几级、什么条件走哪条分支、是否可驳回/撤回。审批流往往散落在 reed 注解和硬编码双重位置，需专门提取。

④

报表口径文档每个统计数字 = 一段可执行的口径描述（取哪张表、什么过滤条件、怎么聚合）。这是 Phase 4 对账的裁判书，也是全项目最难替代的部分，值得投入最深。

为什么口径文档值得花最大力气业务用户判断"新系统对不对"，最终靠的就是报表数字。代码里的统计 SQL 往往包含十年间层层叠加的补丁条件（"当年某某说要把 X 类合同剔除"）。这些隐含决策只存在于 SQL 本身——把每条统计 SQL 连同它的过滤条件、JOIN 关系逐条文档化，等于把十年间流失的业务决策重新存档。

5Phase 2 · 规格重建：新系统的"纸上建筑"

目标：在写第一行业务代码之前，先完成可验收的规格层。

契约与规格（约 2–3 周，可与 Phase 1 部分并行）

完成判据：任一功能的"正确"可以被一条可执行检查判定

三件规格资产

能力清单（Capability Inventory）。以"可对账的验收陈述"重写全部功能：不是"系统支持报销审批"，而是"员工提交报销单后，金额 ≤ 5000 走直属上级一级审批，＞5000 增加部门负责人二级审批；审批通过后生成凭证记录，科目字段取自费用类型映射表"。每条陈述标注：来源证据（文件/行号）、新旧系统对账方式。
数据字典与迁移映射。旧表 → 新模型映射、字段语义、编码值翻译（如 status 0/1/2 → 枚举）、历史数据迁移策略与清洗规则。
新系统技术基线与脚手架。选型原则：克制。选你和 agent 都最熟、招聘市场最大、能再跑 10 年的主流栈（如 Spring Boot 3 + 现代前端或成熟低代码形态），而不是追新。脚手架包含：统一鉴权、审计日志、数据权限、异常与返回约定——这四样正是 reed 隐形提供的能力，必须显式重建。

Spec-driven 工作回路（此后所有开发的默认姿势）

回路

改规格

能力清单/契约的变更先行，写清验收方式

回路

agent 实现

携带词汇表+链路表+相关规格作为上下文

回路

对账/测试裁决

机器判定通过与否，人只仲裁争议

回路

沉淀

决策写入 ADR 与词汇表，更新知识库

这个回路里，你的角色从"写代码的人"变成"写验收标准的人"——这正是"不懂业务也能主导重建"的制度基础。

6Phase 3 · 垂直切片：选对第一场仗

目标：用一个切片回答"AI 重建的新系统，能否在真实业务数据上替代旧系统"。这是整个方法论中唯一"验证可行性"的环节，选错切片 = 白验证。

6.1 切片选择矩阵

维度	为什么重要	高分特征
可对账性（权重最高）	替代性只能靠数字一致来证明	有明确的金额/数量/状态输出，旧系统数据可直接导出比对
闭环完整性	半个流程验证不了端到端替代	从录入 → 审批 → 生效/出数，一个完整单据生命周期
业务核心度	验证结果要能让各方信服	是真实每天在用的流程，而非边缘功能
复杂度适中	第一场仗要赢得快、赢得清楚	1–2 个状态机、1–2 条审批路径，避开 contract（928 文件）这种巨兽

推荐候选 首选：reimbursement（报销，40 文件）。单据录入 → 审批流 → 金额 → 财务凭证，天然全闭环，金额可对账，体量适中。备选：dailylog（工作日志，65 文件）作为纯练手，以及 purchasing（采购，375 文件）作为第二切片。避免首选：报表统计类（口径黑箱太多）与 contract（复杂度爆炸）。

为什么"项目计划管理"验证不了替代性不是这个模块做得不好，而是它选错了验证命题。计划管理类功能属于"管理辅助流"：做出来的东西"看起来像"就够了，没有可对账的数字、没有必须由旧系统当裁判的输出，于是"做对没有"无法判定——你缺的不是开发能力，是一个能让旧系统当裁判的切片。把同样的开发方法用在报销单上，平行跑一个月，对账差异为零，可行性就自动被证明了。

6.2 切片实施方式

新系统实现该单据的完整生命周期（录入、审批、状态机、凭证/出数）。
历史数据按 Phase 2 的迁移映射导入新系统。
规定一个平行运行期（如 4 周）：同一业务在旧系统正常跑，数据同时同步/录入新系统。
每周末自动生成对账报告：单据数、金额合计、状态分布、逐条差异明细。差异为 0 或全部解释归因，即达标。
达标后该模块流量切到新系统，旧模块进入"只读归档"状态。

7Phase 4–5 · 平行对账与逐个替换

strangler fig（绞杀榕）模式：新系统沿模块边界一圈圈长大，旧系统一圈圈枯死。

绞杀式替换（持续数月，按模块推进）

退役判据：对账连续 N 周零差异 + 用户无回退诉求

替换顺序建议

第一批

地基

组织/人员/权限、外部单位等主数据（general / externalorganization / core 能力）

第二批

已验证切片

reimbursement、purchasing 等对账友好单据流，复制切片打法

第三批

业务主干

contract、outsourcing、humanresources、marketing

第四批

口径区

finance、cost、operation、operatingStatistic 报表与统计，最后切

每模块的固定动作（模板化、可复用）

从知识库取该模块的链路表 / 状态机 / 口径文档，更新为当前版。
写可对账的验收陈述，与业务侧逐条确认口径（这一阶段建议开始引入真实业务用户）。
agent 实现 + 数据迁移 + 平行运行 + 周末对账报告。
达标 → 切流量 → 旧模块只读归档；未达标 → 差异归因 → 修规格或修实现，绝不带病切流。
写一份本模块 ADR（架构决策记录）：替代过程、踩坑、口径裁决，喂回知识库。

对账工具本身值得做成基础设施每周末自动对账报告不应是临时脚本，而应是一个可配置的平台：选模块、选口径、跑比对、出差异明细。它会陪伴整个替换周期，也是你向业务方证明进度与质量的核心证据物。

8AI 原生工程实践清单

贯穿所有阶段的日常操作纪律。

Context Engineering（上下文工程）—— 决定 agent 产出质量的第一变量

任务包模板化。每个 agent 任务固定携带：相关模块的链路表切片、领域词汇表、相关状态机/口径、项目编码规范。缺上下文的生成 = 幻觉自由发挥。
结论必须带证据锚点。凡 agent 输出的业务结论，强制附"来源文件:行号"或"来源 SQL 原文"，无锚点的结论一律视为推测。
抽查制度。所有批量提取产物随机抽 5% 人工核对，准确率不达标就改 prompt 重跑，不凑合。

知识即资产（Knowledge as Code）

词汇表、链路表、口径文档、ADR 全部版本化入库，与代码同仓；它们是被代码生成和消费的一等公民。
每次与真实业务用户的交流结论，24 小时内回写知识库——口头共识是本项目最贵的流失资产。

测试与对账资产

Golden Master（特征化测试）：对关键旧逻辑，先录输入输出对再重建——新实现必须逐对复现，把旧系统变成免费的测试 oracle。
对账即验收：一切"对不对"的争议以差异报告仲裁，不以会议仲裁。
新系统自身保持正常单测/集成测试纪律；对账层是额外的、面向业务的测试。

防漂移

agent 每次会话以最新知识库快照为上下文，防止模型凭早期印象生成过时命名与结构。
新代码评审由第二个 agent 扮演"考古质疑者"：对照旧系统证据链挑刺，专问"这个行为旧系统里证据在哪"。

990 天落地计划

按周排布，可直接执行。

周	动作	产出 / 判据
W1–W2	Phase 0：代码索引与六张底表；SVN → Git 迁移保留历史	链路表、权限清单、定时任务清单、口径 SQL 清单、数据字典、reed 能力清单；5% 抽查通过
W3–W5	Phase 1：按"数据/界面/逻辑"三视角对 reimbursement、purchasing 做深度考古，其余模块做广度考古	词汇表 v1、报销/采购状态机、审批流清单、口径文档首批
W6–W7	Phase 2：报销切片的能力清单与验收陈述；新系统脚手架（鉴权/审计/数据权限/返回约定）	报销单全量"可对账陈述"清单；脚手架可运行
W8–W9	切片实现：agent 按陈述逐条实现 + 历史数据迁移	报销模块在新系统全生命周期可用
W10–W13	平行运行 + 周末对账（把对账平台本身做成可复用工具）	连续 4 周对账零差异或全部归因 → 可行性结论落地

10常见陷阱 Top 10

每一条都来自同类项目的高频死法。

Big-Bang 翻译：让 AI 按文件逐个翻译 3412 个 Java 文件。产出物"像代码"但无人知道对不对，三个月后没人敢碰。

照抄 UI：把旧界面当规格。界面是十年前交互理念的化石，新系统应对齐业务目标而非对齐像素。

忽视 reed 隐形行为：权限、审计、数据权限、字段加密藏在内部框架里，不显式重建，上线后必然出事。

跳过考古直接开发：你目前的直觉（"还没找到感觉"）就是这条陷阱的警报——感觉缺失的本质是业务真相缺失。

选了不可对账的切片：没有数字裁判的模块做得再漂亮也证明不了替代性。

低估报表口径：统计数字背后的十年补丁条件是最深的知识，最后做报表 = 最后发现地雷。

定时任务与 Job 遗漏：没人记得的 Job 每天在生产数据，漏一个，对账就永远对不平。

agent 结论无证据：不带文件/行号锚点的"业务结论"是幻觉的温床，且会污染整个知识库。

没有业务用户介入：考古能还原 90%，剩下 10% 的"为什么"只存在于人脑——W6 起必须引入真实用户确认口径。

追新技术栈：重建的目标是再稳定跑 10 年 + 你自己和 agent 都熟，不是简历好看。

11对你当前两个实践的判断

你说"不要受目前实践影响，还没找到感觉"——我的判断是：方向都不坏，但都停在了到达价值的一半路程上。

① 项目计划管理模块（新系统练手）

开发方法本身没问题，问题在命题选错：它只能验证"AI 能做出一个系统"，验证不了"AI 能替代旧系统"。不需要推倒重来——把它当作脚手架与工程纪律的试验田保留，然后按 §6 换一个可对账的切片（报销）去回答真正的命题。

② Oracle .dmp 查看 Web 工具

这个工具的直觉其实非常准——数据是业务真相的另一半，而且它比代码更诚实（代码说"应该"，数据说"实际"）。但不要停在"能查看"，按本方法论的路线升级它：

从"查看 dmp"升级为自动化数据画像：每张表的行数、字段取值分布、状态字段的频数（状态机考古的数据视角全靠它）。
升级为表 → 业务实体映射工作台：表结构字典（Phase 0 底表⑤）从这里直接导出。
最终升级为 §7 的对账平台：新旧系统差异比对是它最自然的产品形态。

"感觉"到底去哪找你缺的感觉，本质是闭环：从"能看、能做"到"能证明对"。这个闭环 = 知识库 → 规格 → 切片 → 对账 → 退役。一旦报销切片在平行运行里对出连续零差异，你就会得到那种感觉——因为它不再是感觉，而是证据。