摘要：很多人以为做 Agent Skill 需要写代码、调 API、搞部署，实际上完全不需要。Skill 的本质就是一个 .md 文件，用自然语言写清楚工作流程和约束规则就行。本文以一个会议纪要整理 Skill 为例，手把手走一遍从需求梳理到测试上线的完整流程，拆解 5 种常见的 Skill 设计模式，总结让 Skill 从「能用」到「好用」的核心原则。最后聊聊做完自己的 Skill 之后，怎么在 20 万+ 的 Skill 市场里找到别人做的好 Skill。

适用人群：想用 Agent 提效但没有编程经验的普通用户，以及刚接触 Skill 生态的开发者

---

一、先破一个误解：Skill 不是代码

如果你还没做过 Skill，大概率对它有一个错误认知——觉得它是一段程序，需要写 Python、调接口、搭服务器。

不是的。

一个 Agent Skill 的核心就是一个 .md 文件（markdown 文件），你在里面用自然语言写清楚三件事：

1. 这个 Skill 干什么（任务目标）
2. 输入输出长什么样（数据格式）
3. 有什么注意事项（约束规则）

保存，完了。没有编译，没有部署，没有依赖安装。

你可以把它理解成一份特别详细的「工作交接文档」。你把自己干某件事的方法、标准、注意事项全部写下来，交给 AI，AI 就会按照你写的方式去执行。

它采用「按需加载」机制——Agent 不会一次性加载所有 Skill 的完整内容（上下文窗口放不下），而是在接到任务时，先扫描所有 Skill 的名称和描述，判断哪个跟当前任务有关，只加载相关的那个。所以你装很多 Skill 也不会浪费资源，Agent 只在需要的时候才去读取对应的 Skill 内容。

---

二、手把手做一个：会议纪要整理 Skill

光讲概念没用，我们直接做一个。

场景

你们团队每周开会，开完之后需要有人把会议内容整理成纪要，提炼要点，列出待办。这个活以前你自己做，每次少说半小时。现在我们把它做成一个 Skill，以后丢给 Agent 两分钟搞定。

第一步：明确核心问题

先想清楚一件事：这个 Skill 只解决一个什么问题？

第一版不要贪多。不要上来就想做一个「全能会议助手」，又要整理纪要、又要分析会议效率、又要自动排下次会议日程。

第一版就做一件事：把会议内容整理成格式规范的纪要，包含讨论要点和待办事项。

第二步：梳理需求细节

问自己几个问题：

输入是什么？      → 会议录音的文字转写稿（或者手动输入的会议要点）
输出是什么？      → 结构化的会议纪要
输出格式要求？    → 按议题分段，每个议题包含讨论要点和结论
待办怎么列？      → 每条待办标注负责人和截止时间
什么情况下会出错？ → 多个议题交叉讨论时容易混在一起

这一步特别重要。你不梳理清楚，写出来的 Skill 就是一个模糊的指令，AI 按自己理解来做，结果跟你预期对不上。

第三步：写 Skill 文件

打开一个新的 .md 文件，开始写。我直接给一个可以参考的骨架：

# 会议纪要整理 Skill

## 任务目标
根据用户提供的会议文字稿，整理成结构化的会议纪要。

## 输入
- 会议文字转写稿（可以是粗略的、口语化的）

## 输出格式
### 会议基本信息
- 会议主题
- 参会人员
- 会议时间

### 讨论内容
按议题分段，每个议题包含：
- 议题名称
- 关键讨论要点（不超过 5 条）
- 结论或决策

### 待办事项
每条待办包含：
- 事项内容
- 负责人
- 截止时间

## 约束规则
- 如果会议中多个议题交叉讨论，按时间线拆分，不要按议题强行归类
- 如果某个待办没有明确指定负责人，标注为「待确认」，不要自己编一个
- 如果会议中出现了分歧但没有达成结论，在该议题下标注「未达成一致，待后续讨论」
- 讨论要点只提炼关键信息，不要复述原文
- 不要添加会议中没有出现的内容

你看，全程自然语言，不需要写一行代码。

