区分 Bundled Skills 与内置命令的关键在于「谁决定何时执行」：前者由 Claude 根据上下文自动调用，后者必须由用户在终端键入触发。这一差异贯穿了加载方式、运行时路径与适用场景，是把 Claude Code 真正用出生产力的分水岭。把这两类机制混为一谈，会让流程要么过度自动化、要么反复手动触发，团队效率始终提不上去。
一、Bundled Skills 是什么、内置命令是什么
Claude Code 的扩展机制分两大族系：内置命令（Built-in Commands）是固化的客户端逻辑，Bundled Skills 是预装的、以 Prompt 为核心的 Playbook。两者最终都呈现为「/xxx」的输入形态，但内部走向完全不同。
| 维度 | 内置命令 | Bundled Skills |
|---|---|---|
| 触发主体 | 用户键入 | Claude 自主调用 |
| 底层形态 | 固定逻辑、无 token 消耗 | 提示词驱动，Claude 自行调度工具 |
| 是否消耗上下文 | 通常不消耗 | 加载时占用上下文窗口 |
| 安装方式 | 随 Claude Code 预装 | 随 Claude Code 预装 |
| 是否可并行派生子代理 | 一般不派生 | 可派生子代理并发执行 |
| 典型代表 | /help、/compact、/clear | /code-review、/debug、/refactor |
举个实际场景：用户主动让会话瘦身时，输入 /compact 是直接调用客户端的压缩逻辑；遇到一段需要自动审查的代码时，Claude 会在合适的语境里自行触发 code-review Skill——用户并没敲这个命令。这两种「/xxx」外形相似，本质却属于两个完全不同的执行层。
二、根本区别：执行机制的三层差异
2.1 触发层：从「我决定」到「它判断」
内置命令的触发完全由用户控制。/help 显示帮助、/compact 压缩上下文、/clear 清空会话、/cost 统计 token 消耗——每一个动作都必须由人显式发起。客户端在收到这些字符后，直接执行对应的本地逻辑，不进入模型推理循环。
Bundled Skills 则把触发权交给 Claude 模型本身。Skill 文件中有一段面向模型的描述（description 字段），Claude 会在判断「当前任务与该 Skill 描述匹配」时，自行决定调用。这种调用对用户是透明的——你看不到「我用了某个 Skill」的过程，只会看到结果。
2.2 运行层：固定逻辑 vs. 工具编排
内置命令走的是客户端硬编码路径。例如 /clear 触发的就是清空消息列表、重置上下文窗口的操作，不会让模型参与决策。这类命令执行迅速、行为可预测，但也因此无法灵活适配复杂任务。
Bundled Skills 走的是「提示词 + 工具调用」路径。Skill 内部是结构化的 Playbook：先定义背景约束，再列出可调用的工具，最后给出执行步骤。Claude 拿到 Skill 后，会按 Playbook 的节奏调用 Read、Grep、Bash 等工具，必要时还会派生 sub-agent 并行处理任务。/simplify 之所以能识别过度设计并改写，是因为它在执行中会读文件、跑命令、对比方案——这远超一个固定命令的复杂度。
2.3 上下文与派生能力层
内置命令一般不进入或改变上下文窗口（/clear 例外，它会主动清空）。Bundled Skills 在被加载时会占据上下文额度，Playbook 越长，单次会话能容纳的活跃 Skill 就越少。代价换来的是派生能力：复杂 Skill 可以在执行中起一组 sub-agent，把任务拆给子进程并发跑，再汇总结果。
三、何时用哪一类：三步决策
把「执行机制差异」翻译成工程决策，可以套用下面这套判断步骤：
- 任务是否每次都需要在「人主动」的前提下执行？若是，优先用内置命令或自定义 Slash Command；
- 任务是否有可被「上下文特征」明确识别的模式（文件名、错误信息、代码 diff）？若是，把它写成 Bundled Skill，让 Claude 自动触发；
- 任务是否需要并行处理多文件、多分支？若是，必须用 Skill，且 Skill 内需显式声明可派生 sub-agent。
3.1 把命令升格为 Skill 的典型路径
很多团队最初用自定义 Slash Command（.claude/commands/foo.md）封装流程，跑了一段后发现「这事其实每次 Claude 自己就该做」。这时候把 foo.md 升级为 Skill：把纯指令拆成「description + 触发条件 + 步骤 + 输出规范」四段，让模型根据 description 自主判断。
---
name: pr-review
description: Review the diff against the project coding standards. Use when a pull request is opened or a branch has unpushed commits.
allowed-tools: Read Grep Bash(git diff:*)
---
按以下顺序审查当前分支的 diff：
1. 调用 `git diff main...HEAD --stat` 拿到改动范围；
2. 对每个改动文件读全文，重点检查命名、错误处理、并发安全；
3. 输出三段：✅ 通过项、⚠️ 建议项、❌ 必须修改项。升级后，Claude 在检测到「开了 PR」或「有未推送提交」时，会自动跑这套审查逻辑，不再需要用户每次都打 /pr-review。这是把「人驱动」切换到「模型驱动」的典型模式。
四、落地时的两个易错点
别把内置命令写得太复杂。 把 /help 改成「用 mermaid 画架构图再推荐命令」这种重负载是反模式——内置命令的优势是「快且零上下文」，一旦加入模型推理，这层优势就消失了。
别给 Skill 塞太多参考材料。 Skill 文件中堆背景、风格指南、说明性长文，会让描述匹配精度下降，模型更容易误触发或漏触发。Skill 应保持「动作导向」：写清楚步骤、允许的工具、期望的输出格式，把知识类内容交给 CLAUDE.md 或独立的规则文件。
到这里，命令与 Skill 的边界就清晰了：把需要人拍板的事交给 /xxx 命令，把模式可枚举的事交给 Skill，二者在工程上各司其职。
常见问题（FAQ）
Q1：自定义 Slash Command 算哪一类？
自定义命令归入命令族，需要手动触发，与 Bundled Skills 的自动调用机制有本质区别。
Q2：怎么判断一个 Skill 是不是该拆分？
当 Skill 文件超过几百行、或开始包含大量条件分支时，应拆为多个子 Skill 或用 sub-agent 模式。
Q3：内置命令能否调用 Skill？
可以，但通常没必要；如需自动触发，直接用 Skill 替代命令更合适。
