這幾天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開發範圍內的轉型，難以規避這一趨勢，無論使用哪種程式語言都是如此。開發者的目光可以向其他領域擴充套件，如業務適配、方案重構與系統遷移，尋找新的發展空間。