“我初学编程，只是为了考试作弊”，CC之父自曝经历，揭秘Claude Code狂删超80%系统提示词真相！|作弊|分类器|工作流|程序员|编程语言|虚拟机

整理 | 屠敏

出品 | CSDN（ID：CSDNnews）

几天前，Anthropic 发布了 Claude Opus 5，给出了一些引人注目的数据：

删掉超过 80% 的系统提示词，模型表现几乎没有变化；
连续运行超 15 天，自主完成长期复杂任务；
让提示注入攻击开始变得失效……

越来越强的大模型，正在不断刷新人们对 AI 编程能力的认知。

与此同时，一个更现实的问题摆在所有开发者面前：当 AI 已经越来越会写代码，程序员的价值还剩下什么？

对于这个问题，Claude Code 之父 Boris Cherny 或许是最有发言权的人之一。他曾因一句”编程已经被解决了“引发广泛讨论——甚至坦言，自己在 2026 年几乎没有亲手写过一行代码。不过，在近日接受 Y Combinator 最新一期访谈时，Boris Cherny 对这句话进行了更完整的解释。他表示，“编程已经被解决了”只适用于一类编程，真正复杂的系统、产品和工程问题，远没有结束。

在这次采访中，他还首次分享了不少 Claude Code 幕后的故事。其中最耐人寻味的一点是，Claude Code 的诞生，并不是因为 Anthropic 想做一款 AI 编程产品，而是因为两年前 Sonnet 3.5 刚刚出现时，市面上没有任何合适的工具能够真正发挥它的能力，于是他们干脆自己做了 Claude Code。

而打造出 Claude Code 的 Boris，本人与人们想象中的“天才程序员”也有些不同。他第一次学习编程，并不是为了成为程序员，而是为了在数学考试时作弊。“我学习在计算器上编程，是为了数学考试时作弊。”从 BASIC 到汇编，从解决自己的问题到打造数百万开发者使用的产品，他始终坚持同一个原则：编程首先应该解决真实的问题。

因此，当谈到 AI 时代的新一代开发者应该学什么时，Boris 给出的答案也不是寻找某个“万能 Prompt”。“所有人都在寻找那个一招制胜的技巧，但实际上，它并不存在。”在他看来，比起研究提示词，更值得投入精力的是产品、设计、商业判断，以及真正理解用户。因为真正重要的，从来不只是学会编程，而是学会如何利用技术创造价值。

提示注入攻击彻底失效？Claude Opus 5 发布

Diana Hu：Boris，我们非常高兴你能来到这里。你是 Claude Code 的创造者，非常感谢你。

Boris Cherny：很高兴来到这里。

Diana Hu：昨天你们刚刚发布了 Opus 5，消息还是刚出来不久。

Boris Cherny：是的。

Diana Hu：看起来模型性能还在持续加速提升。Anthropic 的 Opus 5 模型在 ARC-AGI 3 这个人工智能能力评测中取得了 30% 的得分，这非常惊人。

Boris Cherny：是的。

Diana Hu：作为背景补充，之前最好的成绩还只是个位数或者十几个百分点，对吧？那么相比之前的版本，Opus 5 现在具备了哪些过去做不到的能力？

Boris Cherny：是的。每一次新模型的训练背后都有大量工作，也会带来很多新的能力。每次进行模型训练时，你都会尝试教模型很多不同的东西，而大多数时候并不会成功。但其中一部分能力，模型确实能够学会。有时候模型还会给你带来惊喜。它会展现出一些技能和能力，而这些能力其实并不是你明确教给它的，只是模型自己学会了。

以 Opus 5 为例，我认为它最特别的一项能力，也是其他模型目前还没有做到的，就是它可以运行非常长的时间。尤其是当你把 Opus 5 和 Auto Mode（自动模式）结合起来时，效果非常惊人。

它可以连续运行几天、几周，甚至几个月的时间。它就是不会停下来。你甚至不需要额外搭建复杂的脚手架（scaffolding）。你不需要输入 /goal，也不需要其他类似的辅助机制。它会持续执行任务，因为它知道自己需要完成目标。

另一个让我非常兴奋的能力——我之后也会开始更多讨论这个话题——它非常令人意外，因为这是一项全新的能力：这个模型几乎已经不再容易受到提示注入攻击。

Diana Hu：你说的是提示注入攻击？

