Simon Willison 回顧今年的 LLM 發展時提到，2025 年 11 月前後，新模型配上 coding agent 的 harness，可靠性像是跨過了日常使用的門檻。這個判斷我蠻有感，最近在日本這邊跟同事聊 AI 導入，大家現在問得更細了：「能不能讓它每天跑，跑壞時找不找得到原因」。

我在遊戲專案裡的經驗是，agent 偶爾成功其實很容易製造錯覺。它可以很快幫你補 NPC 對話測試，也可以把一個小型工具從 0 寫到能動。但真正麻煩的是那些低頻、跨系統的錯誤：存檔載入後 NPC 狀態重置、日文長句讓 UI 超出框、玩家重試三次後事件重複觸發。這些問題單看一次生成結果，很難看出來。

所以我現在會先做一份 failure matrix，故意把任務推到壞掉的位置。以 NPC 對話功能為例，我會固定 20 組測試情境，包含空字串、超過 120 字的日文、玩家中途斷線、同一事件連續觸發，以及模型回傳不合法 JSON。每個情境讓 agent 從 issue、log 到修正完整跑 3 次，記錄四個數字：一次通過率、需要人工介入的次數、修正後引入的新錯誤數、以及從失敗到可合併的分鐘數。

最簡單的測試甚至只要一段：

請連續執行 tests/npc_dialogue_cases.json 3 輪。不要跳過失敗案例。每輪輸出 case id、錯誤類型、你修改的檔案，最後列出三輪都失敗的案例。

我會把 agent A 的第一次成功率，和 agent B 的「第三輪仍然不壞」比例分開看。前者是 demo 指標，後者才比較接近日常可靠。上個月一個小工具的結果很典型：第一次 20 案過了 17 案，看起來有 85%；連跑三輪後只有 11 案每輪都過，穩定率是 55%。再加上刻意改壞的輸入，兩者差距更明顯。

在日本這邊，很多團隊導入工具時會先做小範圍 pilot，這種慢一點的節奏其實適合 agent。把「可以幫我做功能」改寫成「在 50 個已知案例和 10 個未知案例裡，連續三輪維持多少成功率」，才有辦法比較版本，也才知道哪種任務該交給它。

我的觀察是，coding agent 跨過可用門檻後，接下來最有價值的工作是替它設計更容易失敗的考場。測完要留下 failure log 和重現指令，隔週換模型或換 harness 再跑一次。能說清楚它在哪裡壞、壞了之後多久能救回來，才算真的進入日常。