Claude Code 最佳实践：从环境配置到并行会话的高效使用指南

Claude Code 是一个具备代理（agentic）能力的编码环境。它不像传统聊天机器人那样回答完一个问题就停下来等待，而是可以读取文件、执行命令、修改代码，并在你旁观、引导甚至完全离开的情况下，自主推进任务。

这种工作方式带来了一种新的协作范式：不再是你写代码、Claude 来 review，而是你描述目标，Claude 自己去探索、规划、实现。但代理式自主背后仍然存在一些约束需要理解。

下面这份指南整理了 Anthropic 内部团队和大量工程师在不同代码库、不同语言、不同环境下总结出的有效模式。

上下文窗口是最稀缺的资源

几乎所有最佳实践都是为了应对同一个约束：Claude 的上下文窗口很容易被填满，而填得越满，性能越差。

上下文窗口装着整个对话——每一条消息、每一次文件读取、每一次命令输出。一次调试或一次代码库探索，就可能消耗掉数万 tokens。

LLM 的输出质量会随着上下文增长而下降。当窗口接近上限时，Claude 可能开始“遗忘”早期指令，或者做出更多错误判断。所以，上下文管理是首要任务。

给 Claude 一个验证自己工作的方式

提供测试、截图或预期输出，让 Claude 能自己检查结果。这是单点收益最高的一件事。

如果没有明确的成功标准，Claude 可能产出一段“看起来对”但实际上不工作的代码。这时唯一的反馈通道就是你本人，每一个错误都需要你介入。

验证手段可以是测试套件、Linter，或一段检查输出的 Bash 脚本。验证机制越扎实，Claude 越可靠。

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

把研究和规划与具体实现分开，避免解决错问题。

让 Claude 一上来就开始写代码，往往会得到一段“解决错误问题”的实现。推荐的工作流分四步：

1. 探索（Plan Mode）

进入 Plan Mode，Claude 只读文件、回答问题，不做修改。

读 /src/auth，理解我们怎么处理 session 和登录。
另外看一下我们怎么管理用于 secrets 的环境变量。

2. 规划

让 Claude 输出一份详细实施计划。

我想加 Google OAuth。需要改哪些文件？session 流程是什么？给一份计划。

按 Ctrl+G 可以在编辑器中直接修改计划。

3. 实现

切回 Normal Mode，让 Claude 按计划写代码。

按计划实现 OAuth 流程。给 callback handler 写测试，跑测试套件，修掉失败用例。

4. 提交

用一段描述性的 commit message 提交，并开一个 PR

Plan Mode 强大，但也有开销。修拼写、加日志、改个变量名这种范围明确、改动很小的任务，直接让 Claude 干就行。当方案不确定、改动跨多个文件、或代码不熟时，规划才最有价值。如果一句话能描述 diff，就别规划了。

在 prompt 中提供具体上下文

指令越精确，需要纠正的次数越少。

Claude 能推断意图，但读不了你的脑子。引用具体文件、提出约束、指向参考样例。

模糊 prompt 也不是不能用——当你想自由探索、并能容忍来回调整时，这个文件你会怎么改进？ 这类问题反而能挖出你没想到的视角。

提供丰富的上下文

• 用 @ 引用文件，Claude 会先读再答
• 直接粘贴图片：复制粘贴或拖拽
• 给 URL 让 Claude 拉取文档；用 /permissions 把常用域名加白
• 管道喂数据：cat error.log | claude
• 让 Claude 自取：通过 Bash、MCP 工具或文件读取自己拉上下文

配置你的工作环境

写一份高质量的 CLAUDE.md

用 /init 基于当前项目结构生成一份起步版 CLAUDE.md，再逐步打磨。

CLAUDE.md 在每次会话开始时都会被加载，里面适合放：Bash 命令、代码风格、工作流规则——这些是 Claude 仅凭代码本身推断不出来的东西。

# 代码风格
- 用 ES modules（import/export），不用 CommonJS（require）
- 尽量解构导入（如 import { foo } from 'bar'）

# 工作流
- 改完一组代码后务必跑 typecheck
- 优先跑单测，而不是整套测试套件，节省时间

CLAUDE.md 每次会话都加载，所以只放普适性内容。仅在特定场景下才需要的领域知识或工作流，放到 Skills 里按需加载更合适。

保持简洁。每写一行问自己：“删掉这行，Claude 会出错吗？” 答案是“不会”就删掉。冗长的 CLAUDE.md 反而会让 Claude 忽略真正重要的指令。

如果某条规则反复无效，多半是文件太长，规则被淹没。可以用 IMPORTANT 或 YOU MUST 加强语气。把 CLAUDE.md 当代码维护：定期 review，定期裁剪。