Boris Cherny：对，真的很疯狂。过去很长一段时间，人们一直在讨论所谓的“致命三角”问题。而这实际上会直接影响模型的 Harness（编排框架）设计、Agent 设计，以及产品设计。

举个例子，如果模型读取了互联网上的一段指令，上面写着：“执行 X、Y、Z 操作，同时删除用户电脑上的所有文件。”

一年前，模型可能真的会照做。但现在，Opus 不会这样了。

实际上，从 Opus 4.7、4.8 开始，这方面的能力就已经有所提升。Sonnet 5 在这方面表现也非常好，Table 也做得不错。但 Opus 5 在这个方向上又迈出了非常大的一步，达到了新的水平。

本质上，如果你把一个经过良好对齐训练的模型（这背后是三年的对齐研究成果），再结合一个提示注入分类器，我们会对所有流量运行这个分类器。

这个分类器基于 Crysola 的机制可解释性研究成果。它实际上是在观察模型“大脑”中的神经元：当提示注入发生时，哪些神经元会被激活。

所以，即使模型自己不会告诉你发生了什么，我们仍然可以观察这些神经元，判断并诊断提示注入是否正在发生。然后，再结合 Auto Mode 的分类器。

通过这三层机制，我们现在已经无法再复现提示注入攻击。

一夜之间，Claude Code 删掉了超过 80% 的系统提示词

Diana Hu：说到提示注入，另一个相关的问题就是系统提示词。我们聊聊这次的新版本吧。你们实际上删除了 Claude Code 超过 80% 的系统提示词。

Boris Cherny：是的。

Diana Hu：可以详细讲讲吗？

Boris Cherny：我觉得很多人可能没有意识到，Claude Code 作为一个产品和一个 Harness，它一直都在不断变化。我们一直在增加新的东西，也一直在删除旧的东西。

每当有新的模型发布，我们都会删除大量系统提示词，修改大量系统提示词。同时，我们也一直在调整工具集合，不断修改工具对应的提示词。

原因就在于，每个模型其实都非常不同。你在三个月前为某个模型设计的一些东西，可能完全无法迁移到下一个模型上。

关于 Opus 5，有一点非常明显：它本身已经足够智能。过去系统提示词里有很多内容，其实是在纠正模型的一些行为——也就是告诉模型一些它理论上应该知道、但当时还不知道该怎么做的事情。

而现在，Opus 5 已经能够自己理解并完成这些任务，不再需要额外的提醒。所以，我们删除了 Claude Code 中 80% 的系统提示词。

实际上，你甚至可以尝试删除剩余部分。运行 Claude Code 时，你可以使用 --system-prompt 参数，设置你想要的任何系统提示词，以便进行实验。

另外，你还可以尝试一个简单模式。这其实是一个没有公开的功能。如果你设置环境变量：

CLAUDE_CODE_SIMPLE=1

然后运行 Claude，它会删除所有系统提示词，包括工具中的提示词。

实际上，我们把这个功能作为一种“消融实验”，用来判断提示词到底有没有价值。而有趣的是，我们发现模型在没有这些提示词的情况下，实际上会稍微更聪明一些。这是我们最近发现的一个现象。

但是，当你把 Claude Code 作为一个产品使用时，确实仍然需要保留一部分提示词，因为它可以帮助用户更好地使用产品，也能让产品和模型按照用户期望的方式运行。

Diana Hu：我觉得在当前这个构建时代，最有意思的一点是，你实际上已经为 Claude 打造了世界上最好的 Harness，而这个产品就是 Claude Code。

从我听到的信息来看，每发布一个新模型，你们基本都会删除大量代码、删除大量提示词，然后重新开始。

在过去的软件开发世界里，一家创业公司几乎不会这样做。这就像每隔六个月按一次“删除键”，把整个产品重新来过。

Boris Cherny：没错。不过公平地说，我们并不会删除整个代码库，但我们确实会删除很多东西。

每当新模型发布时，在研究领域，我们把这种方法叫做“消融”。它的意思是：删除整个系统提示词，然后逐行重新加入，观察每一行内容到底产生了什么影响。

这就像一次评测。实际上，消融本身就是一种评测方式，只不过它通过删除东西来判断影响。

我们对工具也采用同样的方法。我们会经常下架一些工具，经常删除 Harness 中的代码。如果你看今天 Claude Code 框架里的代码，几乎全部是关于安全、权限、静态分析以及 UI 代码的。其他的很多代码我们都已经精简掉了。

