Claude Code 功能这么多，先学哪几个？

刚开始用 Claude Code，问个问题、拿段现成代码，大家都觉得挺顺手。真正的烦躁往往是从第二次、第三次开始的：每次开新对话，你都得把项目用什么框架、哪些目录不能碰、改完代码后该怎么跑测试，从头到尾再念叨一遍。

于是你打开文档，看到一长串功能：Slash Commands、Memory、Checkpoints、CLI、Skills、Hooks、MCP、Subagents、Plugins。每一项看上去都能解决点什么，很容易想一口气全配上。

可同样是“它没按我想的来”，原因可能完全不在一个层级。每次提交前都要把一段审查标准手动复制一遍，缺的是一个调用入口；每次换个窗口，Claude 就改用 npm 装依赖、无视项目里的锁文件，缺的是跨会话的长期记忆。

功能一多，排查也会跟着变难。下面的办法是先盯住自己天天重复的那几句话：

• 跨任务通用的规则，写进项目记忆；
• 经常要用的固定流程，做成命令入口；
• 先用一个低风险的小任务验证这两样管不管用，再按真实缺口往上加检查点、Hook 或外部连接。

每加一项都能看清它到底解决了什么，出错时也知道去哪一层找原因。

01 九项能力各自解决什么问题

先想想：你每天反复向它说明的是什么？从这些重复内容入手，逐步建立适合项目的工作方式。把自己的重复动作摸清楚了，下面这张能力清单才不至于变成一堆干巴巴的名词：

先看中间的问题列，挑出两三个当前最困扰你的问题，想清楚需要什么结果，再选择对应能力。

Slash Command 提供斜杠快捷入口，Skill 保存具体方法和参考资料。按 Claude Code 的 Skills 文档，自定义命令已经并入 Skill：一个写好的 Skill 本身就能直接当成命令调用，同一套方法可以共用一个配置。

代码审查、CI/CD 或者团队协作规范里，确实经常把入口、规则、CLI、Hook 甚至专业子代理串在一起用。在把它们拼装成大系统之前，最好先搞明白每一个零件替你扛下了哪一段工作，往后哪一步出差错，你才找得准该去拧哪颗螺丝。

02 为什么要分阶段学

看到这么多功能，谁都容易忍不住想一股脑儿全配齐。试想一下：你把 MCP 外部连接、三个专业子代理外加保存后自动校验的 Hook 一起端上来了，结果连最基本的测试脚本跑什么都还没跟它说明白。

一旦执行失败，你是去排查网络超时、子代理误解、Hook 拦截，还是提示词写得太含糊？几层变量绞在一起，排查起来就是一团乱麻。

起步阶段把步子迈小一点。先写清楚三五条核心项目规矩，把最常用的一个需求存成快捷命令，挑一个微小但真实的任务去验证它管不管用。真正跑顺手了，再往上搭新积木。每多加一块，你都能清清楚楚地看到：它是真解决了原来的痛点，还是又引来了一堆新麻烦。

学习时可以按下面四层逐步推进。

第一层：会稳定发起任务
  |
  |-- 用 Slash Commands 固化高频请求
  |-- 用 Memory 写清项目规则和长期上下文
  |
第二层：会安全修改项目
  |
  |-- 用 Checkpoints 支持试错和回退
  |-- 用 CLI 把简单任务接入脚本或批处理
  |
第三层：会封装可复用能力
  |
  |-- 用 Skills 固化专项方法
  |-- 用 Hooks 做自动检查、记录和安全控制
  |
第四层：会组合复杂工作流
  |
  |-- 用 MCP 连接外部工具和数据
  |-- 用 Subagents 拆分专业职责
  |-- 用 Plugins 打包团队流程

先稳定基础上下文和任务入口：命令减少重复输入，记忆减少重复解释。两者稳定后，再增加回退、自动化和团队协作能力。

这条路径帮助你定位当前阶段。基础不稳时回到命令和记忆；小任务稳定后增加检查点、CLI、Skills 与 Hooks；跨工具、角色或团队时再考虑连接、委派和分发。规划、深度思考、后台任务与远程控制等进阶能力，等遇到相应需求再深入。

官方的 Claude Code 功能总览 也给出了类似的“逐步加”思路：同一条约定 Claude 连错两次，就写进 CLAUDE.md；同一段提示词反复输入，就存成 Skill；第二个仓库也要同样的配置，再打包成插件。

03 从具体困难选择能力

回到你手头真实的日常开发里。像检查未提交变动、按照团队规范拟定 commit 消息这些流程，可以封成命令随手调用。至于项目用什么包管理器、哪些目录不能动、提交前必跑哪些测试，写进 Memory。

三个常见的困难，各自对应一项能力：

• 每次改完代码都要重复要求运行测试：把重复请求保存为 Slash Command。
• 项目使用 pnpm，Claude 却在新会话中反复使用 npm：在 Memory 中保留项目规则。
• 大重构失败后需要手动还原：使用 Checkpoints，并用 Git 保护需要长期保留的版本。

准备跨文件重构、升级核心依赖或者做大扫除时，动手前先想好怎样回退。Checkpoints 能撤回它用文件编辑工具改过的文件，直接敲到终端里的命令、对数据库结构的变更，仍要靠 Git 分支或快照系统兜底。

