07 · 先寫測試再寫正文
寫 Skill 最容易犯的錯，是先寫一大篇說明書，再去看它有沒有用。正確的順序反過來：先找出"不給 Skill 它會錯在哪"，再只寫剛好能修好這些錯的內容。
為什麼順序要反過來
你憑想像寫的說明書，一半在解決不存在的問題。
模型本來就知道會議紀要該有結論和待辦——你花三段話解釋這個，純屬浪費上下文。它真正不知道的是：你們家的紀要人名不能補全、拿不準要寫「待確認」、跑題內容要歸到第三塊。
這三條才是你的 Skill 該裝的東西。 怎麼找出來？測一遍就知道了。
三步走
第 1 步 · 不帶 Skill 跑一遍，把錯記下來
拿一份真實材料，用一句最普通的話讓它做：
幫我把這段會議記錄整理成紀要。
【貼上材料】然後逐條記錄它錯在哪，越具體越好：
基線（無 Skill）：
1. 把"劉總監"寫成了"劉建國總監" ← 補全了人名
2. 給會議編了個日期 2026-04-12 ← 材料裡沒有
3. 待辦沒有責任人列 ← 結構不對
4. 把"預算可能收緊"漏了 ← 跑題內容被丟棄
5. 把"秒殺規則未定"寫進了"已定事項" ← 分類錯這份基線清單就是你的需求文件。 你的 Skill 只需要解決這五條，不需要解決別的。
寫完 Skill 之後回來對，五條都修好了就是達標。修好三條就是沒寫完。
第 2 步 · 攢三個用例
一個不夠，五個太多，三個剛好：
| 用例 | 測什麼 | 怎麼設計 |
|---|---|---|
| ① 正常觸發 | 它會不會自己想起來用這個 Skill | 用一句平常會說的話 + 一份新材料 |
| ② 邊界情況 | 規矩在難處有沒有生效 | 材料裡缺資訊、有衝突、有跑題 |
| ③ 不該觸發 | 會不會誤傷 | 一個相鄰但不同的任務 |
用例 ① 最容易被忽略，但它測的是整個 Skill 的前提：沒被觸發，後面全是零。
用例 ③ 也別省。Skill 裝到第五個的時候，誤觸發會成為主要煩惱。
別用你調提示詞時用過的那份材料
那份材料你已經反覆看過、提示詞也是照著它調的，測不出問題。換新的。
第 3 步 · 寫剛好夠的正文
對著第 1 步的基線清單，一條一條給解藥：
| 基線裡的錯 | 正文里加的話 |
|---|---|
| 補全了人名 | "人名沿用原文稱呼，不要補全" |
| 編了日期 | "日期照抄原文；沒有則填「待確認」" |
| 待辦沒責任人 | 給一個三列表格模板 |
| 漏了跑題內容 | "跑題內容不寫進紀要；但若含承諾或風險，歸入第三塊" |
| 分類錯 | "先把內容分成已定 / 要辦 / 未定三類，再往模板裡填" |
清單上沒有的，一句都別寫。 你覺得"順便交代一下也好"的那些話，就是把正文撐到沒人看的元兇。
一張記錄表
三個用例 × 每次改版，記一張表。跟提示詞篇 08 章是同一套方法：
| ① 正常觸發 | ② 邊界 | ③ 不該觸發 | |
|---|---|---|---|
| 基線（無 Skill） | — | ❌ 5 條問題 | — |
| v1 | ❌ 沒被觸發 | ✅ | ✅ |
| v2（改了 description） | ✅ | ⚠️ 衝突被抹平了 | ✅ |
| v3（加了衝突規則） | ✅ | ✅ | ✅ |
三列全綠，釋出。
怎麼判斷"通過"
別用"感覺不錯"。把 Skill 裡的檢查清單直接拿來當評分表：
- [ ] 三個章節齊全，標題與模板一致
- [ ] 全文無材料之外的人名全稱、日期、金額
- [ ] 每條待辦都有負責人與截止（或明確的「待確認」）
- [ ] 未定的事沒有被寫進第一塊這也是為什麼前面建議每個 Skill 都自帶一份檢查清單——它同時是給模型的自查依據，和給你的驗收標準。 一份東西兩個用途。
換模型也要測
Skill 是加在模型上的東西，效果取決於模型。同一份 Skill：
- 強模型：可能嫌你寫得太囉嗦，反而不如簡潔版
- 快而便宜的模型：可能需要你把步驟寫得更細才跟得上
如果你們團隊有人用這個、有人用那個，至少在你們實際會用的那幾個上各跑一遍三用例。
一個偷懶但有效的做法
把三個用例的材料和期望結果，存進 Skill 的附件裡。
meeting-notes/
├── SKILL.md
└── TESTS.md ← 三個用例：材料 + 期望表現好處：
- 你三個月後回來改，不用重新想怎麼測；
- 同事接手，知道這個 Skill 的邊界在哪；
- 換模型時，五分鐘就能驗一遍。
代價幾乎為零——附件不被讀到就不佔地方。