Claude Code Hooks、Slash Commands 和 Skills 怎么选：按触发者划分工作流

Claude Code 里的 hooks、slash commands 和 skills，最稳的区分方式不是看哪个功能更高级，而是先问谁触发动作。人需要明确按下开始键时，用 slash command 或用户调用的 skill；Claude 需要加载一套可复用方法、资料和检查表时，用 skill；某个生命周期事件必须稳定执行校验、通知或脚本时，用 hook。

截至 2026 年 6 月 1 日，Claude Code 文档还有一个容易误读的现实：自定义 commands 已经并入 skills，但已有的 .claude/commands/ 文件仍然可用。因此真正的问题不是“旧 commands 文件夹还能不能用”，而是“这个动作应该由人触发、由 Claude 判断触发，还是由运行时事件触发”。只要触发者没有定清，后面写文件、改 settings 或加自动化都会变得脆。

快速路线图

这张表是整套判断的核心。Slash command 解决“什么时候开始”；skill 解决“怎样按同一套方法做”；hook 解决“事件发生时一定执行什么”。三者都能减少重复输入，但风险不同：命令可能被忘记，skill 可能被加载得太宽或太窄，hook 可能在错误时机频繁触发并挡住正常工作。

所以不要把它们都叫自动化。一个发布流程可能需要 /release-checklist 作为人工启动点，一个 release skill 存放步骤和回滚要求，再加一个 hook 阻止错误分支的危险命令。三层都有独立职责才值得组合；如果三层只是在重复同一段提示词，就应该删掉至少一层。

Slash Commands 负责明确时机

Slash command 适合人必须选择启动时刻的场景。你在消息开头输入 /，选择命令，并在需要时附带参数。它像一个会话内按钮，适合开始审查、整理状态、运行某个检查清单、切换会话行为，或者要求 Claude 先计划但不要执行。

最重要的是副作用控制。如果一个动作可能部署、删除、扣费、发布、改大量文件、访问外部服务或切换分支，那么“由人显式启动”就是安全模型的一部分。它可以背后调用 skill 的方法，但启动动作仍然应该可见，不应该只因为想省一句命令就交给自动判断。

