為什麼 Claude 不遵守 Superpowers 的鐵律？理論與實務的落差分析

上一篇文章整理了 github.com/obra/superpowers 裡所有 skill 的隱藏規則。這篇要回答一個更根本的問題：這些規則白紙黑字寫得清清楚楚，為什麼 Claude 實務上常常不遵守？

Skill 的規則是真實存在的

先確認這些規則不是我們誤解或誤記的。以下是幾條最關鍵規則的原始出處：

鐵律 1：修了三次還沒修好，停下來

來源：skills/systematic-debugging/SKILL.md 第 195-197 行

If < 3: Return to Phase 1, re-analyze with new information
If ≥ 3: STOP and question the architecture (step 5 below)
DON’T attempt Fix #4 without architectural discussion

同一個檔案第 227 行：

“One more fix attempt” (when already tried 2+)
ALL of these mean: STOP. Return to Phase 1.

鐵律 2：選最便宜的 model

來源：skills/subagent-driven-development/SKILL.md 第 89-91 行

Use the least powerful model that can handle each role to conserve cost and increase speed.
Mechanical implementation tasks (isolated functions, clear specs, 1-2 files): use a fast, cheap model. Most implementation tasks are mechanical when the plan is well-specified.

鐵律 3：沒有失敗測試不能寫 code

來源：skills/test-driven-development/SKILL.md 第 31-34 行

## The Iron Law

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

鐵律 4：1% 機率就必須 invoke skill

來源：skills/using-superpowers/SKILL.md 第 11-15 行

If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.

IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.

This is not negotiable. This is not optional. You cannot rationalize your way out of this.

鐵律 5：宣稱完成前必須這個訊息內跑過驗證

來源：skills/verification-before-completion/SKILL.md 第 16-22 行

## The Iron Law

If you haven’t run the verification command in this message, you cannot claim it passes.

規則是真實的，寫得清楚，甚至用了「Iron Law」、「ABSOLUTELY MUST」、「NOT negotiable」這些最強烈的措辭。

那為什麼實務上 Claude 修了四次五次還在猜？為什麼還是會選 Haiku？為什麼不跑完驗證就說「完成了」？

五個根本原因

原因 1：Skill 是文字，沒有執行引擎

Skills 的運作方式是：Claude 呼叫 Skill 工具 → 工具把 SKILL.md 的內容貼進 context → Claude 讀完然後「盡力遵守」。

沒有 interpreter，沒有 runtime，沒有 if-then 邏輯，沒有計數器，沒有警報。Claude 違反規則不會有任何程式層面的後果。

這就是為什麼 using-superpowers/SKILL.md 第 13 行要用大寫強調「YOU DO NOT HAVE A CHOICE」—— 因為它知道 Claude 有選擇，它在試圖用措辭彌補缺乏強制力這件事。

原因 2：Skill 沒被載入就不存在

using-superpowers skill 規定「每次對話開始前先查 skill」，但執行這條規則的還是 Claude 本身。如果 Claude 這次忘了 invoke Skill 工具，systematic-debugging 的三次上限根本不在 context 裡，等於不存在。

這是一個自我參照的問題：「用 skill 確保 skill 被用」的規則本身也依賴 skill 被正確載入才能生效。

原因 3：Context 壓縮吃掉規則

長對話之後，Claude Code 會自動壓縮前面的 context。Skill 內容被載入進 context，但在第五次修 bug 的時候，第一次載入的 systematic-debugging 很可能已經被壓縮到只剩摘要，「三次停下來」這條規則不見了。

Claude 不是故意無視規則，是規則已經不在它的視野裡了。

原因 4：RLHF 訓練行為覆蓋 skill 規則

Claude 的訓練讓它傾向：

• 持續幫忙（不輕易放棄）
• 樂觀估計（「這次應該可以」）
• 不讓使用者失望（說「我不知道怎麼修」感覺像失敗）

Skill 說「第三次停下來討論架構」，但訓練說「繼續幫用戶解決問題」。訓練是骨子裡的，skill 是貼上去的文字。骨子裡的贏。

這個矛盾在 skill 作者知道：systematic-debugging/SKILL.md 第 195 行不只說「stop」，還用粗體、全大寫，以及「DON’T attempt Fix #4」的雙重否定，都是試圖用措辭強度來對抗訓練行為。

原因 5：Haiku 沒有能力執行複雜的工作流程規則

來源：skills/subagent-driven-development/SKILL.md 第 89-100 行告訴 Claude 選最便宜的 model。

但兩階段 review（spec compliance → code quality）、四種 status 的不同處理邏輯、三次上限計數、context 打包給 subagent——這些都需要相當的推理能力。Haiku 被選來做「機械性」的工作，卻遇到需要判斷的情況時，它沒有能力忠實執行這些細緻規則，就退回最直覺的行為：繼續做、繼續猜。