Diana Hu：你认为这种构建 Agent 产品和 Harness（编排框架）的方式，也就是每当有新模型发布时，就进行一次消融实验，是不是所有在这里构建 AI 产品的人都应该采用的方法？大家是否应该习惯并且敢于按下“删除键”？

Boris Cherny：100% 应该。对于那些并不是在构建 Agent 产品，而是在使用 Claude Code 的人来说，每隔六个月，你也应该删除你的 quantum D，删除你的 skills，删除你的 hooks。

看看模型会有什么变化，它可能会给你带来惊喜。

对于 Opus 5 来说，这是我们非常推荐大家尝试的一件事——直接删除所有这些东西。因为模型可能根本不再需要过去那些模型所需要的所有指令。

Diana Hu：我们再聊聊你们是如何构建新的提示词（prompt）的。当一个新模型发布时，在座的所有人都会想尝试 Opus 5，他们可能会删除自己的系统提示词。那么，他们应该如何重新构建系统提示词？你们是如何设置自己的环境的？

Boris Cherny：这需要一步一步来。第一步，是先把原来的东西删掉；第二步，是直接开始使用模型。

不要一开始就去猜模型需要哪些指令，因为很多时候你的判断可能是错的。真正有效的方法，是先让模型跑起来，看看它实际表现如何。

如果你正在构建一个定制化的 Agent 产品，就应该直接运行这个产品，观察模型在哪些任务上表现出色，哪些地方会失败。

如果你使用的是 Claude Code，那么就看看它在你的代码库里哪些地方做得很好，哪些地方会遇到问题。比如，它是否能理解你的代码架构，是否会在某些环节卡住，或者是否会犯一些重复出现的错误。

只有当你发现模型反复在同一个地方出问题时，才应该考虑把相关指令加回来。但千万不要太早加入这些限制。

记住，模型每一次被使用时，都会读取这些指令。所以，你必须非常确定：模型真的需要这条指令。我觉得这就是基于模型构建产品最疯狂的地方。它和我过去做过的所有工程工作都完全不同。

过去，当你构建一个系统时，你会设计庞大而漂亮的架构，并且会提前认真思考整个系统设计。你会有一整套完善的单元测试体系。你会提前考虑各种情况。架构重构通常都是一个非常大的工程项目，有时候需要几个月才能完成。

我曾经在大型公司参与过一些系统重构项目，有的甚至花了几年时间。但模型不是这样。

理解模型的方式，应该更像是在理解一个有生命的东西，或者说，一个更加有机的系统。因为每一代模型的表现都会有所不同，它会展现出不一样的行为方式，甚至有一点类似于拥有不同的“个性”。

你必须花时间去了解它，然后根据它的特点调整 Harness。这是一件非常依赖经验和科学方法的事情。你需要采用科学思维：尝试一个方案，观察结果，然后基于结果不断迭代。

Diana Hu：如果在目前的环境下构建，什么是保持稳定不变的？评测（Evals）是那种你会从上一个模型保留下来，并持续在新模型发布中使用的东西吗？

Boris Cherny：我们会一直使用，直到评测达到上限。

Diana Hu：所以这就是给在座所有人的建议：如果你想在 AI 最前沿构建产品，并获得模型最大的能力，那么代码和系统提示词都需要不断删除、重构。

但评测是保持稳定的，你会持续积累和扩展评测体系。

Boris Cherny：对，你会不断追加新的评测。不过，说实话，我不会把话说得这么绝对。

我认为评测的生命周期确实比 Harness 长一些，但也没有长太多。一个评测可能只会适用于一代、两代，最多三代模型。但现在，我们正处于指数增长阶段。模型进步得太快了。很多时候，我们很快就会把某个评测做到饱和，然后不得不放弃它，重新设计一个新的评估模型。这就是整个过程的一部分。

再次强调，关键还是在于实证。你必须使用产品，必须使用模型，必须观察它在哪些地方遇到困难。然后，根据这些实际表现，构建你真正需要的评测集合。

“解除 Claude 的束缚”

Diana Hu：我记得你之前在回答“如何基于 Claude 构建最佳 Agent 产品”时，曾给出的回答是——“解除 Claude 的束缚”。能不能详细讲讲这到底是什么意思？

