Boris Cherny：我们砍掉了 Claude Code 80% 的提示词

Interviewer我觉得在这个时代构建产品真的很有意思——你们基本上为 Claude 构建了世界上最强的 harness，那就是 Claude Code。据我所知，每次有新模型发布，你们基本上会把整个代码库、所有 prompt 都删掉，每次都从头开始。这在以前可不是创业公司会对产品做的事，因为相当于每六个月就把一切按删除键。

Boris没错，没错。公平地说，我们不会删掉整个代码库，但确实会删很多。所以每次有新模型，我们都会——在研究里这叫 ablation。意思是你会删掉整个 system prompt，然后逐行把它加回来，看看每一行的影响到底是什么。它有点像 eval，本质上就是一种通过删除东西来判断影响的 eval。对工具我们也是这么做的。我们一直在下线工具，一直在删 harness 里的代码。如果你去看现在 Claude Code harness 里的代码，几乎全都是关于安全、权限和 static analysis 的，还有一堆 UI 代码，实际上我们已经下线了很多其他代码了。

Interviewer你认为这种构建 agentic 产品和 harness 的方式——每次新模型发布都做 ablation——应该推广吗？在座所有做 AI 产品的人是不是都应该这么做？要够勇敢、敢于按下删除键。

Boris百分之百应该。而且对于那些不是在做 agentic 产品、但正在使用 Claude Code 的人来说，每六个月删掉你的 Claude MD，删掉你的 skills，删掉你的 hooks，看看模型会怎么做，它可能会给你惊喜。其实对于 Opus 5，我们真的推荐这么做：试试把这些东西都删掉，因为模型可能真的不再需要那些过去模型才需要的指令了。

Interviewer那我们来聊聊，这种情况下你们是怎么构建新 prompt 的。在座各位都想试试 Opus 5，他们都会删掉自己的 system prompt。那该怎么重建呢？你们是怎么搭建环境的？

Boris你得一步一步来。第一步是删，第二步是用。不要去猜模型需要什么样的指令，因为你可能猜不对。你要做的是运行它。如果你在构建一个 customer agent 类的产品，你就去跑这个产品，看看模型在哪些地方失败了，在哪些地方表现很好。

如果你在使用 Claude Code，你会想看看它在你的代码库中哪些地方表现好，也许又在架构之类的地方哪里会绊住。只有当你看到它反复在同一个地方栽跟头时，你才把它加回去。但你不想太早这么做，因为别忘了，每次你使用它时模型都会读取这条指令。所以你一定要确保模型确实需要这条指令。我觉得在模型之上做构建这件事多少有点疯狂。它和我以前做过的所有工程都太不一样了。过去你在系统之上搭建东西时，你会构建那些庞大而精美的系统，而且会预先认真思考系统设计。

你有一套庞大的单元测试。你什么都考虑周全，而且你知道，重构架构是个大工程，有时要花上几个月。我在大公司做过重构项目，要花好几年。但模型不是这样。呃，思考它的方式几乎就像它是一种活的生物，某种更有机的东西。每一代模型的表现都不同，性格也略有差异。你必须花时间去了解它，然后据此调整框架。而且我觉得这非常像一种经验性的、有点科学味道的事情。你必须采取非常科学的思维方式：先尝试，观察结果，再据此迭代。

：如果你现在正在这个领域做构建，那么什么东西是稳定的？Eval 是你从之前的模型保留下来的东西，并在每一次新模型发布时继续使用它们吗？

：我们会一直保留，直到 eval 触及上限。

：所以这算是给大家的一个窍门。代码和 system prompt，如果你想在最前沿做构建、让模型拥有最强能力，你得删掉这些，但 eval 是恒定的，基本上要不断往里面追加。

：是的，你要不断追加。实际情况是，呃，说实话，我甚至不会把话说得这么绝对。我认为 eval 比框架活得稍微久一点，但也久不到哪去。一个 eval 可能存活一到三代模型，但如今，你知道，我们正处在一个指数级的阶段。模型进步太快了，很多时候我们刚把 eval 跑饱和，就得扔掉它，再设计一个新的 eval。这就是流程的一部分。再说一次，关键在于经验实证。你必须去用产品，必须去用模型，必须去看它在哪挣扎，然后据此构建你的 eval 集合。

