今天又看了一张 Claude Code 技能系统全景图，信息量非常大，但它其实在讲一个很核心的问题：当系统里有 1000+ 个 skills 时，Claude Code 到底怎么发现它们、筛掉大部分、选中少数几个，再把真正需要的技能加载进来执行。
我以前会比较自然地把 skill 理解成“一个提示词文件”或者“一个功能说明文档”。但这张图给我的感觉是：在 Claude Code 里，Skill 更像一个工程化的能力单元。它既描述自己能做什么，也规定什么时候应该被使用，还会声明参数、工具权限、路径约束和执行提示。
换句话说，Skill 不只是 prompt，它更像一份“可被模型发现、可被系统约束、可被执行流程调用”的小型协议。
一、技能从哪里来
图里把技能来源按优先级分了几层，这一点很关键。因为同名技能、不同目录、不同信任来源之间，必须有一套清晰规则，否则 1000 个技能很快就会变成混乱的上下文噪声。
大体可以分成这些来源：
- Managed Skills：企业托管技能，通常由组织统一发放和治理。
- User Skills：用户级技能，放在用户自己的 Claude 配置目录里，偏个人长期复用。
- Project Skills：项目级技能，随当前项目走，适合团队共享项目规则。
- Plugin Skills：插件提供的技能，常和 hooks、agents、commands 一起出现。
- Additional Skills：通过额外目录传入的技能，用于临时扩展。
- Bundled Skills：内置技能，通常信任级别最高。
这里让我觉得很工程化的一点是：技能不是简单堆起来，而是要做优先级管理、路径规范化和去重。图里也提到，同名或同路径的技能会通过 realpath 这类方式做路径去重，避免同一个能力被重复加载。
二、不是把 1000 个技能都塞进上下文
这张图最值得记住的点，是 Claude Code 的发现流程并不是“读取所有 SKILL.md 全文”。
如果真的把 1000 个技能的完整说明都塞进上下文，那模型还没开始干活，上下文窗口就先被污染了。所以它采用的是类似懒加载的方式：
- 先扫描技能目录，只读取 SKILL.md 的 frontmatter 元数据。
- 根据来源、路径、状态、用户调用方式等条件过滤。
- 得到一个很小的候选集，通常是 5-20 个技能卡片。
- 模型根据用户问题和技能的 description、when_to_use 判断要不要用。
- 只有在确认使用某个技能后，才加载完整的 SKILL.md 内容。
这个设计很像“先索引，后精读”。系统不急着把所有知识都端上来，而是先用短元数据做召回和筛选，再把真正相关的技能完整展开。
所以 description 和 when_to_use 写得好不好，影响会非常大。它们不是装饰性描述，而是技能能否被正确选中的入口。
三、Skill、Tool、MCP 的关系
图里还有一个很有用的关系：Skill、Tool、MCP 不是一回事。
我的理解是：
- Skill 负责告诉模型“什么时候用、怎么用、有哪些边界”。
- Tool 是可执行能力，比如读写文件、运行命令、搜索、编辑代码等。
- MCP 是外部能力接入层，可以把外部服务、数据源、API、资源暴露给模型使用。
也就是说，Skill 更像一份使用说明和行为约束，Tool 是手，MCP 是外部世界的接口。一个好的 Skill 不一定自己提供能力，但它能组织上下文、限定工具、给出流程，让模型在正确的范围内调用能力。
这也解释了为什么 allowed-tools 很重要。不是所有技能都应该拥有所有工具权限，尤其当任务涉及写文件、调用外部服务、执行 shell 或访问敏感资源时，权限边界就会决定系统是否可靠。
四、执行流程其实很像一个小型运行时
从图里的执行流程看，一个 Skill 被选中后并不是立刻“把 prompt 扔给模型”。它大致会经历这些步骤：
- 加载完整 Skill，读取 SKILL.md 全部内容，比如 prompt 模板、示例和约束。
- 解析参数，比如用户显式传入的
$ARGUMENTS或类似占位符。 - 构建执行上下文，把外部上下文、工作区信息、任务状态组织起来。
- 限制工具权限，只允许调用 allowed-tools 中声明的工具。
- 调用模型执行，让 Claude 完成任务。
- 返回结果，可能是文件、代码、解释、下一步建议或测试结果。
所以 Claude Code 的 Skill System 不只是一个目录扫描器，它更像一个 runtime：里面有 Skill Loader、Skill Catalog、Skill Resolver、Skill Executor。发现、选择、加载、执行，每一步都有明确责任。
五、信任级别和安全边界
图里把信任等级也列了出来，这一点很现实。
内置技能和企业托管技能通常信任度更高，因为它们受控、可审查、治理链路更明确。用户技能和项目技能更灵活，但也更依赖个人或团队的维护质量。MCP 来源的技能或外部能力风险最高，因为它可能连接外部服务、网络资源，甚至间接触发 shell 或 API 行为。
这让我想到一个很实际的原则：能力越强，越要有边界；离外部世界越近，越要有约束。
AI Agent 真正落地时，问题不只是“能不能做”，还包括“该不该做”“能做到什么范围”“失败时怎么处理”“会不会误用工具”。Skill 系统正是在这些地方发挥作用。
六、今天的小结
这张 Claude Code Skills 全景图给我的最大启发是：当技能数量变多之后，系统的核心难点不再是“有没有这个能力”，而是“如何找到正确能力，并在正确边界里使用它”。
所以一个高质量 Skill 至少要回答清楚几件事：
- 它能解决什么问题？
- 什么情况下应该使用它？
- 需要哪些参数和上下文？
- 它允许使用哪些工具？
- 它的执行流程和输出标准是什么？
如果说 Prompt 是对模型说话，那 Skill 就是在给模型写一份可复用、可治理、可执行的工作契约。
今天给自己记一句话：
当 skills 从几十个变成上千个，真正重要的不是“多”，而是可发现、可过滤、可选择、可约束、可执行。
配图
下面放三张图：一张是原始全景图，两张是我重新整理的简化图，方便后面快速回看。
