Claude Code 里 CLAUDE.md、Skills、Commands 到底该怎么用？

这个问题很适合用一个工程化视角来回答：Claude Code 不是靠把提示词越写越长来变稳定，而是靠把项目记忆、复用流程和触发入口放到不同层里。

许多人用 Claude Code 两三天，就会做一件很自然、也很危险的事：把所有东西都塞进 CLAUDE.md。

代码风格放进去，测试命令放进去，Bug 修复流程放进去，Review 标准放进去，发布注意事项放进去，甚至连“每次回答都要先想清楚”这种空泛提醒也放进去。

这个动作不能说错。它至少说明你已经意识到：Claude Code 不应该每次都从零开始猜项目规则。

但如果继续堆下去，CLAUDE.md 很快会变成一个巨大的“项目愿望清单”：什么都写了，什么都不够强，Claude 偶尔遵守，偶尔忘记，你也不知道该怪模型、怪文件、怪上下文，还是怪自己写得太散。

前三篇我们讲了 Claude Code 为什么不是普通聊天框，启动目录和上下文为什么重大，以及从读项目到修 Bug 的完整闭环。

当一套流程开始重复出现，应该把它沉淀在哪里？

答案不是“都写进提示词”，也不是“都做成命令”。更实用的判断是：

· 稳定的项目背景和原则，放进 CLAUDE.md。

· 会重复执行的工作流，做成 Skill。

· 需要你手动触发、带参数、切换会话状态的动作，用 Command。

· 真正需要硬约束的安全边界，交给 settings、permissions 或 hooks。

一、先建立一个判断：记忆不是流程，流程也不是命令

Claude Code 里的这些概念很容易混在一起，由于它们都长得像 Markdown，都能影响 Claude 的行为，也都可能通过 / 触发。

但它们的本质不同。

CLAUDE.md 更像项目里的“长期说明书”。它告知 Claude：这个项目是什么、技术栈是什么、代码风格是什么、哪些目录别碰、测试怎么跑、团队有什么长期约定。

Skill 更像“可复用工作流”。它不是单纯记一句规则，而是把一组步骤、判断标准、参考文件、脚本、输出格式封装起来。列如“修复一个 Issue”“生成一次发布说明”“做一次安全 Review”，这些都比一条规则更复杂。

Command 更像“交互入口”。你在会话里输入 /memory、/init、/agents、/permissions，是在告知 Claude Code 或 CLI：目前切换到某个操作。官方 Commands reference 也明确把 commands 定位成会话里的控制入口：管理权限、清理上下文、运行工作流、切换模型等。

换句话说：

CLAUDE.md 解决：Claude 每次进项目，应该先知道什么？
Skill 解决：这件事我会重复做，能不能封成稳定流程？
Command 解决：我目前要触发哪个动作，带什么参数？

把 Claude Code 当成工程系统看时，这四层最好分开维护：记忆、流程、触发入口、强制边界。

这三个层次分不清，Claude Code 就会变成“靠感觉使用”的工具。分清之后，它才开始像一套工程系统。

二、CLAUDE.md：适合放稳定背景，不适合放所有流程

CLAUDE.md 最适合放三类内容。

第一类是项目背景。

列如：

Project Context
This is a Windows desktop tool written in C++ and Python.
The Python scripts are used for build automation and data processing.
The C++ code under src/native/ is the production runtime.

这类信息稳定、全局有效、每次会话都值得知道。

第二类是长期规则。

列如：

Coding Rules
· Prefer small, reviewable changes.
· Do not edit generated files under dist/.
· When touching parser logic, update tests under tests/parser/.
· On Windows, prefer PowerShell examples unless the user asks for WSL.

第三类是项目入口。

列如：

Common Commands
· Install dependencies: pnpm install
· Run unit tests: pnpm test
· Run type check: pnpm typecheck
· Build: pnpm build

这些东西放在 CLAUDE.md 里，Claude 每次进项目都能少问许多废话。

还有一种很容易漏掉的官方能力：.claude/rules/。如果规则只影响某个目录或某类文件，列如 src/api/**/*.ts、tests/**/*.test.ts，把它拆成 path-specific rule 更合适；根 CLAUDE.md 只保留全局共识。否则一个前端组件规则也会在后端数据库迁移时挤进上下文，读着热闹，实际添乱。

但 CLAUDE.md 不适合承载太复杂的“程序”。

列如你写：

每次修 Bug 时，请先阅读错误日志，再搜索相关文件，再列出假设，再等待我确认，再修改代码，再运行测试，再总结 diff。

这句话可以放，但它不是最好的形态。由于它实则已经不是一条规则，而是一条工作流。工作流一旦变长，就需要输入、步骤、验证、输出格式、失败处理，甚至需要读取额外参考文件。继续塞进 CLAUDE.md，只会让文件越来越长，行为越来越不可控。

官方 memory 文档也提醒过一个关键点：CLAUDE.md 会影响 Claude 的行为，但不是硬 enforcement layer。真正的阻断、权限、沙箱、敏感文件 deny，要靠 settings、permissions 或 managed policy。