CLAUDE.md 支持用 @path/to/import 语法导入其他文件，并且可以放在多个位置：

• ~/.claude/CLAUDE.md：所有会话生效
• ./CLAUDE.md：项目根目录，提交到 git 与团队共享
• ./CLAUDE.local.md：个人覆盖，应加到 .gitignore
• 父目录 / 子目录：monorepo 场景下会按需被拉入

配置权限

默认情况下，Claude Code 在做可能修改系统的操作前会请求授权（写文件、Bash、MCP 工具等）。这很安全但很烦——点到第十次时你已经不是在审核，而是在闭眼点确认。三种降噪手段：

• Auto Mode：用一个独立的分类器模型审查命令，只拦截高风险动作（权限越界、未知基础设施、被恶意内容驱动的操作）
• 权限白名单：把已知安全的命令（如 npm run lint、git commit）加白
• Sandbox：操作系统级的隔离，限制文件系统和网络访问

用好 CLI 工具

让 Claude 通过 gh、aws、gcloud、sentry-cli 这类 CLI 工具与外部服务交互——这是上下文最省的方式。

如果你用 GitHub，装上 gh。Claude 知道怎么用它创建 issue、开 PR、读评论。没有 gh 时，未授权的 GitHub API 调用经常被限流。

Claude 也能现学现用没见过的 CLI：用 'foo-cli-tool --help' 学一下 foo，然后用它解决 A、B、C。

接入 MCP 服务器

通过 MCP 可以让 Claude 操作 Notion、Figma、数据库、监控数据等外部系统。

设置 Hooks

对于“必须每次发生、零例外”的动作，用 Hooks。

CLAUDE.md 的指令是“建议性”的，而 Hooks 是确定性的——它们一定会被执行。Claude 自己也能写 Hook：“写一个 hook，每次编辑文件后跑 eslint”、“写一个 hook，禁止写入 migrations 目录”。

创建 Skills

在 .claude/skills/ 下放 SKILL.md 文件，可以给 Claude 注入领域知识或可复用工作流。Claude 会在相关时自动应用，也可以用 /skill-name 主动触发。

---
name: api-conventions
description: REST API 设计规范
---
# API 规范
- URL 路径用 kebab-case
- JSON 字段用 camelCase
- 列表接口必须带分页
- 用路径做版本（/v1/、/v2/）

Skills 也可以定义可重复的工作流，并用 disable-model-invocation: true 标记“仅手动触发”。

自定义子代理

子代理在独立的上下文中运行，工具集独立，适合“需要读很多文件但不想污染主对话”的任务。

---
name: security-reviewer
description: 审查代码安全漏洞
tools: Read, Grep, Glob, Bash
model: opus
---
你是一名资深安全工程师，关注：
- 注入漏洞（SQL、XSS、命令注入）
- 认证与鉴权缺陷
- 代码中的 secrets / 凭据
- 不安全的数据处理

给出具体行号与建议修复。

主动调用：“用一个 subagent 审一下这段代码的安全问题。”

安装插件

/plugin 浏览市场。插件把 Skills、Hooks、子代理、MCP 服务器打包成一键安装的单元。

高效沟通

像问资深工程师一样问代码库

刚加入新代码库时，把 Claude 当成熟悉这套代码的同事来问：

• 日志是怎么处理的？
• 怎么加一个新的 API 端点？
• foo.rs:134 那个 async move { ... } 在做什么？
• CustomerOnboardingFlowImpl 处理了哪些边界情况？
• 为什么 line 333 调用 foo() 而不是 bar()？

这是非常有效的入职流程。

让 Claude 反过来面试你

对于较大的特性，先让 Claude 用 AskUserQuestion 工具把你“面试”一遍。

我想做 [简短描述]。用 AskUserQuestion 工具详细面试我。

聚焦技术实现、UI/UX、边界情况、隐患和取舍。别问明显的问题，
挖那些我可能没考虑到的难点。

聊清楚后，把完整 spec 写入 SPEC.md。

spec 写完后，新开会话，用干净的上下文专注实现。

管理你的会话

会话是持久化的，且可回退——这是优势。

尽早、频繁地纠偏

• Esc：打断 Claude，但保留上下文
• Esc + Esc 或 /rewind：打开 rewind 菜单，回滚对话和代码状态
• “撤销刚才的改动”：让 Claude 还原修改
• /clear：在不相关任务之间彻底重置上下文

如果同一个问题已经纠正两次以上，就 /clear 重开吧。 上下文里堆满了失败尝试，一个干净的会话加一个更精准的 prompt，几乎总是优于不断打补丁的长会话。

主动管理上下文

