Claude Code 创始人 Boris Cherny 的 13 个使用技巧完整解析

前几天在 Twitter 上看到一个帖子，Claude Code 的创始人 Boris Cherny 分享了他自己使用 Claude Code 的方式。他说自己的配置"出人意料地简单"，因为 Claude Code 开箱即用效果就很好，所以他个人没有做太多定制。

不过看完他的 13 个技巧，我发现"简单"是相对的。他确实没有用什么黑科技，但他把 Claude Code 的各种功能组合起来用，形成了一套高效的工作流。这些技巧单独看都不难，组合起来效果很明显。

我把这 13 个技巧逐个研究了一遍，有些自己也实践了。这篇文章完整梳理一下，既是给大家的分享，也是自己的学习笔记。

![](/media/202603/2026-03-07_111050_7649170.41115728638660465.png)

### 技巧 1：并行运行 5 个 Claude

Boris 说他在终端同时运行 5 个 Claude，用 tab 1-5 编号，用系统通知来知道哪个 Claude 需要输入。

这个做法的核心思路是并行处理。等一个 Claude 跑的时候，可以给另一个 Claude 布置任务。不用干等，时间利用率更高。

要让这个模式跑起来，关键是要有通知机制。不然开 5 个窗口，根本顾不过来哪个在等待输入，哪个还在执行中。Boris 提到用系统通知，具体实现可以用 Hook：Claude 等待输入时触发一个通知脚本。

### 技巧 2：终端 + 网页版配合使用

除了本地终端的 5 个 Claude，Boris 还会在 claude.ai/code 上并行运行 5-10 个 Claude。本地和网页版之间可以来回切换：用 `&` 把本地会话推送到网页版，用 `--teleport` 把网页版会话拉回本地。

本地终端适合需要访问本地文件的任务，网页版适合不需要本地环境的任务，可以在云端跑不用占用本地资源。两边能来回切换，灵活调配。

`&` 是把当前本地会话推送到云端继续运行，适合你要离开电脑但任务还没完成的情况。

`--teleport` 是把网页版的会话拉到本地继续，适合你在网页版开始了一个任务，但发现需要访问本地文件或工具。

我目前主要用本地终端，网页版用得少。不过知道有这个能力，以后处理复杂项目可以考虑这种并行模式。

### 技巧 3：使用 Opus 4.5 + thinking

Boris 说他所有任务都用 Opus 4.5 with thinking。虽然 Opus 比 Sonnet 更大更慢，但因为需要的引导更少、工具使用更准确，最终反而更快。

这个我自己的体验也类似。用更强的模型，虽然单次响应慢一点，但一次做对的概率更高。不用来回修正，总时间反而更短。

而且 Opus 在处理复杂任务时明显更稳，不容易跑偏。Sonnet 有时候会理解错意图或者漏掉细节，Opus 这方面好很多。

如果你的场景对速度很敏感，可以简单任务用 Sonnet，复杂任务用 Opus。我基本都是用 Opus。

![image-20260106163504912](/media/202603/2026-03-07_1111260.06624418498466167.png)

### 技巧 4：团队共享 CLAUDE.md

他们团队有一个共享的 CLAUDE.md 文件，提交到 Git，整个团队每周都会贡献内容。每当发现 Claude 做错了什么，就把"不要这样做"加到 CLAUDE.md 里，让 Claude 下次知道避免。

这个做法我觉得很不错，把团队的集体经验沉淀下来，一个人踩过的坑其它人就不用再踩一遍了。

CLAUDE.md 是项目级别的配置文件，放在项目根目录。Claude Code 在这个项目里工作时会自动读取，了解项目的特殊规则和约定。

我觉得这个思路可以延伸：不只是记录"不要做什么"，也可以记录"应该怎么做"，比如项目的代码规范、架构约定、常见问题的处理方式。让 Claude 像一个熟悉项目的团队成员一样工作。

### 技巧 5：代码审查时 @.claude

