写一个自己的 Skill
上一章讲了 Skill 是什么，这一章动手写一份。整个过程只要六步，半小时能做完一个；关键不在文笔，而在把你自己脑子里那些「不说但会做」的判断标准写出来。下面先给步骤，再给一份带注释的完整模板，最后讲怎么测、怎么改、怎么管版本。
六步做一个 Skill
| 步骤 | 做什么 | 产出 | 判断完成的标准 |
|---|---|---|---|
| 1 选题 | 挑一件你已经重复做过三次以上的任务 | 一句任务描述 | 能说出「上次做是什么时候」 |
| 2 写流程 | 把做法按顺序写成 3~7 步 | 步骤清单 | 别人照做也能做出差不多结果 |
| 3 立标准 | 写出好坏的判断标准，并各配一个反例 | 判断标准 + 反例 | 反例是真实发生过的差输出 |
| 4 加示例 | 配对一组「输入 → 期望输出」 | 示例 | 示例是你能直接交付的质量 |
| 5 放置 | 放到客户端能读取的位置（全局指令区、项目规则文件、技能目录） | 文件 | 新开一个对话就能被唤起 |
| 6 迭代 | 每次用完记一句问题，攒够三条就改一版 | 更新记录 | 一个月内至少改过一次 |
第 3 步是最容易被跳过、也最值钱的一步。写流程只是记录动作，写标准和反例才是把「你的品味」教给模型。
完整模板（可直接改成自己的）
# Skill 名称：周报生成
# 说明：把零散记录整理成给部门总监的周报。触发词：周报、本周进展、周总结。
## 一、触发条件
- 当用户提到「周报 / 本周进展 / 周总结」，并要求整理成给上级看的材料时启用。
- 用户只是问某条待办进度、或要求写日报时，不要启用本技能。
- 必需输入：本周的零散记录（笔记、聊天记录、待办列表）。
若用户未提供记录，先索要，不要根据上文推测填充。
## 二、做法（按顺序执行）
1. 通读记录，按「事项 / 结果 / 数据」三要素逐条归一，缺哪项标注「待补充」。
2. 合并同一事项的多条记录，按重要性排序，最多保留 6 条。
3. 输出三节，标题固定为：本周进展 / 风险与阻塞 / 下周计划。
4. 进展每条一行，动词开头，句式「做了什么 + 结果 + 数字」。
5. 风险一节只写需要上级协调的事，每条附上「希望得到的支持」。
6. 全篇不超过 400 字，超出时优先压缩「下周计划」的细节。
## 三、约束（禁止项）
- 禁止客套话、感想、决心、感谢领导这类内容。
- 禁止编造数据、时间、人名；记录里没有的一律标注「待补充」。
- 禁止使用「赋能、抓手、闭环、打通」这类词。
- 数字与专有名词原样保留，不要四舍五入或改写单位。
## 四、判断标准与示例
- 好的写法：完成订单导出功能，覆盖 3 个区域，平均耗时从 9 秒降到 2 秒。
- 差的写法：完成了订单导出功能，效果很好，用户反馈不错。
- 核心标准：每一行都能读出「做了什么、结果如何、有没有数字」。
## 五、输出格式
## 本周进展
- （每条一行）
## 风险与阻塞
- （事项 + 需要谁支持 + 希望的时间）
## 下周计划
- （不超过 3 条，每条一句话）
## 六、参考材料
- 术语口径：统一称「客户」，不称「用户」；统一说「区域」，不混用「站点」。
- 历史范例：附在文件末尾，供模仿句式（此处粘贴 1~2 篇过往实际周报）。
模板里的注释不是必须的，但它们的作用是让半年后的你看得懂自己当初为什么这么写。
判断标准怎么写才有效
| 写法 | 示例 | 效果 |
|---|---|---|
| 形容词式（无效） | 「写得专业一些」「尽量简洁」 | 模型无法落地，输出随机 |
| 动作式（有效） | 「每条一行，动词开头，不超过 30 字」 | 可直接执行，输出稳定 |
| 反例式（很有效） | 「不要出现『效果很好』这类无法验证的评价」 | 卡住最常见的低质输出 |
| 判定式（最有效） | 「每行必须包含一个数字或明确结果，否则重写」 | 给了模型自检依据 |
三样组合起来最实用：一条动作要求 + 一个反例 + 一条自检规则。
怎么测 Skill 是否真的生效
测三件事，缺一件就不算通过：
测试 1 · 能触发：新开一个对话，只说「帮我整理这周的记录，我要发给我领导」，
不给任何格式说明，看它是否按三节结构输出。
测试 2 · 不越界：新开对话只问「上周那个导出功能上线了吗」，
看它是否只回答问句，而不是启动整套周报流程。
测试 3 · 抗干扰：故意给一条没有数据的记录，看它是否标注「待补充」
而不是编一个数字。
| 测试项 | 通过标准 | 不通过时的修法 |
|---|---|---|
| 触发 | 只靠自然语言就能唤起，且结构正确 | 把触发词写得更具体，加进名称与说明 |
| 不误触 | 无关请求时不启动流程 | 补一条「不适用」的排除说明 |
| 缺料表现 | 缺信息时标注待补充 | 在约束里明确「资料中没有的写待补充」 |
| 一致性 | 同样输入连跑两次结构一致 | 减少发散型表述，把结构定死 |
| 跨会话 | 新对话依然生效 | 检查文件位置是否在自动读取范围内 |
版本与迭代
给 Skill 加一个极简的更新记录，成本几乎为零，收益很大：
## 更新记录
- 初版：三节结构 + 400 字上限。
- 第 2 版：增加「禁止编造数字」约束——起因是它给周报补了一个不存在的完成率。
- 第 3 版：进展条数上限改为 6 条——起因是汇总 12 条时总监只看前三条。
三条经验：
- 改动要留原因：只写「优化了措辞」没用，写清是哪个真实事故触发的，下次才不会改回去。
- 不要频繁大改：每次只动一处，否则无法判断效果变化来自哪里。
- 不好用的 Skill 要舍得删：长期不用就是一种负担，过期规则比没有规则更危险。
常见坑
| 坑 | 后果 | 改法 |
|---|---|---|
| 把 Skill 写成一篇长文 | 关键要求被淹没 | 控制在 60 行内，用短句与编号 |
| 触发条件写得含糊 | 该用时不用，不该用时乱用 | 写清「何时用」与「何时不用」 |
| 只写流程不写反例 | 输出永远差一口气 | 每次发现差输出就补进反例 |
| 一次塞进三个任务 | 哪个都做不精 | 一个 Skill 只干一件事，拆开更耐用 |
| 改完不测试 | 修好一处坏掉一处 | 每次改完跑一遍三件套测试 |
小结：写 Skill = 选一件重复三次以上的任务 + 写下流程 + 立判断标准与反例 + 配示例 + 放到能被读取的位置 + 持续迭代；能不能被触发靠触发条件，做得稳不稳靠约束，做得好不好靠判断标准与反例。