Claude Code 官方最佳实践：怎么把它用好

原文 · Anthropic（Claude Code 团队）

几乎所有技巧都围绕一件事：上下文窗口会很快被塞满

读原文

导读

Claude Code 不是「问一句答一句」的聊天机器人，它能读文件、跑命令、改代码，自己一路把问题做完，你在旁边看、纠偏，或者干脆走开。这篇官方指南把 Anthropic 内部团队和大量工程师摸出来的有效模式做了系统化整理。

它最关键的一条暗线是：几乎所有最佳实践都源自同一个约束，Claude 的上下文窗口会很快被塞满，而塞满之后性能会下降。下面按原文结构做完整精译导读，建议结合上方链接读英文全文。

一、一切的起点：管好上下文窗口

上下文窗口装着你整段对话：每一条消息、Claude 读过的每个文件、每一次命令输出。一次调试或一次代码库探索，动辄就吃掉几万 token。

为什么这件事最重要：上下文越满，模型表现越差。快满的时候，Claude 会开始「忘掉」早先的指令、犯更多错。所以上下文窗口是你最该管理的资源，后面几乎每条技巧都是在为它服务。

“Claude’s context window fills up fast, and performance degrades as it fills.”

二、给 Claude 一个能自己验证的办法

Claude 在「看起来做完了」时就会停。如果没有一个它能自己跑的检查，「看起来完成」就是它唯一的信号，于是你就成了那个验证循环：每个错误都得等你去发现。给它一个能产出「通过 / 失败」的东西，循环就能自己闭合，Claude 做完、跑检查、读结果、不断迭代直到通过。

这个检查可以是任何能在对话里读到信号的东西：一套测试、构建的退出码、linter、把输出和基准对比的脚本，或者把浏览器截图和设计稿对照。原文给了三个改写示例：与其说「写个校验邮箱的函数」，不如附上具体测试用例并要求「实现后把测试跑一遍」；与其说「让仪表盘好看点」，不如「贴上设计稿，实现后截图和原图对比、列出差异再修」；与其说「构建挂了」，不如贴上报错并要求「修复并验证构建通过，解决根因，别把错误压下去」。

检查建好后，再决定它对「停止」卡得多死：可以在同一条 prompt 里让它跑检查并迭代；可以设成 /goal 条件，由独立评估器每轮复检直到成立；可以用 Stop hook 当成确定性闸门，不过则不让本轮结束；也可以让验证子代理或动态工作流用一个全新的模型去反驳结果，做事的那个就不是打分的那个。最后一点：让 Claude 拿证据说话，给出测试输出、跑了什么命令返回了什么、或结果截图，而不是只声称「成功了」。

“Give Claude something that produces a pass or fail, and the loop closes on its own.”

三、先探索，再规划，最后写代码

让 Claude 直接上手写，容易写出「解决了错误问题」的代码。推荐的工作流分四步：探索（进 plan mode，只读文件、答问题、不改动）、规划（让它产出详细实现计划，可按 Ctrl+G 在编辑器里直接改计划）、实现（切出 plan mode，让它对照计划写代码、写测试、跑测试修失败）、提交（让它写描述性的 commit 信息并开 PR）。

但 plan mode 也有成本。范围清楚、改动很小的事（改错别字、加一行日志、重命名变量）直接让它做就行。规划最有用的时候，是你对方案没把握、改动跨多个文件、或你不熟那段代码。一句话判断：如果你能用一句话描述这个 diff，就跳过计划。

“If you could describe the diff in one sentence, skip the plan.”

四、在 prompt 里给足具体上下文

Claude 能推断意图，但读不了你的心思。指令越精确，要返工的地方越少。原文给的策略是：圈定范围（说清哪个文件、什么场景、测试偏好，比如「为 foo.py 写测试，覆盖用户登出的边界情况，别用 mock」）；指明来源（让它去 ExecutionFactory 的 git 历史里找答案，而不是凭空猜）；参照已有模式（让它先看 HotDogWidget.php 这种现成例子再照着写）；描述症状（给出症状、可能位置、以及「修好」长什么样，先写一个能复现的失败测试再修）。

至于喂料的方式：用 @ 引用文件（Claude 会先读再答）、直接粘贴或拖拽图片、给文档和 API 的 URL（用 /permissions 把常用域名加白名单）、用 cat error.log | claude 把文件内容直接管道进去、或者干脆让 Claude 自己用 Bash / MCP / 读文件去把需要的上下文拉进来。

“Claude can infer intent, but it can’t read your mind.”

五、配好你的环境：CLAUDE.md 与扩展

CLAUDE.md 是 Claude 每次对话开头都会读的文件，放它从代码里推不出来的持久上下文：Bash 命令、代码风格、工作流规则。用 /init 能基于当前项目结构生成一个起步版，再慢慢打磨。它每次都加载，所以只放普遍适用的东西；只在某些时候才相关的领域知识，用 skills 按需加载，别塞进来。

关键是简洁。每写一行都问自己：「删掉这条会不会让 Claude 犯错？」不会就删。臃肿的 CLAUDE.md 反而会让 Claude 忽略你真正的指令，因为重要规则淹没在噪声里。该写的：猜不到的 Bash 命令、与默认不同的风格规则、测试方式、仓库规矩、项目特有的架构决策、环境怪癖、非显而易见的坑。该排除的：读代码就能知道的、语言通用约定、频繁变动的信息、长篇教程。可以用 IMPORTANT / YOU MUST 加强遵守，并把它 check 进 git 让团队共建。

