編碼代理評測
26 種測試提示未能穩定改善編碼代理，更多測試不等於較高正確率
一項 Zstandard 實作實驗比較 TDD、模糊測試、性質測試與形式驗證等 26 種條件，沒有方法穩定勝過不加指示的預設組。代理常正確辨認高風險區域，卻生成無效輸入、證明無關性質或把錯誤結果寫進測試。
工程師 Dan Luu 公開一組編碼代理測試實驗：要求代理以 Rust 實作 Zstandard，並分別追加 TDD、QuickCheck、Proptest、模糊測試、差分測試、變異測試，以及 Lean 4、Kani、TLA+、Verus 等 26 種提示條件；另保留完全不指定驗證方法的預設組，並比較 medium 與 xhigh 推理強度。每個主要條件包含大量重複執行，避免把單次成功當成方法效果。
結果不是「形式方法無效」，而是代理通常不會有效使用指定工具。QuickCheck 執行中，63／160 次只檢查一項性質；模糊測試多半餵入完全隨機位元組，反覆走相同的無效輸入拒絕路徑。代理只有 10／160 次產生具結構的隨機輸入，其中一半確實找到錯誤，顯示瓶頸更接近測試資料生成策略，而非工具本身。使用 Lean、Verus 等方法時，代理常證明與實作風險無關的性質，最後仍依賴普通 Rust 單元測試。
TDD 讓代理寫出約兩倍測試，卻沒有提高正確率；明確要求使用 Rust 內建測試框架也出現類似情況。常見失敗包括忽略最脆弱行為、用目前程式輸出反向製作「正確答案」，以及選到迴文輸入，令位元序反轉錯誤剛好通過。預設組反而高於平均，但各組差距不足以支持精確排名。
這對代理工作流的含意是：`請多測試`、`使用 TDD` 或掛上一份教學型 skill，不能替代測試設計。較可靠的做法是由人或獨立規格先定義 oracle、合法輸入生成器、覆蓋目標及故障注入，再讓代理擴充案例。研究仍只涵蓋 Rust、壓縮格式與少量其他任務，且不是同儕審查論文；下一步需要跨模型、語言、倉庫級任務及預先註冊的統計比較。