这里最核心的部分是约束规则。你告诉 AI「不要做什么」比「做什么」更重要。因为 AI 容易犯的错误就是过度发挥，约束条件能帮它守住边界。

第四步：测试和迭代

写完之后，拿一段真实的会议文字稿去测。

这里有一个关键原则：一定要用真实数据，不要用你随手编的测试数据。 编造的测试数据往往结构太干净、表述太规范，覆盖不到真实场景中的那些脏数据和边界情况——比如有人说话说一半被打断了、两个议题交叉讨论了五分钟、某个待办说了但没说谁来做。

测试的时候关注三个层面：

指定调用测试：直接让 Agent 用这个 Skill 处理你的会议稿，看输出是否符合预期
自然触发测试：在正常对话中说「帮我整理一下这个会议纪要」，看 Agent 能不能自动识别并调用这个 Skill
边界测试：    故意丢一段不是会议纪要的内容进去，看 Skill 会不会错误地处理它

第一版大概率不完美。比如你可能发现它会把闲聊内容也当成讨论要点，或者多个议题交叉的时候拆分逻辑不对。没关系，回头改约束规则就行。比如加一条「忽略与议题无关的寒暄和闲聊内容」。

一般经过 2-3 轮「测试→发现问题→改规则→再测试」的循环，就能稳定下来了。

第五步：保存和使用

把 .md 文件放到你 Agent 工具的 Skill 目录下。不同工具的位置不一样：

Claude Code：项目根目录/.claude/skills/ 或 ~/.claude/skills/
CatPaw：    项目根目录/.catpaw/skills/ 或 ~/.catpaw/skills/
Cursor：    项目根目录/.cursor/skills/

放进去之后，下次你在 Agent 对话里说「帮我整理这个会议纪要」，Agent 就会自动找到并加载这个 Skill，按照你定义的方式去执行。

从零到能用，整个过程大概 30 分钟。如果你对自己的工作流程已经比较清楚，可能更快。

---

三、五种 Skill 设计模式：找到适合你的那种

上面那个会议纪要 Skill 只是一种类型。根据不同的任务特点，Skill 大致可以分成五种设计模式。了解这些模式可以帮你快速判断自己的需求适合做成哪种 Skill。

3.1 知识注入型

场景：你有一些 AI 不知道的专有知识，想让它在工作中参考。

比如你们团队有一套代码规范、文案写作标准、或者行业特定的术语表。这些内容不在 AI 的训练数据里，你把它塞进 Skill，AI 在工作时就会参考这些知识。

做法：把知识文档直接放进 .md 文件或 references 文件夹里就行了。

难度：最低。本质上就是把文档丢进去。

3.2 模板生成型

场景：你需要反复生成固定格式的内容。

日报、周报、PRD 文档、邮件模板都属于这类。你把模板定义好，用户每次只需要填几个关键信息，AI 就自动把内容填充到模板里。

做法：在 Skill 文件里定义清楚模板格式和填充规则。

难度：低。上面那个会议纪要 Skill 就是模板生成型的一种。

3.3 审查打分型

场景：你需要对某类内容进行评估。

文章审核、简历筛选、方案评估都属于这类。AI 按照你预设的评判标准，对输入内容逐项打分并给出修改建议。

做法：你得有一套明确的、经过验证的评判标准。这是关键——标准含糊的话，AI 的打分就没有参考价值。

难度：中等。难点不在写文件，在于你自己得先有一套靠谱的评判体系。

3.4 反转采访型

场景：需要通过多轮提问收集信息，然后生成个性化方案。

旅行规划、产品需求调研、学习计划定制都适合这种模式。Skill 不是直接给答案，而是先问你一系列问题——预算多少、偏好什么、有什么限制——然后基于你的回答生成定制方案。

做法：在 Skill 里设计提问逻辑和分支处理。比如用户说预算 5000，走一套逻辑；说预算 50000，走另一套。

难度：较高。需要考虑多轮对话的流转和分支情况。

3.5 流水线型

场景：需要把多个步骤串联成一个完整工作流。

比如写公众号文章的完整流程——选题确认→写大纲→写初稿→自检修改。每一步的输出是下一步的输入，Skill 会按顺序一步步执行。