其余扩展按需要上：配置权限（auto mode 让分类器把关、/permissions 加白名单、/sandbox 做系统级隔离）；让 Claude 用 gh、aws 这类 CLI（最省上下文的外部交互方式）；用 claude mcp add 接 Notion、Figma、数据库；用 hooks 保证「每次都必须发生」的动作（确定性，比 CLAUDE.md 的建议性更硬）；建 skills 给它领域知识和可复用流程；建自定义 subagent 处理读很多文件、不想污染主对话的隔离任务；用 /plugin 装插件打包以上能力。

“Bloated CLAUDE.md files cause Claude to ignore your actual instructions!”

六、高效沟通：像问资深工程师那样问

上新代码库时，把 Claude 当成可以请教的资深同事：日志怎么走？怎么加一个新 API 端点？foo.rs 第 134 行那句 async move 是什么意思？某个类处理了哪些边界情况？为什么这里调 foo() 而不是 bar()？不用特别的 prompt 技巧，直接问，这是很好的上手方式，还能减轻其他工程师的答疑负担。

做较大的功能时，反过来让 Claude 先「面试」你：从一句最小描述开始，要求它用 AskUserQuestion 工具就技术实现、UI/UX、边界、权衡逐项追问你没考虑到的硬骨头，问到都覆盖了再把完整规格写进 SPEC.md。然后开一个全新会话去执行，新会话上下文干净、只聚焦实现，而你手里有一份可参照的书面规格。最有用的规格是自包含的：点名涉及的文件和接口、写清什么不在范围内、并以一个端到端的验证步骤收尾。

“Ask Claude questions you’d ask a senior engineer.”

七、管理会话：对话是可持久、可回退的

尽早、频繁地纠偏。最好的结果来自紧凑的反馈回路：按 Esc 可中途叫停且保留上下文以便重定向；Esc + Esc 或 /rewind 打开回退菜单，恢复之前的对话与代码状态；说「Undo that」让它撤销改动；/clear 在不相关任务之间重置上下文。如果同一个问题你已经纠正超过两次，说明上下文被失败的尝试污染了，这时 /clear 重开、用一个更具体、吸收了教训的 prompt，几乎总是胜过一个堆满纠正的长会话。

主动管理上下文：任务之间多用 /clear；接近上限时 Claude 会自动压缩（保留代码、文件状态、关键决策）；想更可控就 /compact <指令>，比如只聚焦 API 改动；想压缩部分对话用 Esc + Esc 选检查点再「从这里总结 / 总结到这里」；还能在 CLAUDE.md 里定制压缩时务必保留哪些信息。临时小问题用 /btw，答案出现在可关闭的浮层里、不进对话历史。

把子代理用于调研：既然上下文是根本约束，子代理就是最强的工具之一，它在独立上下文里探索代码库、只回报摘要，不弄脏你的主对话；实现完也可以让子代理在新上下文里复查边界情况。还有检查点：每条 prompt 都会建检查点，Claude 改动前会自动快照文件，可只恢复对话、只恢复代码、或两者都恢复（但它只追踪 Claude 自己的改动，不能替代 git）。会话本地保存，claude --continue 接最近一次、claude --resume 从列表选，用 /rename 给会话起名、像分支一样各自带独立上下文。

“A clean session with a better prompt almost always outperforms a long session with accumulated corrections.”

八、自动化与规模化

Claude Code 可以横向扩展。非交互模式：claude -p "提示" 不开会话直接跑，用于 CI、pre-commit、各种自动化，输出可选纯文本、JSON 或流式 JSON 便于程序解析。并行多会话：worktree（隔离的 git 检出，编辑不打架）、桌面端可视化管理、web 端跑在云端隔离 VM、agent teams 自动协调多会话。多会话还能做「写手 / 审查者」模式：一个会话写实现，另一个用全新上下文审查，新上下文不会偏袒自己刚写的代码，复查更客观；测试也一样，一个写测试、另一个写代码去通过。

在文件间横向铺开：让 Claude 先列出所有要迁移的文件，再用脚本循环对每个文件跑 claude -p，并用 --allowedTools 限定权限；先在两三个文件上试、按出错情况打磨 prompt，再全量跑。用 auto mode 做无人值守执行，分类器在命令执行前把关，拦截越权、未知基础设施和被恶意内容驱动的动作；-p 模式下若反复被拦会直接中止（没有用户可回退）。最后加一道对抗式审查：完工前让一个子代理在全新上下文里只看 diff 和你给的标准去报缺口，做事的那个就不是打分的那个。要注意，被要求挑毛病的审查者通常总能挑出点什么，所以让它只标记影响正确性或既定需求的缺口，其余当可选项，别为了每条发现而过度工程。

“A reviewer prompted to find gaps will usually report some, even when the work is sound, because that is what it was asked to do.”

九、避开常见的翻车模式 + 养出你自己的直觉

原文最后点名五个常见错误：「大杂烩会话」（一个任务里穿插无关问题，上下文塞满无关信息，解法是 /clear）；「反复纠正」（越改越错，解法是两次失败后 /clear 重写 prompt）；「过度臃肿的 CLAUDE.md」（太长导致一半被忽略，解法是狠狠删，能用 hook 替代就替代）；「信任却没验证」（看起来合理但没处理边界，解法是永远提供验证，验证不了就别发）；「无尽探索」（不圈范围地让它调研，读几百个文件吃满上下文，解法是收窄范围或交给子代理）。

但这些模式都不是铁律，只是通常好用的起点。有时你「应该」让上下文累积，因为正深陷一个复杂问题、历史很有价值；有时该跳过规划让它自己琢磨，因为任务本就是探索性的；有时一个模糊 prompt 恰恰对，因为你想先看它怎么理解再去约束。留意什么有效：当 Claude 产出很棒时，记下你当时做了什么；当它卡住时，问问为什么。时间久了，你会养出任何指南都写不出来的直觉。