Agent 先寫測試，看見紅燈，再修改折扣計算，最後所有測試轉綠。團隊裝的 TDD skill 看來有作用。接著另一組驗收案例送入「折扣超過原價」，程式卻回傳負數。

這是本文設計的假設案例，沒有執行模型實驗。它指出兩件可以同時成立的事：Agent 遵守了流程，交付仍有缺陷。若評測只數紅綠循環完成幾次，團隊會保留一份很容易被遵循、卻未必改善結果的指令。

Sergii Makarevych 在〈How to write and test agent skills with evals〉提出一個有用的區分：adherence 衡量是否照做，effect 衡量照做之後是否帶來收益。他用 Superpowers 的 TDD skill 展開評測設計；文章沒有提供該設計已跑完的實驗結果，因此不能讀成「TDD 已被證明無效」。

本文把這個區分落到同一個修復任務：先確認技能是否進入執行，再驗證流程，最後比較交付。採用 skill 的依據，應是它解決了哪一種失敗，以及團隊願意付多少代價。

先把「測試先行」寫成一個可以失敗的假說

假設專案規則是：金額用整數分計算，折扣不得讓應付金額小於零。原始函式直接回傳原價減折扣；問題單要求修復超額折扣，並保持合法輸入的行為。開場那次失敗的修復只處理了問題單列出的數值，沒有把零下限套用到所有合法組合。

這時「請遵守 TDD」太寬。本文選出的候選規則只有一句：修改實作前，新增一個能重現這次缺陷的測試，執行並確認它因預期行為不符而失敗。

背後的假說是：這一步能減少測試根本沒碰到缺陷、卻被當成修復證據的情況。可觀測的收益應是新增測試能攔下舊錯誤，且最後修復能通過獨立驗收。測試數量增加、解說變長，都不直接算收益。

先用未載入候選 skill 的 Agent 跑一批同類問題，才能知道這種失敗是否常見。如果基線已能穩定留下有效回歸測試，再加一段強制流程可能只增加時間。反過來，若基線常把程式的錯誤輸出抄成預期值，就有值得驗證的改善目標。

這與讓 Claude 自動調 prompt 前，先驗證評分器的分工不同：那篇處理評分器與資料隔離；這裡要判斷一條具體規則該保留、改寫，還是刪除。

沒有載入，不能算成內容沒有用

評測紀錄先留一個獨立欄位：本次是否真的讀到了指定版本的 skill 本文。只看技能出現在目錄，或 Agent 說「我會使用」，都不足以確認載入。

Vercel 的 Next.js 16 評測提供了一個具體警訊：預設 skill 組有 56% 的案例沒有呼叫技能，通過率與沒有文件的基線同為 53%；加入明確呼叫指示後是 79%。這是 Vercel 在該組任務下的結果，不能推成所有 Agent 都只會載入一半的技能，也不能據此宣告 AGENTS.md 永遠優於 skills。

對折扣案例，我會把評測分成兩輪：

  • 內容輪：明確提供候選 skill，檢查這條規則被讀到後，是否改變行為與品質。
  • 路由輪：恢復平常的技能目錄與觸發方式，檢查相同類型的任務是否會選中它，以及不相干的任務是否被誤觸發。

兩輪的結果各自保留。內容輪有效、路由輪常漏載，下一步是處理發現與觸發；不需要再把同一句 TDD 規則加粗三次。正式採用的整體成功率仍須包含漏載案例，不能只挑有載入的成功執行對外報分。

遵循分數要從事件判定，效果要由另一組驗收回答

對這條測試先行規則，adherence 可以沿著時間順序查：新測試是否先被寫入？測試命令是否在第一次實作修改前執行？失敗是否來自該測試的行為斷言？

「退出碼非零」還不夠。套件沒裝好、語法錯誤、測試根本沒被發現，都可能出現紅燈，卻沒有驗證折扣缺陷。若工具紀錄缺少寫檔或執行事件，就標示無法判定，不讓 Agent 的事後敘述補成通過證據。

effect 則交給執行後的獨立檢查。以下是本文對假設案例提出的驗收方式：

  1. 把 Agent 新增的測試移回相同依賴環境的原始程式，確認它會因折扣缺陷失敗，再放到修復後版本確認通過。
  2. 執行 Agent 沒看過的驗收案例，覆蓋零折扣、折扣等於原價、折扣大於原價，以及既有合法輸入。
  3. 選少量明確的錯誤變體，例如永遠回傳零或漏掉超額折扣限制，檢查新增測試能否辨認。變體須由需求支持；不能把任何測試未攔下的改寫都算產品缺陷。

