Claude Code官方最佳实践10条：Plan模式、CLAUDE.md与并行工作流实战指南

Claude Code 发布已有一段时间，一些顶尖开发者甚至用它编写了火星探测车的代码。然而，许多人在使用了数月后，仍然停留在“让它写个简单函数”的初级阶段。究其原因，是他们从未掌握 Claude Code 真正的核心用法。

本文将整合 Claude Code 作者 Boris Cherny 的内部团队实践与官方最佳实践文档，为你提供 10 条即学即用的高级技巧。如果想深入探讨 AI 编程助手的最佳实践，欢迎来云栈社区交流。

一切的根本：上下文窗口是你最贵的资源

在探讨具体技巧之前，首先要理解一个核心概念：Claude 的上下文窗口。

你可以把它想象成一块大小有限的白板。你发送的每条消息、Claude 读取的每个文件、执行的每条命令输出，都会写在这块白板上。随着白板逐渐被填满，Claude 的表现会开始下降——它可能忘记早期的指令，开始犯错，甚至变得“迟钝”。

因此，下文所有的技巧，本质上都是为了帮助你更高效地利用这块宝贵的白板。

技巧一：让 Claude 自我验证工作成果

这是能带来最高单一收益的转变。

大多数人的做法是：描述需求 → 等待 Claude 输出 → 自己手动检查是否存在 Bug。结果就是你成了唯一的质检员，每个错误都需要你亲自发现。

Boris 团队的做法是：将具体的验证标准直接写入 Prompt（提示词）中。

例如，当你需要编写一个邮箱验证函数时，不要只说“写一个邮箱验证函数”，而是给出明确的测试用例：

💡 PROMPT

写一个验证邮箱格式的函数。测试用例要求：hello@gmail.com 应该通过验证，hello@ 应该验证失败，@domain.com 也应该验证失败。写完后请运行你编写的测试并告诉我结果。

有了明确的验收标准，Claude 就能自主检查输出结果，为你省去大量的人工审查时间。

官方文档中还有一个更进阶的玩法：给 Claude 截一张设计稿的图片，然后指示它“实现这个设计，完成后截图并与原设计稿进行对比，列出所有差异并进行修复”。这就为 AI 构建了一个自动纠错的闭环。

技巧二：先规划，再动手执行

这个坑很多人都踩过：你描述了需求，Claude 直接开始编写代码，15 分钟后你发现它解决的是另一个完全不同的问题。

Claude Code 内置了一个 Plan Mode（规划模式）。在该模式下，Claude 只会读取文件、梳理脉络，而不会修改任何一行代码。

Boris 团队的标准工作流如下：

1. 进入 Plan Mode，让 Claude 读取所有相关文件，摸清整个项目的结构。
2. 让 Claude 输出一份完整的执行计划：包括需要修改哪些文件、改动的先后顺序、以及可能遇到的陷阱。
3. 你自己审阅这份计划，发现问题直接修改。
4. 切换回普通模式，让 Claude 严格按照计划执行。
5. 任务完成后，让 Claude 撰写清晰的提交信息（Commit Message）。

团队中有人采用了更极致的做法：用一个 Claude 实例来撰写计划，再启动另一个 Claude 实例，以“高级工程师”的身份来审查这份计划。只有计划通过审核，才开始真正的编码工作。

先投入 10 分钟做好规划，往往能省下后续 2 小时的返工时间。

技巧三：CLAUDE.md 是你最被低估的效率工具

如果你每天使用 Claude Code，却还没有创建 CLAUDE.md 文件，那么你正在浪费大量时间重复自己。

CLAUDE.md 是一个放在项目根目录下的文件，Claude 每次启动时都会读取其中的内容。你把规则写进去，Claude 每次都会自动遵守，无需你再三重申。

例如下面这些常见但每次都要重复说明的事项：

• 只使用 ES Modules，不要用 CommonJS。
• 测试中不要使用 mock。
• 每次修改代码后必须运行 linter 检查。
• 我们的分支命名规范是 feature/ticket-编号。

把这些写入 CLAUDE.md，即可一劳永逸。

Boris 团队还有一个非常聪明的习惯：每次 Claude 犯了某个错误，在纠正它之后，会在对话末尾加上这样一句：

💡 PROMPT

请更新你的 CLAUDE.md 文件，确保下次不再犯同样的错误。

Claude 会将这条新规则写入文件。下次启动时，规则自动生效。长此以往，CLAUDE.md 就演变成一个能够持续自我进化的规则系统。

