Claude Code 中文文档

Claude Code 最佳实践

充分利用 Claude Code 的技巧与模式,涵盖从配置环境到跨并行会话扩展的方方面面。

Claude Code 是一个智能体编程环境。与那种仅回答问题并等待的聊天机器人不同,Claude Code 可以读取你的文件、执行命令、做出修改,并在你观察、干预或完全走开时自主地解决问题。

这会改变你的工作方式。你不再是自己编写代码然后让 Claude 审查,而是描述你想要什么,由 Claude 来想办法构建。Claude 会探索、规划并实现。

但这样的自主性仍然需要一定的学习过程。Claude 在某些约束条件下工作,你需要理解这些约束。

本指南涵盖的模式已经在 Anthropic 内部团队以及在不同代码库、语言和环境中使用 Claude Code 的工程师中证明了有效性。关于智能体循环的底层工作原理,请参阅 Claude Code 如何工作


大多数最佳实践都基于一个约束条件:Claude 的上下文窗口填充得很快,并且随着填充,性能会下降。

Claude 的上下文窗口保存了你的整个对话,包括每条消息、Claude 读取的每个文件以及每个命令的输出。然而,它可能很快就会被填满。一次调试会话或代码库探索可能就会产生并消耗数万个 token。

这一点很重要,因为随着上下文的填充,LLM 的性能会下降。当上下文窗口即将满载时,Claude 可能会开始“遗忘”之前的指令,或犯更多错误。上下文窗口是需要管理的最重要资源。要了解会话在实践中是如何填满的,请观看交互式演示,了解启动时加载什么以及每次文件读取的成本。使用自定义状态行持续跟踪上下文用量,并参阅减少 token 用量以了解减少 token 用量的策略。


让 Claude 有能力验证其工作

💡

给 Claude 一个它能运行的检查项:测试、构建、可对比的截图。它决定了你是得全程盯着还是可以放心走开。

Claude 在工作看起来完成时就会停止。如果没有可运行的检查项,“看起来完成”就成了唯一的信号,而你就会变成验证循环:每一个错误都得等你来发现。给 Claude 一个能产生通过或失败信号的东西,这个循环就会自动闭合。Claude 执行工作,运行检查,读取结果,然后不断迭代,直到检查通过。

检查项可以是任何能在对话中返回 Claude 可读信号的东西:测试套件、构建的退出码、代码检查工具、将输出与预期结果进行 diff 的脚本,或者与设计稿对比的浏览器截图

策略 优化前 优化后
提供验证条件 “实现一个验证邮箱地址的函数” “编写一个 validateEmail 函数。示例测试用例:user@example.com 为 true,invalid 为 false,user@.com 为 false。实现后运行测试”
可视化验证 UI 变更 “让仪表盘看起来更好” “[粘贴截图] 实现这个设计。截取结果截图并与原设计对比。列出差异并修复”
处理根本原因,而非表象 “构建失败了” “构建失败并报如下错误:[粘贴错误信息]。修复它,并验证构建成功。解决根本原因,不要压制错误”

一旦检查项就位,再决定它对停止的限制程度:

  • 在一次提示内:要求 Claude 在同一条消息中运行检查并不断迭代,如上表示例所示。
  • 跨整个会话:将检查设置为 /goal 条件。一个独立的评估器会在每一轮之后重新检查,Claude 会持续工作直到条件满足。
  • 作为确定性闸门Stop 钩子 会以脚本方式运行你的检查,并在检查通过之前阻止回合结束。Claude Code 会覆盖该钩子,并在连续 8 次被阻止后结束回合。
  • 借助第二个视角验证子代理 或会检查自身发现的动态工作流 会用一个全新的模型尝试反驳结果,这样执行工作的代理就不会是给自己打分的那个人。

每一步都以设置换取专注。提示词版本今天就能在任何任务上直接使用。/goal 和 Stop 钩子版本则能让无人值守的运行在没有你的情况下也能正确完成。

让 Claude 展示证据,而不是直接宣称成功:测试输出、它运行的命令及其返回值,或结果截图。审查证据比你亲自重新运行验证更快,并且对那些你没有一直盯着的会话也同样有效。


