Claude Code Harness 05：五层能力如何分工

Claude Code 工作系统做乱，大多数情况不是少了什么，而是什么都想放、什么都不知道该放哪。同一句"最佳实践"，到底该写在 CLAUDE.md 里，做成 skill，还是做成 hook？这个问题不先解决，系统就会长成一锅粥------CLAUDE.md 里有工作流、command 里又重复一遍、skills 再写一版、hooks 再补个提醒，最后连自己都不知道某条规则该去哪改。

这一章的目标是帮你建立一套"放置判断法"。以后遇到任何新规则、新知识、新自动化、新能力，都能先判断它该落在哪一层。

一、五层不是并列功能，而是不同职责

层	主要职责	解决的问题	最适合放什么
Rules	长期约束	哪些线不能越	安全、范围、验证底线、工程约束
Skills	按需方法论	这类任务该怎么做	TDD、Review、Debug、Search、Context Budget
Commands	高频入口	这套流程怎么稳定触发	`/plan`、`/tdd`、`/verify`、`/review`
Hooks	自动化治理	哪些动作不该靠记忆	格式化、审计、提醒、阻断、生命周期动作
MCP	外部能力接入	Claude 怎么连接世界	浏览器、文档、数据库、平台 API

有些东西是原则，有些是方法，有些是入口，有些是自动触发，有些是能力接入。混在一起，系统迟早失控。

二、Rules：系统底线

很多团队写 rules 的方式是"写代码要优雅"、"注意可维护性"、"尽量提高质量"。这些话没错，但它们不像底线，更像倡议书。

Rule 该解决的问题是：无论当前任务是什么，有哪些行为是系统不能容忍的。

md 复制代码

## Rules（好的示例）

- Do not widen scope without explicit confirmation.
- Do not weaken lint, typecheck, or test configuration to make checks pass.
- For multi-file or ambiguous work, start with a plan before editing code.
- Do not claim completion before running verification.
- Do not manually edit files under `src/generated/`.

这些内容在约束行为，而不是在表达美德。

判断一条东西适不适合进 rules，问三个问题：是否应该长期生效？是否在给系统划边界而不是补知识？是否对所有相关任务都成立？三个都答"是"，才适合进 rules。

三、Skills：任务方法论

最容易被滥用的一层。大家一发现 skill 好用，就把所有"稍微有点复杂的说明"都塞进去，最后产出一堆百科全书式的大 skill。

Skill 的本质是"某类任务的操作方法"。它适合承载 TDD workflow、code review checklist、debug 流程、search-first 流程、strategic compact 方法、security review 方法。它不适合当项目介绍、长期规则或知识总集用。

一个好 skill 的特点：触发条件明确、作用范围明确、不重复系统默认常识、有高信号 gotchas、能明显改变 Claude 的默认行为。

md 复制代码

# Bugfix Workflow

When to use:
- A bug is reproducible
- Existing behavior regressed
- Scope should remain minimal

How it works:
1. Reproduce
2. Write failing test
3. Identify minimal fix
4. Run targeted verification
5. Summarize root cause and regression coverage

Gotchas:
- Do not refactor unrelated modules while fixing the bug
- Do not replace missing tests with "manual reasoning"

如果一个 skill 的主要作用只是"给更多背景"而不是"改变工作路径"，那它很可能写错了。

四、Commands：高频工作流入口

从工作系统角度看，command 的价值在于把高频动作产品化成稳定入口。

很多开发工作流的问题不是"你不知道怎么做"，而是每次进入路径不稳定------有时先 plan 有时直接写，有时先测有时后测，有时 review 得很像样有时只说两句。Command 解决的是入口稳定性。

特别适合做成 command 的事情：每天都会用、一旦进入就应该有固定结构、值得让 Claude 每次都从同一个起点开始。

Command 和 Skill 的关系：skill 负责"怎么做"，command 负责"从哪进入"。两者不是替代关系，适合配合使用。比如 /review 是入口稳定，code-review skill 是方法论稳定。

如果你这周已经第三次跟 Claude 说"先不要写代码，先重述需求、列风险、拆步骤，等我确认后再动手"------那它应该变成一个 command，而不是继续停留在口头里。

五、Hooks：系统治理层

Hooks 干的事情有一个共同特点：高频、机械、容易忘、一旦漏掉影响会持续累积。检查 console.log、编辑后自动格式化、TS 文件后自动 typecheck、compact 前保存状态、会话结束时输出总结、长命令提醒后台化------这些如果全靠人类自己记或者靠 Claude"应该会记住"，迟早漏。

Hooks 的价值在于把这些动作从"习惯"提升成"系统行为"。

判断 hook 是否值得加的标准：是否高频、是否机械、是否容易漏。三个都满足就是 hook 候选。

不适合 hooks 的：需要复杂推理的大任务、需要大量上下文才成立的工作流、一次性低频探索性的判断。这些更适合 skill、command 或 subagent。

Hook 的边界很清楚：它不做复杂决策，而是把固定治理动作自动化。

六、MCP：能力接入层

MCP 从分层角度看，解决的是"Claude 能不能接进来"，而不是"接进来以后应该怎么做"。

"如何做 code review"是 workflow 问题，归 skill/command。"如何在浏览器里自动操作页面"是能力接入问题，归 MCP。

最典型的误区是一有新能力需求就先想接个 MCP。但很多时候真正缺的不是"接更多世界"，而是现有能力的治理、上下文预算控制、工作流入口固定化。

MCP 不是工作流本身，只是能力接口。工作流层应该放在 commands、skills、hooks 里。MCP 负责给这些层提供"能接到外部世界"的基础。

七、判断图：一个新需求到底该放哪一层

text 复制代码

1. 长期生效的底线？           → Rules
2. 某类任务的方法论？          → Skills
3. 高频工作流的稳定入口？       → Commands
4. 高频、机械、容易漏的自动动作？ → Hooks
5. 对外部能力的接入？          → MCP
6. 项目级总说明或启动即需知道？  → CLAUDE.md

对应成目录动作：

text 复制代码

项目级总说明 → 改 CLAUDE.md
长期边界    → 改 .claude/rules/*.md
高频入口    → 改 .claude/commands/*.md
高频自动化  → 改 .claude/hooks/hooks.json 和 scripts/
外部能力    → 改 .mcp.json

八、最常见的四种分层错误

把 skill 当规则写。 Skill 全是"请写高质量代码"、"注意安全"、"请先理解需求"------太泛了，不像方法论，更像泛规则。

把 command 当 skill 写。 一个 command 里塞满长篇知识，却没有明确入口结构。结果它不像入口，更像又一份说明文档。

把 hook 当 workflow 写。 希望 hook 做太多复杂推理、一次 hook 解决整条大流程。结果 hook 越来越脆、越来越难调。

把 MCP 当万能增强剂。 什么能力都优先接个 MCP，不去判断它是不是高频刚需、CLI/command 是否更便宜。结果系统越来越重但不一定更稳。

九、速查表

想加的东西	最优先放哪
项目总体说明	CLAUDE.md
长期不可越界规则	rules
某类任务的操作方法	skills
高频工作流入口	commands
自动检查/提醒/阻断	hooks
浏览器/数据库/API 能力	MCP
当前任务进展	session summary / task system

十、小结

Rules 是底线，Skills 是方法，Commands 是入口，Hooks 是治理，MCP 是能力接入。它们之间最重要的关系不是谁更高级，而是谁负责什么。

系统按职责分层之后，就能清楚判断：哪一层出了问题、哪一层该补、哪一层不该再继续堆东西。

下一章讲工作系统里第一个要被固定下来的习惯：为什么复杂任务一定要先 Plan。