Claude Code 的负责人 Boris Cherny 上周在 Meta 的 @Scale 大会上，把自己的工作流全摊开了。

数字很唬人：今年 1700 多个 PR，新增 40 万行代码，删掉 25 万行，从 3 月到现在烧掉 80 亿 tokens，全部由 Claude Code 生成。他去年 11 月那天卸载了 IDE，到现在每一行代码都不再手写，而且大部分是在手机上敲出来的。他自己的原话是：「六个月前你跟我说我会在手机上写代码，我会说你疯了。」

我刷到这条的时候，第一反应跟大多数人一样：我也得赶紧上 Loops、上 CoWork。

后来我把整场对话和 TechCrunch 的报道翻了一遍，发现这个反应错了。不是错在「想学」，是错在「学的对象」。大家都在记他用了哪些新工具，但他真正展示的，是一条工具底下的东西——一条瓶颈链。

Boris 用了一个程序员都懂的类比解释 Loops：源代码是语句，Agent 写代码是函数，那 Loops 就是高阶函数——Agent 去提示 Agent。他说这一步的跨度，和当初从手写代码到 Agent 一样大。

听起来像是又一个炫酷工具。但你把他后半段连起来看，会发现 Loops 只是一条更长线索上的一个点。

他画的那条线是这样的：

编码这个瓶颈解决了，下一个卡点就浮上来——代码审查。于是有了 Claude Code Review，到工程师看到 PR 的时候，98% 到 99% 的 bug 已经被自动修掉，人只需要判断「这个 PR 该不该存在」。

审查不卡了，再下一个是安全。Claude Security 每周扫一遍整个代码库自主修复，据他说 Opus 4.8 之后能抓到专业渗透测试都没发现的漏洞。

安全也顺了，最新冒出来的瓶颈是 CI 速度。他头天晚上用一句话启动了 Dynamic Workflows，让模型编排几百个子 Agent 去分析真实 CI 数据，跑了几小时、几百万 tokens，产出四个 PR，把 CI 时间砍掉一半。

编码、审查、安全、CI——你发现没有，每一节都是「上一个瓶颈被打掉之后，下一个自己冒出来」。Loops、Claude Security、Dynamic Workflows 这些名字，不是他先有了工具再去找用途，而是每撞到一个新瓶颈，顺手长出来的解法。

这才是主线。工具是副产物。

如果你只记住「他用了 Loops」，你抄到的是一节链条，还是别人那条链上的一节。

为什么说抄工具会出事？因为工具不挑人，但瓶颈挑人。

Boris 给的成本建议特别豪气：别省 token，先把 token 发给所有人去实验，包括 PM、设计师、数据科学家，找到有效用法再去后端优化。他有句话传得很广——「削减投资可能省 50%，但增大回报的空间是 1000% 甚至 10000%。」

这话在 Anthropic 内部成立。但你得看清他站的位置：Anthropic 自己卖 token，用的是自家最新模型，工程师全是顶配。token 烧得越多，对它越是双赢。这是一个特权样本。

把同样的姿势搬到普通公司，画风立刻变了。

Fortune 五月的报道里，微软砍掉了大部分 Claude Code 的 license，部分原因就是成本。Uber 的 CTO 说，公司 4 个月就烧光了 2026 全年的 AI 编码工具预算，COO 说这笔成本「越来越难证明合理」。Axios 提到一个更夸张的案例：某家公司没给员工的 Claude license 设上限，单月花掉差不多 5 亿美元。

更扎心的是 MIT 的那条结论：95% 的生成式 AI 试点，没能带来可衡量的财务回报。

同一套工具，Boris 用出人均 8 倍，别人用出 4 个月烧光预算。差的不是工具版本，是他们解决的根本不是同一个瓶颈。Anthropic 的瓶颈是「怎么把已经验证的高产出再放大」，而很多公司的真实状态是「我连这个 token 花在哪个有效用例上都说不清」。

后者照抄前者的「别省 token」，等于在一个还没找到出口的迷宫里踩满油门。

这里有个容易被忽略的细节。Boris 那句「先发 token 让大家实验」，其实暗含一个顺序：先找到有效用例，再在后端优化成本。 找用例在前，铺规模在后。

多数团队把顺序做反了：先把工具买进来、铺下去，再回头找「它到底能解决我什么问题」。先采购，后找瓶颈。

而瓶颈在哪，回报就在哪——这件事是有数据的。同一份企业调研里，AI 带来的生产力增益高度不均：代码审查 3.6 倍、客服 4.2 倍，但法务只有 1.4 倍、临床 1.2 倍，因为后两者的速度优势全被合规审查吃掉了。换句话说，瓶颈选对，再普通的工具也能放大；瓶颈选错，再贵的模型也只换来增量改进。

这正是我自己做内容系统时踩过的坑。

我一度以为草稿「AI 味重」是个文风问题，换个 prompt 就能解决。试了很多版措辞，没用。后来才想明白，AI 味重不是文风问题，是反馈缺失——系统不知道上一篇为什么被我打回，下一篇就接着犯同样的错。真正该补的不是更花哨的生成 prompt，是把「为什么不好」结构化地回流给模型。

工具（prompt 模板）一直在我手边，但我前面那阵子一直在错的瓶颈上使劲。判断错了瓶颈，加再多工具都是空转。

找瓶颈，从来不是「买哪个」，是「我现在最卡的那一环到底是什么」。这是判断题。

有人会反驳：想这么多干嘛，Boris 自己不也是先发 token、先动手实验出来的？纠结「我的瓶颈是什么」本身就是一种拖延，行业最佳实践摆在那，抄过来用起来自然就知道哪好用了。

这话对一半。

对个人探索，「先动手」确实是对的。一个人花点 token 把 Loops、把 Code Review 跑一跑，成本可控，撞一撞就有手感，这种探索我完全赞成。

但放到组织和预算层面，「先动手」和「先想清楚」之间，差的就是 Anthropic 和那家单月烧 5 亿的公司之间的距离。区别不在动不动手，在动手的对象是什么。

把第一笔预算花在「找出我们最卡的那个瓶颈」上，是对的。把第一笔预算花在「先把全套工具铺给所有人」上，大概率就是那 95% 没回报的试点之一。

动手，动在找瓶颈上，不是动在铺工具上。

把这场对话压成方法论，其实就三步，而且不依赖任何特定工具：

第一步，找出你现在最卡的那一环。 不是「行业在用什么」，是「我的流程里，哪一步在拖所有人后腿」。对 Boris 是编码，编码解决后是审查；对你可能完全是另一个东西。这一步想错，后面全错。

第二步，用最小成本验证「打掉它」真的有回报。 别一上来全员铺工具，先在那一个瓶颈上做小实验，确认 ROI 是 3.6 倍那种、不是 1.2 倍那种，再谈放大。

第三步，打掉它，然后立刻问「现在最卡的变成哪一环了」。 这才是 Boris 真正在示范的东西——不是某个工具，是「解决一个、立刻瞄准下一个」这个永不停的动作。瓶颈链会一直往前移：编码、审查、安全、CI，再往后他猜是创意和 GTM。

工具会过时，Loops 明年可能就有更强的形态。但「持续找到并打掉自己的下一个瓶颈」这个能力不会过时。

所以下次再看到某个大厂负责人晒出惊人的工作流，先别急着记他用了什么。先问一句：他真正在解决的瓶颈，和我现在最卡的那一环，是同一个吗？

不是同一个，他的工具清单对你就是噪音。是同一个，你也不该抄他的工具——你该抄的是他找到这个瓶颈的那套判断。