Claude Code是一个用于代理式编程的命令行工具。作为一项研究项目,Claude Code 为 Anthropic 的工程师和研究人员提供了一种更原生的方式,将 Claude 集成到他们的编码工作流中。
Claude Code 是有意设计得底层且无强制性的,提供了接近原始模型访问的能力,而不会强加特定的工作流。这种设计理念创造了一个灵活、可定制、可脚本化且安全的强力工具。不过,这种灵活性对于初次使用代理式编程工具的工程师来说存在必定的学习曲线——至少在他们形成自己的最佳实践之前是如此。
本文列出了已被证明有效的通用模式,这些模式不仅对 Anthropic 内部团队有效,也适用于外部工程师在各种代码库、语言和环境中使用 Claude Code 的情况。文中没有任何一条是固定不变或普遍适用的;请将这些提议视为起点。我们鼓励你进行实验,找到最适合你的方法!
1. 自定义你的设置
Claude Code 是一个能够自动拉取上下文的代理式编程助手。这种上下文收集会消耗时间和 token,但你可以通过环境调优来优化它。
a. 创建 CLAUDE.md 文件
CLAUDE.md 是一个特殊文件,Claude 在启动对话时会自动将其内容拉入上下文。这使其成为记录以下内容的理想场所:
- 常用 bash 命令
- 核心文件和实用函数
- 代码风格指南
- 测试说明
- 仓库规范(如分支命名、合并 vs rebase 等)
- 开发环境设置(如 pyenv use、哪些编译器可用)
- 项目中特别需要注意的行为或警告
- 其他你想让 Claude 记住的信息
CLAUDE.md 文件没有强制格式要求。我们提议保持简洁和人类可读性。例如:
# Bash commands
– npm run build: Build the project
– npm run typecheck: Run the typechecker
# 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.md 并提交到 git 中,这样可以在不同会话和团队成员之间共享(推荐),或者命名为 CLAUDE.local.md 并加入 .gitignore。
- 运行 claude 所在目录的任意父级目录。这对于 monorepo 特别有用,列如你在 root/foo 运行 claude,而在 root/CLAUDE.md 和 root/foo/CLAUDE.md 都有 CLAUDE.md 文件,这两个文件都会被自动拉入上下文。
- 运行 claude 所在目录的任意子目录。这是上述情况的反向操作,在你处理子目录中的文件时,Claude 会按需拉入 CLAUDE.md 文件。
- 你的主目录(~/.claude/CLAUDE.md),这将应用于你所有的 claude 会话。
当你运行 /init 命令时,Claude 会自动生成一个 CLAUDE.md 文件。
b. 调整你的 CLAUDE.md 文件
你的 CLAUDE.md 文件会成为 Claude 提示的一部分,因此应像任何常用提示一样进行优化。一个常见的错误是在没有迭代其有效性的情况下添加大量内容。花时间实验并确定什么能产生最好的指令执行效果。
你可以手动向 CLAUDE.md 添加内容,也可以按下 # 键,让 Claude 自动将指令整合到相关的 CLAUDE.md 文件中。许多工程师常常使用 # 来在编码过程中记录命令、文件和风格指南,然后将 CLAUDE.md 的更改包含在提交中,以便团队成员也能受益。
在 Anthropic,我们有时会运行 CLAUDE.md 文件通过提示优化器,并常常调整指令(例如使用 “IMPORTANT” 或 “YOU MUST” 来强调某些部分),以提高执行效果。

