Claude Code 上下文管理

我第一次认真用 Claude Code 做跨文件改动时，把同一个登录跳转的 bug 修了三轮。第一轮它改了路由，没生效；我贴上报错让它再看，它改了中间件，还是没生效；第三轮它开始动我根本没让它碰的 session 逻辑。修到这里我才反应过来，问题不在 Claude Code，在我：前两轮失败的补丁、报错日志、我那些反复的纠正，全堆在上下文里，它每次都得带着这一堆噪音重新判断。我 /clear 重开，把复现步骤一次写清楚，第一次就修好了。

Claude Code 用好的前提只有一条：管理上下文窗口。它不是代码补全，是一个有状态的 agentic 工具，整段对话的上下文都在窗口里。上下文越来越满，Claude 就越来越容易忘掉早期指令、重复失败方案，或者自信地改错地方。

Anthropic 自己的最佳实践文档里说得直接：大多数最佳实践都基于同一个约束，上下文窗口填得很快，填满之后性能会下降。

上下文窗口是唯一重要的事

上下文里装着所有对话记录、读过的文件、每条命令的输出。窗口一共 200K token，听着很多，但读三五个上千行的源文件、再加上几轮命令输出，几万 token 就没了，一个稍长的调试 session 用掉一半很常见。窗口越满，Claude 越容易忘掉早期指令，开始犯低级错误。用 /context 可以随时看当前占用，超过一半就该考虑 /clear 了。

与其想「怎么给 Claude 更多信息」，不如想「怎么让上下文保持干净」。

• 任务之间跑 /clear 清空上下文，不要把上一个任务的残留带进来
• 卡住之后反复纠正超过两次，就停下来，/clear 重开，写一个更精确的提示，几乎总比继续改快
• 调查性的任务（「这个模块的结构是什么」「找所有涉及 auth 的文件」）交给 subagent 做，它用自己的上下文读文件，只把结论还给主 session

Esc 键也随时可以打断 Claude 正在做的事，重新定向，上下文保留不变。改坏了的话，Esc+Esc 或 /rewind 可以回到任意检查点，只回滚代码，或者连对话一起回滚。

给 Claude 一个自检的方式

最佳实践文档把这件事放得很靠前，用下来确实是收益最高的习惯之一：给 Claude 一个它自己能跑的检查。

光描述需求，Claude 给的结果看起来可能没问题，但某个边界情况下悄悄出错。你就成了唯一的验证环节，每个 bug 都得自己先发现。

不如直接在提示里给验证条件。

写一个 validateEmail 函数。测试用例：user@example.com → true，invalid → false，user@.com → false。写完之后跑测试，修掉失败的。

这样 Claude 自己就知道有没有做对。你看它给的证据——测试输出、命令结果——就够了，不用自己再跑一遍。

UI 改动也一样。把截图粘进去，让它截图对比，列出差异，自己迭代。你要是只说「让 dashboard 好看点」，写出来的东西只有 Claude 自己觉得对。

先规划，再写代码

直接让 Claude 开始写代码，容易解决一个错误的问题。代码库不熟、改动跨多文件的时候尤其如此。

四步流程：进入 Plan Mode（Shift+Tab 切换）先探索代码，不做修改；让它出方案，涉及哪些文件、流程怎么走；确认没问题后退出 Plan Mode 实现，同时跑测试；最后 commit 和 PR。官方的 common workflows 也把「先规划再编辑」单独列出来，因为这一步能避免 Claude 很认真地解决一个错误的问题。

不过规划本身也有开销。改一行 log、重命名一个变量，直接做更快。Plan Mode 适合方案不确定、改动跨多文件、代码不熟的场景。

还有一种玩法：让 Claude 先来采访你。

我想做 [简短描述]。先不要写代码，先采访我：
- 技术实现有哪些不确定点？
- UI/UX 有哪些边界？
- 哪些取舍需要我决定？
- 有哪些我可能没想清楚的问题？

采访完之后，把结论整理成 SPEC.md。SPEC 里要写清楚涉及哪些文件、哪些不在范围内，以及最后用什么命令或截图验证。

