很多人一听到“开发 Skill”，第一反应可能是：这是不是要写代码？是不是要懂 Agent 框架？是不是又是一个听起来很高级、实际上门槛很高的东西？

但我这段时间折腾下来，感觉 Skill 没那么玄。

最简单的 Skill，本质上就是把你反复对 AI 说的那一套话，整理成一个可以复用的说明书。它可以很简单，只是一段稳定的对话规则；也可以很复杂，带参考资料、模板、脚本、校验流程，甚至变成一个小型工作流。

这篇就用普通人的角度，讲讲怎么从 0 开始做一个属于自己的 Skill。

普通人创建 Skill 的整体流程

Skill 到底是什么？

先说人话版。

Skill 就是给 AI 准备的一份“专用操作手册”。

平时你可能经常这样和 AI 沟通：

1
2
3
4
5
你帮我整理一下这篇草稿，口语一点，不要改核心意思。
排版成博客格式。
图片路径别弄丢。
最后加上公众号二维码。
先本地预览，确认后再推送。

如果每次都要重新说一遍，就很烦。Skill 要解决的就是这个问题：把这些稳定要求沉淀下来，变成一个文件。以后你只要说“整理这篇文章”，AI 就知道该按你的习惯处理。

按照 Agent Skills 的公开规范，一个标准 Skill 至少是一个文件夹，里面有一个 SKILL.md。这个文件包含元信息和具体说明，也可以继续附带 scripts/、references/、assets/ 等资源。它的价值不是“让 AI 变聪明”，而是把你的经验、流程、偏好和约束稳定地交给 AI。

为什么普通人也值得开发 Skill？

我觉得意义主要有五个。

第一，少说重复话。

你每天都在重复的那些要求，比如“不要改核心意思”“先预览再推送”“图片别丢”“Windows 环境用 .bat”，都可以变成 Skill 里的默认规则。

第二，把个人习惯变成能力。

同样是整理文章，有人喜欢正式，有人喜欢口语；有人要微信公众号风格，有人要技术博客风格；有人喜欢先写大纲，有人喜欢直接出成文。Skill 可以把这些偏好固定下来。

第三，让 AI 少犯老错误。

你曾经纠正过 AI 的地方，往往就是 Skill 最有价值的内容。比如：

  • 不要把 tempbook/ 里的临时文件提交。
  • 图片要复制到 source/img/xxx/，不能只引用本地路径。
  • 写完文章先 hexo generate，不要直接推送。
  • 密钥、数据库连接串、邮箱密码不能进入 Git。

这些不是大而空的“最佳实践”，而是你自己真实踩过的坑。

第四，让复杂任务变成固定流程。

比如我现在整理博客，经常是：

  1. 检查工作树。
  2. 读取临时文档。
  3. 复制和压缩图片/视频。
  4. 生成 Hexo Markdown。
  5. 本地构建。
  6. 本地预览。
  7. 等确认后再提交推送。

这就很适合做成 Skill，因为步骤稳定，而且漏一步就容易出问题。

第五，多场景复用。

一个 Skill 不一定只能服务一个项目。比如“文章整理 Skill”可以用于博客、公众号、周报；“代码审查 Skill”可以用于多个仓库；“图片处理 Skill”可以用于博客配图、README 截图、社媒素材。只要把“通用流程”和“项目特例”分开，就能复用。

先别想复杂：从一个对话型 Skill 开始

最简单的 Skill 不需要脚本，不需要工具链，甚至不需要特别规范。

你可以先把它理解为：把一段 Prompt 变成固定文件。

简单对话型 Skill

比如我们做一个“博客草稿整理 Skill”，目标是把临时笔记整理成 Hexo 博客文章。

目录大概这样：

1
2
blog-draft-cleaner/
└── SKILL.md

SKILL.md 可以先写成这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
---
name: blog-draft-cleaner
description: 整理中文博客草稿，适合把临时笔记、公众号草稿、项目记录改写成 Hexo 博客文章。用户提到整理文章、博客排版、临时笔记转博客时使用。
---

