Claude Code 精通指南 第2篇：心智模型

有个真相，区分了那些热爱 Claude Code 的开发者和觉得它不好用的人：理解它的思维方式，一切都会改变。

大多数人把 Claude Code 当搜索引擎用——输入问题，拿到答案。但 Claude Code 不是搜索引擎。它是一个在循环中自主运行的智能体（agent），会做决策、使用工具、根据结果调整策略。一旦你理解了这个架构，就能明白为什么有些 prompt 效果惊艳，而另一些却毫无起色。

Agentic Loop：Claude Code 的真实工作方式

在底层，Claude Code 运行着一个看起来极其简单的模式：

思考 → 行动 → 观察 → 修正 → 重复

实际运行起来是这样的：

1. 思考（Think） — Claude 分析你的请求，决定该做什么
2. 行动（Act） — 使用工具（读取文件、执行命令、编辑代码）
3. 观察（Observe） — 查看该操作的结果
4. 修正（Correct） — 根据结果调整策略
5. 重复（Repeat） — 循环继续，直到 Claude 判断任务完成

这不是一个线性对话。而是一个递归循环（recursive loop），会持续运行直到 Claude 明确判定任务已完成。默认行为是持续到解决为止，而不是回复一次就停。

为什么这很重要： 当你让 Claude「给这个应用加上身份验证」时，它不会只是生成代码然后丢给你。它会阅读你现有的代码，理解你的设计模式，编写实现，运行测试来验证是否正常工作，修复发现的问题，然后才向你汇报。这就是循环在实际运转的样子。

上下文窗口：Claude 的工作记忆

Claude 有一个「上下文窗口」（context window）——可以理解为工作记忆。Claude 需要知道的关于你的对话、代码库和当前任务的所有信息，都必须装进这个窗口。

标准上下文： 200,000 个 token（大约相当于 500 页文本）

扩展上下文： Claude Sonnet 4 现在在 API 上支持高达 100 万 token——足以容纳超过 75,000 行代码的整个代码库。这需要 tier 4 API 访问权限，超过 200K 的输入 token 费用翻倍。

关键洞察：你发送的每条消息都包含了完整的对话历史。这就是 Claude「记住」你之前讨论内容的方式。但这也意味着长对话会消耗指数级增长的 token。

什么东西在占用你的上下文

上下文来自多个来源，它们全都会累加：

你的 prompt — 本次会话中你发送的每一条消息

Claude 的回复 — Claude 回复给你的所有内容

工具结果 — Claude 读取的文件内容、命令输出、搜索结果

系统上下文 — CLAUDE.md 内容、git 状态、项目结构

会话历史 — 自你上次 /clear 以来的完整对话记录

当你让 Claude「读取这个文件」时，整个文件内容都会被加入上下文。让它读十个文件，你可能在 Claude 还没开始处理你的实际请求之前，就已经消耗了数千个 token。

关于订阅计划的说明

你需要多关心上下文管理，取决于你的订阅方案：

Max 5x / Max 20x 计划 — 你有充裕的 token 额度。上下文管理对输出质量仍然有好处，但你不需要精打细算每一个 token。

Pro 计划 / 按量付费 API — 每次工具调用、每次文件读取、每个冗长回复都在花你的钱。积极的上下文管理直接影响你的账单。

下面的策略对注重成本的用户最有价值，但即使在不限量的计划上，更干净的上下文也会产出更好的结果。

管理上下文：那些重要的命令

/clear — 推荐的默认操作

/clear

清除一切。全新开始。零上下文。

换个角度想：/clear 应该是你的默认操作，而不是最后的手段。经验丰富的 Claude Code 用户会频繁清理——不是因为出了问题，而是作为任务之间的标准操作。

什么时候该用：

• 开始新功能时（必须）
• 在不相关的任务之间（做完身份验证，现在要搞 UI）
• 当前上下文中不到 50% 与当前任务相关时
• Claude 看起来困惑或陷入循环时
• 完成一个功能之后
• 当你注意到重复或偏离方向的回复时

/clear + /catchup 模式：

有些开发者会创建一个自定义 /catchup 命令，让 Claude 读取 git 分支中所有改动过的文件。/clear 之后运行 /catchup，就能在不带冗余上下文的情况下重新建立相关上下文。（完整实现见 第4篇）

/clear
/catchup
"Continue implementing the payment flow"

这样你就获得了干净的上下文，里面只有真正相关的内容。

/compact — 谨慎使用

2026年1月更新： 从 v2.0.64 开始，/compact 现在是即时完成的——不再需要等待。你也可以试试 /context 来检查 MCP 服务器是否在吃掉你的空间。

/compact

/compact 不会清除一切，而是对你的对话创建一个智能摘要，然后以该摘要作为上下文重新开始。

说句实话： 很多老手在能避免的情况下都不用 /compact。自动摘要是不透明的——你不知道具体保留了什么、丢失了什么。

/compact 适用的场景：

