🎯 什麼情境該想到我
當你「skill 內容明明沒問題，但它該出手時不出手、不該出手時亂出手」的時候。
這是 skill 最常壞掉、卻最少人測的一環——大部分評測只測「內容有沒有用」，不測「會不會被叫起來」。
⚙️ 怎麼用（步驟 / 公式）
-
列出 6 個左右的測試請求，每個先寫下「期望觸發或不觸發」。
關鍵是正負案例都要有，而且負案例要涵蓋幾種不同的「不該出手」：類型 例子（以短劇編劇 skill 為例） ✅ 該觸發 標準請求 ✅ 該觸發 只做其中一個步驟的單點請求 ❌ 不該觸發 鄰近但不同的領域（長篇小說對白） ❌ 不該觸發 下游工序（分鏡——該給分鏡 skill） ❌ 不該觸發 另一個工具的職責（影片提示詞） ⚠️ 部分適用 混合請求：先做自己該做的，再交棒 最後那類（混合請求）最容易出事——skill 常會整碗端走。
-
每個請求跑 5 次，記正確數（例：
5/5、3/5）。
觸發是機率性的，單次結果沒有意義。 -
裝 skill 前先跑一次當基線（RED），才知道哪些行為本來就有、哪些是 skill 帶來的。
-
看哪一條沒滿分，找出誤判的方向。
實例：某條「只交付臺詞」的請求首次只有3/5，失敗型態是誤走一般審閱／修改路徑。 -
⭐ 做最小修補，然後重跑整組。
上例的修法是把路由條目限定成「審閱或修改（不含單點創作）」——改幾個字，不是重寫 description。
重跑整組是為了確認沒有回歸：改 description 修好 E，很可能同時弄壞 B。 -
全部 5/5 才算過，並把結果表存進 repo。
🧪 我實際套用的紀錄
- 2026-08-28：（待填）
⚠️ 注意 / 什麼時候不適用
- 這張只測「有沒有被叫起來」，不測「叫起來之後做得好不好」。後者要用 工具-AI改動的AB對照評測，兩者是互補的兩半，缺一不可。
- 負面案例比正面案例更難寫也更有價值。正面案例你自然想得到；真正會出事的是「鄰近領域」與「下游工序」——要刻意去想「誰的地盤最容易被我誤踩」。
- description 是全域資源。它同時決定觸發與不觸發，改動一定要重跑整組；只驗剛修好的那條等於沒驗。
- n=5 是下限不是保證。邊界模糊的條目（真的介於適用與不適用之間）可能永遠到不了 5/5——那代表範圍定義本身有問題，該改的是 skill 的邊界，不是 description 的措辭。
- 環境裡裝了哪些其他 skill 會影響結果：「該交棒給分鏡 skill」這種期望，在沒裝分鏡 skill 的環境下無法真正驗證。
🔗 相關工具
- 工具-用壓力情境測試skill —— 另一軸：這張測「會不會被叫起來」，那張測「被叫起來之後扛不扛得住壓力、會不會被合理化掉」。兩軸都測才算驗過
- 工具-AI改動的AB對照評測 —— 另一半：內容品質的對照評測。那張的來源文章明確沒測觸發（它把 skill 路徑直接塞進 prompt），這張補的正是那個缺口
- 工具-把重複的prompt包成skill —— 做完 skill 之後，這張是驗收清單的一部分
- 工具-防止agent造假通過驗收 —— 同樣的心法：把「什麼叫過」定義成可判定的數字，而不是感覺