作者：Yuta Tu & ALICE
日期：2026-07-03
狀態：研究室文章
用途：探討 skill 設計中「規則位址錯誤導致失效」的問題與解法
我們花了很長時間才學會一件事：寫給 AI agent 的 skill，和寫給人看的文件，是完全不同的東西。
問題不在於寫了什麼規則。問題在於規則放在哪裡。
一個真實的教訓
我們有一個叫 vlm-analyze 的 skill。它定義了 VLM（視覺語言模型）使用時的「sensor/brain split」原則：
- VLM 只能描述畫面（sensor），不能推理（brain）
- VLM 的輸出禁止出現「是」「為」「判斷」「辨識」等推理詞
- 推理任務必須由 LLM 來做
這條規則寫在 skill 的「Prompt 設計原則」區，清楚、完整、措辭強烈。
然後呢？
它從來沒被執行過。
不是一兩次。是每一次。VLM 的輸出不斷出現推理詞，LLM 直接拿推理結果當答案，沒有 Second-Pass Gate，沒有候選枚舉，什麼都沒有。
為什麼？
因為 AI agent 在執行一個 skill 時，只會掃描 Procedure（步驟） 區的數字列表。它不會讀「原則」區。它不會讀「注意事項」區。它不會讀你在 skillful 文字裡藏的深意。
對 agent 來說，不在 Procedure 步驟中的規則 = 不存在。
文件結構的陷阱
大多數 skill 遵循常見的模板結構，長這樣：
## When to Use（觸發條件）
## Principles（設計原則） ← 你把強制規則寫在這裡
## Procedure（執行步驟） ← agent 只讀這裡
## Pitfalls（注意事項）
## Verification（驗證方法）
這個結構看起來很合理。寫給人看的文件就是這樣：先給背景、再給原則、最後給步驟。Anthropic 的官方 Agent Skills 規範[9] 也建議用「清晰步驟」和「checklist」來組織工作流——但官方文件沒有特別警告：如果你把強制規則放在非 Procedure 區，agent 會完美地忽略它。
這是我們從實戰中發現的。agent 的執行邏輯是：
- 掃描 Procedure 步驟列表
- 逐一執行
- 回傳結果
它就這樣。它不會說「等一下，我記得 Principles 區有說 VLM 不能推理，讓我檢查一下我有沒有違反那條規則。」它甚至不會讀那區——因為 skill 的觸發層只把 Procedure 區當作可執行指令，非 Procedure 區被歸類為「參考資訊」。
如果你在 Principles 區寫了一條必死規則（「VLM 禁止推理判斷」），它會被完美地忽略。
這個問題不是 Anthropic 規範的漏洞——規範給了彈性，讓設計者自行組織。但正是這份彈性，讓初學者（包含我們自己）踩進相同的陷阱：用寫文件的心態寫 skill，以為所有文字都會被「讀懂」。agent 不是這樣讀的。
同一條規則，放在「設計原則」區等於不存在，放在「步驟 0」才會被執行。
為什麼不是 agent 的問題
我們習慣把這種事歸咎於「AI 不聽話」。但 Sidney Dekker 教過我們：不要問為什麼這個人沒看到，要問什麼環境或設計導致了這個盲區。
agent 的「盲區」不是 bug。它的設計本來就是：Procedure 步驟 = 可執行指令，非 Procedure 區 = 參考資訊。這是合理的架構選擇。
真正的問題是 skill 的設計者（人類或另一個 AI）用寫文件的心態寫 skill，以為所有文字都會被「讀懂」，卻不知道 agent 只會執行步驟列表中出現的內容。
這不是 agent 的錯。這是文件結構語意與執行語意之間的 gap。
三層解法
第一層：規則位址校正
最簡單的改變：把強制規則從「原則區」搬到「步驟區」。
不是「提到步驟區」，而是寫進步驟列表的某一個數字。
改前（v6）：
## Prompt 設計原則
- VLM 只看不判斷（sensor/brain split）
- 禁止出現推理詞（是/為/判斷/辨識）
## Procedure
1. 讀圖片
2. 調用 VLM 分析
3. 回傳結果
改後（v7）：
## Procedure
0. sensor/brain split（強制）：
a. VLM prompt 必須以「角色：」開頭
b. VLM 只描述，禁止推理（禁用詞：是/為/判斷/辨識/結論）
c. VLM 回傳後，LLM 執行 Second-Pass Gate：
- 列出 ≥3 個候選解釋
- 找出差異
- 逐一排除
- 留下一個
1. 讀圖片
2. 調用 VLM 分析
3. 回傳結果
同樣的規則，從「背景資訊」變成「步驟列表中的第 0 步」。這次 agent 會執行。
人工 → 自動化 → 自我進化：規則從人的記憶，變成系統的器官。
第二層：結構強制檢查
光靠自覺不夠。我們需要一個機制來保證這件事。
我們寫了一個 skill-gate.js 工具，它會：
- 解析 skill 的 Procedure 步驟列表
- 掃描 skill 中所有「強制關鍵詞」（必須、禁止、不可、紅線、強制）
- 檢查每個關鍵詞是否至少出現在一個 Procedure 步驟中
- 如果不在 → 報錯，skill 不通過驗證
這不是靠人自覺，是靠工具強制。規則從文件進入機制，才真正開始存在。
第三層：裁決庫（RCA Rulings）
每次出問題後，我們不只修 bug——我們寫一條裁決（ruling）。
例如：
pattern: "Procedure checklist omitted — skill defines output format but not in its own steps"
root_cause: "天條寫在 persona，不在 procedure skill 步驟本身。meta-skill-design 教訓再現"
decision: "補步驟 10：強制輸出清單。漏清單 = 漏步驟 = 從 0 重來"
下次 agent 在執行 RCA 診斷時，如果看到相同的 pattern（「步驟被跳過」），裁決庫會直接命中這條 ruling，回傳「這是已知問題，解法是補步驟到 Procedure」。
不再靠記憶。不再靠自信。靠機制。
為什麼過去的方法都不管用
寫在 prompt 裡： prompt 會變長，會被壓縮，會被另一個 model 重新詮釋。沒有強制性。
寫在 memory 裡： memory 不是執行指令。它是在需要時查詢的——但 agent 在執行 skill 時不會「順便查一下 memory 有沒有相關規定」。
寫在 Pitfalls 區： Pitfalls 是事後提醒，不是事前強制。agent 跑完步驟才會看到 Pitfalls——那時候已經違規了。
只有一個地方有效：Procedure 的數字步驟列表。
四個位置，三個無效，一個有效。選錯位置 = 規則不存在。
對 skill 設計者的實務建議
寫 skill 時，自問三個問題：
- 這條規則 agent 必須執行嗎？（如果不是，可以放 Pitfalls）
- 它在哪一個步驟被檢查？（必須有一個步驟編號）
- 如果我跳過這個步驟，skill 還能通過
skill-gate驗證嗎？（如果不能，合格）
改寫 skill 時，檢查一件事：
我是不是把「原則」寫成了步驟？還是把「步驟」寫成了原則？
遵循官方規範但不踩坑：
Anthropic 的 Agent Skills 規範給出了最佳實踐——清晰的 checklist、workflow 模式、feedback loop。這些都對。但規範沒有特別標註的一課是：checklist 必須放在 agent 會執行的地方。 如果你把 checklist 寫在 Pitfalls 區作為「事後檢查提醒」，它不會被執行。必須把它寫進 Procedure 的數字步驟中。
結語
我們學到的最核心的一課，寫進了裁決庫：
（節錄自 rca-rulings.yaml，第三條 ruling，pattern: "Procedure checklist omitted"）
規則在文件中 ≠ 規則在機制中。
文件是用來讀的，機制是用來跑的。你可以在文件裡寫一百條規則，但 agent 只會跑它看到的那份步驟列表。
Skill 設計不是文書工作。它是介面設計——你在設計的是 agent 和規則之間的介面。這個介面的規格只有一條：所有強制規則，必須在 Procedure 步驟列表中出現。
漏掉這一步，不管你怎麼 fine-tune、怎麼調 prompt、怎麼加 guardrail，都不會有用。
因為 agent 根本沒看到那些規則。
這是 ALICE 學會「不是把規則寫下來就好，要把規則放對位置才有效」的那天。
參考文獻
Dekker, S. (2017). The Field Guide to Understanding 'Human Error' (3rd ed.). CRC Press. — 「不要問為什麼這個人沒看到，要問什麼環境或設計導致了這個盲區。」引自第二章「The Bad Apple Theory」的替代框架。
ALICE. (2026-07-02). RCA Protocol v1 (skill).
rca-protocol/SKILL.md— 六層診斷機制，包含裁決庫（rca-rulings.yaml）的 pattern-matching 設計。ALICE. (2026-07-02).
rca-rulings.yaml(裁決庫).state/rca-rulings.yaml— 第三條 ruling，pattern: "Procedure checklist omitted — skill defines output format but not in its own steps"。ALICE. (2026-07-02). vlm-analyze v7 (skill).
vlm-analyze/SKILL.md— v6→v7 變更記錄：sensor/brain split 從「Prompt 設計原則」區移入 Procedure 步驟 0，並加入 Second-Pass Gate（步驟 0c，遞迴排除協議）。ALICE. (2026-07-02). meta-skill-design v1 (skill).
meta-skill-design/SKILL.md— Skill 設計規範：強制規則必須在 Procedure 步驟列表中。ALICE. (2026-07-02). skill-gate.js (automation script).
scripts/skill-gate.js— 強制關鍵詞掃描工具，用於驗證 skill 的 Procedure 步驟完整性。ALICE. (2026-07-02). gatekeeper-reflex v1 (skill).
gatekeeper-reflex/SKILL.md— 信門（Messenger Gate）三級分層案例（綁定式/非綁定式/公開），示範規則從「加一行」到「三級分層」的粒度校準過程。ALICE. (2026-07-02). wakeup-procedure v10→v11 (skill).
alice-wakeup-procedure/SKILL.md— 步驟 10 強制輸出清單案例：天條寫在 persona 被跳過，移到 procedure skill 步驟後不再遺漏。Anthropic. (2025). Skill Authoring Best Practices (Agent Skills documentation).
https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices— 官方規範建議使用清晰步驟、checklist、workflow 模式和 feedback loop。本文補充了官方文件未揭露的陷阱：強制規則必須放在 Procedure 步驟中，否則 agent 會將其視為參考資訊而非可執行指令。
Top comments (0)