0029 COBOL → Java 转译重构闭环评价工程方案

date

May 8, 2026

summary

COBOL → Java 转译重构闭环评价工程方案

status

Published

COBOL → Java 转译重构闭环评价工程方案

一、问题定位

要素	内容
输入	COBOL 主机代码（批处理/联机事务）
输出	Java（Spring Boot 框架）
模型	内部部署模型，能力弱于 GPT/Claude
核心矛盾	模型能力弱 → 产出错误多 → 需严格闭环校验
红线	源代码不出内网

二、整体架构

三、阶段详解

Stage 1：预处理与 COBOL 源码分析

目标：在转译前理解 COBOL 程序结构，为后续评价建立基线。

步骤	操作	产出
1.1 源码解析	扫描 COBOL 程序，识别 divisions/sections/paragraphs	程序结构树
1.2 数据流提取	提取 FILE SECTION、WORKING-STORAGE、LINKAGE 定义	数据字典
1.3 逻辑片段分割	按 paragraph 拆分为独立逻辑单元	逻辑片段列表
1.4 依赖分析	识别 CALL、COPY、JCL 依赖关系	依赖图谱
1.5 测试基线录制	用典型输入运行原 COBOL 程序，录制输出	I/O 基线用例

工具：自研 Python 脚本解析 COBOL 结构（无需外部工具，依赖正则 + 简单解析器）。

关键产出文件（每个程序一份）：

Stage 2：模型转译（可迭代）

目标：将 COBOL 逻辑片段输入本地模型，生成 Java 代码。

步骤	操作
2.1 提示词模板	每段按统一模板：`COBOL源码 + 数据字典上下文 + Spring Boot约束/内部技术规范约束 + 输出格式要求`
2.2 批量转译	按依赖顺序逐段提示模型
2.3 结果组装	将各段 Java 输出按依赖关系组装为完整项目

输出：标准 Maven 项目结构，含 pom.xml、application.yml、实体类、Service、Controller。

Stage 3：静态验证（快速失败）

目标：用最低成本拦截明显错误，减少后续阶段无效工作。

检查项	方式	通过标准
3.1 编译检查	`mvn compile`	零编译错误
3.2 代码规范	团队 CheckStyle/SpotBugs 规则	无阻断项
3.3 结构完整性	扫描 Controller/Service/Repository 是否匹配设计	无缺失
3.4 空指针风险	静态分析识别未判空变量	高风险项为 0

失败处理流程：

关键设计：错误的反馈必须结构化，而非简单将错误日志原文丢给模型。结构化为：

Stage 4：动态验证（单元测试）

目标：验证每个 Java 方法的逻辑正确性。

步骤	操作
4.1 生成测试用例	基于 COBOL 的分段逻辑，构造典型输入/预期输出
4.2 执行测试	`mvn test`
4.3 覆盖率检查	行覆盖率 ≥ 80%，分支覆盖率 ≥ 70%
4.4 失败分析	比对预期输出与实际输出，定位逻辑差异

测试数据来源：Stage 1 录制的 I/O 基线 + 等价类/边界值构造。

失败处理：

Stage 5：行为等价校验（核心环节）

目标：在系统层面验证 COBOL 原程序与 Java 程序对同一输入的输出是否一致。

方法：

差异分级：

级别	定义	处理方式
L1: 格式差异	空格、换行、小数位	自动标准化后重新diff
L2: 等价差异	输出值等价但表达方式不同（如 `1.0` vs `1`）	模型修正
L3: 逻辑差异	输出值不同	人工介入审核
L4: 遗漏差异	缺少某个输出字段或记录	人工介入审核

关键点：此阶段依赖 Stage 1 录制的 I/O 基线质量。基线越全，等价验证越可靠。

Stage 6：人工审核

目标：弥补自动验证无法覆盖的语义和业务逻辑层面。

审核角色：

角色	职责	检查重点
代码审核员	代码质量、架构合规	Spring Boot 最佳实践、异常处理、事务边界
业务审核员	业务逻辑一致性	与 COBOL 原逻辑的业务语义是否一致

审核流程：

审核辅助工具：生成审核视图，将 COBOL 段与 Java 方法并排展示，标注自动验证通过/失败项。

Stage 7：评分与报告

目标：量化每个转译程序的质量，识别模型薄弱环节。

评分维度：

维度	权重	计分方式
编译通过率	15%	首次编译通过率
单测通过率	25%	通过用例 / 总用例
行为等价率	35%	diff 通过基线 / 总基线
人工审核分	20%	代码审核 + 业务审核综合评分
代码质量分	5%	CheckStyle/SpotBugs 违规数

反馈聚合：

四、工作流编排

单程序处理流程

批量处理模式

多个程序可并行处理 Stage 1（预处理），串行进入后续阶段。可配置同时进行中的转译任务数（建议 3-5 个）。

五、反馈闭环设计（核心）

结构化反馈格式

每轮反馈必须包含完整上下文，否则弱模型无法正确修复：

反馈策略

阶段内循环：Stage 3/4/5 发现问题 → 模型修复 → 重新验证，最多 N 轮（建议 3 轮）

阶段间降级：同一问题经 N 轮修复仍不通过 → 标记为"需人工介入"，跳过当前程序继续

知识积累：高频问题 + 解决方案整理为 Few-shot 示例库，用于优化模型的初始提示词

六、工程实施建议

技术栈选型（最小依赖）

用途	工具	理由
构建工具	Maven	Spring Boot 标配，无需额外安装
测试框架	JUnit 5 + AssertJ	Java 生态标准
代码规范	CheckStyle（团队规则文件）	单 jar，零依赖
I/O diff	`diff` 命令或 Python `difflib`	系统自带/标准库
工作流编排	Shell 脚本或 Makefile	零额外依赖
报告生成	Python 脚本	标准库即可
数据存储	JSON 文件 + 目录结构	无需数据库

角色与职责

角色	人数建议	职责
流程管理员	1	编排流水线、监控进度
代码审核员	2+	Spring Boot 代码评审
业务审核员	2+	COBOL/Java 业务逻辑一致性审核
模型调优员	1	基于反馈优化提示词和示例库

阶段交付物

阶段	交付物
Phase 1（本阶段）	方案设计文档
Phase 2	评价流水线原型（脚本 + 工具链搭建）
Phase 3	Pilot 试跑（选 3-5 个典型程序跑通全流程）
Phase 4	反馈闭环验证 + 迭代优化
Phase 5	规模化推广 + 流程固化

七、风险与应对

风险	影响	应对措施
弱模型修复能力不足	循环修复不收敛	设最大轮数 → 人工兜底 → 积累样例增强提示词
I/O 基线录制困难	等价校验无据可依	COBOL 程序插桩录制 / 业务人员手工构造测试数据
COBOL 程序规模大	单次全量处理周期长	按逻辑段拆分、并行处理
业务逻辑隐性知识	自动化无法覆盖	强化 Stage 6 业务审核环节、补充业务规则文档