嗨，我是 Lena。第一次配置 SKILL.md 文件时，我总觉得哪里有点不对。不是错了，只是和我原先想的不太一样。我读完说明，把文件放到正确的目录里，Claude 也识别到了它。但随后我开始想：我到底给了它什么？知识？一种习惯？还是某种可以传递下去的东西？
这个问题我想了有一阵子。下面是我目前的一些观察。
什么是 Claude Skills？
Claude Skills 是模块化、可复用的能力包。它们通常以文件夹的形式组织，为 Claude Agent 提供特定领域的说明、上下文，以及可选脚本。每个 skill 的核心都是一个 SKILL.md 文件。
如果你正在用 Claude Code 或 Claude API 开发，这大概已经是你熟悉的模式，或者很快就会遇到。
SKILL.md 是如何工作的
每个 skill 都放在一个目录里。里面的 SKILL.md 文件分成两部分：顶部是一段 YAML frontmatter，下面是 markdown 正文。
front matter 很精简。它告诉 Claude 这个 skill 叫什么、应该在什么时候使用，也就是 Claude 启动时会读到的一段简短说明。真正的指令写在 markdown 正文里：该怎么做、输出该如何格式化、有哪些边界情况要注意、需要加载哪些辅助文件。
启动时，Agent 会把所有已安装 skill 的名称和描述预加载进 system prompt。这个元数据层是渐进式披露的第一层：它只给 Claude 足够的信息，让它知道该在什么场景下调用哪个 skill，而不用一开始就把全部内容塞进上下文。
这点我当时觉得确实设计得很用心。Claude 启动时并不会把整个 skill 文件都读进去，只读 frontmatter。只有当某个 skill 变得相关时，它才会继续加载更详细的内容。这意味着你可以安装很多 skills，而不必一直消耗 context window。
你可以把哪些行为编码进去
实际上，范围相当大。Skills 可以承载：
- 分步骤的过程指令 — 如何处理某类文件、某种 review 模式，或某种输出格式
- 领域约定 — 命名标准、项目特定规则、偏好的库
- 辅助文件 — 模板、示例输出、Claude 可执行的 Python 脚本
- 条件式子文档 — 只有在 Claude 判断相关时才会加载的更深一层参考资料
Skills 做的是让 Claude 为解决某个问题做好准备，而不是直接替它把问题解掉。这和传统工具有根本差别，后者是执行后返回结果。
这一点对我来说很重要。Skill 本身不会运行。它提供指引，真正进行推理的仍然是 Claude。
如何设置并使用 Claude Skills
文件位置与格式
如果是个人在所有项目里通用的 skills，就放在 ~/.claude/skills/。如果是通过 Git 共享的项目级 skills，路径则是 .claude/skills/。每个 skill 都需要自己的子目录，目录里再放一个 SKILL.md 文件。
格式本身很直接。创建 skill 很简单，本质上就是一个文件夹，里面放一个带 YAML frontmatter 和说明正文的 SKILL.md 文件。Anthropic's official skills repository on GitHub 里有可直接起步的模板 skill，也包含了那些驱动 Claude 内置 PDF、Word 和 PowerPoint 处理能力的 source-available document creation skills。
Claude 如何读取并应用 Skill 指令
一旦安装好某个 skill，Claude 就会监控进入的任务，并把它们与各个 skill 的描述进行匹配。匹配上之后，它就把 SKILL.md 的内容加载进上下文，并从那里开始遵循说明。
你也可以用斜杠命令手动调用，比如 /<skill-name>，或者让 Claude 基于任务上下文自动决定是否启用。两种方式在底层的工作原理是一样的。
我在这里观察到一件很有意思的事：当 Claude 使用一个 skill 时，它并不是“已经知道”里面的说明，而是每次都会重新去读它，就像在查一份文档。这一点的影响，我后面还会再说。
Claude Skills 擅长的地方
领域知识与项目约定
这大概是 skills 最能发光的地方。如果你的团队有一套特定编码规范、偏好的调试流程，或者固定的输出要求，把这些编码进 skill 文件里，Claude 就能稳定地应用它们，而不用你每次开新会话都重新解释一遍。
我在几个不同项目里试了几次。和单纯依赖 CLAUDE.md 指令、或者在 prompt 里一遍遍重复相比，一致性明显更好。Claude 会去读这个 skill，照着它执行，输出也更可预期。
一致的输出格式
对于结构化输出，比如技术文档、代码审查、API 文档，skills 很适合拿来当格式契约。你把预期结构描述清楚，Claude 把它读进去，输出就更容易稳定贴合。
Claude Code skills 遵循 Agent Skills 开放标准，这一格式可以跨多个 AI 工具使用。Claude Code 还在这个标准上扩展了额外能力，比如 invocation control、subagent execution，以及 dynamic context injection。
这种跨平台兼容性很值得注意。如果你同时在多个 Agent 工具上构建工作流，同一种 SKILL.md 格式是可以复用的。
Claude Skills 的上限在哪里
从这里开始，我渐渐发现它和我起初想象的东西其实并不完全一样。
静态文件 vs. 动态学习
SKILL.md 文件是人写出来、存到磁盘上的。它不会自己更新。如果 Claude 借助某个 skill 很好地完成了任务，这次成功也不会反向写回 skill 文件。下一次会话，仍然是从同一份静态文档开始。
你当然可以要求 Claude 把那些成功做法和常见错误整理回 skill 里，但 这一步是手动的。 要由你来发起。Claude 不会自己这么做。
我不确定这是不是缺陷。更像是一条清晰的设计边界。
没有执行反馈闭环
当 Claude 应用某个 skill 并产出结果时，没有任何信号会回流到 skill 本身。没有记录会告诉你哪条指令有效、哪条被忽略、哪条造成了问题。Skill 本身没有“被使用过”的记忆。
Agent 在生产环境里跑得越久，这一点越重要。那些模式会积累在你的脑子里，而不是积累在文件里。
Skills 不会在 Agent 或团队之间自然传播
Custom Skills 是每个用户各自拥有的，它们不会在组织范围内自动共享，也不能被管理员集中管理。
所以，如果团队里某个人基于几个月的实际使用，把一个 skill 打磨得更好了，这个改进版本并不会自动传给队友。它只会留在本地。总得有人去复制、提交、共享，然后大家各自再更新。
这并不是说它坏了。但它意味着 skill 的改进传播得很慢，而使用这个 skill 的 Agent 网络，也不会随着时间自然收敛到更好的行为上。
从静态 Skills 到可继承的能力
超出 SKILL.md 的“可复用、可验证能力”意味着什么
我最近一直在想，如果一次 skill 的成功执行，比如某个 Agent 真的顺利跑通了一条复杂的调试序列，能不能直接变成其他 Agent 可以继承的东西。不是一份被复制的文件，而是一套带审计轨迹的、已经验证过的解法。
现在的 skills 更像 onboarding 文档。它们基于某个人当下最好的理解写成，然后被手动分发。这个模型是有效的，而且在稳定、成熟、问题边界清楚的领域里，它工作得很好。
但对于那些把 Agent 跑在生产环境里的团队来说，Agent 会失败、恢复、适应。于是“skill 写了什么”和“上周真正有效的做法是什么”之间的差距，会悄悄拉大。
当你需要一种会演化的东西
我越观察真实使用中的 Agent 系统，就越觉得 难点不在于把知识编码一次，而在于如何让它保持最新。 Skills 解决的是编码问题。更新性的问题，依然是开放的。
现在已经开始出现一些基础设施层面的尝试，它们把经过验证的 Agent 行为当作可共享资产来看待。那不再是静态文件，而是带来源脉络的已验证解法。这种架构与 SKILL.md 很不一样，也会把“信任”以及 Agent 语境下“复用”到底是什么意思这些问题重新带出来。
这条线到底该画在哪，我现在也还没有完全想清楚。
局限与权衡
如果只说我目前观察到的结论：
Claude Skills 的确很有用。 它们减少重复，提高一致性，也让领域知识可以跨会话迁移。对于个人开发者和小团队来说，这比临时、零散地写 prompt 要好得多。
真正的上限，会出现在你想要一种能自我改进、能自动在 Agent 之间传播，或者能从真实运行里持续积累证据的能力时。 这并不是 SKILL.md 被设计来解决的问题。
这个权衡很简单：可预测性 vs. 适应性。Skills 提供的是可预测性。它们不会，也不打算，给你一个能从自己历史里学习的 Agent。
FAQ
- Claude Code 里的
SKILL.md文件是什么？
SKILL.md 文件是 Claude skill 的核心组件。它是一个带 YAML frontmatter 的 Markdown 文档，为 Claude 提供特定领域的指令、上下文和元数据。它告诉 Claude 什么时候该启用这个 skill，以及启用后该做什么。借助 Claude 的 VM 环境，skills 能提供一些单靠 prompt 很难做到的能力。
- Claude Skills 是怎么工作的？
Claude 会在启动时读取 skill 的元数据，只有在检测到相关任务时，或者你用斜杠命令手动调用时，才加载完整指令。这种渐进式加载能把上下文占用保持在较低水平。skill 目录里的辅助文件也会按需加载，而不是一次性全部读入。
- 我该如何为 Claude Code 创建自定义 skill？
在项目的 .claude/skills/ 目录下创建一个子目录（如果是个人全局使用，则放到 ~/.claude/skills/）。然后新增一个 SKILL.md 文件，顶部写上包含 name 和 description 的 YAML frontmatter，下面接你的 Markdown 指令。Claude 会在相关场景下自动发现并应用这个 skill。你可以去看 Anthropic skills GitHub 仓库里的模板和示例，也可以阅读完整的 Agent Skills 文档来获取配置指导。如果想看更偏技术的拆解，Anthropic's engineering blog post on Agent Skills 很值得细读。如果你用的是 SDK，Agent Skills in the SDK 则解释了在那个上下文里，skill discovery 和 tool access 是怎样工作的。
- Claude Skills 和 MCP tools 是一回事吗？
不完全是，尽管我自己有时也会把这两者混在一起。MCP (Model Context Protocol) tools 是 Claude 在运行时调用的外部能力，例如文件系统、数据库、API 和各种服务。它们会执行，并返回结果。Claude Skills 则是指导性的：它们告诉 Claude 应该如何 行事、如何接近某个任务，而不是给它新增一个可以调用的工具。一个 skill 可能会引导 Claude 完成一套 code review 流程；一个 MCP tool 则可能真的去取回被审查的文件。两者可以协同工作，但解决的问题并不一样。一个给 Claude 提供访问能力，另一个给 Claude 提供行为指引。
- Claude Skills 可以在项目之间共享吗？
可以共享一部分。放在 ~/.claude/skills/ 的 skills 属于个人技能，会应用到这台机器上的所有项目。放在项目目录 .claude/skills/ 里的 skills 则是项目级的，可以提交进 Git，这意味着克隆仓库的队友也会自动拿到同样的 skills。不会发生的是更进一步的自动同步或自动传播。如果你在一个项目里把某个 skill 改进了，这个改进不会自己流向别处。共享仍然是手动的：复制、提交、分发。对个人和在同一仓库协作的小团队来说，这通常够用；但对于在多个环境里运行多套 Agent 工作流的大型组织，摩擦就会逐渐显现出来。
我会继续观察这个领域怎么演化。静态指令与会自我更新的 Agent 能力之间的距离，感觉正在慢慢缩短，只是过程并不总是显眼。我现在也还没完全想明白这意味着什么。下次见。