：我记得你描述过该如何在 Claude 之上构建最出色的 agentic 产品时，用过一个说法，这个概念叫做给 Claude 解除束缚，也就是 unhobbling Claude。能多讲讲这是什么意思吗？

：是的，hobbling 指的是在研究中，模型正在做某事，而你却挡了它的路。有一种思考方式我很喜欢，在产品构建中非常有用。呃，它叫做 product overhang。这个概念是说，如今的模型——不是未来的模型，就是今天的模型——已经能够做各种各样我们尚未意识到的事情。模型有很多这样的能力，人们还没有发现。比如使用某种特定工具、使用某种特定语言、解决某种特定问题，或者以某种特定方式做事，而这些我们原本以为超出了模型的能力范围。

呃，这就存在一种 overhang。因为在每一代模型中，模型都能做到这些事，但往往没有一款产品能让模型去做，让它展现出这种能力。而另一方面，经常发生的情况是产品反而碍事。这种碍事，我们称之为 hobbling。而没能从模型中激发出正确行为，我们称之为 product overhang。所以这就像是同一枚硬币的两面。

其中一个例子就是最初的 Claude Code。当我刚开始做这个项目时，大概是——呃，你知道——一年半到两年前左右。那时候用的是 Sonnet 3.5。在当时，那是一款非常了不起的编程模型，可以说是当时最好的编程模型。按现在的标准看，它可能相当糟糕了。但我认为那是 Anthropic 构建的第一款伟大的编程模型。那时候，如果你看看市面上的编程产品，它们都在做什么？它们在做单行自动补全。有时做多行自动补全，那还是个挺新的概念。

呃，它们也在做聊天，你可以和 agent 对话，但它没有写入权限，你只能读，可以询问代码库的情况。所以当时的感觉是，并没有哪款产品真正激发出模型一次性写整个函数、整个文件的能力。当时还没到一次性做整个功能的程度，我们还没走到那一步，但整个文件应该是可以的。那就是当时的能力水平。所以 Claude Code 的想法是：行，我们觉得模型大概能做到这个。如果我们去掉所有脚手架，只给模型最简洁的框架，让它能一次性写整个文件、构建整个功能，会怎么样？

呃，大概就是这么回事。这就是当时的产品能力悬置。模型明明有能力做某事，但所有东西都在挡它的路。

我认为，如今的现代模型存在大量的 product overhang，而我却还没看到初创公司去捕捉这些机会。我知道有些人在思考这些问题，但目前仍有巨大的机会去激发模型的这些行为，它们非常惊人、有趣，而且具有商业价值。

：我认为这对在座各位来说都是一个特别的洞见。基本上，只要你们能想清楚如何解除对模型的束缚，你们每个人都能创造出下一个 Claude Code，因为这本质上就是 Claude Code 的诞生故事。你们给 Sonnet 3.5 解除了束缚，因为之前所有的迭代都让模型在 IDE 里显得非常僵化。而 Claude Code 是最早让模型获得完整终端访问权限的产品之一。

：是的。

：那么，我们来聊聊有哪些领域，以及在场的未来创始人应该如何思考解除对 Claude 的束缚、解决这种 product overhang？

：有几点我会去考虑。第一，你应该给模型布置一些比你认为它能力范围稍难一点的任务。我看到一个非常普遍的错误是，人们在使用 Claude Code、在使用 Claude 时，给出的指令过于具体。他们会说：“我要你做这件事，但你要按这种方式、这种方式、这种方式去做。你必须先做一，再做二，再做三，再做四。” 对现代模型来说，这真的不是正确的做法。你应该把层级放高一点。你要描述任务，要描述护栏，要描述退出标准，然后就放手让模型自己去发挥。过一会儿再回来看。我觉得它会给你带来惊喜。再说一次，这在六个月前是行不通的，但今天确实有效。

