↓

造 Claude 的人自己怎么用 Claude？Boris Cherny 的 10 条实战秘诀

·

你大概以为，Claude Code 的创造者一定有一套极其复杂的定制方案，各种花式插件、深度配置、秘技满屏。

结果 Boris Cherny 本人说了句大实话：

“我的设置出奇地朴素。Claude Code 开箱就挺好用的，我几乎不做定制。”

朴素归朴素，但他的用法一点都不简单。Boris 是 Anthropic 的工程师，Claude Code 就是他一手打造的。之前在 Meta 做了五年 Principal Engineer，写过一本《Programming TypeScript》。2026年初，他陆续在 X 和 Threads 上公开了自己和团队的完整工作流，还搭了个网站 howborisusesclaudecode.com 专门讲这事。

不是营销号搬运，不是产品演示，是真实的工作日常。

看完我发现，真正的效率差距不在配置，而在思路。

第一章：最大的解锁——同时跑15个Claude #

大多数人用 AI 是一条线：打开一个对话，给任务，等回复，再给下一个任务。

Boris 完全不是这种用法。

他同时开着 10 到 15 个 Claude 会话。终端里 5 个标签页，编号 1 到 5，每个跑一个独立任务。另外 5 到 10 个挂在 Claude 网页端。甚至早上出门前从手机上开几个会话，等到了电脑前再看结果。网页端的会话还能用 --teleport 命令拉回本地。

怎么管这么多会话？他用 git worktree 给每个会话创建独立的工作目录——文件隔离，上下文隔离，任务之间完全不污染。再用 iTerm2 的系统通知来跟踪——哪个会话完成了或需要输入，自动弹提醒。

他的原话：“The single biggest productivity unlock."（最大的生产力解锁。）

有跟进了的编辑说：“我只跑了三四个并行就已经回不去了。连这点程度的改变都让生产力完全不一样了。”

核心逻辑简单到有点反直觉：并行化胜过优化。与其花功夫让一个会话更聪明，不如多开几个。团队里有人给 worktree 起别名 za、zb、zc，一键切换。还有人专门留一个 worktree 只读日志跑 BigQuery 分析，不掺和编码任务。Boris 本人更喜欢直接用多个 git checkout 而不是 worktree，但核心一样——独立目录，独立上下文，互不干扰。

机制不重要，模式才重要。

第二章：卡住了？别硬推，重新规划 #

Plan Mode 是 Claude Code 里的规划模式，大多数人只在开始任务时用一下。Boris 的用法不一样。

他在任务执行到一半卡住时，会切回 Plan Mode 重新规划。不是硬着头皮继续推，而是停下来重新想。他的说法是：“当方向偏了就停下来，别在错路上狂奔。”

更有意思的是他团队成员的做法：让 Claude 写完计划后，再开一个独立的 Claude 会话，让它扮演"Staff Engineer"来审查这个计划。等于让 AI 自己当评审，用对抗性思维来找出方案漏洞。

Plan Mode 也可以用来做验证。不是只管规划实施步骤，验证环节同样值得先规划再执行。

第三章：让AI自己教自己 #

这一条是我觉得最意外的。

Boris 的习惯是，每次纠正 Claude 的错误之后，加一句：“更新你的 CLAUDE.md，让你不再犯这个错误。”

CLAUDE.md 是 Claude Code 的项目配置文件，记录项目规则、编码风格、技术栈信息。Boris 的团队共享一个 CLAUDE.md，所有人每周都在往里加内容。每次 Claude 犯错，就加一条规则，持续迭代。

Boris 的评价：“Claude 在给自己写规则这件事上出奇地擅长。”

本质上是让 AI 用自己的失败来训练自己。错了就写规则，规则积累到一定程度，后面的错误率肉眼可见地下降。有团队成员甚至给每个任务维护一个独立的笔记目录，CLAUDE.md 里直接指向这些笔记。每次做完 PR 就更新笔记，相当于给每个项目建了一本"踩坑手册”。

这是货真价实的复利效应——每犯一次错，下次就更不容易犯。日积月累下来，CLAUDE.md 就是整个团队和 AI 协作的知识资产。

第四章：重复两次的事，就该自动化 #

Boris 有个简单的判断标准：如果一个操作每天做超过一次，就把它变成 Skill。

