旧系统很大
一个真实、长期演化的 Delphi 桌面项目，不是教学示例。
BIG LEGACYMIGRATION WORKBENCH · DESIGN
INDEXRETROSPECTIVE DESIGN已经实现，再把设计补完整
Delphi →
Spring Boot
业务逻辑迁移工作台
把“一次不确定的 AI 转换”，重构成一条有边界、有证据、可停止、可复核的迁移生产线。
LEGACY / DELPHIBEHAVIORTARGET / SPRING BOOT
DESIGN
21 SLIDES
21 SLIDES
00 / ORIGINAL REQUEST起点非常朴素
最开始，我们只有
三个确定条件。
目标不是空项目
迁入已经二次开发过的 Spring Boot，必须服从现有框架。
EXISTING TARGET前端不自动迁移
现有 Web 画面由人工对应，工具只负责后端业务逻辑。
BACKEND ONLYDelphi UI不迁业务行为要迁Spring 框架要服从
01 / THE FALSE START为什么前几次都不满意
“换一种语言”
从来不是核心问题。
01语法能翻译
但 UI 事件与业务规则混在一起。
02代码能生成
但不知道哪些由新框架接管。
03测试能补
但没有旧系统真实结果做基准。
04AI 会说完成
但“看起来正确”不是验收证据。
CODE TRANSLATION ≠ SYSTEM MIGRATION
02 / REFRAME改变问题，才有可能稳定
不要问
→怎么把 Delphi
翻译成 Java？
应该问
怎样证明旧业务行为
在新框架下仍然成立？
源码证据＋迁移决定＋业务 Case＋真实执行＝可接受迁移
03 / SCOPE CONTRACT先决定不做什么
迁移边界，是第一个产品。
DELPHI
桌面实现
Form / DFM按钮与控件事件入口业务方法DataModule / SQL筛选层UI → RETIREEVENT → REPLACERULE → KEEPGAP → ADD
SPRING BOOT
既有 Web 系统
固定画面Controller 路由Service / DomainRepository / 事务统一异常与认证前端人工对应，不等于忽略 UI；UI 事件仍然是寻找业务入口的重要证据。
04 / DEFINITION OF DONE成功必须先被定义
我们不保证 AI 不犯错。
我们保证错误不能冒充成功。
01
迁移决定已经人工批准
BOUNDARY02
启用 Case 已确认且旧侧基准存在
BASELINE03
写入文件全部属于计划与允许目录
TRACE04
旧新 Case 全部一致，新侧追加 Case 全部通过
PROOFNO EVIDENCE→NO SUCCESS
05 / PRODUCT ARCHITECTUREAI 只是其中一层
四层结构，把概率能力
包进确定性控制。
AI GENERATIONCodex / Claude / 本地规则
分析建议、Case 草案、计划、代码候选
CONTROL PLANE状态机 / Schema / 人工门禁
什么能继续，什么必须停止
EVIDENCE PLANE逻辑图 / 契约 / Case / 基准 / 比较
每个阶段留下可复核产物
LOCAL RUNTIMEElectron / Runner / Git / 文件系统
在用户机器上执行，不要求托管旧代码
06 / THE CONTROLLED LOOP七阶段最小闭环
每一步都有输入、产物和门。
分析 Delphi
Form / 事件 / 方法 / SQL
→映射 Spring Boot
保留 / 替换 / 废弃 / 新增
→设计业务 Case
一个业务分支，一个 Case
→固定 Delphi 基准
记录真实输入与可观察结果
→生成实装计划
层 → 任务 → Case → 允许目录
→实现业务逻辑
受控写入、执行、修正
→业务等价比较
一致 / 差异 / 未执行
重新执行上游→下游自动过期→拒绝使用陈旧证据
07 / SOURCE EVIDENCE从 UI 线索进入业务深处
先把 Delphi 变成
一张可以追问的逻辑图。
DFMOrderForm画面
→EVENTSaveButtonClick按钮事件
→METHODValidateTotal业务规则
→DATASaveOrderDataModule
SQLUPDATE orders持久化副作用
静态解析 v1识别 .pas / .dfm / 方法 / 调用 / SQL达到扫描上限时，系统阻止形成完整成功结论
08 / FRAMEWORK SCREENING旧系统不是全部照搬
每一个旧侧行为，
必须得到一个明确决定。
KEEP保留纯业务规则旧新语义必须一致
REPLACE框架替换事件、DataModule、SQL实现改变，行为保留
RETIRE废弃Delphi Form / 控件前端人工对应
ADD新增目标框架强制能力仅新侧验收
MANUAL待决定证据不足的行为阻止后续流程
AI 负责提出建议→人负责批准边界→未决定项阻止下流
09 / BEHAVIOR CONTRACT把“大系统”切成可证明的小单元
一个业务状态 × 一个分支
× 一个终点结果。
ARRANGE
库存存在
订单未锁定ACT / INPUT
saveOrder
total = 100ASSERT
returnValue
businessError
databaseChangesCLEANUP
回滚测试数据
恢复独立状态Case 描述业务操作，不描述 Delphi 按钮坐标，也不绑定 Web DOM。
10 / LEGACY BASELINE旧系统必须真正跑一次
没有旧侧执行结果，
就没有“等价”可比较。
$ runner --case CASE-042.json
exitCode 0
returnValue true
businessError null
databaseChanges orders:1
baseline captured ✓INPUTCase 定义operation / arrange / input
→EXECUTIONDelphi Runner真实命令、超时、退出码
→OUTPUT固定基准JSON 可观察结果
11 / PLAN TRACEABILITY“按计划执行”不靠一句提示词
计划必须一直追踪到
最后一个修改文件。
LAYERService 接入
→layer-serviceTASK映射保存入口
→task-save-orderCASE保存订单分支
→CASE-042 / 043FILEOrderService.java
src/main/java/…虚构 taskId：拒绝Case 不属于任务：拒绝文件超出计划目录：拒绝任务无归属：不能成功
12 / DETERMINISTIC GATES概率生成，确定性执行
六道门，把 AI 的自由度
压缩到安全范围。
范围
允许目录保护目录优先
状态
人工批准草案不能下流
仓库
Git 必须干净写入前备份
执行
有限迭代超限即停
证据
真实 Runner未执行不算通过
追踪
任务 / Case / 文件计划外写入拒绝
安全不是提醒 AI 小心而是让不符合规则的结果无法被执行。
13 / CONTROLLED ITERATION失败是下一轮输入，不是被隐藏的噪声
生成 → 执行 → 比较 → 修正，
直到通过或明确停止。
CASE
EVIDENCE同一批业务 Case
EVIDENCE同一批业务 Case
01AI 候选实现
02受控文件写入
03Spring Runner
04差异回馈
全部 MATCHED → 接受／达到轮数上限 → BLOCKED／异常 → 点击状态查看详情
14 / SUCCESS METRICS通过率不能脱离覆盖率
“Case 全绿”之前，
先问有没有遗漏 Case。
业务节点决定覆盖率
已有决定的旧侧业务节点
÷ 已识别业务节点Case 覆盖率
已确认 Case 覆盖节点
÷ 要求迁移的业务节点旧新一致率
结果一致的双侧 Case
÷ 已执行双侧 Case误报成功率
下游失败却被判成功
目标：0100% 一致 ≠ 100% 业务覆盖因此遗漏节点、待决定项、扫描截断都会单独阻止成功结论。
15 / FINAL COMPARISON最终交付是一览，不是一句“完成了”
每个 Case 都有状态，
每个状态都能打开证据。
CASE-042REPLACE
{ok:true, rows:1}{rows:1, ok:true}MATCHEDCASE-043KEEP
{error:"LOCKED"}{error:"LOCKED"}MATCHEDCASE-044REPLACE
{total:80}{total:100}DIFFERENTCASE-045ADD
target-only—NOT RUN16 / THE ACTUAL APP设计最终落在一个桌面工作台
不是聊天窗口。
是一台迁移控制台。
MIGRATION PROJECT
真实命令执行订单系统业务迁移
Delphi 旧工程 / READ ONLYSpring Boot 既有工程 / CONTROLLED
01分析 Delphi已完成
02映射 Spring Boot已完成
03设计业务 Case已完成
04固定 Delphi 基准已完成
05生成实装计划执行中
06实现业务逻辑未执行
07业务等价比较未执行
提示词可编辑 · 结构化产物可查看 · 失败状态可展开 · 模拟与真实证据明确区分
17 / WHY NO AGENT FRAMEWORK当前足够，比“技术更热闹”更重要
我们没有为了 AI，
再套一层通用 AI 框架。
CURRENT
专用阶段式执行框架
状态机、产物、门禁、Runner、比较器，全部围绕迁移问题设计。
- 流程固定
- 错误可定位
- 证据可持久化
- 离线可退化
LATER, IF NEEDED
通用 Agent 框架
只有出现跨机器队列、海量并行、长期恢复、多专业 Agent 协作时再引入。
LangChain? AutoGen?
Semantic Kernel?框架选择的标准：它是否减少不确定性，而不是它是否看起来更像 AI。
18 / HONEST BOUNDARIES设计也要说明它不能证明什么
当前闭环可用，
但它不是魔法。
01
解析器不是 Delphi 编译器
当前以静态规则识别逻辑；特殊语法需要扩展。
02
Case 完整性仍需人负责
工具能显示遗漏，但真实业务输入仍来自领域知识。
03
Runner 必须由项目提供
旧侧与新侧都需要稳定、可重复的执行入口。
04
目标工程原有测试仍要通过
业务等价之外，还有构建、迁移、代码评审与人工验收。
我们交付的不是“必然成功”，而是不会悄悄失败的迁移过程。
19 / DESIGN IN ONE SENTENCE从概念走到实际
D→S
把遗留系统迁移，
从一次 AI 猜测
变成一条证据链。
理解旧侧→筛选边界→固定行为→受控实现→证明结果
AI 负责提高速度；框架负责限制自由；Case 与真实执行负责决定是否成功。
01 / 21
按空格开始 · 方向键翻页 · F 全屏 →