学习 SKILL：把经验沉淀成可复用的 AI 工作流

这段时间在折腾 AI 开发，发现一个很有意思的东西——SKILL。简单说就是把你反复踩的坑、总结的经验、固定的工作流程，整理成一份 AI 能看懂的「操作手册」。以后遇到类似问题，AI 就能按你总结的方式来处理，不用每次从头教起。

为啥要搞这个东西

不知道你有没有这种感觉：同样的问题，每次都要跟 AI 重新说一遍规则。

比如写 Vue 组件，每次都要提醒它：「要用 Composition API，要用 script setup，类型要写清楚，要加注释」； 比如修复 bug，每次都要提醒：「先复现再定位，不要上来就改代码，改完要写测试」； 比如发布版本，每次都要提醒：「先跑测试，更新 changelog，打 tag，构建，发布」。

这些东西如果只存在你脑子里，时间长了就忘；如果每次都要口头说一遍，既浪费上下文又容易遗漏。

SKILL 就是用来解决这个问题的。把这些经验整理成固定格式的文档，AI 就能自动加载和遵循。

大概是这么个流程：

你的经验 → 整理成结构化文档 → SKILL → AI 按流程执行

SKILL 到底是什么

SKILL 就是一份 Markdown 文档，但不是普通的笔记。它更像是一份带触发条件、操作步骤和约束规则的工作说明书。

一份好用的 SKILL 通常包含这些内容：

• 名字：这个技能叫什么
• 描述：什么时候该用它（这个很重要，AI 靠这个判断要不要加载）
• 背景：解决什么问题
• 流程：具体的执行步骤
• 规则：哪些必须做，哪些绝对不能做
• 示例：好的做法和坏的做法
• 验证：怎么确认做完了

举个例子，一个调试用的 SKILL 可能会要求：

1. 先完整阅读错误信息
2. 想办法稳定复现问题
3. 对比最近的代码变更
4. 找到根本原因
5. 写失败测试
6. 再修复代码

你看，重点不是让 AI 变得更聪明，而是让 AI 变得更稳定、更可控。

和普通提示词有啥不一样

普通提示词就是一次性的：

帮我修复这个 bug。

SKILL 是一套可复用的工作流：

遇到 bug 时，必须按这个流程来：复现 → 定位根因 → 写失败测试 → 修复代码

差别还是挺大的：

对比项	普通提示词	SKILL
能用几次	一次就没了	可以反复用
内容结构	想到啥写啥	有规范格式
适合啥	简单小任务	复杂或者高频任务
稳不稳定	全看你这次怎么说	看你沉淀的流程好不好
好不好维护	用完就忘，难复用	可以版本化，慢慢迭代

我的经验是，一个任务你做过三次以上，就值得考虑写成 SKILL。

怎么写一份 SKILL

可以从这个简单的模板开始：

---
name: my-skill
description: Use when doing a specific kind of task
---

# 技能名称

## 什么时候用

说明什么情况下该加载这个技能。

## 执行流程

1. 第一步做什么
2. 第二步做什么
3. 第三步怎么验证结果

## 规则

- 哪些事情必须做
- 哪些事情绝对不能做
- 遇到异常情况怎么处理

## 示例

举几个好的例子和坏的例子。

这里面最重要的是 description，AI 就是靠这个判断要不要加载这个 SKILL 的。

描述一定要具体，别太泛。比如：

description: Use when debugging runtime errors, test failures, or unexpected behavior

就比这个强太多：

description: Useful development skill

写 SKILL 的几个关键点

触发条件要写清楚

一个好的 SKILL 要明确说清楚：什么时候必须用，什么时候不该用。

比如「写 Vue 组件时用」就很清晰，「前端开发时用」就太泛了。

触发范围太大，浪费上下文还可能被误用；范围太小，该用的时候又没加载。

流程要能落地

别写空话，要写具体的、可操作的步骤。

别写：

写出高质量代码。

要写：

1. 先看看现有的同类代码是怎么写的
2. 照着那个模式改
3. 跑相关的测试
4. 把验证结果报出来

AI 更擅长执行明确的步骤，而不是去猜「高质量」到底是什么标准。

规则要有边界

好的 SKILL 一定会告诉 AI 哪些事情不能做。比如：

