先说结论：
Skill是处理某一类标准化、流程化问题沉淀的一种能力，它和工作流特别类似，Workflow是流程主导，Skills则是大模型主导，所以Skills更自由风险也更高。实现方式上就是通过自然语言模拟程序的流程，既在何种场景调用哪种能力。优势是能力可复用、节省反复拼接prompt的时间和token开销、通过接入脚本增加系统操作性。劣势是风险更高，skill多了管理成本增加。

Skill 到底是什么：一个可复用的能力单元

Skill，指的是围绕某类任务封装的一组可复用能力单元。它不是一句 Prompt，也不是单独一个工具，而是把任务相关的执行要素组织到一起，让 Agent 在处理某类问题时不再完全依赖临场发挥。

一个 Skill 通常会包含这些内容：

• 任务说明：它要解决什么问题
• 触发条件：什么情况下应该调用
• 输入约束：需要哪些字段，缺失时如何处理
• 执行步骤：任务按什么顺序推进
• 依赖资料：模板、术语表、规范文档、参考样例
• 工具规则：什么时候调用检索、搜索、脚本或外部接口
• 输出约束：结果格式、字段要求、检查规则
• 失败策略：信息不足、调用失败或置信度不足时如何回退

如果把 Prompt 看成“这次任务怎么交代”，那么 Skill 更像“这类任务以后都怎么做”。它的重点不是提升一次回答的表现，而是把一类任务变成可以沉淀、复用、维护和治理的能力模块。

Skill 和 Prompt、RAG、Tool、Workflow 的区别是什么

Skill 容易被误解，一个重要原因是它和 Prompt、RAG、Tool、Workflow 都有交集。如果不把边界说清楚，很容易被认为只是给老概念换了个名字。

Skill 和 Prompt 的区别

Prompt 是一次性说明，主要作用是告诉模型当前任务的角色、目标和要求。它适合快速试验，也适合简单任务，但通常缺少明确的模块边界、依赖管理和版本管理能力。

Skill 则不是一次对话里的临时指令，而是围绕某类任务封装好的能力定义。它强调复用、结构化、可维护，而不是“这次多写一点规则”。

可以简单理解为：Prompt 是单次交代，Skill 是任务级封装。

Skill 和 RAG 的区别

RAG 解决的是“模型知识不完整”的问题。它通过检索外部资料，把相关内容补给模型，让回答更接近事实。

但 RAG 只负责补知识，不负责定义完整任务。它告诉模型“该参考什么”，却不直接规定“参考之后怎么处理、如何输出、遇到缺失怎么办”。

Skill 可以使用 RAG，但它比 RAG 多了一层任务组织能力。

Skill 和 Tool 的区别

Tool 解决的是“模型能不能执行外部动作”的问题，比如查询数据库、调用接口、读取文件、执行脚本。

但工具只是动作接口，不等于任务本身。一个工具可以被很多任务复用，而 Skill 会进一步规定：何时调用工具、调用结果如何使用、调用失败如何处理。

所以，Tool 提供能力入口，Skill 负责把这些能力编排进具体任务。

Skill 和 Workflow 的区别

Workflow 更强调显式流程编排，通常会把顺序、分支、条件、状态流转写得比较清楚，适合强约束、确定性更高的业务链路。

Skill 也有流程，但它更像围绕某类任务抽出来的能力节点。它关注的是“这类任务怎么稳定完成”，而不一定把整个系统流程都展开成状态机。

在很多系统里，两者的关系其实是分层的：Workflow 负责编排多个步骤或多个 Skill，Skill 则是 Workflow 中可复用的任务能力节点。

一句话概括这几个概念

• Prompt：一次性说明
• RAG：补知识
• Tool：补动作
• Workflow：补流程编排
• Skill：把任务说明、知识、动作、输出约束组合成一个可复用能力单元

它们不是互斥关系，而是分层协作关系。Skill 可以使用 RAG 和 Tool，也可以被 Workflow 编排。

为什么需要 Skill：它真正解决的是“能不能稳定执行”

Skill 的意义，不在于让模型多会说一句话，而在于让同类任务的执行方式更稳定。

第一，它能把流程固定下来。
很多任务失败，不是模型完全不会，而是每次都在“现场发挥”。Skill 把步骤写清楚后，模型面对同类任务时，优先沿着固定路径执行，漏步、跳步和格式跑偏都会明显减少。

第二，它能把依赖资源绑定到任务上。
如果模板、术语表、规范文档和样例都散落在不同地方，模型每次都要临时拼接上下文，结果自然容易不一致。Skill 的做法是把这些依赖收拢到任务定义里，减少知识分散造成的执行偏差。