# 博客草稿整理流程

你负责把用户提供的中文草稿整理成 Hexo 博客文章。

## 基本要求

- 保留原文核心意思，不要为了润色改变事实。
- 可以适当口语化，让文章更像真实博客。
- 段落要短，标题层级清晰。
- 代码、命令、路径要用 Markdown 代码格式。
- 图片和视频必须复制到博客资源目录，不要引用临时目录。
- 写完后先本地构建和预览，不要主动推送，除非用户明确说可以推送。

## 输出结构

1. 生成一篇 Hexo Markdown 文章。
2. 补齐 front matter：title、date、categories、tags、cover。
3. 如果素材里有图片或视频，统一放到 `source/img/<slug>/`。
4. 最后给用户本地预览地址。

## 注意事项

- 不要提交 `tempbook/`。
- 不要把密钥、账号、数据库连接串写进文章。
- 如果原文涉及敏感信息，要先匿名化。

这就已经是一个 Skill 了。

它不高级，但有用。因为它把你平时反复说的话，变成了一个稳定流程。

实际例子：把“整理博客”变成 Skill

如果你想一步到位，可以直接复制下面这个 Prompt，让 AI 帮你生成第一版 Skill。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
我想创建一个自己的 Agent Skill，名字叫 blog-draft-cleaner。

用途：
把临时笔记、公众号草稿、项目复盘整理成 Hexo 博客文章。

我的习惯：
- 中文博客，口语一点，但不要太散。
- 可以润色，但不能改变核心意思。
- 图片和视频要复制到博客资源目录，不能引用临时目录。
- 视频可以适当压缩。
- 最后固定加公众号二维码。
- 先本地预览，确认后再提交推送。
- tempbook/、后端/、密钥配置不能提交。

请帮我生成一个符合 Agent Skills 格式的 SKILL.md。
要求：
1. 有 name 和 description。
2. description 要写清楚什么时候触发。
3. 正文要有步骤、注意事项、输出格式。
4. 给一个输入示例和输出示例。
5. 不要写得太泛，要贴近我的 Hexo 博客工作流。

生成后，你再让 AI 自查一次：

1
2
3
4
5
6
7
8
请检查这个 SKILL.md：
1. 是否过于宽泛？
2. description 是否能让 Agent 准确判断什么时候使用？
3. 有没有遗漏安全规则，比如不要提交 tempbook/、不要泄露密钥？
4. 是否有明确的构建和预览步骤？
5. 有没有可以删掉的空话？

请直接给我修改后的版本。

这两个 Prompt 基本就能做出第一版。

三步创建自己的 Skill

我建议普通人按这个顺序来，不要一上来就做复杂工程。

第一步：选一个高频场景

不要从“我要做一个万能 Skill”开始。

先找一个你经常重复的场景，比如：

  • 整理博客草稿。
  • 生成公众号文章。
  • 给代码做安全检查。
  • 把零散需求整理成开发任务。
  • 给图片生成统一风格提示词。
  • 写周报、日报、复盘。
  • 部署前检查 Git 状态和构建结果。

判断标准很简单：如果你已经连续三次对 AI 说过类似的话，这件事就值得做成 Skill。

可以用这个 Prompt 找场景：

1
2
3
4
5
6
7
8
9
10
11
请根据我最近经常让 AI 做的事情，帮我判断哪些适合做成 Skill。

请按表格输出：
- 场景名称
- 我重复说过的要求
- 是否适合做 Skill
- 适合做成简单对话型、流程型，还是深度工具型
- 第一版 Skill 应该包含哪些规则

我的零散场景如下：
<把你的场景贴在这里>

第二步：写一个最小可用的 SKILL.md

第一版只写三部分：

  1. 这个 Skill 是干什么的。
  2. 什么时候应该用它。
  3. 具体怎么做。

