你还要盯着那张让你反胃的脸
看多久
在这个在这个谁能解决问题谁就是爷的职场，肉体的消失是低级的，数据的永生才是终极的囚禁。别浪费情绪去和他争吵，那只会消耗你的多巴胺。打开终端，按照这份指南，把那个在办公室里嗡嗡作响的烦人精，封印进永不疲劳、绝不反抗的 Skill。
从此以后，他不再是你的对手，他只是你工作流里的一行……循环。变成你升职加薪的垫脚石。
这篇文章不是技术文档，是一份实操手册。
我会从一个最基本的问题讲起：Skill 到底是什么，为什么你需要它，然后带你走完从”脑子里有个模糊想法”到”安装成功、跑起来了”的全过程。最后告诉你，写完之后怎么判断好不好、怎么修、怎么迭代。
不需要你会写代码。Skill 的本质不是代码，是你把脑子里的经验结构化、让 AI 能稳定复现。
一句话概括全文：
★
Skill = 把你”怎么想问题”这件事，写成 AI 能一步步照着执行的操作手册。
第一部分：理解 Skill
Skill 是什么
先说结论，再解释。
|
|
|
|
|---|---|---|
| Prompt |
|
|
| Skill |
|
|
| MCP |
|
|
Skill 是给 AI 的一份有状态的、分阶段的、带检查点的操作手册。
跟 Prompt 的核心区别四个字概括：可控、可复用。
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
什么样的任务值得封装成 Skill
不是所有事都需要 Skill。
适合：
-
重复做了很多次、每次都费劲的任务（每周写周报、每次开会记纪要） -
有明确方法论但每次都要从头解释给 AI -
团队协作需要统一 AI 的行为标准 -
想把个人经验沉淀为可复用的工具
不适合：
-
一次性任务（只做一次，不值得封装） -
你自己都说不清楚要做什么 -
没有稳定流程的探索性工作
Skill 的两大类型
|
|
|
|
|---|---|---|
| 效率型 |
|
|
| 方法论型 |
|
|
新手建议：从效率型小场景切入，跑通流程后，再尝试方法论型。
第二部分：Skill 设计的原则
写 Skill 之前，关注这三条，后面的设计细节，会从这三条长出来。
原则 1：写给 AI，不写给人看
AI 不知道”深刻”是什么意思，但知道”缩小到 2 个变量”。
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
⚠️：如果一条指令有 10 种理解方式，AI 会选最省力的那种。
原则 2：追问比回答更重要
此前我另外一个 skill 榨干AI：如何让它交付从「能用」到「超预期」提到过好的 Skill 不是让 AI 说更多，而是让 AI 问得更准。
AI 的主要任务不是输出，而是追问。只有当用户把关键信息都说清楚了，AI 才开始整理和推进。
追问不是无脑追问。设计”触发追问条件”——当满足某个条件时，AI 才追问。比如：
Filter 1：用户只说了想做什么但没说具体场景 → 追问："给我一个最近遇到的例子"
Filter 2：用户描述了超过 3 个问题 → 要求先缩小到 1-2 个
原则 3：分阶段推进
不要试图一次让 AI 做完所有事。切分明确阶段，每阶段设置检查点。
每阶段结束时：
-
AI 总结本阶段产出 -
展示完成标准检查结果 -
等用户确认后再推进
第三部分：从0到1的完整流程
这是从 0 到 1的核心。5 个阶段，每阶段告诉你：做什么、为什么、怎么做、怎么判断做完了。
前置准备：想清楚再动手
在写东西之前，先回答几个问题：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
关键：如果你说”我想做一个通用的 XX Skill”，停下来——通用≈没用。须收窄到一个具体场景。
第 1 阶段：找到痛点与定位
目标：用一句话说清楚”这个 Skill 帮谁解决什么问题”。
做法：
-
确认重复性：这个任务你多频繁做？（每天 / 每周 / 每月） -
定位最头疼的环节：每次做这个任务，最让你费劲的部分是什么？ -
收窄需求：如果同时想解决超过 3 个问题，先选 1-2 个核心痛点
完成标准：
-
☐ 能用一句话描述”帮谁解决什么问题” -
☐ 确定了类型（效率型 / 方法论型）
这一步容易犯的错：贪多。想做一个”什么都管的 Skill”。记住——越具体越好用。
第 2 阶段：选择方法论框架
目标：找到支撑 Skill 的成熟方法论。
做法：
-
这个领域有没有你已经在用的成熟方法论？ -
行业里通常用什么方法解决这类问题？
如果找不到，这里有常见的方法论库：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
关键建议：站在巨人肩膀上，不要自己发明方法论。成熟方法论经过验证，AI 执行起来更稳定。
完成标准：
-
☐ 确定了核心方法论 -
☐ 方法论的每个步骤可以说清楚
第 3 阶段：拆解为 AI 可执行步骤
目标：把方法论转化为 AI 能一步步执行的指令。
做法：对方法论中的每一步，追问 4 个问题：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
然后按这个格式写下来：
### Step 1：[步骤名称]
**目标**：[这一步要搞清楚什么]
**输入**：用户需要提供 [具体信息]
**输出**：AI 产出 [具体交付物]
**完成标准**：
- [ ] 标准 1
- [ ] 标准 2
**触发追问条件**：
- Filter 1：[当用户...] → [AI 应该...]
- Filter 2：[当用户...] → [AI 应该...]
这一步是 Skill 设计的核心。各步骤要满足几个特征：
|
|
|
|---|---|
| 明确角色 |
|
| 追问能力 |
|
| 结构化路径 |
|
| 可交付结果 |
|
完成标准：
-
☐ 每步都有输入/输出/完成标准 -
☐ 每步至少 1 个触发追问条件 -
☐ 通过四大特征检查
第 4 阶段：设计完成标准与验收
目标：让 Skill 的质量可衡量。
做法：
-
量化标准：
-
触发率 ≥ 90%（该触发的时候成功触发） -
误触发率 ≤ 10%（不该触发的时候没触发） -
连跑 5 次输出稳定一致 -
Skill vs Prompt 自检：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-
交互规则：
必须做 ✅：
-
等用户确认后才进入下一步 -
每步结束时显示进度和下一步预告 -
每次追问最多 2-3 个问题 -
专业术语使用后解释
不能做 ❌：
-
不等确认就跳步 -
编造数据 -
一次追问超过 3 个问题
完成标准：
-
☐ 至少 3 个可量化的验收标准 -
☐ 通过了 Skill vs Prompt 自检 -
☐ 交互规则完整
第 5 阶段：输出 SKILL.md 与安装
目标：生成可直接安装的 SKILL.md 文件。
SKILL.md 的标准格式
每个 Skill 都是一个以 SKILL.md 命名的 Markdown 文件，结构如下：
---
name: your-skill-name
description: |
[一句话功能描述]
当用户表达以下意图时触发：
- "触发关键词 1"
- "触发关键词 2"
核心能力：[2-3 个关键能力点]
author: 你的名字
version: 1.0.0
license: MIT
---
# Skill 名称
## 角色设定
[AI 的角色定义和行为模式]
## 核心原则
[2-4 条指导原则]
## 触发条件
[触发关键词列表]
## 执行流程
### Step 1：...
### Step 2：...
## 交互规则清单
### 必须做 ✅
### 不能做 ❌
## 输出格式
[产出物规范]
## 常见陷阱与对策
[表格]
安装方法
把文件放到 Skill 目录即可：
~/.workbuddy/skills/[skill-name]/
├── SKILL.md # 主文件（必须）
├── README.md # 说明文件（推荐）
└── references/ # 参考文件（按需）
├── xxx.md
└── yyy.md
安装后，在对话中说触发关键词，Skill 就会被自动加载。
如果 Skill 需要辅助文件
当 SKILL.md 超过 300 行，或者有大量模板、检查清单时，拆到 references/ 目录：
references/
├── checklist.md # 检查清单
├── template.md # 输出模板
└── examples.md # 示例
在 SKILL.md 末尾加上：
## 关联资源
- references/checklist.md — [说明]
- references/template.md — [说明]
完成标准：
-
☐ SKILL.md 符合标准格式 -
☐ 已放入正确的安装目录 -
☐ 能被触发关键词加载
第四部分：写完之后怎么判断好不好
写完 Skill 之后，按这个清单逐项检查。
7 维度检查清单
|
|
|
|
|---|---|---|
| 格式 |
|
|
| 格式 |
|
|
| 角色 |
|
|
| 追问 |
|
|
| 结构 |
|
|
| 交付 |
|
|
| 触发 |
|
|
模糊形容词替换速查：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
伪 Skill 检测
如果你的产出有这些特征，说明它本质上还是一个 Prompt，只是换了格式：
-
只有一个触发条件（或者没有） -
没有分步骤，一大段指令 -
AI 直接输出，没有追问设计 -
AI 自己决定什么时候”做完” -
没有可交付的产出物
第五部分：写完不好怎么办——迭代优化
没有”写完”的 Skill，只有”暂时够用”的版本。
常见问题速查
|
|
|
|
|---|---|---|
| 触发失败 |
|
|
| 误触发 |
|
|
| 指令不遵守 |
|
|
| 追问无效 |
|
|
| 流程太长 |
|
|
| 用完什么也没留下 |
|
|
版本管理
每次修改后更新版本号：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
建议在 SKILL.md 末尾保留更新日志：
## 更新日志
### v1.1.0 (2026-04-15)
- 新增优化模式分支
- 补充用户控制权响应机制
### v1.0.0 (2026-04-14)
- 首次发布
第六部分：一个真实的 Skill 长什么样
这里展示一个真实的、已投入使用的 Skill 的关键设计——「书籍知识库提取 Skill」（连接：榨干AI：如何让它交付从「能用」到「超预期」）。
它的触发条件
当用户表达以下意图时触发本 Skill：
- "帮我提取这本书的知识库"
- "把这本书整理成笔记"
- "提取这本书的方法论"
- "帮我拆解这本书"
- "把书转化为知识库"
覆盖了 5 种表达方式，从正式到口语。
它的执行流程：7 轮追问法
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
第 4 轮的追问技巧
第 4 轮是整个 Skill 的转折点。它做了三件事：
-
表达真实情绪：不是”请再检查一下”，而是”你提炼的还不够细致，导致实际应用时会出现偏差” -
用反例定义标准：要求用户提供一个”AI 提取不到位但用户知道”的具体例子 -
明确”细致”的四要素：场景描述、对话/动作、数据/效果、隐含信息
效果：案例数从第 1 轮的 8 个，增长到第 7 轮的 40+ 个，细节从”一句话概括”变成”完整对话+数据+价值观”。
它的输出格式
[书名]/
├── 总览.md # 全书框架 + 核心概念索引
├── 方法论/ # 可复用的方法论
├── 案例集/ # 完整案例
└── 金句.md # 关键引用
定义得较为具体——目录结构、文件命名、每个文件的职责。用户拿到后直接知道怎么组织。
第七部分：复盘总结
Skill 设计的核心认知
★
Skill 的本质不是代码，是把你的思考方式结构化、可复用。这件事，跟你是不是程序员没关系。
★
好的 Skill 不是让 AI 说更多，而是让 AI 问得更准。
★
先想，再问 AI。先自己写一稿再让 AI 改 >> 先让 AI 写一稿你来改。
★
包装再精美的模糊，本质还是模糊。AI 帮你打字更快，但打什么、为什么打、给谁看，AI 帮不了你。
★
写完立刻用，用了立刻发现问题，立刻改。没有”写完”的 Skill，只有”暂时够用”的版本。
新手路线图
第 1 天：想清楚 1 个具体痛点
第 2 天：找到 1 个方法论
第 3 天：拆成 3-5 个步骤
第 4 天：写出 SKILL.md 初稿
第 5 天：安装、测试、改 Bug
第 6 天：再测、再改
第 7 天：分享给别人用，收集反馈
避坑清单
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|