Skill 是 Claude Code 的自定义技能模块，本质是一段可以复用的提示词模板加工具调用。他的团队搞了一堆实用的：

  • /techdebt——每次编码结束自动扫一遍，找出重复代码干掉
  • context dump——一键同步过去 7 天的 Slack、Google Drive、Asana 和 GitHub 内容到上下文
  • BigQuery 技能——直接在 Claude Code 里用自然语言写数据库查询

这些 Skill 全部提交到 git。新成员加入团队，立刻就能用上前辈打磨过的最佳工作流，零学习成本。

Boris 说他已经六个多月没手动写过 SQL 了。这个 BigQuery 技能的逻辑很简单：Claude 写查询语句，skill 执行查询，Claude 解读结果。你全程不用离开当前工作上下文。

同样的思路可以复制到任何有命令行或 API 的数据库上——PostgreSQL、SQLite、SQL Server 都行。核心不在于"Claude 懂 SQL"，而在于你可以待在同一个上下文里，让 Claude 处理翻译层。

第五章：给问题，别给方案 #

面对 Bug，Boris 的做法出人意料地简单。

他直接把 Slack 里的 bug 讨论线程贴给 Claude，然后只说一个字：“修。”

不解释怎么修。不拆步骤。不微操。

也可以说"去修失败的 CI 测试"或者"看看 Docker 日志里有什么异常"。Claude 处理分布式系统的日志噪声能力很强，能从一堆杂乱输出里发现规律。

他说：“信任 Claude 找到路径。给它问题，不要给解决方案。”

这是一种思维方式的转变：从"教AI做事"变成"给AI目标"。当你不再手把手告诉它怎么做，它经常能找到你想不到的路径。

第六章：把AI当同级，不是下属 #

Boris 团队有三句高频提示词，每句都像在挑战对方：

  1. “拷问我的改动，我通过你的测试之前不许提 PR。"——让 Claude 当你的代码审查员
  2. “向我证明这能工作。"——让 Claude 对比主分支和特性分支的差异，找出行为变化
  3. “基于你现在掌握的所有信息，废弃当前方案，实现一个优雅的。"——当 Claude 给了平庸的修复，强制它带着完整上下文重新来过

不是客客气气地说"请帮我看看”，而是直接上对抗。背后的哲学：把 Claude 当成一个需要说服的资深同事，不是听指令的助手。

还有一个有意思的细节：团队推荐用语音输入长提示词。macOS 上连按两次 fn 键开启语音听写。说话速度是打字的三倍，而且开口说话时你会自然地带入更多背景信息和上下文细节，提示词的质量明显提升。尤其在 Plan Mode 下用语音输入，效果最好。

第七章：Subagent保持主线程干净 #

团队用"使用 subagents"这句提示词来让 Claude 投入更多算力处理问题。

更深层的用法是把具体任务卸载给子代理，保持主会话的上下文窗口干净聚焦。上下文窗口是有限资源，塞太多不相关信息会拉低输出质量。

还有一个聪明的用法：把权限审查交给更强模型（比如 Opus）处理，让它扫描请求里有没有风险操作，安全的自动批准。相当于用一个更强的模型当安全门卫，不干主力活。

第八章：五条底层哲学 #

回顾 Boris 的全部分享，底层逻辑其实就五条：

  1. 并行化 > 优化——与其优化单个会话，不如多开几个并行跑
  2. Plan Mode 用于纠偏——不只是起步规划，更是卡住时的救生工具
  3. 让 AI 自我改进——用 CLAUDE.md 记录每次失败，错误率持续下降
  4. 技能复利增长——把重复操作固化为 Skill，团队共享，代代传承
  5. 挑战而非指令——把 AI 当同级来挑战，不给方案给问题

他的设置朴素，但纪律不朴素。工具人人都能用，差距在工作流。

Boris 在最开始说了一句挺值得琢磨的话：“没有一种正确的方式使用 Claude Code。我们故意把它做得很灵活，让你可以随便用、随便定制、随便折腾。”

所以别纠结"最佳实践”，找到适合自己的节奏就好。但如果你要选一条先试试，我建议从并行开始——多开两个会话，感受一下。

Claude Code 的创造者给我们的最大启示，或许不是某个具体技巧，而是这种态度：别追求最复杂的配置，追求最扎实的工作流。