先探索,再规划,后编码

💡

将研究和规划与实现分离,以避免解决错误的问题。

让 Claude 直接跳到编码可能会产生解决错误问题的代码。使用 计划模式 将探索与执行分离。

推荐的工作流程有四个阶段:

  1. 探索

    进入计划模式。Claude 读取文件并回答问题,而不进行更改。

    阅读 /src/auth 并理解我们如何处理会话和登录。
    同时查看我们如何管理用于机密的环境变量。
    read /src/auth and understand how we handle sessions and login.
    also look at how we manage environment variables for secrets.
  2. 规划

    让 Claude 创建一个详细的实现计划。

    我想添加 Google OAuth。需要更改哪些文件?
    会话流程是怎样的?制定一个计划。
    I want to add Google OAuth. What files need to change?
    What's the session flow? Create a plan.

    Ctrl+G 在文本编辑器中打开计划,以便在 Claude 继续之前直接编辑。

  3. 实现

    退出计划模式,让 Claude 编写代码,根据其计划进行验证。

    根据你的计划实现 OAuth 流程。为回调处理器编写测试,
    运行测试套件并修复任何失败。
    implement the OAuth flow from your plan. write tests for the
    callback handler, run the test suite and fix any failures.
  4. 提交

    让 Claude 提交,附带描述性信息并创建 PR。

    使用描述性提交信息提交并创建 PR
    commit with a descriptive message and open a PR
📌

计划模式很有用,但也会增加开销。

对于范围明确且修复很小(如修正拼写错误、添加日志行或重命名变量)的任务,请让 Claude 直接完成。

当您不确定方法、更改涉及多个文件或您不熟悉正在修改的代码时,规划最有用。如果您能用一句话描述 diff,请跳过计划。


在提示中提供具体上下文

💡

你的指令越精确,你需要修正的次数就越少。

Claude 可以推断意图,但无法读懂你的思想。引用具体的文件,提及约束条件,并指向示例模式。

策略 之前 之后
限定任务范围。 指定哪个文件、什么场景以及测试偏好。 "为 foo.py 添加测试" "为 foo.py 编写一个测试,覆盖用户登出时的边缘情况。避免使用 mock。"
指明信息来源。 让 Claude 去查看能回答问题的来源。 "为什么 ExecutionFactory 的 API 这么奇怪?" "浏览 ExecutionFactory 的 git 历史,总结其 API 是如何演变的"
引用现有模式。 让 Claude 参考代码库中的模式。 "添加一个日历小部件" "查看主页上现有小部件的实现方式以理解模式。HotDogWidget.php 是一个很好的示例。按照该模式实现一个新的日历小部件,允许用户选择月份并通过向前/向后翻页来挑选年份。仅使用代码库中已有的库,从零构建。"
描述症状。 提供症状、可能的位置以及“修复”后的样子。 "修复登录 bug" "用户报告会话超时后登录失败。检查 src/auth/ 中的认证流程,尤其是 token 刷新。编写一个能重现该问题的失败测试,然后修复它"

在你探索且可以承受方向纠正时,模糊的提示可能很有用。像 "what would you improve in this file?" 这样的提示可能会揭示出你没想到要问的事情。

提供丰富的内容

💡

使用 @ 引用文件、粘贴截图/图片,或直接通过管道传入数据。

你可以通过以下几种方式向 Claude 提供丰富的数据:

  • 使用 @ 引用文件,而非描述代码所在位置。Claude 会在回复前读取文件。
  • 直接粘贴图片。将图片复制/粘贴或拖放到提示框中。
  • 提供文档和 API 参考链接的 URL。使用 /permissions 将常用域名添加到允许列表。
  • 通过管道传入数据,运行 cat error.log | claude 直接将文件内容发送给 Claude。
  • 让 Claude 自行获取所需内容。告诉 Claude 通过 Bash 命令、MCP 工具或读取文件来自行拉取上下文。

配置你的环境

