AI 时代的 SAP 开发新范式：用 AI Agent 做 ABAP 代码审查

当代码审查变成一句话：AI Agent 重塑 ABAP 发布范式

一个问题，两种世界

想象一个场景：你的团队明天要上线一个新的 ABAP 程序，处理跨工厂的库存调拨。

传统方式：开发人员自查，技术负责人抽检，走 ATC 扫一遍，填个发布单，批准上线。整个过程依赖个人经验，覆盖面取决于当天谁在做 Review，有没有时间认真看。

AI Agent 方式：在对话框输入一句话：

Review program ZMMR0002 for release.Transport: DEVK900234, Change description: 新增跨工厂 STO 创建逻辑。Save the report to reports/.

五分钟后，你拿到一份结构化的 Markdown 报告：对照 9 个维度逐项检查，每个问题标注了严重级别、SAP 官方规则编号、真实代码证据、以及具体修复方案。最后是一个明确的 GO / CONDITIONAL GO / NO-GO 发布建议，以及可直接流转的签字审批表。

AI 写 ABAP 已经不新鲜，AI 审 ABAP 才刚刚开始。abap-code-review 是 sap-adt-cli 系列的第二站——把发布前最依赖经验的那道关，交给 Agent 强制覆盖。打开 GitHub，半小时之内你就能在自己的开发机上跑出第一份审查报告。

AI 工作范式带来了什么变化

在 SAP 领域深耕多年，我们积累了大量宝贵的业务知识和开发经验。这些经验不会因为 AI 的出现而失效，恰恰相反——它们是我们驾驭 AI 工具的核心优势。AI 真正改变的，是这些知识的组织和传递方式。

专家知识，从经验变成可执行的流程

过去我们说"用 AI 提高效率"，通常是指加速某个具体步骤，比如写文档、生成测试数据。AI Agent 范式走得更远一步：把专家知识结构化为可执行的工作流，让 Agent 作为一个参与者嵌入研发流程，而不只是一个快捷工具。

abap-code-review 这个 SKILL 就是这种思想的体现：

• • 它不是"帮你查找代码中的问题"
• • 它是"把有经验的人脑子里的审查清单固化下来，每次发布都完整执行一遍，生成可追溯的审查记录"

对团队来说，这意味着每次审查的覆盖范围不再取决于当天谁有时间、谁经验更丰富。

每个人的经验，都可以沉淀为团队的能力

传统 Code Review 的质量，很大程度上取决于 Reviewer 当天的状态、对业务模块的熟悉程度，以及这个人过往踩过多少坑。

SKILL 的做法是把这些知识显式地编码进去：

• • SAP 官方 Clean ABAP Style Guide 的核心规则（REF_CLEAN_ABAP.md）
• • ABAP 安全漏洞的权威分类，对照 SAP 官方 Security Notes 和 CWE 类别（REF_ABAP_SECURITY.md）
• • 9 个审查维度的强制检查清单，覆盖：

每一次执行，覆盖范围都是完整的。不会因为"今天比较忙"而跳过性能检查维度。每条规则在 SKILL 内有唯一编号（格式如 PERF-FAE-1 = Performance / FOR ALL ENTRIES / Rule 1），方便归档追溯。

审查结论，从口头承诺变成书面证据

这一点在企业场景中尤为实用。

传统 Code Review 的结论往往是："我看了，没问题。" 没有记录，也没有证据。六个月后出了生产事故，很难回溯当初审查了哪些内容、遗漏了什么。

AI Agent 的输出是结构化报告：每个 Finding 都有真实代码片段作为证据，每个结论都有规则编号作为依据，每次审查都有完整的审查范围记录。这份报告作为人工审查的输入和留痕，配合技术负责人签字共同构成完整的发布决策记录——AI 提供覆盖面和证据链，人继续保留最终判断权。

和 ATC 的本质区别

SAP ABAP Test Cockpit（ATC）是目前最主流的代码质量工具。它很好，但它和 AI Agent 审查是两种完全不同的东西。

ATC 做得好的事

• • 静态语法检查：基于规则引擎，速度快，覆盖面广
• • 与传输系统集成：可以在传输请求释放时强制执行
• • Clean ABAP 规范检测：可扩展检测命名、结构、废弃语句等标准违反

ATC 的结构性局限

几个具体的场景说明差异：

场景 1：Enhancement 对标准流程的隐性影响

某个 BAdI 实现表面上只在物料移动后追加了一段自定义校验逻辑，ATC 扫描结果干净，语法和授权都没问题。但 AI Agent 在分析 [CHANGE] 维度时会识别到：这个 BAdI 出口在两步法跨工厂 STO 的发货环节（移动类型 641 / 645）配合特殊库存标识时，会与标准过账的提交序列产生时序错位——轻则自定义校验抛异常导致整笔过账回滚，重则自定义集成接口（如已发出的 IDoc 或写入自定义日志表的中间状态）与最终过账结果脱节，造成下游系统状态不一致。这种场景组合只有在生产环境特定业务量下才会复现，靠人工审查很难在发布前预判到。

场景 2：历史遗留"祖传逻辑"的变更影响

Include 里有一段注释写着"月末勿动"的代码，本次变更只是在旁边加了几行字段赋值，ATC 不会报任何问题。AI Agent 在 [CHANGE] 维度会识别到：这段代码中存在依赖 SY-DATUM 的条件分支，逻辑在每月最后三个工作日走不同的路径，且与 FI 月结程序共享同一张自定义控制表的写入权。新增的字段赋值恰好在这个分支之前修改了控制表的状态字段，意味着月末触发时的执行结果和平时不同。这类时间依赖的业务逻辑，是最容易在发布后第一个月末才暴露的定时炸弹。

