很多人用 Claude Code，就是打开终端，问个问题，等它回答。用着用着就发现不对劲了：上下文越来越乱，加了一堆规则它反倒不听话了，skill 越来越多也不知道哪个有用。

其实 Claude Code 不是这么用的。

今天这篇文章不讲那些基础操作，只说真正影响成败的几个核心点。不管你是刚上手还是用了一段时间，看完这篇，对 Claude Code 的理解应该能串起来了。

一、Claude Code 不是聊天框

很多人第一次用，觉得这就是个能跑命令的 AI 对话框。

其实不是。它的核心是一个不停转的循环：收集信息 → 干活 → 看看干没干对 → 没干对就再来一遍。

这个循环会一直转，直到任务做完。每一轮它都在做三件事：看看现在有什么信息、决定下一步干啥、检查刚才干的对不对。

你遇到的大部分问题——回答不准、改错文件、忘了之前说过什么——其实都不是模型不够聪明，而是这个循环里的某个环节出问题了。最常见的就是：你给了它错误的信息，或者它干完了但没法判断自己干没干对。

把这个逻辑搞清楚了，后面的东西才有根。

二、六个层次，一个都不能少

把 Claude Code 拆开看，其实是六层。每层解决不同的问题：

第一层：CLAUDE.md / rules / memory —— 长期记忆

告诉它你是谁、这个项目是干什么的、有什么规矩。每次开新会话都会加载，这是它的底子。

第二层：Tools / MCP —— 能干的事

读文件、改代码、跑命令、调接口，这些都是工具层给的。

第三层：Skills —— 按需加载的方法

告诉它遇到这类事该怎么干。不是每次都加载，需要的时候才拉进来，像个方法包。

第四层：Hooks —— 必须执行的规则

不靠它自己记，而是在特定时候强制执行。比如改完文件自动跑格式化，动了重要文件直接拦住。

第五层：Subagents —— 派出去干活的人

派一个独立的 Claude 去干一件具体的事，干完回来汇报。好处是隔离——中间的乱七八糟不会污染主线程。

第六层：Verifiers —— 验证闭环

让它的输出能被检查、能撤回、能翻记录。没有这层，它说干完了你也不知道到底干没干对。

这六层的问题在于：只强其中一层，整个系统就会偏。CLAUDE.md 写太长，上下文先把自己搞乱了；工具堆太多，它不知道该用哪个；Subagent 开得到处都是，状态就漂移了；验证这步跳过了，出问题都不知道在哪。

三、上下文工程：大多数人卡在这

很多人觉得上下文就是容量问题——200K token 够大了，随便塞。但真正卡住你的地方，不是不够长，而是太吵了。有用的信息被一堆没用的东西淹没了，它找不到重点。

200K 并没有全部给你用

Claude Code 的 200K 上下文，真正能用的大概 160K-180K。剩下的被这些东西占了：

• 系统指令：约 2K

• 启用的 Skill 描述：约 1-5K

• MCP Server 工具定义：约 10-20K（这个是最大的隐形杀手）

• LSP 状态：约 2-5K

• CLAUDE.md 和 Memory：约 3-7K

一个典型的 MCP Server（比如 GitHub）有 20-30 个工具定义，每个约 200 tokens。接 5 个 Server，光这部分就吃掉 25000 tokens，占总量 12.5%。在需要读大量代码的时候，这 12.5% 就很要命了。

什么该常驻，什么该按需

我自己用下来的经验是：

• 始终常驻：CLAUDE.md 里放项目契约、构建命令、禁止的事

• 按路径加载：.claude/rules/ 里放语言、目录相关的规则

• 按需加载：Skills 里放工作流和领域知识

• 隔离加载：Subagents 负责大量探索和并行研究

• 不进上下文：Hooks 负责确定性的脚本、审计、阻断

说白了，偶尔用的东西就不要每次都加载进来。

压缩机制有个坑

Claude Code 有个自动压缩功能。上下文快满的时候，它会把早期的对话内容缩成摘要，腾出空间继续聊。