Claude Code 工具白名单
c. 精选允许的工具列表
默认情况下,Claude Code 会对任何可能修改系统的操作请求权限:文件写入、大多数 bash 命令、MCP 工具等。我们设计了这种保守的方法以确保安全性。你可以自定义允许列表,添加你认为安全的额外工具,或者允许那些容易撤销的潜在不安全工具(如文件编辑、git commit)。
有四种方式可以管理允许的工具:
- 在会话中选择“始终允许”。
- 启动 Claude Code 后使用 /allowed-tools 来添加或移除允许的工具。例如,你可以添加 Edit 以始终允许文件编辑,添加 Bash(git commit:*) 以允许 git commit,或添加 mcp__puppeteer__puppeteer_navigate 以允许使用 Puppeteer MCP 服务器导航。
- 手动编辑 .claude/settings.json 或 ~/.claude.json(我们提议将前者提交到源码控制中,与团队共享)。
- 使用 –allowedTools CLI 标志 以进行会话特定的权限设置。
d. 如果使用 GitHub,请安装 gh CLI
Claude 知道如何使用 gh CLI 与 GitHub 交互,例如创建问题、打开 pull request、读取评论等。如果没有安装 gh,Claude 依旧可以通过 GitHub API 或 MCP 服务器(如果你已安装)与其交互。
2. 给 Claude 更多工具
Claude Code 继承了你的 shell 环境,使它可以访问所有你的工具。虽然 Claude 知道一些常见的工具如 Unix 工具和 gh,但它不知道你的自定义 bash 工具,除非你给出说明:
- 告知 Claude 工具名称及使用示例
- 告知 Claude 运行 –help
- 在 CLAUDE.md 中记录常用的工具
b. 将 Claude 与 MCP 一起使用
Claude Code 既可以作为 MCP 服务器也可以作为客户端。作为客户端,它可以连接到任意数量的 MCP 服务器,通过三种方式访问它们的工具:
- 在项目配置中(在该目录下运行 Claude Code 时可用)
- 在全局配置中(在所有项目中可用)
- 在提交的 .mcp.json 文件中(可供任何人使用)。例如,你可以在 .mcp.json 文件中添加 Puppeteer 和 Sentry 服务器,这样每个在你的代码库中工作的工程师都可以开箱即用地使用这些工具。
在使用 MCP 时,启动 Claude 时加上 –mcp-debug 标志有助于识别配置问题。
c. 使用自定义斜杠命令
对于重复的工作流——调试循环、日志分析等——将提示模板存储在 .claude/commands 文件夹内的 Markdown 文件中。这些文件会在你输入 / 时出目前斜杠命令菜单中。你可以将这些命令提交到 git 中,供团队其他成员使用。
自定义斜杠命令可以包含特殊关键字 $ARGUMENTS,以从命令调用中传递参数。
例如,下面是一个可用于自动拉取并修复 GitHub 问题的斜杠命令:
Please analyze and fix the GitHub issue: $ARGUMENTS.
Follow these steps:
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
Remember to use the GitHub CLI (`gh`) for all GitHub-related tasks.
将上述内容放入
.claude/commands/fix-github-issue.md 文件后,它将在 Claude Code 中作为 /project:fix-github-issue 命令可用。你可以使用 /project:fix-github-issue 1234 来让 Claude 修复第 #1234 号问题。同样,你可以将你希望在所有会话中可用的个人命令添加到 ~/.claude/commands 文件夹中。
3. 尝试常见工作流
Claude Code 不强制规定特定的工作流,给你足够的灵活性来按照自己的方式进行。在我们用户社区中,已经出现了几种成功的使用模式:
a. 探索 → 规划 → 编码 → 提交
这个多功能的工作流适合许多问题:
- 让 Claude 阅读相关文件、图片或 URL,可以给出一般性指引(“阅读处理日志的文件”)或具体文件名(“阅读 logging.py”),但明确告知它暂时不要编写代码。- 这一步工作中应思考使用子代理,尤其是在处理复杂问题时。告知 Claude 使用子代理来验证细节或调查特定问题,尤其是在对话或任务初期,一般可以在不影响效率的前提下保留上下文可用性。
- 让 Claude 制定解决问题的计划。我们提议使用“think”触发扩展思考模式,这会给 Claude 更多计算时间来更彻底地评估替代方案。这些特定短语直接映射到系统中增加的思考预算:“think” < “think hard” < “think harder” < “ultrathink”。每个级别分配逐步更多的思考预算给 Claude 使用。- 如果这一步的结果看起来合理,你可以让 Claude 创建一个文档或 GitHub 问题,记录它的计划,这样你可以在实施阶段(步骤 3)如果不满意结果时重置到这一点。
- 让 Claude 实现解决方案。这也是一个好时机,要求它在实现每个部分时明确验证解决方案的合理性。
- 让 Claude 提交结果并创建 pull request。如果相关,这也是更新 README 或 changelog 的好时机,解释它刚刚做了什么。
步骤 #1–#2 至关重大——没有它们,Claude 往往会直接跳到编码解决方案。虽然有时这就是你想要的,但在需要深入思考的问题上,先让 Claude 研究和规划可以显著提高性能。
b. 写测试 → 提交;写代码 → 迭代 → 提交
这是 Anthropic 最喜爱的工作流之一,适用于可以通过单元测试、集成测试或端到端测试轻松验证的更改。测试驱动开发(TDD)在代理式编程中变得更加强劲:
- 让 Claude 根据预期的输入/输出对编写测试。要明确说明你正在做 TDD,这样它可以避免即使在代码库中尚未存在的功能也创建模拟实现。
- 告知 Claude 运行测试并确认它们失败。在这个阶段明确告知它不要编写任何实现代码一般是很有协助的。
- 当你满意测试后,让 Claude 提交测试。
- 让 Claude 编写能通过测试的代码,指示它不要修改测试。告知它继续直到所有测试都通过。它一般需要几次迭代才能写出代码、运行测试、调整代码并再次运行测试。- 在此阶段,让它使用独立的子代理来验证实现是否过拟合测试可能会有所协助。
- 当你满意更改后,让 Claude 提交代码。
当 Claude 有一个明确的目标去迭代时,它表现最好——视觉原型、测试案例或其他类型的输出。通过提供像测试这样的预期输出,Claude 可以做出更改、评估结果并逐步改善,直到成功。
c. 写代码 → 截图结果 → 迭代
类似于测试工作流,你可以为 Claude 提供视觉目标:
- 给 Claude 一种截取浏览器截图的方式(例如,使用 Puppeteer MCP 服务器、iOS 模拟器 MCP 服务器,或手动复制/粘贴截图)。
- 给 Claude 一个视觉原型,通过复制/粘贴或拖放图像,或提供图像文件路径。
- 让 Claude 根据设计编写代码,截取结果截图,并迭代直到结果匹配原型。
- 当你满意时,让 Claude 提交。
像人类一样,Claude 的输出往往会随着迭代显著改善。虽然第一版可能不错,但经过 2–3 次迭代后,它一般会看起来更好。给 Claude 看到自己输出的工具会有最佳效果。

