《Claude Code 如何用规则、技能和子代理控制工作流》

导语

这篇 Claude Blog 文章是一份 Claude Code 自定义机制的结构化指南。它逐一比较规则、技能、子代理、钩子、输出样式、追加系统提示和实践建议，核心问题不是“把指令放在哪里都行”，而是：不同指令有不同加载时机、上下文成本、压缩行为、确定性和适用场景。正确配置能让 Claude 更省上下文、更可靠，也更不容易把团队规则和个人偏好混在一起。

1. 规则：适合文件范围内的约束，而不是所有会话常驻

规则是放在 .claude/rules/ 里的 markdown 文件，用来给 Claude 特定约束或约定。不限定范围的规则像 CLAUDE.md 一样，会在会话开始时加载，并在压缩后重新注入；如果规则和当前任务无关，就会浪费 token。

路径范围规则通过 frontmatter 里的 paths 字段控制何时加载。例如只适用于 src/api/ 和 /*.handler.ts 的 API 规则，在文档任务里不会进入上下文，只有 Claude 读取相关目录文件时才加载。文章的建议是：像“所有 API handler 必须先用 Zod 校验输入”或“migrations 只能追加”这类跨多个角落、但不是全仓库适用的约束，适合放在带路径范围的规则里，而不是嵌套的 CLAUDE.md。

2. 技能：适合可复用流程，只在调用时加载完整说明

技能位于 .claude/skills/，每个技能是一个包含 SKILL.md、脚本和资源的文件夹。会话开始时只加载技能名称和描述，完整正文只有在 slash command（例如 /code-review）或任务自动匹配时才加载。

技能适合部署流程、发布清单、代码审查等程序化 playbook。内置 /code-review 就是例子：它检查当前 diff 并报告发现，不直接改文件。压缩时，Claude Code 会把已调用技能重新注入，但所有已调用技能共享预算；调用太多时，最早的技能会先掉出上下文。因此，技能的价值在于把长流程从常驻上下文移到按需加载，同时让每次执行遵循同一套结构。

3. 子代理：适合隔离副任务，避免主上下文被中间结果污染

子代理定义在 .claude/agents/，同样是 markdown 文件，frontmatter 包含名称、描述、可选模型和工具权限，正文成为子代理的系统提示。会话开始时只加载名称、描述和工具列表；正文不会自动进入父会话，而是由 Agent 工具带着 prompt 调起。

子代理和技能的关键差异是隔离。子代理在新的上下文窗口中运行，父会话只收到最终消息和元数据，中间搜索、日志分析、依赖审计等过程不会挤占主线程。子代理最多可嵌套五层，动态工作流可以编排几十到几百个后台 agent；计划和中间结果存放在脚本变量里，而不是 Claude 的主上下文里。文章的取舍很清楚：如果你想在主线程里看见并引导每一步，用技能；如果副任务会产生大量一次性中间结果，用子代理。

4. 钩子：适合必须确定发生的动作和防线

钩子是用户定义的命令、HTTP endpoint 或 LLM prompt，会在文件编辑、工具调用、会话开始等生命周期事件上触发。它们可注册在 settings.json、托管策略设置或技能/代理 frontmatter 里，类型包括 command、HTTP、mcp_tool、prompt 和 agent。

前三类钩子确定性执行，prompt 和 agent 类型则使用模型判断产生输出。钩子的上下文成本低，因为配置或指令在主上下文外；handler 由 harness 执行，或在独立窗口里做模型调用。大多数钩子输出不会保存到主上下文，除非配置要求返回；阻塞钩子的标准错误会进入上下文，让 Claude 知道调用为什么被拒绝。如果某件事必须稳定发生，比如编辑后运行 linter、完成后发 Slack、执行前阻止特定命令，就应该用钩子或权限，而不是只写提示词。

5. 输出样式：权重最高，但容易不小心替换默认工程师行为

输出样式位于 .claude/output-styles/，会把指令注入系统提示。它们每次会话开始加载，永不被压缩，首次请求后缓存，具有中等上下文成本。因为位于系统提示中，输出样式拥有本文已讲机制里最高的指令遵循权重，应谨慎使用。

风险在于：修改输出样式会替换默认样式，除非在 frontmatter 中设置 keep-coding-instructions: true。默认工程师行为里包含如何界定改动范围、何时加注释、如何处理安全担忧、完成前运行测试等关键习惯；如果自定义样式覆盖掉这些，Claude Code 可能从软件工程助手变成泛用助手。文章建议先看内置 Proactive、Explanatory 和 Learning 三种样式，它们覆盖自治、教学和协作编码的常见需求。

6. 追加系统提示：适合单次补充，不适合堆很多互相竞争的要求

append-system-prompt 是修改输出样式的替代方式。它只是在原始系统提示上追加，不改变 Claude 的默认角色；并且只在本次 invocation 生效，不像文件那样跨会话持久存在。

代价是上下文成本较高，因为它会增加输入 token；虽然 prompt caching 会降低会话内后续请求成本，但要求 Claude 更详细或更长，也会提高输出 token。文章建议把它用于具体编码标准、输出格式或领域知识；但追加指令存在边际收益递减，指令越多，特别是互相冲突时，遵循越不稳定。

7. 快速判断：不要把所有东西都塞进 CLAUDE.md

文章最后给出一组位置选择规则。凡是“每次 X 都要 Y”的确定性行为，如编辑后运行 formatter 或完成后发 Slack，应使用钩子，而不是让模型选择要不要执行。凡是“绝不能做”的防线，不应只写在 CLAUDE.md；模型在长会话、压力或 prompt injection 下可能失守，真正防线应是钩子、权限或管理员托管设置。PreToolUse 钩子可以检查工具调用并用 exit code 2 阻止。

长达 30 行的流程不适合放在 CLAUDE.md，应放进技能；CLAUDE.md 更适合常驻事实，如构建命令、monorepo 布局和团队约定。只适用于 API 的规则应写路径范围，避免无范围规则像 CLAUDE.md 一样常驻。个人偏好也不该写进项目级 CLAUDE.md；文件式机制通常有用户级对应物，项目级文件应只保留团队范围、代码库特定的偏好。最后，文章建议成熟后可把技能、子代理、钩子和输出样式打包成 plugin，方便团队或项目共享。

思想框架

文章的论证顺序是从“指令放哪里”拆成一张机制选择表：规则按路径控制约束加载，技能按需加载流程，子代理隔离副任务，钩子提供确定性自动化和防线，输出样式改变系统层行为，追加系统提示适合单次补充，CLAUDE.md 则只适合常驻事实。它反复强调同一个判断：提示词不是万能治理层。可靠性来自把指令放到合适执行层级里，让确定性行为交给钩子和权限，让长流程进技能，让副任务进子代理，让团队规则和个人偏好分层保存。