Claude 会问出你自己没想到的问题。采访完之后，新开一个 session 来实现，上下文干净，有书面 spec 可以对照，比边聊边改效果好很多。

CLAUDE.md 是跨 session 的记忆，不是项目文档

Claude 每次都从空白上下文开始，CLAUDE.md 是打破这个限制的方式。Claude Code memory 文档里说得很清楚：CLAUDE.md 在 session 开始时进入上下文，相当于写给 Claude 的持久说明书。

跑 /init 可以让 Claude 分析项目自动生成一份初版，然后手动调整。格式随意，保持可读就行：

# Code style
- Use ES modules (import/export), not CommonJS (require)
- Destructure imports when possible

# Workflow
- Typecheck after a series of code changes
- Run single tests, not the full suite

判断标准只有一个：删掉这行，Claude 会不会犯错？ 不会就删掉。

CLAUDE.md 最常见的问题是被写成项目文档：架构说明、API 介绍、详细流程，想到什么就往里塞。越堆越长，越容易被忽略。官方建议控制在 200 行以内，这个上限不是随便定的。CLAUDE.md 本身也进上下文，太长会挤占 session 的起始空间，Claude 也会开始漏掉其中的规则。

Claude 反复问同一类问题，或者反复犯同一类错，就是在提醒你该往 CLAUDE.md 里加东西了。

提示词越具体，纠正越少

模糊的提示不是不行，但后续纠正成本更高。几个对比：

「给 foo.py 加测试」→「给 foo.py 写测试，覆盖用户未登录的情况，不要用 mock」

「修登录的 bug」→「用户反馈 session 超时后登录失败，检查 src/auth/，写个复现的失败测试，修完确认通过，解决根本原因，不要只是压掉错误」

「加一个日历组件」→「看 HotDogWidget.php 的实现方式，按同样的模式做一个日历组件，支持选月和前后翻页，不引入新依赖」

用 @ 引用文件比描述「在某某目录下有个文件」高效得多。截图可以直接粘贴或拖进去。错误日志可以 pipe 进来：

cat error.log | claude -p "有没有异常，总结一下原因"

什么时候不要这么做

Plan Mode 不是默认动作。改一行文案、删一个没用的 import、补一个显而易见的测试，直接做更快。如果你能用一句话描述最终 diff，没必要让 Claude 先写一页计划。

subagent 也不是免费的。它适合探索、归纳、定位范围，比如「auth 相关文件有哪些」「这个模块的数据流怎么走」。不适合承载需要连续判断的主线实现，否则只是把上下文问题换了个地方。

CLAUDE.md 适合放每次 session 都该知道的规则，不适合放某个功能的临时背景。临时背景进当前提示或 SPEC.md，别永久污染每次启动。

几个容易浪费时间的模式

反复纠正却不清空上下文。 Claude 犯错，你纠正，还错，再纠正。上下文里全是失败的尝试，继续纠正很难比重开更快。及时认赔，/clear，把学到的东西写进新提示里。

CLAUDE.md 越写越长。 想到什么就往里加，最后几百行，Claude 读完早忘了前面写了什么。精简比堆砌重要，每行都应该是会让 Claude 犯错的信息。

让 Claude 去「调查」却不限定范围。 Claude 开始读文件，越读越多，上下文很快就满了。这类任务交给 subagent，主 session 只接收结论。

没有验证方式就算完成。 功能看起来能跑，但没有测试、没有命令验证、没有截图对比，出了问题不知道什么时候引入的。给 Claude 一个自检条件，不只是提升输出质量，也是替自己省事。

下次开 Claude Code session，先做三件事：把任务边界写清楚（哪些文件可以改，哪些不能），把验证方式写清楚（测试、命令、截图对比，至少选一个），如果 Claude 连续两次改错，别继续纠正，/clear 重开。

用了一段时间之后我学到的：Claude Code 不会替你想清楚问题，但能让想清楚之后的落地速度快很多。前提是你真的想清楚了。