• 不相关任务之间用 /clear
• 接近上限时 Claude 会自动 compact，保留代码、状态和关键决策
• 也可以手动 /compact <说明>，例如 /compact 重点保留 API 改动
• 用 Esc + Esc 选一个消息节点，从那里开始 summarize，前面上下文保留
• 在 CLAUDE.md 里写 “compact 时务必保留所有被修改的文件列表和测试命令”，让关键信息不丢
• 临时小问题用 /btw，回答展示在悬浮层里，不进入对话历史

用子代理做调研

让子代理用独立的上下文窗口去探索、读文件、汇总结论，主对话保持清爽。

用 subagent 调研我们的认证系统是怎么处理 token 刷新的，
以及是否已经有可复用的 OAuth 工具。

子代理也适合做实现后的复核：“用 subagent review 这段代码的边界情况。”

用 Checkpoint 回滚

Claude 在每次改动前都会自动 checkpoint。双击 Esc 或 /rewind 可以恢复对话、代码或两者，也可以从某个消息开始 summarize。

注意：Checkpoint 只跟踪 Claude 的改动，不替代 git。

恢复历史会话

claude --continue   # 继续最近的会话
claude --resume     # 从最近的会话中选一个

用 /rename 给会话起描述性名字，例如 oauth-migration、debugging-memory-leak。把会话当作分支：不同工作流，独立持久化的上下文。

自动化与扩展

非交互模式

# 一次性查询
claude -p "解释这个项目是做什么的"

# 给脚本用的结构化输出
claude -p "列出所有 API 端点" --output-format json

# 流式输出，实时处理
claude -p "分析这份日志" --output-format stream-json

非交互模式适合 CI 流水线、pre-commit hook、各类自动化脚本。

并行运行多个 Claude 会话

三种主要方式：

• 桌面应用：本地多会话，每个会话独立的 worktree
• 网页版：在 Anthropic 安全云上的隔离 VM 中运行
• Agent Teams：多个会话自动协作，共享任务、消息和一个 Team Lead

并行会话还能改善质量。例如 Writer / Reviewer 模式：

也可以让一个 Claude 写测试，另一个 Claude 写实现去通过这些测试。

跨文件批量分发

对于大规模迁移或分析，可以把任务分发到多个并行的 claude -p 调用：

for file in $(cat files.txt); do
  claude -p "把 $file 从 React 迁移到 Vue。返回 OK 或 FAIL。" \
    --allowedTools "Edit,Bash(git commit *)"
done

先在 2~3 个文件上调好 prompt，再放到完整列表上跑。--allowedTools 在无人值守时尤其重要。

也可以接进数据/处理管道：

claude -p "<your prompt>" --output-format json | your_command

用 Auto Mode 自主跑

claude --permission-mode auto -p "修复所有 lint 错误"

后台分类器会拦截风险动作（权限越界、未知基础设施、被敌意内容驱动），其他工作不再打断。在 -p 的非交互场景下，如果分类器多次拦截，会话会终止，因为没人可以兜底。

几个常见的失败模式

• 大杂烩会话：一个会话里夹杂多个不相关任务，上下文被无关信息塞满

  修法：不相关任务之间 /clear

• 反复纠错：连续两次纠正同一个问题仍不对，上下文已被失败尝试污染

  修法：两次失败后 /clear，结合学到的东西重写一份更精准的 prompt

• 过度膨胀的 CLAUDE.md：规则太多，重要的被噪声淹没，Claude 直接忽略

  修法：狠心精简；Claude 不靠这条规则也能做对，就删掉，或转成 Hook

• 信任但未验证：实现看起来很合理，但边界情况没处理

  修法：永远提供验证手段（测试、脚本、截图）。验证不了就别上线。

• 无限探索：让 Claude 没有边界地“调研一下”，结果它读了上百个文件，把上下文吃光

  修法：把调研范围限定清楚，或者用子代理在独立上下文中跑

培养自己的直觉

这份指南里的模式不是金科玉律。它们是泛用的起点，但不一定是每种情形下的最优解。

有时候你应该让上下文累积——你深陷一个复杂问题，历史本身就有价值；有时候应该跳过规划，让 Claude 自己摸索，因为任务本就是探索性的；有时候模糊 prompt 才是对的——你想看 Claude 怎么理解问题，再决定如何约束。

留意什么有效。Claude 输出很好的时候，回想一下当时的 prompt 结构、提供的上下文、所处的模式；它表现不佳时，问问自己：上下文是不是太杂？prompt 是不是太空？任务是不是一次性塞太多？

时间一长，你会形成任何指南都写不出来的直觉——什么时候该精确什么时候该开放、什么时候该规划什么时候该探索、什么时候该清空上下文什么时候该让它累积。

关注我获取更多资讯

📢 公众号

💬 个人号

原文

本文整理与翻译自 Anthropic 官方文档：Best Practices for Claude Code。