结论不是 ATC 不好，而是两者应该互补：ATC 做早期语法门槛，AI Agent 做发布前的深度审查和证据留存。

结合 sap-adt-cli 实现端到端自动化

abap-code-review 只是审查引擎。真正让它运转起来，还需要一个能读取 ABAP 源码的工具。

数据合规说明：ABAP 源码可能包含核心业务逻辑。使用前请确认向云端 AI 服务发送代码符合企业数据安全规范；敏感系统建议使用内部部署模型。

这里搭配使用的是 sap-adt-cli，一个通过 SAP ADT REST API 连接系统的命令行工具，同时也是一个 AI Agent SKILL。它让 Agent 可以直接从 SAP 系统拉取程序源码，覆盖 REPORT / Class / Function Module / Include / CDS View / DDIC 等主流对象类型，无需人工复制代码。

完整工作流

开发人员完成开发准备发布传输请求，在 Claude Code / OpenCode 中输入一句话，Agent 触发 abap-code-review SKILL，由 sap-adt-cli 通过 ADT API 直连 SAP 系统读取源码（主程序 → 全部 INCLUDE → CLASS METHOD 逐个读取），对照参考文档完成 9 维度分析，生成结构化报告保存至 reports/ 目录，最后由技术负责人审阅报告签字 GO / NO-GO。

使用方式

以下是核心配置步骤，逻辑不复杂，但请预留时间处理 SAP 网络访问和用户权限配置。为 sap-adt-cli 创建专用 SAP 用户是个好习惯，权限按最小化原则配置，只开放只读场景所需的范围。

第一步：配置 sap-adt-cli 连接

git clone https://github.com/shrek-abaper/sap-abap-cli.gitcd sap-abap-clipython3 skills/sap-adt-cli/scripts/sap_adt_cli.py configure# 按提示输入 SAP 系统地址、用户名、密码、客户端

配置完成后验证连通性：

python3 skills/sap-adt-cli/scripts/sap_adt_cli.py status

Windows 用户可直接运行仓库内的 setup-opencode-abap-cli.bat，一键完成 opencode 和 sap-adt-cli 的安装与配置。

第二步：安装 abap-code-review SKILL

git clone https://github.com/shrek-abaper/abap-code-review.git

将 sap-abap-cli/skills/sap-adt-cli 和 abap-code-review 两个目录放入 Claude Code 或 OpenCode 的 skills 路径下即可。

第三步：在 Agent 中执行审查

Review program ZMMR0002 for release.Transport: DEVK900234Change description: 新增跨工厂 STO 创建逻辑，涉及 EKKO/EKPO 写入。Save the report to reports/.

Agent 会自动调用 sap-adt-cli 从 SAP 系统读取 ZMMR0002 的完整源码（含所有 INCLUDE），完成 9 个维度的分析，生成 ABAP_REVIEW_ZMMR0002_20260509.md 并保存。如果发现 CRITICAL 问题，文件名自动前缀 CRITICAL_。

一份真实的报告长什么样

报告结构是固定的：

• • Report Header：程序基本信息、审查范围、引用标准
• • Executive Summary：3-5 句总结，给决策者看
• • Release Recommendation：🔴 NO-GO / 🟡 CONDITIONAL GO / 🟢 GO
• • Risk Summary：各级别发现数量一览
• • Detailed Findings：每个问题，证据代码 + 规则编号 + 修复建议
• • Dimension Coverage：9 个维度覆盖确认
• • Scope Limitations：未能读取的对象说明
• • Remediation Checklist：CRITICAL/HIGH 的行动清单
• • Sign-off：开发者 / 技术负责人 / 发布经理签字栏

以 FOR ALL ENTRIES IN 空内表这个经典问题为例，Agent 输出的 Finding 大致是这样的：

🔴 CRITICAL｜PERF-FAE-1｜ZMM_INCLUDE_F01 L.134

当 lt_orders 为空时，FOR ALL ENTRIES IN 退化为全表扫描，MSEG 千万级数据量下将直接导致超时。

问题代码：

SELECT mseg~matnr, mseg~menge, mseg~werks  FROM mseg  FOR ALL ENTRIES IN @lt_orders  WHERE mseg~aufnr = @lt_orders-aufnr.

修复：

IF lt_orders IS NOT INITIAL.  SELECT mseg~matnr, mseg~menge, mseg~werks    FROM mseg    FOR ALL ENTRIES IN @lt_orders    WHERE mseg~aufnr = @lt_orders-aufnr.ENDIF.

每个结论都有证据，每个证据都有出处。这份报告可以直接归档进你的变更管理系统。

这不只是一个工具，是一种新的开发范式

abap-code-review 这个项目是这段时间自己在用的东西，顺手开了源。背后的积累来自三个地方：SAP 官方 Clean ABAP Style Guide 和安全编码指南的核心规则、社区多年沉淀的最佳实践、以及项目实战中反复碰到的真实坑。把这些整理成 Agent 每次发布前都会跑一遍的检查清单，算是一次蒸馏和固化。

在 SAP 这个专业性强、行业纵深深的技术生态里，我们积累的业务理解和系统经验，恰恰是构建这类工具最核心的原材料。AI 做的事，是让这些经验不再只存在于某个人的脑子里。

类似的思路也在往其他方向延伸，比如：

• • 需求评审（对照业务规则检查功能设计文档）
• • 接口设计审查（RFC 参数、BAPI 使用合规性）
• • 数据迁移脚本验证
• • ABAP 单元测试覆盖率分析

AI 工作范式不是对过往经验的否定，恰恰是让经验产生更大的价值。

资源

• • abap-code-review（代码审查 SKILL）：github.com/shrek-abaper/abap-code-review
• • sap-adt-cli（ABAP 源码读取工具）：github.com/shrek-abaper/sap-abap-cli