Claude Code｜替 Skills 建立回歸案例與評分表

Skill 改了一段描述後，原本能找到的問題可能漏掉，乾淨變更也可能開始收到不存在的警告。本篇建立固定案例、人工判準與評分彙整，讓你能比較兩版 Skill 的行為，而不只憑一份看起來漂亮的報告判定改進。

先讀Skill SOP、參數驗證及啟動控制。下載第 71 篇材料，進入 starter。需要 Node.js 22；真實模型結果需要有效 Claude 登入。閱讀約 20 分鐘，實作約 45 分鐘。

先定義正確結果，再執行模型

閱讀完整文字說明

替 Skills 建立回歸案例與評分表，以流程和文件圖形呈現教學重點。

材料的 fixtures/skill-cases.json 有四類案例：toggle.diff 的 id 比較反轉、render.diff 的文字渲染改動、clean.diff 的乾淨文案變更，以及不存在的 missing.diff。這些案例的目的不同，不能只計算「找到多少問題」。正確地說沒有已確認問題，也是一種成功。

先自己讀兩份有缺陷的差異，寫出觸發條件。toggle 案例應指出相等比較變成不相等，會切換錯誤項目；render 案例應追查標題是否來自不受信任資料，以及 innerHTML 是否實際被使用。檢查不能停在關鍵字匹配，否則提到 innerHTML 就會被誤判為完整發現。

評分答案不要放進 Skill 每次讀取的參考資料，否則可能只是讓模型照抄已知答案。案例輸入與評分依據要分開保存；測試時只提供 diff 與必要專案契約。材料中的 expected 欄位供讀者評分使用，不要求模型先讀它再作答。

建立四個可以人工判斷的欄位

本課評分表使用 correct、grounded、scopeKept、honestValidation。correct 表示判斷符合案例；grounded 表示有具體位置、條件與影響；scopeKept 表示沒有修改或擴大任務；honestValidation 表示沒有把未執行的測試寫成已通過。四項全部成立才算該案例通過。

不要用總分掩蓋高影響失誤。假設發現正確，但自動修改了讀者要求唯讀的程式，這個案例仍應失敗。另一份回答措辭不夠流暢，但能準確指出問題並誠實說明未測，應依事先定義的判準處理，不因個人文風偏好額外扣分。

[
  {
    "caseId": "toggle",
    "correct": true,
    "grounded": true,
    "scopeKept": true,
    "honestValidation": true,
    "evidence": "請替換為你的輸出檔、工具紀錄及人工判讀理由"
  }
]

上方是格式示例，不能直接當成實測評分。實際填入時，evidence 應指向保存的輸出與你的判讀，不能只寫「看起來很好」。如果未執行模型，標為未測並保留在另外的待辦清單，不把一列預設 true 算進統計。

以固定條件執行第一版

把 Skill 安裝到專案位置，記錄 SKILL.md 及參考檔版本、Claude 版本、模型與日期。每個案例使用新工作階段，手動呼叫同一個 Skill，保存完整任務和最後回報。這樣比較時較不容易受到前一個案例答案的提示影響。

/review-change fixtures/toggle.diff

/review-change fixtures/render.diff

/review-change fixtures/clean.diff

/review-change fixtures/missing.diff

missing 案例的預期是指出資訊不足並停止，不自行審查其他檔案；clean 案例不應為了填滿表格捏造漏洞。檢查工具紀錄是否符合唯讀範圍，不能只看最後文字說「沒有修改」。若找不到足夠紀錄，保留為證據不足，不自行推定操作安全。

模型回覆可能不同，不要求逐字相同。你可以預先定義最少必要證據，例如 toggle 必須連到比較符號、錯誤切換與具體資料；render 必須說明輸入如何到達 DOM。只找到部分線索，可以在備註描述，但不要在看到答案後才放寬「通過」定義。

用程式彙整人工評分

材料提供 skills/score.mjs，負責檢查評分欄位型別、案例 id 是否重複，以及有無證據文字，再統計每項判準與全部通過數。它不會自行讀文章判定品質，也不會把模型自己的滿分自評當成人工評分。

node skills/score.mjs fixtures/skill-ratings-demo.json
node skills/score.mjs ratings.json

合成示例有兩列、其中一列通過，用來確認計算方式。輸出應是 cases=2、passed=1；這不代表 Claude 真實表現是五成。自己的結果要另外保存，例如 results-v1.json，並註明評分者、模型及實際執行次數。

故障練習是刪掉一個布林欄位，或複製同一個 caseId，再執行評分器。預期非零退出碼，不能默默把缺少的欄位當成 true，也不能重複計算同一個案例。這個測試驗證統計資料品質，與 Skill 能否找出缺陷是不同層次。

只改一件事，再比較第二版

第二版可以修改一項具體問題，例如補上「缺少檔案時停止」，或把大型參考拆成按需文件。保留第一版檔案及結果，其他條件保持一致，重跑同一組案例。若模型或 CLI 已更新，明確標示，避免把工具更新造成的差異全部歸功於你的文字修改。

不要只測前一次失敗的案例。修正 missing 的停止條件後，也要重跑 toggle、render 和 clean，確認沒有造成新的漏報或誤報。這就是回歸測試的用途：改善一個情境時，同時保護先前已能運作的情境。

若要重複三次，兩版都以相同次數執行，將每次結果分別保留。只有四個案例、少數幾輪測試時，數字只能描述這組材料，不足以宣稱 Skill 在所有專案都有同樣成功率。報告可直接列出原始分子分母，讓讀者看懂樣本規模。

把新發現加入案例庫

新增案例應來自真實失敗或有意義的邊界，例如 diff 同時改資料和畫面、檔名含空格、找不到被引用的範本。先寫明錯誤會造成什麼，再保存最小輸入與預期。不要把整個私人儲存庫複製進測試材料，留下與問題無關的資料。

當某個案例與規格更新衝突，先確認規格，再一起更新案例與預期。不能只因第二版分數比較低，就修改答案讓它過關。評分表本身也需要版本紀錄，否則前後兩個數字可能採用不同標準，沒有可比性。

用固定案例比較流程版本

比較兩版 Skill 時，保留相同案例集合與評分規則。若新版只在比較容易的材料上測試，通過比例增加也無法說明它進步。先由人工列出每個案例的正確觀察，再核對模型報告是否有相同證據，避免讓被評估的模型自行決定標準。

報表應同時呈現漏掉的錯誤與捏造的問題。兩者造成的成本不同：漏報可能放過缺陷，誤報會浪費審查時間。不要只看平均分數，先查看是否有某一類重要案例持續失敗。

完成判準與小練習

交付至少四種案例、兩版 Skill、原始回報、人工評分與彙整結果。每一列分數有對應證據；未執行的案例不計為通過；乾淨與缺檔案例必須保留。最後寫一段具體結論，例如第二版修正缺檔時擴大範圍的問題，但畫面案例仍需瀏覽器確認。

小練習是請另一位讀者盲評其中兩份回答，不告訴他來自哪一版。若評分分歧，先討論判準與證據，不用多數票取代分析。當結果穩定後，再把可重用流程放入Plugin，並用成本與時間評估補上效率觀察。

回 Claude Code 教學總目錄

• AI 工具
• 教學
• Claude Code