：你能举一些例子吗？哪些有挑战性的任务或能力是人们现在应该去探索的，而且是它在六个月前还做不到的？

：可以。这么说吧，其中一个例子是，模型现在基本上可以把任何代码库从一种语言重写为另一种语言。

这简直有点疯狂。这类工作如果让工程师来做，原本需要花上非常长的时间，而现在模型处理起来却相当快。

举个例子，Cloud Code 是基于 Bun JavaScript runtime 构建的。这是一个开源的 JavaScript runtime，是 Node.js 的替代品，相当于一个更快的 Node。

Bun 是用 Zig 编写的。Zig 是一种系统编程语言，有点像 C，非常底层。

C 和 Zig 的一个问题是必须手动管理内存，因此很容易遇到内存泄漏以及其他内存管理问题。

因此，Bun 团队一直在做的一件事就是让 Claude 对代码库进行 fuzz，试图模拟并触发内存泄漏，而且他们已经做了很长时间。

他们发现了很多内存泄漏，但基本上是一次处理一个 case。当时模型的能力也就限于做这种 fuzzing。

后来团队里的 Jared 说：“要不我们干脆重写吧，也许模型能搞定。”

我觉得这是他每推出一代新模型都会拿来测试的难题之一。从 Fable 开始，模型逐渐能够完成这个任务了。

我认为 Opus 5 也能做到。他所做的基本上是定义了一个测试套件。

Bun 的好处在于它的测试非常充分。Bun 本身有一个庞大的测试套件，Node.js 也有一个庞大的测试套件，所以很容易判断你是否做对了。

他让模型把代码从 Zig 重写成 Rust。只用了一个 prompt。这是一个 dynamic workflow。

dynamic workflows 是 Claude Code 的一项功能，本质上可以让你协调几十个、几百个、几千个 agents 来高效地完成工作。

它运行了 11 天，重写了整个代码库。

这是一次性完成的吗？

它是一……不，不是一次性完成的，但中间有人工引导。有人工引导。

但之前的模型做不到这件事，即使有人工引导也做不到。

11 天？天哪。这在过去即使是最顶尖的工程师也要花好几个月，甚至几年吧？

肯定超过一年。

是啊。

对，超过一年。这大概有 10 多万行代码。JavaScript runtime 非常复杂，里面有很多东西。

而且它确实能跑。现在已经投入生产了。你现在运行 Claude Code 时，背后用的就是这个。

这是一个例子。我再讲第二个，关于 product overhang。

这是一个很实际的用例：你正在解决一个问题，可能是业务问题、工程问题或产品问题。你应该持续用最新的模型去试，看看它能不能直接搞定。

因为即使之前的模型做不到，新的模型也许可以。

我觉得第二种思路是去做实验。给自己自由去玩转模型，做一些有创意的事情。它经常会给你带来惊喜。

最近几周在 Anthropic 内部很火、几乎病毒式传播的一件事是，有人发现你可以给 Opus 5 用 OpenCV。

哦。

你可以让它画画。你可以对 Opus 说：“嘿，用 OpenCV 画出这张图像。”

它其实画得很好。它能画肖像、动物、风景。

我们并没有训练模型画画。这就像是 solicitation gap。如果你用正确的方式去问它，它就能做到。

我们是偶然发现这一点的，纯粹是边玩边尝试一些有创意、并没有直接商业应用的东西。但这很有意思。

我的假设是，如今的模型可能还有几十个、几百个类似的能力尚未被人发现。

这方面的一个重要研究领域基本上就是 model elicitation，对吧？就是变得非常擅长发掘这些能力，并引导模型去做正确的事，对吗？

是的。

人们怎样才能在这方面变得更强？具体来说，人们怎样才能更擅长 prompt engineering？人们还需要做大量的 prompt engineering 吗？还是说情况也在变化？跟我们讲讲这个领域的发展方向。

是啊，我记得大概一年前，最火的招聘岗位之一是 prompt engineer。后来变了，我觉得变成了 context engineer。就是这样一波一波的。

我觉得这些头衔会来来去去。如今的技能重心不再是 prompt engineering，而是更多在于如何给 Claude 布置一个看起来有点太难的任务。