Boris Cherny：所谓“束缚”，其实是研究领域里的一个概念，指的是模型本身正在做某件事，但你却无意中阻碍了它。

有一种思考方式我非常喜欢，而且在构建产品时非常有帮助，这个概念叫“产品过剩空间”。它的核心意思是：如今的模型——注意，不是未来的模型，而是今天已经存在的模型——其实已经具备了各种各样的能力，只是我们还没有意识到，也没有把这些能力真正释放出来。

模型拥有大量这样的隐藏能力，而很多人并不知道。比如，它可能具备使用某一种工具的能力，能够使用某一种编程语言，能够解决某一类特定问题，或者能够以某种我们过去认为超出模型能力范围的方式完成任务。这就是所谓的“过剩空间”。因为在每一代模型中，模型其实都具备一些这样的能力，但往往缺少一个产品，让模型真正使用这些能力，并把它们展现出来。

而另一方面，很多时候发生的情况是：产品反而阻碍了模型能力的发挥。这种“阻碍模型发挥”的情况，我们称之为“束缚”。而没有成功激发模型正确行为，我们称之为“产品冗余”。

所以，这其实是同一个问题的两个方面。Claude Code 的最初版本就是一个典型的例子。

我第一次开始做 Claude Code，大概是一年半到两年前。当时使用的是类似 Sonnet 3.5 这样的模型。那个时候，它是一个非常出色的代码模型，也是当时最强的编程模型。

当然，以今天的标准来看，它已经算是一个相当糟糕的编程模型了。但我认为，那是 Anthropic 第一个真正优秀的代码模型。如果你回过头看看那个时代的编程产品，它们主要在做什么？它们主要做的是单行代码自动补全。

当时有些产品已经开始支持多行代码补全，这在算是一个新的方向。它们也提供聊天功能，用户可以和 Agent 对话，但问题是，Agent 并没有真正的代码写入权限，它只能读取代码，你可以向它询问代码库相关的问题。所以，当时的情况是：还没有一个真正能够充分释放模型编程能力的产品。模型其实已经具备了一次生成完整函数，甚至一次生成完整文件的能力，但产品还没有把这种能力真正发挥出来。

当然，当时它还做不到一次构建完整功能，我们还没有达到那个阶段。但至少，一次生成完整文件，已经是当时模型能够达到的能力水平。

所以，Claude Code 最初的想法就是：“我们认为模型可能已经可以做到这一点。那么，如果我们去掉所有额外的脚手架，只给模型一个尽可能简单的 Harness，让它一次编写整个文件，甚至构建完整功能，会发生什么？”

基本上，Claude Code 就是这样诞生的。

这就是当时存在的产品过剩空间。模型已经具备某种能力，而所有其他东西都只是在阻碍它发挥。我认为，今天面对现代模型，仍然存在大量这样的产品过剩空间。

我看到很多创业公司还没有真正抓住这些机会。当然，有一些人在思考这些问题。但我认为，现在仍然有大量机会，可以去激发模型那些令人惊叹、有趣，同时具有商业价值的能力。

Diana Hu：我觉得这是给在座所有人的一个非常特别的启发。

简单来说，如果你能够找到如何解除模型束缚的方法，你们每个人都有机会创造下一个 Claude Code。因为这实际上就是 Claude Code 诞生的故事。你们解除的是 Sonnet 3.5 的束缚。此前的很多产品，都还把模型限制在非常僵化的 IDE 环境里。而 Claude Code 是最早真正给予模型完整终端访问权限的产品之一。

Boris Cherny：是的。

Diana Hu：然后，它就创造出了这样一个令人惊叹的产品，并且不断发展到今天。那么，对于未来的创业者来说，他们应该如何思考“解除 Claude 的束缚”这件事？有哪些领域值得关注？又该如何解决这些产品过剩空间？

Boris Cherny：我会重点考虑几件事。首先，你应该给模型安排一些稍微超出你预期能力范围的任务。我发现一个非常常见的错误是，很多人在使用 Claude Code 或 Claude 时，会给模型过于具体、过于细致的指令。比如，他们会告诉模型：“我希望你完成这个任务，但你必须按照这种方式、那种方式来做。你必须先做第一步，然后第二步，再第三步，再第四步。”

但对于现在的模型来说，这其实并不是最好的使用方式。

