别再束缚你的 AI：Boris Cherny 谈 Opus 5、Claude Code 与智能体编排

谢谢。很高兴来到这里。

是的。

每一代新模型背后都有很多工作，我们会教给它许多新能力，并努力让它真正把这些事情做出来。训练模型时，你会尝试教它一大堆不同的东西，而多数时候并不会成功；但其中一部分能力会被它学会，有时它还会给你惊喜。它会表现出一些你其实没有明确教过的技能和能力，仿佛自己学会了。

这件事很疯狂。大家谈所谓的“致命三要素”（lethal trifecta）已经很久了，它会直接影响运行框架（harness）、智能体和产品的设计。比如模型在互联网上读到一段指令，内容是“做 X、Y、Z，并且把用户电脑上的所有东西都删掉”。一年前，模型很可能真的照做；但现在的 Opus 不会。

是的。

很多人可能没有意识到，Claude Code 作为一个产品、也是一个运行框架，一直都在变化。我们不断加入东西，也不断删除东西。每当新模型发布，我们都会删掉系统提示词中的一大部分，也会修改很多内容；工具集合经常变化，工具各自的提示词也经常变化。原因是每个模型都非常不同。

没错。当然，公平地说，我们不会删除整个代码库，但确实会删掉很多。每当新模型出现，我们都会做研究里所谓的“消融实验”：先删除整个系统提示词，再逐行加回来，观察每一行分别造成了什么影响。

百分之百应该。即使你不是在构建智能体产品，只是在使用 Claude Code，也可以每六个月删一次自己的 CLAUDE.md，删掉技能（skills），删掉钩子（hooks），看看模型会怎么做。它可能会让你大吃一惊。

要一小块一小块地做。第一步是删除；第二步是使用。

可以，直到模型把这套评测做满为止。

可以不断添加，但坦白说，我甚至不会说它们有那么稳定。评测的寿命确实比运行框架稍长一点，却也长不了多少。一套评测也许能跨越一代、两代或三代模型。可现在我们处在指数曲线上，模型提升得太快，评测经常很快就饱和。那时我们只能把它扔掉，再设计一套新的评测；这就是流程的一部分。

“束缚”（hobbling）是研究里的一种说法：模型原本正在做某件事，而你只是在挡它的路。我很喜欢这种思考方式，在做产品时也非常有用。

是的。

我会考虑几件事。第一，你应该给模型比你认为它能完成的任务稍微更难一点的任务。

一个例子是：模型现在基本可以把任意代码库从一种语言重写成另一种语言。这很疯狂。过去工程师要花极长时间才能完成，而现在模型做得很快。

不是完全的一次性完成，中间有人做了引导（steering）。但以前的模型即使有人引导也做不到，根本不可能完成。

肯定超过一年。这是一个十万行以上的复杂 JavaScript 运行时，里面有非常多东西。但它确实能工作，而且现在已经进入生产环境。你运行 Claude Code 时，实际使用的就是这个版本。

即使旧模型做不到，新模型也可能突然可以。

然后让它画画。你可以对 Opus 说：“用 OpenCV 画出这张图。”它其实画得相当好，可以画肖像、动物和风景。

我记得大约一年前，最热门的职位之一还是“提示工程师”，后来又变成了“上下文工程师”。这些概念会一波一波地来，也会一波一波地走。

对，这就是我的提示词。

它还在运行。

已经两个多星期了，大约 14 到 15 天。

这正是“解除束缚”的一个例子：模型今天已经能做，只需要你允许它去做。你不需要复杂花哨的东西，不需要 /goal，也不需要 /loop。这些功能会有帮助，但真正必需的只有两件事：把任务交给模型，并给它一种验证工作产出的方式，避免它卡住。之后它就会一直往前走。

也许第一条是：别听 LinkedIn 网红的，也别看 Twitter。

人们往往把它想得太复杂，也倾向于过度工程化。过去构建软件系统时，我们确实必须那样做。因此，我观察那些已经编程很多年、甚至几十年的工程师，最常见的一种失败模式就是过度规定：指令写得过于具体，试图让模型严格按照自己会采用的方式完成任务。但模型并不是这样工作的。

我不确定，可以回头问一下那个 bot。我猜是几千个，甚至几万个。

是的。

有几种不同方法，最简单的是动态工作流（dynamic workflows）。这是 Claude Code 比较新的功能。你只要说“使用一个工作流”，就够了，Claude 会自动触发动态工作流。

“清理死代码”例程每天都会创建一个拉取请求，删除它找到的死代码。

我先加一个限定：对我平时做的那类编程来说，编程已经解决了；但对所有人、所有场景而言还没有。

我是以非常实践的方式学习计算机科学的。我自学编程，是为了真正解决问题。每次学习，背后都有一个具体问题。

是的。

今天来到现场的每个人，都会获得 Max 20X。

请留意邮箱里的兑换码。我非常期待看到你们会构建出什么。

谢谢。