Boris 说他在审查同事 PR 的时候，会 tag @.claude 来添加内容到 CLAUDE.md。他们用 Claude Code 的 GitHub Action 来实现这个功能。

这个场景是这样的：你在 review 同事的代码，发现 Claude 生成的某段代码有问题（比如用了不推荐的写法）。你可以 tag Claude，让它把"不要用这种写法"加到 CLAUDE.md 里，作为 PR 的一部分提交。

这样 code review 不只是发现问题，还能顺便改进 Claude 的行为，形成正向循环。

要用这个功能需要配置 Claude Code 的 GitHub Action，具体可以在 Claude Code 里运行 `/install-github-action`。

### 技巧 6：从 Plan mode 开始

大多数会话 Boris 会从 Plan mode 开始。如果目标是写一个 PR，他会用 Plan mode 和 Claude 来回讨论，直到满意计划。然后切换到 auto-accept edits 模式，Claude 通常可以一次性完成。

Plan mode 的快捷键是按两次 shift+tab。进入 Plan mode 后，Claude 不会直接动手改代码，而是先给你一个实现计划。你可以审查计划、提出修改意见、确认后再让它执行。

这个做法的好处是减少返工。如果一上来就让 Claude 写代码，写完发现方向不对，改起来很麻烦。先讨论计划，确认思路一致了再动手，效率更高。推荐大家多用plan模式。

![image-20260106163441453](/media/202603/2026-03-07_1111300.7786915535072179.png)

Boris 说"一个好的计划是成功的一半"，我觉得确实如此。尤其是复杂任务，花几分钟讨论计划，能省很多后面改来改去的时间。

### 技巧 7：Slash Commands 一键化高频操作

Boris 为每个"内循环"工作流创建了 Slash Commands，比如 `/commit-push-pr` 他每天要用几十次。这些命令提交到 Git，放在 `.claude/commands/` 目录，团队共享。

Slash Commands 本质就是快捷提示词。把你经常说的话保存成一个命令，下次直接输入 `/命令名` 就行了，不用每次打一长串。

我自己也配置了几个常用命令：/review 做代码审查、/test 跑测试、/commit-push-pr 提交推送创建 PR。确实省了不少重复输入的时间。

### 技巧 8：Subagents 自动化常见工作流

Boris 经常用几个子代理：code-simplifier 在 Claude 完成后简化代码，verify-app 提供端到端测试指南。他把 Subagents 理解为"自动化大多数 PR 的常见工作流"。

Subagents 和 Slash Commands 的区别是：Slash Commands 共享主对话上下文，Subagents 有独立的上下文窗口，可以并行执行。

code-simplifier 这个代理的思路很有意思：Claude 写代码的时候关注功能实现，可能写得比较啰嗦；写完之后让专门的代理做一遍简化，让代码更简洁。
![image-20260106163609744](/media/202603/2026-03-07_1111320.11820047304262882.png)

### 技巧 9：PostToolUse Hook 自动格式化

他们用 PostToolUse Hook 来格式化 Claude 生成的代码。Claude 大部分时候格式是对的，Hook 处理最后 10%，避免 CI 因为格式问题失败。

这个 Hook 在 Claude 每次写入或编辑文件后自动触发，运行格式化工具（比如 Prettier）。你不用每次手动跑格式化，也不用担心提交的代码格式不对。

配置方法是在 `settings.json` 里加一个 PostToolUse Hook，指定要监听的工具（Write、Edit、MultiEdit）和要执行的格式化命令。

### 技巧 10：权限预设而非跳过权限

Boris 说他不用 `--dangerously-skip-permissions`。相反，他用 `/permissions` 预先允许一些已知安全的命令，避免不必要的权限提示。这些配置提交到 `.claude/settings.json`，团队共享。

这个做法的思路是：不是要完全跳过权限检查（那样不安全），而是把确定安全的命令提前放行，减少干扰。

比如 `git status`、`git diff`、`ls`、`npm run test` 这些命令，在你的项目里肯定是安全的，可以预先允许。真正危险的命令（比如 `rm -rf`）还是会被拦住。