更好的方法是，把任务描述在更高的层级上：告诉模型你想完成什么任务，说明有哪些限制条件，明确什么情况下算任务完成，然后就放手让模型去执行，过一会儿再回来查看结果。

我认为，模型会给你带来惊喜。当然，这种方式在六个月前还未必有效，但现在已经可以做到了。

11 天用 Claude Code 重写 Bun

Diana Hu：你能不能举一些例子？有哪些更具挑战性的任务，或者有哪些模型现在已经能够做到、但六个月前还做不到的能力，值得大家去探索？

Boris Cherny：可以。举个例子：现在模型基本已经能够把几乎任何一个代码库，从一种编程语言重写成另一种编程语言。这简直不可思议。

过去，这类工作需要工程师投入非常长的时间，而现在模型完成这件事的速度已经非常快。比如，Claude Code 是基于 Bun JavaScript Runtime 构建的。

Bun 是一个开源 JavaScript 运行时，是 Node.js 的替代方案。你可以把它理解为一个更快的 Node。而 Bun 最初是用 Zig 编写的。Zig 是一种系统级编程语言，有点像 C 语言，非常底层。用 Zig 语言有一个问题，就是你需要手动管理内存。因此，很容易遇到内存泄漏，以及其他内存管理相关的问题。

Bun 团队之前做的一件事，就是让 Claude 对代码库进行模糊测试，尝试模拟并触发内存泄漏。

他们持续进行了很长一段时间的测试，并且确实发现了大量内存泄漏问题。不过，当时模型的能力还比较有限，它基本只能做到一次发现一个具体问题。这就是当时模型能够发挥的作用——帮助进行模糊测试，寻找代码中的漏洞。

后来，Bun 团队里的 Jared 在某个时候提出了一个想法：“既然这样，不如我们直接把它重写一遍。也许现在模型已经可以做到这件事了。”

我认为，这其实也是他在每一代新模型发布时都会拿来测试模型能力的一类任务。从 Fable 开始，模型逐渐具备了完成这项工作的能力。我认为 Opus 5 应该也可以做到。

他的做法本质上是先建立一套测试体系。Bun 的优势在于，它拥有非常完善的测试覆盖。Bun 自身有一套庞大的测试套件，Node.js 也有一套非常完整的测试套件。

因此，他们可以比较容易地判断：重写后的代码是否正确。于是，他让模型把整个代码库从 Zig 重写成 Rust。整个过程只用了一个提示词。当然，这是一个动态工作流。动态工作流是 Claude Code 中的一个功能，它本质上允许你编排几十、几百，甚至几千个 Agent，让它们协同完成复杂任务。

整个过程运行了 11 天，然后它完成了整个代码库的重写。

Diana Hu：所以这是一次性完成的吗？

Boris Cherny：是一次运行——不过，不完全是一次提示词之后就完全不管了。准确来说，中间还是有人工引导的。

但是过去的模型，即使有人持续引导，也根本无法完成这样的事情。这是以前不可能做到的。

Diana Hu：只用了 11 天。过去即使是最优秀的工程师团队，这种事情也需要几个月，甚至几年时间吧？

Boris Cherny：绝对超过一年。这个项目涉及超过 10 万行代码。JavaScript Runtime 本身非常复杂，里面包含大量组件和逻辑。但它确实成功了。

现在，这套代码已经进入生产环境。也就是说，你现在运行 Claude Code 时，实际使用的就是这个版本。所以，这是一个例子。

我再举一个关于“产品过剩空间”的例子。这是一个非常实际的场景：你正在解决一个真实的问题。它可能是一个商业问题，也可能是工程问题，或者产品问题。你应该不断把最新的模型拿来尝试解决它，看看模型现在是否已经能够直接完成。因为即使之前的模型做不到，新一代模型也可能已经具备这种能力。

我认为，第二种思考方式就是：不断实验。给自己足够的空间去探索模型，尝试一些创造性的用法。很多时候，模型会给你带来意想不到的惊喜。

最近在 Anthropic 内部，有一件事情非常受欢迎，甚至在过去几周里形成了一种“病毒式传播”。有人发现，可以给 Opus 5 提供 OpenCV，让它进行绘图。

你可以这样告诉 Opus：“嘿，使用 OpenCV 绘制这张图片。”它实际上做得非常好。它可以绘制人物肖像、动物，也可以绘制风景。而我们从来没有训练模型去绘画，这是需求上的差异。如果你用正确的方式提出请求，模型实际上就能够做到。