第三，它能把工具调用纳入任务边界。
很多业务任务不是“生成一段文字”就结束了，而是需要查资料、跑脚本、读文件、发请求。Skill 把这些动作放进统一的任务定义里，模型就不再只是“知道应该做什么”，而是能更稳定地“按规则去做”。

第四，它让经验从聊天记录变成系统资产。
一段 Prompt 只能算一次经验；一个 Skill 才是能被复用、升级、版本化和共享的能力模块。这种变化，才是 Agent 系统从“能演示”走向“能运行”的关键一步。

第五，它可以节省成本。
skill通过metadata这种渐进式搜索的方式，大大降低了大模型读取不必要信息的可能性，只有在匹配到相应工具才会进一步读取工具内容，节省了token消耗。

从实现视角看，Skill 在系统中通常长什么样

从工程实现角度看，Skill 通常不会只是一个抽象概念，而是一份可注册、可调用、可维护的能力定义。

它可能表现为配置文件，也可能表现为平台元数据、代码对象，或者“Prompt 模板 + 输入输出 Schema + 工具权限 + 依赖资源”的组合。不同系统实现形式不同，但核心目标是一致的：让某类任务拥有明确边界和可治理结构。

一个真正可落地的 Skill，通常不只包含内容本身，还需要配套这些机制：

• 路由策略：决定何时触发、由谁触发
• 版本管理：区分旧版本和新版本的行为差异
• 日志记录：追踪调用了什么、用了哪些资源、执行了哪些步骤
• 评估机制：衡量字段完整率、格式合规率、任务成功率、人工修订率
• 回退策略：当信息不足、工具失败或结果置信度不足时如何兜底

从工程实现看，Skill 不只是概念，而是一个目录

如果只把 Skill 理解成“更高级的 Prompt”，还是不够落地。真正进入工程实现后，Skill 通常首先表现为一个目录：目录里有必需的 SKILL.md，还可以有 references/、scripts/、assets/ 等辅助内容。OpenAI 的公开文档明确把 Skill 描述为“一个目录 + 必需的 SKILL.md + 可选的脚本与参考资料”，并建议把可复用工作流沉淀成这种结构。([OpenAI Developers][1])

一个最常见的组织方式如下：

.agents/
└── skills/
    └── meeting-minutes/
        ├── SKILL.md
        ├── references/
        │   ├── template.md
        │   ├── terminology.md
        │   └── good-example.md
        ├── scripts/
        │   ├── clean_transcript.py
        │   └── validate_minutes.py
        └── assets/
            ├── output_schema.json
            └── sample_input.md

如果是个人通用 Skill，可以放在用户目录；如果是项目级 Skill，通常放在仓库里的 .agents/skills。公开文档给出的推荐就是：全局 Skill 放用户目录，团队或仓库专属 Skill 放 .agents/skills。([OpenAI Developers][2])

这件事很重要，因为它说明 Skill 的本质不是“一段聊天时顺手贴上的说明”，而是可以被版本管理、团队共享、随项目一起演进的工程资产。

一个 Skill 目录通常怎么组织

目录结构不必复杂，但最好一眼能看懂“说明在哪、资料在哪、脚本在哪”。

1. SKILL.md：Skill 的入口和说明书

这是唯一必需文件，也是整个 Skill 的核心。公开文档要求 SKILL.md 至少包含 name 和 description 两个元数据字段，并在后面写具体说明。模型会先读取这两个字段做发现和匹配，只有在判断这个 Skill 相关时，才继续读取完整内容。([OpenAI Developers][1])

可以把它理解成两层：

• 前面的元数据，负责“让系统知道这个 Skill 存在，并大致知道它适合什么任务”
• 后面的正文，负责“真正告诉模型这项任务该怎么做”

2. references/：长文档、规范、模板说明

当某个任务依赖较长的背景资料、术语表、规范文档、历史样例时，不建议全部塞进 SKILL.md。更合理的方式是放进 references/，在 SKILL.md 中告诉模型什么时候去读、优先读哪份。OpenAI 的文档把这类内容称为 longer docs，也就是更长的参考材料。([OpenAI Developers][3])

适合放在这里的内容有：

• 公司或团队规范
• 术语表
• 高质量样例
• 长模板说明
• 输出字段解释

3. scripts/：确定性步骤交给脚本