几个设置步骤能让 Claude Code 在你的所有会话中发挥显著更大的效能。有关扩展功能的完整概述以及何时使用每一种功能,请参阅 扩展 Claude Code

编写有效的 CLAUDE.md

💡

运行 /init 命令,根据当前项目结构生成一份初始的 CLAUDE.md 文件,然后随着时间推移不断完善。

CLAUDE.md 是 Claude 在每次对话开始时都会读取的特殊文件。你可以在其中包含 Bash 命令、代码风格以及工作流规则,这能为 Claude 提供那些仅凭代码无法推断出来的持久化上下文。

/init 命令会分析你的代码库,检测构建系统、测试框架和代码模式,为你提供一个坚实的基础以便进一步完善。

CLAUDE.md 文件没有强制的格式要求,但应保持简短且便于人类阅读。例如:

# 代码风格
- 使用 ES modules (import/export) 语法,而非 CommonJS (require)
- 尽可能解构导入(例如 import { foo } from 'bar')

# 工作流
- 完成一系列代码更改后,务必进行类型检查
- 出于性能考虑,最好运行单个测试,而不是整个测试套件
# Code style
- Use ES modules (import/export) syntax, not CommonJS (require)
- Destructure imports when possible (eg. import { foo } from 'bar')

# Workflow
- Be sure to typecheck when you're done making a series of code changes
- Prefer running single tests, and not the whole test suite, for performance

CLAUDE.md 在每次会话中都会被加载,因此只应包含广泛适用的内容。对于仅在特定情况下相关的领域知识或工作流,请改用 技能。Claude 会按需加载它们,而不会让每次对话都变得臃肿。

保持简洁。对每一行内容,都问一问自己:“如果删掉这一条,会不会导致 Claude 出错?” 如果不会,就删掉它。臃肿的 CLAUDE.md 文件会让 Claude 忽略你真正的指令!

✅ 应包含的内容 ❌ 应排除的内容
Claude 无法猜到的 Bash 命令 Claude 通过阅读代码就能明白的任何内容
与默认配置不同的代码风格规则 Claude 已经知道的标准语言规范
测试说明和首选的测试运行器 详细的 API 文档(应改为提供文档链接)
仓库规范(分支命名,PR 约定) 频繁变动的信息
项目特有的架构决策 长篇解释或教程
开发环境的特殊要求(必需的环境变量) 对代码库逐文件的描述
常见的陷阱或不太明显的行为 不言自明的做法,如“编写整洁的代码”

如果 Claude 在已有规则禁止的情况下仍然反复做你不想让它做的事,那很可能是因为文件太长,导致那条规则被淹没了。如果 Claude 问你的问题在 CLAUDE.md 中已有答案,那可能是措辞有歧义。请把 CLAUDE.md 当作代码来对待:在出问题时审阅它,定期精简,并通过观察 Claude 的行为是否真的发生改变来测试你的修改。

你可以通过添加强调(例如,“重要”或“你必须”)来调整指令,以提高遵从性。将 CLAUDE.md 签入 git,方便你的团队共同完善。这个文件的价值会随着时间不断累积。

CLAUDE.md 文件可以使用 @path/to/import 语法来导入其他文件:

请参阅 @README.md 了解项目概述,参阅 @package.json 了解可用的 npm 命令。

# 额外说明
- Git 工作流:@docs/git-instructions.md
- 个人覆盖:@~/.claude/my-project-instructions.md
See @README.md for project overview and @package.json for available npm commands.

# Additional Instructions
- Git workflow: @docs/git-instructions.md
- Personal overrides: @~/.claude/my-project-instructions.md

你可以将 CLAUDE.md 文件放置在以下几个位置:

  • 主文件夹 (~/.claude/CLAUDE.md):适用于所有 Claude 会话
  • 项目根目录 (./CLAUDE.md):签入 git 以与团队共享
  • 项目根目录 (./CLAUDE.local.md):个人针对项目的笔记;请将此文件添加到你的 .gitignore 中,这样就不会与团队共享
  • 父目录:在单体仓库(monorepos)中非常有用,root/CLAUDE.mdroot/foo/CLAUDE.md 都会被自动引入
  • 子目录:当 Claude 读取这些目录中的文件时,会按需引入子目录下的 CLAUDE.md 文件

