用了3个月Claude Code，这9条最佳实践让我少走了无数弯路

用了三个月Claude Code，我踩过的最大坑，不是提示词写得不够好，也不是模型选错了，而是一个绝大多数人根本意识不到的东西：上下文窗口。

它就像房间里的大象。你的Claude越来越笨，你以为是模型变傻了，其实是你把它的“白板”写满了。

这篇文章，我会把自己从“上下文小白”到“上下文管理高手”的完整经验掰开揉碎了讲给你听。每一条都是我亲手验证过的，没有理论空谈。

如果你也在用Claude Code，这篇东西可能会帮你省掉几十个小时的无效返工。

好，我们直接发车。

什么是上下文窗口？为什么它是AI协作的隐形瓶颈？

本段核心问题：为什么Claude会越用越笨？

Claude的大脑里有一块白板。你发的每一条消息、Claude读的每一个文件、它执行的每一条命令，全都会被写在这块白板上。白板的大小是固定的——这就是“上下文窗口”。

一旦白板写满了，Claude的表现就会开始下滑：它会忘记你一小时前刚交代的规则，会犯一些明显不该犯的低级错误，甚至会开始重复自己的话。

这不是Claude变笨了，而是它真的记不住了。Claude Code的创建者Boris Cherny说过一句大实话：“想用好Claude Code，关键就是管理好这块白板。”

理解了这一点，后面所有的策略才讲得通。

策略一：别让Claude一上来就写代码

本段核心问题：如何避免Claude一上来就写错代码？

这是几乎所有新手踩的第一个坑。你描述一个需求，Claude立刻撸起袖子开始写代码。十五分钟后你发现，它解决的根本不是你想要的问题，或者方向完全跑偏了。

更糟的是，这十五分钟的代码生成已经吃掉了大量宝贵的上下文空间。想纠正的时候，白板已经快满了。

正确做法是：先切计划模式（Plan Mode）。

Claude Code内置了一个Plan Mode，按Shift+Tab就能切换进去。在这个模式下，Claude只读文件、理清思路，不动任何代码。它就像团队里的架构师，先画图、不写代码。

我现在的标准流程是这样的：

  1. 切到计划模式，让Claude阅读相关文件，理清代码之间的关联。
  2. 让Claude写出完整计划：要改哪些文件？步骤顺序怎么排？哪里可能出错？有没有更好的实现方式？
  3. 我亲自审查计划，不对就改，直到逻辑清晰。
  4. 切回正常模式，基于已经审查过的计划开始开发。
  5. 让Claude用清晰的提交信息提交代码，方便以后回溯。

多花十分钟做计划，能帮你避免无数次返工。Boris的团队甚至更极致：他们用一个Claude写计划，另一个Claude以高级工程师身份审查计划。计划这一步，他们是认真的。

策略二：用子代理保护你的主战场

本段核心问题：如何不让调研任务把主会话的上下文搞废？

回到白板的比喻。Claude调查一个问题时会读大量文件：日志、配置、源码……一通读下来，白板很快就半满了。等它研究完准备动手写代码时，空间已经不够用了，写出来的代码质量也会大打折扣。

子代理（Subagent） 完美解决了这个问题。

子代理是一个独立的Claude实例，它有自己的上下文窗口，在自己的空间里干活。它把调研结果汇报回来，但完全不占用你主会话的白板空间。

用法极其简单：在任何调研任务后面加一句 “use subagents” 就行。比如：

“用子代理帮我查查支付流程是怎么处理失败交易的。”

子代理会自己去读所有相关数据，然后回来给你一份清晰的报告。你的主会话始终保持清爽，收到报告后还有大量空间继续开发、写代码。

这是我目前使用频率最高的技巧，没有之一。作为Java后端开发，我经常需要排查复杂的分布式系统问题——日志散落在不同服务，调用链又长又绕。以前一个排查任务就能把整个会话搞废。现在我把所有“读日志、查源码、分析调用链”的活儿全部扔给子代理，主会话只做决策和写代码。效率的差距，用“天壤之别”来形容一点都不过分。

策略三：CLAUDE.md 是你的“活规则书”

本段核心问题：如何让Claude每次都按你的习惯工作，而不用反复交代？

如果你每天都在用Claude Code，但还没有认真维护一个叫 CLAUDE.md 的文件，那你正在浪费大量的效率。

CLAUDE.md 是Claude每次启动时都会自动读的文件。你在这个文件里写什么规则，Claude就按什么方式跟你工作。

想想你每天重复说的话：

  • “用 ES modules，不用 CommonJS”
  • “测试不要用 mocks”
  • “代码改完后记得跑一次 linter”
  • “分支命名格式是 feature/工单编号”

没有 CLAUDE.md，每次都得重新说一遍。有了它，说一次就够。

但最关键的技巧是这个：每次Claude犯了错，你纠正完以后，最后加一句：

“更新 CLAUDE.md，以免再犯这个错误。”

Claude会自动把这次教训写进自己的规则文件。时间久了，CLAUDE.md 会变成一份专门为你、为你的项目优化的“活文档”。

