别再写 Prompt，开始 Loop：Boris Cherny 方法论

所有人都在优化 Prompt，Boris Cherny 却彻底抛弃了这个概念

他打造了 Claude Code，带领着这个团队。但他使用这个工具的方式，与绝大多数人截然不同。没有秘密模型，没有奇特配置——他说这套工具开箱即用效果就很好，自己几乎没做任何特殊定制。真正的杠杆不在于工具本身，而在于他如何围绕这个工具重新安排整个工作流。

最颠覆人们认知的是：他的个人配置甚至显得有些无聊。五个终端标签页、一个文本文件、几个斜杠命令（slash commands），以及一条他反复强调的规则。把这些组合在一起，就让一名工程师发挥出了整支团队的效能。

以下就是这套方法论的真实全貌，整理自他 1 月份分享的工作流推文、Lenny's Podcast 与 Pragmatic Engineer 的专访，以及《财富》（Fortune）杂志的报道。没有空洞的理论，只有他的实操做法。

第一部分：他在指挥一支交响乐团，而不是在聊天

5 个本地窗口，10 个网页窗口，还有 1 个还在床上躺着时用手机启动的任务。

大多数人只运行一个 Claude 然后静静等待；Boris 运行的则是一个 Agent 蜂群。

在他的 MacBook 终端里常驻着 5 个 Claude Code 会话，标签页编号从 1 到 5，系统通知会提醒他哪一个会话需要人工输入。在此之上，还有 5 到 10 个会话在 claude.ai/code 网页端并行运行。

他可以把会话从本地无缝交接给网页端，又能用 --teleport 命令拉回本地；甚至每天清晨还没走到办公桌前，他就已经用 Claude iOS App 启动了新的任务。

绝大多数人都搞错了一个细节：他的每一个本地会话都拥有独立的 git 检出目录（checkout），而不是共享分支或 worktree。正是通过这种方式，5 个 Agent 才能在同一时间修改同一个代码库而互不干扰、互不踩脚。

图片说明：5 个本地 + 5-10 个网页 + 手机端。独立 git 检出目录。一个人指挥全局。

对于执行中的混乱，他非常坦诚：大约有 10% 到 20% 的会话会在撞上意外状况时被直接放弃。这完全没问题——当你同时运行 20 个会话时，扔掉 3 个的代价几乎为零。

而且他从不去挑选模型。所有任务统一使用带 Thinking（思考模式）的 Opus——哪怕它模型更大、单 Token 生成更慢。因为你需要干预它的次数更少，它在工具调用上表现更好，从整个任务的完成度来看它全面胜出。当你同时协调 10 个会话时，单个会话的速度就不再重要了——因为你永远不必坐在那里等待。

瓶颈不再是敲代码的速度，而是在各个正在写代码的 Agent 之间进行上下文切换的能力。

第二部分：复利工程——一个会自我学习的文本文件

每一个错误都会变成一条规则。规则被团队共享。整支团队每周都在变得更聪明。

Boris 的记忆系统只是一个提交到 Git 里的纯文本文件，名叫 CLAUDE.md。不是向量数据库，也不是微调模型，就是一个每个 Claude 会话在启动时都会读取的文件。

关键在于这是一个团队共享对象。他的整个团队每周都会多次向这个共享的 CLAUDE.md 追加写入。每当 Claude 做了不正确的事情，修正规则就会被写入该文件，确保同样的错误不再发生第二次。它包含了代码风格规范、设计指南、PR 模板以及各种需要避开的“雷区”。

“每当 Claude 做出错误的事情，我们就会把它添加到 CLAUDE.md 中，这样它下次就知道不能再这么做了。”

—— Boris Cherny

图片说明：人类发现一次问题。Claude 写入规则。未来所有 Session 自动规避。

他个人的 CLAUDE.md 长什么样？基本上只有两行字，指向团队共享的那个文件。团队的这个文件大小控制在 2,500 个 Token 左右——这是故意保持的精简状态，因为他非常清楚一个臃肿的记忆文件会有多么昂贵（后文会展开）。