听起来挺好？但默认的压缩算法有个问题：它按“能不能重新读取”来判断优先级，早期的工具输出和文件内容会被优先删掉。问题是你两小时前定的架构决策、约束理由，也会被一起扔掉。

两小时后再改代码，它可能根本不记得之前定了什么，莫名其妙的 bug 就这么来的。

解决办法：在 CLAUDE.md 里写 Compact Instructions，告诉它压缩的时候必须保留什么：

## Compact Instructions

When compressing, preserve in priority order:
1. Architecture decisions (NEVER summarize)
2. Modified files and their key changes
3. Current verification status (pass/fail)
4. Open TODOs and rollback notes
5. Tool outputs (can delete, keep pass/fail only)

还有个更主动的办法：开新会话前，让它写一份 HANDOFF.md，把当前进度、试过什么、什么走通了、什么是死路、下一步该做什么写清楚。下个会话只读这个文件就能接着干，不依赖压缩的摘要质量。

几个有用的习惯

• 用 /context 随时看 token 占用，别等系统自动压缩了才补救

• 任务切换用 /clear，同一任务进新阶段用 /compact

• 长会话主动看消耗，MCP 工具定义是最容易被忽略的大头

• 不用的 MCP Server 及时断开，别让它白占上下文

四、CLAUDE.md：这是你和它之间的约定

CLAUDE.md 是整个体系里最基础也最容易写错的东西。

很多人把它当文档库用，恨不得把项目背景、API 文档、团队规范全塞进去。结果每次会话一开始，它就被一堆信息淹没了，真正重要的指令反而被稀释了。

我的建议很简单：一开始什么都不写。

先用起来，等你发现自己老是在重复同一件事——比如每次都要提醒它“跑测试再提交”、“别动 .env 文件”——再把这些补进去。

该放什么

• 怎么 build、怎么 test、怎么跑（最核心的）

• 关键目录结构和模块边界

• 代码风格和命名约束

• 不明显的环境坑

• 绝对不能干的事（NEVER 列表）

• 压缩时必须保留的信息（Compact Instructions）

不该放什么

• 大段背景介绍

• 完整 API 文档

• “写高质量代码”这种空话

• 它读一下仓库就能猜出来的信息

• 低频任务的详细知识（这些放到 Skills 里）

一个简单的模板

# Project Contract

## Build And Test
- Install: `pnpm install`
- Dev: `pnpm dev`
- Test: `pnpm test`
- Lint: `pnpm lint`

## Architecture Boundaries
- HTTP handlers live in `src/http/handlers/`
- Domain logic lives in `src/domain/`
- Do not put persistence logic in handlers

## Safety Rails

### NEVER
- Modify `.env`, lockfiles, or CI secrets without approval
- Commit without running tests

### ALWAYS
- Show diff before committing
- Update CHANGELOG for user-facing changes

## Compact Instructions
Preserve:
1. Architecture decisions (NEVER summarize)
2. Modified files and key changes
3. Current verification status
4. Open risks and TODOs

Anthropic 官方自己的 CLAUDE.md 大概只有 2.5K tokens。短、硬、可执行，这是核心。

让 Claude 自己维护 CLAUDE.md

这是我特别喜欢的一个技巧：每次纠正它的错误后，直接告诉它——

“Update your CLAUDE.md so you don't make that mistake again.”

它在给自己补规则这事上其实挺好用的。用久了确实越来越少犯同样的错。不过也要定期看看，时间长了总有些条目会过时。

五、Skills：不是模板，是用的时候才加载的方法包

很多人第一次听说 Skills，以为就是“保存的 Prompt”。

不是的。Skill 的核心是“按需加载”——描述符常驻上下文（告诉它什么时候该用），但完整内容只在真正需要的时候才拉进来。

这个设计叫“渐进式披露”：不是让模型一次性看到所有信息，而是先给索引和导航，再按需拉细节。

一个好 Skill 长什么样

四个条件：

• 描述要让模型知道“什么时候该用我”，而不是“我是干什么的”。这两者差很多

• 有完整的步骤、输入、输出和停止条件。别写了个开头没结尾

• 正文只放导航和核心约束，大资料拆到 supporting files 里

• 有副作用的 Skill 要显式禁止自动调用，不然它会自己决定要不要跑