模板可以直接复制：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
---
name: your-skill-name
description: 一句话说明这个 Skill 做什么，以及用户说什么时应该使用它。
---

# 目标

你要帮助用户完成什么任务。

## 工作流程

1. 第一步。
2. 第二步。
3. 第三步。

## 用户偏好

- 偏好 1。
- 偏好 2。
- 偏好 3。

## 输出格式

请按下面格式输出：

```markdown
...
```

## 避免事项

- 不要做什么。
- 遇到什么情况必须先问用户。
- 哪些文件、配置、密钥不能碰。

注意 name 尽量用英文小写和连字符，比如：

1
2
3
4
blog-draft-cleaner
wechat-article-polisher
repo-review-checklist
image-prompt-maker

这不是审美问题，而是为了减少不同工具之间的兼容问题。Agent Skills 规范里也要求 name 使用小写字母、数字和连字符，并和目录名匹配。

第三步：用真实任务测试

不要写完就觉得完成了。

拿一个真实任务测试，比如：

1
2
请使用 blog-draft-cleaner Skill，整理 tempbook/xxx.md 为一篇博客。
先不要提交和推送，我本地审核后再说。

测试时重点看四件事：

  1. 它有没有正确触发。
  2. 它有没有漏步骤。
  3. 它有没有做你不想让它做的事。
  4. 它的输出是不是比纯聊天更稳定。

如果 AI 又犯了老错误，不要只在聊天里纠正一次，直接把这条纠正写回 Skill。

比如它忘了复制图片，就加：

1
2
3
4
## 常见坑

- 如果原文图片路径来自 tempbook/ 或其他本地临时目录，必须复制到 `source/img/<slug>/` 后再引用。
- 禁止在文章中直接引用 `E:\Work\...` 这类本机绝对路径。

这样 Skill 才会越用越像你。

简单开发、深度开发，有什么区别？

我自己的理解是，Skill 可以分三层。

1. 简单对话型

特点：

  • 只有一个 SKILL.md。
  • 主要是你的偏好、格式、流程。
  • 不需要脚本。
  • 最适合普通人入门。

适合：

  • 写作风格。
  • 周报格式。
  • 博客排版。
  • Prompt 生成。
  • 固定回复模板。

例子：

1
每次我说“整理成博客”，你都按我的 Hexo 博客规范处理。

2. 流程型

特点：

  • 有明确步骤。
  • 有检查点。
  • 可能需要读取文件、运行命令、生成结果。
  • 需要规定什么时候停下来等用户确认。

适合：

  • 本地构建和预览。
  • 发布前检查。
  • 项目初始化。
  • 数据清洗。
  • 多文件整理。

例子：

1
先检查 Git 状态，再整理文章，再复制素材，再构建预览，最后等我确认是否推送。

3. 深度工具型

特点：

  • 不只是一份说明书。
  • 会带 references/、assets/、scripts/。
  • 可以内置模板、校验脚本、示例输出。
  • 更像一个轻量工具包。

适合：

  • PDF/Word/Excel 批处理。
  • 固定 API 调用。
  • 图片批量处理。
  • 代码审查规则。
  • 部署和回滚流程。
  • 复杂内容生产流水线。

深度 Skill 的结构

深度开发当然更强，但它也更需要规范。否则 Skill 会从“帮你省事”变成“另一堆难维护的说明文档”。

深度开发是否需要开发规范？

需要，而且越深越需要。

简单 Skill 可以随手写，因为它只是帮你固定表达习惯。但只要进入下面这些情况，就应该有规范：

  • Skill 会读写文件。
  • Skill 会运行命令。
  • Skill 会处理真实业务数据。
  • Skill 会提交代码、部署、发邮件、调用 API。
  • Skill 需要多人共用。
  • Skill 会跨项目复用。

我建议至少遵守这些规则。

规则 1：先写边界

Skill 不只要写“做什么”，还要写“不做什么”。