然后如何让它能够在过程中验证自己的工作？我认为验证可能是人们最没有做对、或者说实际上最重要的一件事。

举个例子，我们有一个 Claude 的桌面应用，是用 Electron 构建的。我们把它优化得很快，现在体验相当棒。六个月前它还又慢又不太稳定，现在已经非常好了。

团队大部分人都在用这个。不过作为实验，我想看看如果换成原生应用会是什么感觉。

于是我开了一个 Claude tag session。Claude tag 是我们的新产品，本质上就是 Claude 在 Slack 里运行。

我的第一个问题是：“嘿 Slack，你能访问 GitHub 上的 Mac OS runner 吗？”它说不能。

于是我接入了一个 runner，这样它就能通过 GitHub 启动一台 Mac 虚拟机。

然后我的第二个问题是，我创建了一个空的代码库，是把原来的 Claude 桌面应用用 Swift 重写了一遍。

我问：“你能访问这个代码库吗？”它说不能。然后我给了它权限，我说：“好的，太好了。现在我能访问了。”

然后我说：“好的，现在我要你做的是，把 Electron 应用用 Swift 重写一遍。

我要你在 Mac 虚拟机里运行 Electron 应用，截图，然后逐像素地与 Swift 版本对比，没完成之前不要停。”

这基本上就是你的 prompt？

对，这就是我的 prompt。

这个任务运行了多久？

还在跑。

你什么时候启动的？

已经稍微超过两周了，大概 14、15 天的样子。

是啊，所以我不知道现场有没有人让 Claude 运行过超过两周的任务。如果有的话，请举手。

哦。

好吧，有一些人。

这其实是关于 hallucination 的一个例子。这真的是那种模型今天已经能做到，你只是需要让它去做的案例。

你不需要那些花哨的功能。不需要 slash goal，不需要 slash loop。这些有帮助，但本质上你只需要给模型布置任务，给它一种验证工作产出的方式，这样它就不会卡住，然后它就会一直运行下去。

实际上在这个案例中，Claude 还决定做 live blog。它在内部创建了一个 Slack 频道，每隔几分钟就发布一张进度截图。

哇。这个 prompt 听起来如此简单。我是说，在座的每个人都能做到。那么，是什么让这里的人能成为最顶尖的 1% Claude 用户呢？人们怎样才能学会像 Boris 那样使用 Claude？

也许，别听 LinkedIn 上那些 influencer 的。

别听他们的，也别看 Twitter。

Speaker A关于模型，有一点是：我觉得大家都在寻找某种一招制胜的奇技淫巧。但那种东西不存在，根本没有。模型的运作方式是你必须从经验出发去摸索。你得给它一个足够难的任务；你得给它验证工作的工具，就像你自己做这项任务时一样；你得观察它在哪儿遇到了困难，然后想办法解决——要么通过更好的 prompting，要么通过某种 skill，要么如果模型缺少上下文，就给它一个 MCP，让它能拉取所需的上下文。大概就是这样。

Speaker B听起来很简单。

Speaker A我觉得大家有点想得太复杂了。容易过度工程化。因为在过去我们搭建系统的时候，很多时候不得不那样做。所以当我看到那些写代码写了很久、甚至写了几十年工程师，一个非常典型的失败模式就是试图过度指定、过度细化，想让模型完全按照你本人的方式去执行任务。但模型根本不是这样运作的。不过我觉得很多人正在慢慢摒弃这种想法，这需要一段适应的过程。而且你也要慢慢摸索该如何把这个东西当成同事来对待。我觉得它现在的智能水平就是这样。

Speaker B顺着这个说，我们来深入聊聊那个还在跑的任务。两周前你启动了它——我想就是两周前吧——它派生出了多少个 agent？

Speaker A我也不确定，我可以去问 Bod，然后再告诉你。我猜是几千、几万个吧。

Speaker B几千个。现场有没有人给运行中的模型下过 prompt，让它派生出超过一千个 agent 的？没有？我觉得这是另一个窍门：最擅长用 Claude 的用户，能够发起真正给你带来巨大杠杆效应的任务，比如派出几千个 agent。

