AI + SAP ADT实战案例（一）：用 Codex 只读排查领料接口里的物料错位

大家好，我回来了

最近两年，我几乎把大部分业余精力都放在 AI 上。

不是说不做 SAP 了。上班还是照样处理 SAP 问题，ABAP 也照样写，只是下班后继续整理 SAP 文章、发技术笔记的动力少了很多。以前写一篇 SAP 文章，最麻烦的不是内容本身，而是截图、备注、脱敏、打码、整理步骤，这些工作太费时间了。

后来我越学 AI，反而越发现一个问题：如果只是追着各种 AI 工具跑，很容易越学越散。真正能长期沉淀下来的，还是要回到自己最熟悉、最有经验的领域。

对我来说，这个领域就是 SAP。

我以前完全不懂前后端开发，靠着 Codex、Claude Code 这些工具，也能从零做出自己的 AI 生图、生视频网站：注册登录、前后端页面、数据库、云服务器部署、域名绑定，整套流程都跑通了。这个过程让我很震惊，也让我开始重新思考：

如果 AI 连一个网站都能帮我从零搭起来，那它能不能反过来帮助我处理最熟悉的 SAP 问题？

最近刚好接触到 SAP ADT，这个想法就越来越清晰了。

ADT 全称是 ABAP Development Tools，是 SAP 官方提供的 ABAP 开发工具，通常运行在 Eclipse 里。简单理解，它就是把 ABAP 开发、对象查看、代码搜索、调试和维护工作，放到更接近现代 IDE 的环境里。

更关键的是：如果 AI Agent 能通过 ADT 只读连接 SAP，它就不再只是“根据你贴出来的几行报错猜原因”，而是可以自己去看代码、查表、读日志、追对象关系。

第一次让 Codex 通过 ADT 帮我排查生产问题时，我说实话是有点震惊的。

因为以前这种问题，我要自己来回切系统、查接口、查表、看代码、对日志；现在只要把问题讲清楚，Codex 就可以按只读边界自己往下追。它不一定每次都完美，但这种工作方式已经很值得 SAP 顾问、ABAP、运维同学认真研究。

所以这个系列，我准备从这里重新开始。

它不是单纯记录某个 SAP 报错怎么解决，而是记录一种新的工作方式：

用 AI + SAP ADT，把日常 SAP 问题排查过程自动化、结构化、证据化。

目录

• 一、这篇文章重点讲什么
• 二、第一步：选择一个能执行工具的 AI Agent
• 三、第二步：让 Agent 接上 SAP Engineering Skill
• 四、第三步：用大白话把问题丢给 Codex
• 五、第四步：Codex 是怎么自动排查的
• 六、本案例最后查到了什么
• 七、为什么我觉得 AI + SAP ADT 值得研究
• 八、后续这个系列准备怎么写

一、这篇文章重点讲什么

先把重点说清楚。

这篇文章虽然用了一个真实的领料接口报错做案例，但重点不是这个报错本身。

我真正想讲的是：

AI 怎么跟 SAP 结合？

更具体一点，就是：

• 我怎么把问题告诉 Codex；
• Codex 怎么通过 ADT 连接 SAP；
• 它怎么自动读接口日志、查表、看 ABAP 代码；
• 它怎么把这些线索整理成证据链；
• 最后怎么给出一个相对靠谱的判断方向。

SAP 的问题本身只是案例载体。真正有价值的是这套方法。

对新手来说，它可以帮你更快理解复杂链路。

对老顾问来说，它可以帮你少做很多重复查询，把精力放回业务判断上。

二、第一步：选择一个能执行工具的 AI Agent

这个系列我会以 Codex 为例来讲，因为我自己现在用得最多，这次排查也确实是在 Codex 里完成的。

但这套思路不是 Codex 专属。

只要你的 AI Agent 能接入 Skill、MCP 或命令行工具，理论上都可以按类似方式使用，比如：

• Claude Code；
• Cursor；
• Trae；
• OpenClaw；
• WorkBuddy；
• 其他支持工具调用的 Agent。

模型也很关键。

SAP 问题经常不是只看一条报错就能判断的，它可能同时涉及 ABAP 代码、接口参数、日志、表数据、主数据、订单、预留、BOM、配置和业务含义。

