IBM押注3年的COBOL轉譯，98.78%通過率讓2300億行

15,552個真實程序，98.78%生成有效Python，零LLM參與。這組數字來自一家叫AGUELLID CODE的法國公司，他們上周剛用IBM的SAM1做了概念驗證，這周就把測試規模拉到了全球級別。

這不是又一個AI編程工具的故事。恰恰相反，它刻意避開了AI。

從505行到1.5萬：測試是怎么膨脹的

AGUELLID CODE的測試集覆蓋131個開源倉庫，分布在5個大洲。挪威、法國、巴西、印度、日本、美國——GitHub、HuggingFace、CBT Tape、GnuCOBOL、IBM公開倉庫，全部納入。商業COBOL、GnuCOBOL擴展、TypeCOBOL、大型機方言，不設篩選，能找到的全測。

這種"不挑樣本"的做法在代碼遷移領域很少見。多數廠商會精心選擇演示案例，把轉換成功率刷得漂亮。AGUELLID CODE的做法更像壓力測試：如果系統能在隨機抓取的代碼堆里存活，才有資格談生產環境。

版本迭代的數據對比很直觀。v5.6處理14,508個文件，成功率96.84%。v5.8e新增1,044個文件，總量15,552，成功率提升到98.78%。失敗案例從456個壓縮到190個，凈增有效文件1,342個。

更細顆粒度的數據：在v5.7的參考語料上，原本289個失敗案例中，180個在一次調試會話中被修復，成功率達到99.25%。

"有效Python"的判定標準有多苛刻

AGUELLID CODE對"有效"的定義是ast.parse()零報錯。這是Python標準庫里的語法解析器，輸入字符串，輸出抽象語法樹，過程中任何SyntaxError都意味著失敗。

沒有人工復核開綠燈，沒有LLM打分放水，沒有風格檢查渾水摸魚。二元判定，沒有灰色地帶。

「人類評審無法覆蓋，模型無法幻覺過關。」這是他們的原話。在需要審計追蹤的銀行、保險、政府系統里，"模型覺得它對"不是有效辯護。

190個失敗案例的構成也被完整公開：TypeCOBOL的多級限定和REPLACE語句約60個，GnuCOBOL的GUI、位運算、面向對象和SCREEN SECTION約40個，非標準COBOL如WebSocket和brainfuck解釋器約30個，深層STRING/UNSTRING嵌套約25個， exotic大型機特性如CICS內聯和復雜EXEC SQL約35個。

這些不是解析器的bug，是標準COBOL解析器預期邊界之外的構造。清理器無法修復解析器從未理解的東西。

語義中間層：為什么不是"翻譯"而是"轉換"

AGUELLID CODE的技術路徑和常規代碼轉換工具不同。他們不直接做COBOL到Python的逐行映射，而是先把COBOL轉成語義中間表示，再生成行為等價的Python。

關鍵區別：等價的是行為，不是代碼行數。同樣的輸入永遠產生同樣的輸出，過程可審計，邏輯可追溯，沒有黑箱。

這個設計選擇指向一個被低估的行業痛點。全球約有2,200億行COBOL在生產環境運行，大部分維護困難——寫代碼的人退休了，文檔不全，行為邏輯成了嵌在語法里的機構記憶。

傳統現代化方案有幾種：重寫（風險極高）、封裝（技術債轉移）、LLM輔助遷移（不可解釋）。AGUELLID CODE試圖提供第四種：確定性轉換，保留行為的同時獲得現代語言的可維護性。

IBM的參與值得關注。SAM1是IBM去年推出的COBOL代碼模型，但AGUELLID CODE的測試刻意排除了LLM路徑。這種"用IBM的工具驗證非IBM的方法"的錯位，某種程度上是對行業主流敘事的無聲反駁。

金融基礎設施的現代化正在進入微妙階段。監管機構對AI生成的代碼越來越警惕，歐盟AI法案和美國金融監管機構的指引都在強調可解釋性。確定性轉換工具可能因此獲得政策窗口。

AGUELLID CODE的下一步是攻克那190個失敗案例。TypeCOBOL和GnuCOBOL擴展的優先級顯然更高——它們代表了開源生態的邊緣地帶，而邊緣地帶的覆蓋度決定了工具能否從"演示可用"跨越到"生產可用"。

2,200億行COBOL不會一夜之間消失。但98.78%這個數字意味著，對于相當一部分代碼庫，"凍結遷移"的決策可能需要重新評估——不是因為它簡單，而是因為替代方案的風險收益比正在變化。

當一家法國初創公司用確定性方法逼近99%成功率時，押注LLM路徑的巨頭們，是否該重新計算自己的置信區間？