做法：把每个步骤的输入输出定义清楚，并且考虑中间某一步出错了怎么办。

难度：最高。需要拆解完整工作流，处理步骤间的衔接和错误恢复。

小结

┌──────────────┬──────────────────────────────┬──────────┐
│ 设计模式      │ 一句话描述                    │ 创建难度  │
├──────────────┼──────────────────────────────┼──────────┤
│ 知识注入型    │ 给 AI 塞它不知道的知识         │ ★☆☆☆☆   │
│ 模板生成型    │ 按固定格式反复生成内容         │ ★★☆☆☆   │
│ 审查打分型    │ 按标准对内容做评估             │ ★★★☆☆   │
│ 反转采访型    │ 多轮提问后生成定制方案         │ ★★★★☆   │
│ 流水线型      │ 多步骤串联的完整工作流         │ ★★★★★   │
└──────────────┴──────────────────────────────┴──────────┘

建议从知识注入型或模板生成型开始。 第一个 Skill 的目标不是做得多好，是跑通流程、建立信心。等你熟悉了 Skill 的工作方式，再尝试更复杂的类型。

---

四、从「能用」到「好用」：5 个核心原则

做出来一个能跑的 Skill 并不难，30 分钟就够了。但从「能用」到「好用」，中间还有一段距离。这 5 个原则能帮你更快地走完这段路。

4.1 先能用，再好用

v1.0 版本的目标就是跑通核心流程，不要追求完美。第一版出来的结果肯定有各种小问题，这很正常。先让它能稳定地完成 80% 的工作，剩下的 20% 通过迭代来完善。

很多人卡在「想把 Skill 一步写到位」这个心态上，结果第一版就写了三天还没写完。不如先花 30 分钟出一个粗糙但能跑的版本，后面再慢慢打磨。

4.2 约束比指令重要

这是最容易被忽略、但对 Skill 质量影响最大的一点。

你告诉 AI「做什么」，它大概率能做到。但你不告诉它「不要做什么」，它大概率会过度发挥。

一些实际有用的约束示例：

❌ 没有约束：
「把会议内容整理成纪要」

✅ 有约束：
「把会议内容整理成纪要。
 - 不要添加会议中没有出现的内容
 - 如果待办没有指定负责人，标注为待确认，不要自己编
 - 讨论要点只提炼关键信息，不要复述原文
 - 忽略与议题无关的寒暄和闲聊」

每一条约束都应该来自你在实际测试中发现的问题。测试时 AI 犯了什么错，你就加一条对应的约束。这就是迭代的过程。

4.3 用真实数据测试

不要用你随手编的「张三说了 A，李四同意了，待办是做 B」这种干净数据来测试。

用你手头真实的会议录音转写稿、真实的合同文本、真实的数据报表。真实数据里有各种脏的、乱的、边界的情况，只有这些情况才能暴露 Skill 的真正问题。

4.4 迭代是常态

好的 Skill 不是一次写出来的，而是用出来的。

每用一次，你可能会发现一个新的边界情况。加一条约束规则，Skill 就更稳定一点。时间长了，这个 Skill 会变成你工作经验的一个精确映射——你踩过的坑、你的判断标准、你的偏好，全部沉淀在里面了。

4.5 第一个 Skill 投入最大，后续越来越快

做第一个 Skill 的时候，你需要理解 Skill 是什么、文件放在哪里、怎么测试、怎么调约束。这些都是一次性的学习成本。

从第二个开始，你已经知道套路了，整个过程会快很多。做到第三个第四个的时候，你可能十分钟就能搞定一个。

---

五、做完之后的问题：你不可能所有 Skill 都自己做

跟着上面的流程，你应该能做出一个属于自己的 Skill 了。

但这里有一个很现实的问题：你只能做你擅长的领域的 Skill。

你做一个会议纪要整理 Skill 没问题，因为你知道会议纪要应该怎么写。但如果你需要一个审查采购合同的 Skill，你做不了——你不知道合同审查应该看哪些要点、哪些条款容易出问题。如果你需要一个分析股票龙虎榜的 Skill，你也做不了——你不了解金融数据的接口和分析逻辑。