打算在自己的 settings.json 里配置了一批预先允许的命令，包括 git 只读操作、文件查看命令、测试和构建命令。同时也配置 deny 列表，明确禁止一些危险操作。

这样既不用每次确认那些安全的命令，又不会误操作真正危险的东西。

### 技巧 11：MCP 工具集成

Claude Code 会使用各种外部工具：通过 Slack MCP 搜索和发送 Slack 消息、用 BigQuery CLI 查询数据、从 Sentry 获取错误日志。这些 MCP 配置提交到 `.mcp.json`，团队共享。

MCP（Model Context Protocol）是让 Claude Code 连接外部服务的协议。通过 MCP，Claude 可以操作的范围大大扩展，不只是本地文件和命令。

Slack MCP 对团队协作场景有用：Claude 可以搜索 Slack 历史消息作为上下文，也可以把进度或结果发到指定频道。

我目前用得比较多的是 Playwright MCP，做浏览器自动化测试。Slack MCP 暂时没配，我的场景用不太上。

![image-20260106163757615](/media/202603/2026-03-07_1111330.09580139759742279.png)

如果你的工作流需要和 Slack、数据库、监控系统等外部服务交互，可以考虑配置对应的 MCP。

### 技巧 12：长任务的验证策略

对于耗时很长的任务，Boris 会用这几种方式确保质量：

(a) 在提示词里让 Claude 完成后用后台代理验证 (b) 用 Stop Hook 自动触发验证 (c) 用 ralph-wiggum 插件做持续监控

另外，在沙盒环境里他会用 `--permission-mode=dontAsk` 或 `--dangerously-skip-permissions`，让 Claude 不受打扰地运行。

这里的核心思路是：长任务运行过程中你不可能一直盯着，需要有机制在完成后自动验证，发现问题能自动修复或者通知你。

沙盒环境指的是隔离的测试环境（Docker、虚拟机等），在那里即使 Claude 出错也不会影响真实环境。所以可以用更宽松的权限设置，让 Claude 全速运行。

### 技巧 13：给 Claude 验证工作的方式

最后一个技巧 Boris 说是"最重要的"：给 Claude 一个验证工作的方式。如果 Claude 有这个反馈闭环，最终结果的质量可以提升 2-3 倍。

他举例说 Claude 用 Chrome 扩展测试每一个提交到 claude.ai 的改动：打开浏览器、测试 UI、迭代修复，直到代码正常工作。

不同场景验证方式不同：可能是跑一个 bash 命令、运行测试套件、在浏览器或手机模拟器里测试。关键是要有这个闭环。

这个技巧我觉得确实是最重要的。没有验证的话，Claude 写完就结束了，对不对不知道。有了验证，Claude 会自己检查、发现问题自己修，输出的质量有保障。

我写了一篇专门的文章讲验证策略：[验证策略完整指南](https://www.aigocode.com/docs/blog/verification)，里面有各种场景的验证方式和配置方法。

### 我的实践总结

把这 13 个技巧过了一遍，我最大的感受是 虽然每天都在用 Claude Code ，但是用好了这些技巧，效率还能进一步提高。

不是只用某一个功能，而是把 Hook、Subagent、Slash Commands、MCP、权限配置这些东西灵活组合，根据实际场景用起来，形成自动化的工作流。

几个印象深刻的点：

**团队思维**：CLAUDE.md、Slash Commands、权限配置、MCP 配置，这些都提交到 Git 和团队共享。个人的效率提升变成团队的知识资产。

**闭环验证**：不是写完就结束，而是写完要验证、发现问题要修复。Claude 越来越有工程师的意思了。

**分层自动化**：Slash Commands 解决命令级的重复、Hook 解决流程级的自动化、Subagent 解决任务级的专业化。每一层都在减少人工干预。

这些技巧单独看都不难，关键是形成习惯、组合使用。我打算接下来把这些逐步融入自己的工作流，看看实际效果如何。