Claude Code核心用法深度指南

2026年如果说只能深度死磕一个AI工具，那么我一定推荐的是claude code！

但大部分人用Claude Code还停留在”打开终端，输入问题，等回答”这个阶段，

用着用着上下文越来越乱，skill越来越多，规则写了一大堆它却越来越不听话时，彻底崩溃。

今天这篇文章不讲基础操作，只讲影响成败的核心知识。无论你是老手还是小白，读完这一篇，你对 Claude Code 的理解将不再是零散的指令，而是一个清晰、可落地的架构模型。

一、Claude Code 不是聊天机器人

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

其实它的核心是一个循环运转的代理系统：

收集上下文 → 采取行动 → 验证结果 → 完成或者回到收集

这个循环会一直转，直到任务完成。每一轮它都在做三件事：看当前有什么信息、决定下一步做什么、检查做得对不对。

不是模型不聪明，是环节出了问题

为什么这个很重要？因为你遇到的大部分问题——回答不准、改错文件、忘了之前说的话——几乎都不是模型不够聪明，而是这个循环里的某个环节出了问题。

最常见的就是：给了它错误的上下文，或者它写出来了但没法判断对不对，也没法撤回。

搞清楚这个底层逻辑，后面的所有技巧才有根基。

二、理解 Claude Code 的操作系统

我觉得最直观的理解方式，是把 Claude Code 拆成六层来看。每一层解决一个不同的问题：

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

告诉 Claude “你是谁、这个项目是什么、有哪些规矩”。每次开会话都会加载，相当于它的基础认知。

第二层：Tools / MCP —— 动作能力

告诉 Claude “你能做什么”。读文件、改代码、跑命令、调用外部 API，这些都是工具层提供的。

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

告诉 Claude “遇到这类事该怎么做”。不是每次都加载，只在需要的时候才拉进来，像一个个方法包。

第四层：Hooks —— 强制执行的规则

不依赖 Claude 自己判断，而是在特定时机强制执行某些操作。比如每次编辑完自动跑格式化，改了受保护文件直接拦住。

第五层：Subagents —— 隔离的工作者

派一个独立的 Claude 去干一件具体的事，干完汇报结果。核心价值是隔离——不让中间过程污染主线程。

第六层：Verifiers —— 验证闭环

让输出可验证、可回滚、可审计。没有这一层，Claude 只能”觉得自己完成了”，你没法确认它真的做对了。

这六层的关键在于：只强化其中一层，系统就会失衡。

CLAUDE.md 写太长，上下文先把自己污染了；工具堆太多，它选择困难了；Subagent 开得到处都是，状态就漂移了；验证这步跳过了，出了问题根本不知道哪里挂的。

三、上下文工程：90% 的人卡在这里

这是我认为整篇文章最重要的一节。

很多人把上下文当”容量问题”——觉得 200K token 够大了，随便塞。但实际卡住你的地方，通常不是不够长，而是太吵了。有用的信息被大量无关内容淹没，Claude 找不到重点。

你的 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 有一个自动压缩机制。当上下文快满的时候，它会把早期的对话内容压缩成摘要，腾出空间继续聊。

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

两小时后再改代码，Claude 可能根本不记得之前定了什么，莫名其妙的 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)

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

几个实用的上下文管理习惯

用 /context 命令随时查看 token 占用结构，别等系统自动压缩后再补救
任务切换用 /clear，同一任务进入新阶段用 /compact
长会话主动观察消耗，MCP 工具定义是最容易被忽视的大头
不用的 MCP Server 及时断开，别让它白白占着上下文

四、CLAUDE.md：你和 Claude 之间的协作契约

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

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

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

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

该放什么

怎么 build、怎么 test、怎么跑（最核心的）
关键目录结构和模块边界
代码风格和命名约束
不明显的环境坑
绝对不能干的事（NEVER 列表）
压缩时必须保留的信息（Compact Instructions）

不该放什么