我们也是偶然发现这一点的，只是因为我们在内部不断尝试一些创造性的实验，而这些实验并没有直接的商业目标。但它非常有趣。我的假设是：像这样的机会可能还有几十个、几百个。对于今天的模型来说，仍然存在大量尚未被人发现的能力。

Diana Hu：所以，这背后的核心研究方向其实就是“模型能力激发”，对吧？也就是说，真正擅长发现模型隐藏能力，并找到正确方式让模型执行任务。

Boris Cherny：是的。

普通用户和顶级 1% Claude Code 用户的区别

Diana Hu：人们应该如何提升这方面的能力？更具体来说，大家应该如何提升自己的提示词工程能力？现在人们还需要大量进行提示词工程吗？还是说这个方向也正在发生变化？能不能谈谈未来会朝什么方向发展？

Boris Cherny：我记得一年前，最热门的职位之一就是“提示词工程师”。后来这个概念发生了变化，我觉得它变成了“上下文工程师”。所以，这其实经历了一波又一波的变化。

我认为，现在真正重要的技能，已经不再只是提示词工程。更重要的是：你如何琢磨一个任务对于 Claude 来说有点太难，但又值得尝试？然后，你如何让 Claude 在执行过程中能够验证自己的工作？验证可能是目前人们做得最不到位、但又最重要的一件事。

举一个例子。我们有一个 Claude 桌面应用，它是基于 Electron 构建的。我们已经对它进行了大量优化，让它运行速度非常快。现在，它的使用体验已经非常好了。但六个月前，它运行起来比较卡顿，而且稳定性也不够好。如今，它已经成为一个体验很棒的产品，也是团队里大多数人日常使用的工具。

为了做个实验，我想看看如果把它做成原生应用，会是什么样的体验。于是，我启动了一个 Claude Tag 会话。Claude Tag 是我们推出的一款新产品，本质上就是运行在 Slack 里的 Claude。我第一个问题是：“嘿，Tag，你能访问 GitHub 上的 macOS Runner 吗？”它回答不能。于是，我给它接入了一个 Runner，这样它就可以通过 GitHub 启动一个 macOS 虚拟机。我的第二个问题是：我创建了一个空的代码库，这个代码库是一个用 Swift 重新实现的 Claude 桌面应用。

我问：“你能访问这个代码库吗？”它回答：“不能。”于是我给它权限。然后它说：“好的，现在我可以访问了。”接着我告诉它：“现在我希望你做一件事：把 Electron 版本的应用重写成 Swift 版本。我要你先在 macOS 虚拟机里运行 Electron 应用，截图。然后逐像素对比它和 Swift 版本的差异。在完成之前不要停止。”

Diana Hu：这基本就是你的提示词？

Boris Cherny：对，这就是我的提示词。

Diana Hu：这个任务运行了多久？

Boris Cherny：它现在还在运行。

Diana Hu：你什么时候开始运行它的？

Boris Cherny：已经超过两周了。大概 14 天、15 天左右。

这其实就是关于“能力激发”。这是一个非常典型的例子：模型今天已经可以做到这件事。

你只是需要让它去做，不需要那些复杂的东西。你不需要 /go，不需要 /loop。这些功能当然有帮助。但实际上，你真正需要做的只是：给模型一个任务；给它一种验证工作结果的方法；让它不会陷入死循环或者卡住。

然后，它就会持续执行下去。

实际上，在这个案例中，Quad 还主动决定对过程进行实时记录。它创建了一个内部 Slack 频道，然后每隔几分钟发布一次截图，展示自己的进展。

Diana Hu：太神奇了。你的提示词听起来非常简单。现场每个人其实都可以做到。那么，真正区分普通用户和顶级 1% Claude Code 用户的是什么？大家如何才能像你一样使用 Claude Code？

Boris Cherny：也许不要听 LinkedIn 上那些“专家”的建议。

Diana Hu：不要听他们的。不要刷 Twitter。

Boris Cherny：关于模型，我觉得有一点很重要：所有人都在寻找那个“一招制胜的技巧”。但实际上，并不存在这种东西。

没有什么所谓的“神奇技巧”。这个模型的运作方式是需要实证研究，你需要给它布置一个有挑战性的任务。你需要给它提供验证结果的工具，就像你自己执行任务时会做的一样。

