這幾天在跑一個照片辨識 pipeline，流程是這樣：Opus 5 寫每一輪的規格和驗收條件，DeepSeek V4.1 Flash 走 opencode-go 路由負責實作，本機 VLM 讀圖。第五輪的規格丟過去，Flash 開工前先停下來問了一個問題。
分類規則跟驗收條件互斥。
規格寫的是「regex 命中而且對照表查得到 → 目標類別」，驗收條件又要求某一批的目標類別剛好是連號的 26 張。Flash 把規則對兩批既有的分類報告跑了一遍，逐張數，發現有 5 張 regex 命中但對照表查不到：一張是某個字讀錯、換掉就救得回來，一張讀出來的編號本來就不在對照表，另外三張直接組不出編號。嚴格照規格跑，這批剩 21 張，三條驗收條件一起 FAIL。
它給了三種處理方式，標了一個推薦，然後等我決定。
另一個專案，同一組模型，同一天
人行道路徑的無障礙判定。一樣 Opus 5 寫規格，Flash 實作。這輪要求改三個地方，其中一條驗收條件寫的是：某條路線整條不准出現 LAST_RESORT。
Flash 做完三個改動，回報：LAST_RESORT 佔 15.23%，cap 是 15%，那條路線的驗收也還是 FAIL。兩個問題它都往回查到三個改動以外的規則和資料。然後給了三個選項：照三個改動 commit 並回報缺口；加第 4 個改動（比對距離 6 m 改 12 m，它量過，掉到 11.7%，過 cap）再 commit；或者先不 commit，去查普查資料跟驗收條件到底誰錯。
沒 commit 任何東西。
普查資料裡那條路線本來就有三段真的窄，0.69 m、0.85 m 那種。「整條不准有 LAST_RESORT」在寫的時候沒對著普查資料重算過，跟「剛好 26 張」是同一種錯，條件是憑上一輪印象填的，不是跑出來的。
兩個專案、兩種資料，同一個洞。
opus 5 caught by deepseek 4.1 flash?
第一個反應是這個。
但仔細看，兩次都不是靠推理猜出來的。是把規則寫成程式、對資料全量跑、數出來跟驗收條件比，矛盾自己浮出來。這種東西在寫規格的時候幾乎看不見。26 這個數字是照上一輪 regex 命中數填的，規則文字後來又多加了一個查表條件，兩邊各自看都合理，要跑過資料才會撞在一起。
寫規格的人是抽查，實作的人是全量枚舉。
我比較在意的是它接下來做的事：兩次都是發現矛盾之後停下來問，沒有自己挑一個安靜做掉。第二次它已經量出 12 m 可以過 cap，還是沒 commit。很多模型在這種情況會直接選「放寬」，然後在回報裡輕描淡寫帶過，你要到驗收 FAIL 或 PASS 得很可疑才會回頭發現。
可是 Opus 5 不是比 4.1 Flash 強？兩邊都能跑檢查啊
對，而且寫規格的那個 session 確實有跑實測：量裁切框的座標、確認對照表的欄位、確認某個編號查不到。所以不是能不能跑，是有沒有想到要跑。
它跑的都是自己覺得不確定的東西。座標、欄位。「剛好 26 張」跟「整條不准」它沒當成不確定，因為數字是上一輪回報來的、規則是上一輪驗過的，這輪只是加一個條件，看起來是收緊。沒重算的是：收緊之後還剩多少。
更尷尬的是證據就在它自己手上。照片那個專案，第四輪的合成測試案例是它寫的，裡面明明白白有兩條：一個是「這種讀法組不出編號」，一個是「這個編號組得出來，但不在對照表」。就是那 5 張裡的兩張。寫測試案例的時候知道這兩張過不了查表，寫分類規則的時候又要求必須查得到，兩段隔了幾十行，沒接起來。
兩段分開看都沒錯。能力高低不太影響這種事，因為根本沒有東西觸發它回頭重算。
換成 Opus 5 去實作、Flash 寫規格，我猜多半還是實作方抓到。
本來我以為這個洞有一半是我的，絕對條件是我的寫法。
回去翻了兩串對話，不是。「剛好 26 張」跟「整條路線不能有任何 LAST_RESORT」都是 Opus 5 自己寫的。人行道那條，我給它的只有一句現場觀察：以明德國小為分界，往振興方向 OK，往捷運站會越來越不 OK。它先提議「明德路上不能出現 LAST_RESORT」，寫進 prompt 時又擴大成整條路線。15% 的上限，它自己也註明是估的，沒有實測。
我的部分在 AGENTS.md：派 DeepSeek 的前提是驗收要機器判得出來，prompt 要釘死。這會把規格往硬數字推，但數字要不要對著資料重算，裡面沒寫。
那分數呢
去查了 DeepSWE 跟 Terminal-Bench，數字對這件事蠻有解釋力。
接近或反超的（都是廠商自報，harness 不一樣）：
- Terminal-Bench 2.1：Flash 90.6 對 Opus 5 89.1。Flash 用自家 harness 90.6，用 mini-SWE 90.3，用 Claude Code 88.0
- DeepSWE v1.1：Flash 74.2，Opus 5 各家寫法不一，有的寫 74.0，Anthropic 自己公布的是 68.8
- AutomationBench：Flash 54.8 對 Opus 5 50.3
拉開差距的：
- Terminal-Bench 4.0（9 月初剛換的難版）：Opus 5 51.8、Fable 5.1 57.9（官方榜），Flash 31.2
- HLE：Opus 5 56.3 對 Flash 36.8
- NL2Repo：Opus 5 75.3 對 Flash 65.4
DeepSeek 自己的表上，兩邊都有數字的 15 項 benchmark 裡，Flash 贏 5 項、平均贏 1.94 分；Opus 5 贏 10 項、平均贏 10.19 分。光是 harness 選擇就能讓 DeepSWE 擺盪好幾分，所以 TB 2.1 那種一兩分的差距基本上是雜訊。
Flash 抓到矛盾的那種工作，照規格寫程式、跑資料、對驗收條件，就是 TB 2.1 和 DeepSWE 在量的東西，兩邊本來就接近飽和。Opus 5 真正拉開的是 TB 4.0、HLE 這種要自己撐長推理鏈的難題。寫規格時漏掉「加了條件後重算數量」，難度沒那麼高，就是沒觸發檢查。
在「執行加驗證」這個工作型態上，兩者差距小到誰拿到資料誰就贏。
規格方做了什麼
Flash 找到矛盾，怎麼補是規格方設計的。
人行道那條驗收，從「整條不准」改成把絕對條件綁回資料：LAST_RESORT 只准落在普查記錄的窄段、或它們所在的同一條邊上，落在別的地方才算失敗，而且每一段都要列出寬度、障礙物數量、速限、密度。
比對距離放寬那條也不能只看比例降了。要 Flash 印出 6 m 跟 12 m 各自對到的邊數，還有多邊形道路名稱跟 OSM name 不一致的邊數。12 m 的不一致率比 6 m 高超過 2 個百分點，就停下來回報，不准 commit。這個 2 個百分點，Opus 5 也註明是抓的安全邊界，沒有實測。
所以這兩次是分工做完的：Flash 找矛盾，Opus 5 改驗收。這兩件事我目前沒看到單一模型自己做得好。
之後怎麼做
兩邊各加一條。
寫規格那方：每個帶數字或絕對條件的驗收發出去之前，用現有的報告把新規則模擬一次重算。跑不到 10 秒。這兩次的矛盾在那一步就會現形，不用等 Flash 那邊來回一趟。
實作那方的第 0 步：開工前先把這些驗收對現有的報告和資料跑一遍，有矛盾先回報，再寫程式。Flash 這兩次是自發做的，把它寫死成流程。
Flash 留著當實作主力。原本我不打算讓它寫規格，有好幾個實際上手的測試說它在 benchmark 暗示應該輕鬆處理的任務上會卡住。
但 Flash 寫規格會怎樣，我沒試。現在說「不讓它寫」，是憑第三方的實測報告加 benchmark 差距推的，跟我批評規格方「數字憑上一輪印象填」是同一種推法。
下一輪讓它起草、Opus 5 審，看看。