如果任务里有某些步骤适合确定性执行，比如清洗文本、校验字段、格式转换、批量重命名、固定命令调用，就可以放进 scripts/。公开文档明确提到，Skill 可以不仅是说明，还可以附带 supporting logic 和 repeatable commands，在需要时执行。([OpenAI Developers][4])

适合放在这里的内容有：

• 文本预处理脚本
• 输出校验脚本
• 固定命令封装
• 结构化转换脚本
• 结果检查脚本

这一层非常关键。它意味着 Skill 并不是“全靠模型自由发挥”，而是可以把能写死的部分尽量写死，把需要模型判断的部分留给模型。

4. assets/：静态资源和样板文件

assets/ 更适合放那些不需要解释太多、但经常要被读取或复制的静态内容，比如模板、示例输入、JSON Schema、初始配置文件。OpenAI 文档把它概括为 templates and starter files。([OpenAI Developers][3])

适合放在这里的内容有：

• Markdown 模板
• Word/邮件样板文本
• JSON Schema
• 示例输入
• 初始配置文件

可以看到，这四层分工其实很清楚：

• SKILL.md 讲规则
• references/ 放知识
• scripts/ 放动作
• assets/ 放材料

这样组织以后，整个 Skill 才真的像一个“任务能力包”。

SKILL.md 应该怎么写：先写触发边界，再写执行规则

很多人第一次写 Skill，最容易犯的错误是把 SKILL.md 写成“超长 Prompt”。这样当然能用，但不利于触发、维护和复用。

更合适的写法，是把它当成一份任务说明书，按固定顺序组织。至少应包含下面几部分。

1. YAML 头部：定义名字和触发范围

公开文档给出的最小形式就是：

---
name: meeting-minutes
description: Generate structured meeting minutes from transcripts. Use this skill when the user wants meeting notes, action items, decisions, or risk extraction from meeting content. Do not use it for casual summaries or brainstorming notes.
---

...

这里最重要的不是 name，而是 description。因为模型会先看 description 来决定要不要调用这个 Skill。官方文档反复强调：描述必须写清楚什么时候该触发，什么时候不该触发，否则隐式调用的可靠性会下降。([OpenAI Developers][1])

所以 description 不该写成泛泛的一句“生成会议纪要”，而应该写成：

• 适用场景
• 不适用场景
• 可能出现的触发词
• 任务边界

2. 任务目标：先说这项 Skill 到底负责什么

在 YAML 头部后，第一段最好直接定义目标，例如：

## Purpose

This skill converts meeting transcripts into structured meeting minutes with decisions, action items, risks, and pending confirmations.

这一段不是装饰，而是在帮模型建立稳定任务心智：这项 Skill 是“整理纪要”，不是“随便总结”。

3. 输入要求：把前置条件说清楚

建议单独写一个 Inputs 小节，明确：

• 必填输入是什么
• 可选输入是什么
• 输入缺失怎么办
• 哪些字段不能猜

例如：

## Inputs

Required:
- meeting topic
- attendees
- meeting time
- transcript

Optional:
- background documents
- previous meeting minutes

If owner or due date is unclear, mark it as pending confirmation instead of guessing.

这一段的价值很大。它能直接减少模型“擅自脑补”的概率。

4. 执行步骤：把流程写成模型可跟随的顺序

这一部分建议写成明确步骤，而不是大段散文。比如：

## Steps

1. Read the transcript and identify discussion topics.
2. Separate discussion from final decisions.
3. Extract action items.
4. For each action item, capture owner and due date when available.
5. Extract risks, blockers, and pending confirmations.
6. Format the result using the meeting minutes template in assets/template.md.
7. Run scripts/validate_minutes.py before finalizing if the environment allows it.

这样写有两个好处：

第一，模型知道先做什么后做什么。
第二，人后续维护时也容易改。

5. 输出格式：写清结构，不要只写“规范输出”

输出要求越模糊，结果越容易飘。建议直接写成结构要求，甚至指定引用哪份模板。

例如：

## Output format

Output in Markdown with these sections:
- Basic Info
- Agenda
- Decisions
- Action Items
- Risks and Pending Confirmations

如果要求更严，还可以把 JSON Schema 或表格模板放到 assets/ 里，再在 SKILL.md 中引用。

6. 检查与回退：工程感最强的一段

这一段最容易被忽略，但恰恰最像工程文档。建议专门写清楚：

• 哪些字段必须检查
• 信息不足时怎么办
• 工具失败时怎么办
• 哪些内容禁止猜测

例如：

## Validation rules