Speaker A是的。

Speaker B这是怎么做到的？

Speaker A有几种不同的方式。最简单的是 dynamic workflows。在 Claude code 里，这是个相当新的功能。你只需要说“use a workflow”就行了。然后 Claude 就会触发 dynamic workflow。dynamic workflow 的本质是，我们有 Bun runtime，用 Bun 作为 sandbox，然后在 Bun 里启动一个 virtual machine，让 Claude 启动大量 agent 并对它们进行编排。

它不会只跑一个 agent，也不会只跑 10 个并行 agent。比如说，任务可能是重写整个代码库，或者对一些非常复杂的数据做深入分析，又或者构建一个非常复杂、需要多个阶段、可能几十个 pull request 才能完成的功能。这时候它会先启动一批 agent 做第一遍处理；基于此，第二步可能会再启动一批 agent 来验证成果，或者做总结；然后可能还有第三阶段，再次 fan out。所以它会高效地编排一大批不同的 agent。

我的背景是函数式编程，所以我们设计这套系统时，本质上是在构建一种 agent 的 algebra：有按顺序运行 agent 的方式，也有并行运行 agent 的方式。Claude 有不同的工具来在 sandbox 里编排这些 agent，从而高效使用 token，完成极其复杂的工作。这挺酷的，而且没怎么被报道过。这其实是一种新的 test time compute 形式。我们谈到 scaling law 以及模型随时间变得更智能时，historically 这取决于 neural net 的大小、训练数据量，以及训练时投入的 FLOPs。

而最近我们又增加了 test time compute。用研究人员的话说，这其实就是个花哨的说法，指的是模型生成了多少 token。而现在 dynamic workflows 本质上是一种编排 test time compute 的新方式，是一种把 test time compute 的量级真正、真正拉高的新途径，用来完成非常困难的任务。说了这么多，这就是一种能够高效且富有成效地启动数千个 agent 的方法。

第二种方式是 loops and routines。Loop 本质上是一个运行在本地 Claude 上的 cron job，而 routine 则是运行在云端 Claude 上的同类东西。所以你可以合上笔记本。这跟 dynamic workflow 略有不同：dynamic workflow 是一个任务，你把它拆成多个块；而 loops and routines 是一个重复性的任务，上下文不共享，但可能共享记忆。

你可以反复执行，比如每 5 分钟、每小时、每天一次。我们现在开始做的是让 Claude 自己维护自己的代码库。做法是我们有一个 Slack channel，让 Claude 启动一堆不同的 routines 来维护自己的代码库。我们实际上对 CLI、iOS app、Android app、desktop app 都这么做了。举个例子，其中一个 routine 是清理死代码。就一个 prompt，一句话。

Claude 每天运行它，会在所有代码库里通过静态和动态分析寻找死代码——我们没教它怎么做，它自己摸索出来的。然后每天会提一个 pull request 去清理死代码。另一个例子是发布应该上线的实验：实验已经全量上线了，它就从代码库里删掉实验代码，直接 ship 出去。还有一个是给代码库里需要测试覆盖的区域写测试；以及删掉那些没必要存在的测试，因为你知道，有些测试可能是旧模型或者以前的人加的，没什么用。

我特别喜欢的一个是……我忘了我们叫它什么，好像叫 abstraction police。意思是，在一个大型代码库里，经常会出现同一种抽象在多个地方存在，如果你仔细看看，其实它们应该是同一个抽象，但随着时间推移，出于各种原因，你在代码库的不同部分用不同方式重新实现了它。所以 Claude 每天都会遍历我们所有的代码库，找出这些几乎重复的抽象，然后把它们统一起来。现在我们每天大概有 20 到 30 个这样的 routines，在所有代码库里运行。

还没完全做到，但我们正走在通过这种方式完全自动化维护我们应用的道路上。而且这又是每天运行几百个 agent，有时甚至几千个 agent。这相当于过去可能需要几十甚至上百个工程师才能完成的工作。这意味着工程师们可以去做他们真正想做的事：发布新产品、和用户交流、做真正有趣的事。

