这是我们客户2026年开年时的真实处境。老旧系统解耦重构，也是是每一个 CIO 必须面对的问题。

ERP 解耦有个公开的秘密：重构编码只占20%工作量，剩下80%是“搞懂老系统到底干了什么”。

一个 ERP 标准包，资深顾问读明白需要2到3天。312个标准包，加上170多个客户化包，排着队干要两年。两年之后，业务需求早变了。

我们客户给这个阶段起了个名字

“代码考古”

系统里沉淀着十年的业务逻辑：哪些逻辑是必须的，哪些是历史遗留，哪些是为了绕过某个已废弃的逻辑打的补丁。没人知道。400 多个 PL/SQL 包像一个个上了锁的黑箱子，排成一排，等你一个个撬开。

2026年2月，项目启动。

汉得与客户联合项目组做了个决定

“让 AI 来干考古的活”

市面上讲 AI 赋能 IT 项目的文章很多，但我们很快发现一个事实：AI 裸用就是个高级聊天框。同一个问题问两遍，给你两个不同的答案。在 ERP 系统解耦面前，这种不确定性是致命的——复杂调用链中一个逻辑编造，你根本不知道错的在哪里。

所以项目没急着上 AI 写代码，而是搭了一套 AI Harness 工程框架，替代人工读包环节。具体干三件事：

所有 ERP 标准包逻辑代码从数据库自动导出、结构化解读，170多个客户化包按业务领域分类提取核心逻辑，19类业务对象定义从 ERP 表的 HTML 快照自动转成标准化文档。AI 要回答问题，先给提供充分的可读取信息来源。

明令禁止 AI 编造表名、列名、JOIN 条件。所有 SQL 字段必须可溯源到业务对象定义文件。违规时 AI 必须停止并告知用户。所有解读出来业务逻辑链接到源代码包与代码行数，规则解决了一个真实痛点：AI 解读时编造字段，编造逻辑，在 ERP 这种庞然大物里，排查成本极高。

13个 AI 技能，每个负责一个具体环节——有的读 PL/SQL 包，有的分析调用链路，有的写重构设计文档，有的评审文档质量，有的自动调接口做双端数据对比。将解耦重构设计中的 AI 协作方式方法，融合在日常工作流程中的技能使用中。

这三件事合起来，叫 Harness

一个让 AI 从“聊天工具”

变成“项目基础设施”的工程框架

有了共享知识底座，团队开始跑流程。先让 AI 自动解读400多个包。两年的人工工作量，压缩到两个月。顾问不用再读代码了，可以集中精力判断业务逻辑对不对，是否裁剪或保留。

然后是194份设计文档的自动生成。每份文档包含 API 定义、参数映射、业务约束、测试用例。 AI 写完，自己评审。评审六维深潜，逐业务约束对比标准包源码与设计文档差异，找缺失校验、矛盾逻辑、不可达路径，携带改进建议由产品决策。

通过 Skill 沉淀团队评审经验，一份 “投料单物料新增与修改”文档，三轮评审下来，累计发现39项设计缺陷。其中“变更物料时操作类型判定逻辑矛盾”这个问题，涉及三个参数的交叉组合逻辑，人工评审几乎不可能发现。

传统项目里，设计文档质量靠“感觉还行”。在这个项目里，质量变成了数字——89%的异常场景校验拦截率，单份文档累计发现30个以上设计缺陷。

团队通过 AI 自动化测试 skills，AI 自组织测试数据，自动调用 API 执行逻辑，等待 ERP 同步，然后查询解耦领域和 ERP 两边的数据库，逐字段对比差异。27条用例跑完，自动发现了11个 Bug。其中的典型：

最核心的转变是“确定性”——传统 ERP 解耦项目最大的风险是做完了但不知道对不对，代码是新的，业务逻辑对不对没人说得准。

AI 自动化测试提供了一层确定性保障：通过 AI 组织数据执行新旧系统的代码逻辑并核对数据一致性，Bug 由自动化测试自动发现，非手工构造。

设计阶段有评审拦截，测试阶段有双端对比， Bug 修复后有自动复测。质量在整个链条上可追溯、可度量。

通过 AI Harness 工程提供了从设计、开发到自动化测试的全链条质量保障，可追溯、可度量，大幅提升解耦效率。

设计文档生成、六维评审、API 测试、双端对比、Bug 登记、复测验证，六个环节形成完整质量闭环。几组数字值得记住：

312个标准包解读

从两年压到两个月

194份设计文档

从一年压缩到三个月

单个文档39项设计缺陷

在写代码之前就被发现和修复

传统 ERP 是一座知识黑箱，核心业务逻辑深锁在 PL/SQL 包中，靠资深 IT 人员的私域认知。

本次项目在推动系统解耦的同时，完成了一件更具远期价值的事——用本体的方法，把隐性的领域知识显性化，构筑起企业运营知识本体。

在本体视角下，工单被明确定义为制造业的核心业务实体。围绕它，我们厘清了工单的类型、生命周期状态，以及它与工序、物料需求、资源等实体之间的关联与约束。

过去，这些知识全部裹挟在 `WIP_JOB_DETAILS` 包3000行代码里，查询、创建、状态变更、发放、完工、反冲，一步一坑。

现在，我们基于本体模型实施服务能力 API 化——不是简单地把表暴露成 REST 接口，而是按“业务能力”拆解和封装 API。

以“工单创建”为例，这一能力背后聚合了 WIP_ENTITIES 等四张表、三道状态校验、两轮数据展开，最终被凝练成一个契约清晰的接口：`POST/v1/organizationId/discrete-jobs/createWorkOrders`，入参明确、返回清晰、错误码可枚举。

整个项目共沉淀190个标准化 API，覆盖工单管理、基础设置与数据同步三大领域，每一个 API 就是一个独立、可调用的业务能力原子。

这意味着，制造领域的专业知识不再锁在少数人脑里，而是存在于一个结构化、可检索、可引用的知识空间中——这正是一个可被人与机器共同消费的领域本体。

新人两周可上手，AI 30分钟就能读透。我们把这种状态称为 “Agent Ready” 。

未来，任何一个 AI Agent 要进入工单业务，再也不必去啃老旧的 PL/SQL 代码，也无需到处问人：

打开知识空间，即可理解所有业务对象的定义与关系；浏览 API 清单，就能知道有哪些能力可供调用；查阅设计文档，便能掌握业务逻辑约束。

这就是 Agent 化的基础准备——给它一个结构化的业务世界模型，和一套按能力组织的 API 工具箱。没有这两样，Agent 面对 ERP 就是盲人摸象；有了这两样，Agent 就能化身一位不经培训、永不离职的数字员工。

太多 ERP 解耦项目只做到“把代码搬出来”，却忘了把搬出来的东西整理好。

解耦像是拆房子，而 API 化与知识本体化，则是把拆下的砖瓦分类编号、画成图纸。不做这后一步，下一次改造依然要从“考古”重新开始。

我们选择在当下就完成企业运营知识本体的构建，把业务的“活灵魂”从代码遗迹中解放出来，为 AI 时代的智能运营铺好认知基座。

携手汉得，共铸硬核竞争力！