构建指南难度 1⏱ 32 分钟实践
01五分钟做第一个 Skill
用最短路径做出第一个可用 Skill，快速建立对 Skill 结构和使用方式的直觉。
Skill上手实战第一个 Skill
更新于 2026-04-11M01-五分钟做第一个Skill
从现成 Skill 出发做个性化改造，理解一个 Skill 是怎么一步步被改成自己需要的样子。
内容摘要
> 模块3：把Skill改成你自己的 | 用时：约30分钟 | 目标：掌握description触发机制、正文三要素、自由度设计、触发测试方法
模块3：把Skill改成你自己的 | 用时：约30分钟 | 目标：掌握description触发机制、正文三要素、自由度设计、触发测试方法
上节课咱们搞懂了 Skill 的底层原理——渐进式披露、和 MCP 的区别、为什么装 50 个也不卡。
但搞懂原理和真正用得顺手，中间还隔着十万八千里。
这节课我带你怎么把一个"能用"的 Skill，调成"好用"的 Skill。
说实话，我前两三个月写 Skill 的时候，真的崩溃过好多次。明明 Skill 写好了，AI 就是不用。或者用了，输出的东西跟我想要的差了十万八千里。后来我才慢慢摸索出来：改 Skill 其实就两个地方要动——description 控制"什么时候触发"，正文控制"输出什么质量"。
这两个东西搞明白了，你的 Skill 就从"凑合能用"变成"顺手好用"。
还记得模块 1 里咱们做的那个 Skill 吗？无论是周报、小红书还是 commit message，当时写完都觉得挺顺的。
但我后来做其他 Skill 的时候，真的崩溃过好多次。明明 description 写得挺好的，AI 就是不用。或者用了，出来的东西跟我想要的差了十万八千里。
比如我做过一个短视频脚本 Skill，description 写的是"生成短视频脚本"，结果测试的时候：
我心想：这不对啊，我明明写了格式要求的。
后来我折腾了好几天才搞明白——description 写得不对，AI 就不触发；正文写得不对，触发了输出也烂。
这节课就是手把手教你改这两个东西。我用三个不同类型的真实案例——公众号文章、短视频脚本、电商详情页——给你演示不同场景的调试方法。你照着走一遍，能省不少弯路。
当你输入一句话，AI 会做一件事：把你的话和所有 Skill 的 description 做语义相似度比较。哪个 description 和你的话最"像"，就触发哪个 Skill。
我打个比方。description 就像一本书的书名和简介。你去图书馆找书，不会翻开每一本看内容，而是扫一眼书脊上的标题。如果你的 Skill 叫"文案助手"，用户说"帮我写个小红书种草文"，AI 扫一眼——"文案"和"种草"语义上有交集，但不算强匹配，可能触发，也可能不触发。
这就是为什么 description 写得好不好，直接决定你的 Skill 能不能被用上。你在 description 上的投入，回报率是最高的。
我把触发问题分成两类：Under-trigger（该触发没触发） 和 Over-trigger（不该触发也触发了）。两种都很烦，但原因和修复方法完全不同。
Under-trigger 就是用户明明在说你的 Skill 相关的事，但 AI 没有匹配上。
举个我自己踩过的真实例子。我做了一个架构图生成 Skill，description 写的是：
"生成精美软件架构图。当用户需要画架构图时使用。"
我当时觉得写得挺好的。然后测试了一下：
四个测试只过了一个。问题出在哪？
**description 里只有"架构图"三个字，但用户不会每次都说"架构图"。**他们会说"系统设计"、"调用关系"、"技术方案"、"模块图"、"组件图"，说法五花八门。
我的 description 太窄了。说白了就像一个只认识一个名字的门卫，用户换个说法就进不来了。
Over-trigger 是反过来的——你的 Skill 太热情了，什么事都想揽。
我做过一个"社交回复助手"，description 写的是：
"帮你写回复。当用户需要回复消息时使用。"
结果呢？这些全部误触发了：
"回复"这个词太泛了，什么场景都有"回复"。我的 Skill 就像一个到处抢活干的同事，什么活都接，结果干的都不是自己的事。
我把一个真实案例的完整改写过程展示出来。假设我要做一个"电商详情页生成"Skill。
第一版（最原始）：
"写详情页。"
就这么三个字。我测试了一下，只有用户说"写详情页"的时候才触发。说"帮我做个产品页"就不触发。基本等于没用。
第二版（加了触发场景）：
"生成电商详情页。当用户需要写产品描述时使用。"
比第一版好了一点点，但问题依旧——"淘宝文案"、"商品介绍"这些说法还是触发不了。而且 AI 不知道输出什么格式，触发了也没用。
第三版（加更多触发词）：
"生成电商详情页。当用户需要写详情页、产品描述、淘宝文案时使用。输出包含主图卖点、痛点场景、解决方案、信任背书、行动号召。"
好多了。覆盖了"详情页"、"产品描述"、"淘宝文案"三种说法。但我测试的时候发现，用户说"帮我写个产品介绍页"还是不触发。"介绍页"太口语化了，我的 description 里没有这种说法。
第四版（最终版）：
"生成高转化率电商详情页。当用户需要写详情页、产品描述、淘宝文案、商品介绍、产品页文案，或者想生成卖点文案、做产品介绍、写种草文案时使用。输出结构：主图卖点（3-5个核心卖点）→痛点场景（用户痛点描述）→解决方案（产品如何解决）→信任背书（证书/评价/销量）→行动号召（购买引导）。适用于淘宝、京东、拼多多等电商平台。"
这一版我加了口语化的触发场景"卖点文案"、"种草文案"、"产品介绍"，还加了"商品介绍"、"产品页文案"等同义词。同时把输出结构也说清楚了（主图卖点→痛点场景→解决方案→信任背书→行动号召），还限定了"电商平台场景"。
测试结果：10 个相关提问触发了 9 个，5 个不相关提问只误触发了 1 个。能用。
你看，一个好的 description 不是一拍脑袋就能写出来的，它是改出来的。每一版你都能发现新的触发盲区，然后补上。好在这部分工作也可让AI代劳。
我总结出两种写 description 的策略，适用不同的场景。
如果你的 Skill 是专门解决一个特定问题的，比如"生成 Docker Compose 配置文件"，那就用精准狙击。
特点： 触发范围窄，只对特定领域生效，不容易误触发。
写法要点是"说清楚做什么 + 限定场景"。
"生成 Docker Compose 配置文件。仅在用户需要编写或修改 docker-compose.yml 时使用。支持多服务编排、网络配置、卷挂载。不适用于 Dockerfile 编写或容器运维操作。"
注意最后那句"不适用于 Dockerfile 编写或容器运维操作"。这是精准狙击的精髓——主动告诉 AI 你的 Skill 不干什么，把边界画清楚。
还有个例子：
"生成 GitHub Actions CI/CD 工作流。仅在用户需要创建或修改 .github/workflows 下的 YAML 配置时使用。支持 Node.js、Python、Java 项目。不适用于 Jenkins、GitLab CI 等其他 CI 工具。"
同样是"做什么"加上"不做什么"，边界非常清晰。你把它想象成给 AI 画了一个圈——圈内的归我管，圈外的别来烦我。
如果你的 Skill 适用范围广，比如"写作助手"、"翻译助手"，那就用触发词轰炸。
特点： 触发范围宽，把用户可能说的各种说法都写进去，确保不遗漏。
"帮助用户进行各类文案写作。当用户需要写文章、写作、写文案、写稿、写推文、写笔记、写帖子、写内容、写宣传语、写广告语、写软文、写种草文、写分享文时使用。支持小红书、微信公众号、微博、知乎等平台风格。"
看到没？光"写"这个动作我就列了十几种说法。用户不管说"帮我写个帖子"还是"来篇种草文"还是"写个推广文案"，全都能命中。
再给一个例子：
"帮助用户翻译文本。当用户需要翻译、中翻英、英翻中、中译英、英译中、把中文翻译成英文、把英文翻译成中文、translate、查看翻译、对比翻译时使用。支持中英、中日、中韩互译。"
这里连"中翻英"和"中译英"都分开写了。因为 AI 做语义匹配的时候，"翻"和"译"是不同的词，分开了命中率更高。
**我的经验是：通用型 Skill 的 description 宁可多写不能少写。**你有 1024 个字符的额度，不用白不用。我自己的通用型 Skill，description 基本都写满了。
description 决定了 Skill 会不会被触发，正文决定了触发之后输出什么。
正文写不好，就会出现上面那种情况——触发了，但输出一坨糊糊。
我把正文拆成三个要素：操作步骤、输出格式、反模式。三个都写到位了，输出质量才有保障。
操作步骤就是给 AI 一个明确的执行顺序。没有步骤，AI 就会"想到哪写到哪"。
我见过很多人写正文的时候，就把要求堆在一起，没有先后顺序。比如：
## 写作要求
- 写一篇小红书笔记
- 用 emoji 开头
- 口语化风格
- 300-500 字
- 加 3-5 个标签
这种写法不是不能用，但 AI 有可能先写标签再写正文，或者把 emoji 放在结尾。加了步骤顺序就不一样了：
## 操作步骤
1. 先根据用户给的主题，构思一个有吸引力的标题
2. 然后写正文，遵循下面的写作风格
3. 最后添加标签和互动引导语
就这么简单——"先、然后、最后"。AI 有了顺序，输出就会稳定很多。
我再给一个非写作类的例子。假设你在做一个"代码审查"Skill：
## 操作步骤
1. 先阅读用户提交的代码，理解这段代码在做什么
2. 逐项检查：命名规范、逻辑错误、性能问题、安全隐患
3. 按严重程度分级输出问题列表（严重 → 警告 → 建议）
4. 对每个问题给出修改建议和示例代码
5. 最后给出整体评价和改进方向
五步走，清清楚楚。AI 不会跳步，不会漏项。
输出格式就是告诉 AI "我要的东西长什么样"。不给格式，AI 就用自己的默认格式，而 AI 的默认格式通常不是你想要的。
我举个 PRD 的例子。如果只写了"生成 PRD"，没有规定格式，AI 就输出了一整篇不带分段的纯文本。后来在正文里加了格式模板：
## 输出格式
### 需求背景
2-3 句话说清楚为什么要做这个功能。
### 目标用户
一段话描述这个功能是给谁用的。
### 用户故事
按以下格式写 3-5 条：
- As a [角色], I want [功能], so that [价值]
### 功能需求
用表格列出：功能点 | 优先级 | 描述
### 验收标准
用表格列出：验收条件 | 预期结果
加了这模板之后，输出立刻从"一坨文字"变成了结构清晰的文档。AI 不是不会写结构化文档，是你要告诉它你要什么结构。
再给一个详情页的格式模板：
## 输出格式
### 主图卖点（必填）
- [ ] 卖点一：核心卖点一句话（突出差异化）
- [ ] 卖点二：功能卖点一句话
- [ ] 卖点三：情感卖点一句话
### 痛点场景（必填）
- [ ] 场景一：描述用户遇到的痛点
- [ ] 场景二：痛点带来的困扰
### 解决方案（必填）
- [ ] 方案描述：产品如何解决上述痛点
- [ ] 核心功能：1-2个核心功能点
### 信任背书（选填）
- 证书/检测报告/用户评价/销量数据
### 行动号召（必填）
一句话购买引导，带紧迫感。
方括号让格式一目了然，AI 照着填就行。
反模式是三个要素里被忽视最多的，但它可能是提升输出质量最快的方法。
为什么反模式这么重要？因为 AI 有很强的"默认行为"。你让它写文章，它默认写书面语。你不明确告诉它"不要做"，它就会按默认来。
我举个例子。我做一个"朋友圈文案"Skill，正文里写了"口语化、轻松、自然"。结果 AI 输出：
今天心情非常愉悦，和大家分享一下我最近的生活。
首先，我要说的是，这家餐厅真的非常好吃...
"非常愉悦"、"首先，我要说的是"——这还是书面语啊。我加了反模式之后：
## 反模式
| 不要这样做 | 症状 | 怎么改 |
|-----------|------|--------|
| 结构词堆砌 | "首先""其次""最后" | 直接说事，不要过渡 |
| 程度副词滥用 | "非常""十分""极其" | 删掉，或用"挺""蛮" |
| 书面语腔调 | "笔者认为""综上所述" | 换成"我觉得""说白了" |
| 华丽修辞 | 排比句、对仗句 | 短句，一行一个意思 |
| 长段落 | 超过 3 行 | 强制换行，留空白 |
再测试，AI 的输出变成了：
昨晚被朋友拉去吃了一家泰料，绝了 🤤
冬阴功汤酸到上头，咖喱鸡浓到可以拌两碗饭
地址放评论区了，冲！
区别非常大。**写"做什么"是描述一个无限大的可行域，写"不做什么"是在可行域上画边界。**反模式就是帮 AI 打破它的默认行为。
光说原理不够，我拿三个不同领域的例子完整展示一遍怎么改正文。
改之前：
生成 API 接口文档。
三个字。输出可想而知——AI 自己发挥，格式不统一，该有的字段没有，不该写的写了一堆。
改之后：
## 操作步骤
1. 根据用户提供的接口信息，确定请求方法和路径
2. 按照标准 RESTful 格式生成文档
3. 对每个字段标注类型、是否必填、默认值
4. 提供请求和响应示例
## 输出格式
### [方法] [路径]
**描述**：一句话说明这个接口做什么。
**请求参数**：
| 参数名 | 类型 | 必填 | 默认值 | 说明 |
|--------|------|------|--------|------|
**响应示例**：
```json
{ "code": 200, "data": {}, "message": "success" }
错误码：
| 错误码 | 说明 |
|---|
改完之后，每次输出的接口文档格式统一、字段齐全，直接能用。
#### 实例二：中自由度案例——电商详情页生成 Skill
**改之前：**
```markdown
生成电商详情页文案。
AI 输出的文案要么卖点不清晰，要么结构混乱，要么没有转化引导，看完不知道怎么用。
改之后：
## 操作步骤
1. 分析用户提供的产品信息，提炼3-5个核心卖点（差异化优先）
2. 根据产品类型，构建对应的痛点场景（2-3个用户痛点）
3. 撰写解决方案部分，突出产品如何解决问题
4. 添加信任背书（证书、评价、销量等）
5. 最后写行动号召，带紧迫感
## 输出格式
### [产品名] 详情页文案
**主图卖点**
- 卖点1：[核心卖点] — [一句话解释]
- 卖点2：[功能卖点] — [一句话解释]
- 卖点3：[情感卖点] — [一句话解释]
**痛点场景**
- 场景1：[用户痛点描述]
- 场景2：[痛点带来的困扰]
**解决方案**
[产品如何解决痛点，2-3句话]
**信任背书**
[证书/评价/销量数据，1-2点]
**行动号召**
[带紧迫感的购买引导，1句话]
## 反模式
- 不要堆砌功能参数，要突出用户收益
- 不要写"质量很好"这种空话，要具体
- 不要忽略行动号召部分
- 不要输出超过500字
改完之后，详情页有了清晰结构，卖点突出，转化路径完整。直接能用。
改之前：
生成面试问题。
AI 输出的问题要么太简单（"你的优点是什么"），要么太泛（"说说你的项目经历"），完全不能用。
改之后：
## 操作步骤
1. 确认岗位类型和级别（根据用户输入判断）
2. 按以下维度各生成 2 个问题：技术能力、项目经验、沟通协作、问题解决、文化匹配
3. 每个问题附带考察点和评分标准
4. 标注问题难度（初级/中级/高级）
## 输出格式
### [岗位名称] 面试题库
#### 技术能力
**Q1：[问题]**
- 难度：[级别]
- 考察点：[具体考察什么]
- 好的回答包含：[要点 1、要点 2、要点 3]
- 差的回答特征：[什么表现说明不行]
#### 项目经验
（同上格式）
## 反模式
- 不要出"你的优缺点是什么"这种烂大街的问题
- 不要出纯理论题，必须是场景化问题
- 不要一次生成超过 15 个问题
- 不要忘记标注考察点
改完之后，每个问题都有明确的考察目的，面试官拿来就能用。
不是所有 Skill 都该写得一样详细。有些任务你得把步骤写死，有些反而应该给 AI 留发挥空间。
Extra08 提出了一个自由度光谱的概念：
任务越脆弱（容易出错） → 自由度越低 → 用脚本锁死
任务越灵活（多种方案都对） → 自由度越高 → 用文字引导
| 自由度 | 实现方式 | 适用任务 | 示例 |
|---|---|---|---|
| 高 | 文字指令 | 多种方法都可行，依赖上下文 | 写作风格、创意生成 |
| 中 | 模板+参数 | 有最佳实践但允许变通 | 报告生成、代码审查 |
| 低 | 具体脚本 | 操作脆弱容易出错，必须精确 | 部署脚本、数据处理 |
做错了最多文案不好看，不会出大事。
## 写作风格
- 口语化，像跟朋友聊天
- 短句为主，每段不超过 3 行
- 卖点突出，避免参数堆砌
不给具体步骤，只给风格和原则。AI 在框架内自由发挥，输出更自然。
大多数 Skill 属于这一类。核心步骤固定，细节让 AI 自己决定。详情页就是典型例子——有固定的5步结构（主图卖点→痛点场景→解决方案→信任背书→行动号召），但每个部分的内容可以根据产品灵活调整。
## 操作步骤
1. 先分析用户提供的产品信息（固定）
2. 按照5步结构生成详情页（固定框架，具体内容 AI 自行判断）
3. 确保每个部分都有转化引导（固定要求）
4. 根据产品类型调整语言风格（具体风格 AI 自行判断）
步骤 1 和 3 是死的，步骤 2 和 4 是活的。
做错了后果严重，比如部署脚本、删除数据。
## 数据库迁移操作步骤（严格按顺序执行）
1. 先执行数据备份命令
2. 确认备份文件存在且大小 > 0，否则停止操作
3. 在测试环境执行迁移脚本
4. 检查测试环境数据完整性
5. 以上四步全部通过后，在生产环境执行迁移
## 安全限制
- 任何时候都不要跳过备份步骤
- 不要使用 DROP、TRUNCATE 等危险语句
每一步都是确定性的，AI 没有发挥空间。多写 10 行指令，比数据库被删了强一万倍。
写完 Skill 不能拍拍屁股走人。你得测试。不测试就上线，等于不试穿就买鞋。
我设计测试用例的方法很简单：5 个该触发的 + 5 个不该触发的。
10 个用例，不多不少，够用了。
这 5 个问题不能都是同一种问法。我一般这么设计：
五种问法覆盖了用户真实使用时的各种可能。如果一个 Skill 这五种都能触发，基本就稳了。
这 5 个问题的设计思路是"挑那些和你的 Skill 容易混淆的场景"。
比如你的 Skill 是"电商详情页生成"，那容易混淆的就是：
如果你发现这 5 个不该触发的问题中有 2 个以上误触发了，说明你的 description 太宽了，需要加限制条件。
测试完 10 个问题之后，我按这个思路分析：
如果该触发的 5 个问题里，有 2 个以上没触发。
这说明 Under-trigger 了。回去看 description，把没触发的那些问法的关键词补进去。比如"帮我推荐个平价面膜"没触发，就在 description 里加"推荐"、"种草"、"平价好物"这些词。
如果不该触发的 5 个问题里，有 2 个以上误触发了。
这说明 Over-trigger 了。在 description 里加排除条件。比如"帮写商务邮件"误触发了，就加一句"不适用于商务邮件、正式信函等职场写作场景"。
如果触发了但输出不对。
这说明 description 没问题，正文有问题。回去改正文，加格式要求或反模式。
如果有时触发有时不触发。
这通常是 description 里的措辞不稳定。同一个意思，"写笔记"和"写一篇笔记"匹配度可能不一样。我的做法是把所有同义词都写进去，不依赖单一措辞。
我一般调三轮。不是因为我闲，是因为两轮经常不够。
第一轮：粗调。
把 description 和正文写好，跑 10 个测试用例。记录哪些通过、哪些失败。
第二轮：根据结果修补。
第一轮没通过的用例，针对性修改 description 或正文。改完之后再跑一遍全部 10 个用例。注意，这里有个坑——改了一个地方可能会影响其他用例，所以要全跑一遍，不是只跑失败的。
第三轮：边界测试。
找几个"模棱两可"的问题测试。比如你的 Skill 是"电商详情页生成"，试试"帮我写个产品测评发网上"——这到底该不该触发？如果触发了，输出质量行不行？
这种边界问题没有标准答案，但你需要知道你的 Skill 在边界情况下的表现，才能决定要不要进一步调整。
我把"电商详情页生成"的完整测试过程写出来，你看一遍就懂了。
初始 description：
"生成电商详情页。当用户需要写产品描述时使用。"
第一轮测试结果：
该触发的 5 个：
不该触发的 5 个：
5/5 该触发的只过了 1 个，5/5 不该触发的误触发了 4 个。惨不忍睹。
问题分析：
"产品描述"这个词太泛了，什么场景都在用。我需要把范围缩窄到电商转化场景，同时把各种口语化的说法加进去。
修改后的 description：
"生成高转化率电商详情页文案。当用户需要写详情页、淘宝文案、产品页、种草文案、卖点文案，或者想生成产品介绍、电商文案、转化文案时使用。输出包含主图卖点、痛点场景、解决方案、信任背书、行动号召。不适用于产品评测、使用说明、品牌宣传、活动策划等场景。"
第二轮测试结果：
该触发的 5 个全部触发了。不该触发的 5 个里面，"写一份品牌宣传文案"还是误触发了——因为"文案"这个词在我的触发词里没有明确排除。
再次修改：
在"不适用于"后面加了"纯品牌宣传、非转化类文案"。
第三轮测试：全部通过。
这个案例说明一件事：一轮改好是运气，三轮通过才是质量。
这是 Skill 和提示词最本质的区别。提示词只能描述，Skill 可以封装资源。
| 目录 | 内容 | AI 怎么用它 | 典型场景 |
|---|---|---|---|
scripts/ | 可执行代码（Python/Shell） | 调用执行，读取输出 | 精确计算、数据处理、API 调用 |
references/ | 参考文档（Markdown/txt） | 按需读取，指导输出 | 长文档拆分、多平台规范、schema 定义 |
assets/ | 模板文件（Excel/PPT/图片） | 复制修改，直接使用 | 报告模板、品牌素材、配置文件 |
AI 擅长理解和组织信息，但不擅长精确计算和格式控制。
什么时候必须用脚本：
示例：PDF 旋转任务
SKILL.md 只写：调用 scripts/rotate_pdf.py input.pdf 90
scripts/rotate_pdf.py：实际的 PDF 处理代码
AI 不需要理解 PDF 旋转算法，只需要知道"什么时候调用这个脚本"。
当你的 SKILL.md 正文超过 5000 tokens，就该考虑拆分。
三种拆分模式：
模式 1：高层指南 + 参考文件
## 高级功能
- 表单填写：详见 [FORMS.md](references/FORMS.md)
- API 参考：详见 [API.md](references/API.md)
模式 2：按领域组织
references/
├── finance.md # 财务指标
├── sales.md # 销售数据
└── product.md # 产品分析
用户问销售问题时，AI 只读 sales.md。
模式 3：多平台内容
## 平台选择
- 微信公众号：加载 [wechat-style.md](references/wechat-style.md)
- 小红书：加载 [xhs-style.md](references/xhs-style.md)
AI 不需要"读懂"这些文件，只需要知道"什么时候放进去"。
典型用途：
assets/report-template.xlsx → 生成报告时复制，填入数据assets/product-image-template.psd → 生成详情页时参考产品图排版assets/prd-template.docx → 按模板格式输出 PRD提示词只能"说"："请按这个格式写"
Skill 可以"做"：
scripts/analyze.py 精确分析references/schema.md 了解表结构assets/template.xlsx 生成报告这是 Skill 超越提示词的核心能力。
最后分享几条我在改 Skill 过程中总结的经验。这些不是什么高深的理论，就是踩坑踩出来的。
关于 description：
关于正文：
关于调试：
改 Skill 这件事，本质上就是和 AI 沟通的过程。**你写得越清楚，AI 就越能给你想要的东西。**最开始可能要改好几轮，但改熟练了之后，一次就能写个八九不离十。
下一个模块我们会上一个台阶——不是改别人做好的 Skill，而是从头设计一个复杂的 Skill。到那时候你会用到这个模块里所有的技巧：精准的 description、完整的正文三要素、合理的自由度设计。这些基本功练扎实了，后面做复杂 Skill 才不会手忙脚乱。
咱们，下节课见。
优先展示同分类且标签更接近的内容，方便继续串联学习。
用最短路径做出第一个可用 Skill，快速建立对 Skill 结构和使用方式的直觉。
从需求、结构、描述和规则设计出发，独立完成一个属于自己的 Skill。