基础任务能稳定运行后，再按缺口选择扩展：

单项能力不足时，再从使用场景选择组合：

挑组合时，照着眼下的缺口选就行。只看本地代码 diff，一个快捷命令配上几条项目规矩就足够了；真要核对线上的 PR 讨论，再顺手接个外部查询。至于 MCP 和专业子代理，等任务真被卡住的时候再请出场，一点都不迟。

04 从命令加记忆的最小工作流起步

从小项目起步最省心：准备一个快捷命令、一份项目记忆，然后挑个低风险的小任务，亲手检验它们到底灵不灵。

第一步，初始化或手动创建项目记忆，只写 Claude Code 完成任务必需的项目事实。在项目根目录创建 CLAUDE.md，按实际项目修改下面的示例；测试和构建命令要以项目已有脚本为准：

# Project Rules

## Tech Stack

- Next.js
- TypeScript
- PostgreSQL

## Common Commands

- Install dependencies: `npm install`
- Run tests: `npm test`
- Run lint: `npm run lint`

## Coding Rules

- Keep changes scoped to the requested task.
- Do not modify generated files.
- Run tests before summarizing a completed code change.

规则写多了该放哪一层、怎样确认它被读到，可以看 CLAUDE.md 规则越写越乱，怎么整理。

第二步，把你最常用的一类请求写成命令，例如“检查当前改动并给出提交建议”。一个命令至少要说明四件事：检查范围、判断标准、输出格式、遇到不确定情况时怎么处理。把下面的内容保存为 .claude/skills/review-changes/SKILL.md，目录不存在时先创建它：

---
name: review-changes
description: Review uncommitted changes and report risks without modifying files.
---

# Review Current Changes

Review the current uncommitted changes.

Focus on:

- behavior changes
- missing tests
- risky edits
- unclear naming
- files that should not have been changed

Output:

1. Findings first, ordered by severity.
2. Then list test gaps.
3. End with a concise summary.

If the diff is too large, ask me which area to inspect first.

命令里的参数、动态上下文和执行链，把常用请求写成 Claude Code 斜杠命令 有完整说明。

第三步，选一个已有小改动的项目，调用 /review-changes。对照真实结果检查：

• 它读的是当前 diff 吗？有没有按严重程度列问题、遵守项目规则？
• 每条发现有没有位置、行为变化和触发条件？除了行号，还要说明为什么会出错。
• 若读取相邻的未改代码，报告有没有解释它与本次变化的关系？
• 没发现问题时，有没有说明检查范围和未验证项？通用建议不算本次发现。

光看它在回答里把规则背得头头是道没用，那只能证明它“看到了”文件。有没有真执行，全看它落到具体文件上的动作和输出。在这个极小的范围内把链路调通了，后面再挂自动化脚本，你心里才真正有底。

第四步，按实际需要准备目录。下面的命令只创建文件和目录，不会自动安装命令或启用 Hook：

# 准备项目级命令目录或 Skill 目录
mkdir -p .claude/skills

# 准备项目记忆
touch CLAUDE.md

# 确实需要 Hook 时，再准备脚本目录
mkdir -p .claude/hooks

Skill 还需要 SKILL.md，Hook 还需要脚本和事件配置；空目录本身不会改变 Claude Code 的行为。

第五步，等你发现某个动作需要自动检查，再加入 Hook。比如你经常忘记格式化，可以让写文件后自动运行格式化；如果你担心危险命令，可以在运行命令前做拦截。

第六步，等命令、记忆和安全边界稳定后，再考虑 MCP、Subagents 和 Plugins，让新增能力对应明确需求。

完成每个模块后，问自己四个问题：

1. 我能说清这个功能解决什么问题吗？
2. 我能说清它不适合解决什么问题吗？
3. 我能写出一个最小配置或最小命令吗？
4. 我能指出一个常见错误并说明如何排查吗？

答不清时，先把当前这一层弄清楚。高级能力依赖基础配置；前面没分清的职责，接入后续工作流时会更难排查。

05 分清各项能力的职责

相近能力解决的问题完全不同。配置工具链时，先明确每项能力的职责，才能减少日后排查的困难。可以从常见的职责错位检查边界：

例如，“用 pnpm、别动 generated/ 目录、提交前跑测试”放在一个命令里，调用它时能看到，换个任务就可能又得补充。这些要求会跨任务使用，就写进项目记忆，供各个命令共用。

Hook 则要顺着时间想。你想阻止修改，就得在编辑前检查；编辑后才发现问题，文件已经变了，还要处理现有改动。格式规则可以由脚本判断，复杂含义则需要审查方法和依据。先确认要查什么、动作发生到哪一步，再决定交给谁。

06 用实际任务检查工作方式

配好之后，用实际任务检查这五件事：

逐项检查配置。例如常用入口已经好启动，自动检查却只留下“完成”两字，那就先补日志或失败原因；入口本身可以继续用。沿实际缺口修好这一层，再增加配置，才知道后来的改善来自哪里。

今天就可以做的一件事：把你这周对 Claude Code 说过两次以上的话列出来，规则归记忆，流程归命令。其余功能，等真正遇到对应问题时再学。