⚠️ 重要提示： 别让 CLAUDE.md 变成一个长达 500 行的“怪物”。其中的每一行都应该对应一个真实发生过的错误。如果你无法回答“如果没有这行规则，Claude 可能会犯什么错？”，那么就删掉它。文件过长会导致 Claude 开始忽略其中的细节。

技巧四：并行操作是真正的效率倍增器

这是 Boris 整个团队公认收益最大的改变。

Claude Code 支持多个会话（Session）同时运行。你可以利用 Git 的 worktrees 功能，在同一个项目中创建多个独立的工作区。团队中有人同时运行 3 到 5 个会话，每个会话处理不同的任务。

一个典型的并行用法是：

• 会话 A：编写新功能。
• 会话 B：审查会话 A 编写的代码，寻找边界情况和潜在漏洞。
• 将会话 B 的反馈提供给会话 A。

一个负责编写，一个负责审查，这样产出的代码质量，远比单个会话反复修改要高得多。

另一种用法是：让会话 A 先编写测试（测试驱动开发，TDD），然后会话 B 再编写能让这些测试通过的代码。让 Claude 帮你实践 TDD，而无需你亲自执行每一步。这种并行开发模式对后端 & 架构复杂项目的效率提升尤为显著。

并行带来的不仅是速度的提升，更是代码质量上本质的不同。

技巧五：修复 Bug，直接向 Claude 投喂原始数据

很多人修复 Bug 的姿势是：将 Bug 现象描述成文字，然后让 Claude 猜测问题所在。接着 Claude 猜一次，你纠正一次，循环往复。

Boris 团队的做法直接得多：把原始错误数据扔给 Claude，然后只说一个词：“fix。”（修复）

他们的 Claude Code 接入了 Slack MCP。当有 Bug 报告在 Slack 频道中出现时，他们直接将整个 Slack 对话线程粘贴给 Claude，并附上指令：“fix。” Claude 会自己读取报错信息、定位相关代码、并实施修复。

或者更简单，直接说：“去修复一下 CI 上失败的测试。” 不解释失败原因，不指定具体文件。让 Claude 自己去追踪。

关键在于：提供给 Claude 原始、真实的信息——错误日志、Slack 线程、Docker 输出——而不是你对这些信息的二次描述。前者使 Claude 能够自主追踪问题根源，后者则迫使 Claude 在你有限的理解框架内进行猜测。

技巧六：使用子智能体，保持主对话上下文清洁

还记得那块有限的白板吗？

当 Claude 需要深入调查一个复杂问题时，它可能需要阅读大量文件。调查完成后，白板可能已经占用过半，这时才开始真正的工作，效果自然会打折扣。

子智能体（Subagents） 正是为了解决这个问题：让一个独立的 Claude 实例去执行调查任务，它拥有自己独立的上下文。调查完成后，它只需将结论汇报给你的主会话，主会话的白板空间得以保持洁净。

使用方法很简单，在任何调查类请求后面附加一句指令即可：

💡 PROMPT

使用子智能体来……（后面接具体任务）

例如：“使用子智能体来搞清楚我们的支付流程是如何处理失败交易的。”

Boris 团队的做法更进一步：他们利用 Hooks 和 Opus 4.5 模型构建子智能体，自动扫描每一个权限请求，拦截可疑操作，自动批准安全请求。这相当于为 Claude Code 安装了一位智能安全门卫。这种利用多智能体协作解决复杂任务的方法，正是当前人工智能领域的前沿实践之一。

技巧七：编写 Skill（自定义命令），消灭重复劳动

Boris 的规则非常简单：任何一天内做了两次的事情，就把它变成一个 Skill。

Skill 是保存下来的工作流程，你可以给它命名，之后直接调用。

例如，一个名为 /fix-issue 的 Skill，你只需要输入 /fix-issue 447，Claude 便会自动执行以下操作：

1. 读取 GitHub 上的 Issue #447。
2. 定位项目中相关的文件。
3. 实施修复。
4. 编写并运行测试。
5. 创建 Pull Request。

整个过程，一个命令完成，无需任何上下文切换。

Boris 团队中还有人专门创建了 BigQuery Skill，使得团队任何成员都可以直接在 Claude Code 中运行数据分析，而无需手写一行 SQL。Boris 本人表示，他已经有 6 个月没有手动编写过 SQL 了。

最新发布的 /simplify 和 /batch 两个新 Skill 也值得关注——前者用于自动并行审查 PR 并确保符合 CLAUDE.md 规范，后者用于批量处理可并行化的代码迁移任务。

技巧八：高阶提示词技巧，迫使 Claude 给出更优解

