这几天DeepSeek火爆全网，AI又成了热门话题，借此我想谈谈自己关于AI对ABAP开发影响的看法。
本文链接：https://www.cnblogs.com/hhelibeb/p/18702304
SAP的术语迷宫
在ERP领域浸润多年的从业者，都能直观感受到SAP体系构建的术语迷宫增加的沟通成本。从FI（财务会计）到PP（生产计划）的模块命名规则，从"事务码"到"用户出口"的技术概念，这些经过三十年沉淀的特有词汇如同加密协议般，将非SAP背景的IT从业者区隔在外。术语构筑的专业壁垒，一定程度上形成了SAP生态参与者的护城河，但也成为新进开发者入局的认知障碍点。
大语言模型正在瓦解这种术语不对称。通过交互式对话，AI可将诸如BAPI调用这类专业操作，平移到通用开发语境中进行类比解释，让其他从业者轻松理解——许多SAP从业者都有类似的经历：向外部开发者解释BAPI和RFC的概念往往需要额外的沟通成本。
和AI发展同时存在的是，SAP近年来也在走向生态开放与转型。开发者需要理解的不只是SE38编辑器的操作，也要掌握Fiori元素与OData服务的结合逻辑。AI可以成为新老技术范式转换的辅助，这一辅助有双向的作用。它让ABAP开发者更容易跟上新技术的发展，也意味着老的护城河不复存在。
新技术是优势吗？谈谈代码化程度与AI可替代性
可以把ABAP的开发工作分为两类，
- 高代码化开发，典型的如CDS和Class的开发，它的特点是只需要输入代码即可以完整地完成开发工作。
- 低代码化开发，典型的例子是带屏幕的Report、BRF+等，这一类开发的特点是，需要通过UI界面的操作完成开发，而不能仅仅通过代码完成开发工作。
前者，由于可以将完整的开发内容直接交给大语言模型处理，显然是AI辅助开发的突破口。而后者由于涉及非代码操作，AI辅助开发的实现将比较困难，除非SAP提供相应的接口，或调整开发方式以提高代码化程度，就像当年对SE11的改进一样。早期SAP系统只能通过SE11修改表和数据元素，而在更新版本中，开发者已可以使用ADT直接读取和编辑对象定义代码。
技术演进带来了悖论：越符合现代开发范式的工作，由于其高度结构化、接口标准化的特点，反而更容易被大语言模型自动化；而依赖于GUI事务码的旧体系（如SAPscript表格绘制），却因系统耦合度过高形成反AI壁垒。技术先进性 ≠ 职业安全性，对于努力学习新技术的ABAP开发者而言，这或许是一个值得探讨的问题。
Java和ABAP，谁会先被AI取代
国产替代是今年来行业里不可避免的话题，不少ABAP由于信创的需求转型做了Java，这也引发了新讨论：Java和ABAP，究竟哪个更有前景？
Java的开发工作更倾向于纯代码化，因此在AI辅助编程的背景下，似乎更容易被部分取代。但跳脱语言本身，考虑到企业对投入产出比的要求，可以知道，成本因素在语言与平台选型中起着关键作用，如果未来Java开发能通过大规模AI替代来降低成本，那凭什么坚持选择难以被低成本替代的SAP ABAP？
因此，Java和ABAP哪一个先被AI替代或许并不重要，AI对程序员的冲击将会是全方位的，除了少数特殊从业人员，大多数开发者都难以置身事外。
结语
AI在降低行业门槛、替代ABAP开发者，这种替代不是所谓的技术演进可以抵抗的，甚至恰恰相反，新技术会导致替代的进一步加速。局限在ERP开发范围内的转型，难以规避这一趋势，无论使用哪种编程语言都是如此。开发者的目光可以向其他领域扩展，如业务适配、方案重构与系统迁移，寻找新的发展空间。