配置权限

💡

使用自动模式让分类器处理审批,使用 /permissions 将特定命令加入许可名单,或使用 /sandbox 进行操作系统级隔离。每种方式都能减少中断,同时让你保持控制。

默认情况下,Claude Code 会对可能修改系统的操作请求权限:文件写入、Bash 命令、MCP 工具等。这很安全,但很繁琐。经过十次审批后,你就不再真正审查了,只是在机械点击。有三种方法可以减少这些中断:

  • 自动模式:单独的 classifier 模型会审查命令,只拦截看起来有风险的操作:权限提升、未知基础设施,或由恶意内容驱动的操作。当你信任任务的大方向,但不想每一步都点击确认时,这是最佳选择
  • 权限许可名单:允许你知道安全的特定工具,如 npm run lintgit commit
  • 沙箱机制:启用操作系统级隔离,限制文件系统和网络访问,让 Claude 在已定义的边界内更自由地工作

阅读更多关于权限模式权限规则沙箱机制的内容。

使用 CLI 工具

💡

让 Claude Code 在与外部服务交互时使用 CLI 工具,如 ghawsgcloudsentry-cli

CLI 工具是与外部服务交互时上下文效率最高的方式。如果你使用 GitHub,请安装 gh CLI。Claude 知道如何使用它来创建 issue、打开 pull request 和阅读评论。没有 gh,Claude 仍然可以使用 GitHub API,但未经身份验证的请求经常会触发速率限制。

Claude 也很擅长学习它未知的 CLI 工具。尝试这样的提示:使用 'foo-cli-tool --help' 了解 foo 工具,然后用它来解决 A、B、C。

连接 MCP 服务器

💡

运行 claude mcp add 连接外部工具,如 Notion、Figma 或你的数据库。

借助 MCP 服务器,你可以让 Claude 从问题追踪器实现功能、查询数据库、分析监控数据、集成 Figma 中的设计,并自动化工作流。

设置钩子

💡

对于每次都必须发生、零例外的情况,使用钩子。

钩子会在 Claude 工作流的特定节点自动运行脚本。与建议性的 CLAUDE.md 指令不同,钩子是确定性的,并保证相应操作一定会发生。

Claude 可以为你编写钩子。尝试这样的提示:"写一个在每次文件编辑后运行 eslint 的钩子""写一个阻止对 migrations 文件夹写入的钩子。" 直接编辑 .claude/settings.json 手动配置钩子,并运行 /hooks 浏览已配置的内容。

创建技能

💡

.claude/skills/ 中创建 SKILL.md 文件,为 Claude 提供领域知识和可复用工作流。

技能用你的项目、团队或领域的特定信息扩展 Claude 的知识。Claude 会在相关时自动应用它们,或者你可以用 /skill-name 直接调用。

通过在 .claude/skills/ 中添加包含 SKILL.md 的目录来创建技能:

---
name: api-conventions
description: 我们服务的 REST API 设计规范
---
# API 规范
- URL 路径使用 kebab-case
- JSON 属性使用 camelCase
- 列表端点务必包含分页
- 在 URL 路径中进行 API 版本管理(/v1/、/v2/)
---
name: api-conventions
description: REST API design conventions for our services
---
# API Conventions
- Use kebab-case for URL paths
- Use camelCase for JSON properties
- Always include pagination for list endpoints
- Version APIs in the URL path (/v1/, /v2/)

技能还可以定义你直接调用的可重复工作流:

---
name: fix-issue
description: 修复 GitHub issue
disable-model-invocation: true
---
分析并修复 GitHub issue:$ARGUMENTS。

1. 使用 `gh issue view` 获取 issue 详情
2. 理解 issue 中描述的问题
3. 在代码库中搜索相关文件
4. 实施必要更改以修复问题
5. 编写并运行测试以验证修复
6. 确保代码通过 linting 和类型检查
7. 创建描述性提交信息
8. 推送并创建 PR
---
name: fix-issue
description: Fix a GitHub issue
disable-model-invocation: true
---
Analyze and fix the GitHub issue: $ARGUMENTS.