三种典型的 Skill

• 检查清单型：发布前跑一遍，确保不漏项。比如 build 通过了没、版本号改了没

• 工作流型：标准化高风险操作。比如配置迁移，先备份、再 dry-run、确认后再执行、最后验证。内置回滚步骤

• 领域专家型：封装决策框架。比如出问题了，按固定路径收集日志、检查状态、匹配症状，不让它瞎猜

描述符要写短

每个启用的 Skill，描述符是常驻上下文的。优化前后差距很大：

# 低效（~45 tokens）
description: |
  This skill helps you review code changes in Rust projects.
  It checks for common issues like unsafe code, error handling...

# 高效（~9 tokens）
description: Use for PR reviews with focus on correctness.

还有个实用策略：高频用的 Skill 保持自动调用，优化描述符；低频的禁止自动调用，手动触发；极低频的直接删掉，改成文档。

六、Hooks：不靠记性，靠机制保证

Hooks 很容易被忽视，但它解决的问题很关键：有些事情不能靠它自己记得去做。

比如：

• 每次编辑完 Rust 文件，自动跑一下编译检查

• 改了受保护的配置文件，直接拦住不让动

• 任务完成后推个通知

这些事如果写在 CLAUDE.md 里，它经常当没看见。但如果做成 Hook，是在生命周期事件前后强制执行的，不依赖模型判断。

一个实际例子

假设项目同时有 Rust 和 Lua 代码，可以按文件类型分别触发检查：

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "pattern": "*.rs",
        "hooks": [{
          "type": "command",
          "command": "cargo check 2>&1 | head -30",
          "statusMessage": "Checking Rust..."
        }]
      },
      {
        "matcher": "Edit",
        "pattern": "*.lua",
        "hooks": [{
          "type": "command",
          "command": "luajit -b $FILE /dev/null 2>&1 | head -10",
          "statusMessage": "Checking Lua syntax..."
        }]
      }
    ]
  }
}

每次编辑完立刻知道有没有编译错误，比“跑了一堆才发现最开始就挂了”省事太多。

注意限制输出长度

Hook 的输出也会进上下文。所以一定要加 | head -30 之类的截断，避免 Hook 输出反而把上下文搞乱了。

CLAUDE.md + Skills + Hooks 三层配合

• CLAUDE.md 声明规则：“提交前必须通过测试和 lint”

• Skill 告诉它具体怎么做：什么顺序跑测试、怎么看失败、怎么修

• Hook 对关键路径做硬性校验：必要时直接阻断

三样少任何一层都会有漏洞。只写规则，它经常当没看见；只靠 Hook，细节判断做不了。放在一起才稳。

七、Subagents：派一个独立的去干活

Subagent 就是从主对话派出去的一个独立 Claude。它有自己的上下文窗口，只能用你指定的工具，干完了汇报结果。

核心价值不是“并行”，而是隔离。

扫代码库、跑测试、做审查这类会产生大量输出的事，交给 Subagent 做，主线程只拿摘要，不会被中间过程污染。

Claude Code 内置了三种 Subagent：

• Explore：只读扫库，跑 Haiku 模型省成本

• Plan：规划调研，不动文件

• General-purpose：通用型，什么都能干

配置时要显式约束

不要给它和主线程一样宽的权限，否则隔离就没有意义了。几个关键配置：

• tools / disallowedTools：限定能用什么工具

• model：探索任务用 Haiku/Sonnet，重要审查用 Opus

• maxTurns：防止跑飞

• isolation: worktree：需要动文件时隔离文件系统

什么时候不该用 Subagent

子任务之间强依赖、频繁要共享中间状态的场景，用 Subagent 反而更麻烦。这种情况在主线程里顺序做就好。

八、验证闭环：它说“完成了”不算数

这是很多人忽略的一环，但它决定了你能不能真正信任它的输出。

“它说完成了”其实没什么用。你得能知道它做没做对、出了问题能退回来、过程还能查，这才算数。

验证的三个层级

• 最低层：命令退出码、lint、typecheck、单元测试

• 中间层：集成测试、截图对比、contract test、smoke test