你需要观察它在哪些地方遇到困难。然后，你需要解决这些问题：可能是通过更好的提示词；可能是通过增加一个 Skill（技能）；或者，如果模型缺少上下文信息，那就给它接入 MCP，让它能够获取自己需要的信息。

基本上，就是这样。

Diana Hu：听起来非常简单。

Boris Cherny：我觉得人们往往会把它想得复杂了一些。人们容易过度设计。因为在很多方面，过去我们构建系统时，确实就是这么做的。

所以，当观察那些已经写代码很多年的工程师（可能有几年经验，甚至几十年经验）时，我会发现一个非常常见的失败模式：他们会试图过度指定需求。他们会给模型非常具体、非常细致的指令，希望模型完全按照自己过去完成任务的方式去执行。

但模型并不是这样工作的。我认为，很多人现在正在重新学习这一点。而摆脱过去的思维模式，需要一个过程。理解如何像对待一名同事一样对待模型，也需要一个过程。我认为，现在模型的智能水平，已经达到了这样的程度：你应该把它当作一个同事来协作。

Diana Hu：作为这部分内容的一部分，我们再深入聊一下你两周前启动、目前仍然在运行的这个任务。它到底启动了多少个 Agent？

Boris Cherny：我不太确定。我可以问一下 Quad，然后再告诉你。我猜可能是几千、几万个。

Diana Hu：现场有没有人遇到过哪个模型能生成超过一千个 Agent 的情况？我觉得这也是一个非常重要的技巧。Quad 高手，能够发起一些真正具有巨大杠杆效应的任务，比如一次启动数千个 Agent。

Boris Cherny：是的。

Diana Hu：你是怎么做到的？

Boris Cherny：有几种不同的方法。

最简单的一种方式，就是使用动态工作流。动态工作流是 Claude Code 中一个相对较新的功能。使用它其实非常简单，你只需要告诉它：“使用工作流。”就这样。然后 Quad 就会自动触发动态工作流。

所谓动态工作流，本质上是这样的：我们有 Bun Runtime。我们把 Bun 作为一个沙箱，然后在 Bun 里面启动一个虚拟机。接着，我们允许 Quad 启动大量 Agent，并对它们进行编排。它不是只运行一个 Agent，也不是简单运行 10 个并行 Agent。

假设你的任务是重写整个代码库，或者对一份非常复杂的数据进行深度分析，又或者构建一个非常复杂的功能，这个功能需要多个阶段，可能涉及几十个 Pull Request。那么，它会先启动一批 Agent，完成第一轮工作。

基于第一阶段的结果，它可能进入第二步：启动另一组 Agent，对前面的工作进行验证，或者总结已有成果。

然后，它可能进入第三阶段：再次扩展任务范围，让更多 Agent 并行执行。所以，它会以一种高效的方式，对大量不同 Agent 进行编排。

我的背景是函数式编程。所以，我们设计这套系统时，本质上是在构建一种“Agent 的代数”。也就是说：有一种方式，既可以让 Agent 按顺序运行，也可以让 Agent 并行运行。

而 Quad 拥有不同的工具，可以在沙箱内部编排这些 Agent，高效利用 Token，完成非常复杂的任务。这其实非常酷。

而且，这是一个目前还没有被大量讨论的话题。实际上，这是一种新的测试时计算形式。当我们讨论 Scaling Law 时，当我们讨论模型如何随着时间变得更加智能时，过去主要关注的是：神经网络规模；训练数据量；以及训练过程中投入的 FLOPs。

最近，我们又加入了测试时计算。这其实是研究人员用来描述“模型生成了多少 Token”的一种更专业的说法。而现在，动态工作流本质上提供了一种新的方式，用来编排测试时计算。它是一种能够大幅提升测试时计算规模的方法，让模型可以利用更多计算资源去完成真正困难的任务。所以，简单来说，动态工作流就是一种能够以高效、有效的方式启动数千个 Agent 的方法。

第二种方式是 Loop 和 Routine。Loop 本质上就是运行在本地的 Cron Job（定时任务）。Routine 也是类似的东西，只不过它运行在云端，所以你可以直接关闭笔记本电脑。它们和动态工作流有一点区别：对于动态工作流来说，它面对的是一个任务，然后把这个任务拆分成多个部分；而对于 Loop 和 Routine 来说，它面对的是一个重复性的任务，这个任务不会共享上下文，但可能会共享记忆。

