Claude Code 创始人 Boris Cherny 的 13 个使用技巧完整解析
深入解析 Claude Code 创始人 Boris Cherny 分享的 13 个使用技巧，涵盖并行工作、Plan mode、Hooks、Subagents 等高效工作流。
前几天在 Twitter 上看到一个帖子，Claude Code 的创始人 Boris Cherny 分享了他自己使用 Claude Code 的方式。他说自己的配置"出人意料地简单"，因为 Claude Code 开箱即用效果就很好，所以他个人没有做太多定制。
不过看完他的 13 个技巧，我发现"简单"是相对的。他确实没有用什么黑科技，但他把 Claude Code 的各种功能组合起来用，形成了一套高效的工作流。这些技巧单独看都不难，组合起来效果很明显。
我把这 13 个技巧逐个研究了一遍，有些自己也实践了。这篇文章完整梳理一下，既是给大家的分享，也是自己的学习笔记。
技巧 1：并行运行 5 个 Claude#
Boris 说他在终端同时运行 5 个 Claude，用 tab 1-5 编号，用系统通知来知道哪个 Claude 需要输入。
这个做法的核心思路是并行处理。等一个 Claude 跑的时候，可以给另一个 Claude 布置任务。不用干等，时间利用率更高。
要让这个模式跑起来，关键是要有通知机制。不然开 5 个窗口，根本顾不过来哪个在等待输入，哪个还在执行中。Boris 提到用系统通知，具体实现可以用 Hook：Claude 等待输入时触发一个通知脚本。
这个场景我在 Hooks 指南 里详细写过，配置一个 Notification 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。
技巧 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模式。
Boris 说"一个好的计划是成功的一半"，我觉得确实如此。尤其是复杂任务，花几分钟讨论计划，能省很多后面改来改去的时间。
技巧 7：Slash Commands 一键化高频操作#
Boris 为每个"内循环"工作流创建了 Slash Commands，比如 /commit-push-pr 他每天要用几十次。这些命令提交到 Git，放在 .claude/commands/ 目录，团队共享。
Slash Commands 本质就是快捷提示词。把你经常说的话保存成一个命令，下次直接输入 /命令名 就行了，不用每次打一长串。
我自己也配置了几个常用命令：/review 做代码审查、/test 跑测试、/commit-push-pr 提交推送创建 PR。确实省了不少重复输入的时间。
这部分我写了一篇详细的教程，感兴趣可以看 Slash Commands 完整教程。
技巧 8：Subagents 自动化常见工作流#
Boris 经常用几个子代理：code-simplifier 在 Claude 完成后简化代码，verify-app 提供端到端测试指南。他把 Subagents 理解为"自动化大多数 PR 的常见工作流"。
Subagents 和 Slash Commands 的区别是：Slash Commands 共享主对话上下文，Subagents 有独立的上下文窗口，可以并行执行。
code-simplifier 这个代理的思路很有意思：Claude 写代码的时候关注功能实现，可能写得比较啰嗦；写完之后让专门的代理做一遍简化，让代码更简洁。
我参考他的思路创建了 code-simplifier、verify-work、verify-ui 三个代理。详细的配置和使用方式在 Subagents 完整指南 里。
技巧 9：PostToolUse Hook 自动格式化#
他们用 PostToolUse Hook 来格式化 Claude 生成的代码。Claude 大部分时候格式是对的，Hook 处理最后 10%，避免 CI 因为格式问题失败。
这个 Hook 在 Claude 每次写入或编辑文件后自动触发，运行格式化工具（比如 Prettier）。你不用每次手动跑格式化，也不用担心提交的代码格式不对。
配置方法是在 settings.json 里加一个 PostToolUse Hook，指定要监听的工具（Write、Edit、MultiEdit）和要执行的格式化命令。
详细的配置在 Hooks 完整指南 里有，包括完整的格式化脚本。
技巧 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 暂时没配，我的场景用不太上。
如果你的工作流需要和 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 会自己检查、发现问题自己修，输出的质量有保障。
我写了一篇专门的文章讲验证策略：验证策略完整指南，里面有各种场景的验证方式和配置方法。
我的实践总结#
把这 13 个技巧过了一遍，我最大的感受是 虽然每天都在用 Claude Code ，但是用好了这些技巧，效率还能进一步提高。
不是只用某一个功能，而是把 Hook、Subagent、Slash Commands、MCP、权限配置这些东西灵活组合，根据实际场景用起来，形成自动化的工作流。
几个印象深刻的点：
团队思维：CLAUDE.md、Slash Commands、权限配置、MCP 配置，这些都提交到 Git 和团队共享。个人的效率提升变成团队的知识资产。
闭环验证：不是写完就结束，而是写完要验证、发现问题要修复。Claude 越来越有工程师的意思了。
分层自动化：Slash Commands 解决命令级的重复、Hook 解决流程级的自动化、Subagent 解决任务级的专业化。每一层都在减少人工干预。
这些技巧单独看都不难，关键是形成习惯、组合使用。我打算接下来把这些逐步融入自己的工作流，看看实际效果如何。
相关教程#
这篇文章是一个完整的概述。具体的配置和使用方法，我写了 4 篇详细的教程：
感兴趣的可以按需查看。