内蒙古股票配资
2024 年，Boris Cherny 加入 Anthropic 时，AI 编程产品大多还停留在代码补全和对话问答阶段。模型已经能够写出完整的函数和文件，但产品通常只允许它在编辑器里提出建议，很少真正赋予它读取代码库、修改文件和调用终端的能力。
Boris 决定试试另一种做法：尽量拿掉复杂的限制，让模型直接进入真实的开发环境。这个最初的实验，后来发展成了 Claude Code。加入 Anthropic 之前，他曾在 Meta 工作近七年，成长为首席工程师，负责 Instagram 的服务端架构、开发基础设施和代码质量；他也是技术书籍《Programming TypeScript》的作者。
如今，作为 Claude Code 的创造者和负责人，Boris 正在尝试把 AI 编程推向新的阶段：让模型连续运行数周，独立重写大型代码库，调度数千个 Agent，并逐步接管软件维护工作。
在 YC 的这场对谈中，他分享了正在重新定义行业的问题：当模型进步越来越快，过去的产品设计是否反而成了限制？开发者应该如何释放模型尚未被发现的能力？当编程本身逐渐被解决，真正重要的又会是什么？
以下是他的主要观点：
1. Opus 5 已经从完成任务走向持续工作。配合 Auto Mode，它可以连续运行数天、数周甚至数月，不需要复杂的循环指令和脚手架，也能围绕目标不断推进。
2. Prompt Injection 可能正在从根本性障碍变成可控问题。通过模型对齐、注入检测器与 Auto Mode classifier 三层防护，Anthropic 已经很难再复现针对 Opus 5 的有效提示词注入攻击。
3. 模型越聪明，System Prompt 反而应该越短。Claude Code 为 Opus 5 删除了超过 80% 的 System Prompt；在部分消融实验中，去掉提示词后的模型甚至表现得更聪明。
4. AI 产品需要不断做减法。每一代模型发布后，开发者都应该重新审视 prompts、skills、hooks 和工具，只有当模型反复在同一个地方失败时，才把相应的约束加回来。
5. 一批 AI 创业机会藏在 Product Overhang 里。模型已经具备大量尚未被产品释放的能力，真正的机会不是继续堆叠工作流，而是拿掉妨碍模型发挥的设计，让潜在能力变成可用、可收费的产品。
6. Prompt Engineering 的重点正在从“教模型怎么做”转向“让模型验证结果”。好的任务只需要交代目标、约束与完成标准，再提供测试、截图或运行环境，让模型能够判断自己是否做对。
7. Agent 的杠杆开始来自规模化协作。dynamic Workflows 可以编排数百乃至数千个 Agent；Anthropic 已经让数十个 routines 每天自动清理代码、补充测试、统一抽象，逐步走向应用维护自动化。
8. 对越来越多的软件开发任务而言，编程正在接近被解决。真正拉开构建者差距的，将不再只是写代码的能力，而是提出问题、设计产品、理解用户、判断商业价值，以及敢于重新测试那些过去被认为“不可能”的事情。
Opus 5的与众不同：能连续运行数周，且不再受Prompt Injection影响
Diana Hu：好的，Boris，我们非常高兴今天能邀请到你——Claude Code的创造者。谢谢你。
Boris Cherny：很高兴来到这里。
Diana Hu：刚刚发布的消息——你们昨天才上线了Opus 5。
Diana Hu：而且看起来，模型性能还在持续加速。你们把ARC-AGI 3的成绩提升到了30%，这太不可思议了。
Diana Hu：给大家一个背景参考，在此之前，最好的成绩还只是个位数或者十几个百分点。那么，现在Opus 5能做到哪些以前做不到、或者之前版本做不到的事情？
Boris Cherny：每一个新模型背后都有很多工作，也会加入很多新的能力，我们会训练模型，让它学会完成各种各样的事情。每次进行模型训练时，你都会尝试教给模型大量不同的东西，但绝大多数时候其实都不会奏效。不过，其中有一部分能力，模型确实能够学会。
有时候，它还会让你感到意外。它会表现出一些技能和能力，而这些东西其实并不是你真正教给它的，但它就是自己学会了。以Opus 5为例，有一项我认为其他模型都还没有做到的能力，就是它可以持续运行非常长的时间。尤其是当你把Opus 5和Auto Mode结合起来时，效果简直不可思议。它可以连续运行几天、几周，甚至几个月的时间，而且就是不会停下来。你甚至不需要使用scaffolding（脚手架机制）。也就是说，你不需要调用/goal，也不需要其他那些东西。它会一直做下去，因为它知道自己需要完成这个任务。
另外还有一件让我非常兴奋的事情——它之所以令人惊讶，是因为这是一项非常新的能力：这个模型似乎已经不再容易受到prompt injection的影响了。
Diana Hu：也就是说，它不再容易受到prompt injection的攻击了。
Boris Cherny：太不可思议了。人们已经讨论这个lethal trifecta很长时间了（ZP注：致命三要素，指Agent同时具备访问不可信内容、访问敏感数据、执行外部操作等能力组合时，会带来严重的prompt injection风险）。而这实际上会对harness design、Agent design和product design都产生很大的影响。因为假设模型在互联网上读到了一条指令，比如“执行X、Y、Z，然后把用户电脑上的所有东西也都删除”。如果放在一年前，模型可能就真的直接照做了。但如今，Opus不会这么做了。实际上，从Opus 4.7、4.8开始就是这样了。Sonnet 5在这方面一直表现得相当不错，Table也做得相当好。但Opus 5在这方面又达到了一个全新的前沿水平。
所以，本质上，如果你把一个经过良好alignment的模型——也就是说，这背后是我们三年左右的alignment研究——和一个prompt injection classifier结合起来，而我们会对所有流量运行这个classifier。它的工作原理是基于Crysola在mechanistic interpretability（机制可解释性）方面的研究。具体来说，我们实际上是在观察模型”大脑”中的神经元：当prompt injection发生时，哪些神经元会被激活。所以，模型甚至不会告诉你发生了什么，但我们实际上可以看到这些神经元，并据此判断和诊断prompt injection正在发生。然后，再把它和Auto Mode classifier结合起来。有了这三层防护，我们现在已经无法再演示出prompt injection的效果了。
为什么删掉了80%的System Prompt
Diana Hu：说到prompt injection，硬币的另一面就是现在的system prompt。我们来聊聊这次的新版本。你们实际上把Claude Code的system prompt删除了超过80%。
Diana Hu：再多给我们讲讲这件事。
Boris Cherny：我觉得很多人可能没有意识到，Claude Code无论作为一个产品，还是作为一个harness，其实一直都在变化。我们一直在增加东西，也一直在删除东西。
每次有新模型发布，我们都会删除一大批system prompt，也会修改其中很大一部分内容。我们一直在调整工具集，也一直在修改工具所使用的prompts。原因就在于，每个模型都非常不一样。所以，你三个月前针对某个模型做的一些东西，到了下一个模型上，可能完全无法迁移过去。
所以，Opus 5的一个特点就是，它真的非常聪明。system prompt里有很多内容，原本是在纠正模型的一些行为——这些行为本来是模型应该自己知道怎么做的，但当时它并不知道。现在Opus 5自己就能做到了。所以，我们删除了80%的system prompt。
实际上，你甚至可以尝试把剩下的部分也删掉。当你运行Claude Code时，可以直接使用–system-prompt，然后设置你自己想要的system prompt，如果你想进行实验的话。另外，你还可以尝试simple mode。这实际上是一个没有公开文档说明的功能。如果你设置CLAUDE_CODE_SIMPLE=1这样的环境变量，然后运行Claude，它就会删除所有system prompt，包括工具中的system prompt。
实际上，我们会把这个功能当作一种ablation（消融实验），用来判断：这些prompt到底有没有用？有意思的是，我们发现，在没有这些prompt的情况下，模型实际上反而会稍微更聪明一点。这是我们一直观察到的现象。但是，当你把Claude Code作为一个产品来使用时，你确实还是希望保留其中一部分prompt，因为这些prompt能帮助你更好地使用这个产品，也能帮助产品和模型按照你作为用户实际使用它时所期望的方式来运行。
Diana Hu：我觉得，在如今这个“构建”的时代，有一件事情特别有意思：基本上，你们已经为Claude打造出了世界上最好的harness，也就是Claude Code。按我听到的意思，每发布一个新模型，你们基本上都会把整个代码库大量删掉，把prompt大量删掉，然后每次都从头开始。在过去的世界里，一家创业公司不会对自己的产品这么做。就好像每隔六个月，就把所有东西全部按下删除键一样。
Boris Cherny：没错。不过公平地说，我们并不会把整个代码库全部删除，但确实会删掉很多东西。每次有新模型发布，在研究领域，我们把这个过程叫作ablation。具体来说，就是把整个system prompt删除，然后再逐行把它加回来，以判断每一行单独产生的影响。这就像做一个eval，你可以对它进行评估。Ablation本质上就是一种eval，只不过你通过删除东西来判断它所产生的影响。
对工具，我们也会做同样的事情。我们一直在unship工具，也一直在删除harness里的代码。如果你看看今天Claude Code的harness里还剩下的代码，几乎全部都是围绕安全性、权限和静态分析的。还有一大部分是UI代码。而实际上，其他很多代码我们已经unship掉了。
敢于按下删除键：如何重建System Prompt
Diana Hu：你觉得这种构建Agentic产品和harness的方式——也就是每次有新模型发布，就进行一次ablation——是不是在座所有正在构建AI产品的人都应该这么做？都应该习惯于、也敢于按下删除键？
Boris Cherny：100%。对于那些不是在构建Agentic产品、而是在使用Claude Code的人，我也建议：每隔六个月，就把你的quantum D、你的skills、你的hooks都删掉（ZP注：结合上下文，”quantum D”应指Claude Code中用户自定义的某项配置）。看看模型会怎么表现，它可能会让你大吃一惊。对于Opus 5，我们确实非常建议这么做——就是试着把这些东西全部删掉，因为模型可能已经不再需要过去那些模型所需要的全部指令了。
Diana Hu：我们再聊聊你们是怎么构建这个新的prompt的。每次有新模型发布，在座的每个人肯定都会想试试Opus 5，然后他们会把自己的system prompt删除掉。那么，他们应该如何重新构建system prompt？你们是怎么搭建自己的环境的？
Boris Cherny：一点一点来。第一步是删除。下一步是使用它。你不应该去猜模型需要什么指令，因为你可能根本无法准确预测。你真正应该做的是让它运行起来。如果你正在构建一个定制的Agentic产品，那就运行这个产品。观察它在哪些地方会出问题，哪些地方做得很好。如果你在使用Claude Code，那就看看它在哪些地方能很好地处理你的代码库，或者它可能在哪些地方会在架构上卡住，又或者在其他什么地方出现问题。
只有当你发现它反复在同一个地方出问题时，你才应该把相应的指令加回来。但不要太早这么做。要记住，模型每次使用时都会读到这条指令。你真的要确保模型确实需要这条指令。
我觉得，这就是在模型之上构建产品最疯狂的地方。它和我过去做过的所有工程都如此不同。过去，当你基于系统进行构建时，你会搭建庞大而精巧的系统，并且会在一开始就认真思考整个系统的设计。你会有一整套完善的单元测试，会把所有事情都考虑进去。而重新架构是一项很大的工程。有时候需要几个月。我曾经在大公司参与过产品的重新架构，甚至需要好几年。
但模型不是这样的。你几乎可以把它看成一种有生命的东西，一种更加有机的存在。每一代模型的行为都会有所不同。它会有稍微不同的性格特征。你必须花时间去了解它，然后根据它的特点调整harness。这在很大程度上是一件经验性的、科学性的事情。你必须用科学家的思维方式来对待它：尝试一些东西，观察结果，然后根据结果不断迭代。
Diana Hu：你现在是在这样一个不断变化的世界里进行构建，那么究竟什么东西会保持稳定？eval是不是你们会从之前的模型中保留下来，然后在每次新模型发布时继续使用？
Boris Cherny：在我们把这个eval的性能和覆盖范围做到饱和之前，我们会一直保留它。
Diana Hu：所以，这就是给大家的建议：代码和system prompt——如果你想站在技术最前沿进行构建，并让模型发挥最大的能力，就必须删除这些东西。但eval是相对稳定的，你基本上会不断往里面追加。
Boris Cherny：对，你会不断追加。不过实际情况是——说实话，我甚至不会把话说到这么绝对。我认为，eval的生命周期确实会比harness稍微长一点，但也没有长太多。一个eval可能会存在一代、两代、三代模型。但如今我们处在指数增长阶段，模型提升得太快了。很多时候，我们很快就会把一个eval做到饱和，然后不得不把它丢掉，再重新设计一个新的eval。这本身就是整个过程的一部分。归根结底，还是要以经验和实际观察为基础。你必须使用产品，必须使用模型，必须观察它在哪些地方表现吃力。然后根据这些观察，去构建你应该拥有的eval set。
Product overhang与Unhobbling Claude：模型那另一半还没被释放的能力
Diana Hu：我想，我听你描述过一个用来解释“如何基于Claude构建最好的Agentic产品“的说法，就是unhobbling Claude。能不能再多给我们讲讲，这究竟是什么意思？
Boris Cherny：对。hobbling这个概念在研究领域里，指的是：模型本身正在做某件事情，而你却在从中阻碍它。有一种思考这个问题的方式我非常喜欢。它在构建产品时特别有用，这个概念叫product overhang（ZP注：模型已经具备某种能力，但现有产品没有把这种能力释放出来，形成的能力积压）。
它的核心思想是：模型能够用我们今天的模型——不是未来的模型，而是现在就已经存在的模型——做到各种各样的事情，而我们还没有意识到这些能力。模型拥有很多这样的能力，但人们并不知道。比如，它可能有能力使用某个特定的工具、使用某种特定的语言、解决某一类特定的问题，或者以某种特定的方式完成任务，而我们原本以为这些事情已经超出了模型的能力范围。
之所以会出现这种overhang，是因为在每一代模型中，模型其实都具备这些能力，但往往没有一个产品能够让模型真正做到这些事情，也没有一个产品能够让它把这些能力展现出来。反过来，很多时候发生的事情是，产品本身反而挡住了模型。这种”挡住模型”的现象，我们称之为hobbling；而产品没有把模型正确的行为能力激发出来，我们称之为product overhang。所以，这其实是同一件事情的两个方面。
一个例子就是最初版本的Claude Code。我刚开始做它的时候，大概是一年半到两年前，差不多是那个时间。那时候是Sonnet 3.5。当时，那是一个非常出色的coding model，是当时最好的coding model。按照今天的标准来看，它现在已经算是一个相当糟糕的coding model了。但我认为，那是我们在Anthropic做出的第一个真正优秀的coding model。当时，如果你看看那个时期的各种编程产品，它们在做什么？它们做的就是单行自动补全。当时有时候也会做多行自动补全，这在当时还是一个新想法。他们也在做聊天功能，所以你可以和Agent对话，但它没有写入权限。你只能读取。你可以询问关于代码库的问题。
所以，当时给人的感觉是，并没有真正意义上的产品能够充分激发模型一次编写完整函数、一次编写完整文件的能力。当时还做不到一次完成整个功能，我们还没发展到那个阶段，但大概已经可以做到一次完成整个文件。这就是当时模型能力所处的水平。
所以，Claude Code的想法就是：好，我们觉得模型可能已经能做到这些。那么，如果我们把所有scaffolding都去掉，只给模型一个尽可能简单的harness，让它能够一次写完整个文件，甚至构建完整个功能，会怎么样？基本上就是这样。这就是当时的product overhang。模型本身已经有能力做某些事情，而周围的一切反而都在妨碍它。我认为，如今面对现代模型，存在大量的product overhang，但我还没有看到多少创业公司真正把这些能力转化出来。我认为确实有人在思考这些问题，但这里仍然存在巨大的机会：去激发模型那些令人惊叹、有意思，同时又具有商业价值的能力。
Diana Hu：我觉得，这对在座的所有人来说都是一个非常特别的洞察。基本上，如果你能想办法unhobble这些模型，你们每个人都有可能创造出下一个Claude Code，因为这实际上就是Claude Code的诞生故事。你们通过unhobble Sonnet 3.5，让它摆脱了过去那些迭代版本的限制——当时这些产品仍然把模型非常严格地限制在IDE里。而Claude Code是最早让模型获得完整终端访问权限的产品之一。
Diana Hu：然后，这就创造出了这样一个惊人的产品，而且它还在不断发展。那我们来聊聊，未来的创业者应该如何思考unhobbling Claude，以及如何解决这种product overhang？具体有哪些方向值得关注？
Boris Cherny：有几件事情是我会考虑的。第一，你应该给模型布置一些比你认为它能做到的任务稍微更难一点的任务。我经常看到的一个非常常见的错误是，人们在使用Claude Code、使用Claude时，会给它过于具体的指令。他们会说：“我希望你完成这个任务，但我要你按照这种方式、这种方式、这种方式来做。你必须先做第一步，然后第二步、第三步、第四步。”
对于现代模型来说，这其实完全不是正确的使用方式。你应该把任务描述得稍微高层一些。你需要说明任务是什么，说明guardrails（约束边界），说明exit criteria（完成条件），然后就放手让模型去做，过一会儿再回来看看结果。我觉得它会让你感到意外。再强调一次，这种做法六个月前可能还行不通，但今天已经可以了。
一个Prompt、运行11天：重写整个代码库
Diana Hu：你能不能举一些例子，说明有哪些具有挑战性的任务，或者哪些新的能力，是人们现在应该去探索的，而这些事情是模型六个月前还做不到的？
Boris Cherny：可以。比如，其中一个例子就是，现在模型基本上可以把几乎任何代码库从一种编程语言重写成另一种编程语言。这简直有点疯狂。这类工作过去作为工程师可能需要花非常长的时间，而现在模型完成得相当快。
一个例子就是，Claude Code是基于Bun JavaScript runtime构建的。它是一个开源的JavaScript runtime，是Node.js的一种替代方案。可以把它理解成一个更快的Node。Bun是用Zig编写的。Zig是一种系统编程语言，有点像C。它属于非常底层的语言。Zig的问题之一是，你必须手动管理内存。所以很容易遇到内存泄漏以及其他内存管理问题。
Bun团队当时做的一件事情，就是让Claude对整个代码库进行模糊测试，尝试模拟并触发内存泄漏。他们持续进行了很长一段时间。他们确实找到了很多内存泄漏。当时的方式基本上是一次找到一个问题。这就是当时模型所具备的能力水平——进行这种模糊测试。
后来在某个时候，团队里的Jared说：“好，我们干脆直接把它重写了吧。也许模型能做到。”我认为，这是他每次有新一代模型发布时，都会拿来测试模型的那类测试问题之一。从Fable开始，模型逐渐具备了完成这件事的能力。我认为Opus 5也可以做到。他的做法本质上是先定义一个测试套件。Bun有一个很大的优势，就是它经过了非常、非常充分的测试。Bun有一套很大的测试套件，Node.js也有一套很大的测试套件。所以，你很容易判断自己做得对不对。
他让模型把整个代码库从Zig重写成Rust。只用了一个prompt。这是一个dynamic workflow。Dynamic workflows是Claude Code中的一项功能，本质上可以让你协调几十、几百，甚至几千个Agent，高效地协同完成工作。整个过程运行了11天，然后它把整个代码库全部重写了。
Diana Hu：而且这是一次完成的吗？
Boris Cherny：算是一次完成——不，严格来说不是one shot，但过程中有引导。不过，即使有steering，之前的模型也根本做不到这件事。那在当时就是不可能的。
Diana Hu：只用了11天。我的天。这件事情如果放在过去，就算有最优秀的工程师，也得花好几个月，甚至几年吧？
Boris Cherny：绝对超过一年。这涉及超过100,000——JavaScript runtime非常复杂，里面有大量的东西。而且，它确实跑起来了。现在它已经在生产环境中运行了。你现在运行Claude Code时，它所使用的就是这个版本。
所以，这是一个例子。我再举第二个例子——一个product overhang。这是一个非常实际的使用场景：你正在解决一个问题。可能是一个商业问题、工程问题，也可能是产品问题。你应该不断把最新的模型拿来尝试，看看它能不能直接把这个问题解决掉。因为即使之前的模型做不到，新的模型也有可能做到。
我认为，第二种思考方式就是去做实验。给自己充分的自由，去玩模型、尝试一些有创造性的事情。很多时候，它会让你感到意外。最近在Anthropic内部有一件事情特别受欢迎，过去几周甚至已经在公司内部迅速传播开来：有人发现，你可以给Opus 5提供OpenCV，然后让它进行绘图。你可以这样做：直接告诉Opus：“嘿，用OpenCV画出这张图。”它实际上画得相当不错。它可以画肖像，可以画动物，也可以画风景。
我们并没有专门训练这个模型去画画。这只是一个solicitation gap（ZP注：指模型已经具备某项能力，但只有你用正确的方式去要求它时，这项能力才会被激发出来）。如果你用正确的方式要求它，它实际上就能做到。我们是偶然发现这一点的，只是因为我们在随便玩模型，尝试一些有创造性的事情，而这些事情并没有直接的商业应用。但这很有意思。我的假设是：对于今天的模型，很可能还有几十、几百个类似这样的机会，只是目前还没有人意识到它们的存在。
Prompt Engineering正在改变，验证才是关键
Diana Hu：所以，这方面一个很重要的研究方向，本质上就是模型能力激发——不断变得更擅长发现模型的各种能力，然后以正确的方式要求模型去完成相应的事情。
Diana Hu：那么，人们应该如何在这方面变得更强？更具体地说，人们应该如何提高自己的prompt engineering能力？现在大家还需要做大量的prompt engineering吗？还是说，这也正在发生变化？跟我们讲讲这个方向未来会怎么发展。
Boris Cherny：我记得一年前，最热门的招聘职位之一是prompt engineer。后来它发生了变化，我觉得变成了context engineer。所以，这方面会经历一轮又一轮的浪潮。我认为，这些职位和技能都会不断出现，也会不断退潮。如今真正重要的技能，与其说是prompt engineering，不如说是想办法给Claude布置一个看起来有点超出它能力范围的困难任务。然后，你还要想办法让Claude能够在执行过程中验证自己的工作。验证可能是目前人们做得最不到位、但又最重要的一件事情。
举一个例子。我们有一款Claude的桌面应用，它是用Electron构建的。我们已经把它做得非常快了。现在使用体验相当棒。六个月前，它还比较卡顿，而且不太可靠。但现在体验已经非常好了。它也是目前团队里大多数人都在使用的东西。作为一次实验，我想看看，如果把它做成原生应用，使用起来会是什么感觉。
所以，我启动了一个Claude Tag会话。Claude Tag是我们推出的一款新产品，本质上就是运行在Slack里的Claude。我的第一个问题是：“嘿，Tag，你能访问GitHub上的一个macOS runner吗？”它说不能。然后我给它接入了一个runner。这样，它就能够通过GitHub启动一台Mac虚拟机。
我的第二个问题是，我创建了一个空的代码库，里面是一个用Swift重写的Claude桌面应用。我问它：“你能访问这个代码库吗？”它说不能。然后我给它访问权限，它就说：“好的，太棒了。现在我可以访问了。”然后我说：“好，现在我要你做的是，把这个Electron应用重写成Swift。我希望你先在Mac虚拟机里运行Electron应用，给它截图，然后逐个像素地进行观察，把它和Swift版本进行比较。在完成之前不要停下来。”
Diana Hu：所以，那基本上就是你的prompt？
Boris Cherny：那就是我的prompt。
Diana Hu：那运行这个任务花了多长时间？
Boris Cherny：还在运行。
Diana Hu：你什么时候开始的？
Boris Cherny：已经运行两个多星期了。大概14天、15天左右。
Diana Hu：我不知道现场有没有人让Claude连续运行一个超过两周的任务。举个手？现场有人做到过吗？
Boris Cherny：这就是elicitation。这实际上就是一个非常典型的例子：模型今天已经能够做到这件事，你只需要让它去做。而且你不需要那些很复杂的东西。你不需要/go，也不需要/loop。这些东西确实有帮助。但实际上，你真正需要的就是：把任务交给模型，再给它一种能够验证自己工作结果的方式，这样它就不会卡住，然后它就会一直做下去。
而且实际上，在这个案例里，Claude还决定给这个过程做live blog（实时连载播报）。它做的事情是，在内部创建了一个Slack频道，然后每隔几分钟就发一张截图，展示自己的进展。
Diana Hu：哇。所以，这个prompt听起来真的非常简单。现场的每个人都可以做到。那我想知道，真正能够成为Top 1% Claude Code用户的人，他们和其他人之间究竟差在哪里？大家要怎样才能像Boris一样使用Claude Code？
Boris Cherny：也许首先不要听LinkedIn上那些网红的话。
Diana Hu：别听。也别看Twitter。
Boris Cherny：这就是模型的特点。我觉得每个人都在寻找那个“一个奇招”——某个只要掌握了就能搞定一切的技巧。但根本不存在这样的东西。使用模型的方式就是，你必须用一种经验性的方式去接近它。你必须给它一个难到有点超出能力范围的任务。你必须给它提供验证工作成果所需的工具，就像你自己完成这项任务时，也会使用这些工具一样。你必须观察它在哪些地方遇到困难，然后针对这些问题进行修正——要么通过更好的prompting，要么通过一个skill。或者，如果模型缺少必要的上下文，那就给它一个MCP，让它能够获取自己需要的上下文。基本上就是这样。
Diana Hu：听起来很简单。
Boris Cherny：我觉得人们有点容易把事情想得太复杂了。我认为，人们往往会过度设计，因为从很多方面来说，过去我们构建系统时，本来就必须这么做。所以，当我看到那些已经写了很多年代码、甚至写了几十年代码的工程师时，这是一个非常、非常常见的错误模式：试图把指令写得过于具体，希望模型完全按照你自己原本会采用的方式去完成任务。但模型的工作方式并不是这样的。
不过，我觉得很多人正在逐渐摆脱这些习惯，而这本身就是一个过程——需要一点一点地慢慢改变。你需要逐渐弄清楚，应该如何像对待一个同事一样对待这个东西。我认为，现在它的智能程度已经达到了这个水平。
运行数千个Agent：Dynamic Workflows、Loops与Routines
Diana Hu：作为这个话题的一部分，我们再深入聊聊那个你两周前启动、到现在已经运行了两周的任务。它一共spawn了多少个Agent？
Boris Cherny：我不确定。我可以问一下Claude，然后再告诉你。我猜可能是几千个，几十……
Diana Hu：几千个。现场有人给任何一个模型下过这样的prompt，让它spawn出超过一千个Agent吗？没有。我觉得这也是另一个值得注意的技巧。最优秀的Claude用户能够发起那些真正能给你带来巨大杠杆的任务，比如一次spawn几千个Agent。
Boris：是的。
Diana Hu：那要怎么做到这一点？
Boris Cherny：有几种不同的方式。最简单的方法是dynamic workflows。这是Claude Code中一个相当新的功能。你只需要说一句：“use a workflow。”就这样。然后Claude就会直接触发dynamic workflow。
Dynamic workflow本质上是这样的：我们有Bun runtime。我们把Bun用作沙盒，然后在Bun里面启动一台虚拟机。接着，我们让Claude启动大量Agent，并对它们进行编排。而且它不是只启动一个Agent，也不是只启动10个并行Agent。比如说，任务可能是重写整个代码库，或者对某些非常复杂的数据进行深入的数据分析；又或者是构建一个非常复杂的功能，需要经过多个阶段，可能还需要提交几十个pull request。它会先启动一批Agent，完成第一轮工作。根据第一轮的结果，它可能会进入第二个阶段，启动另一批Agent来验证前面的工作，或者对前面的工作进行总结。然后，它可能进入第三个阶段，再次fan out。也就是说，它会以一种高效的方式，对大量不同的Agent进行编排。
我的背景是函数式编程。所以，我们设计这个系统的方式，本质上可以理解为一个针对Agent的代数。这里有一种方式可以让Agent按顺序运行，也有一种方式可以让Agent并行运行。Claude有不同的工具，可以在沙盒内部对这些Agent进行编排，高效地使用Token，从而完成非常、非常复杂的工作。这挺酷的，而且这方面其实还没有太多公开讨论。
实际上，这是test time compute的一种新形式。当我们谈论Scaling law，谈论模型随着时间推移变得越来越智能时，历史上，这主要取决于几个因素：神经网络的规模、训练数据的数量，以及训练过程中投入的FLOPs数量。最近，我们又加入了test time compute。这基本上就是研究人员一种比较高级的说法，意思是：模型会生成多少个Token？而现在，dynamic workflows本质上提供了一种编排test time compute的新方式，一种真正大幅增加test time compute、让模型完成超难任务的方法。
所以，说了这么多，简单来说，这就是一种能够以高效、有产出的方式启动数千个Agent的方法。第二种方式是loops和routines。Loop本质上就是一个在本地运行、为Claude设置的定时任务。Routine也是一样的东西，只不过它运行在云端。所以你可以把笔记本电脑合上。而这和dynamic workflow稍微有所不同：对于dynamic workflow来说，它是一个任务，然后把这个任务拆分成多个部分。而对于loops和routines来说，它是一个会重复执行的任务，这些重复执行之间不会共享context，但可能会共享memory。
然后你可以不断重复执行这个过程。你可以每小时运行一次、每五分钟运行一次，也可以每天运行一次。我们已经开始做的一件事情是，现在实际上让Claude维护它自己。我们的做法是创建一个Slack频道，然后让Claude启动一批不同的routines，去维护它自己的代码库。我们实际上会对CLI、iOS app、Android app以及桌面应用都这么做。
举个例子，其中一个routine是清理死代码。这只需要一个prompt——就一句话。Claude每天运行一次。它会利用静态分析和动态分析，在所有代码库中寻找死代码。我们并没有在prompt里告诉它要怎么做这些事情；这些都是它自己摸索出来的。然后，它每天都会提交pull requests，把这些死代码删除掉。
另一个例子是把那些应该正式上线的实验发布出去。比如某个实验已经面向100%的用户开放了，那么它就会把这个实验从代码库中删除，然后直接上线。还有一个routine是为代码库中测试覆盖率不足的区域编写测试。另一个则是删除那些其实不应该存在的测试，因为它们是早期模型添加的无用测试，或者是某个时候由人添加进去、但实际上没有价值的测试。
还有一个我特别喜欢的——我忘了我们当时叫它什么。我觉得我们叫它abstraction police（抽象警察）。它的想法是：在一个大型代码库里，经常会存在相同的抽象，而且会在多个地方重复出现。仔细看的话，你会发现它们其实可能应该是同一个抽象，只不过随着时间推移，不知道出于什么原因，我们在代码库的不同部分以不同方式把它重新实现了好几次。所以，Claude每天都会检查我们所有的代码库，找到这些几乎重复的抽象，然后把它们统一起来。
现在，我们每天大概有20到30个这样的routines在所有代码库中运行。目前还没有完全做到，但我们正在朝着完全自动化应用维护的方向前进。这意味着，每天有数百甚至数千个Agent在运行，正在完成几十甚至几百名工程师的工作——过去，要完成这种类型的工作，需要这么多工程师。也就是说，工程师现在可以专注于他们真正想做的事情：发布新产品、和用户交流，以及去做那些真正有意思的事情。
编程，几乎已经被解决了
Diana Hu：那么从这里可以得出一个结论——你过去也提到过：编程基本上已经被解决了。我很好奇，现在既然几乎每个人都可以写软件了，那么真正优秀的构建者和其他人之间，究竟是什么在拉开差距？既然现在所有人都能发布代码了，优秀构建者所需要具备的品质又是什么？
Boris Cherny：我想先加一个限定。对于我所做的这类编程来说，编程已经被解决了。但对所有人来说，还没有。现在仍然有一些非常底层、非常复杂的系统级代码库，Claude在处理时还是会遇到困难。有一些分布式系统，Claude也依然会比较吃力。还有一些非常细节的UI验证，比如某个地方差了一个像素之类的情况。Claude在这方面仍然不是完美的。Opus 5在视觉和Computer Use方面实现了一次很大的跃升，但它依然不是完美的。
不过我其实很好奇，在座各位可以举一下手吗？如果你现在100%的代码都是由Agent写的，你已经完全不再手写代码了，就举一下手。挺不错。好，那超过50%的呢？手稍微少了一些，也许差不多。所以，我认为我们正在逐渐接近这个状态。对于越来越多种类的代码来说，编程正在变成一个已经被解决的问题。这很酷。
当我思考那些最擅长使用Claude的人时，我觉得他们都有一种非常有效的心态。核心还是在于经验主义。所以，忘掉你过去从旧模型那里学到的一切。忘掉你在课堂上学到的所有计算机科学理论。看着模型，尝试让它完成一项任务，观察它在哪些地方遇到困难，然后根据这些结果进行调整。
所以，这已经越来越不像一门理论科学，而更像一门经验科学。我认为，那些真正擅长这件事的人，真正擅长放下自己原有认知的人——他们能够放下过去那种“以前行不通，所以现在也不会行”的想法，愿意重新尝试——这种能力，如今真的非常、非常容易取得成功。
CS学生仍然值得亲手学习的东西
Diana Hu：最后一个问题。考虑到我们刚才谈到的所有这些，如果在座有人正在学习CS，而且是在AI Agent编程时代到来之前就学会了编程，那么对于现在的学生来说，哪些东西仍然值得用“笨办法”、用过去的方式亲自学习？
Boris Cherny：对我来说，我是非常实践地学习计算机科学的。我通过自学编程来解决实际问题，在解决问题的过程中学习。每当我做这些事情时，都是因为我当时有一个具体的问题需要解决。我最开始其实是在TI-83计算器上学编程的。那还是我上初中的时候。后来，我还在互联网上写了一份关于如何给TI-83计算器编程的指南。现在网上某个地方可能还找得到。用的是BASIC——那是我的第一门编程语言。
我当时之所以在计算器上学编程，是为了在数学考试里作弊，这样我就能考得更好。所以，对我来说，它完全是出于实际需求。对于当时的一个初中生来说，这是我能想到的最实用的事情。最后，我真的考出了很好的成绩。然后我买了一根小小的串行线缆，把程序传给我的同学，他们的成绩也都变得很好。后来数学变得更难了。到了那个时候，我已经没办法再用BASIC解决问题了。所以，我从那个用BASIC编写的代数求解器开始，继续面对更难的问题。等到了微积分阶段，我就必须运行assembly，这样才能写出一个更强的求解器——这样到了考微积分的时候，我就能更好地作弊了。
对我来说，编程一直都是非常实践性的东西。所以，这也是我一直给在校学生的建议：不要只学习计算机科学——当然，计算机科学在智力上非常有意思，也确实很值得学习。但你还要学习如何把它应用起来。很多时候，这意味着去创业，去构建产品，培养自己的设计品味，培养自己的商业嗅觉，学习如何做数据科学，学习如何与用户交流。还有很多其他技能。而当你把这些技能和计算机科学、工程结合起来时，它们才真正变得有价值。所以，这些就是我现在仍然会选择亲手学习、亲手掌握的硬技能。
Diana Hu：所以，如果我来总结一下你的意思：先从为自己做一些你真正想要的东西开始，然后再进一步，去做一些其他人也想要的东西。
Boris：是的。
Diana Hu：我们还有最后一个特别的消息要宣布，Boris。最后一件事。
Boris Cherny：对。所以，今天在场的每一位，你们都会获得Max 20X。
Diana Hu：太棒了。
Boris Cherny：所以，记得查看你的邮箱，里面会有一封相关的邮件。我已经迫不及待想看看你们会做出什么东西了。
Diana Hu：所以我很好奇，在座应该有人现在就会开始构建某个能够连续运行几个月、调度数千个Agent的东西——毕竟你们现在已经有这个账号和额度可以去做了。那就这样，非常感谢你，Boris。
Boris Cherny：谢谢。
编译：Alice Xu内蒙古股票配资
文章为作者独立观点，不代表联华证券-股票配资开户-正规配资开户观点