Safe yolo mode
d. Safe YOLO 模式
与其监督 Claude,你可以使用 claude
–dangerously-skip-permissions 跳过所有权限检查,让 Claude 不受干扰地工作直到完成。这在修复 linter 错误或生成样板代码等工作流中超级有效。
让 Claude 运行任意命令是有风险的,可能导致数据丢失、系统损坏甚至数据外泄(例如通过 prompt injection 攻击)。为了最小化这些风险,请在没有互联网访问权限的容器中使用
–dangerously-skip-permissions。你可以参考使用 Docker Dev Containers 的实现。
e. 代码库问答
当你进入一个新的代码库时,可以使用 Claude Code 进行学习和探索。你可以问 Claude 你会问另一个工程师在结对编程时同样的问题。Claude 可以代理式搜索代码库来回答如下问题:
- 日志记录是如何工作的?
- 如何创建新的 API 端点?
- 第 134 行 foo.rs 中的 async move { … } 是什么意思?
- CustomerOnboardingFlowImpl 处理哪些边界情况?
- 为什么在第 333 行调用 foo() 而不是 bar()?
- baz.py 第 334 行在 Java 中的等价物是什么?
在 Anthropic,我们使用 Claude Code 进行这种方式的学习已经成为核心入职流程,大大提高了上手速度并减少了其他工程师的负担。不需要特殊的提示!只需提问,Claude 就会探索代码以找到答案。

