9 月 13 日，一家叫 Specific Labs 的機構掛出了一份新排行榜，名字是 Real-SWE。它跟以往那些程式基準有一處關鍵的不同：題目不是從 GitHub 上扒的公開 issue，是從幾家真實公司手裡買斷授權、直接搬出來的生產程式碼庫任務。每一道題原本都派給了一個拿薪水的工程師。
十道題，八套「模型 + 命令列工具」的組合，每道題每套跑八次，一共 640 次評分。榜首那一欄是 Claude Code 跑 Fable 5.1，通過率 38.8%。
完整的一份排行榜
Specific Labs 把模型和它的原生命令列工具綁在一起評，理由是企業工程師本來就這麼做事：
- Fable 5.1（Claude Code）38.8%
- GPT-6 Astra（Codex CLI）33.8%
- Gemini 3.8 Flash（Gemini CLI）31.2%
- GLM 5.3（Claude Code）28.8%
- Grok 4.6（Grok Build）23.8%
- Muse Spark 1.3（Muse Code）23.8%
- Kimi K3（Kimi Code）18.8%
- GPT-5.6 Sol（Codex CLI）16.2%
通過率等同於 pass@1，每道題跑八次取平均。
真正該看的不是這個排名，是題目那一側的分布。十道題裡有六道，所有模型合起來的通過率不到 15%。最難的一道叫「分析流歸約器」，八個模型各跑八次，64 次嘗試一次都沒成。倒數第二道是稅務轄區判定，通過率 3.1%，全靠 Fable 5.1 和 GLM 5.3 各碰對的那一次撐著。
難的地方不在演算法
Specific Labs 公布了兩個衡量題目形狀的中位數。指令本身的中位長度是 1742 個字元，跟 DeepSWE、Terminal-Bench 那一檔差不多。但參考答案的中位數要改 11 個檔案，而 FrontierCode 和 DeepSWE 都是 6 個。
一道題的沙箱裡掛著什麼，也說明了問題。AWS 模擬器、Docker、Kubernetes、GitHub、Linear、PostgreSQL、MySQL、MongoDB、Redis，再加上 Slack、Intercom、Google Drive 和 ClickUp。排行榜裡那道稅務題的指令，講的是這麼一件事：平台上每家商戶結稅的方式都不一樣，有的自己維護稅率，有的要按買家收貨地去第三方稅務服務商那裡即時定價，有的乾脆不收；已經拿到免稅憑證的客戶無論商戶怎麼設定都不能被收稅；發票結清之後還要把這筆銷售按發票號回報給稅務方，好讓申報對得上帳；歐盟雙方之間的發票兩邊的加值稅號都得印上去。
這不是一道演算法題。這是一個人在某家公司待夠了時間才知道的東西。
失敗的分法比通過率更有資訊量
Specific Labs 沿用 DeepSWE 的分類，把失敗的那 468 次逐條歸了類。不同模型栽的地方明顯不一樣：
Grok 4.6 失敗的 61 次裡有 41 次是漏需求（67.2%）——指令裡寫了的行為，交上來的修補沒做。Gemini 3.8 Flash 失敗的 55 次裡有 27 次是整合錯誤（49.1%），思路對，接進周圍的系統時接錯了。GPT-5.6 Sol 失敗的 67 次裡有 29 次屬於「沒核實的假設」（43.3%）：它對這套系統怎麼運作做了一個猜測，然後不去工作區裡查一眼，直接往下寫。
Fable 5.1 那 49 次失敗攤得比較平：漏需求 18 次（36.7%），整合錯誤 17 次（34.7%），沒核實的假設 12 次（24.5%），改壞了原有行為的只有 2 次（4.1%）。
還有一組數字值得單獨拎出來。跑不到 10 分鐘的 98 次裡失敗了 70 次，失敗率 71.4%；跑滿 10 分鐘以上的 542 次裡失敗了 398 次，失敗率 73.4%。讓 AI 代理人多想一會兒，通過率沒有變好。
一筆算得出來的帳
每次執行的估算成本從 Gemini 3.8 Flash 的 2.50 美元到 Fable 5.1 的 6.96 美元。這條曲線不是單調的：Gemini Flash 花 2.50 美元拿到 31.2%，GLM 5.3 花 5.12 美元拿到 28.8%，多付一倍的錢，通過率反而低了兩個多點。
把單次成本除以通過率，可以倒推出「真正做成一道題」的期望花費。Fable 5.1 是 6.96 除以 0.388，約 18 美元；Gemini 3.8 Flash 是 2.50 除以 0.312，約 8 美元。這兩個數字是從排行榜公布的資料算出來的，不是 Specific Labs 自己給的。
18 美元換一個改動，聽上去仍然比一名工程師的一小時便宜得多。但這筆帳少了一項：那 61.2% 沒做成的執行，輸出的不是空白，是一份看起來完整、需要有人讀完才能判定它漏了哪條需求的修補。
真正被抬高的是哪個職位
Specific Labs 在文章裡點了一句：真實企業裡 99% 的 token 藏在模型看不到的地方。
這句話解釋了為什麼排行榜上的分數會掉到這個量級，也解釋了軟體工程這個職業接下來往哪邊走。我們 6 月 26 日寫過裁員刀口先落在了管理層而不是工程師身上，9 月 9 日寫過 Cognition 把工程師挪到監督位。Real-SWE 把那個監督位具體化了：它要監督的是五類失敗——漏掉的需求、沒核實的假設、接錯的整合、改壞的舊行為、改到了根本沒被呼叫的檔案。
這五類裡沒有一類是靠讀程式碼就能發現的。要抓住漏需求，你得先知道這家公司的業務規則裡免稅客戶是怎麼定義的；要抓住整合錯誤，你得知道這個改動下游還有誰在呼叫；要抓住「改錯檔案」，你得知道生產環境裡跑的到底是哪一份。
所以在企業這一側，價值正在從寫程式這個動作，挪到手裡攥著公司專屬脈絡的那個人身上。初階職位受的擠壓最直接。過去累積這份脈絡的方式，正是從小改動一點一點做起，而小改動現在多了另一個供給來源。同時被抬起來的是另一類工作：能把任務講清楚到 AI 代理人做得對的人，和能在修補合進主幹之前看出它漏了什麼的人。
接下來盯什麼
Real-SWE 只有十道題、三家公司的程式碼庫，樣本小，這一點排行榜自己也沒藏。它值得追的原因不在分數本身，在方法：一旦有人開始拿授權來的私有生產程式碼庫出題，公開基準上那些好看的數字就有了一個對照面。
我們會盯兩件事。一是這份排行榜擴到幾十家公司之後，38.8% 是往上走還是往下走；二是有沒有企業開始把「AI 代理人提交的修補必須經人複核」寫進流程文件。那一步落下來，這份失敗分類表才第一次變成一個正式的職位。