大段背景介绍
完整 API 文档
“写高质量代码”这种空泛原则
Claude 读一下仓库就能推断出来的信息
低频任务的详细知识（这些放到 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

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

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

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

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

很多人第一次听到 Skills，会以为它就是”保存的 Prompt”。

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

这个设计背后的理念叫”渐进式披露”（progressive disclosure）：不是让模型一次性看到所有信息，而是先给索引和导航，再按需拉取细节。

一个好 Skill 长什么样

一个好的 Skill 应该满足四个条件：

**描述要让模型知道”什么时候该用我”**，而不是”我是干什么的”。这两个差很多。
有完整的步骤、输入、输出和停止条件。别写了个开头没有结尾。
正文只放导航和核心约束，大资料拆到 supporting files 里。
有副作用的 Skill 要显式禁止自动调用，不然 Claude 会自己决定要不要跑。

三种典型的 Skill 类型

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

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

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

描述符要写短，每个 Skill 都在偷你的上下文

每个启用的 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：不靠 Claude 记性，靠机制保证

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

比如：

每次编辑完 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..."
        }]
      }
    ]
  }
}

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

在 100 次编辑的会话中，每次节省 30-60 秒，累积下来能省 1-2 小时。

注意限制输出长度

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

CLAUDE.md + Skills + Hooks 三层配合

CLAUDE.md 声明规则：”提交前必须通过测试和 lint”
Skill 告诉 Claude 具体怎么做：什么顺序跑测试、怎么看失败、怎么修
Hook 对关键路径执行硬性校验：必要时直接阻断

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

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

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

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

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

Claude Code 内置了三种 Subagent：

Explore：只读扫库，跑 Haiku 模型省成本
Plan：规划调研，不动文件
General-purpose：通用型，什么都能干

配置时要显式约束

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

tools / disallowedTools：限定能用什么工具
model：探索任务用 Haiku/Sonnet，重要审查用 Opus
maxTurns：防止跑飞
isolation: worktree：需要动文件时隔离文件系统

什么时候不该用 Subagent

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

八、Prompt Caching：藏在底层的成本密码

这块很少有人讲，但它直接影响你的使用成本和很多设计取舍。

Claude Code 的整个架构都是围绕 Prompt 缓存构建的。缓存命中率高，不只降低成本，还能获得更宽松的速率限制。

缓存是按前缀匹配的

Claude Code 的 Prompt 按这个顺序排列：

System Prompt → 静态，锁定
Tool Definitions → 静态，锁定
Chat History → 动态
当前用户输入 → 最后

从头到尾，前面不变的部分会被缓存。所以破坏前面的内容 = 破坏缓存。

常见的缓存杀手

在系统 Prompt 里放带时间戳的内容（每次都变）
非确定性地打乱工具定义顺序
会话中途增删工具

那动态信息怎么办？比如当前时间。答案是：别动系统 Prompt，放到用户消息里传进去。Claude Code 自己也是这么做的。

会话中途不要切换模型

Prompt 缓存是模型唯一的。假如你已经和 Opus 对话了 100K tokens，想问个简单问题切到 Haiku——实际上比继续用 Opus 更贵，因为要为 Haiku 重建整个缓存。

确实需要切换的话，用 Subagent 交接：让 Opus 准备一条交接消息给另一个模型就行。

九、验证闭环：Claude 说”完成了”不算数

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

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

验证的三个层级

最低层：命令退出码、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

我自己有个很简单的判断标准：假如一个任务你都说不清楚”什么叫做完”，那它大概率也不适合直接丢给 Claude 自动完成。

验证标准本身都没有，Claude 再聪明也跑不出正确答案。

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

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

上下文管理