Use Claude to interact with git
f. 使用 Claude 与 Git 交互
Claude 可以有效地处理许多 Git 操作。Anthropic 的许多工程师使用 Claude 处理 90%+ 的 git 交互:
- 搜索 以回答诸如“v1.2.3 中有哪些变更?”、“谁负责这个功能?”或“为什么这个 API 设计成这样?”等问题。明确提示 Claude 查看 Git 历史记录来回答这些问题会有协助。
- 编写提交信息
- 处理复杂的 Git 操作,如回滚文件、解决 rebase 冲突以及比较和嫁接补丁
g. 使用 Claude 与 GitHub 交互
Claude Code 可以管理许多 GitHub 交互:
- 创建 pull request:Claude 理解缩写“pr”,并将根据 diff 和上下文生成适当的提交信息。
- 实现一次性解决简单代码审查评论:只需告知它修复 PR 上的评论(可选地,给它更具体的指令)并在完成后推送到 PR 分支。
- 修复失败的构建或 linter 警告
- 分类和整理开放问题,让 Claude 遍历开放的 GitHub 问题
这消除了记住 gh 命令行语法的需要,同时自动化了例行任务。
h. 使用 Claude 处理 Jupyter 笔记本
Anthropic 的研究人员和数据科学家使用 Claude Code 来读写 Jupyter 笔记本。Claude 可以解释输出,包括图像,提供一种快速探索和与数据交互的方式。没有必须的提示或工作流,但我们推荐的工作流是将 Claude Code 和 .ipynb 文件并排打开在 VS Code 中。
你还可以让 Claude 清理或对 Jupyter 笔记本进行美学改善,然后再展示给同事。明确告知它要让笔记本或其数据可视化“美观”一般有助于提醒它是为了人类观看体验而优化。
4. 优化你的工作流
以下提议适用于所有工作流:
a. 指令要具体
Claude Code 的成功率在第一次尝试时会因更具体的指令而显著提升。提前给出清晰的方向可以减少后续纠偏的需求。
例如:
|
不够好 |
更好 |
|
add tests for foo.py |
为 foo.py 编写一个新的测试用例,覆盖用户未登录的边界情况。避免使用 mocks |
|
why does ExecutionFactory have such a weird api? |
查看 ExecutionFactory 的 Git 历史记录并总结其 API 形成的过程 |
|
add a calendar widget |
查看主页上现有小部件的实现方式,了解代码和接口分离的模式。HotDogWidget.php 是一个很好的起点。然后,遵循该模式实现一个新的日历小部件,让用户可以选择月份并通过分页前后翻页选择年份。从头开始构建,不使用除代码库中已使用的库之外的其他库 |
Claude 可以推断意图,但它不能读心。具体性带来更好的预期一致性。

给 Claude 图片
b. 给 Claude 图片
Claude 对图片和图表的支持超级好,可通过以下几种方式提供:
- 粘贴截图(小技巧:在 macOS 上按 cmd+ctrl+shift+4 截图到剪贴板,再按 ctrl+v 粘贴。注意这不是一般在 Mac 上使用的 cmd+v,并且远程操作时不生效)
- 拖放 图片直接到提示输入框中
- 提供图片文件路径
这在使用设计原型作为 UI 开发参考点,以及进行分析和调试时特别有用。即使你不添加视觉内容到上下文中,也要清楚地告知 Claude 结果的视觉吸引力有多重大。

提及你希望 Claude 查看或操作的文件
c. 提及你希望 Claude 查看或操作的文件
使用 tab 补全快速引用仓库中的任意文件或文件夹,协助 Claude 找到或更新正确的资源。