我自己 CLAUDE.md 里有一条规则就是这样来的：我发现Claude老是在我的Obsidian Vault里创建 .txt 文件——Obsidian根本不显示 .txt，这等于白干。纠正了一次之后，我让它加了一条“Vault内只创建 .md 文件”的规则。从此再也没犯过。

⚠️ 但要注意：CLAUDE.md 不能太长。如果写到500行，Claude的注意力会被分散，有些规则反而被忽略了。我维护的原则是：每条规则都应该回答一个问题——这条没了，Claude会犯错吗？ 如果不会，删掉。

策略四：给Claude自检的机会

本段核心问题：怎么不让自己的眼睛成为唯一的质量检查员？

大多数人的用法是：描述需求 → 祈祷Claude写对 → 自己一行一行检查。这样你就成了唯一的质检员，相信我，特别累，而且很容易漏掉问题。

更好的做法是：在提示词里内置验证标准。

举个例子。你想写一个邮箱验证函数，不要只说：

❌ “写一个邮箱验证函数。”

换成这样说：

✅ “写一个函数判断邮箱是否有效。用这些案例测试：hello@gmail.com 应该通过，hello@ 应该失败，.com 应该失败。写完后自动执行这些测试。”

Claude 就会在写完代码后自我检验，直接告诉你结果，完全不用你逐行盯着看。

视觉类的任务也一样。你要改一个按钮设计？直接粘贴截图，然后说：“让它看起来像这样，改完后截图给我，告诉我有什么不同。”

给 Claude 一个明确的对比标准，避免你自己成为唯一的反馈环节。这一招，每用一次都能帮你省下好几个小时。

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

本段核心问题：为什么Claude老是理解错你的意思？

Claude能从上下文推断很多东西，但它读不懂你的心思。

看看这两组提示词的对比：

❌ 模糊版：“给 PaymentService 加测试。”

✅ 具体版：“写 PaymentService 的单元测试，覆盖用户请求中途会话过期的情况。不允许用 mocks。重点测试令牌看似有效但实际已过期的边缘情况。”

任务是一样的，结果却天差地别。

你也可以直接指向 Claude 应该看的位置：

❌ “为什么这个函数表现怪怪的？”

✅ “看这个文件的 git 历史，找出这个行为是什么时候加进来的，为什么会有。”

区别就是：Claude 是在胡乱猜测，还是在给你一个确定的答案。

作为后端开发，我现在写提示词的习惯是：明确输入、明确输出、明确约束、明确验证方式。把它当成写接口文档一样来对待。

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

本段核心问题：会话时间长了Claude开始胡言乱语怎么办？

你跟 Claude 交谈久了，一定会发现它开始跑偏：反复啰嗦同样的话、忘了你早期给的规则、回答质量明显下降。

这就是上下文污染——白板写满了，Claude 只能不断覆盖掉旧内容，导致“失忆”。

Boris 的团队在复杂任务中，每30-45分钟就做一次上下文重置。操作方法很简单：

  1. 让 Claude 总结当前进度：“总结我们目前做了什么，还剩哪些任务，当前有哪些待解决的问题。”
  2. 开一个新会话。
  3. 把总结直接粘贴进新会话，继续往下做。

这能保持 Claude 思路一直清晰，避免长时间会话带来的“脑雾”。

很多人舍不得关会话，觉得“上下文都在里面，关了多可惜”。实际上，一个臃肿的、写满垃圾的上下文，还不如一份精炼的进度总结。

策略七：并行会话 + Git Worktree

本段核心问题：如何让多个Claude同时为你工作而不互相干扰？

这是 Boris 团队公认的生产力杀手锏。你可以同时开启多条 Claude Code 会话，配合 git worktree（代码库的多个独立工作副本），让它们互不干扰、并行干活。

举个例子：

🅰️ 会话 A 负责写新功能
🅱️ 会话 B 负责审查 A 写的代码

把 A 的产出直接丢给 B，让它找边缘问题、找缺陷。然后把审查结果带回 A，A 再优化。一个 Claude 写，一个 Claude 审，代码质量蹭蹭往上涨。

有人同时开 3-5 个会话，给每个 worktree 起好名字，并设置 shell 别名（za, zb, zc），一键就能切换。你也能用同样的方法搞测试驱动开发：一个 Claude 先写测试，另一个写能通过测试的代码。TDD，但 Claude 做了所有重活。

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

本段核心问题：每天都要重复说的提示词，能不能存起来一键调用？

如果你每天在 Claude Code 里重复做一件事超过两次，就该把它变成 Skill。

Skill 本质上是保存好的工作流程。你把固定的操作步骤写清楚，取一个名字，以后只需要调用这个名字，Claude 就会自动执行整套流程。

我自己封装了十几个 Skill：封面图生成、文章发布、图片压缩、网页转 Markdown……每一个都是从“每次手动说一遍完整提示词”进化成“一条命令搞定”的。

Boris 的规则值得借鉴：如果每天做两次以上，就封装成 Skill。他团队给 BigQuery 搭了一个 Skill，团队成员直接在 Claude Code 里做数据分析查询，连 SQL 都不用写。一个 Skill，贯穿所有项目复用，效率翻倍。

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