- Do not present uncertain statements as final decisions.
- Do not invent owners or deadlines.
- If confidence is low, mark the item as pending confirmation.
- If transcript quality is poor, summarize conservatively and state uncertainty.

这部分一加，Skill 才不只是“会做”，而是开始具备“做错时怎么收住”的能力。

一个更清晰的工程示例：会议纪要 Skill 应该怎么落到目录里

下面给一个更完整、也更适合博客展示的例子。

目录结构

.agents/
└── skills/
    └── meeting-minutes/
        ├── SKILL.md
        ├── references/
        │   ├── terminology.md
        │   ├── writing-guidelines.md
        │   └── strong-example.md
        ├── scripts/
        │   ├── clean_transcript.py
        │   └── validate_minutes.py
        └── assets/
            ├── template.md
            ├── output_schema.json
            └── sample_input.md

SKILL.md 示例

---
name: meeting-minutes
description: Use this skill to generate formal meeting minutes from meeting transcripts or notes. Trigger when the task requires decisions, action items, owners, deadlines, risks, or pending confirmations. Do not use for casual summaries, brainstorming drafts, or informal note cleanup.
---

## Purpose

Generate structured meeting minutes from transcripts or raw meeting notes.

## Inputs

Required:
- topic
- attendees
- meeting_time
- transcript

Optional:
- background_docs
- previous_minutes

Never guess missing owners, deadlines, or final decisions.

## Resources

- Use `assets/template.md` as the output template.
- Use `references/terminology.md` for project terms.
- Use `references/writing-guidelines.md` for wording and formatting conventions.
- Refer to `references/strong-example.md` as a quality example.

## Steps

1. Read and, if needed, clean the transcript.
2. Identify agenda items and discussion topics.
3. Separate discussion content from confirmed decisions.
4. Extract action items with owners and due dates when explicitly supported.
5. Extract risks, blockers, and pending confirmations.
6. Format the output using `assets/template.md`.
7. Run `scripts/validate_minutes.py` if available.

## Output format

Return Markdown with these sections:
- Basic Info
- Agenda
- Decisions
- Action Items
- Risks and Pending Confirmations

## Validation and fallback

- If confidence is low, use "Pending confirmation" instead of asserting a final decision.
- If owner or due date is missing, leave it blank and mark it for confirmation.
- If transcript quality is poor, summarize conservatively and note uncertainty.

references/ 里放什么

references/terminology.md

# Terminology

- RC: Release Candidate
- CR: Code Review
- Blocker: An issue that prevents the next planned step

references/writing-guidelines.md

# Writing Guidelines

- Use concise, factual language.
- Do not rewrite discussion into conclusions unless explicitly supported.
- Prefer bullet points for risks and pending confirmations.

assets/ 里放什么

assets/template.md

# Meeting Minutes

## Basic Info
- Topic:
- Time:
- Attendees:

## Agenda

## Decisions

## Action Items
| Item | Owner | Due Date | Status |
|---|---|---|---|

## Risks and Pending Confirmations

scripts/ 里放什么

scripts/validate_minutes.py 可以只做两件确定性检查：

• 是否有必需章节
• Action Items 是否包含 Owner / Due Date 列

这样，模型负责理解和归纳，脚本负责硬校验。两者分工就清楚了。

写博客时，最值得强调的一个工程原则

写到这里，博客里最好点明一个原则：

不要把所有东西都塞进 SKILL.md。
SKILL.md 负责定义任务，references/ 负责承载长资料，scripts/ 负责确定性动作，assets/ 负责提供模板和静态材料。

这句话很重要，因为它直接体现了 Skill 和普通 Prompt 的工程差异。

普通 Prompt 的做法，常常是“所有信息挤在一段话里”；
Skill 的做法，则是“把任务拆成可管理的文件结构”。

前者适合临时使用，后者才适合长期维护。

一个好 Skill 目录，至少要满足这 4 点

最后可以用一小段收束工程设计原则。

1. 入口单一

不管目录里放多少东西，入口都应明确是 SKILL.md。这样人和系统都知道从哪里开始理解这个 Skill。公开文档也把 SKILL.md 视为必需入口文件。([OpenAI Developers][1])

2. 资料分层

说明、长文档、脚本、模板不要混放。分层之后，维护成本会低很多，也更适合团队协作。

3. 边界明确

一个目录只解决一类任务。不要一个 Skill 既做会议纪要、又做周报、又做项目复盘。Skill 一旦边界模糊，触发和维护都会变差。官方最佳实践也强调，每个 Skill 应该聚焦一个工作。([OpenAI Developers][4])