所以 CLAUDE.md 的定位应该克制：它负责让 Claude 进入项目状态，不负责把每件事都自动化。

三、Skills：把重复流程从“口头提醒”变成“可复用工序”

当你发现自己第三次对 Claude 说同一段话时，就该思考 Skill。

列如第三篇文章里，我们讲过一个 Bug 修复闭环：

Explore -> Plan -> Change -> Verify -> Diff

如果你每次都手打：

请先不要改代码。先定位相关文件，解释可能缘由，给出修复计划；我确认后再修改，并在修改后运行测试和总结 diff。

这就已经是 Skill 的候选了。

一个最小 Skill 可以长这样：

name: fix-bug-safely
description: Fix a bug through a cautious explore-plan-change-verify-diff workflow. Use when the user provides an error, failing test, issue, or reproduction steps.
Fix Bug Safely
Workflow
1. Read the error, reproduction steps, and relevant project files.
2. Do not edit files yet.
3. Explain the likely cause and list the files that may need changes.
4. Wait for user confirmation unless the user explicitly approved direct changes.
5. Make the smallest reasonable change.
6. Run the relevant test or validation command.
7. Summarize the diff, test result, and remaining risk.
Output
· Root cause:
· Files changed:
· Verification:
· Remaining risk:

这和把一段提示词放进 CLAUDE.md 的区别很大。

CLAUDE.md 是“长期背景”。Skill 是“可调用工序”。它应该有清楚的触发条件、步骤、输出格式和边界。

更重大的是，Skill 还能带支持文件。官方 skills 文档提议把详细参考资料、模板、脚本、示例输出放在 Skill 目录里，只在需要时加载。这样 SKILL.md 不必变成一本巨书。

一个稍微像样的项目 Skill 可能是这样：

.claude/
skills/
fix-bug-safely/
SKILL.md
references/
testing-policy.md
error-patterns.md
scripts/
collect-test-output.ps1

这就是从“我每次提醒一下 Claude”变成“项目里有一条可复用流程”。

对团队来说，这一步很关键。

个人使用时，提示词写在哪里都能凑合。团队使用时，如果每个人都靠自己的一段口头咒语，结果必定不稳定。Skill 至少让流程有了一个可以 review、可以版本管理、可以持续改善的载体。

四、Commands：不是所有可复用动作都应该自动触发

Commands 的价值在于“目前就做这件事”。

列如：

/init
/memory
/permissions
/agents

这些不是普通文本，而是会话控制入口。官方命令参考里也提到，command 要出目前消息开头，后面的文本会作为参数传入。

这件事对自定义工作流也很重大。

假设你有一个发布检查流程。它可能包含：

· 读取 git status。
· 查看最近 commits。
· 检查版本号。
· 跑测试。
· 生成 release notes。
· 提醒人工确认是否发布。

这显然是重复流程，可以做成 Skill。但它也有明显副作用，甚至可能接近发布动作。你不必定希望 Claude 在“看起来要发布”的时候自动触发它。

这时可以让它成为手动 command，并在 Skill frontmatter 里控制自动调用：

name: release-check
description: Run release readiness checks and prepare release notes.
disable-model-invocation: true
Release Check
Run checks, summarize risk, and prepare release notes.
Do not publish, tag, or push unless the user explicitly asks.
ARGUMENTS: $ARGUMENTS

disable-model-invocation: true 的含义很朴素：别让 Claude 自己决定什么时候触发。用户要用，就手动输入。

Command 和 Skill 最容易混淆的地方：

· Skill 是能力和流程。

· Command 是你触发这个能力的入口。

· 有些 Skill 可以自动触发。

· 有些 Skill 必须手动触发。

所以不要问“它到底是 Skill 还是 Command”。更好的问题是：这条流程能不能被自动识别？如果不能，就让用户明确调用。

五、一张决策表：到底放在哪里？

下面这张表可以直接拿去判断。

这张矩阵不是为了背概念，而是为了少做一个错误动作：把所有重复工作都塞进同一个文件。

项目是什么、技术栈是什么：放 CLAUDE.md。缘由是每次会话都应该知道。

代码风格、测试命令、目录约定：放 CLAUDE.md。缘由是稳定、全局、长期有效。

某个模块的详细设计文档：放普通 docs，再在 CLAUDE.md 里做链接。缘由是不要把长文档全塞进启动上下文。

Bug 修复流程：做成 Skill。缘由是它有步骤、有验证、有输出格式。

代码 Review 标准流程：做成 Skill。缘由是它可重复、可审计、可共享。

发布前检查：做成手动触发 Skill 或 Command。缘由是它有副作用，不应自动触发。

临时问答、一次性探索：留在普通对话。缘由是不值得沉淀。

敏感文件禁止读取：交给 settings 或 permissions。缘由是这不是提议，而是硬边界。

保存跨会话经验：根据是否需要人审和团队共享，选择 /memory、auto memory 或 CLAUDE.md。