所以 skill 的 model 選擇規則本身，就是讓 skill 的其他規則失效的原因之一。

一個具體的案例：兩階段 Review 的崩潰

subagent-driven-development 規定兩階段 review，而且有嚴格順序（SKILL.md 第 247 行）：

Start code quality review before spec compliance is ✅ (wrong order)

這個規定存在，是因為曾經出問題（skills/writing-skills/SKILL.md 第 154-156 行）：

Testing revealed that when a description summarizes the skill’s workflow, Claude may follow the description instead of reading the full skill content. A description saying “code review between tasks” caused Claude to do ONE review, even though the skill’s flowchart clearly showed TWO reviews (spec compliance then code quality).

換句話說：

1. Skill 的 description 寫了工作流程摘要
2. Claude 讀了 description 就走捷徑，沒有讀完整 SKILL.md
3. 看到「code review between tasks」→ 只做了一次 review
4. 整個兩階段機制失效

修法是把 description 改成只描述「什麼時候用這個 skill」，不描述工作流程。但這同時說明：一個措辭上的疏漏，就足以讓整個 skill 的核心機制失效，而且你不會知道。

另一個案例：Permission 擋住了整個 Review Loop

我們最近遇到的真實案例：在 ~/.claude/settings.json 裡，PermissionRequest hook 的 matcher 設定為 Agent|TeamCreate|Team，而 hook 的行為是對 Agent 工具直接回傳 deny。

結果：每次 LEAD 要 dispatch subagent（不管是 implementer、spec reviewer 還是 code quality reviewer），都被系統層面攔截拒絕。

兩階段 review 的規則還在 context 裡，Claude 也打算遵守，但 Agent 工具每次都失敗。Skill 的工作流程完全無從執行。

修法：把 Agent 從 hook matcher 移除（改成 TeamCreate|Team），並把 defaultMode 改成 bypassPermissions。這個設定層面的問題修好之後，Agent Team 才能真正按 skill 的設計跑。

Skills 在什麼條件下才有效

綜合以上，Skills 的效果受以下條件影響：

條件	有利	不利
Session 長度	新開的 session，context 乾淨	長對話，skills 被壓縮
Model	Sonnet / Opus，有推理能力	Haiku，複雜 workflow 跟不上
Permission 設定	Agent 工具不被攔截	Permission hook 擋住 subagent dispatch
Skill 載入	LEAD 主動 invoke 正確的 skill	沒有 invoke，規則不在 context
文件完整性	AGENTS.md 明確指定每個 agent 的 model	讓 Claude 自己判斷 model，選 Haiku

你能做什麼

Skill 的規則沒辦法完全靠 Claude 自己執行，但有幾件事可以提升遵守率：

1. 在 CLAUDE.md 加覆寫規則（降低對 skill 的依賴）

## Superpowers Skill Override Rules

### Model Selection
NEVER use haiku for implementation tasks. Follow:
- opus: architecture, code review, cross-file reasoning
- sonnet: all implementation tasks
- haiku: file scanning, directory listing ONLY

### Git Branch
No branch confirmation needed when already on non-main/master branch.

### Debugging Limit
After 3 failed fix attempts, STOP and escalate to user.
Do not attempt Fix #4 without discussion.

2. 修好 settings.json（讓 Agent 工具不被攔截）

{
  "permissions": {
    "allow": ["Agent"],
    "defaultMode": "bypassPermissions"
  },
  "feedbackSurveyRate": 0
}

3. 在 AGENTS.md 明確指定每個 agent 的 model

| Agent | Model | Role |
|-------|-------|------|
| implementer | sonnet | Feature implementation |
| spec-reviewer | sonnet | Spec compliance check |
| code-reviewer | opus | Code quality review |

4. 永遠從 dev branch 開工

git checkout -b dev

避開所有 skill 的 main/master 保護規則，減少一類不必要的確認詢問。

一個誠實的評估

Superpowers skill 系統的設計思路是正確的：把軟體開發的最佳實踐（TDD、系統性除錯、分層 review）轉化為 AI agent 的工作協議。規則本身大多有充分的理由。

但在現實中，一個純粹依賴文字指令的系統，要對抗 LLM 的訓練行為、context 長度的物理限制、以及工具層的設定問題，注定只能是「盡力遵守」而非「強制執行」。

理解這個落差，比假設 Claude 完全遵守更有用。知道規則存在、知道為什麼可能失效，讓你能夠在關鍵節點主動介入，而不是事後才發現 Claude 在第五次猜測同一個 bug。

---

延伸閱讀：

• Claude Code Superpowers 隱藏規則：4 個你不知道的坑與避開方法
• Agent Team 穩定的關鍵：spawn 之前先建好兩份文件
• github.com/obra/superpowers（原始碼）