最厉害的操作体现在 Code Review（代码审查）中。当 Boris 审阅队友的 PR 并发现不良模式（anti-pattern）时，他不仅是留下评语，而是通过 GitHub Action 在 PR 里 @ 标记 Claude，让 Claude 在同一个 PR 里把教训直接写入 CLAUDE.md。代码修复与规则更新随同一个 PR 一起提交。这就是人们所说的“复利工程”（Compound Engineering）：每合并一次代码，代码库本身就会变得更加智能。

第三部分：先规划，再放手

所谓的“一次性生成（One-shot）”是个谎言。制定计划本身才是核心工作。

当人们看到 Claude 尝试“一次性生成”某个功能却失败时，他们会归咎于模型；而 Boris 归咎于缺乏规划。

他的默认操作是进入 Plan 模式（按两次 Shift+Tab）。此时他还不让 Claude 动任何代码。他会在计划上与 Claude 来回磨合推敲，直到方案完全符合他脑中的构想。只有到了这一步，他才会切换到自动接受修改模式（auto-accept edits），让它全速运行。

“如果我的目标是提交一个 PR，我会使用 Plan 模式，与 Claude 来回沟通直到我对它的计划满意。从那时起，我再切换到自动接受修改模式，Claude 通常就能一次性成功交付。一份优秀的计划真的至关重要！”

—— Boris Cherny

图片说明：Plan 模式 -> 达成共识 -> 自动接受修改 -> 一次性成功。计划才是思考的阵地。

对大多数人而言，“一次性生成”失败的原因在于信息带宽不足。你只用短短几个词描述了一个复杂的特性，于是 Claude 构建出的东西自然和你脑中想的大相径庭。规划过程，就是在写下任何一行代码之前提高沟通带宽的方法。所谓的“神奇 One-shot”，不过是一份优质计划兑现成果的自然体现。

第四部分：将内环工作流转化为代码

任何他重复做过两次以上的事情，都会变成一条命令、一个 Subagent 或一个 Hook。

这正是那个看似“原生开箱即用”的配置悄然演变为一台精密机器的地方。Boris 不会为例行工作重复撰写 Prompt，他直接将其代码化。

他为每一个内环任务（inner-loop task）编写斜杠命令（Slash commands），并提交到 .claude/commands/ 目录中，以便整个团队以及 Claude 自身调用。他的主力工具是 /commit-push-pr，每天要运行几十次。它通过内联 Bash 预先计算 Git 状态，从而避免模型为了搞清楚当前状态而浪费一次往返对话。

用 Subagent（子 Agent）保护上下文。他主要依赖两个子 Agent：一个是负责在 Claude 完成编写后清理代码的 Code Simplifier，另一个是带有端到端测试详细指令的 Verify App agent。子 Agent 独立运行，只返回最终结果，从而将执行过程中的杂乱信息隔绝在主会话之外。

配置 PostToolUse Hook 来自动格式化每一次修改（如 bun run format）。Claude 生成的代码本身就已经很干净，而这个 Hook 负责处理最后 10% 的细节，确保不会因微不足道的格式问题破坏后续的 CI 构建。

用权限白名单替代冒险。他几乎从不使用 --dangerously-skip-permissions。相反，他通过 /permissions 将安全命令列入白名单（如 bun run build、bun run test 等），并将其提交到 .claude/settings.json 中与团队共享。所有人只需对安全默认设置达成一次共识即可。

其余工具全部通过 MCP（Model Context Protocol）接入。Claude 可以向 Slack 发消息、运行 BigQuery 分析数据、从 Sentry 提取错误日志——一切均通过 MCP 实现，且所有配置均托管于 Git。同时他也给出了警告：MCP 会膨胀你的上下文，并可能打开 Prompt 注入攻击的大门，因此在安装任何 MCP 之前，先让 Claude 对其进行安全审查。

图片说明：Slash commands、Subagents、Hooks、Permissions、MCP。例行工作不再靠 Prompt，而是化为基础设施。

第五部分：验证才是胜负的关键

这是他最为关键的一条建议，而且它与写 Prompt 没有任何关系。