Speaker B我想由此可以得出一个很好的结论，你过去也提到过，基本上 coding 已经解决了，对吧？你提过这个。现在我很好奇，既然实际上每个人都能写软件了，是什么让顶尖的 builder 与众不同？当所有人都能 ship code 的时候，真正重要的素质是什么？

Speaker A我有一点要补充。Coding 对于我做的那种 coding 来说已经解决了，但对所有人来说还没有。你知道，仍然有一些非常底层的系统级代码库，Claude 在里面还是会遇到困难。

在分布式系统方面，Quad 仍然有些吃力。还有一些非常细碎的 UI 验证工作，比如某个元素差了几个像素之类的，Quad 仍然不够完美。Opus 5 在视觉和计算机使用能力上是一次巨大飞跃，但仍不够完美。不过，我其实很好奇在座的各位，如果你 100% 的代码都是用 agent 写的，自己不再手写任何代码，请举手。已经很不错了。那超过 50% 的呢？举手的人稍微少一点，可能差不多。所以我觉得，这项技术正在逐步接近，越来越接近解决更多类型的代码问题。

这很酷。当我思考最擅长使用 Quad 的人时，我觉得有一种心态非常有效，那就是注重实证。忘掉你过去学过的所有关于旧模型的知识，忘掉你在课堂上学到的所有计算机科学理论。观察模型，尝试完成一项任务，看看它在哪些地方吃力，然后据此调整。所以这很大程度上已经变成了一门实证科学，而不是理论科学。我认为那些真正擅长这一点的人，那些擅长忘记自己的先验假设、放下以前行不通的想法、愿意再次尝试的人，这种技能现在非常非常成功。

现在，鉴于我们谈到的所有内容，如果这里有正在学习 CS 的学生，而且你是在 AI agent 编程时代之前学会编程的，那么学生还应该用传统方式、硬啃的方式去学些什么呢？

对我来说，我是通过实践学习计算机科学的。我通过自学编程来解决问题。每当我这样做时，都是为了解决我遇到的某个具体问题。所以我最初其实是在 TI-83 计算器上学习编程的。那是初中时候的事了，后来我还真的在网上写了一篇关于 TI-83 计算器编程的指南。现在还在互联网的某个角落挂着呢。那是 BASIC 语言，我的第一门语言。我学习在计算器上编程，就是为了能在数学考试中作弊，从而取得更好的成绩。

所以这关乎一些实用性的东西，你知道，对一个初中生来说，那大概是我能想到最实用的事情了。最后我取得了好成绩，然后我弄了一根串口线，把程序传给同学们，他们也取得了很好的成绩。后来数学变得有点难了，已经不再是能用 BASIC 解决的了。于是我就从那种用 BASIC 写的代数求解器，过渡到了必须解决更难的问题。一旦我们学到微积分，我就得学习 assembly，这样才能写出更好的求解器，以便在微积分考试中更好地作弊。

所以对我来说，编程一直是非常实用的。我想我对在校学生的建议一直是：不要只学计算机科学。这确实在智力上引人入胜，了解它也真的很有意思，但要学会如何应用它。而这往往关乎创办公司、打造产品、培养自己的设计感、培养商业意识、学习如何做数据科学、学习如何与用户交流。还有其他所有这些技能，当你把它们与计算机科学和工程结合起来时，那才是真正非常有价值的地方。所以这些才是我仍会亲自动手去学的硬技能。

那么，如果我理解并总结一下，先从为自己做想要的东西开始，然后再进阶去做人们想要的东西。

是的。

我们还有最后一个特别公告要告诉大家。你还有什么想说的吗？

是的，嗯，今天在座的各位，你们将获得 Max 20X。[欢呼]

相当不错。

所以，请在你们的邮件里查找兑换码。我非常期待看到你们会做出什么。

我们会发邮件的。

[欢呼]

所以，我很好奇。这个房间里应该有人在构建某种希望能运行数月、动用数千个 agent 的东西，既然你们现在有了这样的账户。那么，Forrest，非常感谢你。

谢谢。