Anthropic 最近发布了 Claude Code，一个面向智能体编程的命令行工具。这玩意儿最初是作为研究项目开发的，不过现在它已经成了 Anthropic 内部工程师和研究人员的得力助手——用一种更原生、更直接的方式，把 Claude 集成到他们的编码工作流中。

Claude Code 的设计哲学很有意思：刻意保持在底层，不带任何预设偏好（用他们的话说就是 unopinionated）。什么意思呢？就是它尽量让你接近原始模型的能力，而不是强迫你走某种固定流程。这种理念带来的是一个灵活、可定制、可脚本化，同时又确保了安全性的工具。听起来很美，对吧？但问题在于，这种灵活性对刚接触智能体编程工具的工程师来说，意味着一定的学习成本——至少在你摸索出自己的最佳实践之前，得花点功夫。

这篇文章梳理了一些已经被证明行之有效的通用模式，这些模式不仅在 Anthropic 内部团队中得到了验证，也适用于外部工程师在各种代码库、语言和环境中的实践。需要特别说明的是：这里列出的每一条都不是什么金科玉律，没有放之四海而皆准的真理。请把它们当成起点，大胆实验，找到最适合你自己的玩法。

更详细的文档？可以去 claude.ai/code 看看，涵盖了本文提到的所有功能，还有额外的示例、实现细节和进阶技巧。

1. 定制你的设置

Claude Code 是一个智能体编程助手，它会自动把上下文信息拉取到提示中。这个过程会消耗时间和 token，但你完全可以通过调整环境来优化它。

a. 创建 CLAUDE.md 文件

CLAUDE.md 是一个特殊文件——Claude 在开始对话时会自动将其内容拉取到上下文中。所以它特别适合用来记录这些东西：

• 常用的 bash 命令
• 核心文件和工具函数
• 代码风格指南
• 测试说明
• 代码仓库规范（比如分支命名、用 merge 还是 rebase 等）
• 开发者环境设置（例如 pyenv 的用法、哪些编译器可用）
• 项目特有的那些意外行为或警告
• 你希望 Claude 记住的其他信息

这个文件没有固定格式。建议保持简洁，易于人类阅读。举个例子：

# 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 命令的目录的任何子目录。和上面相反，这种情况是当你在子目录中处理文件时，Claude 会按需拉取对应目录下的 CLAUDE.md 文件。
• 你的主文件夹（~/.claude/CLAUDE.md），这会应用到所有 claude 会话。

还有个快捷方式：当你运行 /init 命令时，Claude 会自动帮你生成一个 CLAUDE.md 文件。

b. 优化你的 CLAUDE.md 文件

既然 CLAUDE.md 会成为 Claude 提示的一部分，那它就应该像任何你经常使用的提示一样，不断优化迭代。一个常见的错误是：一股脑儿塞进大量内容，却没有通过实际使用来验证其效果。花点时间做实验，搞清楚哪些内容能让模型最好地遵循指令。

你可以手动往 CLAUDE.md 里添加内容，也可以按 # 键给 Claude 一个指令，它会自动把这条指令整合到相关的 CLAUDE.md 中。很多工程师在编码时会频繁使用 # 来记录命令、文件和风格指南，然后把 CLAUDE.md 的改动包含在 commit 里，这样团队成员也能受益。

在 Anthropic 内部，我们偶尔会使用提示词优化器来处理 CLAUDE.md 文件，并且经常调整指令措辞——比如加上 "IMPORTANT" 或 "YOU MUST" 来强调——以提高遵从度。

图：Claude Code 工具允许列表设置界面

c. 管理 Claude 的允许工具列表

默认情况下，Claude Code 对任何可能修改你系统的操作都会请求许可：文件写入、许多 bash 命令、MCP 工具等等。这种保守的设计是故意的——优先保证安全性。不过你可以自定义允许列表，把那些你确定安全的工具放进去，或者允许那些容易撤销的潜在不安全操作（比如文件编辑、git commit）。

有四种方式管理允许的工具：

• 在会话中被提示时选择"始终允许 (Always allow)"。
• 启动后使用 /allowed-tools 命令来添加或移除允许列表中的工具。比如你可以添加 Edit 来始终允许文件编辑，Bash(git commit:*) 来允许 git 提交，或者 mcp__puppeteer__puppeteer_na vigate 来允许使用 Puppeteer MCP 服务器进行导航。
• 手动编辑 .claude/settings.json 或 ~/.claude.json（建议把前者检入源码控制以便团队共享）。
• 使用 --allowedTools 命令行标志进行会话级别的权限设置。