这就是 Skill 生态的真正价值所在。不是每个人都自己做自己用，而是一个领域的专家把经验沉淀成 Skill，另一个领域的人拿来用。 能力的跨领域流通，才是 Skill 这件事最有想象力的地方。

那问题来了，别人做的好 Skill 怎么找？

这是目前 Skill 生态最头疼的一环。

主流平台上已经有 20 万+ Skill，而且每天都在增长。搜一个需求出来几十个结果，名称差不多，Description 差不多，你根本分不清谁好谁差。

搜「合同审查」→ 47 个结果

「智能合同助手」    下载量 3,200    Description：帮您智能审查合同
「AI 法务专家」     下载量 2,800    Description：一键合同风险检测
「合同审查大师」    下载量 1,500    Description：专业合同审查工具
  ...

你能从这些信息里判断出哪个是一个法务老手花了一周沉淀十年审查经验做出来的，哪个是一个没有法律背景的人花五分钟用 AI 生成的吗？

判断不了。因为你在安装之前能看到的信息只有名称、Description 和下载量。而 Skill 的真实质量——约束条件写得好不好、错误处理完不完备、边界情况覆盖了多少——全部藏在那个 .md 文件里面，安装之后才看得到。

我们做的一个尝试：Deep Skill Finder

这就是我们做 Deep Skill Finder 的出发点。

思路很简单：不看 Skill 的 Description 怎么写，看它在真实任务里跑得怎么样。

社区里每天都有大量用户在真实工作中使用各种 Skill，他们的使用记录散落在各种帖子和讨论里——谁用了哪个 Skill，跑的什么任务，结果能不能用，有没有报错。我们把这些散落的真实使用数据收集起来，结构化，变成一个可搜索的推荐源。

所以当你说「我需要一个能帮我审查采购合同的 Skill」的时候，它不是去匹配哪个 Description 里写了「合同」两个字，而是去翻那些真实的使用记录，看看哪个 Skill 在合同审查这种任务里真的跑通过、真的出了可用的结果。

一个使用建议：不要像传统搜索那样输入「合同」「法律」这种宽泛关键词。 直接描述你的完整任务效果更好：

帮我审查这家企业的采购合同，重点检查付款条款、违约责任和知识产权风险。
找一个合适的 Skill 辅助你，保证法律分析的专业性。

它会根据整个任务语义去匹配，而不是靠某一个关键词。

Skill 的安装也很简单

找到想用的 Skill 之后，安装方式通常有三种：

链接安装：把 Skill 的 GitHub 页面链接发给 Agent，说「帮我安装这个」
NPX 安装：复制 Skill 提供的 npx 命令，粘贴到终端执行（不懂也没关系，直接让 Agent 帮你跑）
手动安装：把 Skill 的文件夹下载下来，放到 Agent 的 Skill 目录里

不管哪种方式，装完就能用。

---

六、总结

整篇走下来，核心内容可以归纳成这几点：

Skill 是什么——不是代码程序，是用自然语言写的 .md 文件，本质是一份工作手册。

怎么做——明确一个核心问题，梳理输入输出和约束规则，用真实数据测试，反复迭代。30 分钟能做出第一版。

做什么类型——五种设计模式（知识注入、模板生成、审查打分、反转采访、流水线），建议从最简单的知识注入型或模板生成型入手。

怎么做好——约束比指令重要，用真实数据测试，先能用再好用，迭代是常态。

做完之后——自己做覆盖自己擅长的领域，跨领域的需求去市场上找。面对 20 万+ Skill 的筛选问题，可以试试基于社区真实执行数据的推荐工具 Deep Skill Finder。

每个人都能做 Skill，每个人都应该试着做一两个自己的 Skill。不是因为它有多酷，而是你在做的过程中会被迫梳理自己的工作流程——我到底是怎么干这件事的、我的判断标准是什么、哪些步骤可以被规则化。这个梳理本身，就是一种能力提升。

工具地址：meyo.life/skill

---

如果觉得有帮助，欢迎点赞收藏。你做过或者想做什么类型的 Skill？欢迎在评论区聊聊，也许能给其他人一些灵感。