Claude Code 最佳实践:一切都围绕「上下文窗口」打转

Claude Code 不是那种"你问它答、然后干等"的聊天机器人——它会读你的文件、跑命令、改代码,在你旁观、纠偏甚至彻底离开时自主推进问题。这种自主性很爽,但有学习曲线。

而这条学习曲线上的几乎所有技巧,都能追溯到同一个约束:

上下文窗口会很快填满,而填满后性能会下降。

上下文窗口装着你的整段对话——每条消息、它读过的每个文件、每条命令的输出。一次调试或一次代码库探索,动辄就消耗掉几万 token。而 LLM 的表现会随上下文填满而下降:快满时,Claude 会开始"忘记"早先的指令、犯更多错。所以上下文窗口是你最需要管理的资源。 下面所有实践,本质上都是在为这个约束服务。

一、给它一个能自我验证的方式(回报最高的一件事)

给 Claude 提供测试、截图或期望输出,让它能自己检查自己。这是单项回报最高的投入。

Claude 能自我验证(跑测试、比对截图、校验输出)时,表现会显著变好。没有明确的成功标准,它可能产出"看起来对、实际不工作"的东西——而你就成了唯一的反馈回路,每个错误都得你亲自盯。

对比一下含糊和具体的提示:

策略	❌ 之前	✅ 之后
给验证标准	“实现一个校验邮箱的函数”	“写 validateEmail。测试用例:`user@example.com` → true,`invalid` → false,`user@.com` → false。实现后跑测试”
可视化验证 UI	“让仪表盘好看点”	“[贴截图] 实现这个设计,然后截图和原图对比,列出差异并修掉”
治根而非治标	“构建挂了”	“构建报这个错:[贴错误]。修掉并验证构建通过,针对根因,别把错误压下去”

关键不只是"让它验证",还要让它拿出证据而非口头宣称成功:测试输出、它跑了什么命令返回了什么、或结果截图。审阅证据比你自己重跑一遍验证快得多,而且对你没盯着看的会话也管用。

二、先探索,再规划,最后写代码

把"研究+规划"和"实现"分开,避免解错问题。

让 Claude 直接上手写,容易写出"解决了错误问题"的代码。用 plan 模式把探索和执行分开。推荐的四阶段流程:

探索(Explore):进 plan 模式,Claude 只读文件、答问题,不改东西。

读 /src/auth,搞懂我们怎么处理 session 和登录,也看看密钥的环境变量是怎么管的
规划(Plan):让它产出详细的实现计划。按 Ctrl+G 可在文本编辑器里直接改这份计划再让它继续。

我想加 Google OAuth,需要改哪些文件?session 流程是怎样的?做个计划
实现(Implement):切出 plan 模式,让它照计划写,并对照计划验证。
提交(Commit):让它写一条描述性的 commit message 并开 PR。

但要注意:plan 模式有用,但也有开销。 范围清晰、改动很小的活儿(改个 typo、加行日志、重命名变量),直接让它干就行。“如果这个 diff 你一句话就能描述清楚,那就跳过规划。” 规划最有价值的时候是:你不确定怎么做、改动跨多个文件、或你对要改的代码不熟。

三、在提示里给足具体上下文

指令越精确,需要的纠正就越少。

Claude 能推断意图,但读不了你的心。引用具体文件、说明约束、指向示例模式:

策略	❌ 之前	✅ 之后
限定范围	“给 foo.py 加测试”	“给 foo.py 写测试,覆盖用户已登出的边界情况,别用 mock”
指明来源	“为什么 ExecutionFactory 的 api 这么怪?”	“翻 ExecutionFactory 的 git 历史,总结它的 api 是怎么演变成这样的”
参照现有模式	“加个日历组件”	“看主页上现有组件怎么实现的,HotDogWidget.php 是个好例子,照这个模式实现一个日历组件……只用代码库里已有的库”
描述症状	“修登录 bug”	“用户反馈 session 超时后登录失败,查 src/auth/ 的认证流程尤其是 token 刷新,先写个能复现的失败测试,再修”

反过来,含糊的提示在"探索"阶段反而有用——这个文件你会改进哪些? 这种问法能暴露你想不到的东西。