• 你正在做到一半，需要保留特定的决策记录
• 你有复杂的上下文，重建起来很痛苦
• 你想继续但上下文已经到了 70% 以上

什么时候用 /clear 更好：

• 开始新任务时
• 上下文中不到一半是相关的
• 你可以轻松重建重要的上下文

如果你确实要用 /compact，给它指引方向：

/compact Focus on preserving our authentication implementation
And the database schema decisions we've made

这告诉 Claude 摘要时最重要的内容是什么。

「记录并清除」策略

对于复杂的、跨会话的任务，有一个比依赖压缩更好的模式：

1. 记录： 让 Claude 把计划和进度写入一个 markdown 文件
2. 清除： /clear 完全清理会话
3. 继续： 重新开始，告诉 Claude 读取那个 markdown 文件然后继续

"Save our current progress and the remaining TODOs to docs/auth-migration-plan.md"
/clear
"Read docs/auth-migration-plan.md and continue from where we left off"

这创建了持久的外部记忆，可以完美地跨会话保留——没有有损压缩。

2026年1月更新： 这个模式现在已内置在 Plan Mode（计划模式）中。当你接受一个计划时，Claude 会自动清除上下文并将计划加载到一个全新的窗口中。这显著提高了计划的执行准确性。如果你想保留上下文，可以选择退出。

Auto-Compact：不要过度依赖的安全网

2026年1月更新： Auto-compact 现在在 75% 容量时触发（而不是之前的 92-95%），留出约 50k token 的推理空间。这是一个重大改进。

当上下文达到容量上限时，Claude Code 会自动压缩。这可以防止在任务执行中途耗尽空间。

但不要过度依赖它。 自动压缩仍然是应急行为，不是策略。到它触发的时候，你的输出质量可能已经开始下降了。

更好的做法：在自然断点处主动清理，而不是让上下文膨胀到系统不得不介入。

Extended Thinking（扩展思考）：让 Claude 想得更深

Claude Code 支持通过关键词触发思考模式（thinking mode），分配更多的推理预算：

"think" — 约 4,000 token 的思考预算

"think hard" — 约 10,000 token 的思考预算

"ultrathink" — 约 31,999 token 的思考预算（最大值）

只需在你的 prompt 中包含这些词：

"ultrathink about how to architect this payment system"
"think hard about the edge cases in this validation logic"

什么时候该用：

• 架构决策 → ultrathink + plan mode
• 陷入循环 → ultrathink 来突破困境
• 复杂调试 → think hard
• 常规任务 → 不需要关键词

注意： 这些关键词只在 Claude Code 的终端界面中有效，在网页聊天或 API 中无效。关于所有触发词和最新更新的深入解析，请参阅 第9篇：高级技巧。

Plan Mode（计划模式）：先想再做

大多数人犯的错误是：直接让 Claude 去做事情，而不是先让它规划。

Plan Mode 是一个只读状态，Claude 可以研究、分析和提出方案，但不会动任何文件。对于复杂任务来说，这是无价之宝。

如何进入 Plan Mode

按 Shift+Tab 循环切换模式：

1. 按一次： Auto-accept 模式（Claude 不会对每个操作都请求许可）
2. 按两次： Plan Mode（Claude 只能读取，不能写入）
3. 按三次： 回到正常编辑模式

看终端底部的提示文字来确认你当前处于哪种模式。

Plan Mode 中 Claude 能做什么

Plan Mode 限制 Claude 只能使用研究类工具：

• Read — 查看文件和内容
• LS/Glob — 列出目录和搜索文件模式
• Grep — 跨文件搜索内容
• WebSearch/WebFetch — 在线查资料
• Task — 启动研究子代理（sub-agent）
• TodoRead/TodoWrite — 管理任务列表

不能做的事： 编辑文件、运行命令、做任何更改。

什么时候该用 Plan Mode

探索不熟悉的代码：

[按两次 Shift+Tab 进入 Plan Mode]
"Explain how authentication works in this codebase.
Which files handle sessions? Where are tokens validated?"

Claude 会深入你的代码并解释，完全不会有破坏任何东西的风险。

规划重构：

"I want to migrate from REST to GraphQL.
What would need to change? What's the order of operations?"

Claude 分析依赖关系并提出迁移路径。

理解架构：

"How would you approach adding real-time notifications to this app?
What are the trade-offs between WebSockets and SSE here?"

Claude 结合你现有的代码进行分析并提出方案。

核心洞察：规划的成本很低，撤销的成本很高。在 Plan Mode 中花五分钟，往往能省下数小时回滚糟糕实现的时间。

「初级开发者」类比（进阶版）

在 第1篇 中，我们介绍了「积极的初级开发者」这个心智模型。现在你理解了底层架构，让我们来完善它：

Claude Code 就像一个技术能力很强的初级开发者：

需要清晰的指令 — 模糊的请求产生模糊的结果，因为 agentic loop 没有明确的停止条件

受益于上下文 — 更多相关信息意味着更好的工具选择和更少的无效循环

