Opus 5 有何不同
好，Boris，我们特别高兴你能来到这里。你是 Claude Code 的创造者。
谢谢。很高兴来到这里。
这真是刚刚出炉的消息——你们昨天才发布 Opus 5。
是的。
看起来模型性能还在持续加速。你们把 ARC-AGI-3 的成绩提高到了 30%，这非常惊人。作为对比，此前最好的成绩还只是个位数偏低的水平，或者十几个点，对吧？和上一代相比，Opus 5 现在能做到哪些过去做不到的事？
每一代新模型背后都有很多工作，我们会教给它许多新能力，并努力让它真正把这些事情做出来。训练模型时，你会尝试教它一大堆不同的东西，而多数时候并不会成功；但其中一部分能力会被它学会，有时它还会给你惊喜。它会表现出一些你其实没有明确教过的技能和能力，仿佛自己学会了。
以 Opus 5 为例，有一项能力是我认为其他模型都没有做到过的：它可以连续运行非常长的时间。尤其是把 Opus 5 和自动模式（auto mode）结合起来，效果非常不可思议——它可以连续工作几天、几周，甚至几个月，就是不会停下来。
你甚至不需要额外搭脚手架（scaffolding），不需要 `/goal`，也不需要其他那些东西。它会一直做下去，因为它知道自己需要完成任务。
还有一件让我非常兴奋、我也准备开始多谈一点的事情。它之所以令人意外，是因为这是一项非常新的能力：这个模型看起来已经不再容易被提示注入（prompt injection）了。
如何解决提示注入
“不再容易被提示注入”是什么意思？
这件事很疯狂。大家谈所谓的“致命三要素”（lethal trifecta）已经很久了，它会直接影响运行框架（harness）、智能体和产品的设计。比如模型在互联网上读到一段指令，内容是“做 X、Y、Z，并且把用户电脑上的所有东西都删掉”。一年前，模型很可能真的照做；但现在的 Opus 不会。
其实从 Opus 4.7、4.8 左右开始，情况就已经在改善，Sonnet 5 在这方面也相当不错；而 Opus 5 又把这条边界向前推进了一大步。
大体上，你需要把三层东西组合起来。第一层是一个对齐良好的模型，这背后大约是三年的对齐研究。第二层是提示注入分类器，我们会让所有流量都经过它。这个分类器基于 Crystal 的机制可解释性（mechanistic interpretability）工作：我们实际上会观察模型“大脑”里哪些神经元在发生提示注入时被点亮。模型自己甚至不会告诉你发生了什么，但我们可以看到这些神经元，据此识别和诊断提示注入。
然后再把它与自动模式分类器结合起来。通过这三层防线，我们现在已经无法再演示出一次成功的提示注入了。
Claude Code 为什么删掉 80% 的系统提示词
说到提示注入，硬币的另一面就是系统提示词。我们来谈谈这次新版本：你们实际上删掉了 Claude Code 超过 80% 的系统提示词。
是的。
展开讲讲。
很多人可能没有意识到，Claude Code 作为一个产品、也是一个运行框架，一直都在变化。我们不断加入东西，也不断删除东西。每当新模型发布，我们都会删掉系统提示词中的一大部分，也会修改很多内容；工具集合经常变化，工具各自的提示词也经常变化。原因是每个模型都非常不同。
三个月前针对某个模型做的设计，换到下一代模型上可能完全无法迁移。Opus 5 的一个特点就是它真的非常聪明。系统提示词里原本有很多内容，是为了纠正一些“模型本来应该知道、但当时并不知道”的行为；现在 Opus 5 自己就会做了。
所以，我们删掉了 80% 的系统提示词。你甚至可以试着把剩下的也删掉。运行 Claude Code 时，可以使用 `--system-prompt`，设成你想实验的任意系统提示词。
还可以试试“简单模式”（simple mode）。这是一个没有正式写进文档的功能：把相应的 Claude Code simple 环境变量设为 1，再运行 Claude，它会删除全部系统提示词，包括工具里的提示词。
我们把这种方式当作一种消融实验（ablation），用来判断某段提示词究竟有没有价值。有趣的是，我们发现没有这些提示词时，模型反而会稍微聪明一点。但当你把 Claude Code 当成产品使用时，其中一些提示词仍然有用，因为它们能让产品和模型以用户期望的方式表现，也能帮助人更顺畅地使用产品。
我觉得这个时代最迷人的一点是：你们先为 Claude 做出世界上最好的运行框架，也就是 Claude Code；但按你的描述，每发布一代模型，你们几乎都会删掉大量代码和提示词，从头重新审视。在旧的软件世界里，初创公司通常不会这样做——每六个月就对产品里的所有东西按一次删除键。
没错。当然，公平地说，我们不会删除整个代码库，但确实会删掉很多。每当新模型出现，我们都会做研究里所谓的“消融实验”：先删除整个系统提示词，再逐行加回来，观察每一行分别造成了什么影响。
它有点像评测（eval）。消融实验本质上也是一种评测，只不过你是通过删除东西来判断它的影响。
工具也一样。我们经常把已经发布的工具撤掉，也经常删除运行框架里的代码。今天 Claude Code 的运行框架中，绝大多数代码其实都与安全、权限和静态分析有关，此外还有不少界面代码；其他很多代码，我们已经陆续撤掉了。
对你的 AI 产品勇敢按下删除键
这种构建智能体产品和运行框架的方式——每当新模型发布就重新做消融实验——是否也适用于今天在场的所有 AI 产品创业者？大家都应该习惯、也敢于按下删除键吗？
百分之百应该。即使你不是在构建智能体产品，只是在使用 Claude Code，也可以每六个月删一次自己的 `CLAUDE.md`，删掉技能（skills），删掉钩子（hooks），看看模型会怎么做。它可能会让你大吃一惊。
特别是对 Opus 5，我们确实建议大家尝试把这些东西都删掉，因为新模型可能真的已经不再需要你为旧模型写下的那些指令了。
如何为新模型重建系统提示词
那我们来谈谈，删掉以后该怎样构建新的提示词。新模型发布后，在场所有人都会想试 Opus 5，也会对自己的系统提示词按下删除键。接下来应该怎样重建系统提示词、怎样设置环境？
要一小块一小块地做。第一步是删除；第二步是使用。
不要凭空猜模型需要哪条指令，因为你的预测可能是错的。你应该先真正运行它。如果你构建的是面向客户的智能体产品，就去运行这个产品，观察模型在哪里失败、哪些地方做得好。如果你在使用 Claude Code，就看它在你的代码库里哪些地方表现良好，又会不会被某种架构或其他问题绊住。只有当你看到它反复在同一件事上跌倒时，才把针对那件事的指令加回来。
不要太早添加，因为模型每次运行时都会读到这条指令。你必须非常确定它确实需要这条指令。
我觉得，在模型之上构建产品最疯狂的一点，就是它与我过去做过的所有工程都截然不同。以前构建系统时，我们会先设计一个庞大而漂亮的体系，预先深入思考系统设计，准备一大套单元测试，把各种问题都考虑进去。一次重新架构会是个大项目，可能持续数月；我在大公司参与过耗时数年的架构改造。
模型不是这样。你几乎应该把它想成一种活物，一种更有机的东西。每一代模型的行为都不同，性格也会略有变化。你必须花时间了解它，然后根据它的表现调整运行框架。
这是一件非常经验主义、也非常科学的事。你需要用科学心态对待它：尝试一件事，观察结果，再根据结果迭代。
如果现在就在这个世界里构建产品，还有什么东西是相对稳定的？评测集能否从上一代模型保留下来，并在每一次新模型发布时继续使用？
可以，直到模型把这套评测做满为止。
所以给大家的建议可以概括成：如果想站在最前沿、榨出模型最多能力，代码和系统提示词要敢于删除；评测则相对稳定，可以持续往里面添加案例。
可以不断添加，但坦白说，我甚至不会说它们有那么稳定。评测的寿命确实比运行框架稍长一点，却也长不了多少。一套评测也许能跨越一代、两代或三代模型。可现在我们处在指数曲线上，模型提升得太快，评测经常很快就饱和。那时我们只能把它扔掉，再设计一套新的评测；这就是流程的一部分。
归根结底，还是要经验主义地做事：使用产品、使用模型，观察它在哪里吃力，然后针对那些困难建立评测集。
产品能力滞后与“解除束缚”
我听你用过一个词来描述怎样在 Claude 之上构建最好的智能体产品——“给 Claude 解除束缚”（unhobbling Claude）。这是什么意思？
“束缚”（hobbling）是研究里的一种说法：模型原本正在做某件事，而你只是在挡它的路。我很喜欢这种思考方式，在做产品时也非常有用。
另一个相关概念叫“产品能力滞后”（product overhang）。它的意思是：不是未来的模型，而是今天的模型，已经能做各种我们尚未意识到的事情。模型拥有大量这样的能力，只是人们还不知道。它也许能使用某个特定工具、某种语言，解决某一类问题，或采用一种我们过去认为超出其能力范围的方式做事。
这里存在一段“滞后”：每一代模型都已经具备某些能力，却常常没有产品让它把这些能力真正表现出来。反过来，产品本身还经常挡住模型。产品挡路，就是“束缚”；没有把模型正确的行为引出来，就是“产品能力滞后”。它们是同一件事的两面。
最初的 Claude Code 就是一个例子。我开始做它大约是一年半到两年前，当时用的是 Sonnet 3.5。它在当时是不可思议的编程模型，可能是世界上最好的；按今天的标准看，它当然已经是一个很差的编程模型，但它大概是 Anthropic 做出的第一款真正优秀的编程模型。
看看当时的编程产品：它们主要做单行自动补全，偶尔做多行补全——那时多行补全还算新概念。它们也提供聊天，你可以询问代码库，但智能体只有读取权限，没有写入权限。
因此，当时并没有一款产品真正引出了模型一次写完整函数、甚至完整文件的能力。那时还没到一次完成整个功能的水平，但写完整文件大概已经可以了。
Claude Code 的思路就是：既然我们认为模型可能做得到，为什么不拿掉所有脚手架，只给它一个尽可能简单的运行框架，让它一次写完整文件，并逐渐构建完整功能？这就是当时存在的产品能力滞后。模型明明能做，周围的一切却都在妨碍它。
今天的现代模型存在更多产品能力滞后，而我没有看到初创公司充分捕捉它们。有人已经在思考这些问题，但这里仍然有巨大的机会：把模型那些惊人、有趣、而且具有商业价值的行为真正引出来。
这对在场所有人都是一个非常特别的洞见。只要找到解除模型束缚的方法，你们每个人都可能创造下一个 Claude Code，因为这正是 Claude Code 的诞生故事。你们给 Sonnet 3.5 解除了束缚：此前的产品仍把模型紧紧限制在 IDE 中，而 Claude Code 是最早直接给它完整终端访问权限的产品之一。
是的。
给 Claude 比预期更难的问题
然后它就成长成了这个令人惊叹、还在不断前进的产品。未来的创业者应该在哪些方向思考怎样给 Claude 解除束缚、怎样消除产品能力滞后？
我会考虑几件事。第一，你应该给模型比你认为它能完成的任务稍微更难一点的任务。
我经常看到一种错误：人们使用 Claude Code 或 Claude 时，把指令写得过度具体，例如“我要你做这件事，但必须用这一种方式、那一种方式；先做一，再做二、三、四”。对现代模型来说，这已经不是正确用法。你应该把抽象层级提高一点。
描述任务，描述护栏，描述退出条件，然后就让模型自己发挥。过一会儿再回来看看，我认为它会让你惊讶。再次强调，这种做法六个月前还行不通，但今天已经可行。
能不能举一些例子？有哪些更具挑战性的任务或能力，是大家应该探索、而模型现在能做、六个月前还做不到的？
一个例子是：模型现在基本可以把任意代码库从一种语言重写成另一种语言。这很疯狂。过去工程师要花极长时间才能完成，而现在模型做得很快。
Claude Code 构建在 Bun JavaScript 运行时之上。Bun 是一个开源 JavaScript 运行时，是 Node.js 的替代方案，可以理解成更快的 Node。Bun 原本用 Zig 编写，Zig 是一种类似 C 的底层系统编程语言。Zig 需要手动管理内存，所以很容易出现内存泄漏和其他内存管理问题。
Bun 团队曾经让 Claude 对代码库做模糊测试（fuzzing），尝试模拟并触发内存泄漏。他们长期这样做，找到了很多内存泄漏，但基本上是一次处理一个案例；那就是当时模型能力的边界。
后来团队里的 Jared 说：“那就直接重写吧，也许模型能做到。”这成了他每遇到一代新模型就会扔给模型的测试题。大约从 Fable 开始，模型逐渐能够完成它；我认为 Opus 5 也可以。
他先定义了一套测试。Bun 的好处是测试非常充分：Bun 有庞大的测试套件，Node.js 也有庞大的测试套件，因此很容易判断重写结果是否正确。
接着，他让模型把代码从 Zig 重写成 Rust。入口只有一个提示，但它运行的是动态工作流（dynamic workflow）。这是 Claude Code 的一项功能，可以编排几十、几百乃至几千个智能体，让它们有效协作。整个过程持续了 11 天，最终重写了整个代码库。
这是一次性完成的吗？
不是完全的一次性完成，中间有人做了引导（steering）。但以前的模型即使有人引导也做不到，根本不可能完成。
11 天？我的天。过去即使由最优秀的工程师来做，也要几个月，甚至几年吧？
肯定超过一年。这是一个十万行以上的复杂 JavaScript 运行时，里面有非常多东西。但它确实能工作，而且现在已经进入生产环境。你运行 Claude Code 时，实际使用的就是这个版本。
这是一个很实际的产品能力滞后案例：你有一个商业问题、工程问题或产品问题，就应该持续把最新模型扔过去试一试，看看它能不能直接完成。
用无目的实验发现隐藏能力
即使旧模型做不到，新模型也可能突然可以。
第二种思路是做实验。允许自己自由地玩模型，尝试有创造力、甚至没有直接商业用途的事情。它经常会给你惊喜。
过去几周，Anthropic 内部有一件事像病毒一样流行起来：有人发现可以把 OpenCV 交给 Opus 5。
哦？
然后让它画画。你可以对 Opus 说：“用 OpenCV 画出这张图。”它其实画得相当好，可以画肖像、动物和风景。
我们从来没有训练模型画画。这就是能力引出差距（elicitation gap）：只要用正确的方式要求它，它就能把事情做出来。我们只是随意玩耍、尝试一些没有直接商业用途的创意，偶然发现了这项能力。
我的假设是，今天的模型里可能还藏着几十个、几百个类似机会，只是还没有任何人意识到。
提示工程正在变成“能力引出”
这里一个重要的研究方向就是模型能力引出（model elicitation），对吧？也就是善于找出模型拥有的各种能力，并用正确的方式要求它去做事。人们怎样才能提升这种能力？换句话说，怎样变得更擅长提示工程？大家还需要投入大量精力做提示工程吗，还是它也正在改变？
我记得大约一年前，最热门的职位之一还是“提示工程师”，后来又变成了“上下文工程师”。这些概念会一波一波地来，也会一波一波地走。
今天更重要的技能，已经不太是提示工程本身，而是怎样给 Claude 一个看起来稍微超出它能力范围的难题，以及怎样让 Claude 在执行过程中验证自己的工作。
验证可能是人们最常做错、也可以说最重要的一件事。
举个例子。Claude 有一个用 Electron 构建的桌面应用。我们已经把它优化得很快，现在体验很不错；六个月前它还比较迟钝，也不太可靠，但现在已经很好用了，团队里多数人都在使用。
不过我想做个实验，看看原生应用会是什么感觉。于是我启动了一个 Claude 的 Slack 会话——这是我们的一种新产品形态，可以理解为让 Claude 直接在 Slack 里运行。
我的第一个问题是：“你能访问 GitHub 上的 macOS runner 吗？”它回答不能。于是我接入了一个 runner，让它可以通过 GitHub 启动一台 Mac 虚拟机。
然后我创建了一个空代码库，目标是用 Swift 重写 Claude 桌面应用。我问它：“你能访问这个代码库吗？”它说不能。我给它开通权限后，它说：“好了，现在可以访问了。”
接下来我只给了它这个任务：“把 Electron 应用重写成 Swift；在 Mac 虚拟机中运行 Electron 应用，给它截图，再逐像素查看并与 Swift 版本比较。在全部完成之前不要停。”
这基本就是你的全部提示词？
对，这就是我的提示词。
一个已经连续运行两周的提示词
这个任务运行了多久？
它还在运行。
你是什么时候启动的？
已经两个多星期了，大约 14 到 15 天。
我不知道现场有没有人让 Claude 为一个任务连续运行超过两周。有的话请举手……好，还真有几位。
这正是“解除束缚”的一个例子：模型今天已经能做，只需要你允许它去做。你不需要复杂花哨的东西，不需要 `/goal`，也不需要 `/loop`。这些功能会有帮助，但真正必需的只有两件事：把任务交给模型，并给它一种验证工作产出的方式，避免它卡住。之后它就会一直往前走。
在这个案例中，Claude 甚至决定自己做“直播日志”。它在公司内部创建了一个 Slack 频道，每隔几分钟就把进展截图发进去。
哇。这个提示词听起来太简单了，在场每个人似乎都能写出来。那究竟是什么把普通用户和最顶尖的 1% Claude Code 用户区分开？怎样才能学会像 Boris 一样使用 Claude Code？
也许第一条是：别听 LinkedIn 网红的，也别看 Twitter。
所有人都在寻找某种“一招制胜的怪技巧”，但那种东西不存在。
模型的正确用法是经验主义的。给它一个过难的任务；给它与你自己执行任务时同样的验证工具；观察它在哪里遇到困难。然后针对困难修复：也许需要更好的提示词，也许需要一个技能（skill）；如果它缺少上下文，就给它接入 MCP，让它能够拉取所需信息。基本就是这些。
听起来很简单。
人们往往把它想得太复杂，也倾向于过度工程化。过去构建软件系统时，我们确实必须那样做。因此，我观察那些已经编程很多年、甚至几十年的工程师，最常见的一种失败模式就是过度规定：指令写得过于具体，试图让模型严格按照自己会采用的方式完成任务。但模型并不是这样工作的。
很多人正在“反学习”过去形成的习惯，而这需要一个过程。你要逐渐学会把这个东西当作同事来对待——以它现在的智能水平，这才是合适的关系。
如何有效编排成千上万个智能体
我们继续深挖这个仍在运行的任务。你两周前启动它，它生成了多少个智能体？
我不确定，可以回头问一下那个 bot。我猜是几千个，甚至几万个。
几千个。现场有没有人写过一个提示，让任何模型生成超过一千个智能体？没有？我觉得这也是一个提示：最优秀的 Claude 用户会发起真正带来巨大杠杆的任务，背后可能有数千个智能体。
是的。
怎样做到？
有几种不同方法，最简单的是动态工作流（dynamic workflows）。这是 Claude Code 比较新的功能。你只要说“使用一个工作流”，就够了，Claude 会自动触发动态工作流。
它大体是这样工作的：我们有 Bun 运行时，把 Bun 用作沙箱，并在里面启动一个虚拟机。然后允许 Claude 启动和编排许多智能体。
它不是只运行一个智能体，也不只是让十个智能体并行。假设任务是重写代码库、对非常复杂的数据做深入分析，或构建一个需要多个阶段、甚至几十个拉取请求的复杂功能，它首先会启动一批智能体完成第一轮工作。
根据第一轮结果，它可能进入第二阶段，再启动另一批智能体验证或总结工作。然后进入第三阶段，再次向外展开。它会以一种有效的方式编排许多不同的智能体。
我的背景是函数式编程，所以我们把这套系统设计成一种“智能体代数”：智能体可以按顺序运行，也可以并行运行。Claude 在沙箱里拥有不同工具，用来编排这些智能体、高效使用 token，并完成非常复杂的工作。
这很有意思，但外界还很少有人真正写过它。它其实是一种新的测试时计算（test-time compute）。谈缩放定律、谈模型怎样变聪明时，历史上主要看神经网络规模、训练数据量和训练中投入的 FLOPs。最近又加入了测试时计算——用研究者的说法，它大致就是模型在推理时能生成多少 token。
动态工作流提供了一种新的测试时计算编排方式，也让你可以在非常困难的任务上大幅增加测试时计算。说了这么多，结论就是：它让你能够以高效、有效的方式启动数千个智能体。
第二种方法是循环（loops）和例程（routines）。循环本质上是一个在本地为 Claude 运行的 cron 任务；例程做的是同一件事，但 Claude 运行在云端，因此你可以合上笔记本电脑。
它们与动态工作流略有不同。动态工作流是把一个任务拆成许多块；循环和例程则是重复执行同一种任务，各次运行不共享上下文，但可以共享记忆。你可以让它每五分钟、每小时或每天执行一次。
我们现在已经开始让 Claude 维护自己。做法是在一个 Slack 频道中，让 Claude 启动许多不同的例程来维护自身代码库。CLI、iOS 应用、Android 应用和桌面应用都采用这种方式。
例如，其中一个例程叫“清理死代码”。它只有一句话的提示词，Claude 每天运行一次。它会利用静态和动态分析，在所有代码库里寻找死代码。我们并没有在提示词里要求它使用这些分析方法，是它自己想出来的。
让 Claude 持续维护自己的代码库
“清理死代码”例程每天都会创建一个拉取请求，删除它找到的死代码。
还有一个例程负责清理已经完成使命的实验。比如某项实验已经向 100% 的用户开放，Claude 会把实验开关从代码库里删除，并直接发布清理后的版本。
另一个例程会为测试覆盖不足的代码区域补写测试；还有一个会删除不再需要的测试，因为有些测试可能是旧模型或人类过去添加的，实际上没有什么价值。
我特别喜欢的一个例程，名字我一时想不起来了，好像叫“抽象警察”（abstraction police）。在大型代码库里，同一种抽象经常会以多个版本重复出现。仔细看，它们也许本来就应该是同一个抽象，但随着时间推移，大家出于各种原因，在代码库不同位置分别重新实现了一遍。
Claude 每天会遍历我们的所有代码库，找到这些近似重复的抽象，再把它们统一起来。
现在，我们每天大约有 20 到 30 个这样的例程在所有代码库上运行。它还没有完全做到位，但我们已经走在通过这种方式把应用维护彻底自动化的路上。
这意味着每天会有数百个、偶尔数千个智能体运行，完成过去需要几十名甚至几百名工程师才能完成的工作。工程师因此可以专注于自己真正想做的事情：发布新产品、与用户交流，以及做那些真正有趣的工作。
编程是否已经“基本解决”
从这里似乎可以得出一个很好的结论。你过去说过“编程基本已经解决了”，对吧？当每个人都能写软件时，真正卓越的构建者与其他人的区别是什么？现在大家都能发布代码，哪些品质变得最重要？
我先加一个限定：对我平时做的那类编程来说，编程已经解决了；但对所有人、所有场景而言还没有。
仍然有一些非常深的系统代码库，Claude 会遇到困难；分布式系统也是如此。还有非常细微的界面验证，例如某个元素偏了一个像素，Claude 仍然做不到完美。Opus 5 在视觉和计算机操作能力上迈出了一大步，但还不完美。
我倒想问问现场：如果你们 100% 的代码都由智能体编写，自己已经完全不手写代码，请举手……人数不少。那超过 50% 的呢？举手的人稍微少一点，也可能差不多。
所以它正在接近“解决”，而且覆盖的代码类型越来越多，这很酷。
当我观察那些最善于使用 Claude 的人时，我发现有一种非常有效的心态：经验主义。
忘掉你对过去模型的认识，也暂时放下课堂上学到的那些计算机科学理论预设。直接让模型尝试一项任务，观察它在哪里遇到困难，然后根据结果调整。模型使用已经不再是一门纯理论科学，而越来越像一门经验科学。
真正擅长的人，能够忘掉自己的先验，放下“以前试过但没成功，所以现在也不行”的判断，并愿意再次尝试。这种能力在今天非常重要，也非常容易带来成功。
计算机专业学生仍应亲手学习什么
最后一个问题。假设现场有人正在学习计算机科学，并且是在 AI 智能体编程时代之前学会编程的，那么学生今天仍然应该用困难的、老派的方式亲手学习什么？
我是以非常实践的方式学习计算机科学的。我自学编程，是为了真正解决问题。每次学习，背后都有一个具体问题。
我最早是在 TI-83 计算器上学会编程的，那还是我上中学的时候。我后来还在互联网上写了一份 TI-83 编程指南，现在可能仍然能在某个地方找到。我的第一门语言是 BASIC。
我学会在计算器上编程，是为了在数学考试中通过作弊取得更好的成绩。对一个中学生来说，那就是我能想到的最实用的问题。
后来我的成绩确实变好了。我还买了一根小型串口线，把程序传给同学，于是他们的成绩也变得很好。
再后来数学变难了，BASIC 已经解决不了那些问题。最初也许只是用 BASIC 写一个代数求解器；到了微积分，我不得不学习汇编语言，写一个更好的求解器，这样才能在微积分考试里“作弊得更好”。
因此，对我而言，编程一直是一件非常实践的事情。我给在校学生的建议也是：不要只学习计算机科学。它在智力上非常迷人，理解这些知识也很有趣，但你还要学习怎样应用它。
这种应用经常意味着创建初创公司、构建产品，培养自己的设计感和商业判断，学习数据科学，学习怎样与用户交流。还有很多其他技能；当它们与计算机科学和工程结合时，价值才真正显现出来。这些就是我认为学生仍应亲手锻炼的困难技能。
所以我来总结一下：先从为自己做一个自己想要的东西开始，然后升级到“做人们想要的东西”。
是的。
最后还有一个特别公告，你来宣布吧？
今天来到现场的每个人，都会获得 Max 20X。
很不错。
请留意邮箱里的兑换码。我非常期待看到你们会构建出什么。
我们会发邮件。现在现场应该有人去构建一个可以连续运行几个月、调动数千个智能体的东西——你们已经有账户可以尝试了。Boris，非常感谢你。
谢谢。