创造Claude Code的Boris，他自己怎么用的？13条心法全公开
嗨，我是ALSKai，让我们一起用AI做点有趣的事。🌿
今天想介绍一下Claude Code之父，Boris Cherny，他自己是怎么使用Claude Code的。
他的简介只有一行：「Claude Code @anthropicai」
他说很多人问他自己怎么用Claude Code，所以他决定公开自己的配置。
然后他自己补了一句，所有人都没料到的话：
「"My setup might be surprisingly vanilla."」
"出奇地普通。"
这条推文，8M浏览量。
「先说他说的"普通"有多不普通」
Boris描述的第一条心法："我在终端里同时跑5个Claude。每个Tab编号1-5，用系统通知告诉我哪个需要回应。"（我的第一反应：诶！该不会和我一样是ADHD吧）不止如此。他在claude.ai/code上另外再跑5-10个Claude，和本地并行。本地5个，网页最多10个，同时最多「15个会话在跑」。
模型用的是Opus 4.5 + thinking。（现在已经是Opus 4.6了hhhhh）
他的理由只有一句话："虽然它比Sonnet慢，但它更善于使用工具，需要纠偏的次数更少，最终反而更快。"要么不动，动则惊人。
「这13条心法，我把它分成三层」
读完所有推文，我发现这13条不是随机的建议，它背后有一个清晰的架构。
「第一层：运行环境」
「心法1——终端里跑5个并行Claude」
5个终端Tab，编号1到5，系统通知调度。哪个Claude需要输入，通知提醒你去回应，其余的继续跑。
这不是"多开"。这是把Claude Code当成一支团队来管理，而不是把它当成一个工具来使用。你是调度员，不是操作工。
「心法2——网页端再开5-10个」
除了本地终端，Boris还在claude.ai/code上并行跑5-10个会话。本地任务和网页任务同时推进，互相不干扰。
有时候他会把本地的会话"移交"给网页端继续跑，用&符号在后台挂起，或者直接在Chrome里手动接力。
（同时管理15个Claude会话，他说这叫普通...）
「心法3——模型选Opus 4.5 + thinking」
这是13条里挺反直觉的一条。
Opus 4.5比Sonnet更大、更慢、更贵。常规思路是：为了效率，选更快的模型。
Boris的逻辑反过来：Opus 4.5更善于使用工具，走错方向的次数更少，省下来的纠偏时间，远超它本身的速度损耗。
慢模型，快结果。Thinking模式让Claude先想清楚再动手，一步到位比来回纠错划算得多。
「第二层：团队记忆」
这是13条里，我认为含金量最高的一层。（最近在团队协作中学习到这一点了，开发的速度真的快很多
「心法4——全团队共享一个CLAUDE.md」
Boris的团队有一个CLAUDE.md文件，存在Git里，全员可以提交更新。
任何时候Claude做了错误的事，就往里面加一条规则。下次Claude进入这个项目，自动遵守。错误发生一次，规则更新一次，下次不再犯。
CLAUDE.md是什么？就像"团队手册"，只不过读者不是新员工，是Claude。
截图里他们的CLAUDE.md写着：开发工作流的规范，用bun不用npm，typecheck→test→lint的顺序，提PR前必须跑哪些检查。每一条都来自某一次Claude犯过的错，或者某一次团队踩过的坑。
「心法5——在PR里@claude，顺手更新CLAUDE.md」
代码审查时，Boris会直接在同事的PR评论里写：
@claude add to CLAUDE.md to never use enums, always prefer literal unions
Claude收到之后，39秒内完成：读取当前CLAUDE.md → 更新规则 → 提交commit。
CLAUDE.md的更新，作为PR的一部分一起合并进去。
这个做法的妙处在于：「每一次代码审查，都是一次给Claude"立规矩"的机会。」 团队越用越默契，Claude越来越懂这个项目的规范。
「第三层：工作流精髓」
「心法6——先进Plan Mode，再切执行模式」
开始新任务，先按Shift+Tab两次，进入Plan Mode。
在计划模式里，Claude只思考，不执行。Boris会和它来回讨论，把任务拆解清楚，直到对计划满意为止。然后切换到auto-accept模式，让Claude一口气跑完。
他说：「一个好的计划，通常能1-shot完成。」
计划模式就像立项评审。需求没说清楚就开始动工，反复返工才是真正的慢。
「心法7——把每天重复的工作流做成Slash Commands」
Boris的团队有一个自定义命令：/commit-push-pr。
一条命令，Claude自动完成commit、push、开PR三件事。命令存在.claude/commands/目录里，人可以调用，Claude自己也可以调用。
他说，凡是每天要做很多次的"内循环"，都值得做成命令。省去重复描述，Claude也能标准化地执行，不会因为每次prompt写法不同而行为不一致。
「心法8——常备几个固定的Subagents」
Boris有几个常驻的子智能体，放在.claude/agents/目录里：
「code-simplifier」：Claude写完代码后，交给它做减法，把复杂的实现简化 「verify-app」：端对端测试验收，有详细的测试指引 「build-validator」：构建验证 「oncall-guide」：值班指南
Subagents和Slash Commands的思路一样：把重复的"内循环"固化成可调用的模块，不要每次都重新描述。
「心法9——用PostToolUse Hook自动格式化代码」
每次Claude写完或修改文件，自动触发一个Hook：bun run format || true。
处理的是最后10%的问题——Claude生成的代码格式基本没问题，但Hook保证了CI环节不会出现格式报错。
自动触发，不需要人记得，不会有遗漏。
「心法10——用/permissions预授权，不用dangerously-skip」
Boris不用--dangerously-skip-permissions（这个参数会直接跳过所有权限检查）。
他的做法是：用/permissions命令，把他确认安全的常用bash命令逐条预授权。截图里列了20多条：bun run build、bun run test、bun run typecheck、find、cc……
Claude执行这些命令时不再弹权限确认，其余不在名单里的命令依然会问。
效率和安全都有，而不是为了省事全开。
现在有Auto-mode了，也是往前走了一大步了，在保证安全的前提下不需要人去批准操作。
「心法11——Claude Code接入全套工具」
Boris说："它帮我搜索并发布Slack消息，跑BigQuery查询回答数据分析问题，从Sentry抓错误日志。"
具体实现：Slack MCP的配置存在.mcp.json里，团队共享。就像CLAUDE.md是Claude的行为规范，.mcp.json是Claude的工具接入表。
http就像你打开一个网页去用别人的服务；stdio就像你在本地装了一个软件。Boris用的是http类型，配置极简，一个URL搞定。
「心法12——长任务不用人盯，自动通知」
截图里有一行让我停下来看了很久：
Reticulating... (1d 2h 47m · ↓ 2.4m tokens · thinking)
一个任务，跑了「1天2小时47分钟」，消耗了「240万tokens」，还在thinking。（过分了吧喂！
对于这种长任务，Boris有三种处理方式：
(a) 让Claude任务完成后自己调用background agent做验证； (b) 用agent Stop Hook，更确定性地在任务结束时触发检查； (c) 用ralph-wiggum插件，跑完发通知。
核心思路一样：「任务跑多久，人都不需要盯着。完成了自动通知，出错了自动处理。」
「心法13——给Claude一个验证自己工作的方式」
这是最后一条，也是Boris认为最重要的一条。
"这可能是从Claude Code里得到好结果，最重要的事。如果Claude有这个反馈闭环，最终成果质量会提升2-3倍。"
他的做法：Claude Code测试他提交的每一行代码。每次修改，自动跑测试验证，不依赖人工检查。
没有反馈闭环的Claude，就像没有测试的代码。你不知道它对不对，它也不知道。
「读完我想到了什么」
13条心法，让我印象最深的不是哪个具体技巧，而是Boris对Claude Code整体的定位：
「把Claude Code当成"一支需要管理的团队"，不是当一个工具用。」
CLAUDE.md是团队规章。Slash Commands是标准作业流程。Subagents是各司其职的成员。Plan Mode是立项前的需求评审。Feedback Loop是最终的质检体系。
一个人创造了这个工具，然后用它建了一套完整的组织体系。
回到开头那句话：「"My setup might be surprisingly vanilla."」
vanilla的意思，不是"没什么特别"。是清晰，克制，无多余依赖。
就像好的代码。
我是ALSKai，让我们一起用AI做点有趣的事。🌿