AI 已经逐渐进入我们的日常工作：编写代码、生成内容，甚至自动完成一些决策。
但是，用得越多，一个问题就越明显：
AI 很强，却不总是稳定。
想象一下我们使用豆包、千问的那些经历，即使输入相同的提示词，也可能得到不同的结果。同一套工作流程，过一段时间再次执行，表现也可能发生变化。
这种不确定性，让我们很难放心地把 AI 真正用到生产环境中。
如果你已经使用 AI 一段时间，应该还会发现另一个问题：你总是在 重复说同样的话。
为了解决这类问题，Anthropic 在 2025 年推出了 Agent Skills，随后又将其发布为开放标准。如今，Claude、OpenAI Codex 等兼容这一标准的 Agent，都可以通过 Skill 封装可复用的工作方式。
当然，国内的 Agent 工具，例如 Trae，CodeBuddy 等，也同样支持。
现在的 Agent 工具，能互相扫描对方的目录，例如你已经安装了 Cursor，现在你又想试试 Trae，当你安装好 Trae 的时候，它会自动地扫描 Cursor 的用户目录，从那里面获取 Skill。
在后续的几篇文章中，我们会依次讨论 Agent Skills 是什么、它如何工作，以及怎样正确地创建和使用一个 Skill。
不过在了解 Skill 之前，我们还是先从问题本身说起。
你为什么总是在重复自己
假设你正在使用 AI 审查 Pull Request。
你通常不会只说一句"帮我审查这段代码"，而是会继续补充要求：检查性能问题、遵循项目规范、指出潜在风险，再给出改进建议。
下一次审查代码时，你还要把这些要求重新说一遍。再下一次，还是一样。
时间久了，通常会出现两种情况：
- 每次都重复输入同样的要求；
- 为了省事而缩短提示词，结果输出质量也跟着下降。
即使你愿意一遍遍地输入完整要求，结果仍然可能不够稳定。
同一个任务，只是提示词存在一点细微差别，最终输出就可能完全不同。
到了这个时候，你甚至会开始怀疑：究竟是你在训练 AI，还是 AI 在训练你？
我们显然需要一种更合适的方式，把这些反复使用的经验和要求组织起来。
这就是 Skill 要解决的问题。
Skill 到底是什么
Skill 是一组可复用的指令，用来告诉 AI 应该怎样处理某一类特定任务。当然，这么说可能很模糊。更准确地说，一个 Skill 通常以目录组织，其中的 SKILL.md 承载元数据和核心指令，目录中还可以按需包含脚本、参考资料和其他资源。
过去，我们需要在每次对话中重新编写提示词；有了 Skill 之后，可以把这些要求定义一次，然后重复使用。
你可以把它理解为：把一段提示词整理成一套工作流。
这套工作流可以明确规定：
- 要完成什么任务；
- 应该按照什么步骤完成；
- 最终结果需要采用什么格式。
这样做可以减少重复输入，让输出更加稳定，也更容易把一套成熟的工作方法分享给其他人。
不过，Skill 并不只是保存起来的提示词。它还有两个很重要的特点：可移植性和可组合性。
Skill 为什么不只是提示词
可移植性
Agent Skills 采用开放的文件格式。一个按照标准编写的 Skill，可以被 Claude Code、OpenAI Codex 等兼容 Agent 识别，不需要为每个平台重新写一套完全不同的工作流。
不过，这里的"可移植"说的是 Skill 的组织格式和核心指令可以复用，并不代表它在所有平台上都能得到完全相同的结果。
不同 Agent 使用的模型、工具、权限机制和运行环境并不相同。如果一个 Skill 依赖某个平台特有的工具或 API，迁移之后仍然需要进行适配。
可组合性
一个 Agent 可以发现多个 Skill，并根据当前任务选择需要的部分加载。
例如，在同一次工作中，它可以先使用 code-review Skill 审查代码，再使用 release-notes Skill 根据修改内容生成发布说明。
两个 Skill 各自负责一段明确的工作流程，又可以在同一个任务中配合使用。正是可移植性和可组合性，让 Skill 不再只是一段方便复制的文本，而是可以长期积累的工作流基础设施。
接下来再看看，Skill 在 Agent 内部究竟是怎样工作的。
Skill 是怎样加载的
看到这里，你可能会产生一个疑问：
如果安装了几十个 Skill，Agent 会不会一次性读取所有指令，不仅挤占上下文，还会让模型变得混乱？
通常不会，因为 Agent Skills 采用了一个很重要的设计：渐进式披露（Progressive Disclosure）。
在初始阶段，Agent 通常只会读取每个 Skill 的名称和描述，并据此判断当前任务可能需要哪个 Skill。
只有在某个 Skill 真正匹配当前任务时，Agent 才会进一步读取完整的 SKILL.md。如果其中还引用了 references/、scripts/ 或其他资源，也会根据任务需要继续加载或执行。
也就是说，采用这种加载机制的 Agent 不会把所有完整指令一次性塞进上下文。初始的名称和描述仍然会占用少量上下文，但真正详细的内容只会在需要时加载。
关于这套加载机制，以及一个标准 Skill 目录应该怎样组织，我们会在后续文章中结合实际示例继续讨论。
Skill、Prompt、Tool 和 MCP 有什么区别
讨论 AI Agent 时，经常会同时看到 Prompt、Tool、MCP 和 Skill。这几个概念很容易混在一起，但它们解决的问题其实并不相同。
| 概念 | 主要作用 |
|---|---|
| Prompt | 用户在当前任务中提供的要求和上下文，通常只服务于这一次交互 |
| Tool | Agent 可以调用的实际能力，例如访问 API、查询数据库、运行命令或操作文件 |
| MCP | 连接 AI 应用与外部数据、工具和服务的一套开放协议 |
| Skill | 告诉 Agent 在特定任务中，应该怎样组织指令、资料和工具调用，形成可复用的工作流 |
换一种更直观的说法：
- Tool 提供能力；
- MCP 建立连接；
- Skill 组织工作流程。
Skill 不会取代 Prompt 或 Tool；它的主要责任是把这些内容组织成一套可以重复执行的工作方法。
理解这些区别之后，下一个问题自然就出现了：是不是所有任务都应该写成 Skill？
什么时候值得创建一个 Skill
并不是每个任务都需要 Skill。
如果你只是偶尔让 AI 写一段生日祝福，显然没有必要把它包装成一套正式的工作流。
但如果一个任务符合下面这些情况，就可以考虑创建 Skill：
- 经常重复相同的指令；
- 任务包含多个固定步骤；
- 希望得到相对稳定、可预测的输出。
判断标准其实很简单：它能否减少重复劳动，并提高工作结果的可靠性？
如果答案是肯定的，那么这个任务就可能适合被整理成 Skill。
现实中的三类 Skill
从实际使用场景来看，Skill 大致可以分为三类。
1. 文档与资产创建
这类 Skill 用来稳定地产出文档、演示文稿、设计稿或代码等内容。
例如，公司可以创建一个报告生成 Skill，让 Agent 始终遵循既定的品牌规范；前端团队也可以创建组件生成 Skill，让输出代码符合自己的设计系统和项目结构。
2. 工作流自动化
这类 Skill 适合处理包含多个步骤，并且需要遵循固定方法的任务，例如 Sprint 规划、资料调研或客户接入流程。
Skill 保存的不只是任务目标，还包括团队已经验证过的正确做法。
3. 增强 MCP 的使用方式
这类 Skill 构建在 MCP 集成之上，用来告诉 Agent 应该怎样正确使用某项外部服务。
MCP 负责把服务连接进来，Skill 则负责提供操作顺序、判断条件和领域经验。
如果只是为自己创建 Skill，最常见的通常是前两类。如果需要把能力提供给其他用户，尤其是同时提供 MCP Server，那么第三类 Skill 往往可以成为真正体现差异的部分。
现在，我们已经知道 Skill 是什么、它大致怎样工作，以及什么情况下值得创建。下面通过一个简单例子，把这些概念串起来。
一个简单的代码审查 Skill
如果没有 Skill，我们可能每次都会输入下面这段提示词：
审查这段代码，检查性能问题，确认它是否遵循最佳实践，并给出改进建议。
下一次遇到相同任务，再重新输入一遍。
有了 Skill 之后，可以把这些要求定义一次。一个最小的 Skill 大致如下：
markdown
---
name: code-reviewer
description: 审查 Pull Request 中的性能问题、代码风格和最佳实践。当用户要求"审查代码"、"检查 PR"或"分析函数"时使用。
---
# 代码审查 Skill
审查代码时：
1. 检查潜在的性能瓶颈；
2. 阅读 `references/style-guide.md`，确认代码是否符合项目规范；
3. 对复杂的性能问题，运行 `scripts/analyze_perf.py --file {filename}`；
4. 结合具体示例提出改进建议；
5. 标记潜在的安全风险。
## 输出格式
- 问题概述；
- 对关键问题给出逐行评论；
- 提供包含代码示例的修改建议。如果你喜欢英文版本：
markdown
---
name: code-reviewer
description: Reviews pull requests for performance issues, style violations, and best practices. Use when user says "review this code", "check this PR", or "audit this function".
---
# Code Review Skill
When reviewing code:
1. Check for performance bottlenecks
2. Verify style guide compliance by consulting `references/style-guide.md`
3. For complex performance analysis, run `scripts/analyze_perf.py --file {filename}`
4. Suggest specific improvements with examples
5. Flag any security concerns
## Output format
- Summary of findings
- Line-by-line comments for critical issues
- Suggested fixes with code samples放在哪里
以 Codex 为例：如果希望团队成员在这个项目中都能使用代码审查 Skill，可以把它放在仓库根目录的 .agents/skills/code-reviewer/ 下：
text
your-project/
└── .agents/
└── skills/
└── code-reviewer/
├── SKILL.md
├── references/
│ └── style-guide.md
└── scripts/
└── analyze_perf.py当你在这个仓库或其子目录中启动 Codex 时，它会扫描当前目录到仓库根目录之间的 .agents/skills/，因此可以发现这个 Skill。
若想供自己在所有项目中使用，也可以放在用户目录，即 ~/.agents/skills/ 中，放在用户目录的 skills，在任何地方都能使用，不仅仅局限于项目中。
.agents/skills/ 是 Agent Skills 常见的项目级目录。遵循这一约定、并扫描该目录的兼容 Agent 都可以发现其中的 Skill；不过不同工具的发现位置和加载规则仍可能不同，使用前最好查阅对应工具的文档。
可以看到，一个 Skill 并不只有 SKILL.md。它还可以包含 references/style-guide.md 这样的参考资料，也可以包含 scripts/analyze_perf.py 这样的可执行脚本。
Agent 会先读取 SKILL.md，再根据其中的指令，在确实需要时继续读取参考文件或执行脚本。
至于 Skill 目录应该怎样组织，我们会在第 2 篇中详细展开。
这里还要注意一个容易被忽略的问题：Skill 可以包含脚本，也可以引导 Agent 访问文件和外部服务。因此，不要直接安装来源不明的 Skill。使用之前，至少应该检查 SKILL.md、脚本、依赖项和它准备访问的资源。
到这里，一个可以重复使用的代码审查 Skill 就完成了。
相同的任务、相同的检查标准，不需要再反复输入一大段提示词。更重要的是，这套方法还可以随着使用过程不断修改和完善。
未完待续
现在，我们已经了解了 Skill 是什么、它为什么值得使用，以及渐进式披露如何减少上下文压力。这些内容是后续实践的基础。
接下来的文章将分别讨论：
- 创建： 编写第一个
SKILL.md，设计触发描述，并正确组织指令、示例和目录结构； - 测试： 测量 Skill 的触发准确率，处理边界情况，检查输出一致性，确认它是否真的按照预期工作；
- 扩展： 分享、版本管理与团队部署，以及怎样避开常见问题。
这个系列最终想解决的问题很简单：
不要停留在反复编写提示词，而是把已经验证过的方法，逐渐沉淀成真正可以复用、可以测试，也可以放心分享的工作流。
下一篇，我们开始真正创建第一个 Skill。