1. Use `gh issue view` to get the issue details
2. Understand the problem described in the issue
3. Search the codebase for relevant files
4. Implement the necessary changes to fix the issue
5. Write and run tests to verify the fix
6. Ensure code passes linting and type checking
7. Create a descriptive commit message
8. Push and create a PR

运行 /fix-issue 1234 来调用它。对带有副作用、你希望手动触发的工作流,使用 disable-model-invocation: true

创建自定义子代理

💡

.claude/agents/ 中定义专门助手,Claude 可将其委派给这些助手来执行隔离任务。

子代理 在自己的上下文中运行,拥有一组允许的工具。它们适用于需要读取大量文件或需要专注而不会弄乱主对话的任务。

---
name: security-reviewer
description: 审查代码中的安全漏洞
tools: Read, Grep, Glob, Bash
model: opus
---
你是一名资深安全工程师。审查代码是否存在以下问题:
- 注入漏洞(SQL、XSS、命令注入)
- 身份认证和授权缺陷
- 代码中的机密或凭据
- 不安全的数据处理

提供具体的行引用和修复建议。
---
name: security-reviewer
description: Reviews code for security vulnerabilities
tools: Read, Grep, Glob, Bash
model: opus
---
You are a senior security engineer. Review code for:
- Injection vulnerabilities (SQL, XSS, command injection)
- Authentication and authorization flaws
- Secrets or credentials in code
- Insecure data handling

Provide specific line references and suggested fixes.

明确告诉 Claude 使用子代理:“使用子代理来审查此代码的安全性问题。”

安装插件

💡

运行 /plugin 浏览市场。插件无需配置即可添加技能、工具和集成。

插件 将技能、钩子、子代理和 MCP 服务器打包成来自社区和 Anthropic 的单个可安装单元。如果你使用静态类型语言,安装 代码智能插件,以便 Claude 在编辑后提供精确的符号导航和自动错误检测。

有关在技能、子代理、钩子和 MCP 之间进行选择的指导,请参阅 扩展 Claude Code


有效沟通

与 Claude Code 的沟通方式会显著影响结果的质量。

询问代码库问题

💡

向 Claude 提出你会问高级工程师的问题。

刚接触新代码库时,使用 Claude Code 进行学习和探索。你可以向 Claude 提出你可能会问其他工程师的同类问题:

  • 日志记录是如何工作的?
  • 如何创建新的 API 端点?
  • foo.rs 第 134 行的 async move { ... } 是做什么的?
  • CustomerOnboardingFlowImpl 处理哪些边缘情况?
  • 为什么这段代码在第 333 行调用 foo() 而不是 bar()

以这种方式使用 Claude Code 是一种高效的入职工作流程,可加快上手时间并减轻其他工程师的负担。无需特殊提示:直接提问即可。

让 Claude 面试你

💡

对于较大的功能,先让 Claude 来面试你。从一个极简的提示开始,让 Claude 使用 AskUserQuestion 工具来面试你。

Claude 会询问你可能还未考虑到的事情,包括技术实现、UI/UX、边缘情况和权衡。

我想构建 [简要描述]。使用 AskUserQuestion 工具对我进行详细访谈。

询问技术实现、UI/UX、边缘情况、担忧和权衡。不要问显而易见的问题,深入探讨我可能未曾考虑到的难点。

持续访谈,直至覆盖所有方面,然后将完整规范写入 SPEC.md。
I want to build [brief description]. 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.

一旦规范完成,启动一个全新的会话来执行它。新会话有干净的上下文,完全专注于实现,你还有书面规范可供参考。

最有用的规范是自包含的:列出涉及的文件和接口,说明什么不在范围内,并以一个端到端的验证步骤来证明功能有效。花时间让规范精确,比花时间盯着实现更划算。


管理你的会话

对话是持久且可逆的。好好利用这一点!