所以我建议尽量使用推理能力强一点的模型，比如 Claude、GPT、Gemini 这类模型的最新版本。

当然，涉及生产系统时，安全边界一定要放在第一位。

我的原则很简单：

• 只读查看；
• 不改 SAP 数据；
• 不执行过账；
• 不写表；

这个边界要提前跟 AI 说清楚。

三、第二步：让 Agent 接上 SAP Engineering Skill

有了 Agent 和模型还不够。

AI 要真正帮你查 SAP，还需要有“看 SAP 的手脚”。

这里可以参考这个开源项目：

shrek-abaper/sap-engineering-skill

这个项目里包含一组面向 SAP ABAP 工程场景的 AI Agent Skill，其中和本文最相关的是 sap-adt-cli。

它可以通过 ADT REST API 读取 ABAP 代码、对象元数据、SQL 查询结果、where-used 关系等信息。

这里需要特别说明一下：SAP ADT 和这个 Skill 并不是只能只读。ADT 本身就是 ABAP 开发工具，开源项目也说明 sap-adt-cli 支持 ABAP 源码读写、DDIC 表/结构/类型、SQL 查询、语法检查、传输管理等能力。也就是说，在具备权限并开启写入能力后，它理论上可以协助编辑代码、创建或维护开发对象。

只是本文这个案例涉及 800 生产系统，我个人为了安全，才要求 Codex 全程按只读模式处理：只查代码、日志和表数据，不写代码、不建表、不改数据、不执行过账。

你不一定要自己手动研究所有安装细节。像我平时用 Codex，就可以直接用比较大白话的方式让它处理：

帮我把这个 SAP Engineering Skill 安装到当前项目里：
https://github.com/shrek-abaper/sap-engineering-skill

先按只读模式配置，后续只能读取代码、表数据和对象信息，不允许写入 SAP，也不要执行过账。

如果是 Claude Code、Cursor、Trae 之类工具，思路也差不多：让 Agent 读取项目说明，按文档安装，并明确只读边界。

这里我最看重的一点是：

AI 不再只是聊天，而是可以在授权范围内真实地帮你查系统。

这就是 AI + SAP ADT 最有意思的地方。

四、第三步：用大白话把问题丢给 Codex

我这次真实提问，并没有写得很专业。

大概就是下面这种口吻：

深度分析思考一下，接口 ZMMF_GOODSMVT_CREATE 在操作订单领料时，为什么有一些报错看上去对不上？

比如物料 11208020030003，消息文本提示：物料 11208020030015 C050 C52A 不存在。

还有物料 11208040010021，提示：物料 11208040010035 C050 C52A 不存在。

这些消息好像并不对应得上，现在完全看不出来到底是哪一行出问题了。

这是 800 生产系统，只读帮我查，不要修改数据，也不要过账。

你看，这段提示词没有什么高深技巧。

它只是把几件事情讲清楚了：

• 我遇到了什么现象；
• 哪些数据看起来对不上；
• 我希望 AI 帮我追原因；
• 这是生产系统；
• 只能只读排查。

这就够了。

后面如果 Codex 需要继续确认接口、日志、订单、预留号、预留项、组件物料，它会自己沿着线索往下查。

下面是这次排查过程中的真实截图。

五、第四步：Codex 是怎么自动排查的

这部分我不展开讲太多具体 SAP 细节，因为本文重点不是这个报错本身。

简单来说，Codex 拿到我的问题后，大概做了几类动作。

第一，它先理解问题现象。

也就是判断：为什么接口行里的物料，和 SAP 报错消息里的物料看起来不是同一个？

第二，它通过 ADT 只读连接到生产系统。

这个过程不是让 AI 去改数据，也不是让它执行过账，而是让它在只读范围内查看接口程序、表数据和相关对象。

第三，它开始自动读取证据。

包括接口日志、相关表数据、ABAP 代码、函数调用逻辑、预留项和订单组件之间的关系。

第四，它把这些线索串起来。

也就是从“用户看到一条对不上的报错”，逐步追到“系统实际按哪个对象在校验”。