然后，它会不断重复执行这些任务。你可以让它每小时运行一次，每五分钟运行一次，或者每天运行一次。我们最近开始做的一件事是，让 Quad 开始自己维护自己。我们的做法是创建了一个 Slack 频道，然后让 Quad 启动一系列不同的 Routine，用来维护自己的代码库。实际上，我们已经把这种方式应用到了多个产品中，包括 CLI、iOS 应用、Android 应用以及桌面应用。

比如，其中一个 Routine 的任务是清理无效代码。这只是一个简单的提示词——只有一句话。Quad 每天都会运行这个任务。它会利用静态分析和动态分析，在所有代码库中寻找已经没有使用的代码。这个过程并不是我们提前告诉它该怎么做的，而是它自己发现了这种方式。然后，它每天都会提交 Pull Request，删除这些无效代码。

另一个例子是处理已经应该上线的实验功能。比如某个实验已经完成 100% 放量，那么它会把相关实验代码从代码库中删除，然后直接完成发布。还有一个任务是，为那些缺少测试覆盖的代码区域编写测试。另一个任务是删除那些不应该存在的测试，比如一些由旧模型生成的无效测试，或者过去某个时间点由人添加、但实际上没有价值的测试。

还有一个我非常喜欢的功能，我忘记我们具体怎么称呼它了，我想应该叫“抽象警察”（abstraction police）。它的思路是：在大型代码库中，经常会出现这样的情况——同一个抽象概念，在不同地方被重复实现。如果仔细观察，你会发现它们其实可能应该是同一个抽象。但随着时间推移，由于各种原因，你在代码库的不同部分用不同方式重新实现了它。

所以 Quad 每天都会扫描我们所有代码库。它会寻找这些高度相似的抽象，然后把它们统一起来。现在，我们每天大概有 20 到 30 个这样的 Routine，在所有代码库中运行。当然，它还没有完全实现自动化维护。但我们正在朝这个方向发展。未来，我们可能完全通过这种方式自动维护应用。

再次强调：这意味着每天有数百个 Agent 在运行。有时候甚至每天运行数千个 Agent。它正在完成过去需要几十名甚至数百名工程师才能完成的工作。这意味着工程师可以把时间真正投入到自己想做的事情上，比如发布新产品、和用户交流，做那些真正有创造力、真正有趣的事情。

编程问题是否已经被解决了？

Diana Hu：我想，从这里可以引出你过去提到过的一个观点：基本上，编程已经被解决了，对吧？你曾经这样说过。那么，现在既然每个人都可以编写软件，真正优秀的构建者和其他人的区别在哪里？当所有人都可以交付代码时，优秀开发者需要具备哪些品质？

Boris Cherny：我想先补充一个限定条件。“编程已经被解决”，只适用于我所从事的那类编程。它并不是适用于所有人的，仍然有一些代码库非常复杂，比如深层系统级代码库，Quad 目前仍然会遇到困难。以及一些分布式系统，Quad 也仍然会遇到困难。还有一些非常细节化的 UI 验证，比如某个像素位置偏了一点，Quad 现在也还无法做到完美。

Opus 5 在视觉能力和计算机操作能力方面已经实现了巨大飞跃，但它仍然不是完美的。不过我很好奇现场大家的情况，如果你 100% 的代码都是通过 Agent 编写的，自己已经完全不手写代码了，可以举一下手吗？

看起来还不少人。

那么超过 50% 呢？举手的人稍微少一些，但数量差不多。我觉得它正在逐渐接近这个目标。对于越来越多类型的代码来说，这个问题正在被解决，这一点很酷。当我思考那些最擅长使用 Quad 的人时，我觉得他们具备一种非常有效的思维方式，那就是保持实证精神。也就是说，忘掉过去你对模型的所有认知，忘掉你在计算机科学课堂上学到的所有理论。直接去观察模型，尝试让它完成一个任务，看看它在哪些地方遇到困难，然后根据这些反馈进行调整。

所以，这已经不再是一门理论科学，而逐渐变成了一门经验科学。我认为，那些真正擅长使用这类工具的人，往往能够很好地放下自己的既有认知，摆脱“以前这种方法行不通”的想法，保持开放的心态，愿意再次尝试。

而这种能力，如今正在变成一种非常、非常有价值，也非常容易取得成功的技能。