GPT-6.1 Sol 在 COBOL 上：86.6% 對 5.4%，且兩項測試中只有一項可重新執行

在 2026 年 10 月 19 日，OpenAI 針對低資源語言發布了兩項程式設計評測，而最受矚目的數字屬於 GPT-6.1 Sol：在低推理強度下，有 86.6% 的 COBOL 遷移任務通過；相較之下，GPT-5.6 Sol 在相同設定下僅有 5.4%，當推理強度提高時則升至 97.9%。第二項評測 MultiLangBench 則是另一個模型的故事——GPT-6 Astra 在最高推理強度下，於二十種語言平均達到 87.4%——但它是這次發布中更有用的那一半，因為 OpenAI 將其測試框架以 Apache-2.0 授權放到 GitHub 上，你今天下午就能自己跑一遍。承載那 86.6% 的 COBOL 遷移評測則是另一回事：它的測試是隱藏的，通過標準是與 OpenAI 外部無人見過的案例進行逐位元組輸出比對，而且沒有任何第三方重現過它。這種不對稱正是全貌所在，而在任何一個數字被引用進遷移商業案例之前，值得把話說清楚。 這類發布背後的已記錄 AI 失敗與代理事件，都收錄在 OrcaRouter AI Incident Archive，其中每一條都附有自己的來源、嚴重程度、信心等級與爭議標記。

先釐清一個日期。GPT-6.1 Sol 本身出自2026年9月29日——這不是一次發布，而且這裡沒有任何內容會改變該模型的權重、價格或費率表。10月19日發生的事，是 OpenAI 公布了證據，說明該模型在一個先前未曾記錄的類別中能做到什麼，並發布了一套任何人都能重跑的基準測試。這正是本文所要談的事件。

實際發布了什麼，以及每一半各自的用途

這兩項評測回答的是不同問題，而 OpenAI 自己的說法將它們區分開來。MultiLangBench 問的是，模型是否能打造某個東西——用一種沒有人訓練過的語言：用二十種程式語言之一從零實作 SQLite 3.40.1，然後通過資料庫符合性測試套件。COBOL 遷移評測問的是，模型是否能搬移某個東西：把 COBOL 程式轉譯成 C++、Java、Kotlin、Python 或 Rust，同時精確保留可觀察到的行為。

第一個是能力下限測試。第二個才是企業真正在乎的，因為 COBOL 並非只是基準測試中引人好奇的題材——IBM 長期以來的估計指出，超過 40% 的網路銀行系統與約 95% 的 ATM 交易背後都是 COBOL，而維護這些程式碼的人力卻沒有新血接替。

• MultiLangBench，最大努力——GPT-6 Astra 87.4%、GPT-6 Luna 40.3%、GPT-5.6 Sol 26.8%。Astra 在 20 種語言中有 19 種突破 83%；COBOL 是它表現最弱的一項，僅 72.1%，而 GPT-5.6 Sol 只有 10.9%，這告訴你：這組語言中最難的，依然是工具鏈最古老的那一個。

• COBOL 移轉，低投入 — GPT-6.1 Sol 86.6%，GPT-5.6 Sol 5.4%，在評估執行中估計為較舊模型 API 成本的 61%，即減少 39%。

• COBOL 遷移，投入較高 — GPT-6.1 Sol 97.9%，O​penAI 稱其已接近飽和。

• OpenAI 確實公布了各語言的詳細數據——Fortran 方面，Astra 為 83.5%，GPT-5.6 Sol 為 21.4%；Visual Basic 為 89.4% 對 27.5%；OCaml 為 85.8% 對 25.6%；GPT-6 Luna 在 COBOL 上為 17.1%，Fortran 上為 31.4%，OCaml 上為 34.1%，Visual Basic 上為 41.6%。

• MultiLangBench 上每個樣本的成本 — GPT-6 Luna 估計為 0.77 美元，而 GPT-5.6 Sol 為 3.48 美元，低約 78%；正是這個數字，讓榜單上最弱的模型成為建置生成管線中值得關注的那一個。

你可以重新執行的評測：MultiLangBench 真正要求的是什麼

該儲存庫位於github.com/openai/MultiLangBench，採 Apache-2.0 授權，而且閱讀測試框架比閱讀排行榜更有資訊量。這項任務足夠具體，模型無法蒙混過關：產生一個可執行檔，接受資料庫路徑作為命令列引數，從 stdin 讀取 SQL 查詢，並表現得像 SQLite 3.40.1。測試來自 SQLite 自家的 TCL 測試套件——總共約 51,000 項測試，其中約 24,000 項被轉換成測試框架使用的三元組：初始資料庫、使用者查詢與驗證查詢。測試名稱是這些組成部分的 SHA-256 雜湊，因此無法藉由名稱記住整個測試套件。

