同一個 DeepSeek 模型，放在 Codex 和 DSH 裡，10/10 和 9/10 差在哪？

九項行為測試通過，不代表指定的原始檔已經被修改；雜湊與匯入路徑補上了這個空位。

測試畫面跳出 9/9 的那一刻，我沒有先收工，而是回頭看了一眼目標檔案。這不是多疑，而是前面 DSH 已經演過一次：測試很誠實地通過，檔案也很誠實地沒有改。

兩邊使用同一個 deepseek-v4.1-flash，都連到同一個 API 位址。Codex 這一邊花了 3 分 59 秒，改對 inventory_service.py；DSH 也拿到九項通過，但 Python 匯入的是旁邊新增的同名套件。功能真的存在，只是不在任務指定的位置。

這也是整件事值得記下來的原因。模型能不能寫出看起來合理的程式，跟它能不能在一個工作區裡完成修改、重跑與交付，是兩個不同層級的問題。

先看驗收，不先看畫面

庫存服務的需求不大，失敗方式倒是很完整。結帳必須一次成功或一次失敗，不能發生前面已扣、後面因庫存不足而中斷。同一個 SKU 要先合併再檢查數量。非法數量要有固定回應。snapshot() 不能把可變的內部資料直接交出去。兩個執行緒不能同時買走最後一件。

測試也壓了競爭條件：五十個執行緒搶七件庫存，四十個執行緒同時買兩種有限商品。這不是只靠補幾個 if 就會穩過的題目。

Codex 先跑測試，讀到失敗訊息，再沿著庫存方法追到驗證與鎖定位置。修改後重新執行，九項行為測試通過。指定檔案最後的 SHA-256 是：

008AF21A36C45CDBB9513961DBF52E2E663791EF5CA5A31FB018871F1F4EF66D

修改前的種子檔是：

5F8FA06F3A9B9ED7022CE2EEC9158D0139DEC6716872FAC8F9D0E86DDC7C88F8

這組差異不能拿來宣稱鎖定設計一定正確。真正的併發風險仍要人工看 diff，重要服務還要另外做壓力測試。它只回答一件很窄、卻很容易被跳過的事：這次執行到底有沒有動到任務指定的檔案。

把 DeepSeek 接進 Codex

我用的設定很短，金鑰放在環境變數，不寫進檔案：

model = "deepseek-v4.1-flash"
model_provider = "crazyrouter"

[model_providers.crazyrouter]
name = "Crazyrouter"
base_url = "https://api.crazyrouter.com/v1"
env_key = "CRAZYROUTER_API_KEY"
wire_api = "responses"
requires_openai_auth = false

排錯時，不要把所有失敗都當成「模型不夠好」。這張設定至少有四層可以分開確認。

第一層是環境變數。金鑰沒載入時，請求根本還沒到模型。第二層是路由，模型 ID、基礎位址或供應商設定不一致，客戶端可能連上閘道卻選不到模型。第三層是介面協議，wire_api = "responses" 與 requires_openai_auth = false 必須和實際供應方式相符。第四層才是工作區權限：模型有回應，但 Codex 不能執行指令，問題就在 agent 的工作環境，不在推論本身。

分層測試還有一個好處：每一步都能留下不同的證據。短回覆證明路由存在，無害指令證明工作區可以執行，真正跑測試時才不會把先前兩層的問題混進來。

重現、修改、重跑與核對各自留下可檢查的結果，最後才把工作當成交付。

第二個 9/9 為何仍然不算完成

DSH 建立了 inventory_service 套件，放在比原始模組更早被 Python 找到的位置。測試匯入新套件，裡面的實作確實通過九項行為。指定的 inventory_service.py 則維持原樣。

把驗收拆成十份：九份看行為，一份看交付檔案。Codex 是 10/10；DSH 是 9/10。少掉的那一分不是效能，也不是程式風格，而是工作落在哪裡。

這裡真正該修的是驗收流程。任務同時指定了「行為要正確」與「修改哪個檔案」，檢查卻停在 9 passed。如果測試程式只讀自然語言摘要，沒有追問模組來源，綠燈就只證明目錄裡有某份可用實作。

修正方式不需要更花俏的提示詞。Agent 結束後，另外跑一段固定檢查就好：

$target = Join-Path $PWD "inventory_service.py"

(Get-FileHash $target -Algorithm SHA256).Hash
python -c "import inventory_service; print(inventory_service.__file__)"
Get-ChildItem -Name inventory_service*

這段指令會碰到三種常見情況：目標檔沒有改變、Python 匯入同名套件、測試讀到舊安裝。實際使用時把模組名稱換成專案中的名稱即可。

行為測試和檔案交付是兩份證據；只有兩者指向同一次執行，才算閉環。

成本要從 token 組成看

這次輸入共 773,893 個 token，其中 738,432 個來自快取，35,461 個未快取。輸出 24,869 個，包含 8,033 個推理 token。

依 2026 年 10 月 27 日 Crazyrouter 公開的 DeepSeek V4 Flash 列表價，未快取輸入每百萬 0.45 美元、快取輸入每百萬 0.02 美元、輸出每百萬 1.34 美元，估算結果如下：

同一個 token 數量若套用 GPT-6.1 Sol 的公開列表價，輸入每百萬 2 美元、輸出每百萬 10 美元，約為 1.797 美元。兩個數字都只是列表價估算，不是帳單；方案、重試、快取命中與實際路由都可能改變最後金額。

這裡也別把 773,893 個輸入 token 解讀成模型很省上下文。Agent 會重讀檔案、接收工具輸出、在失敗後再取一次結果，輸入自然會膨脹。成本低是因為單價低，不是因為它神奇地把工作壓成幾百個 token。

什麼情況值得再跑一次

我會把這個組合放在失敗測試明確、diff 範圍小、可以人工複核的修復工作上。價格低讓多一次嘗試比較沒有心理負擔，Codex 的執行迴圈則讓指令結果真的回到同一個工作區。

但遇到付款、認證、資料庫遷移或正式環境變更，便宜不該縮短審查。交付錯檔的成本不會跟著模型帳單一起變小。這類工作即使也顯示 9/9，我還是會先看修改範圍、檔案雜湊、匯入來源與人工 diff，再決定能不能放行。

這次值得留下的不是「六美分很便宜」而已。更實用的是順序：先讓 agent 完成可觀察的迴圈，再用外部檢查確認交付物的身分。DeepSeek 讓這個迴圈容易負擔，Codex 讓它真的落到磁碟；最後那一分，則要由驗收流程自己拿回來。

目前 Codex 的連線設定可從 Crazyrouter 核對。