/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：回到上一条输入重新编辑，不用重新手打。Claude 走偏了，双击 ESC 修改后重发，比重新开会话省事
Ctrl+B：把长时间运行的命令移到后台，Claude 之后会自动查看结果，不阻塞主线程
Plan Mode（Shift+Tab 两次）：把探索和执行拆开，探索阶段不动文件，确认方案后再执行。对复杂重构特别有用
**/insight**：让 Claude 分析当前会话，提炼出哪些内容值得沉淀到 CLAUDE.md。是迭代优化配置的好手段

十一、常见反模式：这些坑我替你踩过了

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

1. CLAUDE.md 当 wiki 用

每次加载都污染上下文，关键指令被稀释。解决方案：只保留契约，资料拆到 Skills 和 rules 里。

2. 一个 Skill 什么都干

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

3. 工具接太多

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

4. 没有验证闭环

Claude 说”做完了”就信了，结果过两天发现一堆 Bug。解决方案：给每类任务绑定验证步骤。

5. 过度自治

多个 Subagent 并行，权限全开，出了错都不知道是哪个搞的。解决方案：每个 Subagent 最小化权限和 maxTurns。

6. 上下文不做切分

研究、实现、审查全堆在主线程，有效信息被稀释。解决方案：任务切换用 /clear，阶段切换用 /compact，重型探索交给 Subagent。

7. allowedTools 堆积不清理

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

十二、工程化布局：一个完整的项目配置参考

如果你想给自己的项目配一套比较完整的 Claude Code 工程布局，可以参考这个结构，不用全做，按需裁剪：

Project/
├── CLAUDE.md                          # 项目契约
├── .claude/
│   ├── rules/                         # 按路径/语言的局部规则
│   │   ├── core.md
│   │   ├── config.md
│   │   └── release.md
│   ├── skills/                        # 按需加载的方法包
│   │   ├── runtime-diagnosis/         # 统一收集日志和状态
│   │   ├── config-migration/          # 配置迁移回滚
│   │   ├── release-check/             # 发布前校验
│   │   └── incident-triage/           # 线上故障分诊
│   ├── agents/                        # 自定义 Subagent
│   │   ├── reviewer.md
│   │   └── explorer.md
│   └── settings.json                  # 权限和 Hook 配置
└── docs/
    └── ai/
        ├── architecture.md            # 架构细节
        └── release-runbook.md         # 发布手册

全局约束（CLAUDE.md）、路径约束（rules）、工作流（skills）和架构细节完全解耦。

如果你同时维护多个项目，可以把稳定的个人基线放在 ~/.claude/，各项目的差异放在项目级 .claude/。不同项目之间就不会互相污染了。

十三、三个阶段：你现在在哪里

用 Claude Code 大概会经历三个阶段：

第一阶段：工具使用者。 关注的是”这个功能怎么用”。有帮助，但有限。

第二阶段：流程优化者。 开始写 CLAUDE.md 和 Skills，关注”如何让协作更顺”。效率明显提升。

第三阶段：系统设计者。 关注”如何让 Agent 在约束下自主运作”。这时候关注点悄悄变了——从功能层面升到了治理层面。

这两件事的差别其实很大。

大部分人停在第一阶段，把 Claude Code 当一个更强的对话框用。少部分人到了第二阶段，开始有意识地组织上下文和工作流。真正到第三阶段的人，已经在思考怎么设计一套系统，让 Claude 在明确的边界内自己跑起来。

写在最后

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

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

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

别急着配置一大堆东西，先裸着用起来
发现自己在重复做同一件事的时候，把它写进 CLAUDE.md
用 /context 定期看看上下文消耗，找到隐形杀手
遇到复杂任务，学会用 Plan Mode 先想再做
给关键操作加上 Hook 和验证，别靠 Claude 自觉

这些是我半年踩坑换来的一些总结，肯定还有很多没挖掘到的地方。如果你有更好的用法，欢迎在评论区告诉我。

我是 Jacky，关注我，陪你在 AI 时代，无限生长。

本文来自转载Jacky无限生长，不代表发现AI立场，如若转载，请联系原作者；如有侵权，请联系编辑删除。