Claude Code之父：删减80%提示词与利用Product

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时，会给它过于具体的指令。他们会说：“我希望你完成这个任务，但我要你按照这种方式、这种方式、这种方式来做。你必须先做第一步，然后第二步、第三步、第四步。”