第一項證明測試對原始缺陷有辨識力，第二項檢查修復是否只針對眼前範例，第三項補看測試是否過於寬鬆。三者不必合併成一個神祕總分。保留逐案判決，reviewer 才能知道哪一種錯誤減少了。

這裡還有一個限制：部分修復會連帶改介面，使新增測試不能直接套回舊版本。那次 replay 應記為不適用或需要人工檢查，不能把編譯失敗冒充抓到 bug。本文沒有執行以上驗收，也沒有聲稱它能證明所有測試的品質。

三組配對比較，才看得見額外文字的代價

Makarevych 建議比較無技能、候選技能與等長無關文字。本文採用這個思路，但不把第三組當成完美的安慰劑：任何文字都有語意，也可能影響注意力與工具選擇。

對同一個缺陷、同一份起始提交，安排三組獨立執行：

  • 基線組不加入候選 skill，其他既有專案規則維持相同。
  • 技能組加入固定版本的候選規則，確認載入事件。
  • 長度對照組在相同位置加入與任務無關的文字，以所用模型的 tokenizer 配對 token 數，保存確切內容。

每組固定模型版本、reasoning 設定、可用工具、權限、時間與 token 預算、依賴版本和驗收器。每次從乾淨工作區與新對話開始，避免上一輪的解法、測試或快取檔案成為下一輪的提示。交錯執行組別，並對每個任務重跑，觀察波動；只增加同一題的 repeats，不能補足缺少的任務種類。

報告同時留下 hidden-check 通過情況、有效回歸測試、token、耗時與超出預算的執行。超時不能默默剔除，否則最昂貴的失敗會消失。若產品要求「品質不可退步、平均費用不得超過既有預算」，就先寫下門檻；看到結果後才放寬，會改變這次比較的意義。

Signal or Noise在 50 個 web 專案上研究 31 份公開技能，也使用了長度對照。不過論文配對的是文字 byte 長度，而非嚴格相同 token；它的功能性評測也不涵蓋視覺品質與人工 review 時間。這些限制提醒我們：引用負面結果時，要一起交代測了什麼，不能把某組功能測試的變化寫成所有開發品質的結論。

分數沒有上升時，下一步不一定是改寫 skill

回到折扣修復，可以得到幾種不同判斷。

若技能未載入，先處理路由。若已載入但測試先行常被跳過，再檢查指令是否衝突、步驟是否能在當前工具中完成，以及預算是否足夠。低 adherence 是診斷入口，並不自動證明文案寫得差。

若規則被遵循，卻沒有可辨認的效果，就逐案檢查：基線是否本來已經會做？選的任務是否沒有這類失敗？驗收是否漏掉了要改善的品質？樣本是否太少？排除這些問題後，才有理由刪除或縮短候選規則。若只是小樣本中分數相同，結論應是尚未觀察到收益，不能直接宣告背後的方法無效。

若技能優於基線，卻沒有優於長度對照，則目前還無法把收益歸到這條指令的內容。可換一份對照文字，或移除單一規則做消融比較；每次都保留原本的驗收方式。

也不必預設結果一定負面。SkillsBench v4在其 87 項任務、18 種 model-harness 組合中，報告 curated skills 讓平均成功率從 33.9% 提升到 50.5%。這表示適合任務的技能可以有收益；它沒有替任何下載下來的 TDD skill 保證效果。

採用規則：只有在指定環境與任務中，觀察到足以支持決策的收益，且品質與成本限制都成立，才把候選技能升為預設。 不確定性仍大時，保留為小範圍試用，並寫明下一次需要補什麼證據。

技能發版時，一起保存讓它留下來的理由

採用紀錄不用很華麗，但應能回答：哪份 skill、哪個模型與 harness、哪些任務、對照是什麼、哪種失敗減少了、成本增加多少。模型、技能、工具或既有規則變更後，這份紀錄也提供重跑的起點。

開始可以很小：選一條最近反覆出錯的行為，把它改寫成可檢查的規則，拿相同起點比較有無規則的修復，再加長度對照確認收益是否穩得住。對折扣案例，第一個該留下的成果是「測試確實能抓到舊錯誤，修復能過獨立案例」的紀錄，而非又一份要求 Agent 更認真做 TDD 的長文件。

來源與查核範圍

以上於 2026-10-20 查核。折扣案例、驗收步驟與採用規則為本文的工程建議；本文未安裝技能、呼叫付費模型或重現上述研究。