規則正是難度所在，而每一條都堵住了一條捷徑：

• 沒有網路，且環境中完全沒有 SQLite。 測試框架表示要先清除 SQLite 的所有痕跡。模型無法透過 shell 呼叫真正的引擎，也無法取得實作。

• 驗證是針對真實的 SQLite 3.40.1 執行。你的實作會修改資料庫；測試框架會將其擷取出來，並用貨真價實的版本進行檢查。近似行為一律不合格。

• 每項測試限時六十秒，語言錯誤的答案得零分。混用語言會失敗，而測試框架指出，可能會使用另一個模型來檢查你實際使用哪種語言書寫。最後這條規則之所以存在，是因為顯而易見的作弊方式——用 Python 寫再包裝起來——正是有能力的模型最先嘗試的做法。

• 快速執行是 272 項測試，不是 24,000 項。 README 建議只執行名稱以 00、01 或 02 開頭的測試，當你想要可比較的數字時。這是在你將自己的分數與 O​penAI 的比較之前要注意的細節：完整套件執行和快速執行不是相同的測量，而 README 也如此說明。

這是一個真實且可驗證的基準。它還透露了新聞報導沒告訴你的事：那個 87.4% 的頭條數字，是在一套你可以直接套用在自家模型上的測試套件上測得的——這種情況罕見到值得你下載。

你無法重新執行的評測，以及為何這不必然是一樁醜聞

COBOL 遷移評估由 O​penAI 設計、O​penAI 執行、O​penAI 評分，且其測試案例並未公開。通過門檻有精確表述——唯有每個隱藏測試都產生逐位元組完全相同的可觀察輸出，遷移才計入——而這種精確性正是讓結果無法從外部驗證的原因：86.6% 是 O​penAI 以自家隱藏案例為準所做的測量。此次發布的兩項評估中，只有一項是讀者可以重現的。

不公開遷移測試並非站不住腳。該語料庫想必取自真實的舊有程式，而公開它可能洩漏客戶程式碼，或把訓練集交給未來的模型。逐位元組完全一致也是真正保守的標準，比大多數廠商評測更嚴格：它不會獎勵僅僅接近的翻譯。

但這個標準也正是實務麻煩的起點，而 OpenAI 自己的注意事項也指向這一點。遷移輸出在正式上線前，仍需專家審查，並針對業務規則與系統相依性進行測試。而位元組一致性（byte parity）最難的地方，正是 COBOL 本身困難之處：這種語言對定點運算的截斷與捨入方式，是多數目標語言不會採用的，因此翻譯結果可能看似正確、通過一套只檢查「夠接近」的測試，卻仍讓餘額差了一分錢。要求完全相等的隱藏測試套件能處理這點；你自己的審查流程也必須處理這點，因為模型的分數並不是對你的程式所做的陳述。

成本數字也需要同樣謹慎看待。39% 的節省是評估執行階段的估計值——也就是基準測試輸入與輸出的 token——而不是汰換生產系統的成本；後者主要取決於探索、專家審查、整合測試，以及多年來未記錄的行為，而這些行為沒有任何評估樣本能夠涵蓋。

86.6% 和 97.9% 應該在決策中改變什麼？

誠實的解讀比新聞標題更狹隘，卻也比它們更有用。5.4% 的基線不是一個半可用的模型；它是一個幾乎永遠產不出保持行為不變之譯文的模型，因此舊世代從來不是這項工作的候選。GPT-6.1 Sol 達到 86.6%，已進入經濟效益反轉的區間：一個能起草大部分譯文、再留給審閱者檢查的工具，與一個產不出任何可用內容的工具，是截然不同的產品。

在較高投入程度下的 97.9% 才是值得懷疑的數字；不是因為它錯了，而是因為它已經飽和。一旦基準測試接近上限，它就不再能區分模型，而開始衡量測試套件本身，OpenAI 也這麼說。規劃時，請把低投入程度下的 86.6% 視為低成本運作點，並把 97.9% 視為此評估所能呈現的上限——而不是對你程式碼庫準確度的承諾。

還有一項值得做的交叉檢查，而且它與炒作相悖。在建置測試中，COBOL 仍是 GPT-6 Astra 最弱的語言，僅達 72.1%，儘管 Astra 整體是更強的模型，平均達 87.4%。這門語言在兩個方向上都很難。一個在隱藏評測中能良好遷移 COBOL 的模型，並不因此就擅長 COBOL；它只是擅長評測所取樣的模式。