4. 能校验、能回退

只写“怎么做”还不够，还要写“做不稳时怎么办”。这才是 Skill 走向生产级使用的分界线。

用一张表看清楚：Skill 是怎么解决老问题的

旧问题	Skill 的解决方式	带来的收益
Prompt 反复复制，规则散落	模块化封装	提升复用性
执行依赖临场发挥	固化步骤	提高稳定性
模板和资料分散	绑定依赖资源	减少知识缺失
输出标准模糊	增加格式与检查约束	降低结果漂移
优化经验留在聊天记录	版本化管理	沉淀团队资产

这张表基本可以概括 Skill 的核心工程价值：它不是在替代模型，而是在替代那种“每次从头拼 Prompt”的松散组织方式。

Skill 目前的缺陷：它不是魔法，而是更高层次的复杂度

Skill 很重要，但它绝不是银弹。它解决了一批旧问题，也引入了新的复杂度。真正做系统时，这些问题都绕不过去。

结果层：有了 Skill，也不等于结果绝对确定

Skill 可以显著提升稳定性，但底层仍然是生成式模型。只要模型还在做概率生成，就无法像传统程序那样保证完全一致。面对歧义输入、缺失信息或超长文本，输出依然可能波动。

所以，Skill 解决的是“更稳”，不是“绝对不出错”。

治理层：Skill 一多，边界和路由会变复杂

系统里只有几个 Skill 时，问题通常不明显；一旦数量上来，麻烦就会出现。两个 Skill 同时匹配一个任务怎么办？边界过宽的 Skill 会不会侵入别的场景？新旧版本行为不一致怎么办？这些都属于治理问题。

很多系统到后期卡住，并不是 Skill 本身没价值，而是没有建立起清晰的路由和治理机制。

维护层：Skill 不是写完就结束

模板会变，术语会变，业务规则会变，工具接口也会变。如果 Skill 长期不更新，它就会一本正经地执行过时逻辑。表面看起来流程完整，实际上结果已经不符合当前业务。

这意味着 Skill 需要持续维护，而不是“一次封装，永久有效”。

安全与可观测性层：能力增强，风险也会同步增加

当 Skill 开始连接外部知识库、脚本和工具之后，风险就不再只是“回答错了”，而是会上升到系统层面。常见问题包括权限是否过大、依赖资源是否可信、工具调用是否可追踪、错误发生后能否定位。

此外，Skill 还需要配套评估机制。没有字段完整率、格式合规率、任务成功率、人工修订率这类指标，就很难判断它到底是真的稳定，还是只是“看起来稳定”。

一个典型的失败场景

为了更具体地理解这些问题，可以看一个很常见的翻车场景：

一个“项目复盘生成 Skill”上线后，前几周效果不错。后来项目模板更新了，但 Skill 依旧使用旧模板；同时路由策略把部分“技术总结”任务也错误分配给了这个 Skill。结果生成出来的文档表面结构完整，实际上字段名不符合新模板要求，部分结论也写进了错误栏目。更糟的是，因为系统没有完整日志和评估指标，团队起初只觉得“最近质量变差了”，却很难快速定位问题出在模板、路由，还是模型本身。

这类问题很典型。Skill 带来的不是简单复杂度，而是更接近工程系统的复杂度。

一个好 Skill，至少要满足这 5 个条件

如果只讲概念，不讲设计原则，文章很容易停留在“听懂了，但不会用”。从实践角度看，一个好 Skill 至少要满足下面五个条件。

1. 边界清晰

一个 Skill 只解决一类问题，不要既想写纪要，又想做复盘，还想顺带输出周报。边界一旦模糊，后续一定会出现路由冲突和维护混乱。

2. 输入明确

输入字段、前置条件、缺失处理策略都要写清楚。没有输入约束，模型就会自己补空白；而它最容易出错的地方，恰恰就是这种“自作主张的补全”。

3. 步骤稳定

适合做成 Skill 的任务，应该具备相对稳定的处理流程。高度依赖临场创造、问题空间持续变化的任务，不一定适合过早封装。

4. 输出可检验

格式、字段、结构和质量标准要清楚。只有结果可验收，Skill 才能进入评估和迭代闭环。

5. 可维护、可治理

版本、依赖、权限、日志、评估、回退策略，都应该纳入设计范围。一个 Skill 写得再漂亮，如果不能维护和治理，最终也很难真正落地。

这五点看起来朴素，但它们几乎决定了 Skill 是“一个聪明的想法”，还是“一个能长期运行的系统模块”。