给 Claude URLs
d. 给 Claude URLs
将特定的 URL 与提示一起粘贴,让 Claude 获取并阅读。为了避免对一样域名(例如 docs.foo.com)的权限提示,使用 /allowed-tools 将域名加入白名单。
e. 尽早频繁地纠正方向
虽然自动接受模式(按 shift+tab 切换)可以让 Claude 自主工作,但你一般会通过积极协作并引导其方法获得更好的结果。你可以在开始时彻底向 Claude 解释任务以获得最佳结果,也可以随时进行方向修正。
以下四种工具可以协助你进行方向修正:
- 让 Claude 在编码前制定计划。明确告知它在你确认计划看起来良好之前不要编码。
- 按 Esc 中断 Claude 在任何阶段(思考、工具调用、文件编辑),保留上下文以便你可以重新定向或扩展指令。
- 双击 Esc 返回历史记录,编辑之前的提示,并探索不同的方向。你可以编辑提示并重复直到得到你想要的结果。
- 让 Claude 撤销更改,一般与选项 #2 结合使用以采取不同的方法。
尽管 Claude Code 有时能在第一次尝试中完美解决问题,但使用这些纠正工具一般能更快地产生更好的解决方案。
f. 使用 /clear 保持上下文专注
在长时间会话中,Claude 的上下文窗口可能会充满无关的对话、文件内容和命令。这可能会降低性能,有时还会分散 Claude 的注意力。在任务之间频繁使用 /clear 命令来重置上下文窗口。
g. 使用清单和草稿本处理复杂工作流
对于具有多个步骤的大任务或需要详尽解决方案的任务——如代码迁移、修复大量 linter 错误或运行复杂的构建脚本——通过让 Claude 使用 Markdown 文件(甚至是 GitHub 问题!)作为清单和工作草稿本来提高性能:
例如,要修复大量 lint 问题,你可以这样做:
- 让 Claude 运行 lint 命令 并将所有结果错误(带文件名和行号)写入 Markdown 清单
- 指示 Claude 逐一处理每个问题,在检查并确认后标记为完成,然后继续下一个
h. 向 Claude 传递数据
有几种方法可以向 Claude 提供数据:
- 复制粘贴 直接到你的提示中(最常见的方式)
- 管道传入到 Claude Code(例如,cat foo.txt | claude),特别适用于日志、CSV 和大数据
- 告知 Claude 拉取数据 通过 bash 命令、MCP 工具或自定义斜杠命令
- 让 Claude 读取文件 或获取 URL(也适用于图片)
大多数会话涉及这些方法的组合。例如,你可以管道传入一个日志文件,然后告知 Claude 使用一个工具来拉取更多上下文以调试日志。
5. 使用无头模式自动化你的基础设施
Claude Code 包含无头模式,用于 CI、pre-commit hooks、构建脚本和自动化等非交互式场景。使用 -p 标志配合提示启用无头模式,使用 –output-format stream-json 以流式 JSON 输出。
请注意,无头模式不会在会话之间持久化。你必须在每次会话中触发它。
a. 使用 Claude 进行问题分类
无头模式可以支持由 GitHub 事件触发的自动化,例如当你的仓库中创建新问题时。例如,公共的 Claude Code 仓库使用 Claude 来检查新问题并分配适当的标签。
b. 使用 Claude 作为 linter
Claude Code 可以提供超越传统 linter 工具的主观代码审查,识别拼写错误、陈旧注释、误导性的函数或变量名等。
6. 升级使用多 Claude 工作流
除了单独使用外,一些最强劲的应用涉及并行运行多个 Claude 实例:
a. 一个 Claude 写代码;另一个验证
一个简单但有效的方法是让一个 Claude 写代码,另一个进行审查或测试。就像与多个工程师合作一样,有时分开上下文是有益的:
- 使用 Claude 写代码
- 运行 /clear 或在另一个终端中启动第二个 Claude
- 让第二个 Claude 审查第一个的工作
- 启动另一个 Claude(或再次 /clear)读取代码和审查反馈
- 让这个 Claude 根据反馈编辑代码
你也可以对测试做类似的事情:让一个 Claude 写测试,然后让另一个写代码使测试通过。你甚至可以让你的 Claude 实例彼此通信,通过给它们不同的工作草稿本并告知它们写入和读取哪个。
这种分离一般比让单个 Claude 处理所有事情产生更好的结果。
b. 使用多个代码库副本
而不是等待 Claude 完成每一步,Anthropic 的许多工程师的做法是:
- 创建 3–4 个 git 副本 在不同的文件夹中
- 在不同的终端标签中打开每个文件夹
- 在每个文件夹中启动 Claude 执行不同的任务
- 循环切换 以检查进度并批准/拒绝权限请求
c. 使用 git worktrees
这种方法超级适合多个独立任务,提供比多个副本更轻量的替代方案。Git worktrees 允许你将同一个仓库的不同分支检出到不同的目录中。每个 worktree 都有自己的工作目录,带有隔离的文件,同时共享一样的 Git 历史和 reflog。
使用 git worktrees 可以让你同时运行多个 Claude 会话,每个专注于项目的不同部分,各自处理独立的任务。例如,你可以让一个 Claude 重构认证系统,而另一个构建完全不相关的可视化组件。由于任务不重叠,每个 Claude 可以全速工作而不必等待对方的更改或处理冲突:
- 创建 worktrees:git worktree add ../project-feature-a feature-a
- 在每个 worktree 中启动 Claude:cd ../project-feature-a && claude
- 根据需要创建更多 worktrees(重复步骤 1–2 在新的终端标签中)
一些提示:
- 使用一致的命名约定
- 每个 worktree 使用一个终端标签
- 如果你在 Mac 上使用 iTerm2,设置通知以便 Claude 需要关注时你能收到提醒
- 使用不同的 IDE 窗口打开不同的 worktree
- 完成后清理:git worktree remove ../project-feature-a
d. 使用无头模式与自定义框架
claude -p(无头模式)可以将 Claude Code 程序化集成到更大的工作流中,同时利用其内置工具和系统提示。主要有两种使用无头模式的模式:
- 扇出(Fanning out) 处理大规模迁移或分析(例如分析数百条日志的情感或分析数千个 CSV):
- 让 Claude 编写一个生成任务列表的脚本。例如,生成一个需要从框架 A 迁移到框架 B 的 2000 个文件列表。循环遍历任务,程序化调用 Claude,给它一个任务和一组可以使用的工具。例如:claude -p “migrate foo.py from React to Vue. When you are done, you MUST return the string OK if you succeeded, or FAIL if the task failed.” –allowedTools Edit Bash(git commit:*)多次运行脚本并优化你的提示以获得期望结果。
- 流水线(Pipelining) 将 Claude 集成到现有的数据/处理管道中:
- 调用 claude -p “<your prompt>” –json | your_command,其中 your_command 是管道的下一步就是这样!JSON 输出(可选)可以协助为自动化处理提供结构。
对于这两种使用场景,使用 –verbose 标志来调试 Claude 调用可能会有协助。我们一般提议在生产环境中关闭 verbose 模式以获得更干净的输出。
致谢
作者:Boris Cherny。这项工作借鉴了整个 Claude Code 用户社区的最佳实践,他们的创意方法和工作流不断激励着我们。特别感谢 Daisy Hollman、Ashwin Bhat、Cat Wu、Sid Bidasaria、Cal Rueb、Nodir Turakulov、Barry Zhang、Drew Hodun 以及其他许多 Anthropic 工程师的宝贵见解和实践经验,这些经验协助塑造了这些提议。
想了解更多信息?我们的全面文档在 claude.ai/code 上,涵盖了本文提到的所有功能,并提供了更多示例、实现细节和高级技巧。
注:本文翻译自Claude Code Best Practices Anthropic。