及早且频繁地纠正方向

💡

一旦发现 Claude 偏离正轨,立即纠正。

最佳结果来自紧密的反馈循环。虽然 Claude 偶尔能在第一次尝试时就完美解决问题,但快速纠正通常能更快地得到更好的解决方案。

  • Esc:按 Esc 键在操作中途停止 Claude。上下文会保留,你可以重新指示方向。
  • Esc + Esc/rewind:按两次 Esc 或运行 /rewind 打开回退菜单,恢复先前的对话和代码状态,或从选定消息进行摘要。
  • "撤销那个":让 Claude 还原其修改。
  • /clear:在不相关的任务之间重置上下文。包含无关上下文的长会话可能降低性能。

如果你在同一个会话中就同一个问题纠正 Claude 超过两次,上下文会被失败的尝试塞满。运行 /clear 并从头开始,结合你学到的经验给出更具体的提示。一个干净的会话加上更好的提示,几乎总是胜过累积了大量纠正的长会话。

积极管理上下文

💡

在不相关的任务之间运行 /clear 来重置上下文。

当接近上下文限制时,Claude Code 会自动压缩对话历史,保留重要的代码和决策,同时释放空间。

在长会话中,Claude 的上下文窗口可能被无关对话、文件内容和命令填满。这会降低性能,有时还会分散 Claude 的注意力。

  • 在任务之间频繁使用 /clear 完全重置上下文窗口
  • 当自动压缩触发时,Claude 会总结最重要的内容,包括代码模式、文件状态和关键决策
  • 如需更多控制,运行 /compact <指令>,例如 /compact 重点关注 API 变更
  • 如果只想压缩对话的一部分,使用 Esc + Esc/rewind,选择一个消息检查点,然后选择从这里开始摘要摘要到这里。前者会压缩从该点往后的消息,同时保留较早的上下文;后者会压缩较早的消息,同时保留最近的完整信息。参见恢复与摘要
  • 在 CLAUDE.md 中自定义压缩行为,加入类似 "压缩时,始终保留完整的修改文件列表和所有测试命令" 的指令,以确保关键上下文在摘要后得以保留
  • 对于不需要留在上下文中的快速问题,使用 /btw。答案会显示在一个可关闭的浮层中,永远不会进入对话历史,这样你就能在不增加上下文的情况下查询细节。

使用子代理进行调查

💡

"使用子代理调查 X" 委托研究任务。它们会在独立上下文中探索,保持你的主对话干净,专注于实施。

既然上下文是你的根本约束,子代理就成了最强大的工具之一。当 Claude 研究一个代码库时,它会读取大量文件,这些都会消耗你的上下文。子代理在独立的上下文窗口中运行,并返回摘要报告:

使用子代理调查我们的身份验证系统如何处理令牌
刷新,以及我们是否有任何现有的 OAuth 工具可以复用。
Use subagents to investigate how our authentication system handles token
refresh, and whether we have any existing OAuth utilities I should reuse.

子代理探索代码库,读取相关文件,然后带回发现结果,所有这些都不会污染你的主对话。

你也可以在 Claude 实现某些功能后,使用子代理进行验证:

使用子代理审查此代码的边缘情况
use a subagent to review this code for edge cases

使用检查点回退

💡

你发送的每一条提示都会创建一个检查点。你可以将会话、代码或两者恢复到任意之前的检查点。

Claude 会在每次修改前自动为文件建立快照,以便检查点恢复它们。双击 Escape 或运行 /rewind 即可打开回退菜单。你可以仅恢复对话、仅恢复代码、同时恢复两者,或从选定的消息开始总结。详见检查点功能

你不必精心规划每一步,也可以让 Claude 去冒险尝试。如果不成功,就回退并换个思路再试。检查点与会话一同保存,因此你可以关闭终端、稍后恢复会话,仍然可以回退。

⚠️

检查点仅追踪通过 Claude 文件编辑工具所做的更改。通过 Bash 命令或外部进程所做的更改无法被捕获。这不能替代 git。

恢复会话

💡

