Claude Code 最佳实践
这篇文档整理 Claude Code 官方最佳实践，核心是在有限上下文里提高指令质量和协作效率。整体按七条规则逐条展开，每条都配比喻、做法和延伸说明，最后给出小结。
参考来源
Anthropic 为 Claude Code 准备了一本官方秘籍，绝大多数人都没见过，里面包含七个最佳实践。它们的核心其实只围绕一件事：Claude 的上下文窗口（context window）填得很快，一旦填满，表现就会下降。 下面这七条，本质上都是在帮你更好地利用这个最宝贵的资源。
规则一：给 Claude 一个自查的机会
官方原话：给 Claude 一种验证其工作的方式。 这是你能做的「性价比最高」的一件事。
一个比方：包工头盖房子
想象你请了个包工头来盖房子，你把图纸交给他，然后转身就走。一周后回来，心里只能祈祷房子没盖歪。
大多数人用 Claude Code 就是这么干的：告诉它要做什么，然后就撒手不管、听天由命，结果几乎次次翻车。
但如果你再给他一份验收清单呢——门得能开、窗得能关、屋顶不能漏水。这样他在你回来验收之前，就知道该自己检查什么了。
怎么做：别只说要做什么，要说"完成的标准"
比如要做一个注册页面，可以这样下指令：
帮我做一个注册页面，要有姓名和邮箱输入框。
确保邮箱输入框不能乱填，能识别虚假地址。
有人注册成功后就弹出一条消息「谢谢你的邮箱」。
做完这些之后，你自己测试一下，然后给我截个图看看效果。
这样一来 Claude Code 就不是闷头瞎做了——它会自己检查、发现不对劲的地方就自己改，根本不用你再开口。
规则一延伸说明
官方文档建议在提示中包含测试、屏幕截图或预期输出，让 Claude 可以检查自己。没有明确的成功标准，它可能产出"看起来对、实际不能跑"的东西，而你就成了唯一的反馈循环。
| 之前（模糊） | 之后（带验证标准） |
|---|---|
| "实现一个验证电子邮件的函数" | "编写 validateEmail 函数。示例测试用例：user@example.com 为真，invalid 为假。实现后运行测试" |
| "让仪表板看起来更好" | "[粘贴截图] 实现此设计，对结果截图并与原始设计比较，列出差异并修复" |
你的验证可以是测试套件、linter，或一条检查输出的 Bash 命令。投入精力让验证足够可靠。
规则二：先看地图再上路（计划模式）
官方原话：先探索，再规划，最后编码。 把研究、规划和实现分开，避免解决错误的问题。
一个比方：开车去陌生的地方
你要开车去一个从没去过的地方，肯定不会二话不说跳上车就开，指望瞎开能到目的地。你会先在导航上打开地图，确认路线无误，然后才动身。这就是计划模式（Plan Mode）。
三个简单步骤
- 探索：先告诉 Claude Code 你想构建什么，然后切换到计划模式。它会研究你的项目、读取文件，动手之前先摸清现有情况。
- 计划：Claude Code 把所有步骤都写下来——要创建哪些文件、先后顺序、它们之间如何关联。
- 构建：你审视并批准计划，退出计划模式，让它开始构建。
规则二延伸说明
官方推荐的工作流其实有四个阶段（多了一步「提交」），并给出了对应的提示示例：
# 探索（计划模式）
read /src/auth and understand how we handle sessions and login.
# 规划（计划模式）
I want to add Google OAuth. What files need to change? Create a plan.
（按 Ctrl+G 可在编辑器中直接修改计划）
# 实现（默认模式）
implement the OAuth flow from your plan. write tests, run them and fix failures.
# 提交（默认模式）
commit with a descriptive message and open a PR
什么时候可以跳过计划？ 判断标准很简单：要做的东西简单又小（改拼写、加日志、重命名变量）就直接让它执行；东西大一点、要改多个文件、或你不熟悉那段代码时，先规划最有用。如果你能用一句话描述这次改动，就跳过计划。
规则三：「三文鱼」原则（指令要具体）
官方原话：在提示中提供具体的上下文。 你的指令越精确，需要的更正就越少。
一个比方：在餐厅点菜
你一落座，服务员就过来了，你说"随便上点好吃的吧"——服务员哪知道你想吃啥？他只能瞎猜，菜端上来你十有八九得退回去。
但如果你明确说："我要一份三文鱼，五分熟，柠檬汁单放后厨"，他就完全知道该怎么做了——这条规则也因此被称作「三文鱼」原则。
Claude Code 也是同样的道理。如果你只说"把我的网站做得更好看点"，它只能瞎猜——你说的"好看"是指加载更快？界面更漂亮？还是加更多页面？
换成具体指令就清楚多了：
把主页的标题改成蓝色，再把字体调大一点，再加一个「开始使用」按钮。
只需一条指令即可，无需反复沟通。
小技巧：用 @ 符号直接引用文件
还有一招很实用：用 @ 符号把 Claude 直接引到某个文件或文件夹。 只要输入 @ 加文件名，Claude Code 在行动前会先读取这个文件。这就像把菜单递给服务员、直接指着你想点的菜——你给它的信息越多，结果越好。
规则三延伸说明
| 之前（模糊） | 之后（具体） |
|---|---|
| "为 foo.py 添加测试" | "为 foo.py 编写测试，涵盖用户已注销的边界情况，避免 mock" |
| "为什么 ExecutionFactory 的 api 这么奇怪？" | "查看 ExecutionFactory 的 git 历史并总结其 api 是如何形成的" |
| "添加日历小部件" | "参考 HotDogWidget.php 的现有模式，实现一个新的日历小部件……" |
| "修复登录错误" | "用户报告会话超时后登录失败，检查 src/auth/ 中的 token 刷新，先写一个能复现的失败测试再修复" |
官方还列出了几种"提供丰富上下文"的方式：用 @ 引用文件、直接粘贴图像、提供文档 URL、用 cat error.log | claude 管道传数据，或干脆让 Claude 自己用命令去拉取它需要的上下文。
规则四：给 Claude 一份员工手册（CLAUDE.md）
官方原话：编写有效的 CLAUDE.md。 运行
/init生成初始文件，再随时间精化。
一个比方：入职第一天的新同事
把 Claude 想象成公司里的新同事。入职第一天，他完全不知道你喜欢怎么做事、不清楚你的风格和偏好、更不知道你的项目该怎么搭建——没有指示，他全靠猜。
但要是第一天就给他一本手册，从此就再也不用反复解释任何事了。
怎么做：/init
运行 /init，它会扫描你的项目，然后创建一个叫 CLAUDE.md 的文件。这就是 Claude 的「员工手册」——从此每当你打开这个项目，Claude 就已经完全了解你的做事风格。你可以亲自编辑它，添加个人偏好、设定规则、规定项目结构。
关键：一定要保持简洁
这里有一个被反复强调的重点：手册太长没人愿意读，Claude 也一样。
如果你塞太多内容（比如塞成 100 页），Claude 就会开始忽略其中一部分信息。所以只包含那些「Claude 自己无法搞定」的东西。
官方给出的取舍清单：
| ✅ 应该写进去 | ❌ 不要写进去 |
|---|---|
| Claude 猜不到的 Bash 命令 | Claude 读代码就能搞清楚的东西 |
| 与默认不同的代码风格规则 | Claude 已知的标准语言约定 |
| 测试指令和首选测试运行器 | 详细的 API 文档（改为放链接） |
| 仓库礼仪（分支命名、PR 约定） | 经常变化的信息 |
| 项目特有的架构决策 | "编写干净的代码"这类自明的废话 |
官方判断法则：对每一行问自己——「删掉这行会导致 Claude 犯错吗？」不会的话，就删掉。膨胀的 CLAUDE.md 会让 Claude 忽略你真正重要的指令。
规则五：让 Claude 采访你（最大的转折点）
官方原话：让 Claude 采访你。 对于更大的功能，从最小的提示开始，让 Claude 先采访你。
一个比方：别像病人自己给自己看病
大多数人用 Claude Code，就像病人自己给自己看病——总想写出完美的提示，就像给自己开出完美的处方一样。
但其实你不必非得是专家，你只需描述你的需求，剩下的交给 Claude Code。
那一句改变一切的话
这一招往往能带来最大的转折：在告诉 Claude Code 想做什么之后，再加上一句——
针对我的项目采访我一下，然后问我一些我没想到过的问题。
这样一来 Claude Code 就成了诊断医生，会反过来问你问题，比如：
- 你需要一个登录页面吗？
- 如果有人输错了密码怎么办？
- 这个功能在手机上能用吗？
这些都是你很可能还没考虑到、但日后不处理就会出问题的事。等它问完，Claude Code 会根据你的回答制定一份完整的计划——你根本不需要写出完美的提示词，只需要和它聊上一回。
规则五延伸说明
官方给出的提示模板（明确建议用 AskUserQuestion 工具）：
I want to build [简要描述]. Interview me in detail using the AskUserQuestion tool.
Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs.
Don't ask obvious questions, dig into the hard parts I might not have considered.
Keep interviewing until we've covered everything, then write a complete spec to SPEC.md.
官方补充：规范写好后，开一个新会话来执行它——新会话有干净的上下文，可以完全专注于实现，而你手上有一份书面规范可以参考。
规则六：清理桌面（管理上下文）
官方原话：积极管理上下文。 在不相关的任务之间频繁运行
/clear来重置上下文。
一个比方：被埋住的书桌
你的 Claude Code 会话就像一张书桌。你发的每条消息、Claude 读的每个文件、它做的一切，全堆在这张桌子上。
桌子被埋住时，它就啥也找不着了：变慢、搞混、之前告诉它的信息开始出错。这时你坐那儿觉得"Claude Code 坏了"——其实它没坏，只是你的书桌满了。
三个解决办法
/clear——把桌子打扫干净 每次完成一个任务、开始新任务时输入/clear，就像把书桌清空、从头开始，你会得到更好的结果。回退——项目的时光机 如果 Claude Code 跑偏了，按
Esc键就能停下来；再按一次Esc打开回退菜单（也可用/rewind）。你可以回到对话中的任意位置，撤销它之后做的所有事——包括它写的代码和你们的对话，全都能撤销。/compact——保留精华、清掉杂乱 如果你正沉浸在工作中、不想从头再来，随时可以输入/compact。它会保留所有重要信息，清除掉无关紧要的杂乱内容。还能加指令，比如/compact 重点关注 API 的改动。
规则六延伸说明
官方把这些归纳为一个核心原则——上下文是你的根本约束，并额外提醒：
- 在一个会话里如果你对同一个问题纠正 Claude 超过两次，上下文就已经被失败的方法污染了。此时不如
/clear重开，配一个包含"你刚学到的东西"的更好提示——干净的会话几乎总是优于带着一堆纠正的长会话。 - 回退（检查点）只跟踪 Claude 做的改动，不是 git 的替代品。
规则七：多厨房并行（并行多会话）
官方原话：运行多个 Claude 会话。 并行运行以加快开发、跑隔离实验或启动复杂工作流。
一个比方：三位大厨同时开工
现在你不必一次只开一个会话了。在桌面应用里，你可以同时打开多个会话：
- 一个会话用来清理代码；
- 另一个负责编写一个新页面；
- 还有一个专门构建新功能。
就像三位大厨在三个不同的灶台前同时开工。
直接出自官方手册的小技巧：写完再让另一个会话审查
这一招特别值得推荐：先开一个会话去构建内容，然后再开一个新会话去审查它。
之所以有意思，是因为一个全新的会话不会对刚做的工作产生偏见——这就像让另一位厨师来品尝第一位厨师做的菜，得到的评价才更客观。
延伸说明
官方称之为 Writer / Reviewer 模式：
| 会话 A（Writer 写） | 会话 B（Reviewer 审） |
|---|---|
为我们的 API 端点实现速率限制器 |
|
审查 @src/middleware/rateLimiter.ts，查找边界情况、竞态条件和与现有中间件的一致性 |
|
这是审查反馈：[会话 B 输出]。解决这些问题。 |
官方还列出了几种并行方式：Worktrees（隔离的 git 检出）、桌面应用（可视化管理多会话）、Claude Code on the web（云端隔离虚拟机）、Agent teams（自动协调的多会话）。核心价值除了加速，更在于"新鲜的上下文能改进代码审查，因为 Claude 不会偏袒它自己刚写的代码"。
小结
| # | 规则 | 比喻 | 一句话要点 |
|---|---|---|---|
| 1 | 给 Claude 自查的机会 | 给包工头一份验收清单 | 提供测试 / 截图 / 预期输出，让它自己检查 |
| 2 | 先看地图再上路 | 开车前先开导航 | 用计划模式：先探索 → 再规划 → 最后编码 |
| 3 | 「三文鱼」原则 | 点菜要点具体 | 指令越精确，需要纠正的次数越少；善用 @ 引用文件 |
| 4 | 给 Claude 员工手册 | 新同事入职手册 | 用 /init 生成 CLAUDE.md，并保持简洁 |
| 5 | 让 Claude 采访你 | 别自己给自己看病 | 加一句"采访我一下"，让它反问你没想到的问题 |
| 6 | 清理桌面 | 桌子满了就清空 | /clear 重置、Esc 回退、/compact 压缩 |
| 7 | 多厨房并行 | 三位大厨同时开工 | 并行多会话；写完用新会话客观审查 |
最后一点提醒（来自官方）：这七条不是铁律，而是"通常效果很好的起点"。多留意什么有效、什么让 Claude 卡住，慢慢培养自己的直觉——知道何时该具体、何时该开放，何时该规划、何时该探索，何时清空上下文、何时让它累积。