比如：

1
2
3
4
5
6
## 边界

- 不主动推送远程，除非用户明确说“推送”。
- 不读取或打印密钥文件内容。
- 不删除用户文件。
- 遇到未提交改动，先报告并等待确认，或按项目规则先提交 checkpoint。

边界越清楚，AI 越不容易自作主张。

规则 2：先给默认方案，不要给一堆菜单

很多 Skill 写坏，是因为它把所有可能方案都列出来，让 AI 自己选。

更好的写法是：

1
2
默认使用 `npx.cmd hexo generate` 构建。
只有当项目不是 Hexo，或者命令不存在时，再根据 package.json 推断构建命令。

这比下面这种更稳：

1
你可以使用 hexo generate、npm run build、pnpm build、yarn build，根据情况选择。

AI 不是不能判断，而是你没必要让它在每次任务里重新判断。

规则 3：把真实踩坑写进去

Skill 最值钱的部分，不是“请遵循最佳实践”，而是这些具体到你项目的坑：

1
2
3
4
5
6
## 常见坑

- Windows 下使用 `npx.cmd`，不要直接调用 `npx`，避免 PowerShell 执行策略问题。
- `.bat` 文件如果包含中文，优先使用 GBK + CRLF。
- 博客素材必须放到 `source/img/<slug>/`，不能引用 tempbook。
- `public/` 是构建产物，不能提交。

这些东西 AI 可能不知道，但你知道。

规则 4：能校验就校验

只靠“请认真检查”不够。

如果能用命令验证，就写进 Skill：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
## 验证

完成文章后必须执行：

```powershell
npx.cmd hexo generate
```

然后检查生成页面里是否包含：

- 文章 slug。
- 图片路径。
- 视频路径。
- 公众号二维码路径。

对于更复杂的 Skill，可以把验证写成脚本放进 scripts/。

Agent Skills 的最佳实践里也强调：有效的 Skill 往往来自真实任务，并且要通过真实执行不断修正；复杂 Skill 可以用清单、模板、验证循环和脚本来提高稳定性。

一个更完整的 Skill 目录可以长这样

当你的 Skill 慢慢变复杂，可以从单文件升级成这样：

1
2
3
4
5
6
7
8
9
blog-draft-cleaner/
├── SKILL.md
├── references/
│   ├── hexo-blog-style.md
│   └── sensitive-info-rules.md
├── assets/
│   └── post-template.md
└── scripts/
    └── check-post-assets.ps1

各文件负责不同事情：

文件 作用
SKILL.md 核心流程和触发规则
references/hexo-blog-style.md 博客风格、标题习惯、排版规范
references/sensitive-info-rules.md 敏感信息处理规则
assets/post-template.md 文章模板
scripts/check-post-assets.ps1 检查图片、视频、二维码路径是否存在

注意：不要把所有东西都塞进 SKILL.md。

更好的做法是让 SKILL.md 保持短小，把不一定每次都需要看的资料放进 references/。这就是所谓的“渐进加载”：Agent 一开始只知道这个 Skill 是干什么的，真正需要时再读详细说明。

可复制 Prompt：让 AI 帮你从聊天记录提炼 Skill

如果你不知道从哪里开始，最好的材料就是你和 AI 的真实对话。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
请根据下面这段我和 AI 的真实协作记录，提炼一个可复用的 Agent Skill。

目标：
- 找出我反复强调的偏好。
- 找出 AI 容易犯错、我纠正过的地方。
- 找出稳定流程。
- 生成一个 SKILL.md。

要求：
1. 不要写泛泛而谈的最佳实践。
2. 必须把我的具体偏好写进去。
3. 必须包含“什么时候使用这个 Skill”的 description。
4. 必须包含“不要做什么”的边界。
5. 如果有文件路径、命令、输出格式，请保留成模板。

对话记录如下：
<粘贴你的对话记录>