Boris 分享了三个其团队常用的、有些反直觉的 Prompt 技巧：

① 让 Claude 来审查你

在你准备提交代码之前，可以这样指示：

💡 PROMPT

请以最挑剔、最严格的方式质问我这些代码改动，直到我通过你的所有测试，才能开启 PR。

角色互换，让 Claude 担任代码审查者（Reviewer），而你需要为自己的编码决策辩护。这个方法往往能发现比你自行审查时多得多的问题。

② 要求 Claude 推翻重来，实现更优雅的方案

Claude 的第一次实现方案往往选择了最容易的路径。在它完成初步方案后，你可以说：

💡 PROMPT

你现在已经了解了所有背景信息。请推翻刚才的方案，重新构思，给我一个更优雅的实现。

这个时候，Claude 通常会给出一个远比初始方案更出色的答案。

③ 要求 Claude 提供证明

不要仅仅因为测试通过就相信一切正常：

💡 PROMPT

请向我证明这个改动是有效的。展示 main 分支和我的 feature 分支在行为上的具体差异。

技巧九：善用 /clear 和检查点（Checkpoint）

当你在一个会话中工作了很长时间，期间修复了 Bug、询问了无关问题、甚至聊到了其他话题……这就会导致 上下文污染。白板变得杂乱，Claude 的表现开始不稳定。

解决方法有两个：

• /clear：硬重置，清空整个上下文。然后用一个更清晰、精准的 Prompt 重新开始。
• /compact：软重置，告诉 Claude 需要保留什么内容，清理掉其他噪音。例如：/compact 专注于支付集成相关的改动。

关于检查点（Checkpoint）：每当 Claude 执行了代码改动，系统都会自动创建一个存档点。如果你发现方向走错了，可以随时回滚——可以选择仅回滚代码、仅回滚对话、或者两者都回滚。

检查点在你关闭终端后依然存在。第二天回来，你仍然可以回滚到昨天的某个状态。

建议： 如果你在同一个会话中就同一个问题纠正了 Claude 两次，但它仍然没有改正——不要再尝试第三次纠正。果断使用 /clear 清空上下文，重新构思一个更精准的起始 Prompt，从头开始。

技巧十：将 Claude Code 作为强大的学习工具

大多数人只把 Claude Code 当作生产工具。而 Boris 的团队还将其视为绝佳的学习工具。

当你接手一个新项目时，可以直接向 Claude 提问：

💡 PROMPT

• 这个项目的日志系统是如何工作的？
• 这个 processUserData() 函数具体在做什么？为什么这里要调用 methodA() 而不是 methodB()？
• 从用户发出第一个请求到会话建立，完整的登录流程是什么？

这些原本你需要请教资深同事的问题，Claude 能回答得一样好，而且永远不会感到厌烦。

还有两个有趣的玩法：

• 让 Claude 生成 HTML 幻灯片：将复杂的代码逻辑可视化成一张张幻灯片。Boris 表示效果出奇地好。
• 间隔重复学习：你向 Claude 阐述自己对某个模块的理解，Claude 通过不断追问来发现你理解中的盲点，然后记录下来，在后续的对话中反复考察你。这是一个完整且高效的学习闭环，完全可以在 Claude Code 内运行。

最后：四种最常见的失误模式

失误模式	典型症状	解决方案
厨房水槽式会话	一个会话里话题飘到五个不同的方向，上下文混乱。	每切换一个新任务，就使用 /clear。
纠正死循环	针对同一个错误，反复纠正 Claude 3 次以上。	清空上下文，重新编写更精准的 Prompt。
CLAUDE.md 膨胀	规则文件变得冗长，超过 500 行，失去重点。	对每行规则自问：“如果没有这行，Claude 会犯什么具体错误？”，删除多余的。
无边界调查	Claude 为回答一个问题读取了数百个文件，耗尽了上下文。	为调查任务划定明确范围，或使用子智能体（Subagents）进行隔离调查。

核心要点总结

• 用具体的验证标准替代“希望 Claude 能猜对”。
• 先规划，后执行，将时间投资在计划阶段。
• 让 CLAUDE.md 自我进化，将每次纠正转化为持久性规则。
• 并行会话（Sessions） 是提升效率的最大杠杆。
• 使用子智能体（Subagents） 来保持主对话上下文的洁净。
• 果断使用 /clear 比陷入重复纠正的循环更有效。
• 将 Claude Code 视为一位经验丰富的工程师搭档，而不仅仅是一个代码生成器。

更多详细的操作方法和最佳实践，建议查阅 Claude Code 官方最佳实践文档。