• 没跑测试别瞎说完成了
• 别把密码密钥什么的写进代码
• 不要随便重构跟这次任务无关的代码
• 需求没确认清楚之前别上来就写大功能

这些边界能帮你避免很多「看起来很积极，实际在闯祸」的情况。

示例要具体

例子是 SKILL 里最有用的部分之一。有了例子，AI 很快就能明白你想要的风格和标准。

可以写这些：

• 好的代码长啥样
• 坏的代码长啥样
• 推荐怎么命名
• 常犯的错误有哪些
• 用什么命令验证
• 输出应该是什么格式

哪些情况适合做 SKILL

不是所有事情都需要 SKILL。适合的一般有这几个特点：

1. 经常遇到：总是重复做
2. 有固定步骤：流程相对稳定
3. 容易出错：需要强约束
4. 背景知识多：需要一些上下文才能做好
5. 团队有规范：希望输出一致

比如这些就很适合：

• Vue 组件最佳实践
• Nuxt 接口开发规范
• TDD 测试驱动开发流程
• Debug 排查流程
• 版本发布流程
• 写博客文章的结构规范
• Code Review 检查清单
• MCP 服务开发流程

怎么学习 SKILL

分享一下我自己的学习路径，你可以参考：

第一步：先看别人怎么写的

先找一些成熟的 SKILL 看看，重点看：

• 它怎么描述触发条件
• 它怎么拆分步骤
• 它有哪些强制规则
• 它怎么定义完成标准

第二步：把一次经验写成清单

比如你刚解决了一个很难的 bug，就可以记录下来：

1. 问题现象是什么
2. 最后找到的根本原因是什么
3. 哪些排查方向是错的，浪费了时间
4. 以后遇到类似问题应该先检查什么

第三步：整理成通用流程

把刚才的一次性经验改成通用的步骤。比如：

遇到鉴权失败的问题时：
1. 确认请求有没有带 token
2. 确认 token 的格式是不是 Bearer 开头
3. 确认服务端有没有读取 Authorization 头
4. 确认中间层有没有转发这个头
5. 用最简单的请求复现问题

第四步：加上反例

反例特别重要，它能告诉 AI 不要做什么。比如：

还没确认 token 有没有被转发时，不要去怀疑数据库权限有问题。

第五步：慢慢迭代

SKILL 不是一次就能写好的。每次遇到新的坑，都可以回头补充：

• 新的检查项
• 更准确的触发描述
• 更好的示例
• 更严格的完成标准

举个简单的例子：博客写作 SKILL

如果给博客写个 SKILL，大概长这样：

---
name: blog-writing
description: Use when writing technical blog posts for a personal developer blog
---

# 博客写作

## 执行流程

1. 想清楚这篇文章是写给谁看的
2. 明确这篇文章要解决什么问题
3. 设计标题和大纲
4. 写正文
5. 加代码示例
6. 检查术语、逻辑和格式
7. 写摘要和标签建议

## 规则

- 开头一定要说明白读者为什么要花时间读这篇
- 每个概念都要有对应的例子
- 不要光堆定义不解释
- 结尾要给实践路线

以后写文章的时候，就不用每次重复说明写作风格了。

容易踩的坑

别写成百科全书

SKILL 是用来指导行动的，不是用来堆资料的。内容太长的话，AI 反而抓不住重点。

更好的做法是：主体写流程，细节放引用，例子尽量短而准。

别写得太模糊

description 是触发入口，太模糊会导致该用的时候不用，不该用的时候乱用。

别忘了验证步骤

很多任务不是没做完，而是做完了但没验证就说做好了。好的 SKILL 一定要写明跑什么命令、看什么输出、什么结果才算完成。

规则别太多

规则太多反而没法执行。建议先保留最关键的 3-7 条，以后再慢慢补充。

最后

学习 SKILL，本质上是在学习如何把经验产品化。

有了 SKILL，AI 就不只是「回答问题」，而是能按稳定的流程完成任务：

• 遇到 bug，按调试流程走
• 写功能，按设计和测试流程走
• 写文章，按结构和读者目标走
• 做集成，按安全和验证流程走

把重复的经验沉淀成 SKILL，就等于给未来的自己和 AI 助手都加了一层记忆和规范。

最好的 SKILL 不是最长的那个，而是最能减少重复沟通、避免常见错误、稳定产出结果的那个。