d. 如果使用 GitHub，请安装 gh CLI

Claude 知道如何使用 gh CLI 与 GitHub 交互——创建 issue、打开 pull request、读取评论等等。如果没有安装 gh，也别担心，如果你装了 GitHub API 或 MCP 服务器，Claude 照样能用。

2. 给 Claude 更多工具

Claude 可以访问你的 shell 环境，你可以在里面为它构建一堆便捷的脚本和函数——就像给自己构建一样。它还能通过 MCP 和 REST API 利用更复杂的工具。

a. 将 Claude 与 bash 工具结合使用

Claude Code 继承了你的 bash 环境，所以它能访问你所有的工具。但问题在于，虽然 Claude 知道常见的 unix 工具和 gh，如果你的工具有自定义的，它可不知道——除非你告诉它：

1. 告诉 Claude 工具名称和使用示例
2. 告诉 Claude 运行 --help 来查看工具文档
3. 在 CLAUDE.md 中记录常用的工具

b. 将 Claude 与 MCP 结合使用

Claude Code 同时充当 MCP 服务器和客户端。作为客户端，它可以通过三种方式连接到任意数量的 MCP 服务器以访问它们的工具：

• 在项目配置中（在那个目录下运行 Claude Code 时可用）
• 在全局配置中（在所有项目中可用）
• 在签入的 .mcp.json 文件中（对在你代码库中工作的任何人都可用）。例如，你可以把 Puppeteer 和 Sentry 服务器添加到 .mcp.json 中，这样每个在你仓库工作的工程师都能开箱即用地使用这些工具。

使用 MCP 时，用 --mcp-debug 标志启动 Claude 有助于识别配置问题。

c. 使用自定义斜杠命令

对于重复的工作流程——调试循环、日志分析等等——把提示模板存成 Markdown 文件放在 .claude/commands 文件夹里。当你输入 / 时，这些模板就会在斜杠命令菜单中间出现。你可以把这些命令检入 git，团队成员也能用上。

自定义斜杠命令里可以包含一个特殊关键字 $ARGUMENTS，用于从命令调用中传递参数。

举个例子，这是一个可以自动拉取并修复 GitHub issue 的斜杠命令：

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 去修复 issue #1234。同样，你也可以把自己的个人命令添加到 ~/.claude/commands 文件夹中，使其在所有会话中可用。

3. 尝试常见工作流程

Claude Code 不强加特定工作流程，这种灵活性给了你充分的自由去按自己的方式使用。不过，在用户社区中，已经涌现出几种被证明非常有效的模式：

a. 探索、计划、编码、提交

这个通用工作流程适用于很多问题：

1. 让 Claude 阅读相关文件、图片或 URL——可以给一般性指引（"阅读处理日志的文件"）或具体文件名（"阅读 logging.py"），但明确告诉它暂时不要写任何代码。
   1. 这一步值得重点考虑使用子智能体，特别是对于复杂问题。在对话或任务早期，让 Claude 用子智能体验证细节或调查具体问题，通常能在不损失太多效率的前提下保留上下文可用性。
2. 让 Claude 制定解决特定问题的计划。建议使用"思考 (think)"这个词来触发扩展思考模式，这会给 Claude 额外的计算时间，更彻底地评估备选方案。这些特定短语直接映射到系统中递增的思考预算级别："思考 (think)" < "深入思考 (think hard)" < "更深入思考 (think harder)" < "极致思考 (ultrathink)"，每个级别分配逐步增加的思考预算。
   1. 如果这一步的结果看着合理，你可以让 Claude 用计划创建一个文档或 GitHub issue——这样如果后续实现（步骤3）不理想，你可以回滚到这个点重新来。
3. 让 Claude 用代码实现其解决方案。这也是个好时机，让它边实现边明确验证方案的合理性。
4. 让 Claude 提交结果并创建一个 pull request。如果相关，顺便让它更新 README 或变更日志，解释一下刚做了什么。

步骤 #1-#2 至关重要——没有它们，Claude 往往会直接跳到编码解决方案。虽然有时候你确实希望它直接开干，但对于需要深入前期思考的问题，要求 Claude 先研究和计划，可以显著提升性能。

b. 编写测试、提交；编码、迭代、提交

这是 Anthropic 内部最受欢迎的工作流程之一，适用于能通过单元测试、集成测试或端到端测试轻松验证的改动。测试驱动开发（TDD）在智能体编程的加持下变得更加强大：

