把代码黑盒交给 AI

献给每一位想读懂 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 化以标准SKILL.md描述,opencode、Claude Code 原生识别;Cursor 等可通过 MCP 适配器接入。版本覆盖也是一个刻意的设计:•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、activateallow_transport关闭create-transport、release-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]权限与访问控制缺失AUTHORITY-CHECK、未检查SY-SUBRC、权限旁路3[DATA]数据完整性与异常处理FM 调用后的SY-SUBRC、写前加锁、空CATCH4[PERF]性能风险LOOP 内 SELECT、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、增强实现、函数组、CDSabap-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 · MITabap-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