Claude Code 上下文管理实战笔记：9 条高效使用策略

核心认知：上下文窗口是关键

使用 Claude Code 时，最容易被忽视的瓶颈不是提示词质量，也不是模型选择，而是 上下文窗口 的管理。可以把它理解为 Claude 的 "白板" —— 你发的每条消息、Claude 读的每个文件、执行的每条命令都会写上去。白板满了，Claude 就会表现下滑：遗忘指令、犯低级错误、开始重复自己。所以核心原则是：管好这块白板，就是管好 AI 的注意力。

策略一：先做计划，再写代码

新手最常犯的错误是直接让 Claude 动手写代码，结果方向跑偏，还浪费了大量上下文空间。正确做法是使用 Plan Mode（Shift+Tab 切换），让 Claude 先阅读文件、理清关联、输出完整计划（改哪些文件、步骤顺序、潜在风险），经你审查确认后再切回正常模式开发。多花十分钟做计划，能避免无数次返工。

策略二：用子代理（Subagent）保护主会话

调研阶段 Claude 会读大量日志、配置和代码，很快就会塞满主会话的上下文。子代理是独立的 Claude 实例，在自己的上下文窗口中工作，只将结果汇报回来，不占用主会话空间。使用方式非常简单，在调研任务后加一句 "use subagents" 即可。所有"读日志、查源码、分析调用链"的活都适合扔给子代理，主会话只做决策和写代码。

CLAUDE.md

CLAUDE.md 是 Claude 每次启动时都会读取的规则文件。把你反复强调的编码规范、测试要求、命名约定等写进去，就不必每次会话都重新交代。更关键的技巧是：每次纠正 Claude 的错误后，追加一句"更新 CLAUDE.md 以免再犯"，让它把教训沉淀为规则。但要注意控制篇幅，每条规则都应回答"没了这条，Claude 会犯错吗？"，如果不会就删掉。

策略四：在提示词中内置验证标准

不要让自己成为唯一的质检员。写需求时直接给出测试用例和验证标准，让 Claude 能自我检验。比如写邮箱验证函数时，同时给出应通过和应失败的测试数据，要求写完后执行测试。视觉类任务则可以粘贴截图并要求 Claude 改完后对比说明差异。

策略五：提示词要像技术文档一样具体

模糊指令如"给 auth.py 加测试"远不如具体指令有效。好的提示词应该明确输入、输出、约束和验证方式，就像写接口文档一样。还可以直接指向 Claude 应该看的位置，比如"看这个文件的 git 历史，找出这个行为是什么时候引入的"，而不是笼统地问"为什么这个函数表现怪怪的"。

策略六：每 30-45 分钟重置上下文

长时间会话会导致"上下文污染"：Claude 开始跑偏、啰嗦、忘记早期规则。操作方法是让 Claude 总结当前进度（做了什么、剩余任务、当前问题），然后开新会话粘贴总结继续工作。一个臃肿的旧上下文，远不如一份精炼的总结有效。

策略七：并行会话 + Git Worktree

配合 git worktree（代码库的多个独立工作副本），可以同时开多个 Claude Code 会话互不干扰。典型用法是会话 A 写新功能，会话 B 以审查者身份找边缘问题和缺陷，形成"一个写、一个审"的闭环。也可以用于测试驱动开发：一个 Claude 写测试，另一个写通过测试的代码。

策略八：把重复操作封装成 Skill

如果某个操作每天重复超过两次，就应该封装为 Skill（本质是保存好的工作流程）。取个名字，以后一条命令调用即可，从"每次手动写完整提示词"进化为"一键执行"，并且可以跨项目复用。

策略九：给真实数据，而不是你的猜测

传统 Bug 修复流程中，你用语言描述问题，Claude 猜测、试错，浪费大量上下文。更高效的做法是直接贴上真实的错误日志、Slack 对话、CI 输出等原始数据，然后简单地说 "fix"。Claude 非常擅长从真实数据中精准定位问题。

日常工作流串联

任务前检查和更新 CLAUDE.md，评估任务复杂度决定是否启用计划模式。执行中将调研扔给子代理，主会话用具体提示词写代码并内置验证，必要时开第二个会话做代码审查。每 30-45 分钟评估是否需要上下文重置。任务结束后将犯过的错更新到 CLAUDE.md，将重复操作封装为 Skill。

一句话总结：上下文窗口大小固定，但你可以决定在上面写什么、什么时候擦掉重来。管理上下文，本质上是管理 AI 的注意力。