深入 Claude® Code.

为什么是 30% · 四层只用了一层

Claude Code 的能力分四层（第 02 章会展开）： ① 直接对话工具（Read / Edit / Bash …） · ② 项目记忆（CLAUDE.md、auto-memory） · ③ 团队扩展（技能 / 子代理 / 钩子） · ④ 多会话编排（并行 / 无人值守）。

我们观察医院团队前三周的日常使用：超过 90% 的对话停留在 Layer I——直接问、直接答、直接补。 没人调用过自己仓库的技能；没人派过子代理做研究；没人写过钩子拦截危险操作。 四层只用了一层，所以是 30%（其实更少）。

举个例子 · 同一个需求，两种成本

需求：在 jeecg-online 模块里加一个表单——把住院患者基础信息收上来。

差 6 倍。不是 Claude 变笨了，是你没把该用的层用上。 这本手册剩下的章节就是把这另外 50% 补回来。

如果你只记本书的一句话，就记上面这句 —— 所有的建议（从 /clear 到子代理、从计划模式到 git worktree） 都是为了同一件事：把上下文当作最稀缺的资源来管理。 第 07 章会算清楚为什么稀缺。

官方原话是 "the harness matters as much as the model" —— 围绕模型搭起来的那一圈（CLAUDE.md · Hooks · Skills · Plugins · LSP · MCP · Subagents）， 决定 Claude Code 的实际能力，比模型分数更甚。换 Opus 不会救你，搭好 harness 才会。

Skills · Subagents · Hooks
用对层级，胜过用对工具。

Explore →
Plan → Code → Commit.

Anthropic 官方推荐的四阶段循环。一句话总结：把"想清楚"和"动手做"分开，避免在错的问题上动手。

为什么是这个顺序 · 每一步都在防一种错

举个例子 · "加个收住院押金的接口"

差 3 倍。越大、越陌生、越跨模块的改动，差距越夸张。

给它一把
尺子。

Anthropic 官方原话："Give Claude a way to verify its work." 全套官方建议里，这一条被反复说是单一最高杠杆率的实践。本章解释为什么。

为什么是最高杠杆率 · 你不是反馈环的替代品，是它的瓶颈

Claude 生成代码靠的是概率——它没有"对错"的内置判断，只有"像不像之前见过的可工作代码"的判断。 所以它会产出"看起来对但实际不工作"的东西。

没有验证手段时，你就是它唯一的反馈环——它写、你跑、你贴报错、它改、你再跑…… 循环里每一步都要消耗你的注意力 + 上下文。 给它一把尺子（测试 / 编译 / 截图比对），它就能自己跑这个循环，你只需要在它收工时看一眼结论。

举个例子 · 把同一句话改成"可验证"

共同点：每个"可验证"版本都明确告诉 Claude 怎么知道做完了—— 测试用例、像素对比、构建通过。"做完"不再是 Claude 自己判断的，是一个客观的二值信号。

把 CLAUDE.md 当代码维护。
不当文档，当宪法。

CLAUDE.md 是每一次会话启动都会被自动注入到对话开头的文件—— Claude 还没看到你说话之前，先看完它。 所以这份文件不是项目说明书，是这个项目下 Claude 的"宪法"：定基调、定红线、定本仓库特有的东西。

为什么越短越好 · 每次启动都在收税

所以官方建议是一句话：对每一行都问"删了会不会让 Claude 犯错？" 如果不会，就删。 50–100 行是合理上限。再多的内容用 @import 拆到 .claude/rules/，按需加载。

# 根 · 定基调
JeecgBoot/CLAUDE.md
  ├─ 项目是什么
  ├─ 模块图 / 架构
  └─ 全局约定

# 子目录 · 定命令
.../jeecg-module-his-zhiye/CLAUDE.md
  ├─ 本模块跑什么 lint
  ├─ 本模块测什么用例
  └─ 本模块特有的坑

# Claude 在该目录工作时
# 会自动加载它，不会污染别处

上下文是最稀缺资源 —
花掉它，就回不来。

上下文 = 这一次会话里 Claude 能"记得"的全部东西 —— 你说过的话、它读过的文件、它跑过的命令的输出。 它有一个固定上限，每次启动从零开始算，用完了不能续杯。 本章只回答一个问题 —— 为什么这玩意儿这么稀缺，又怎么省着花。

为什么稀缺 · 20 万看着多，烧起来很快

举个例子 · 一次跨模块调试有多贵

怎么省着花 · 三条铁律 + 一张指令表

# 反例：让主会话自己读所有文件
read all auth files and tell me how OAuth works...
# → 主上下文瞬间 +50,000 token，能用空间打了对折

# 正例：派给子代理
use a subagent to investigate how our auth
system handles token refresh. report findings.
# → 主上下文只 +1,500 token，节省约 97%

具体 ＝ 更少修正。
模糊 ＝ 你来当 QA。

Claude 能推断意图，但读不到你脑子里。模糊和具体的差距，不是风格问题，是返工次数问题。

为什么具体 = 少返工 · 把"概率分布"塌缩成一个分支

模型对每个词的理解是概率分布——一句"加个测试"，它可能理解成：单元测试、集成测试、端到端测试；用 mock、不用 mock；覆盖正常路径、还是边界条件。 它必须选一个走。选对了你满意；选错了——你只能返工。

举个例子 · 把同一句话改成"具体"

共同模式："动作 + 范围 + 约束 + 成功标准"。 多出来的几十个字是给 Claude 的护栏——它不再需要猜。

三种把上下文塞给它的方式

如果你正在
感到吃力 —— 多半是这五件事之一。

一个 Claude 不够 —
开四个。

前面所有章节都假设：一个人、一个 Claude、一段对话。但 Claude Code 是水平扩展的工具。

# 一行命令
claude -p "explain this"

# 结构化输出
claude -p "list endpoints" \
  --output-format json

git worktree add ../wt-a feature-a
git worktree add ../wt-b feature-b
# 两个 Claude 同时干

for f in $(cat files.txt); do
  claude -p "migrate $f. OK or FAIL" \
    --allowedTools "Edit"
done

我们已经做对了大半 ——
但很多人还不知道。

下面这棵树是 JeecgBoot 仓库里和 Claude Code 相关的全部资产。如果你不知道它们在哪、做什么 —— 这就是你"用不深"的原因。

工具有了 ——
谁来管这套工具？

前 11 章讲怎么用。这一章讲一件容易被忽略的事：这套工具会不会一年后烂掉，决定权不在工具，在团队怎么管它。

为什么要管 · 不管的代价是看得见的

要管的三件事 · 职责、目录、评审

举个例子 · 给本团队的明天清单

理论30% · 实战50% · 沉淀 20%

看文档的培训，团队最多能从 30% 用到 50%。带着仓库练一遍 + 当场沉淀，能到 70-80%。