• 更高层：生产日志验证、监控指标、人工审查清单

在 CLAUDE.md 和 Skill 里提前写好验收标准：

## Verification

For backend changes:
- Run `make test` and `make lint`
- For API changes, update contract tests

For UI changes:
- Capture before/after screenshots

Definition of done:
- All tests pass
- Lint passes
- No TODO left behind unless explicitly tracked

我自己有个很简单的判断标准：假如一个任务你都说不清楚“什么叫做完”，那它大概率也不适合直接丢给它自动完成。验证标准都没有，它再聪明也跑不出正确答案。

九、高频命令：主动管理，别等系统替你处理

这些命令说白了就干一件事：主动管理上下文和状态。

上下文管理

• /context —— 看 token 占用结构，排查 MCP 和文件读取占比

• /clear —— 清空会话。同一个问题被纠偏两次以上，直接重来

• /compact —— 压缩但保留重点，配合 Compact Instructions 用

• /memory —— 确认哪些 CLAUDE.md 真的被加载了

能力与治理

• /mcp —— 管理 MCP 连接，检查 token 成本，断开闲置 server

• /hooks —— 管理 hooks

• /permissions —— 查看或更新权限白名单

• /model —— 切换模型：Opus 深度推理，Sonnet 常规，Haiku 快速探索

会话连续性

• claude --continue —— 恢复最近会话，隔天接着做

• claude --resume —— 打开选择器恢复历史会话

• claude --continue --fork —— 从已有会话分叉，同一起点不同方案

• claude -p "prompt" —— 非交互模式，接入 CI 或脚本

几个不常见但好用的

• 双击 ESC：回到上一条输入重新编辑，不用重新打。它走偏了，双击 ESC 修改后重发，比重新开会话省事

• Ctrl+B：把长时间运行的命令移到后台，它会之后自动查看结果，不阻塞主线程

• Plan Mode（Shift+Tab 两次）：把探索和执行拆开，探索阶段不动文件，确认方案后再执行。对复杂重构特别有用

• /insight：让它分析当前会话，提炼出哪些内容值得沉淀到 CLAUDE.md。是迭代优化配置的好手段

十、常见坑

用了半年，我总结了几个最常见的误区：

1. CLAUDE.md 当 wiki 用
   每次加载都污染上下文，关键指令被稀释。解决办法：只保留契约，资料拆到 Skills 和 rules 里。

2. 一个 Skill 什么都干
   描述模糊，什么时候该触发都搞不清楚。解决办法：一个 Skill 只做一类事，副作用显式控制。

3. 工具接太多
   MCP Server 堆了五六个，工具定义把上下文挤爆了。解决办法：合并重叠的工具，做明确的命名空间，不用的及时断开。

4. 没有验证闭环
   它说“做完了”就信了，结果过两天发现一堆 bug。解决办法：给每类任务绑定验证步骤。

5. 过度自治
   多个 Subagent 并行，权限全开，出了错都不知道是哪个搞的。解决办法：每个 Subagent 最小化权限和 maxTurns。

6. 上下文不做切分
   研究、实现、审查全堆在主线程，有效信息被稀释。解决办法：任务切换用 /clear，阶段切换用 /compact，重型探索交给 Subagent。

7. allowedTools 堆积不清理
   settings.json 里残留了 rm -rf 之类的危险操作白名单，一旦触发不可逆。解决办法：定期审查权限列表。

写在最后

用 Claude Code 这半年，最大的感受不是 AI 多厉害，而是用好 AI 其实是一件工程活。

模型本身的能力确实强，但能不能发挥出来，取决于你怎么组织上下文、怎么设计约束、怎么验证结果。这些事情不难，但需要有意识地去做。

如果你刚开始用，我的建议是：

• 别急着配置一大堆东西，先裸着用起来

• 发现自己在重复做同一件事的时候，把它写进 CLAUDE.md

• 用 /context 定期看看上下文消耗，找到隐形杀手

• 遇到复杂任务，学会用 Plan Mode 先想再做

• 给关键操作加上 Hook 和验证，别靠它自觉

这些东西做起来不复杂，但差别很大。