这张表最重大的不是分类，而是背后的判断标准。

你可以按 6 个问题来判断：

1. 这条信息是不是每次进项目都需要？
2. 它是背景，还是一组动作？
3. 它是否需要参数？
4. 它是否有副作用？
5. 它是否应该自动触发？
6. 它是否需要硬性阻断，而不是行为提议？

前两个问题决定 CLAUDE.md 还是 Skill。中间两个问题决定 Skill 怎么设计。最后两个问题决定 command、permissions、hooks 是否要参与。

六、最小实践：把第三篇的 Bug 工作流沉淀下来

我们拿第三篇的 Bug 修复流程做一个最小实践。

第一步，在项目根目录生成或整理 CLAUDE.md。

可以先用：

/init
然后把全局项目规则压到很克制的范围内：
Project Rules
· Do not edit files before understanding the failing behavior.
· Prefer small changes that can be reviewed in one diff.
· When fixing a bug, always identify the relevant test command.
· Summarize remaining risk after verification.
注意，这里只写原则，不写完整流程。

第二步，把完整流程做成 Skill：

.claude/
skills/
fix-bug-safely/
SKILL.md
SKILL.md 负责具体步骤：
name: fix-bug-safely
description: Use when fixing a bug, failing test, or reproducible error in this project.
Fix Bug Safely
1. Read the error and reproduction steps.
2. Inspect likely files before editing.
3. Explain the hypothesis and ask for confirmation if the fix is non-trivial.
4. Make the smallest change.
5. Run the relevant test command.
6. Summarize diff, verification result, and remaining risk.

第三步，如果你希望它只能手动触发，就加上：

disable-model-invocation: true

这样它就更像一个明确 command：我叫你修，你再按这个流程修。

七、常见误区：不是写得越多越工程化

第一个误区，是把 CLAUDE.md 当垃圾桶。

看到 Claude 忘了一次规则，就补一句；输出不满意，又补一句；跑错命令，再补一句。最后文件越来越长，里面既有项目结构，又有个人偏好，还有一次性事故复盘。

更好的做法是定期清理：

· 长期项目实际留下。

· 重复流程迁移成 Skill。

· 一次性上下文删掉。

· 详细文档放到 docs，再在 CLAUDE.md 里引用。

第二个误区，是把 Skill 当“更大的提示词”。

Skill 不是把一段超长 prompt 换个文件名。好的 Skill 要有触发条件、步骤、输入、输出、验证和边界。能用脚本稳定做的部分，可以放进 scripts；需要人工判断的部分，才交给 Claude。

第三个误区，是把 Commands 当安全边界。

手动 command 可以降低误触发，但它不是安全系统。涉及删除文件、读取密钥、发布、连接外部系统，还是要靠 permissions、settings、hooks 和人工确认。

第四个误区，是照搬第三方 commands 仓库。

GitHub 上已经有许多 Claude Code command collection，这说明复用需求是真实的。但越是“生产可用”的命令集，越应该先看它会读什么、写什么、跑什么 shell、连接什么外部服务、失败时怎么回滚。

好用和可信，是两件事。

八、一个团队可以怎么开始？

如果你是一个人用 Claude Code，可以先只做三件事：

1. 项目根目录写一个克制的 CLAUDE.md
2. 把最常重复的一条流程做成 Skill
3. 用 /memory 定期检查 Claude 到底加载了什么

一开始不用把体系搭得很重。先让长期规则、复用流程和硬边界各有自己的位置，后面才好迭代。

.claude/
skills/
fix-bug-safely/
SKILL.md
review-changes/
SKILL.md
settings.json
CLAUDE.md
docs/
architecture.md
testing.md

团队第一阶段不要追求全自动。

先从低风险流程开始：读项目、修小 Bug、补测试、写 PR 描述、做只读 Review。等这些流程稳定了，再思考 hooks、MCP、subagents、plugins。

九、实践检查清单

沉淀一条 Claude Code 工作流前，先问这 6 个问题：

· 它是长期项目实际，还是一次性上下文？
· 它是一条规则，还是一组动作？
· 它是否每天或每周重复出现？
· 它是否需要参数，列如 issue 编号、文件路径、发布版本？
· 它是否有副作用，列如改文件、跑命令、发布、连接外部系统？
· 它失败后怎么验证、回滚、复盘？

对应关系可以这样记：

长期实际 -> CLAUDE.md
重复动作 -> Skill
手动触发 -> Command
硬性边界 -> Settings / Permissions / Hooks

如果只能记住一句话，就是：CLAUDE.md 让 Claude 进入项目，Skill 让流程可以复用，Command 让你明确触发动作。

这三件事分清后来，Claude Code 才不只是“更会写代码的聊天框”，而是开始有了项目级工作记忆、可复用流程和可控入口。

下一篇，我们就可以继续往外扩一层：MCP、Agents、Subagents 到底解决什么问题，以及为什么它们不是“越多越好”。