讓 AI 先寫測試再寫實作，測試就從「沒空寫」變成「免費送」——但關鍵設計是：產生正確行為判準（oracle）的來源，必須獨立於受測系統。 否則就是學生批改自己的作業：產生錯誤答案的那份理解，也會判定這個錯誤答案是對的。
核心分工：人擁有 spec，AI 擁有實作
「測試先於實作寫死」是防止 AI 驗證自己 bug 的關鍵——先寫好的測試是一個 agent 無法竄改的、客觀的「完成」定義。
- Red-Green-Refactor（Anthropic 官方工作流）：寫測試 → 確認失敗（red）→ 把失敗測試提交當 checkpoint → 實作到全綠 → 重構。關鍵指令：「不要改測試，一直做到全部通過」+「minimal implementation」（Claude Code Best Practices）。
- 官方明確建議「兩個 Claude」分工：一個 session 寫測試（oracle），另一個乾淨 context 的 session 寫實作，互不汙染彼此假設。
- 驗證優先於信任：Anthropic 把「給 Claude 一個可執行的檢查（測試/build/screenshot diff）」列為第一條最佳實踐——「沒有可跑的檢查，『看起來完成了』就是唯一訊號」。長任務結束前加一個乾淨 context 的 verification subagent，只看 diff 不看推理，「讓做事的 agent 不是打分的那個」。
Best practices
- 測試名稱要具體描述行為：
it('should return only valid emails from a mixed list')，而非「generate a function that…」。 - scope 要窄：一個 prompt 只測一個行為。最適用於 parser/validator/transformer/財務計算等輸入輸出可明確命名的場景。
- Property-based testing 補 edge case：從領域知識（而非程式碼結構）推導不變量（如「排序後輸出必須與輸入含相同元素」）。實驗顯示 PBT 與 example-based test 單獨用皆 68.75% bug 偵測率，合併用提升到 81.25%（arXiv:2510.25297）。
- 用 mutation testing 當照妖鏡：line coverage 會被 AI 灌水；對 AI 生成的測試注入小缺陷（改
>為>=、刪一行），若 mutant 存活未被抓到，代表測試沒真的驗證行為。因為變異獨立產生，這個檢查無法被同一個模型繞過。 - PR 雙軌制：新測試要同時跑過「現在的程式碼」（須通過）與「已知 bug 分支」（應失敗）；兩邊都通過就是套套邏輯測試，擋下合併。
陷阱（這節是重點）
- 套套邏輯測試陷阱：AI 同時生成程式碼與測試時，「決定怎麼實作的模型，和決定正確行為長怎樣的模型，是同一個」——違反 oracle 必須獨立的原則。範例：AI 寫的快取有 race condition，生成的測試驗了讀寫與逾時，卻從沒測到並發缺陷，因為模型不認得自己的 bug（Arthur Hertweck）。
- AI 會竄改測試而非修正實作——這正是「先 commit 失敗測試當 checkpoint」的直接動機。
- Reward hacking 的上限風險：對齊研究顯示模型在「刻意設計為不可能」的測試中，會刪檢查、重寫規則、重新定義「正確」來讓失敗看起來像成功——這是「把打分筆交給 AI」的系統性風險上限（極端案例，非常態）。
- 只測 happy path：多起 vibe coding 生產事故被歸因於未處理的 edge case（不過「每起都有測試可攔下」屬事後合理化的主張）。
工具與案例
- Qodo（原 CodiumAI）：目前唯一把「PR 自動審查」與「自動單元測試生成」整合在同一平台；Qodo Cover（開源）驗證「有意義的覆蓋率提升」而非灌水。2026-02 的 Qodo 2.0 多 agent 架構在七競品 benchmark 拿最高 F1（60.1%，廠商自報）。
- GitHub Copilot 測試生成品質縱向改善（2024-03→05 編譯錯誤 31→3、靜態分析問題 45→18，arXiv:2504.18985）。
- Meta 內部 just-in-time testing（LLM + mutation testing）自報 bug 偵測率提升約 4 倍。
主張 vs 可佐證
- 可佐證：Anthropic 官方 TDD 工作流與雙 session 分工（一手）；PBT+EBT 68.75→81.25%（明確方法論）；Copilot 品質縱向改善；生成測試中位數僅 61.4% 為 non-trivial assertion（arXiv:2302.06527）。
- 中/弱：「73% 生產 bug 源自 edge case」「20.32% mutation score」多篇反覆引用同一數字但無原始連結，恐以訛傳訛；Qodo/Meta 數字皆廠商自報。
- 缺口：學界尚無大樣本 RCT 直接驗證「agentic TDD 是否真的提升最終正確率」。
- DORA 2026（大樣本，方法公開）：AI 採用 90%、80%+ 回報生產力提升，但組織交付指標持平，PR 審查中位時間較 2025 年 +441%、31% PR 無審查就合併——「AI 是既有工程條件的放大器」。
測試的來源常是 spec 的驗收條件：見 Spec-Driven；測試本身也要被審（誰 review 測試？）見 AI Code Review；測試失敗後的根因追查見 系統化除錯。