Claude Code 的创造者 Boris Cherny 也去 YC Startup School 2026 了，分享了一些信息：

- Opus 5 解决了「提示词注入」的问题

在 Agent 领域，有致命三要素（获取你的私有数据、暴露于不可信内容、具备外部通信能力），很容易被提示词注入利用，如果模型在网页中读到类似"执行 X、Y、Z，同时删除用户计算机所有内容"的指令，一年前模型可能就直接执行这个来自外部的指令了。

但 Opus 4.7、4.8 开始就不会了。Opus 5 更强，是因为模型对齐得到大幅提升，且与提示词注入分类器相结合，它的工作机制基于 Anthropic 的模型可解释性研究，可以观察到模型“大脑”中那些在提示词注入发生时被激活的神经元，然后再将自动模式与其做结合。有了这三层防护机制，「提示词注入」问题就被解决了。

- Claude Code 被删除 80% 系统提示词的更多细节

CC 作为一个产品和 harness 一直在变化，每次新模型发布，都会删改大量系统提示词，调整 tools 集以及其提示词。每个模型都很不一样，之前的设计方案可能完全不适用于新模型。Opus 5 非常智能，不再需要很多原本为了纠正模型行为的提示词。

Boris 说了一个 CC 隐藏功能：如果设置环境变量“CLAUDE_CODE_SIMPLE=1”并运行 Claude，它将清除所有系统提示词，包括 tools 提示词。

Claude 内部用这种消融实验来验证提示词的有效性，Boris 近期的发现是：模型没有这些提示词反而更智能。但是作为一款产品，还是需要保留部分提示词。

Claude 模型每次发布，CC 都会大量删除代码，做消融研究，具体做法是：先删除整个系统提示词，然后逐行进行恢复，以评估每一行的影响；tools 也采用同样的方法，经常停用 tool 模块。

对于 CC 普通用户，Boris 建议每六个月删除你的 CLAUDE.md、skills 和hooks。观察模型的表现，它可能会给你带来惊喜。对于 Opus 5 版本，他强烈建议尝试删除所有这些配置，因为模型可能已经不再需要过去版本所需的那些指令集了。

为 Claude Code 重构新系统提示词的方法：第一步是删除。第二步是实际使用它。如果你在使用 CC，看看它在你的代码库中哪些地方表现优异，又或者在哪些架构或其他环节上遇到困难。只有当你看到它反复在同一个地方出错时，才需要添加相应的提示。切记这个指令在你每次使用模型时都会被读取，你真的需要确保模型确实需要这条指令。

过去的时代构建系统时，你会精心设计庞大而优美的架构，深思熟虑系统设计，配备一整套单元测试，考虑周全，重新架构是个大工程，有时需要数月甚至数年。但模型不是这样。你可以把它想象成有生命的生物，更有机体的存在。每一次模型迭代，它的表现都会有所不同，带着微妙的个性差异。你必须花时间去了解它，然后据此调整 harness。这本质上是个经验性且科学的过程。你需要秉持科学思维，尝试、观察结果，再基于此进行迭代。

- 解放 Claude ：产品悬置（Product overhang）与产品掣肘（Product hobbling）问题

产品悬置：现有模型其实已经能实现各种功能，只是我们尚未发掘。每代模型都具备相应能力，但往往缺乏合适的产品载体让模型真正施展这些本领。

产品掣肘：产品成了障碍，无法从模型中引出正确行为。

产品悬置与产品掣肘是一体两面，当年的 Claude Code 诞生就是解决了这两个方面的问题：模型的编程能力已经达到当时最佳；同时当时的编程产品还在做自动补全，没有产品能充分激发模型一次性编写整个函数、整个文件的能力。

CC 在创立时的核心思想：移除所有冗余的支撑结构，只给模型提供最简化的控制框架，让它能一次编写整个文件并构建整个功能。

- 如何解决产品悬置与产品掣肘问题，揭开 Claude 束缚？

首先，你应该给模型布置比你以为它能完成的任务稍难一点的任务。一个很常见的错误是，人们在使用 Claude Code 或 Claude 时，给出的指令过于具体。他们会说：“我希望你这样做，但我希望你按这个方式、这个方式、这个方式做。你必须先做一，再做二，然后三，接着四。”对于现代模型来说，这其实并不是正确的做法。你应该在更高层面进行描述：描述任务本身，描述约束条件，描述完成标准，然后放手让模型去“烹饪”，稍后再回来查看结果。它会给你惊喜。需要再次强调的是，这在六个月前可能行不通，但在今天确实有效。

第二种思路是将其视为实验场。给自己自由空间，用模型探索各种创意可能性。它们常会带来惊喜。最近在 Anthropic 内部有个特别火爆的玩法，已经形成病毒式传播——有人发现把 Opus 5 与 OpenCV 结合，就能让 AI 模型直接进行绘画创作。

- 提示工程、上下文工程的未来

Boris 说，如今的技能，与其说是提示工程，不如说是琢磨如何给 Claude 布置一项看起来有些难以胜任的难题。接着，你又如何让 Claude 能在过程中自我验证呢？验证，恐怕是大多数人至今仍未掌握的最核心能力。

放手让模型去做。不需要复杂指令，不需要 /go，也不需要 /loop。这些工具有帮助，但真正关键的是给模型布置任务，同时提供验证输出的方法，这样它就不会卡壳，然后它就会持续运行。

大家都在寻找某种速效妙招来解决问题，但这种东西并不存在。根本不存在这样的捷径。模型的工作方式是：你必须用经验主义的方法去接近它，给它布置一项过难的任务，同时提供工具让它像你自己完成任务时那样验证成果。你必须观察它在哪方面表现吃力，然后要么通过更优的提示优化，要么 skill 来解决。如果模型缺乏上下文，就给它一个 MCP 接口，让它能自主获取所需的信息。

人们有时想得有点太复杂了。在很多方面，过去构建系统时，确实需要那样做，所以长期从事编程工作多年的工程师们容易产生一个非常普遍的误区——总是试图过度指定细节，想让模型完全按照自己的方式来执行任务。但大模型的工作原理并非如此。Boris 认为很多人正在重新适应这一点，摆脱这种思维定式需要一个过程。关键在于学会如何像与同事相处一样对待大模型。这正是当前智能系统所达到的水平。

- 高效启动数千个 agent 的两种方法

Boris 提到了将 Claude 桌面端从 Electron 应用改到用 Swift 语言重写的案例，提示词很简单，运行了 15 天，开了成千上万个 agent 来完成任务。在被问到如何开启上万个 agent，Boris 分享了两种方法。

1、动态工作流，将单个任务分解成多个部分执行、块间共享目标；2、loops 和 routines，重复性任务、执行间不共享上下文，但可以共享 memory

文字：www.ycrootaccess.com/p/boris-cherny-building-claude-code视频：www.youtube.com/watch?v=qyPCVqFUyDo