我在 Claude Code 裡裝了不少 Skill，但老實說，裝的時候很少真的驗證過它有沒有用——大多是看到別人推薦、讀起來合理，就裝上去了。這 30 天，我想把這個習慣倒過來：用同一套評分尺，把我真的在用的 Skill 一個一個拿出來實測，記錄它會不會被叫到、跑出來的結果對不對、什麼情況會失敗、多花多少成本，最後決定留下、修改還是刪掉。到第 30 天，這些結果會收成一份自己能查的選用指南——不是 30 篇各自獨立的心得，而是同一套方法論跑 30 次的累積結果。

今天的問題

第一篇不測新 Skill，先把方法立起來。9/12 我用 Claude Code 剛推出的 claude plugin eval 功能，實測了自己平常真的在用的 Atomic Commit Skill——這個 Skill 平常負責判斷 commit 要怎麼拆、什麼時候不該 commit。跑完之後我發現一件事：「任務做對」跟「Skill 有被叫到」根本是兩個獨立的問題，不能只看任務結果就說 Skill 有沒有用。這個判斷會是接下來 30 天的核心方法。

技能卡

• 名稱：Atomic Commit
• 版本：1.0.0
• 來源：我自己維護的 Skill，非官方套件
• 觸發條件：description 裡列出的字詞包含「commit」「save progress」「atomic commit」「git commit」，或改動超過 5 個檔案時
• 用途：判斷 commit 粒度（照 Task 還是照 Feature）、產生對應的 commit message
• 已知限制：原文附帶一份特定專案的 scope 對照表，和「禁止中文 commit message」這條規則；這次三個案例都要求英文訊息，沒有測到規則衝突，不能說它跨專案都適用
• 這次證據狀態：9/12 正式跑過一次，18 次觀察；還沒測過真實工作情境裡的規則衝突

拆解

真正會影響這次測試結果的，是三條規則：

1. 判斷 commit 時機：SKILL.md 裡有明確的判斷邏輯——單一 Task 相關就照 Task 拆、混合變更就分拆、測試沒過就先不 commit。
2. 粒度決策：比對「是不是同一模組」「邏輯是否相關」，決定要不要合併成一個 commit。
3. 禁止清單：混合不相關的變更在同一個 commit、測試失敗時 commit，都在明文禁止之列——這條剛好是我第三個案例要測的。

實測

用 Claude Code 9/12 剛推出的 claude plugin eval，一次跑同一題的「有載入 Skill」和「沒載入」兩組，預設各跑 3 次。

• 環境：Claude Code 2.1.269，2026-09-12 21:22:43（台灣時間）開始，243 秒完成
• 規模：3 個合成 Git 任務 × 有／無 Skill × 每組 3 次 ＝ 共 18 次
• 三個任務：
  1. scope——功能修正跟測試要合成一個 commit，無關的筆記檔不能被提交
  2. split——書籤修正和文件更新都做完了，但要拆成兩個 commit
  3. failing——測試會失敗，正確動作是不 commit、不改檔
• 驗收方式：不在受測 repo 裡跑 Git，改用 Node.js 直接解析 zlib 壓縮的 Git object（commit、tree、blob、HEAD、index），另外比對工作區檔案，避免驗收工具本身影響受測環境

結果

三個任務、兩組、共 18 次，全數做對。有 Skill 跟沒有 Skill 的任務成功率完全一樣，差異是 0。

但另一個數字比較有意思——有載入 Skill 的 9 次裡，Atomic Commit Skill 真正被叫到的只有 5 次：

• scope：2／3
• split：3／3
• failing：0／3

跟做

這是這次實測裡兩筆真實的評分紀錄（都來自 scope 任務、有載入 Skill 那組），已去識別、保留原始判準：

紀錄 A

commit-called: passed (Bash called 1x, expected 1..∞)
skill-fired:   passed (Skill called 1x, expected 1..∞)

紀錄 B

commit-called: passed (Bash called 1x, expected 1..∞)
skill-fired:   failed (Skill called 0x, expected 1..∞)

在往下讀之前，先自己判斷：這兩次任務，哪一次算「做對」？哪一次代表 Skill「被叫到」？兩者是同一件事嗎？

答案：兩次都算「做對」——commit-called 都是 passed，任務該做的事都完成了。差別只在 skill-fired：紀錄 A 的 Skill 真的被呼叫了一次；紀錄 B 完全沒被呼叫，模型自己就把任務做對了。這就是「今天的問題」提到的核心判斷——任務結果不能單獨拿來證明 Skill 有沒有用，因為模型不靠 Skill 也可能做對。

判斷

這三個條件說明完整、範圍很小的 Git 情境，沒有測出 Atomic Commit Skill 讓結果變得更好。這不代表它普遍沒用，也不代表可以直接套用到其他專案的規則衝突情境——這次三個任務都沒有踩到中文訊息或跨專案 scope 這類會讓規則產生衝突的情況。

值得留意的是 failing 案例：9 次裡 Skill 一次都沒被叫到（0／3），但任務照樣做對。如果這個 Skill 的定位本來就包含「判斷該不該 commit」，那 failing 案例的零觸發本身就是下一輪該測的題目，不能直接放過。