本段核心问题：如何让Claude自己理解Bug，而不是靠你转述？

传统的 Bug 修复流程是这样的：你用语言描述 Bug → Claude 猜错几次 → 你纠正几次 → 最终修好。这中间浪费的上下文空间是巨大的。

更快的做法是：给 Claude 真实错误信息，然后走开。

Boris 团队接入了 Slack MCP（消息通道）。当 Slack 上报 Bug，他们直接把对话记录贴给 Claude，然后扔一个字：“fix”。

没有多余解释，没有手把手辅导。Claude 自己看对话、自己找问题、自己修复。或者直接说“去修那个失败的 CI 测试”，然后走开。没告诉 Claude 哪个测试、没说明为什么失败，Claude 照样能搞定。

关键在于：给 Claude 的是真实数据（Slack 线程、错误日志、Docker 输出），而不是你对问题的二手猜测。Claude 非常擅长读分布式系统日志，能精准追踪故障点。作为后端开发，这一点让我非常惊喜。

把这些串起来：我的日常工作流

分享一下我现在的典型工作流程，把上面的策略全部串联起来：

开始任务前

  • 检查 CLAUDE.md 是否需要更新
  • 明确任务复杂度，决定是否需要计划模式

任务执行中

  • 复杂调研 → 扔给子代理
  • 写代码 → 主会话 + 具体提示词 + 内置验证
  • 代码审查 → 开第二个会话（并行 + worktree）

每30-45分钟

  • 让 Claude 总结进度
  • 评估是否需要上下文重置（新会话）

任务完成后

  • Claude 犯过的错 → 更新 CLAUDE.md
  • 重复操作 → 封装成 Skill

这套流程让我的效率至少提升了 3 倍。不是因为 Claude 变强了，而是因为我学会了管理它的“大脑”。

最后的话：管理AI注意力才是核心能力

回到文章开头的那个比喻。

上下文窗口就是 Claude 的白板。白板的大小是固定的，但你可以决定在上面写什么、什么时候擦掉重来。

管理上下文，本质上就是在管理 AI 的注意力。这是一项新技能。它跟编程能力无关，跟领域知识无关，但它决定了你能从 AI 身上获得多少价值。

越早掌握，越早受益。

你踩过最大的上下文窗口的坑是什么？欢迎在评论区聊聊 👇

实用摘要 / 操作清单

  1. 先计划后代码：用 Shift+Tab 进入计划模式，理清思路再动手。
  2. 调研用子代理：在复杂查询后加 “use subagents”。
  3. 维护 CLAUDE.md：每次纠正错误后要求更新，保持规则精简。
  4. 内置验证标准：在提示词里直接给出测试用例或对比图。
  5. 提示词要具体：像写接口文档一样写明输入、输出、约束。
  6. 定时重置上下文：每30-45分钟让Claude总结，开新会话继续。
  7. 并行会话 + Git Worktree：让多个Claude同时工作，互不干扰。
  8. 重复操作封装 Skill：一天做两次以上的事就存成命令。
  9. 给真实数据：直接丢错误日志、Slack对话，别自己转述。

一页速览（One-page Summary）

Claude 的上下文窗口是固定大小的“白板”。想让 Claude 保持聪明，必须学会管理这块白板：

  • 写代码前先用计划模式
  • 调研任务交给子代理，不占主会话
  • 用 CLAUDE.md 固化规则
  • 提示词里加验证标准
  • 定时重置会话，避免污染
  • 并行多会话 + git worktree 提升效率
  • 重复操作存成 Skill
  • 直接给真实数据，不靠猜测

常见问答（FAQ）

Q1：Claude Code 的计划模式怎么用？
A：在会话中按 Shift+Tab 即可切换到计划模式，此时Claude只分析文件、出方案，不会修改任何代码。

Q2：子代理（Subagent）会影响费用吗？
A：子代理是独立的会话，会消耗独立的 token，但能有效保护主会话的上下文空间，性价比很高。

Q3：CLAUDE.md 应该放在哪里？
A：放在项目根目录，Claude 启动时会自动读取。建议保持精简，每条规则都应能预防错误。

Q4：如何让Claude在写代码后自动测试？
A：在提示词里写明“写完后用以下用例测试”，并提供测试输入和预期输出。

Q5：上下文重置会不会丢失进度？
A：不会。先让Claude总结当前进度，然后把总结粘贴到新会话，进度完全保留。

Q6：并行会话真的能提高效率吗？
A：能，尤其配合 git worktree。一个写代码一个审查，或者一个写测试一个写实现，效率提升明显。

Q7：Skill 怎么创建？
A：把需要重复执行的完整提示词保存下来，取一个名字，以后直接发名字就能调用。具体方法可参考 Claude Code 文档。

Q8：直接给错误日志，Claude 能看懂吗？
A：能。Claude 非常擅长从原始日志、Slack 对话等真实数据中定位问题，比自己转述准确得多。

参考来源

  • Anthropic 官方最佳实践文档
  • Boris Cherny（Claude Code 创建者）分享
  • 高效AI的 Claude Code 最佳实践解析