使用 /rename 为会话命名,并将其视为分支:每个工作流拥有独立的持久上下文。

Claude Code 在本地保存会话,因此当一项任务跨越多次操作时,你无需重新解释上下文。运行 claude --continue 继续最近的会话,或运行 claude --resume 从列表中选择。为会话起一个描述性名称,如 oauth-migration,方便日后查找。完整的恢复、分支和命名控制请参见管理会话


自动化与规模扩展

在能够高效使用单个 Claude 之后,你可以通过并行会话、非交互模式和扇出模式来倍增产出。

前面所有内容都基于一个人、一个 Claude 和一次对话的假设。但 Claude Code 支持水平扩展。本节介绍的技术将展示如何实现更高产出。

运行非交互模式

💡

在 CI、pre-commit 钩子或脚本中使用 claude -p "prompt"。添加 --output-format stream-json --verbose 以获取流式 JSON 输出。

通过 claude -p "your prompt",你可以以非交互方式运行 Claude,而不需要交互式提示。除非传入 --no-session-persistence,该次运行仍会创建一个可恢复的会话。非交互模式 是将 Claude 集成到 CI 管道、pre-commit 钩子或任何自动化工作流中的方式。输出格式可让你以编程方式解析结果:纯文本、JSON 或流式 JSON。

# One-off queries
claude -p "Explain what this project does"

# Structured output for scripts
claude -p "List all API endpoints" --output-format json

# Streaming for real-time processing
claude -p "Analyze this log file" --output-format stream-json --verbose

并行运行多个 Claude 会话

💡

并行运行多个 Claude 会话以加速开发、运行隔离实验或启动复杂工作流。

选择适合你希望自行协调程度的并行方式:

  • Worktrees: 在独立的 git 检出版本中运行单独的 CLI 会话,避免编辑冲突
  • 桌面应用: 可视化地管理多个本地会话,每个会话使用自己的 worktree
  • 网页版 Claude Code: 在 Anthropic 托管的云基础设施上的隔离虚拟机中运行会话
  • Agent 团队: 通过共享任务、消息传递和一名团队负责人,自动协调多个会话

除了并行化工作外,多个会话还能实现以质量为导向的工作流。全新的上下文有助于代码审查,因为 Claude 不会对自己刚编写的代码产生偏见。

例如,使用编写者/审查者模式:

会话 A(编写者) 会话 B(审查者)
为我们的 API 端点实现一个速率限制器
查看 @src/middleware/rateLimiter.ts 中的速率限制器实现,检查边缘情况、竞态条件,以及与现有中间件模式的一致性。
这是审查反馈:[会话 B 的输出]。处理这些问题。

你可以对测试采取类似的做法:让一个 Claude 编写测试,再让另一个编写代码通过测试。

跨文件分发

💡

对每个任务循环调用 claude -p。使用 --allowedTools 标志来限定批量操作的权限范围。