最擅长具体任务 — 「给登录函数添加错误处理」有明确的完成状态；「改进代码」则没有

会学习你项目的模式 — Claude 会观察它读取的文件中的惯例，并将其应用到它编写的文件中

做重大改动前会先请示 — 权限系统的存在，是因为如果没有它，循环会无限制地执行下去

可能会陷入循环 — 如果任务定义不清晰，Claude 可能会重复类似的操作而没有实质性进展

高效 Prompt 模式

现在你理解了循环机制，下面是如何写出与之配合的 prompt：

明确完成条件

循环需要知道什么时候该停。

❌ "Fix the bugs"
   （哪些 bug？Claude 怎么知道自己做完了？）

✅ "Fix the null pointer exception in src/auth.ts line 42
   where user.email is accessed before the null check"
   （具体位置，具体问题，明确的完成条件）

提前提供上下文

每次工具调用都会消耗 token 和时间。帮 Claude 更快找到它需要的东西。

❌ "Add a login page"
   （Claude 需要遍历你的整个代码库来理解项目模式）

✅ "Add a login page using the same styling as src/pages/signup.tsx
   and our auth service in src/services/auth.ts"
   （Claude 确切知道去哪里找参考）

注意： 在有充裕 token 额度的 Max 5x/20x 计划上，你可以放心让 Claude 更自由地探索。但即便如此，具体的文件引用仍然能产出更快、更一致的结果。

拆分大型任务

一个冗长的循环不如多个短循环。

❌ "Build a complete user dashboard with settings,
    notifications, and profile management"
   （范围巨大，顺序不明，容易迷失方向）

✅ 第1步："Create the dashboard layout component"
   第2步："Add the settings panel"
   第3步："Implement notifications"
   第4步："Build profile management"
   （清晰的完成节点，更容易纠偏）

用路径引用文件

别让 Claude 搜索它可以直接找到的模式。

❌ "Use the same pattern as the other components"
   （Claude 需要读取每一个组件来找到模式）

✅ "Follow the pattern in src/components/Button.tsx"
   （读一个文件就够了，最小化上下文消耗）

当 Claude 卡住了

以下迹象说明 agentic loop 在空转而没有进展：

• 重复性回复（反复提出相同的建议）
• 循环逻辑（反复尝试同一个修复方案）
• 问之前已经问过的问题
• 周期性地产出相似的错误代码

解决方案，按优先级排列：

1. /clear 然后重新开始 — 最有效。干净的上下文往往能立即解除困境。

2. 用 ultrathink — 「ultrathink about this problem」会分配最大推理预算，常常能突破普通 prompt 无法解决的问题。

3. 提供更具体的上下文 — 循环可能在大范围搜索，因为它不知道该往哪里看。

4. 把任务拆得更小 — 完成条件可能太模糊了。

5. 换个角度 — 「Instead of fixing this function, let's rewrite it from scratch.」

6. 切换到 Opus — 如果你在用 Sonnet（Pro 计划的默认模型），通过 /model 切换到 Opus 对真正复杂的推理任务会有帮助。Max 计划用户默认就是 Opus。

反馈循环

高效使用 Claude Code 是迭代式的。不要期望第一次就完美。

你：初始请求
Claude：第一次尝试
你："Good start, but the error handling doesn't cover network failures"
Claude：改进版
你："Better. Can you also add logging?"
Claude：最终版本
你：接受

这不是 Claude 失败了——这是 agentic loop 按设计运转的方式。每次迭代都添加新信息来引导下一个循环。

信任度的校准

你和 Claude Code 的关系应该是渐进式发展的：

第1周： 仔细检查每一个改动。理解 Claude 做了什么以及为什么这么做。

第2周： 对安全操作（读取、测试文件、文档）允许 auto-accept 模式。

第1个月： 信任常规任务。对复杂重构和涉及关键路径的改动仍然要验证。

持续： 始终验证安全关键代码、数据库操作以及任何涉及外部影响的操作。

目标不是盲目信任——而是有依据的信任。你在训练自己的直觉，判断什么时候 Claude 需要监督。

要避免的反模式

在 prompt 中粘贴整个文件 — 让 Claude 自己去读。「Read src/auth.ts and explain the session handling」比粘贴 500 行代码好得多。

忽略 Claude 的提问 — 当 Claude 请求澄清时，是因为循环没有足够的信息来自信地继续。认真回答。

急匆匆地通过权限提示 — 读清楚你在批准什么。「Always allow」很方便，但移除了一道安全检查。

保留过时的上下文 — /clear 没有成本。过时的上下文消耗 token 和准确性。

用 Claude 做琐碎的事 — 有时候直接敲 git status 比解释你想看什么要快。

下一步

你现在理解了 Claude Code 的思维方式。在 第3篇：项目配置 中，我们将深入 CLAUDE.md——这个文件决定了 Claude 对你特定项目的行为方式。一份精心编写的 CLAUDE.md 是「Claude 理解你的代码库」和「Claude 跟你的模式对着干」之间的分界线。