IBM押注15,552個老程序，98.78%活了

2200億行代碼正在死去，但沒人敢拔插頭。

這個數(shù)字來自行業(yè)估算——全球仍有2200億行COBOL在生產(chǎn)環(huán)境運行。銀行核心系統(tǒng)、保險理賠引擎、政府社保數(shù)據(jù)庫，它們支撐著每天數(shù)萬億美元的流轉(zhuǎn)。問題是，寫這些代碼的人大多退休了，而年輕人寧愿送外賣也不愿學一門1959年發(fā)明的語言。

上周，一家叫AGUELLID CODE的公司扔出一份測試報告：他們用自家引擎處理了15,552個真實世界的COBOL程序，98.78%生成了能通過Python語法檢驗的輸出。最關(guān)鍵的一行備注：Zero LLMs involved（零大語言模型參與）。

15,552個程序，從哪來

測試集不是實驗室捏出來的。

AGUELLID CODE團隊從131個開源倉庫里扒了15,552份源代碼，覆蓋五大洲：挪威、法國、巴西、印度、日本、美國。來源包括GitHub、HuggingFace、CBT Tape、GnuCOBOL官方庫，以及IBM的公開倉庫。方言跨度同樣夸張——商業(yè)COBOL、GnuCOBOL擴展、TypeCOBOL、大型機專用變體，全部扔進同一個漏斗。

「沒有篩選偏見，沒有精選樣本，能找到的全要了。」這是他們在技術(shù)博客里的原話。

版本迭代的數(shù)據(jù)對比更直觀。v5.6引擎處理14,508個文件，成功率96.84%，失敗488個。三個月后v5.8e版本擴容到15,552個文件（新增1,044個），成功率跳到98.78%，失敗數(shù)壓到190個。凈增益：1,342個文件從「無法處理」變成「有效輸出」。

在原始v5.7參考語料上，他們甚至測出過99.25%——289個失敗案例里，180個在一次調(diào)試 session 中被修復。

這里有個關(guān)鍵細節(jié)：他們對「有效」的定義極其苛刻。

不是人工審閱「看起來差不多就行」，不是字符串比對，不是風格檢查。他們用Python標準庫的ast.parse()做判定——生成代碼必須能被解析成抽象語法樹，觸發(fā)SyntaxError即判死刑。二進制結(jié)果，零解釋空間，人類 reviewer 無權(quán) override，模型也沒法靠幻覺蒙混過關(guān)。

「這是最嚴格的語法正確性定義。」團隊寫道。

190個失敗案例，卡在什么地方

剩下的1.22%不是隨機噪聲，而是被精確分類的硬骨頭。

TypeCOBOL方言占約60個——多級限定符、REPLACE偽指令、類型化表達式，這些擴展從未進入任何COBOL標準文檔。GnuCOBOL專屬擴展約40個，涉及GUI、位運算組合、面向?qū)ο筇匦浴CREEN SECTION。非標準COBOL約30個，包括WebSocket實現(xiàn)、Brainfuck解釋器、.NET GUI綁定——聽起來像惡作劇，但確實是真實存在的生產(chǎn)代碼。

STRING/UNSTRING語句的深度嵌套約25個，多分隔符復雜場景讓解析器頭疼。大型機專屬邊緣案例約35個，CICS內(nèi)聯(lián)命令、復雜EXEC SQL、嵌套COPYBOOK，這些構(gòu)造 sitting at the outer boundary of what any standard COBOL parser is expected to handle（坐在任何標準COBOL解析器預期處理能力的外邊界上）。

團隊的原話很直接：「這些不是解析bug，是解析器從未理解過的東西，sanitizer 無法修復它從未見過的東西。」

但他們知道每一塊骨頭在哪，正在逐個啃。

不用AI，是賣點還是硬傷

AGUELLID CODE反復強調(diào)「零LLM」，在當下的技術(shù)語境里，這幾乎是一種反潮流的姿態(tài)。

他們的技術(shù)路線確實迥異于主流的「AI代碼生成」敘事。引擎不直接翻譯COBOL到Python，而是先把COBOL轉(zhuǎn)成語義中間表示（semantic intermediate representation），再生成行為等價的Python——不是逐行對應，而是行為逐行為對應。沒有神經(jīng)網(wǎng)絡，沒有提示工程，沒有采樣隨機性。相同輸入永遠產(chǎn)生相同輸出，邏輯可追溯，過程可審計。