提供丰富内容的几种方式:用 @ 引用文件;直接粘贴/拖拽图片;给文档/API 的 URL(用 /permissions 把常用域名加白名单);用 cat error.log | claude 把内容管道喂进去;或直接让 Claude 自己用 Bash/MCP 去拉它需要的上下文。

四、把 CLAUDE.md 当代码来维护

跑 /init 基于当前项目结构生成一个起步版 CLAUDE.md,然后慢慢打磨。

CLAUDE.md 是 Claude 每次对话开头都会读的文件。放该放的:Claude 猜不到的 Bash 命令、与默认不同的代码风格、工作流规则。

最反直觉但最重要的一条:保持精简。 因为它每次会话都载入,臃肿的 CLAUDE.md 会让 Claude 忽略你真正的指令! 对每一行都问自己:“删掉这条会不会让 Claude 犯错?” 不会就删。

✅ 应该写	❌ 不该写
Claude 猜不到的 Bash 命令	它读代码就能搞清的东西
与默认不同的代码风格	它已经知道的标准语言惯例
测试说明、首选测试运行器	详细的 API 文档(给链接就行)
仓库礼仪(分支命名、PR 约定)	频繁变动的信息
项目特有的架构决策	长篇解释或教程
开发环境怪癖(必需的环境变量)	逐文件的代码库描述
常见坑、非显而易见的行为	“写干净的代码"这种不言自明的话

判断信号:如果有规则却仍被反复违反,多半是文件太长、规则被淹没了;如果它问你 CLAUDE.md 里已答的问题,可能是措辞含糊。像对待代码一样:出问题就 review,定期修剪,改完观察 Claude 行为是否真的变了。可以用 “IMPORTANT” / “YOU MUST” 加强关键条目,并把它 check 进 git 让团队共建。

(关于 CLAUDE.md 的载入机制、rules、@import 是否省上下文,我另写过一篇讲得更细。)

五、配好环境:权限、CLI、MCP、hook、skill、subagent

几个一次性设置能让所有会话都更高效:

权限:默认每个改动都要批准,点到第十次你就不是在 review 了。三种减少打断的方式——auto 模式(分类器只拦风险动作)、/permissions 白名单(放行 npm run lint 这类已知安全的)、/sandbox(OS 级隔离)。
CLI 工具:让 Claude 用 gh、aws、gcloud、sentry-cli 等——这是和外部服务交互最省上下文的方式。它也很擅长现学:用 'foo --help' 学会 foo,然后用它解决 A、B、C。
MCP:claude mcp add 接入 Notion、Figma、数据库等。
hook:用于必须每次发生、零例外的动作。CLAUDE.md 是"建议性"的,hook 是确定性的。可以让 Claude 帮你写:写个在每次文件编辑后跑 eslint 的 hook。
skill:在 .claude/skills/ 放 SKILL.md,给 Claude 领域知识或可复用工作流,按需加载、不占满每次对话。带副作用、想手动触发的工作流加 disable-model-invocation: true。
subagent:在 .claude/agents/ 定义专职助手(各有自己的工具和上下文),适合读很多文件或需要专注的任务。

什么时候用 skill、什么时候用 subagent/hook/MCP?核心区别就是是否要占用主上下文——这正好呼应了全文主线。

六、激进地管理上下文(本文的核心动作)

会话是持久且可回退的,善用这一点。

及早、频繁地纠偏。 最好的结果来自紧密的反馈回路:

Esc:中途打断 Claude,上下文保留,可重新引导。
Esc + Esc 或 /rewind:打开回退菜单,恢复之前的对话/代码状态,或从某条消息开始总结。
"撤销刚才那个":让它回滚改动。
/clear:在不相关的任务之间重置上下文。

一条铁律:同一个问题在一次会话里纠正超过两次,上下文就已经被失败的尝试污染了。 这时 /clear 重开,带上你学到的东西写一个更具体的提示——干净会话 + 更好的提示,几乎总是胜过冗长会话 + 一堆累积的纠正。

管理上下文的几个工具:

任务之间频繁 /clear。
自动压缩触发时,Claude 会总结最关键的(代码模式、文件状态、关键决策)。
想更可控用 /compact <指令>,如 /compact 聚焦 API 改动。
只压一部分:Esc + Esc 选检查点,选"从这里总结"或"总结到这里”。
在 CLAUDE.md 里定制压缩行为:压缩时务必保留完整的已修改文件列表和测试命令。
不想进上下文的小问题用 /btw,答案出现在可关闭的浮层里,永不进对话历史。

用 subagent 做调查。 因为上下文是根本约束,subagent 是最强工具之一:它在独立的上下文窗口里读文件,只回报摘要,你的主对话保持干净。既能用于探索(用 subagent 调查我们的认证系统怎么处理 token 刷新),也能用于验证(用 subagent 审查这段代码的边界情况)。

用 checkpoint 回退。 每次发提示都创建一个检查点,Claude 改文件前会自动快照。这让你可以大胆尝试有风险的方案,不行就回退重来。检查点跨会话保留。⚠️ 但它只追踪 Claude 做的改动,不是 git 的替代品。

恢复会话。 claude --continue 接最近一次,claude --resume 从列表选,用 /rename 给会话起名(如 oauth-migration),把它们当分支用——每条工作线一份持久上下文。

七、扩展:并行与自动化

熟练驾驭一个 Claude 后,可以横向扩展:

非交互模式:claude -p "提示" 用于 CI、pre-commit、脚本。--output-format json 给脚本解析,stream-json --verbose 做实时处理。
多会话并行:worktree(隔离的 git 检出,改动不撞)、Desktop app(可视化管理)、Web(云端隔离 VM)、agent teams(自动协调)。一个特别有价值的模式是 Writer/Reviewer:一个会话写,另一个全新上下文的会话 review——因为它不会偏袒刚写的代码。写测试也同理:一个写测试,另一个写代码去过测试。

跨文件 fan-out:大迁移时循环调 claude -p,用 --allowedTools 限定权限。先在 2~3 个文件上调好提示,再跑全量。

for file in $(cat files.txt); do
  claude -p "把 $file 从 React 迁到 Vue,返回 OK 或 FAIL。" \
    --allowedTools "Edit,Bash(git commit *)"
done

自主运行:claude --permission-mode auto -p "修掉所有 lint 错误",分类器做后台安全检查。
加一道对抗式 review:任务收尾前,让一个全新上下文的 subagent 只看 diff 和标准、报告差距。内置的 /code-review skill 就是干这个的。⚠️ 但注意:被要求挑毛病的 reviewer 总会挑出些来,即使代码没问题——所以要明确告诉它"只标影响正确性或既定需求的差距",其余当可选,否则会陷入过度工程。

八、避开几个常见的失败模式

失败模式	修法
大杂烩会话:一个任务没完又问无关的,上下文塞满杂物	不相关任务之间 `/clear`
反复纠正:改了还错、再改还错,上下文被失败尝试污染	两次失败后 `/clear`,写个更好的初始提示
过度膨胀的 CLAUDE.md:太长导致一半被忽略	狠心修剪,能转成 hook 的就转
信而不验:产出看似合理但不处理边界	永远提供验证(测试/脚本/截图),验证不了就别上线
无限探索:让它"调查"却不限定范围,读几百个文件填满上下文	把调查范围收窄,或用 subagent 隔离

九、最后:培养你自己的直觉

这些模式不是铁律,是"通常好用"的起点。有时你该让上下文累积——因为你深陷一个复杂问题、历史很有价值;有时该跳过规划让它自己摸索;有时含糊的提示恰恰对,因为你想先看它怎么理解再去约束。

留意什么管用。 Claude 产出很棒时,注意你做了什么:提示结构、给的上下文、所处的模式;它卡壳时,问问为什么——上下文太吵?提示太含糊?任务一次吃不下?久而久之,你会形成任何指南都给不了的直觉:知道何时具体何时开放、何时规划何时探索、何时清空上下文何时让它累积。

而这一切判断的底层标尺,始终是那一句:上下文窗口,是你最该管理的资源。

关于

关注我获取更多资讯

📢 公众号

💬 个人号