1. 让 Claude 根据预期的输入/输出编写测试。明确说明你正在进行测试驱动开发，这样它会避免创建模拟实现，即使对代码库中尚不存在的功能也是如此。
2. 告诉 Claude 运行测试并确认它们失败。明确告诉它在此阶段不要编写任何实现代码，通常很有帮助。
3. 当你对测试满意后，让 Claude 提交测试。
4. 让 Claude 编写通过测试的代码，指示它不要修改测试。告诉 Claude 继续进行，直到所有测试通过。通常需要几次迭代——编写代码、运行测试、调整代码、再运行测试。
   1. 在这个阶段，让它使用独立的子智能体来验证实现是否过度拟合测试，可能会有帮助。
5. 当你对改动满意后，让 Claude 提交代码。

当 Claude 有一个明确的目标可以迭代时——一个视觉模型、一个测试用例或其他类型的输出——它的表现最好。通过提供像测试这样的预期输出，Claude 可以进行改动、评估结果，并逐步改进直到成功。

c. 编写代码、截图结果、迭代

和测试工作流程类似，你可以给 Claude 提供视觉目标：

1. 给 Claude 一种截取浏览器屏幕截图的方法（比如用 Puppeteer MCP 服务器、iOS 模拟器 MCP 服务器，或者手动复制粘贴截图给 Claude）。
2. 给 Claude 一个视觉模型——通过复制粘贴、拖放图像，或者提供图像文件路径。
3. 让 Claude 用代码实现设计，截取结果的屏幕截图，然后迭代直到结果与模型匹配。
4. 当你满意后，让 Claude 提交。

像人类一样，Claude 的输出通常会随着迭代显著改善。第一个版本可能不错，但经过 2-3 次迭代后，效果通常会好得多。让 Claude 拥有看到自己输出的能力，才能得到最佳结果。

图：在隔离的容器中使用安全 YOLO 模式

d. 安全 YOLO 模式

你可以不监督 Claude，而是用 claude --dangerously-skip-permissions 来绕过所有权限检查，让 Claude 不间断地工作直到完成。这对于修复 lint 错误或生成样板代码等工作流程非常高效。

警告： 让 Claude 运行任意命令是有风险的，可能导致数据丢失、系统损坏甚至数据泄露（比如通过提示注入攻击）。为了最小化这些风险，请在无互联网访问的容器中使用 --dangerously-skip-permissions。可以参照使用 Docker Dev Containers 的参考实现。

e. 代码库问答

接触新代码库时，用 Claude Code 来学习和探索再合适不过了。你可以像在结对编程时问项目里的其他工程师一样，向 Claude 提各种问题。Claude 能智能地搜索代码库来回答常见问题，比如：

• 日志记录是怎么工作的？
• 如何创建一个新的 API 端点？
• foo.rs 文件第 134 行的 async move { ... } 是干什么的？
• CustomerOnboardingFlowImpl 处理了哪些边缘情况？
• 为什么我们在第 333 行调用 foo() 而不是 bar()？
• baz.py 文件第 334 行在 Ja va 中的等价实现是什么？

在 Anthropic，这种方式已经成为核心的入职工作流程——显著缩短了熟悉项目的时间，也减轻了其他工程师的负担。不需要什么特殊提示，直接提问就行，Claude 会自己探索代码找答案。

图：使用 Claude 编写 git commit 消息

f. 使用 Claude 与 git 交互

Claude 能高效处理很多 git 操作。很多 Anthropic 工程师会把 90% 以上的 git 交互交给 Claude 来处理：

• 搜索 git 历史记录来回答诸如"v1.2.3 版本包含了哪些改动？"、"这个特定功能是谁负责的？"或"为什么这个 API 这么设计？"等问题。明确提示 Claude 查找 git 历史记录会很有帮助。
• 编写 commit 消息。Claude 会自动查看你的改动和最近的历史记录，写出一条考虑了所有相关上下文的 commit 消息。
• 处理复杂的 git 操作，比如还原文件、解决 rebase 冲突、比较和嫁接补丁等。

g. 使用 Claude 与 GitHub 交互

Claude Code 可以管理很多 GitHub 交互：

• 创建 pull requests：Claude 理解速记 "pr"，会根据 diff 和周围上下文生成合适的 commit 消息。
• 为简单的代码审查评论实现一键式解决方案：告诉它修复你 PR 上的评论（可选地，给更具体的指示），然后让它推送到 PR 分支。
• 修复失败的构建或 linter 警告。
• 对开放的 issue 进行分类和分流——让 Claude 遍历开放的 GitHub issue 即可。