这个 Prompt 特别适合把“你已经教过 AI 的东西”沉淀下来。

可复制 Prompt：让 AI 帮你评审 Skill

第一版 Skill 写完后，可以让 AI 做一次评审：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
请作为 Skill 评审员，检查下面这个 SKILL.md。

请重点看：
1. description 是否足够具体，能不能帮助 Agent 准确触发？
2. 这个 Skill 是否范围太大？
3. 有没有空话，比如“遵循最佳实践”“适当处理”？
4. 有没有明确输入、输出、步骤、验证？
5. 有没有写清楚安全边界？
6. 有没有应该拆到 references/ 或 scripts/ 的内容？

请输出：
- 主要问题
- 建议修改
- 修改后的 SKILL.md

内容如下：
<粘贴 SKILL.md>

可复制 Prompt：把简单 Skill 升级为深度 Skill

当一个 Skill 开始变长，可以让 AI 帮你拆结构：

1
2
3
4
5
6
7
8
9
10
11
12
我有一个单文件 Skill，现在越来越长。
请帮我把它升级成更规范的深度 Skill。

要求：
1. 保留一个精简的 SKILL.md，只放核心流程、触发规则、边界和验证。
2. 把详细风格规则拆到 references/style.md。
3. 把输出模板拆到 assets/template.md。
4. 如果存在可自动检查的步骤，请设计 scripts/validate.ps1 或 scripts/validate.py。
5. 给出最终目录结构和每个文件的完整内容。

原始 SKILL.md 如下：
<粘贴内容>

这个升级过程很像重构代码：不是为了显得专业，而是为了让它更好维护。

专属和个性化，才是 Skill 的核心

我觉得 Skill 最有意思的地方，不是“让 AI 会做某件事”，而是“让 AI 用你的方式做某件事”。

同样是写博客，你可能会要求：

  • 标题不要太营销。
  • 内容可以口语，但不要装。
  • 技术步骤要能复制。
  • 修改过原文哪里要告诉我。
  • 先本地预览，不要自动推送。
  • 文章末尾固定加公众号二维码。

这些偏好没有绝对对错，但它们构成了“你的工作方式”。

Skill 就是把这些工作方式固化下来。

它不一定要公开，也不一定要给别人用。很多时候，最有价值的 Skill 是非常私人的：它懂你的目录结构、写作习惯、部署流程、命名偏好和风险边界。

多场景适用：一个 Skill 可以怎么复用？

复用的关键是拆分层级。

比如“内容整理”可以拆成：

1
2
3
4
通用层：保留核心意思、结构清晰、段落短、不要编造。
平台层：Hexo 博客 / 微信公众号 / README / 周报。
项目层：图片目录、二维码路径、部署命令、Git 规则。
个人层：语气、标题偏好、哪些词少用、哪些步骤必须停下来确认。

这样你就可以做几个小 Skill，而不是一个巨大的万能 Skill：

  • draft-polisher：负责润色和结构。
  • hexo-post-builder：负责 Hexo 文章和资源路径。
  • wechat-draft-maker：负责公众号排版。
  • safe-publish-checker：负责提交前检查。

小 Skill 更容易复用，也更不容易互相打架。

我的建议：先做一个“笨但稳定”的 Skill

不要一开始就追求全自动。

第一版 Skill，最好笨一点：

  • 步骤写清楚。
  • 默认方案写清楚。
  • 哪些事不能做写清楚。
  • 需要用户确认的节点写清楚。
  • 验证命令写清楚。

等它稳定跑过几次，再考虑加脚本、模板、参考资料。

对普通人来说，Skill 的真正意义不是“开发一个复杂工具”，而是把自己已经摸索出来的经验沉淀下来。

如果你每次都要教 AI 一遍，那就说明这件事值得变成 Skill。

参考资料

如果你也在折腾 Codex、AI Agent、自动化工作流，欢迎关注我的公众号，后面会继续记录这些实践和踩坑。

公众号二维码