当前文档把自定义 commands 并入 skills，并不等于 slash command 这个调用界面消失。更准确的说法是：skill 成为更丰富的自定义工作流包装方式，而 /skill-name 可以给需要手动启动的 skill 一个清楚入口。旧 .claude/commands/*.md 仍能存在，但新工作流通常要先问是否需要 skill 的元数据、辅助文件、脚本和工具控制。

一个干净模式是：内置命令做会话控制；用户调用的 skill 做可复用流程；旧命令文件只保留小而稳定的历史用途。只要没有明确的人为时机需求，就不要急着新增 slash command。它可能只是一个该由 Claude 在相关任务中加载的 skill，也可能是一个应该在事件边界执行的 hook。

Skills 承载可复用方法

Skill 的价值不在于“我喜欢的一段提示词”，而在于它把一套可复用方法打包起来。一个好的 skill 通常有 SKILL.md、说明、例子、参考文件、脚本、模板和边界。它让 Claude 在需要时拿到一套工作法，而不是把所有规则塞进常驻项目说明里。

适合写成 skill 的任务通常会反复出现，而且每次都怕漏步骤。比如按同一证据清单做 PR review、按公司格式写 API 文档、按 source truth pack 做本地化、按迁移规则审计代码，或者按固定浏览器 QA 步骤检查前端。只要这套方法重新解释一次会浪费时间或带来风险，skill 就有意义。

Skill 也可以控制调用方式。有些 skill 适合让 Claude 在上下文匹配时自行加载；有些必须由用户明确调用。凡是有副作用、会花钱、会触碰生产、会联系外部系统或可能改大量文件的 skill，都应该偏向用户调用。这样既保留了可复用方法，又没有丢掉人工启动的安全边界。

如果你已经决定走 skill 路线，再去看本地的 /zh/posts/claude-code-best-skills 会更合适。当前这篇判断的是 skill 什么时候应该成为工作流表面，而不是替你列出所有可安装 skill。缺的如果是外部系统访问，不要让 skill 承担它做不到的事；那通常要看 MCP 或现有工具权限。

Hooks 执行事件里的确定性约束

Hook 适合“事件发生时必须做”的动作。它可以在工具使用前后、会话开始或结束、通知、压缩上下文、特定生命周期点等位置触发，并调用 command、HTTP、prompt 或 agent handler。它的优势不是更聪明，而是更稳定：只要事件发生，规则就会跑。

适合 hook 的例子包括：文件编辑后记录日志或跑格式化；危险 Bash 命令前检查受保护路径；会话开始时注入少量当前上下文；需要人注意时发通知；结束时写一条紧凑记录。共同点是规则很窄，可以用短消息解释通过或失败。

不要把主观审查放进 hook。问题是“这次 review 的判断是否充分”，应该交给 skill、subagent 或人工启动的审查流程；问题是“这个命令是否要删除受保护目录”，才适合 hook。Hook 越自动，越要可预测。先从观察和记录开始，信号稳定后再考虑阻断。

还要避免把 hook 当记忆系统。如果 Claude 需要在开始工作前看到一条长期规则，应放进合适的项目说明或记忆表面；hook 是事件执行，不是隐藏的政策文档。遇到“Claude 总是忘记某事”，先判断那是方法、记忆、访问还是事件约束，而不是直接加 hook。

组合时每层必须有独立职责

强工作流经常会组合这三个表面，但组合不是炫技。只有当每层承担不同职责时，组合才会降低风险。可以用一句话验收：命令决定启动时机，skill 教方法，hook 守住一个窄不变量。

坏组合通常很模糊：command 重复 skill，skill 试图硬执行政策，hook 又让 Claude 做复杂判断。好组合是可解释的：这一步为什么必须人工启动，这套方法为什么要复用，这个事件规则为什么必须自动执行。解释不出来，就先拆掉。

停止规则：不要把 .claude 做成一团隐藏自动化

第一条停止规则：不要把细腻判断放进 hook。Hook 可以拦截命令模式、验证路径、记录事件或发通知，但不该决定一段架构评审是否“足够好”。判断型任务交给 skill 或显式 review。

第二条：不要自动触发破坏性 skill。发布、部署、删除、扣费、生产修改和大规模重写，都应保留人工启动点。把方法放进 skill 可以，开始按钮仍然要可见。

第三条：不要把一次性提示词做成 skill。Skill 需要重复价值、支持文件、模板、示例或脚本。只有一句喜欢的 prompt，还不值得占一个扩展表面。

第四条：不要把命令清单当策略。知道很多 / 命令没有用，关键是知道当前动作属于 timing、method、enforcement、access 还是 runtime。缺外部访问时看 /zh/posts/claude-code-best-mcp-servers；缺定期运行位置时看 /zh/posts/routines-in-claude-code。

第五条：不要让 hook 代替项目规则。项目级长期规则应该在合适的说明或记忆里，hook 只做事件边界上的小动作。隐藏自动化越多，下一位维护者越难判断为什么 Claude Code 在某个步骤突然变慢、阻断或改写输出。

实施前的设计清单

真正落地前，按顺序回答七个问题。谁触发这项工作：人、Claude，还是运行时事件？它是一次性动作，还是可复用方法？它必须自动发生吗？规则能否确定性检查？动作是否会带来成本、删除、发布或生产影响？Claude 是否缺外部数据或操作权限？团队其他人能否理解这个层存在的理由？

答案指向显式时机，就用 slash command 或用户调用的 skill。答案指向方法，就写 skill。答案指向事件里的确定性执行，就配置 hook。答案指向外部系统访问，就看 MCP 或现有工具授权。答案指向无人值守的循环，就先决定运行位置，而不是急着写 .claude 文件。

这个顺序能减少大多数扩展膨胀。一个可维护的设置应该能被一句话解释：这个命令启动流程，这个 skill 保存方法，这个 hook 只守一个不变量。解释越短，团队越容易审查、复制和回滚。

把决定写成团队交接记录

真正容易出问题的不是第一次配置，而是三周后另一个人看到 .claude 目录时不知道为什么存在这些层。每新增一个 slash command、skill 或 hook，都应该留下四个字段：触发者是谁，失败时谁负责，允许它做什么副作用，什么时候应该删除。这个记录可以放在 skill 的说明、项目约定、runbook 或 PR 描述里，但不要只依赖文件名。

对 slash command，交接记录要回答“为什么必须由人按下开始按钮”。例如 /release-check 不是因为 release 很重要，而是因为发布时间、目标分支、回滚窗口和审批状态需要人在当下确认。如果这些输入都能从仓库状态确定，命令可能只是一个 hook 或 CI check；如果它需要判断顺序、异常分支和解释输出，就应该把方法写成 skill。

对 skill，交接记录要回答“它复用了什么方法”。一个合格 skill 至少应该带着稳定目标、可复用步骤、输入输出边界和失败处理。只把常用提示词包起来并不够；团队成员应该能从 SKILL.md 看出何时调用、需要哪些证据、哪些动作不能自动做。如果 skill 开始要求每次都必须执行，那么它可能越界成 hook 或 CI 规则。

对 hook，交接记录要回答“这个事件不变量为什么必须自动执行”。Hook 最适合窄、可检测、低争议的边界：记录工具调用、阻止危险路径、运行 formatter、提醒缺少测试、把事件发送到审计端点。只要规则需要产品判断、上下文权衡或口头解释，就不应该藏在 hook 里。Hook 的价值是确定性，不是把团队讨论自动化。

审查已有配置时，可以按这个顺序清理：先找没人能解释的 hook，再找没有辅助资料的 skill，最后找只是转述 skill 名称的 command。删除比新增更能提高可维护性。一个 .claude 设置越成熟，越应该能指出每层的主人、触发时机、失败路径和回滚办法。

最小可维护配置可以这样写：一个人工入口负责启动 review 或 release，一套 skill 保存证据收集、判断顺序和输出格式，一个 hook 只在工具调用后做日志或格式化。不要让三个层同时生成同一份报告，也不要让 hook 决定是否可以发布。发布前的审批、客户影响、回滚窗口和沟通节奏仍然属于人；重复的检查步骤属于 skill；路径、格式、审计这类可确定规则才属于 hook。这个分工能让失败路径更清楚：命令误用就改入口说明，skill 不稳定就改方法材料，hook 误拦截就改事件规则。

还有一个简单的维护指标：新人能不能在五分钟内说出每个 surface 的用途。如果需要打开多个隐藏脚本才能解释，说明自动化已经越界。先删掉重复层，再补文档，最后才考虑新增 hook 或 skill。团队也可以在 review 模板里加入一行“这个工作为什么不是另一层”，强迫每次变更都说明边界。边界写不清，就先不要合并自动化；先用手动流程跑两次，确认失败模式后再固化，这样后续维护者能看见真实约束，也能判断何时回滚，避免把临时需求变成长期负担。

常见问题

Slash commands 和 skills 现在是不是一回事？

不是。当前文档说自定义 commands 已并入 skills，skill 也可以通过 /skill-name 被调用。但 slash command 仍是会话里的显式调用界面。把 command 当启动时机，把 skill 当工作流包装。

要把所有 .claude/commands 文件迁移成 skill 吗？

不用。已有命令文件能工作就可以保留。只有当流程需要辅助文件、元数据、工具控制、动态上下文或更好发现性时，迁移到 skill 才有收益。

Hooks 是否比 skills 更可靠？

Hook 更确定，不是更高级。配置事件发生时它会执行，所以适合日志、格式化、通知和窄 guardrail；但它不适合代替审查方法、产品判断或复杂推理。

应该先检查什么？

先用 /help 或官方命令文档确认命令可用性，用 /skills 看可用 skill，用 /hooks 或配置调试看事件自动化，用 /context 判断已有规则是否已经加载。看不出缺哪一层，就先别加新层。

项目级规则放在哪里？

广泛、长期、总是需要可见的规则放在项目说明或记忆表面；详细可复用流程放 skill；事件里的窄约束放 hook。不要用 hook 藏一整套项目政策。

简短结论

按触发者选表面。Slash command 负责人工时机，skill 负责可复用方法，hook 负责确定性生命周期事件。需要组合时，每层必须有不同工作；需要外部访问时，不要假装 skill 能解决；需要无人值守时，先决定运行位置。这个规则能让 Claude Code 设置保持可审计、可维护，也更不容易把工作流变成一堆互相覆盖的自动化。