LESSON 04 · SKILL 技能
Why this lesson · 为什么值得学
学会改现有 Skill 适配自己的习惯
把重复活封装成专属 Skill
做出第一个自己的自动化
很多人第一次听到「创建 skill」会觉得很难——要写代码、要懂结构、要会 YAML 格式。
但真相是：创建 skill 根本不需要先理解结构。你直接说「帮我创建一个 XXX 的 skill」——AI 就帮你搞定了。
举一个真实的例子：有人让 AI 创建一个「每日复盘 skill」，他对 AI 说：
AI 自动生成了完整的 SKILL.md——包括名称、简介、规则、陷阱清单。创建者全程没写一行结构代码。
你不知道怎么拆解 → 告诉 AI 你的目标 → AI 帮你拆解并生成 skill。你不需要成为"skill 结构专家"，你只需要知道"我想要什么"。
AI 会执行 skill_manage(action='create', ...)，自动把刚才提炼的规律写成 SKILL.md——包括 YAML 头、工序、陷阱清单。
你全程不需要手动写任何结构化内容。你只需要说"我要什么"和"这个行不行"。
用"指令"而非"信息"，用示例领先
写在 Skill 里的句子，最好能直接被执行。与其写「建议使用某 API」（AI 可能不行动），不如写「始终调用 interactions.create()」。同样，5 行真实代码片段比 5 段文字解释更有力——例子让 AI 一眼就懂你要什么。
有用，但用途变了：
| 过去（旧思维） | 现在（vibe 思维） |
|---|---|
| 先学结构 → 再手动写 skill | 告诉 AI 目标 → AI 自动生成 → 你有空了再去看结构 |
| 你不会写结构 = 你不会创建 skill | 你不会写结构 ≠ 你不会创建 skill——AI 替你写 |
| 结构是门槛 | 结构是结果（不是前提） |
| 你需要知道 YAML 是啥 | 你只需要知道"我有个经验想打包" |
Skill 不再是"写出来的"，而是"长出来的"——你喂案例、给反馈、说迭代，AI 帮你把隐性的经验变成显性的 skill 文件。
你知道结构只是方便你后期检查质量，不是创建的前提。
假设你完全不会写 skill，也没看过任何 skill 文件——你只需要做这件事：
然后 AI 会自动做剩下的事——读你的案例、提炼规律、调用创建命令生成 skill 文件。你只需要确认结果。
这就是 vibe 创建方式：你负责说「要什么」，AI 负责写文件。
建完一定要跑，把"验证点"写进循环
创建 Skill 不是终点。建好后用真实任务跑几遍，看它哪里会坏：是不是漏了某步、是不是假设了不存在的东西。把「运行→验证→修复→再验证」的循环写进 Skill，比一句「保证质量」管用得多。复杂任务尤其要留明确的验证点。
skill_view(name='你创建的skill名')，看看 AI 帮你写了什么结构复杂流程拆成多个小 skill 串联
别把一个大流程塞进一个巨无霸 skill。拆成「定位→修改→验证」这样的小步，让 AI 一步步交付，你也能一步步验收，出错好定位。
上下文是公共资源，skill 越简洁越好
skill 里的每句话都占 AI 的「注意力预算」。能假设 AI 已知道的就别写，把篇幅留给真正关键的规则和陷阱——简洁的 skill 比啰嗦的更可靠。
别指望一次就写出完美的 Skill。大部分在用的 Skill，都改到了第 5 版、第 10 版。这很正常——就像你给新员工写的操作手册，也是用了改、改了再用的。
持续改进的节奏：每次用 Skill 跑完一个真实任务，问自己一句——哪里做对了？哪里没做对？没做对的地方，是规则漏了、还是陷阱没写到？然后直接跟 AI 说「这条规则不对，改成 XXX」「加一条：下次别忘了 XXX」。AI 会自动更新 Skill 文件。用得越多、改得越多，Skill 就越靠谱。
你甚至可以隔一段时间开一个专门的会话，让 AI 帮你审计已有的 Skill：「帮我看看这个 skill 有没有互相矛盾的规则、有没有过时的内容、有没有可以合并的重复部分」——定期清理一遍，保持精炼。
⚠️ 一个需要辨别的观点：你可能会在网上看到有人说「Skill 会淘汰 MCP 和 Workflow」——这是个人预测，不是事实。现实中，Skill（操作手册）、MCP（连接工具的翻译器）、Workflow（固定流水线）解决的是不同层面的问题，目前是互补而非替代关系。它们各自会怎么演进，取决于产品和技术的变化。听到这类预测时，当思路参考就好，别当成定论。
REFERENCES · 参考资料
下一步：把 Skill 用起来。 下一课会把审美方法整理成一个可复用的页面美化 Skill。