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

用了 3 个月 Claude Code，这 9 条最佳实践让我少走了无数弯路 用了 3 个月 Claude Code，这 9 条最佳实践让我少走了无数弯路 Modified March 6 "更新 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@ 应该失败， .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 最佳实践解析 hello@gmail.com auth.py auth.py @Meer AIIT "更新 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@ 应该失败， hello@gmail.com .com 应该失败。写完后执行测试。" Claude 就能自我检验了，不用你逐行盯着看。 视觉类任务也一样。改按钮设计？粘贴截图并说："让它看起来像这样，改完后截图给我，告诉我有什么不同。" 给 Claude 一个对比标准，避免你成为唯一反馈环节。这一招能帮你节省几个小时。 策略五：写提示词，要像写技术文档一样具体 Claude 能从上下文推断很多东西，但它读不懂你的心思。 ❌ 模糊："给 auth.py加测试" auth.py ✅ 具体："写 auth.py的测试，覆盖用户请求中途会话过期的情况。不允许用 mocks。重点测试令牌看似有效但实际过期的边缘情况。" auth.py 任务一样，结果截然不同。 你也可以直接指向 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 最佳实践解析 @Meer AIIT 🔗 原文链接： https://x.com/yanhua1010/status/202... https://x.com/yanhua1010/status/202... 用了 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 写出完整计划：改哪些文件？步骤顺序？哪里可能出错？ 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 犯了错，你纠正完以后，最后加一句：