北京
每一轮ECC迁移，真正卡住项目的往往不是预算，也不是数据库，而是那些没人看得懂的定制代码。几千个Z程序、用户出口、表单和报表，写了二十年，能讲清楚的人只有三个，其中两个已经离职。
SAP给出的新答案是：让AI智能体接手。相关议程已经排进10月27日至29日的SAP TechEd柏林站，线上版免费。需要说明的是，目前公开的只是议程，具体效果要等现场演示才能验证。
从SAP公布的ABAP场次清单看，这次的核心议题是"智能体主导的定制代码迁移"。SAP的场次描述里提到，定制代码迁移经常成为从SAP ERP Central Component迁往SAP Cloud ERP Private的瓶颈。工具链从SAP Cloud ALM里的规划环节起步，一路走到SAP Joule for Developers中定制代码迁移智能体所支持的"AI驱动的批量修复"。
配套场次还包括：用MCP工具从ECC迁移并现代化定制代码的动手工作坊；覆盖完整迁移生命周期的智能体助手；以及围绕ABAP Language Server和ABAP MCP Server展开的智能体主导开发。SAP给整条开发线定的调子是，从"AI辅助"走向"智能体主导"。
要判断一个智能体到底修好了什么，得先看SAP在2025年8月推出的清洁核心分级，它取代了原来的三层模型。
- A级：只使用公开发布、稳定的接口，有正式稳定性契约背书，在BTP上旁路构建，或在ABAP Cloud上栈内构建。
- B级：还会用到SAP的经典API和技术，有文档、通常升级稳定。
- C级：访问SAP内部对象，遗留场景下灵活，但带升级风险。SAP计划为SAP对象提供变更日志，便于提前发现变化。
- D级：不推荐。修改、对SAP表的写访问、隐式增强，SAP称其为最高风险，也是技术债的重要来源。
有个细节值得注意。SAP自己的社区指引承认，过去那种"清洁核心"对"非清洁核心"的二元划分，对拥有大量经典定制代码的系统来说"过于严格"。模型之所以改，是因为真实环境达不到旧标准。
治理层面，SAP推荐ABAP Test Cockpit，并表示SAP BTP上的集中式ATC是私有云和本地部署环境下治理清洁核心开发的推荐做法。
定制代码是客户解释迁移延期的常见理由之一。一位合作伙伴CEO对CIO.com表示，很多客户"因为Z代码和行业定制而卡在ECC上"。DSAG主席则提到环境复杂和技能短缺。日历也摆在那里：SAP称ECC的主流维护在2027年结束，扩展维护到2030年。
哪些活适合机器干？重复的、规则驱动的改动是合适对象，比如替换过时语句或调用、适配已知的简化数据模型、在数百个对象上批量修复同一模式。风险高的是那些意图只存在某个人脑子里的代码：一个悄悄修正业务规则的用户出口，一份带副作用的报表。凡是"能编译、能过ATC"不等于"业务结果还对"的地方，都得小心。过了技术检查的智能体，仍可能破坏业务结果。
所以现场该问的问题很具体：
- 不需要人工修改的修复占比是多少？样本有多大、是什么类型？在整洁代码上做的演示说明不了什么。
- 变更如何评审、测试和传输？智能体只是提建议，还是直接写进开发系统？
- 达不到A级或B级的代码怎么办？重写、退役，还是留在核心之外？
- 在特定版本和附加组件上表现如何？场次文本讲的目标是Cloud ERP Private，本地部署的S/4HANA也要问。
- 批量修复的运行成本是多少？有没有消费计费，失败的尝试谁来付？
- 智能体造成的变更引发事故时，谁负责？这个答案要落到书面上。
柏林之后想自己跑一轮试点，可以这样设计：先挑三组定制对象，一组简单、一组典型、一组难缠；在智能体动手之前，先估算人工工作量；跑完之后测量需要修改的数量、通过的测试、QA阶段发现的缺陷和投入的工时。合格线要在开始前定好，比如大部分修复无需修改即被接受、没有严重回归。结果出来后再定标准，等于骗自己。只放大通过验证的部分，把那组难缠的代码留作诚实的测试。
别用演示来判断这件事。演示用的是整洁代码。要看就看一个混乱系统里出来的数字：无需修改即被接受的修复比例、通过的测试、省下的工时、引发的事故。这些数字如果拿得出来，对全世界每一家还在跑ECC的公司来说，才算真正的大新闻。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
