Claude Code 的 8 大机制我全踩了一遍：哪些真香，哪些是坑

你有没有遇到过这种情况：明明给 Claude 配了 Skill，让它每次提交前跑一遍代码检查，结果它心情好就跑，心情不好直接跳过？

我们团队上周复盘的时候，把锅甩了三圈。最后发现不是模型的问题，是机制选错了。"提交前自动检查"这种需求，Skill 能做，Hook 也能做，但确定性差了一个数量级------Skill 是"人触发/语义匹配"，模型有权决定调不调用；Hook 是"事件触发/自动拦截"，blocking: true 摆在那儿，模型绕不过去。

这一坑让我把书里的 8 大机制从头到尾又过了一遍，整理出这份踩坑实录。

先给结论：8 大机制里，最容易混的是这 4 个

Harness 有个冰山模型------水面之上是 claude -p "..." 这种命令行交互，占了 10% 能力；水面之下是 8 大机制，覆盖从记忆到编程层，占了 90%。我们踩下来，真正容易混的集中在扩展层的四大正交机制：

机制	触发方式	职责	对应里程碑	我们踩的坑
Commands（斜杠命令）	人触发/显式	标准化入口、固定流程编排	M0 骨架	重复造轮子，其实该写命令
Skills（语义触发）	人触发/语义匹配	隐式知识注入、按需加载	M2	当 Hook 用，结果模型不调
Sub Agents（子智能体）	Claude 自动触发	上下文隔离、任务委派	M3	没隔离上下文，主对话炸了
Hooks（事件触发）	Claude 自动触发	自动守护、确定性约束	M4	该用 Hook 的用了 Skill

这张表是血泪总结。核心认知就一句：同一模型在不同 Harness 下的表现差异，远大于不同模型在同一 Harness 下的差距。Harness 比模型更重要。 这也是为什么我们后来不再纠结调参，转而死磕工程。

技术选型决策树：用最简组件，别过度工程

书里给了一个决策树，我们直接拿来用，按"最简组件"原则选：

bash 复制代码

需求
 ├── 人触发？
 │   ├── 显式指令（固定流程） → Commands（/slash-command）
 │   └── 自然语言描述（领域知识） → Skills（语义匹配，渐进式披露）
 ├── 自动触发？
 │   ├── 事件拦截/防护（确定性约束） → Hooks
 │   └── 上下文隔离/复杂任务委派 → Sub Agents
 ├── 需连接外部系统？ → MCP
 ├── 需嵌入 CI/CD？ → Headless 模式
 ├── 需程序化控制？ → Agent SDK
 └── 需打包分发？ → Plugins

选型原则 ：一个需求能被多种机制满足时，优先选确定性更强、可审计性更高的机制。Hook 能表达就别退回提示词约束------这是踩坑后我们立下的铁律。

举个真实配置。顺便一提，我们给雷达鸭 App（收录中国一人公司/超级个体真实赚钱案例的应用，Uni-app+arkTS+UniCloud）加"提交前检查鸿蒙 API 兼容性"的需求时，第一版用 Skill，模型时灵时不灵；换成 PreToolUse Hook，一把梭：

json 复制代码

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "command": "python .claude/hooks/safety_check.py",
        "blocking": true
      }
    ]
  }
}

blocking: true 是关键------模型想跳过？门都没有。这就是确定性约束和提示词约束的本质区别。Skill 靠模型"自觉"，Hook 靠事件"强制"，选谁取决于你能不能接受偶尔失灵。

叠加协作 vs 互斥单选：它们不是单选题

踩坑初期我们犯过一个错：把四大机制当单选题，"这个需求用 Skill 还是 Hook"问得很认真。后来发现这四个是正交叠加的，不是互斥的。

真实场景：代码审查流程可以这么叠------Command /review 作为显式入口触发固定流程，Skill code-reviewing 注入审查规范（渐进式披露，按需加载），Sub Agent 隔离上下文跑深度分析只把结论扔回主对话，Hook 在 PreToolUse 拦截危险命令、PostToolUse 自动格式化。四层各司其职，胶水代码极少：

yaml 复制代码

---
name: code-reviewing
description: >
  Review code for best practices and potential issues.
  Use when the user asks for code review or mentions
  reviewing changes.
allowed-tools:
  - Read
  - Grep
  - Glob
---

这个 Skill 配置里 allowed-tools 做了最小权限约束------只给读权限不给写。叠加 Hook 的危险命令拦截，双保险。书里反复强调单点防护不可靠，多层叠加才安全，我们信了。

完整工作流：从 SessionStart 到 Stop Hook

把 8 大机制串起来，一个用户意图进来的完整流程长这样：

ini 复制代码

用户意图
   ▼
[1] SessionStart Hook → 注入环境变量、初始化审计
   ▼
[2] 五级记忆加载（顺序别写错）：
    user CLAUDE.md → project CLAUDE.md → .claude/rules/*.md
    → CLAUDE.local.md → 常用命令
   ▼
[3] 路由决策：
    ├─ 命中 Skill？ → 加载 SKILL.md（渐进式披露）
    ├─ 需委派？   → 子智能体（上下文隔离）
    └─ 直答？     → 进入 Agentic Loop
   ▼
[4] Agentic Loop（每轮）：
    LLM 决策 → PreToolUse Hook（拦截）→ 工具执行
    → PostToolUse Hook（格式化/审计）
   ▼
[5] SubagentStart/Stop Hook → 注入团队规范、验证输出质量
   ▼
[6] Stop Hook → 测试质量门控（失败则 block，要求修复）
   ▼
[7] 输出

几个设计缘由踩过才理解透：

渐进式披露------SKILL.md 正文只在命中时加载，不提前塞进上下文。我们早期把所有规范堆在 CLAUDE.md 里，上下文膨胀，模型注意力分散，回答质量肉眼可见地下降。

CEO 委派------子智能体隔离上下文，主对话只收"结论"不收"过程"，保信噪比。有一次我们没隔离，子任务的全量中间过程灌回主对话，token 直接爆了，会话当场卡死。

事件驱动------确定性逻辑用 Hook 而非提示词，不可被模型绕过。这是整本书最核心的工程判断之一。

8 大机制真香与踩坑速记

跑完全部 8 个，给每个一句话评价，省得你们再趟一遍：

Agentic Loop 是心脏，理解它才能理解其他机制都附着在它某个环节上------记忆附着在"记忆加载"环节，Skills 附着在"LLM 推理决策"环节，Hooks 附着在"工具执行"前后。真香。

CLAUDE.md 记忆体系 是地基，五级记忆加载顺序写错就是灾难。我们踩过 project 覆盖 user 配置的坑，排查了一下午。

Commands 最简单，适合固定流程，别拿它做动态决策。造轮子之前先想想能不能写成斜杠命令。

Skills 语义匹配很优雅，但记住它是"人触发"的，模型有权不调。别拿它当确定性约束用。

Sub Agents 上下文隔离是真香点，没隔离的那次会话炸了之后我们就学乖了。

Hooks 是确定性最强的机制，不可绕过。该用 Hook 的别用 Skill，这是我们复盘后定的规矩。

MCP 扩展工具池连接外部系统，配置略繁琐但值得。接个 GitHub server 就能查 PR 查 issue：

json 复制代码

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "your-token-here" }
    }
  }
}

Headless + Agent SDK 是进阶玩法，CI/CD 集成和程序化控制。Headless 模式跑代码审查很爽，一行命令搞定：