「在銀行、保險、政府系統(tǒng)里，『模型覺得自己對了』不是可接受的解釋。」

這句話擊中了金融級軟件遷移的命門。2023年摩根大通的一份內(nèi)部備忘錄泄露，顯示其COBOL現(xiàn)代化項目因AI生成代碼的不可解釋性而暫停試點——監(jiān)管合規(guī)部門無法接受「黑箱決策」進入核心賬務系統(tǒng)。AGUELLID CODE的確定性輸出，某種程度上是為這種恐懼開的藥方。

但硬幣另一面是靈活性代價。純規(guī)則引擎的擴展成本極高，每新增一種COBOL方言變體，都需要工程師手寫解析規(guī)則。對比之下，LLM-based方案在處理「從未見過的語法結(jié)構(gòu)」時，往往能通過上下文推理給出合理猜測。190個失敗案例的分類清單，某種程度上暴露了規(guī)則引擎的天花板。

IBM的選擇耐人尋味。他們既是AGUELLID CODE的公開合作方（SAM1概念驗證的505行代碼由IBM提供），也是自家Watson Code Assistant的推手——后者正是基于大模型的COBOL現(xiàn)代化工具。兩種路線并行押注，不把雞蛋放一個籃子。

2200億行代碼，誰來接盤

COBOL現(xiàn)代化的市場 urgency 被低估了二十年，現(xiàn)在真的火燒眉毛。

美國社會保障局（SSA）2023年向國會提交的報告顯示，其核心系統(tǒng)依賴的6000萬行COBOL中，42%的原始作者已去世或無法聯(lián)系。SSA每年花費1.4億美元維持這些系統(tǒng)運轉(zhuǎn)，但招聘COBOL工程師的難度「呈指數(shù)級上升」。類似困境遍布全球：日本三菱UFJ銀行2022年因COBOL系統(tǒng)故障導致1200萬筆交易延遲，罰款金額超過系統(tǒng)現(xiàn)代化預算的三倍。

AGUELLID CODE的測試規(guī)模是個信號。15,552個程序不是學術(shù) toy problem，而是接近真實世界復雜度的壓力測試。98.78%的成功率意味著，理論上已有工具可以批量處理遺留代碼庫，而不需要逐行人工重寫——后者的時間成本通常是前者的40到60倍。

但「語法有效」不等于「生產(chǎn)可用」。ast.parse()通過只保證代碼能跑，不保證邏輯等價。COBOL的COMP-3壓縮十進制、嵌入式SQL預編譯、CICS事務語義，這些運行時行為的精確復現(xiàn)才是硬骨頭。AGUELLID CODE的博客承認，當前驗證聚焦「語法正確性」，語義等價性測試正在開發(fā)中。

另一個懸而未決的問題是性能。COBOL在IBM Z系列大型機上的執(zhí)行效率經(jīng)過六十年優(yōu)化，同等業(yè)務邏輯用Python跑在x86集群上，延遲和吞吐能否達標？團隊沒有公布基準測試數(shù)據(jù)，但評論區(qū)已有讀者追問：「生成的Python代碼，在同等硬件成本下能撐住生產(chǎn)負載嗎？」

IBM的SAM1概念驗證給出了一個樂觀信號：505行COBOL代碼，轉(zhuǎn)換耗時32毫秒。但這個數(shù)字的含金量取決于后續(xù)——是冷啟動時間還是熱路徑性能？是否包含中間表示的編譯開銷？信息尚不完整。

技術(shù)路線之爭仍在發(fā)酵。LLM派主張「先跑起來再修bug」，規(guī)則引擎派堅持「先證明正確再部署」。AGUELLID CODE的測試數(shù)據(jù)給后者添了籌碼，但遠未到終局。2200億行代碼的遷移成本，足夠容納多條技術(shù)路線共存十年以上。

一個值得玩味的細節(jié)：團隊在博客末尾放了一個GitHub issue鏈接，邀請用戶提交「讓引擎失敗的COBOL代碼」。190個失敗案例的分類清單，就是社區(qū)反饋的產(chǎn)物。這種開放姿態(tài)在 enterprise software 領(lǐng)域并不常見——他們似乎確信，透明度本身就是信任貨幣。

下一個版本v5.9的目標已經(jīng)公開：把失敗率壓到0.5%以下，同時啟動語義等價性驗證框架。如果達成，這將是第一個被證明「行為等價」的COBOL-to-Python工業(yè)級工具。

屆時，2200億行代碼的死亡倒計時，或許會真正開始。