根據 OpenAI 在 2026 年 10 月 19 日發布的研究文章，該組織說明了最新模型在低資源程式語言上的進展。所謂低資源程式語言，指的是相對於 Python、JavaScript 等擁有大量公開程式碼與文件的語言，模型可學習的資料明顯較少，但這些語言卻支撐著全球關鍵基礎設施與必要服務。文章舉例，COBOL 支援超過 40% 的線上銀行系統、80% 的面對面信用卡交易，以及 95% 的 ATM 交易；Fortran 則被用於天氣預報與核反應器安全分析。換句話說，這些語言雖然在一般開發者社群中聲量不高，卻與金融、能源、公共安全等領域的日常運作緊密相連。
企業在維護與現代化這類系統時，常遇到幾個現實問題。文件可能不完整，當年撰寫程式的開發者可能已經離開公司，重要的業務規則往往只存在於程式碼本身，而沒有被完整記錄下來。因此，當團隊要除錯或把系統遷移到另一種語言時，真正困難的不只是語法轉換，而是必須保留系統原本的行為。OpenAI 在文章中指出，這項工作受到開發者與企業客戶回饋的引導，因為許多人反映編碼模型在這些語言上經常表現不佳。為了衡量進展，OpenAI 設計了兩項評估，分別測試互補的能力：從零開始建置新軟體，以及保留既有軟體的行為。
兩項互補評估：從零建置與行為保留遷移
第一項評估是 MultiLangBench，它要求模型用 20 種不同程式語言，從頭建置一個與 SQLite 相容的資料庫引擎。SQLite 是一種輕量、嵌入式關聯式資料庫引擎，廣泛用於各種應用中。MultiLangBench 的設計重點在於，模型必須組織程式碼庫、管理狀態、處理錯誤，並在加入新功能的同時維持既有功能。為了讓不同語言的實作可以互相比較，評估採用資料庫檔案作為共同介面：候選程式會收到一個初始資料庫與一道 SQL 查詢，然後產生修改後的資料庫；接著再用參考的 SQLite 實作來檢查結果資料庫的內容是否符合預期。這種做法讓同一套測試可以套用到所有語言，而不必為每種語言重新設計檢查方式。測試內容改編自 SQLite 既有的測試套件，並同時報告測試通過率與 API 成本。
第二項評估聚焦在 COBOL 程式碼庫的遷移。它要求模型把 COBOL 程式轉換到 C++、Java、Kotlin、Python 或 Rust，並且保留每個程式的行為。成功的遷移不僅需要理解程式的業務邏輯，還必須掌握 COBOL 特有的語言行為。文章特別以財務計算為例：COBOL 的定點算術在未明確要求捨入時，會直接捨棄多餘的小數位；如果改寫後的程式改成四捨五入，程式可能順利執行、不產生錯誤，卻會得到不同的財務結果。為了確認這類行為是否被保留，評估使用隱藏測試，要求可觀察輸出必須達到逐位元組一致，而且只有全部測試通過才算成功遷移。這也點出這類行為保留能力雖然對維護舊系統很有價值，但實際套用到生產軟體時，仍然需要專家審查，並針對系統的業務規則與相依性進行測試。
模型結果：準確度提升與成本下降
在 MultiLangBench 上，OpenAI 表示 GPT‑6 Astra 在最大推理努力下，於 20 種程式語言中達到平均 87.4% 的測試通過率，相較之下，GPT‑5.6 Sol 僅有 26.8%，而且每一種受測語言都有改善。其中 COBOL 從 10.9% 提升到 72.1%，OCaml 從 25.6% 提升到 85.8%，Fortran 從 21.4% 提升到 83.5%，Visual Basic 從 27.5% 提升到 89.4%。Astra 在 20 種語言中有 19 種得分超過 83%，COBOL 仍是最難的語言，停留在 72%。另一個模型 GPT‑6 Luna 則提供較低成本的選項，同樣在每種語言上優於 GPT‑5.6 Sol，最大推理努力下的平均測試通過率為 40.3%；其改善包括 COBOL 從 10.9% 到 17.1%、OCaml 從 25.6% 到 34.1%、Fortran 從 21.4% 到 31.4%、Visual Basic 從 27.5% 到 41.6%。這些結果伴隨的估計平均 API 成本為每樣本 0.77 美元，而 GPT‑5.6 Sol 為 3.48 美元，約降低 78%。OpenAI 也把 MultiLangBench 的評估設定與測試套件發布在 GitHub，並附上各語言結果，讓開發者能檢查評估內容、查看自己使用語言的表現，並找出對自身工作重要的落差。
在 COBOL 遷移評估方面，GPT‑6.1 Sol 在低推理努力下達到 86.6% 的準確度，相較之下，GPT‑5.6 Sol 在同設定下只有 5.4%，而且成本僅為其 61%。當推理努力提高時，GPT‑6.1 Sol 的準確度進一步達到 97.9%，幾乎讓這項評估達到飽和。這些數字顯示，模型在跨語言程式開發與遷移上，正同時朝著更準確與更具成本效率的方向前進。
技術脈絡：為什麼行為保留比編譯成功更難
從技術角度來看，低資源程式語言的挑戰不只在於語法或少見的關鍵字。這些語言通常有各自的生態系、工具鏈、執行環境與測試習慣，而且公開可得的範例、文件與討論相對稀少。模型若要在這類語言中有效工作，必須能夠理解不熟悉的程式碼儲存庫、規劃變更、使用建置工具、執行測試，並在失敗時進行除錯。OpenAI 的文章把這組能力視為軟體工程技能的延伸，而不是單純的翻譯任務。尤其在 COBOL 這類處理金融交易與業務記錄的語言中，許多細節看似微小，卻直接反映業務需求，例如捨入規則、缺失記錄的處理方式，以及定點數的精度行為。一旦遷移過程改變了這些語意，系統可能在技術上「可執行」，卻在業務上產生錯誤結果。這也是為什麼逐位元組比對與完整測試通過會成為評估門檻。
實務意義與限制
對企業而言，這類進展的意義在於，維護與現代化舊系統的團隊可能獲得更實用的輔助工具。當模型能更準確地產出可運作程式碼，或以較低成本完成大規模遷移的前期工作，團隊就能把人力集中在業務規則確認、架構決策與風險控管上。不過，文章也明確指出限制：即使評估表現亮眼，實際生產軟體仍需專家審查，並針對系統的業務規則與相依性進行測試。COBOL 在 MultiLangBench 中仍是最難的語言，顯示低資源語言的進步空間依然存在。此外，評估分數並不等於在所有真實專案中都能直接套用，因為每個系統的歷史包袱、相依套件與營運限制都不相同。
OpenAI 表示，這些評估與開發者、企業客戶的直接回饋，能幫助了解模型在哪些方面改善、哪些方面仍不足。其目標是讓模型把軟體工程技能應用到更多語言，並透過 API 讓使用者在團隊採用的語言上嘗試最新模型。使用者的回饋，包括哪些任務有效、模型在哪裡遇到困難、接下來應聚焦哪些語言或工作流程，都會影響後續訓練與評估的方向。整體而言，這篇文章傳達的訊號是：低資源程式語言不再只是被忽略的角落，而是 AI 輔助軟體工程能否真正支援關鍵基礎設施的重要試煉場。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。