Clean Core：AI 时代 ERP 系统的新门槛

当 ERP 的“死代码”击穿 AI 副驾驶

Klaus 在 2019 年退休。他留下的 ZSD_ORDER_FIX_V4 函数模块，唯一的文档是一行注释：// FIXME: remove after 2015 upgrade。现在是 2027 年，这个函数仍然在每一张销售订单进入交货流程时运行。

这不是技术债的哥特故事，而是当下企业 AI 落地的真实卡点。一个 CIO 发现，AI 副驾驶能草拟销售订单、建议交货日期，但当它触发定价引擎——三个自定义用户出口、一张 Z 表、以及 ZSD_ORDER_FIX_V4 的包裹逻辑——它没有报错，只是“看不见”了。屏幕上订单看起来正常，但仓库层面注定失败。

架构师对此给出了直白的解释：“模型从未训练过我们的 Z 逻辑。嵌入式代理无法调用未发布的函数模块。再多的提示工程也教不会它 ZSD_ORDER_FIX_V4 是做什么的，因为唯一的文档在 2019 年退休了。”

SAP ERP 中的几个关键术语

所谓 Z 命名空间，是 SAP 为客户自定义开发预留的命名空间。SAP 标准对象以特定字母开头（如 MARA、VBAK），而任何以 Z 或 Y 开头的程序、表、函数模块，都是客户自己创建的。ZSD_ORDER_FIX_V4 中的 Z 表示自定义，SD 指销售与分销（Sales and Distribution）模块，V4 暗示这是第四个版本。Z 对象数量是衡量“扩展债务”的直接指标。

用户出口（User Exit） 是 SAP 在标准流程中预留的钩子点，允许客户插入自定义逻辑而不修改标准代码。BAdI（Business Add-In）是其面向对象化的现代替代，支持多次实现和版本管理。两者区别在于：用户出口是“民间传说”式的隐式扩展，BAdI 是有契约、可发布的扩展点。

BTP（Business Technology Platform）是 SAP 的云平台，用于在核心系统之外构建扩展、集成和数据应用。把差异化逻辑迁移到 BTP，正是让自定义代码“有契约”的物理载体——BTP 上的服务通过已发布 API 与 S/4HANA 核心对话。

为什么 AI 改变了算术：从年度升级成本到持续利息

过去二十年，“Clean Core”一直是 SAP 营销幻灯片上的口号，被那些靠二十年 Z 代码维持运转的客户礼貌地忽略。自定义代码曾经不是技术债，而是 ERP 适配业务的方式。

但 AI 的入场改变了成本结构。以前，自定义代码的代价发生在升级时刻，大约每年一次，账单是测试工作量。现在，代价是持续性的——每一个 AI 功能、每一个嵌入式代理、每一个“智能”特性，都是为标准流程设计的，对你的自定义逻辑耸耸肩。扩展债务没有增长，但利率上升了。

这里有一个核心洞察：AI 可以与任何有契约的东西协作。它无法与“民间传说”协作。Clean Core 就是将传说转化为契约的过程。

Clean Core 不是清除，而是划清边界

对 Clean Core 最常见的误读是“不允许任何自定义代码”。实际上它意味着：自定义代码生活在核心之外，通过已发布的 API 与核心对话，让标准行为保持标准。业务真正需要的差异化逻辑不会消失——它迁移到 BTP 一侧，或进入为升级而设计的扩展点，那里有文档、有版本，而且——关键的是——任何能读取 API 的东西都能看见它。

那么，你的 Z 命名空间里实际上有什么？根据行业迁移评估的典型分布：

类别	典型占比	命运
死代码，未使用	~45%	删除。无需传输。
与标准重复	~25%	退役。使用标准对象。
可平凡替换	~20%	通过公共 API / BAdI 重写。
真正差异化	~10%	移至 BTP 扩展 / 并行侧。赋予它契约。

从这个角度看，Clean Core 本质上是一个库存问题：你的 4,000 个自定义对象中，哪些编码了真正的竞争优势，哪些只是 2007 年对 SAP 在 2015 年已修复限制的变通方案？我们看到的所有迁移评估都指向同一个结论——绝大多数自定义代码要么已死，要么重复标准，要么可平凡替换。真正差异化的那一小部分值得严谨的工程化处理。其余的都只是带着传输编号的风险。

Clean Core 的官方定义与技术边界