如果你只能从 Boris 的工作方式中学到一件事，那就是：给模型一种检查自身工作的方法，它就会不断磨练迭代，直到把工作真正做好。

“Claude 会通过 Claude Chrome 扩展程序测试我提交给 claude.ai/code 的每一个修改。它会自动打开浏览器，测试 UI 交互，不断迭代演进，直到代码工作正常且 UX 体验良好。”

—— Boris Cherny

图片说明：缺乏检验 = Agent 自说自话。真实检验 = 质量提升 2-3 倍。

一个真实的反馈循环（Feedback Loop）——无论是测试套件、类型检查、构建流程、浏览器测试还是模拟器——都能将最终成果的质量提升 2 到 3 倍。如果没有它，你就没有真正的 Loop，而只是让一个 Agent 自己给自己批改作业，且每次都打满分。

对于长时运行的任务，他会实行多层验证：在主 Agent 完成时触发一个背景 Agent 检查成果；使用 Agent-stop Hook 作为确定性关卡；或者在完全无人值守的情况下运行自主循环插件。无论规模大小，核心原则完全一致——只有当现实的检验结果表明任务通过时，Loop 才会向前推进。

这种方式的回报体现在团队的时间分配上。因为验证过程已经内置在 Loop 内部运行，人类得以解放出来去完成机器依然无法替代的两件事：审阅（Review）与把舵方向（Steer）。当一名工程师打开 PR 时，代码本身就已经处于相当出色的状态。

第六部分：清醒而彻底地“Token 极客化”（Tokenmaxxing）

消耗更多的 Token，但绝不浪费在无意义的地方。

Boris 给企业的建议听起来甚至有些轻率，直到你听到后半句。

“刚开始时不要试图削减成本。给工程师提供尽可能多的 Token 预算。”

—— Boris Cherny

图片说明：最大化能带来能力的 Token 投入，砍掉因上下文臃肿和重复读取历史而浪费的 Token。

他称之为“Tokenmaxxing”（Token 极致化）。瓶颈从来都不是 Token 的成本，而是工程师学会高效使用它们的速度。限制 Token 用量，就会扼杀学习与进化的速度。此外，你拿 Claude Code 评估对比的对象，不应该是一个每月 20 美元的代码助手，而是完成同等工作所需的人工工程师成本。这才应当是参照基准。

然而，“增加投入”并不等同于“盲目挥霍”。在一次播客拆解中，Boris 详细解释了 Token 是如何在模型读到你的 Prompt 之前就被白白烧掉的——一大部分被臃肿的 CLAUDE.md 消耗，另一大部分花在了重复读取历史会话上。这正是为什么他团队的文件精炼在 2,500 个 Token，而他个人的文件只有区区两行。他将预算最大化投在能带来学习与改进的地方，而砍掉所有无意义的开销。

第七部分：坦诚的真相

这套方法无法解决的问题。

这一切并没有消除工程师的岗位，而是改变了工程师的位置。

Boris 有 10% 到 20% 的会话最终会被废弃。当“写代码”不再是瓶颈的那一刻，他的 Code Review（代码审查）便成为了新的瓶颈。此外，Agent 蜂群交付没有人手写过的代码越快，代码库里的实现与人类真正理解的内容之间的鸿沟就会越大。顺畅的工作流会在这种鸿沟上计收“复利”。到了你需要去调试一个全团队没有任何人真正读过的系统的那一天，所付出的代价将远超那些消耗掉的 Token。

两位工程师使用完全相同的配置，可能会得到截然相反的结果。一位用它在自己深刻理解的工作上提速狂奔；另一位则用它彻底放弃了对工作的理解。工具无法区分这二者，但你可以。

图片说明：同样的 5 个标签页，同样的 CLAUDE.md，同样的命令。一条路通往杠杆，另一条路通往沉沦。

Boris 不再手写代码，不再逐句发送 Prompt。但他从未停止规划、审阅与把舵——而这些，才是真正体现他个人价值的部分。

这就是这套方法论的精髓。不是追求更好的 Prompt，而是占据更好的位置：抽离打字磨炼，专注于价值判断。