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 的边界在哪；
- 换模型时，五分钟就能验一遍。
代价几乎为零——附件不被读到就不占地方。