文章目录

• • @[toc]
  • 一句话说清楚
  • 一个 Skill 长什么样？
  • 整个流程怎么跑的？
  • 第一步：聊需求
  • 第二步：写草稿
  • 第三步：跑测试
  • • 先造测试用例
    • 然后做对比实验
  • 第四步：你来看效果
  • 第五步：改进
  • • 1. 别太死板
    • 2. 没用的就删
    • 3. 说原因，别只说"必须"
    • 4. 重复的工作抽成脚本
  • 收尾：优化触发词
  • 补充：为什么分三层？
  • 完整例子：做一个"周报生成skill"
  • • 聊需求
    • 写草稿
    • 改进（多轮）
    • 测试看效果
    • 继续改进
  • 总结
  • 什么时候该用它？

一句话说清楚

Skill = 你写给 AI 的一份"操作手册"，让它干某类活时不再瞎搞。

Skill Creator = 帮你写这份手册的助手。你说需求，它写手册、测试、改进，直到好用为止。

---

一个 Skill 长什么样？

就是一个文件夹，核心是一个叫 SKILL.md 的文件：

周报生成器/
├── SKILL.md        ← 核心！"手册"正文
├── scripts/        ← 可选：辅助脚本
└── references/     ← 可选：参考资料

SKILL.md 的基本格式：

---
name: weekly-report
description: 生成格式化周报。当用户提到周报、
  本周总结、工作汇报时使用此技能。
---

# 这里写具体指令
# 告诉 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 输出严格按某个格式走

不太适合： 只用一次的任务，或者纯主观创作（比如写诗 —— 好坏没法量化）