本週發生的另一件事：關於推理軌跡的說法

10 月 21 日一篇廣為流傳的貼文稱，GPT-6.1 Sol 的推理軌跡「完全可讀，沒什麼好擔心」。O​penAI 10 月 19 日的發布內容中，以及該模型自身文件頁面上，都沒有任何內容支持這是 API 回傳內容的變更。O​penAI 的推理指南明確指出，原始推理 token 不會被揭露——推理項目仍保持不透明——而你可以要求的是 summary（推理摘要），並透過 summary 參數取得，且加密的推理內容會跨回合重播。GPT-6.1 Sol 支援該重播的 all_turns 形式。摘要通道並不等同於可讀的軌跡，而把兩者當成同一回事，正是安全主張靠截圖做出的方式。

可量測的部分與此相鄰，而且對任何要稽核代理的人來說更有意思。Sonar 於 10 月 9 日對 GPT-6.1 Sol 的評估，是在 4,444 個 Java 任務上，以中等投入程度與 GPT-6 Sol 對照執行，結果發現推理 token 下降了 51.4%——從 264 萬降到 128 萬——而推理占輸出量的比例從 41.8% 降至 19.5%，輸出量上升，功能通過率則從 83.09% 提升到 85.29%。同一輪執行也發現漏洞密度下降 32.4%，但嚴重等級的可靠性發現從 21 項增加到 46 項，其中併發錯誤是最大類別，有 196 項發現。這是審查者可以據以行動的取捨。「軌跡可讀」則不是，因為被回傳的並不是那些軌跡。

對遷移專案來說，這件事有一個很具體的重點：你的稽核軌跡是 diff 和測試輸出，而不是模型的敘述。請據此編列審查量能——Sonar 的發現是，多出 39.4% 的生成程式碼，產生 12,982 項總發現，而對照組是 9,859 項；這正是藏在基準測試分數背後的成本樣貌。

你親自同時經營兩邊

這類比較的實際問題在於，基準組與新組通常是兩份合約、兩把金鑰和兩段計費關係，這樣的摩擦足以讓沒有人會去跑基準。兩款模型都放在我們的目錄中、位於同一把金鑰之後：openai/gpt-6.1-sol 與 openai/gpt-5.6-sol，依 OpenAI 的定價表價格、零加成提供，因此每百萬個 token 的輸入費用 $2.00、輸出費用 $10.00，與你直接付給供應商的價格相同；快取輸入為 $0.10，快取寫入為 $2.50，而超過 272K 的級距也原樣轉嫁，分別為 $4.00、$0.20、$5.00 與 $15.00。供應商的費率變更在公布當天就會在此生效，而不是等到下一次合約審查。

這種直通機制正是讓當日基準測試得以低成本執行的原因：將 {{1}}MultiLangBench{{/1}} 快速套件指向兩個模型，並各自支付牌價，你得到的數字是關於你自己的工具鏈，而不是 {{2}}O​penAI{{/2}} 的。自動容錯移轉是這個論點的另一半——如果較新的模型在執行中途效能下降，或某條路由被限流，請求不會隨之失敗，這正是讓你能在擁有自己的證據之前，把未經證實的模型放在遷移管線前面的原因。

MultiLangBench 測試框架是公開的，而 COBOL 遷移案例則不是，因此對 86.6% 唯一誠實的測試，就是你自己打造的那個：抽樣幾百個你自己的 COBOL 程式，將它們翻譯，並把輸出與原始行為逐位元組比對。那是要花一週的工作，而且比廠商表格更有價值。

接下來要看什麼

有三件事會改變這個局面，而目前一件都還沒發生。O​penAI 公布 COBOL 遷移案例，或由獨立實驗室重新執行這些案例，將能讓廠商提供的數字變成可量測的結果。第三方重現 MultiLangBench 的各語言表格，將能告訴我們 COBOL 的 72.1% 是這門語言的特性，還是這套測試套件的特性。而該模型的獨立基準評測紀錄——Artificial Analysis 目前將 GPT-6.1 Sol 的 Intelligence Index 列為 52，在 214 個模型中排名第十二，輸出速度為每秒 55.2 個 token，每項 index 任務成本為 $0.72——則是完全不依賴 O​penAI 自家評測的查核。

在那之前，有用的總結很短。GPT-6.1 Sol 是 9 月 29 日的一款模型，其遺留程式碼能力於 10 月 19 日被記錄下來，體現在一項你能執行、一項你不能執行的評測中。可執行的的那項說，新世代在低資源語言上處於不同級別。不可執行的的那項則說，COBOL 遷移現在值得先做試點。只有你自己的程式碼庫，才能把其中任一項變成決策。