Clean Core
SAP 主推的架构原则，要求保持 S/4HANA 标准内核不被修改，所有扩展通过 released API、BTP 扩展框架或 side-by-side 扩展实现，以确保系统升级时内核可平滑演进。
时间轴 (近 90 天)
SAP的社区指南承认，旧的二元视角（Clean Core vs. 不Clean）对于拥有大量经典自定义代码的系统来说过于严格。
ABAP Test Cockpit（ATC）是 SAP 内置的静态代码检查框架，可识别语法风险、性能反模式、安全漏洞以及不符合 Clean Core 规范的用法，产出必须重写和可降级/废弃的对象清单。
自定义代码修复（为符合 Clean Core 原则）可能导致一次性 20 万至 400 万美元的成本，差异几乎完全取决于自定义代码的构成而非数量。
行业迁移评估的典型分布显示，企业自定义代码中约 45% 是未使用的死代码，约 25% 与标准重复，约 20% 可平凡替换，约 10% 是真正差异化逻辑。
审计结果仍需业务确认，不能机械删除，因为某些代码只在年度结算或极端异常时触发。
Clean Core 的推进应挂钩 S/4 迁移、新 AI 能力或运营模式变革等业务目标，而非作为独立的“美德项目”。
企业无法在一个项目中清理二十年的自定义代码积累，只能停止让它变得更糟，并让时间发挥作用。
在移动代码之前，先用 OpenAPI 规范定义其行为契约；如果团队无法为一段逻辑写出 OpenAPI 文档，说明他们不理解这段逻辑的真实需求。
Clean Core 的官方定义包含三个层次：无修改（不直接改标准代码）、无隐式扩展（不依赖未发布的内部接口、表或函数模块）、有契约的扩展（所有自定义逻辑通过已发布 API、BAdI 或 BTP 服务与核心交互）。
AI 可以与任何有契约的东西协作，但无法与没有文档和契约的“民间传说”式扩展协作；Clean Core 就是将传说转化为契约的过程。
还有 2 条时间轴事件
全部知识事实 (12)
SAP的社区指南承认，旧的二元视角（Clean Core vs. 不Clean）对于拥有大量经典自定义代码的系统来说过于严格。
50%待验证ABAP Test Cockpit（ATC）是 SAP 内置的静态代码检查框架，可识别语法风险、性能反模式、安全漏洞以及不符合 Clean Core 规范的用法，产出必须重写和可降级/废弃的对象清单。
50%待验证自定义代码修复（为符合 Clean Core 原则）可能导致一次性 20 万至 400 万美元的成本，差异几乎完全取决于自定义代码的构成而非数量。
50%待验证行业迁移评估的典型分布显示，企业自定义代码中约 45% 是未使用的死代码，约 25% 与标准重复，约 20% 可平凡替换，约 10% 是真正差异化逻辑。
50%待验证审计结果仍需业务确认，不能机械删除，因为某些代码只在年度结算或极端异常时触发。
50%待验证Clean Core 的推进应挂钩 S/4 迁移、新 AI 能力或运营模式变革等业务目标，而非作为独立的“美德项目”。
50%待验证企业无法在一个项目中清理二十年的自定义代码积累，只能停止让它变得更糟，并让时间发挥作用。
50%待验证在移动代码之前，先用 OpenAPI 规范定义其行为契约；如果团队无法为一段逻辑写出 OpenAPI 文档，说明他们不理解这段逻辑的真实需求。
50%待验证Clean Core 的官方定义包含三个层次：无修改（不直接改标准代码）、无隐式扩展（不依赖未发布的内部接口、表或函数模块）、有契约的扩展（所有自定义逻辑通过已发布 API、BAdI 或 BTP 服务与核心交互）。
50%待验证AI 可以与任何有契约的东西协作，但无法与没有文档和契约的“民间传说”式扩展协作；Clean Core 就是将传说转化为契约的过程。
50%待验证Clean Core 是 SAP 近年主推的架构原则，核心要求是保持 S/4HANA 标准内核不被客户修改（不改标准代码、不直接写标准表），所有扩展通过 released API、BTP 扩展框架或 side-by-side 扩展实现。
50%待验证Clean Core的承诺是升级不破坏标准功能，配合持续改进交付模式，使AI扩展一旦建立不会因下次升级而推倒重来。
50%