整个过程可以简单理解成下面这张图：

以前我排查类似问题，脑子里也会走这套链路。

但区别在于，以前是我自己一项项切事务、查表、翻代码；现在 Codex 可以帮我把这些只读动作自动串起来，并且把结果整理成比较清晰的结论。

这个体验对我来说挺震撼的。

不是因为它解决了一个多么罕见的问题，而是因为它让我看到：SAP 日常排查里大量重复、机械、耗时间的动作，已经可以交给 AI 先跑一遍。

六、本案例最后查到了什么

这个案例最后的结论可以简单说一下。

现象是：

接口行里看到的是一个物料，但 SAP 报错消息里提示的却是另一个物料在某个工厂 / 库位下不存在。

一开始看起来很像“日志和报错对不上”。

但 Codex 顺着接口日志、预留项、订单组件和物料库位视图往下查以后，发现关键点在这里：

SAP 标准过账逻辑最终是按预留项里的组件物料去校验，而不是只看接口行里传入的物料号。

所以报错消息里出现的物料，并不是凭空来的，而是从订单预留项 / 组件物料链路里追出来的。

对应的处理建议也很简单：

• 如果实际应该领接口行物料，就要检查上游为什么传了错误的预留号或预留项；
• 如果实际应该领订单组件物料，就要补齐组件物料对应工厂 / 库位下的主数据视图；
• 接口层最好增加前置校验，当“接口传入物料”和“预留项组件物料”不一致时，提前给出更清楚的提示。

比如可以提示：

接口传入物料与预留项组件物料不一致。
请检查上游传入的预留号/预留项，或确认生产订单组件是否正确。

这样业务看到的就不是一条孤立的标准报错，而是能知道下一步该查哪里。

七、为什么我觉得 AI + SAP ADT 值得研究

这次让我感触比较深的是：

SAP 问题排查，最耗时间的地方往往不是“最后那个结论”。

真正耗时间的是中间过程：

• 到底查哪个程序；
• 到底看哪张表；
• 日志字段和业务对象怎么对应；
• 标准函数为什么返回这个消息；
• 这条报错到底是接口问题、主数据问题，还是上游传参问题。

这些事情，老顾问当然能查。

但问题是，每次都要花时间。

而 AI + ADT 的价值就在于：它可以先帮你把这些基础排查动作跑起来。

你只需要把问题讲清楚，给它边界，让它只读去查，然后你再基于它整理出来的证据链做判断。

这对新手很有帮助，因为新手最怕不知道从哪里下手。

这对老顾问也有帮助，因为老顾问最缺的不是经验，而是时间。

所以我觉得这个玩法，真的值得 SAP 圈子里的人认真研究一下。

尤其是现在 Codex、Claude Code 这类 Agent 工具越来越强，很多以前看起来只能靠人手动排查的事情，已经可以变成：

人负责描述问题和判断方向，AI 负责读取系统和整理证据。

这个变化，我觉得非常重要。

八、后续这个系列准备怎么写

这篇算是第一篇，主要讲清楚 AI + SAP ADT 的基本玩法。

后续我准备继续写成一个系列，例如：

• AI + SAP ADT 如何辅助看 ABAP 接口代码；
• AI 如何通过表数据和日志还原业务链路；
• AI 如何辅助分析生产问题，但保持只读边界；
• AI 如何把日常排查过程整理成 CSDN 文章素材；
• AI + SAP 本地知识库后续怎么搭建。

我现在越来越觉得，SAP 和 AI 不是两条分开的路。

SAP 这种系统复杂、链路长、对象关系多的场景，反而特别适合用 AI 来辅助分析。

如果你本身就在做 SAP 运维、ABAP 开发、模块顾问，或者只是刚开始接触 SAP，我都建议你关注一下这个方向。

因为它不是单纯换一个聊天工具，而是可能会改变我们以后排查问题、沉淀经验、写技术文档的方式。

这也是我重新回来写 SAP 文章的原因。

不是简单回到过去那种“记录一个报错、贴一个方案”的写法，而是想把我最近真正觉得有价值的东西整理出来：

AI + SAP，可能会成为 SAP 顾问和 ABAP 开发以后很重要的一种工作方式。