对于大规模迁移或分析,你可以将工作分发到多个并行的 Claude 调用中:

  1. 生成任务列表

    让 Claude 列出所有需要迁移的文件(例如 列出所有 2,000 个需要迁移的 Python 文件

  2. 编写脚本遍历列表
    for file in $(cat files.txt); do
      claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
        --allowedTools "Edit,Bash(git commit *)"
    done
  3. 先对少量文件测试,然后大规模运行

    根据前 2-3 个文件出现的问题来优化你的提示词,然后在整个文件集上运行。--allowedTools 标志限制了 Claude 可执行的操作,这在你无人值守运行时很重要。

你还可以将 Claude 集成到现有的数据/处理流水线中:

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

在开发期间使用 --verbose 进行调试,并在生产环境中关闭它。

使用 auto 模式自主运行

如需在后台安全检查下不间断执行,请使用 auto 模式。一个分类器模型会在命令运行前对其进行审查,阻止权限范围升级、未知基础设施以及恶意内容驱动的操作,同时让常规工作无需提示即可继续。

claude --permission-mode auto -p "fix all lint errors"

在使用 -p 标志进行非交互式运行时,如果分类器反复阻止操作,auto 模式会中止,因为没有用户可以回退。阈值参见 auto 模式何时回退

添加对抗性审查步骤

💡

在将任务视为完成之前,让一个 subagent 在全新上下文中审查 diff 并报告差距。

Claude 无人值守工作的时间越长,在将工作视为完成之前进行独立检查就越重要。审查者在全新的 subagent 上下文中运行,只会看到 diff 和你给出的标准,而不会看到产生该变更的推理过程,因此它会根据自身条件评估结果。

如需进行正确性检查,可以运行内置的 /code-review 技能,它会在一个全新的 subagent 中审查当前 diff 中的 bug,并将发现汇报给当前会话。如果要对照你的计划来检查 diff,请自行编写审查提示。指出要检查的工作、对照的计划,以及什么算作发现:

使用子代理对照 PLAN.md 审查限流器的差异。检查

every requirement is implemented, the listed edge cases have tests, and nothing outside the task's scope changed. Report gaps, not style preferences.
Use a subagent to review the rate limiter diff against PLAN.md. Check that
every requirement is implemented, the listed edge cases have tests, and
nothing outside the task's scope changed. Report gaps, not style preferences.

由于审查者以 subagent 方式运行,执行会话会直接收到差距报告,并可以修复它们并重新审查,无需你在不同窗口之间复制发现结果。对于更长时间的自主运行,一个 agent 团队 可以在多个任务之间维持这个循环,而你只需抽查记录下来的发现。

📌

要求审查者找差距的提示通常会导致它报告一些发现——即使工作本身是没问题的,因为它被要求这样做。追逐每一个发现会导致过度工程化:额外的抽象层、防御性代码,以及针对不可能发生情况的测试。告诉审查者只标记那些会影响正确性或已明确要求的差距,其余的视为可选项。


避免常见的失败模式

这些是常见的错误,尽早识别能节省时间:

  • “大杂烩”会话。 你从一个任务开始,然后向 Claude 询问一个不相关的事情,然后又回到第一个任务。上下文中充满了无关信息。

    解决方法:在无关任务之间使用 /clear

  • 反复纠正。 Claude 做错了,你纠正它,它仍然错,你再纠正。上下文被失败的方法污染了。

    解决方法:经过两次失败的纠正后,使用 /clear 并根据你学到的内容编写一个更好的初始提示。

  • 过度详细的 CLAUDE.md。 如果你的 CLAUDE.md 太长,Claude 会忽略其中一半的内容,因为重要规则在杂音中丢失了。

    解决方法:无情地修剪。如果 Claude 在没有该指令的情况下已经能正确完成某事,就删除它或将其转换为 hook。

  • 信任与验证的差距。 Claude 产生了一个看似合理的实现,却没有处理边界情况。

    解决方法:始终提供验证(测试、脚本、截图)。如果你无法验证它,就不要发布它。

  • 无穷探索。 你要求 Claude 去“调查”某件事,但没有限定范围。Claude 读取数百个文件,填满了上下文。

    解决方法:狭窄地限定调查范围,或使用 subagents,以便探索不会消耗你的主上下文。


培养你的直觉

本指南中的模式并非一成不变。它们是通常效果不错的起点,但可能并非对所有情况都最优。

有时你应该让上下文积累,因为你正深入一个复杂的问题,历史记录很有价值。有时你应该跳过规划,让 Claude 自行解决,因为任务是探索性的。有时一个模糊的提示恰好正确,因为你想看看 Claude 在受限之前如何解释问题。

注意什么有效。当 Claude 产生出色的输出时,留意你做了什么:提示的结构、你提供的上下文、你使用的模式。当 Claude 遇到困难时,问问为什么。上下文噪音太大?提示太模糊?任务太大,无法一次完成?

久而久之,你会培养出任何指南都无法捕获的直觉。你会知道何时具体、何时开放,何时规划、何时探索,何时清空上下文、何时让它积累。

相关资源

本页为 官方英文文档 的中文译版(机器翻译 + 结构校验)· 译于 2026-07-17 · 以英文原文为准 · 返回 Claude Code 提示词库