这省去了记忆 gh 命令行语法的麻烦，同时自动化了常规任务。

h. 使用 Claude 处理 Jupyter notebook

Anthropic 的研究人员和数据科学家经常用 Claude Code 来读取和编写 Jupyter notebook。Claude 能解释输出（包括图像），为探索和数据分析提供了一种快速方式。没有固定的提示或工作流程，不过推荐的一种做法是：在 VS Code 里并排打开 Claude Code 和一个 .ipynb 文件。

你也可以让 Claude 在向同事展示之前清理或美化你的 Jupyter notebook。明确告诉它让 notebook 或数据可视化"美观"，往往会提醒它这是在为人类的观看体验做优化。

4. 优化你的工作流程

以下建议适用于所有工作流程：

a. 在指令中要具体

Claude Code 的成功率会随着更具体的指令而显著提高，尤其是在第一次尝试时。提前给出明确的方向能减少后续修正的需要。

举个例子：

欠佳的指令	良好的指令
为 foo.py 添加测试	为 foo.py 编写一个新的测试用例，覆盖用户未登录的边缘情况。避免使用 mock。
为什么 ExecutionFactory 的 API 这么奇怪？	查看 ExecutionFactory 的 git 历史记录，并总结其 API 是如何演变而来的。
添加一个日历小部件	查看主页上现有小部件的实现方式，以理解模式，特别是代码和接口是如何分离的。HotDogWidget.php 是一个好的起点。然后，遵循该模式实现一个新的日历小部件，允许用户选择月份并通过向前/向后翻页来选择年份。除了代码库中已使用的库之外，不要使用其他库，从头开始构建。

Claude 可以推断意图，但它无法读心。具体性可以更好地对齐预期。

图：向 Claude 提供图片作为上下文

b. 给 Claude 图片

Claude 可以通过多种方式出色地处理图像和图表：

• 粘贴截图（专业提示：在 macOS 中按 cmd+ctrl+shift+4 截图到剪贴板，然后按 ctrl+v 粘贴）
• 拖放图像直接到提示输入框
• 提供图像的文件路径

这在处理设计模型作为 UI 开发的参考点，以及使用可视化图表进行分析和调试时特别有用。即使你不往上下文中添加视觉效果，向 Claude 明确说明结果在视觉上很重要，仍然是有帮助的。

图：使用 tab 补全来引用文件

c. 提及你希望 Claude 查看或处理的文件

使用 tab 键补全功能可以快速引用仓库中任何位置的文件或文件夹，帮助 Claude 找到或更新正确的资源。

图：向 Claude 提供 URL 作为上下文

d. 给 Claude URL

把特定的 URL 粘贴到提示旁边，让 Claude 去获取并阅读。为了避免对相同域名（比如 docs.foo.com）反复弹出权限提示，可以使用 /allowed-tools 把域名加入允许列表。

e. 尽早且经常地修正方向

虽然自动接受模式（按 shift+tab 切换）可以让 Claude 自主工作，但通常你作为积极的协作者，指导 Claude 的方法，会得到更好的结果。你可以在开始时向 Claude 彻底解释任务以获得最佳结果，但也可以随时修正 Claude 的方向。

下面这四个工具对修正方向很有帮助：

• 在编码之前要求 Claude 制定计划。明确告诉它在你确认计划看起来不错之前不要编码。
• 在任何阶段（思考、工具调用、文件编辑）按 Escape 键中断 Claude，同时保留上下文，以便你重新定向或扩展指令。
• 双击 Escape 键跳回历史记录，编辑之前的提示，探索不同方向。你可以编辑提示并重复，直到获得想要的结果。
• 要求 Claude 撤销改动，通常与选项 #2 结合使用来采取不同的方法。

尽管 Claude Code 偶尔能在第一次尝试时完美解决问题，但使用这些修正工具通常能更快地产生更好的解决方案。

f. 使用 /clear 保持上下文聚焦

在长时间的会话中，Claude 的上下文窗口可能会被不相关的对话、文件内容和命令填满，这会降低性能，有时还会分散他的注意力。在任务之间经常使用 /clear 命令来重置上下文窗口。

g. 对复杂工作流程使用清单和草稿板

对于包含多个步骤或需要详尽解决方案的大型任务——比如代码迁移、修复大量 lint 错误或运行复杂的构建脚本——让 Claude 使用 Markdown 文件（甚至 GitHub issue！）作为清单和工作草稿板，可以提高性能。

