Claude Code规则拆分方案：轻量模型仍保代码质量

我读到一篇很有启发的文章，内容是“把 Claude Code 的规则下放到 hook 中之后，哪怕用 Haiku 也不会出问题了”，分享给大家。

你不需要把要求 AI 遵守的所有规则都写在 prompt 里。如果连能靠机械判定的规则都依赖 AI 的记忆和判断，在 Context 变长、或是模型轻量化之后，规则遵守率很容易下降。

这个方案的思路是：把“需要判断的规则”留在 playbook（汇总了要求 AI 遵守的作业步骤、判断标准、失败模式等内容的规则集）里，“能用 grep 判定的规则”用 Claude Code 的 hook 强制检查。把确定性检查放到模型外部，就能哪怕用轻量模型也能从底层支撑质量。

更多内容继续往下看：

① 要求 AI 遵守的规则，分为「AI 判断」和「机械判定」两类
像“追踪 Server / Client 边界（一边梳理代码依赖关系和数据流，一边确认 Server / Client 的边界）”“确定根本原因”这类需要判断的工作交给 AI。而 @ts-ignore 禁止、特定模式禁止这类能用 grep 判定的内容，完全没必要让 AI 记下来。

② 只写在 prompt 里的规则，没法成为确定性约束
哪怕把规则写在 playbook（汇总了要求 AI 遵守的作业步骤、判断标准、失败模式等内容的规则集）或是委托 prompt 里，AI 守不遵守都依赖模型本身。当 Context 变长，或是从 Opus 换成 Haiku 这类轻量模型后，规则被漏掉的概率也会大幅提升。

③ 能机械判定的规则，下放到 Claude Code 的 PostToolUse hook
每次 Edit / Write 操作后都会触发 PostToolUse hook（工具执行后自动运行命令的机制），检查是否违规。如果以 exit 2 退出，stderr（错误输出）的内容会原封不动返回给 agent，因此可以在代码刚写完的同一个回合就让 AI 完成修正。

④ 在写入瞬间就解决问题，比事后 review 再检测成本更低
如果 builder 出的错要 reviewer 来找，就会产生“实现 → review → 打回 → 重新修改”的来回沟通。用 hook 就能在代码送到 reviewer 面前之前就解决机械性违规，让 reviewer 可以专注在边界追踪（一边梳理代码依赖关系和数据流，一边确认 Server / Client 等边界）、构建结果确认这类真正需要判断的 review 工作上。

⑤ 把规则迁移到 hook，还能优化 token 消耗
写在 prompt 里的规则哪怕没有触发违规，每次都要放进 Context，会一直消耗 token。用 hook 的话只要不违规就不会添加反馈，只有违规的时候才会返回几行内容给 AI。模式可以从“每次都让 AI 读规则”改成“只在必要的时候指出问题”。

⑥ 把确定性检查放到模型外部后，轻量模型会更好用
在预算限制下，可以让 builder 用 Haiku，reviewer 用 Sonnet。不需要让 Haiku 完全遵守 playbook，只要用 hook 保证能机械判定的质量，只把模糊判断交给模型，就能通过分工来调整成本和质量的平衡。

⑦ 把「预防 → 检测·修正 → 判断」拆分给不同机制处理
用 playbook 提前给 AI 传递实现方针和判断标准，用 hook 立刻检测确定性违规并让 AI 修正，剩下机械判定不了的设计和因果关系交给 reviewer 检查。要点不是什么判断都丢给 AI，而是把工作拆分给各个组件最擅长处理的部分。

⑧ AI 的失败模式，可以改造成下次就能自动防范的机制
以前放在 playbook 的 failure catalog（过去发生过的典型失败模式合集）里的规则，我已经把其中能机械判定的内容都迁移到 hook 了。不要只在出问题的时候提醒 AI 就结束，把它升级成能自动检测复发的机制，用得越久开发环境本身就能积累越多规则。