# 用了 3 个月 Claude Code，这 9 条最佳实践让我少走了无数弯路
**作者**: Yanhua
**日期**: 2026-03-01T13:27:19.000Z
**来源**: [https://x.com/yanhua1010/status/2028099767968903629](https://x.com/yanhua1010/status/2028099767968903629)
---
用了 3 个月 Claude Code，我踩过的最大坑不是提示词写得差，不是模型选错了，是一个大多数人根本没意识到的东西：上下文窗口。
它就像房间里的大象。你的 Claude 越来越笨，你以为是模型问题，其实是你把白板写满了。
这篇文章，我会把自己从"上下文小白"到"上下文管理高手"的完整经验分享出来。每一条都是实战验证过的。
如果你在用 Claude Code，这篇文章可能帮你省掉几十个小时的无效返工。
好，我们发车了。
## 先搞懂一件事：上下文窗口到底是什么
Claude 的大脑有一块白板。
你发的每条消息、Claude 读的每个文件、执行的每条命令，全都会写在这块白板上。
白板满了，Claude 的表现就开始下滑。它会忘记你一小时前的指令。会犯一些本不该犯的错误。会开始重复自己的话。
这就是为什么你有时候觉得"Claude 变笨了"。它没变笨，它只是记不住了。
Claude Code 创建者 Boris Cherny 说过一句话：
> 想用好 Claude Code，关键就是管理好这块白板。
理解了这一点，后面所有的策略才讲得通。
## 策略一：别让 Claude 一上来就写代码
这是几乎所有新手踩的第一个坑。
你描述一个需求，Claude 立刻开始写代码。十五分钟后你发现，它解决的根本不是你想要的问题。
更糟的是，这十五分钟的代码生成已经吃掉了大量上下文空间。
正确做法：先切计划模式。
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 Code，但还没有认真维护 CLAUDE.md，你在浪费大量效率。
CLAUDE.md 是 Claude 每次启动时都会读的文件。你写什么规则，Claude 就按什么方式跟你工作。
想想你经常重复说的话：
- "用 ES modules，不用 CommonJS"
- "测试不要用 mocks"
- "代码改完后跑一次 linter"
- "分支命名格式是 feature/工单编号"
没有 CLAUDE.md，每次都得重新说。有了 CLAUDE.md，说一次就够。
但最关键的技巧是这个：
每次 Claude 犯了错，你纠正完以后，最后加一句：
> "更新 CLAUDE.md 以免再犯这个错误。"
Claude 会把教训写进自己的规则。时间久了，CLAUDE.md 会变成一份专门为你优化的"活文档"。
我的 CLAUDE.md 里有一条规则就是这样来的：我发现 Claude 老是在 Obsidian Vault 里创建 .txt 文件（Obsidian 根本不显示），纠正了一次之后加了一条"Vault 内只创建 .md 文件"的规则。从此再也没犯过。
⚠️ 但要注意一点：CLAUDE.md 不能太长。
如果写到 500 行，Claude 的注意力会被分散，有些规则就被忽视了。每条规则都应该回答一个问题：这条没了，Claude 会犯错吗？如果不会，删掉。
## 策略四：给 Claude 自检的机会
大多数人的用法是：描述需求 → 祈祷 Claude 写对 → 自己逐行检查。
这样你就成了唯一的质检员，信我，很累。
更好的做法：在提示词里内置验证标准。
举个例子。你要写一个邮箱验证函数，不要只说"写一个邮箱验证函数"。
换成这样说：
> "写一个函数判断邮箱是否有效。用这些案例测试：hello@gmail.com 应该通过，hello@ 应该失败，@domain.com 应该失败。写完后执行测试。"
Claude 就能自我检验了，不用你逐行盯着看。
视觉类任务也一样。改按钮设计？粘贴截图并说："让它看起来像这样，改完后截图给我，告诉我有什么不同。"
给 Claude 一个对比标准，避免你成为唯一反馈环节。这一招能帮你节省几个小时。
## 策略五：写提示词，要像写技术文档一样具体
Claude 能从上下文推断很多东西，但它读不懂你的心思。
看对比：
❌ 模糊："给 auth.py 加测试"
✅ 具体："写 auth.py 的测试，覆盖用户请求中途会话过期的情况。不允许用 mocks。重点测试令牌看似有效但实际过期的边缘情况。"
任务一样，结果截然不同。
你也可以直接指向 Claude 应该看的位置。
❌ "为什么这个函数表现怪怪的？"
✅ "看这个文件的 git 历史，找出这个行为是什么时候加进来的，为什么会有。"
区别就是：Claude 是在胡乱猜测，还是在给你具体答案。
作为后端开发，我现在写提示词的习惯是：明确输入、明确输出、明确约束、明确验证方式。把它当成写接口文档。
## 策略六：每 30-45 分钟重置你的上下文
你跟 Claude 交谈久了，会发现它开始跑偏。
反复啰嗦。忘了你早期给的规则。回答质量明显下降。
这就是上下文污染。白板写满了，Claude 只能覆盖旧内容。
Boris 的团队在复杂任务中每 30-45 分钟就做一次上下文重置。
操作方法：
1️⃣ 让 Claude 总结当前进度："总结我们目前做了什么，还剩哪些任务，当前有哪些问题。"
2️⃣ 开一个新会话
3️⃣ 粘贴总结，继续做
这能保持 Claude 思路清晰，避免长时间会话带来的"脑雾"。
很多人舍不得关会话，觉得"上下文都在里面"。实际上，一个臃肿的上下文还不如一份精炼的总结。
## 策略七：并行会话 + Git Worktree
这是 Boris 团队公认的生产力杀手锏。
你可以同时开启多条 Claude Code 会话，配合 git worktree（代码库的多个独立工作副本），互不干扰。
举个例子：
🅰️ 会话 A 负责写新功能
🅱️ 会话 B 负责审查 A 写的代码
把 A 的产出给 B，让它找边缘问题和缺陷。然后把反馈带回 A。
一个 Claude 写，一个 Claude 审。代码质量更高，效率更快。
有人同时开 3-5 个会话，给 worktree 起名并设置 shell 别名（za, zb, zc），一键切换。
你也能用同样的方法搞测试驱动开发：一个 Claude 先写测试，另一个写通过测试的代码。TDD，但 Claude 做了所有重活。
## 策略八：把重复操作封装成 Skill
如果你每天在 Claude Code 里重复做一件事超过两次，就该把它变成 Skill。
Skill 本质是保存好的工作流程。你写好步骤，取个名字，以后只需要调用名字。
我自己封装了十几个 Skill：封面图生成、文章发布、图片压缩、网页转 Markdown......
每一个都是从"每次手动说一遍完整提示词"进化成"一条命令搞定"的。
Boris 的规则值得借鉴：如果每天做两次以上，就封装成 Skill。
Boris 团队给 BigQuery 搭了一个 Skill，团队成员直接在 Claude Code 里做数据分析查询，连 SQL 都不用写。一个 Skill，贯穿所有项目复用。
## 策略九：给真实数据，而不是你的猜测
传统的 Bug 修复流程是这样的：
你用语言描述 Bug → Claude 猜错几次 → 改几次 → 最终修好
这中间浪费的上下文空间是巨大的。
更快的做法：给 Claude 真实错误信息，然后走开。
Boris 团队接入了 Slack MCP。当 Slack 上报 Bug，他们把对话直接贴给 Claude，然后扔一个字："fix"。
没有多余解释，没有手把手辅导。Claude 自己看对话、找问题、修复。
或者说"去修那个失败的 CI 测试"，然后走开。没告诉 Claude 哪个测试，没说明为什么失败，Claude 照样搞定。
关键是：给 Claude 的是真实数据（Slack 线程、错误日志、Docker 输出），不是你对问题的猜测。
Claude 非常擅长读分布式系统日志，精准追踪故障点。作为后端开发，这一点让我非常惊喜。
## 把这些串起来：我的日常工作流
分享一下我现在的典型工作流程，把上面的策略串联起来：
开始任务前：
- 检查 CLAUDE.md 是否需要更新
- 明确任务复杂度，决定是否需要计划模式
任务执行中：
- 复杂调研 → 扔给子代理
- 写代码 → 主会话 + 具体提示词 + 内置验证
- 代码审查 → 开第二个会话
每 30-45 分钟：
- 让 Claude 总结进度
- 评估是否需要上下文重置
任务完成后：
- Claude 犯过的错 → 更新 CLAUDE.md
- 重复操作 → 封装成 Skill
这套流程让我的效率至少提升了 3 倍。不是因为 Claude 变强了，而是因为我学会了管理它的"大脑"。
## 最后的话
回到文章开头的那个比喻。
上下文窗口就是 Claude 的白板。白板的大小是固定的，但你可以决定在上面写什么、什么时候擦掉重来。
管理上下文，本质上就是在管理 AI 的注意力。
这是一项新技能。它跟编程能力无关，跟领域知识无关，但它决定了你能从 AI 身上获得多少价值。
越早掌握，越早受益。
你踩过最大的上下文窗口的坑是什么？评论区聊聊 👇
参考来源：
- Anthropic 官方最佳实践文档：https://code.claude.com/docs/en/best-practices
- Boris Cherny（Claude Code 创建者）分享：https://x.com/bcherny
- @Meer_AIIT 的 Claude Code 最佳实践解析
## 相关链接
- [Yanhua](https://x.com/yanhua1010)
- [@yanhua1010](https://x.com/yanhua1010)
- [56K](https://x.com/yanhua1010/status/2028099767968903629/analytics)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [@domain](https://x.com/@domain)
- [auth.py](https://auth.py/)
- [auth.py](https://auth.py/)
- [CLAUDE.md](https://claude.md/)
- [CLAUDE.md](https://claude.md/)
- [https://code.claude.com/docs/en/best-practices](https://code.claude.com/docs/en/best-practices)
- [https://x.com/bcherny](https://x.com/bcherny)
- [@Meer_AIIT](https://x.com/@Meer_AIIT)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [9:27 PM · Mar 1, 2026](https://x.com/yanhua1010/status/2028099767968903629)
- [56.1K Views](https://x.com/yanhua1010/status/2028099767968903629/analytics)
- [View quotes](https://x.com/yanhua1010/status/2028099767968903629/quotes)
---
*导出时间: 2026/3/2 18:58:38*