例如，要修复大量 lint 问题，可以这么做：

1. 告诉 Claude 运行 lint 命令，并把所有结果错误（包括文件名和行号）写入 Markdown 清单。
2. 指示 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 进行 issue 分流

无头模式可以驱动由 GitHub 事件触发的自动化，比如当仓库中创建了新 issue 时。公共的 Claude Code 仓库就用 Claude 来检查新传入的 issue 并分配合适的标签。

b. 使用 Claude 作为 linter

Claude Code 可以提供主观的代码审查，超越传统 linting 工具所能检测到的问题，比如识别拼写错误、过时的注释、误导性的函数或变量名等。

6. 通过多 Claude 工作流程提升效率

除了独立使用，一些最强大的应用涉及并行运行多个 Claude 实例：

a. 让一个 Claude 编写代码；用另一个 Claude 来验证

一个简单但有效的做法：让一个 Claude 编写代码，另一个来审查或测试。类似于和多位工程师协作，有时独立的上下文反而更有益：

1. 用 Claude 编写代码。
2. 运行 /clear 或在另一个终端中启动第二个 Claude。
3. 让第二个 Claude 审查第一个 Claude 的工作。
4. 启动另一个 Claude（或再次 /clear）来阅读代码和审查反馈。
5. 让这个 Claude 根据反馈编辑代码。

你也可以对测试做类似的事：让一个 Claude 编写测试，另一个编写代码使测试通过。甚至可以让不同的 Claude 实例通过独立的工作草稿板来通信——告诉它们写入哪个、读取哪个。

这种分离通常比让单个 Claude 处理所有事情产生更好的结果。

b. 拥有多个代码库检出

Anthropic 的很多工程师并不会等 Claude 完成每一步才动手，而是这样操作：

1. 在不同的文件夹中创建 3-4 个 git 检出。
2. 在不同的终端选项卡中打开每个文件夹。
3. 在每个文件夹中启动 Claude，分配不同的任务。
4. 轮流查看，检查进度并批准或拒绝权限请求。

c. 使用 git worktrees

这种方法对于多个独立任务特别高效，比多个检出更轻量级。Git worktrees 允许你把同一仓库的多个分支检出到不同目录中。每个 worktree 都有自己的独立工作目录和文件，同时共享相同的 Git 历史记录和 reflog。

使用 git worktrees 可以让你同时在项目的不同部分运行多个 Claude 会话，每个会话专注于独立的任务。比如让一个 Claude 重构你的身份验证系统，另一个构建完全不相关的数据可视化组件。由于任务不重叠，每个 Claude 都可以全速工作，不需要等待对方的改动或处理合并冲突：

1. 创建 worktrees：git worktree add ../project-feature-a feature-a
2. 在每个 worktree 中启动 Claude：cd ../project-feature-a && claude
3. 根据需要创建额外的 worktrees（在新的终端选项卡中重复步骤1-2）

一些小技巧：

• 使用一致的命名约定。
• 为每个 worktree 维护一个终端选项卡。
• 如果你在 Mac 上使用 iTerm2，可以设置通知，让 Claude 需要注意时提醒你。
• 为不同的 worktrees 使用单独的 IDE 窗口。
• 完成后清理：git worktree remove ../project-feature-a

d. 将无头模式与自定义工具链结合使用

claude -p（无头模式）可以将 Claude Code 以编程方式集成到更大的工作流程中，同时利用其内置工具和系统提示。使用无头模式主要有两种模式：

1. 并行分发，处理大型迁移或分析（比如分析数百个日志中的情感，或分析数千个 CSV）：

   1. 让 Claude 编写一个脚本生成任务列表。比如生成一个需要从框架A迁移到框架B的2000个文件的列表。
   2. 循环遍历任务，为每个任务以编程方式调用 Claude，给它任务和一组可用的工具。例如：claude -p "将 foo.py 从 React 迁移到 Vue。完成后，如果成功，你必须返回字符串 OK，如果任务失败则返回 FAIL。" --allowedTools Edit Bash(git commit:*)
   3. 多次运行脚本并优化你的提示以获得期望结果。

2. 流水线处理，将 Claude 集成到现有的数据/处理流水线中：

   1. 调用 claude -p "" --json | your_command，其中 your_command 是处理流水线的下一步。
   2. 就这样！JSON 输出（可选）可以帮助提供结构，便于自动化处理。

对于这两种用例，使用 --verbose 标志进行 Claude 调用的调试会有帮助。通常建议在生产环境中关闭详细模式以获得更清晰的输出。