SAP 对 Clean Core 的定义包含三个层次：无修改（No Modifications） 指不直接改标准代码，这是底线；无隐式扩展指不依赖未发布的内部接口、表或函数模块，因为这些对象在升级时可能被静默替换；有契约的扩展指所有自定义逻辑通过已发布 API、BAdI 或 BTP 服务与核心交互，接口有版本、有文档、可发现。

这个定义的关键在于“可发现性”。AI 代理和任何外部工具只能调用已发布、有元数据描述的接口。未发布的函数模块在 ABAP 层面存在，但在 API 网关层面不可见——这就是副驾驶“看不见” ZSD_ORDER_FIX_V4 的技术原因。Clean Core 不是美学要求，而是让核心系统对 AI 和其他自动化工具具备可观测性和可调用性。

诚实排序：如何开始而非一次性清洗

陷阱在于将 Clean Core 视为一个独立的“美德项目”——没有人会为卫生习惯拨款。只有当它与业务已经想要的东西挂钩时才会推进：S/4 迁移、新的 AI 能力、运营模式变革。实际顺序并不光鲜：

1. 运行使用审计。 事务代码 /UI5/UI2_CUST_ANALYSIS（或你的工具）——过滤“最后执行 > 365 天”。这些优先处理。
2. 删除死重。 不搞仪式。不“以防万一”。如果一年没运行，它就不是差异化——它是民间传说。
3. 应用前瞻规则。 新逻辑放在核心之外，除非有书面理由说明不能。“我们一直这样做”不是理由。
4. 为幸存者订立契约。 对于保留的约 10%：在移动代码之前先写 OpenAPI 规范。如果你无法描述接口，你就不理解需求。

你无法在一个项目中清理二十年的积累。你只能停止让它变得更糟，让时间发挥作用。做对这件事的公司不是拥有最纯净系统的公司，而是能够对任何一段自定义逻辑回答三个问题的公司：它做什么、为什么存在、什么 API 可以替代它。在 ERP 世界里，AI 就绪的样子就是这个答案。模型会自行持续改进。你的 Z 命名空间不会。

仍然有人需要给 ZSD_ORDER_FIX_V4 写文档。AI 不会写。问题是你是在下一个副驾驶到来之前写，还是在它再次失败之后写。

使用审计工具与迁移评估的实操背景

文中提到的 /UI5/UI2_CUST_ANALYSIS 是 SAP 提供的自定义代码分析工具之一，属于 SAP Readiness Check 和 Custom Code Migration 工作流的一部分。它能扫描 ABAP 仓库，标记未被使用、与标准重复、或依赖已弃用 API 的对象。更完整的工具链还包括 SAP Custom Code Migration App（基于 ABAP 测试驾驶舱）和 ATC（ABAP Test Cockpit）检查变式，后者可检测 S/4 不兼容语法和已弃用对象。

审计的核心指标是 最后执行时间戳。ABAP 系统会记录程序、函数模块和事务代码的最后运行日期。过滤“最后执行 > 365 天”是一个务实阈值：一年未运行的代码几乎不可能是当前业务差异化逻辑。但需注意，某些代码只在年度结算或极端异常时触发，因此审计结果仍需业务确认，不能机械删除。

OpenAPI 规范先行 的意义在于：在移动代码之前，先用标准接口描述语言定义其行为契约。如果团队无法为一段逻辑写出 OpenAPI 文档，说明他们不理解这段逻辑的真实需求——这正是 ZSD_ORDER_FIX_V4 困境的根源。

常见问题

Clean Core 意味着完全不能有自定义代码吗？

不是。Clean Core 意味着自定义代码存在于核心之外，通过已发布的 API 与核心交互，让标准功能保持标准。差异化逻辑迁移到 BTP 扩展点，获得契约和版本管理。

为什么 AI 副驾驶对自定义 ERP 逻辑“视而不见”？

AI 模型没有在企业的 Z 逻辑上训练过，嵌入式代理无法调用未发布的函数模块。如果没有文档和契约，模型无法理解自定义代码的行为，导致建议看似正常但实际会失败。

企业应该从哪一步开始 Clean Core？

从使用审计开始。识别一年以上未运行的代码优先删除，然后对保留的差异化逻辑编写 API 契约。将 Clean Core 挂在 S/4 迁移或 AI 能力引入等业务目标上，而非作为独立项目。