文章目录
- @[toc]
- 一句话说清楚
- 一个 Skill 长什么样？
- 整个流程怎么跑的？
- 第一步：聊需求
- 第二步：写草稿
- 第三步：跑测试
- 先造测试用例
- 然后做对比实验
- 第四步：你来看效果
- 第五步：改进
- 1. 别太死板
- 2. 没用的就删
- 3. 说原因，别只说"必须"
- 4. 重复的工作抽成脚本
- 收尾：优化触发词
- 补充：为什么分三层？
- 完整例子：做一个"周报生成skill"
- 聊需求
- 写草稿
- 改进（多轮）
- 测试看效果
- 继续改进
- 总结
- 什么时候该用它？
文章目录
- @[toc]
- 一句话说清楚
- 一个 Skill 长什么样？
- 整个流程怎么跑的？
- 第一步：聊需求
- 第二步：写草稿
- 第三步：跑测试
- 先造测试用例
- 然后做对比实验
- 第四步：你来看效果
- 第五步：改进
- 1. 别太死板
- 2. 没用的就删
- 3. 说原因，别只说"必须"
- 4. 重复的工作抽成脚本
- 收尾：优化触发词
- 补充：为什么分三层？
- 完整例子：做一个"周报生成skill"
- 聊需求
- 写草稿
- 改进（多轮）
- 测试看效果
- 继续改进
- 总结
- 什么时候该用它？
一句话说清楚
Skill= 你写给 AI 的一份"操作手册"，让它干某类活时不再瞎搞。
Skill Creator= 帮你写这份手册的助手。你说需求，它写手册、测试、改进，直到好用为止。
一个 Skill 长什么样？
就是一个文件夹，核心是一个叫 SKILL.md 的文件：
周报生成器/ ├── SKILL.md ← 核心！"手册"正文 ├── scripts/ ← 可选：辅助脚本 └── references/ ← 可选：参考资料SKILL.md 的基本格式：
---name:weekly-reportdescription:生成格式化周报。当用户提到周报、 本周总结、工作汇报时使用此技能。---# 这里写具体指令# 告诉 AI 怎么干活就两部分：头部（名字+什么时候用）和正文（怎么干活）。
整个流程怎么跑的？
聊需求 → 写草稿 → 跑测试 → 你来看效果 → 改进↑ 不满意就一直循环，直到你说 OK
// SKILL.md 第10-20行说的就是这个循环： - 想清楚要让 AI 干嘛 - 写一版草稿 - 拿几个测试例子去跑 - 看看结果好不好 - 根据反馈改进 - 重复，直到满意第一步：聊需求
Skill Creator 会问你几个关键问题：
// 它会问你： 1. 你想让 AI 干什么？ 2. 什么情况下应该触发这个技能？ 3. 输出应该是什么样子？ 4. 要不要搞测试用例来验证？举个例子 —— 你想做"周报生成器"：
你：我想让 AI 帮我写周报，我告诉它这周干了啥，它帮我整理成格式化的周报
Skill Creator：周报格式有模板吗？要分哪几个板块？语气正式还是随意？
你：分"本周完成"、“下周计划”、"风险"三块，语气正式点
聊清楚后，进入下一步。
第二步：写草稿
Skill Creator 根据你的需求写出 SKILL.md。
有个重要细节：description字段要写得"积极主动"一些。
// AI 天生有点"懒"，不太愿意主动调用技能 // 所以描述要写得覆盖面广一点，多列几种触发场景| 示例 | |
|---|---|
| 不好 | “帮助生成周报” |
| 好 | “生成格式化周报。当用户提到周报、本周总结、工作汇报、甚至说’帮我整理下这周干了啥’时都触发” |
第三步：跑测试
这步做的事情很简单：拿几句话去试，看 AI 干得好不好。
先造测试用例
模拟真实用户会怎么说：
// 假装自己是用户，写几种不同的说法： 1. "帮我写个周报，这周修了登录的bug，还做了用户反馈页面" 2. "整理下这周工作，主要做了代码评审和迭代规划" 3. "老板要周报，我这周净开会了，还有几个线上问题"然后做对比实验
| 对照组 | 实验组 |
|---|---|
| 不带技能的 AI | 带着你的技能的 AI |
| → 看"裸奔"出来什么效果 | → 看加了手册后好了多少 |
就像药物临床试验：一组吃药，一组吃安慰剂，对比效果差异。
第四步：你来看效果
测试跑完后，会打开一个网页让你看结果：
- 左边是"没技能"的输出，右边是"有技能"的输出
- 你逐条看，觉得哪里不好就写评语
- 觉得没问题的直接跳过
- 看完点"提交"
你可能会写这样的反馈：
测试1："格式不错，但语气太正式了，像给甲方写的" 测试2：（空 = 你觉得OK） 测试3："风险那块写得太敷衍了，应该具体说是什么问题"第五步：改进
根据你的反馈修改 SKILL.md，然后重新跑测试。
改进时有 4 个原则：
1. 别太死板
// 测试只有几个例子，但技能要能应对无数场景 // 不能为了通过测试写死板的规则| 示例 | |
|---|---|
| 坏 | “如果用户提到’登录bug’就归类到安全相关”（太死了，换个词就不灵了） |
| 好 | “根据工作内容的性质自动归类到合适的方向”（灵活通用） |
2. 没用的就删
// 如果某条指令对结果没啥帮助，删掉它 // 手册越精简，AI 执行得越好3. 说原因，别只说"必须"
| 示例 | |
|---|---|
| 坏 | “必须用列表格式！禁止用段落！必须加表情！”（AI不理解为什么） |
| 好 | “周报的读者是忙碌的老板，他们要快速扫一眼就抓住重点，所以用要点列表比长段落好”（AI理解了，举一反三） |
4. 重复的工作抽成脚本
// 如果每次测试都发现 AI 在重复写同样的辅助代码 // 那就写好放到 scripts/ 文件夹里，让它直接用 // 比如：每次都要解析 git 记录，那就写一个现成的脚本收尾：优化触发词
技能做好了，还要确保 AI “知道什么时候该用它”。
手册写好了还不够，得贴好标签。标签越准，AI 越能在对的时候拿出来用。
怎么优化？造 20 个测试句子：
// 10 句"应该触发"的（各种说法）： "帮我把这周干的事整理成周报发给老板" "这周的工作汇报帮我写一下" "整理下本周工作内容" // 10 句"不应该触发"的（容易混淆的）： "帮我写个项目文档" ← 不是周报！ "总结一下这次代码改动" ← 是代码总结！然后自动跑 5 轮优化，找到最准确的描述。
// 自动把 20 个句子分成"训练集"和"测试集" // 反复调整 description，让触发准确率最高 // 用测试集的分数来选最好的版本（防止过拟合）补充：为什么分三层？
AI 的"注意力"有限（不能同时记住太多东西），所以技能分三层加载：
// 三层加载机制： 第1层：名字 + 简介（永远在 AI 视野里，约100字） 第2层：手册正文（触发技能时才加载，建议500行以内） 第3层：附带资料（需要时才去查，不限大小）就像你的书架：
- 第1层 = 书脊上的书名（一眼扫到，决定要不要拿下来看）
- 第2层 = 翻开书（要用的时候才看）
- 第3层 = 书里的附录（需要细节时才翻到后面）
完整例子：做一个"周报生成skill"
聊需求
直接告诉claude，创建一个周报（cladue会开始思考）：
写草稿
他会在
~\.claude\skills目录下生成一版你要的内容：
改进（多轮）
把不符合你要求的内容改掉（直接告诉它就行了，不要直接改skill文件）
第二轮：
测试看效果
准备测试数据，看结果：
> 用 下面内容测试周报skill： 周一 • 整理并同步上周未完成的需求文档，和产品对齐本周优先级 • 修复首页 Banner 在移动端适配异常的问题（Safari / iOS 端） • 参与需求评审会，评估活动页开发周期与技术风险 • 优化本地开发环境配置，升级 pnpm & node 版本 周二 • 活动页静态页面还原（基于 Figma 设计稿） • 封装通用弹窗组件，支持异步关闭与多类型提示 ... 周五 ...
继续改进
这时候如果你还是觉得生成内容不合适，你就继续让它改skill，直到满意为止。
总结
聊需求 → 写手册 → 测试 → 看效果 → 改 → 循环 → 交付
本质就是：把"教 AI 干活"这件事，变成了一个可以反复试、反复改的流程。不是写一次就完了，而是像训练员工一样，练到好用为止。
什么时候该用它？
- 你有个重复性的活，想让 AI 每次都按你的标准来
- 你发现自己每次都在重复输入差不多的话
- 你想把自己的经验"教"给 AI
- 你需要 AI 输出严格按某个格式走
不太适合：只用一次的任务，或者纯主观创作（比如写诗 —— 好坏没法量化）
