信创改造的工程能力不该锁死在某个 AI 工具上，在 Codex 和 DeepSeek Harness上的实践

上篇文章结尾我承诺：下一篇讲讲"这两个工具我都实际拿来跑过真实老系统的信创改造"。

这篇交作业。但动笔前，我得先纠正一个可能误导你的点——这篇不做"Codex 和 DSH 谁强"的硬对比。

原因是：我两次用它们的改造范围本来就不一样——Codex 那次，我要求的架构升级点更多，是一轮"深度使用"；DSH 那次，只要求升级 JDK、Tomcat 和国产数据库，是一轮"轻量验证"。先决条件不一致，硬比既不公平，也会得出错误结论。

那这篇讲什么？讲背后真正有价值的东西：一套能同时跑在 Codex 和 DeepSeek Harness 上的信创改造 Skills。

一、先认识它：一套信创改造的 Skills 平台

其实在做这个老系统的信创改造时，我不是"裸用" Codex 或 DSH，而是先把改造方法沉淀成了一套 Agent Skills。

这套东西我叫它 itai-agent-skills，一个面向金融、保险行业老系统的信创改造智能体平台。核心是 13 个 Agent Skills，最关键的是头两个：

• 01 号 Skill · 项目分析：扫源码、识别架构分层、清点实体，输出项目 WIKI 和代码结构树；

• 02 号 Skill · 适配方案：基于分析结果和你确认的改造范围，动态生成适配方案、检查清单和改造计划。

后面还有 03 规则库、04 Maven/JDK 升级、05 Spring/MyBatis 接入、06 DB 层改造、07 BL 层改造、08 Command/UI 适配、09 JSP 兼容、10 配置部署、11 审核、12 存储过程迁移、13 WebService 迁移等——串起来就是一条"项目分析 → 适配方案 → 规则准备 → AI Coding → 审核交付"的完整流水线。

它还有一个更重要的设计：先方案、后代码（SPEC 模式）——编码前先对齐"改什么、怎么改、风险在哪"，每个关键决策（数据库选型、JDK 升级、框架选择）用询问的方式选择逐项确认，决策都记录在案。方案先行，编码才不会跑偏。

二、把这套 Skills 放到 Codex 上，做一次深度使用

先看 Codex 这一路。

我把上面这套 Skills 喂给 Codex，并且这次人为要求的改造点更多——要覆盖架构升级、依赖调整、事务改造、ORM 引入、SQL 改造、周边系统解耦、数据迁移、存储过程等一系列专项。

结果是，Codex 配合这套 Skills，交出了一套很完整的方案包：一份"研发指导方案"把九大改造专项写到了命令级，外加方案汇报、影响矩阵、工作量、WBS、风险，和一份检查清单。

由于涉及公司机密，不给大家呈现更多细节了

这里要强调一句：这份深度，来自"Skills 的编排 + 我要求的多改造点"，而不是"Codex 天生更强"。 换个底座、喂同样的 Skills、给同样的要求，理论上也能到这个深度。

三、再把这套 Skills 放到 DSH 上，做一次能力验证

再看 DSH 这一路。

这次我换了个轻量目标：只想验证"DSH 这个底座，能不能承载起这套 Agent Skills"——所以只要求了 JDK 升级、Tomcat 替换、国产数据库迁移这几个点。

结果是，DSH 同样跑通了整条链路：01 号 Skill 分析出了项目 WIKI，02 号 Skill 生成了适配方案、检查清单和改造计划，后续的迁移说明、审核报告也都出来了。

它证明了我要验证的那件事：这套 Skills 不挑底座。

四、真正想说的结论：底座可换，能力不能丢

把两次合起来看，结论其实很清楚：

同一套信创改造 Skills，跑在 Codex 上能深度交付，跑在 DeepSeek Harness 上也能完整跑通。

这背后，正是上一篇《Codex vs DeepSeek Harness》里"一切皆插件"的落地版——当你的工程能力沉淀成 Skills，它就不再绑定某个模型或某个工具；底座（Codex / DSH / 别的）可以换，能力不丢。

所以别再纠结"哪个工具更强"。真正该沉淀的，是属于你自己的那套 Agent Skills——那才是不会被淘汰的资产。

五、交个底

这套 itai-agent-skills，就是我一直打磨的"信创改造智能体平台"：13 个 Skills + 规则库 + 模板 + 脚本，先方案后代码，支持 Oracle → 达梦 / OceanBase / Kingbase 等多条国产化迁移路线，已经在真实老系统上验证过，而且我们还在持续完善与优化！

面向保险、银行这类信创压力大、存量系统多的行业。