献给每一位想读懂 ABAP 代码的 SAP 顾问:把代码黑盒交给 AI
这篇文章关注一个常见问题:做 SAP 的业务顾问,想读懂 ABAP 代码时怎么办。我把答案做成了一份开源 Skill——
sap-adt-cli(仓库名仍为sap-abap-cli),通过 SAP ADT REST API 直连系统,把 ABAP 源码、CDS、DDIC、传输请求读出来交给 AI,再由 AI 用中文告诉你逻辑长什么样、问题出在哪。一个同源的姊妹项目
abap-code-review则在它之上加了一层发布前代码审查,两个 Skill 可以叠在同一个 Agent 里连起来用。
一、从一句「这个要问开发」说起
做过几年 SAP 业务顾问的人,大概都被同一句话卡住过:
「这个要问开发……」
过账金额对不上、字段逻辑跑偏、单据状态停在一个不该停的位置——业务顾问拿着一堆现象,真正的逻辑却躺在ABAP 代码里。在这之前,顾问能做的事情非常有限:
• 抓一份截图、抄一段报错,丢到群里等开发回复。
• 自己点进 SE80 / SE38 / SE37,看到一堆
PERFORM、CALL FUNCTION、ENHANCEMENT之后,默默退出来。• 把问题原样转给开发,在业务与开发之间反复同步信息,然后继续被业务部门追问「到底什么时候能解决」。
问题不是「顾问不该看代码」,而是看代码的成本太高、回报太慢。
在一个跑了十几年的 SAP 系统里,客制化对象常常上千,任何一个字段背后都可能挂着十年前某次需求评审的决定。这种代码黑盒,长期是业务顾问的盲区。
二、AI 时代,代码黑盒不再是必然
大模型擅长做的一件事,就是把一段陌生代码翻译成可读的业务语言。
前提是——它得真的拿到那段代码。
这就是sap-adt-cli想解决的事情:
• 通过SAP ADT REST API直连系统,读取 ABAP 程序 / 类 / 函数模块 / 接口 / Include、CDS 视图、DDIC 表与结构、包、事务码、传输请求。
• 把这些能力封装成一份标准Agent Skill(
SKILL.md),opencode、Claude Code 等支持 Skill 的 Agent 可以直接加载。• 在具备系统权限并满足公司合规要求的前提下,顾问可以在自己的 AI 客户端里发问,由 Agent 拉取代码、读取逻辑、输出一份中文分析报告。
例如:
Analyze class ZCL_PAYMENT_PROCESSOR for security vulnerabilities Scan package ZMYPAYMENT and list objects with SQL injection / missing auth-check / hardcoded credentials它解决的不是「让顾问取代开发」,而是另一件更现实的事:
让业务顾问带着线索去找开发,而不是带着问号。
少走弯路,沟通更精准,问题解决更快。这才是 AI 在企业系统里真正能带来的价值。
三、技术上做了什么
如果只用一句话概括技术路径:
把 SAP 系统的代码与对象暴露成 AI 可调用的能力,再用一层 CLI 协议把它标准化。
展开来说有三层:
层次 | 解决的问题 |
| SAP ADT REST API | 替代过去只能在 SAP GUI / Eclipse ADT 里完成的源码读取与对象操作。 |
| sap-adt-cli | 把 ADT 能力封装成稳定的命令行接口,统一参数、返回、错误格式;输出走 stdout,错误走 stderr,让 Agent 可预期地处理结果。 |
| Skill 化 | 以标准 |
版本覆盖也是一个刻意的设计:
•ECC
•S/4HANA(On-Premise)
•BTP ABAP Environment
这意味着只要系统启用了 ADT 服务、账号具备相应权限,无论是存量 ECC / S/4HANA,还是 BTP ABAP Environment,都可以用同一套 CLI 接入 AI。
实现细节:Python 3.8+,依赖仅
click/requests/urllib3,首次运行自动安装。SAP 侧需激活/sap/bc/adt服务路径(如使用run-sql,还需/sap/bc/adt/datapreview),账号需具备SAP_ADT_BASE或等效读权限。
四、v1.1.x:从「只能看」到「能看能改」
第一个版本的定位很克制,只做读操作——拉源码、看对象、做诊断。
v1.1.0跨了一步,从「只能看」走到「能看能改」,新增了这 10 个命令:
syntax-check·get-cds-view·get-type-group·write-source·activate·where-used·run-sql·list-transports·create-transport·release-transport。
同时仓库的 CLI 名也从sap-abap-cli重命名为sap-adt-cli,更贴近背后调用的 ADT API 范围(仓库 URL 保持不变,老配置目录会自动迁移)。
最新的v1.1.1进一步修复了 S/4HANA 上run-sql的兼容性(GET → POST 自动回退、采用 typedAccept头、以及更可靠的 XML 解析)。
这一步必须把权限边界一起想清楚,否则就容易让自动化能力越过企业系统应有的变更流程。设计上做了两层防护。
双层防护 · 能力标志 + 每次确认
能力标志 | 默认 | 解锁的命令 |
allow_write | 关闭 | write-source、 |
allow_transport | 关闭 | create-transport、 |
两个标志独立,默认全部关闭,建议只在受控的开发环境中启用。
可以在授权范围内让 AI 读取代码,同时完全禁止它执行写入操作;也可以只开allow_write,把传输请求的创建与释放继续锁住。
即使能力标志打开,每一次写操作仍需一次显式确认:
1. 先输出变更预览(影响对象 / 目标传输请求)。
2. 强制要求
[y/N]确认。3. 确认仅对本次操作生效,不复用、不缓存。
换句话说:在这套工具约束下,AI 不能靠一次「同意」拿到长期通行证,也不能在用户未确认的情况下执行写入。
DML 在 CLI 层被拦住
run-sql只接受SELECT。
INSERT/UPDATE/DELETE/MERGE/MODIFY/TRUNCATE在 CLI 层就会被拒绝,与 SAP 系统侧权限无关。默认返回 100 行,上限 1 万行。
在企业系统里,AI 的自主性越高,人在回路的设计就越重要。能力标志 + 每次确认 + DML 黑名单,本质上是把「人机协作的边界」显式写进了工具协议里。
五、给顾问的一键上手:Windows + opencode
多数业务顾问并不希望为了试一个工具先搭一整套环境。所以仓库里提供了一个面向 Windows 的一键脚本:
setup-opencode-abap-cli.bat双击以后它会:
1. 检查 Node.js ≥ 18、Python 3、Git 是否安装(缺什么会给出下载链接);
2. 补上 Node 和 npm 全局包的
PATH;3.
npm install -g opencode-ai装上opencode(免费开源的 AI Agent);4. 把仓库 clone 到
%USERPROFILE%\.agents\sap-abap-cli,并在.agents\skills\sap-adt-cli建一个目录 junction;5. 装好 Python 依赖。
装完以后在cmd里:
opencode进去后/connect连你喜欢的模型,然后直接用中文提问:
分析类 ZCL_PAYMENT_PROCESSOR 是否存在安全漏洞 读取程序 ZREPORT_UPLOAD,检查 SQL 注入、缺失权限检查、硬编码凭据 扫描包 ZMYPAYMENT,列出所有可能有安全问题的对象opencode 会自动调用sap-adt-cli拉代码,再交给模型分析——顾问全程不需要复制粘贴代码。
首次运行会交互式录入 SAP URL / 用户名 / 密码 / Client / 是否跳过 SSL 校验,保存在~/.sap-adt-cli/config.json里(权限 0600)。
合规提醒:ABAP 源码可能包含核心业务逻辑与敏感数据。调用云端模型前请先确认公司数据安全政策;对敏感环境,建议优先使用内部部署或已获审批的模型。
这套 Skill 不绑定 opencode——SKILL.md是通用 Skill 规范,Claude Code 原生支持;TRAE CN 把 skill 目录放到.trae/skills/下即可直接加载,无需 MCP 适配。
六、组合用法:接上abap-code-review做发布前审查
sap-adt-cli解决的是「让 AI 拿到代码」。
如果你想让审查过程有标准、有评级、有签字结论,可以再叠上一个配套 Skill:
abap-code-review是一个面向 SAP ABAP发布前代码审查的 Agent Skill,把审查拆成 9 个维度,要求 Agent 逐项覆盖:
# | 维度 | 关注点 |
1 | [SEC] 安全漏洞 | SQL 注入、代码注入、命令注入、路径攻击、硬编码凭据 |
2 | [AUTH] 权限与访问控制 | 缺失 |
3 | [DATA] 数据完整性与异常处理 | FM 调用后的 |
4 | [PERF] 性能风险 | LOOP 内 SELECT、 |
5 | [STD] ABAP 代码规范 | 弃用语句、硬编码业务值、超长方法、注释掉的代码 |
6 | [INTERFACE] 接口与集成风险 | RFC 里的 dialog 消息、缺失 EXCEPTIONS、OData 后端鉴权 |
7 | [CHANGE] 变更影响评估 | 受影响表、SAP 标准对象修改、共享 INCLUDE、传输依赖 |
8 | [COMP] 合规与审计 | PII 处理、双人复核、审计日志、SoD 路径 |
9 | [FUNC] 功能完整性(可选) | 业务场景覆盖、边界条件、逻辑与需求对齐 |
每条 finding 都需要真实代码片段做证据(不推测),并引用具体规则(如SEC-SQL-1)。
报告最后给出一个明确的发布结论:
🔴 NO-GO · 🟡 CONDITIONAL GO · 🟢 GO
并附带一份可签字的 Markdown 报告(开发 / 技术 Lead / 发布经理 / 安全负责人)。
特别规则:[SEC] 或 [AUTH] 里的 HIGH 发现会被自动归为 CRITICAL,建议直接 NO-GO。
两个 Skill 怎么配
Skill | 职责 |
sap-adt-cli | 拉代码——主程序、所有 INCLUDE、增强实现、函数组、CDS |
abap-code-review | 按 9 维度评级,输出结构化报告和 GO / NO-GO 结论 |
同一个 Agent 同时加载这两个 Skill,就可以把拉代码 → 多维度审查 → 出签字报告串成一条流程。
运维 / 发布经理可以在传输请求释放前先跑一遍审查,尽量把 CRITICAL / HIGH 项挡在生产之前,而不是等出问题后再回头补检查清单。
七、一个 SAP 顾问 + AI Agent 的开发范式
这个项目本身也是一次实验:
一个有十多年 SAP 项目经验、但并非传统软件开发出身的顾问,能不能借助 AI 交付一份可以对外发布的工具?
最后走出来的路径大致是一个spec-driven的环:
1.定规格:在与Claude Sonnet 4.6的对话里,把需求、变更范围、验收标准、反模式写成结构化的 Markdown spec。
2.交给 Agent 执行:这份 spec 交给 opencode + Oh My OpenAgent 运行,后端接 GitHub Copilot Pro 订阅,由 Agent 规划、实现、测试、验证。
3.人负责方向与验收:人的角色更接近「决定要什么 + 验收产出 + 调整 spec」,而不是「亲手写每一行代码」。
如果说过去一个顾问要做开源项目,需要先补足大量工程能力,今天更现实的路径是:把领域意图描述清楚,交给一个具备工具调用能力的 Agent 执行。
能力 = 模型 + 上下文 + 约束。你不需要亲自控制模型,但你需要控制上下文和约束。
八、它适合谁
这套 CLI 并不是通用工具,但会更适合下面几类场景:
•SAP 业务顾问:希望在提交开发协作前,先看清楚代码逻辑,再去对齐方案。
•运维 / 接口支持团队:经常处理字段不一致、接口报错等问题,需要快速判断是配置问题还是代码逻辑。
•想做 SAP 方向 AI Agent 的同行:不用自己再造一遍 ADT 调用层,直接把 CLI 注册成 Skill。
•正在做存量系统 AI 化的产品 / 架构师:可以把它作为一个参考样本——如何把一个成熟企业系统以受控方式开放给 AI Agent。
九、写在最后
AI 时代,代码黑盒不再是业务顾问的盲区。
但「不再是盲区」不等于「自动看得懂」。它需要有人把 SAP 这种企业系统的能力,重新封装成 AI 可以理解、可以调用、又有边界约束的接口。
这件事未必显眼,也不一定短期出彩,但对 B 端 AI 化是真正的地基。
sap-adt-cli和abap-code-review是我在「SAP × AI」这个方向上持续打磨的两个配套 Skill——一个负责「拿到代码」,一个负责「审查代码」。
同时它们也是一个「领域专家 + AI Agent」合作交付的实验。后面会继续演进——更稳的 CLI 协议、更完善的 Skill、更细的权限模型、更多 SAP 场景的接入。
如果你也在做 SAP × AI 这件事,欢迎一起聊。
仓库资源
sap-adt-cli:github.com/shrek-abaper/sap-abap-cli · v1.1.1 · MIT
abap-code-review:github.com/shrek-abaper/abap-code-review · 9 维度发布前审查 Skill
支持系统:ECC / S/4HANA(On-Premise)/ BTP ABAP Environment
依赖:Python 3.8+ ·
click·requests·urllib3
