Boris Cherny：构建Claude Code——删除提示词，释放模型潜能

Opus 5发布后不久，Claude Code的创造者Boris Cherny在Startup School 2026上与Diana Hu对话，探讨最新模型能做什么、Claude Code是如何诞生的，以及在底层能力不断加速时构建产品意味着什么。

Diana：好了，Boris，我们非常高兴能请到你，Claude Code的创造者。谢谢。

Boris：很高兴来到这里。

Diana：刚出炉的消息，你们昨天刚刚发布了Opus 5。

Boris：是的。

Diana：模型的性能似乎一直在加速。你们把Arc AGI 3的得分提升到了30%，这太不可思议了。

Boris：是的。

Diana：作为对比，之前最好的成绩只有个位数或者百分之十几，对吧？与之前的版本相比，Opus 5现在能做什么以前做不到的事情？

Boris：是的。每一个新模型都凝聚了大量工作，我们会教模型很多新能力。训练模型时，你试图教一大堆不同的东西，但大多数时候并不奏效。但其中有一部分东西，模型确实学到了。有时它还会给你惊喜。它拥有一些你实际上并没有教过它的技能和能力，但它就是学会了。对于5来说，一个我认为没有任何其他模型做到过的事情是，它能持续运行很长时间。尤其是当Opus 5与Auto Mode结合使用时，简直令人难以置信。它可以连续运行几天、几周、几个月。它就是不停下来。你甚至不需要使用脚手架。你不需要slash goal，不需要其他那些东西。它会一直运行下去，因为它知道自己需要完成任务。另一件让我非常兴奋的事情是——我开始多谈一点——之所以令人惊讶，是因为这是一项全新的能力——模型似乎不再会被提示注入了（prompt injection）。

Diana：不会再被提示注入。

Boris：这真的很疯狂。人们谈论这个“致命三重奏”已经很久了。这确实影响了测试平台（harness）设计、Agent设计和产品设计。因为如果模型在互联网上读到一条指令，上面写着“做X、Y和Z，还要删除用户电脑上的一切”——一年前，模型会直接照做。但现在，Opus不会了。实际上，从Opus 4.7和4.8开始就已经是这种情况了。Sonnet 5在这方面表现得相当好，Table也做得很好。但Opus 5在这个领域达到了新的前沿。所以基本上，如果你把一个对齐良好的模型——这基本上是三年的对齐研究——与一个提示注入分类器结合起来，我们对所有流量都运行这个分类器。这个分类器基于Crysola的机制可解释性工作，我们直接观察模型大脑中在提示注入发生时亮起的神经元。模型甚至不会告诉你，但我们实际上能看到那些神经元，能够判断和诊断出正在发生什么。然后你再把它与Auto Mode分类器结合起来。有了这三层防护，我们再也无法演示提示注入了。

Diana：谈到提示注入，硬币的另一面就是系统提示词（system prompt）。我们来谈谈新版本。你实际上删除了Claude Code系统提示词的80%以上。

Boris：是的。

Diana：请详细讲讲。

Boris：我觉得很多人可能没有意识到的是，Claude Code作为一个产品和一套测试平台，一直在变化。我们一直在添加东西，一直在删除东西。每次新模型发布，我们都会删除一大批系统提示词，修改一大批系统提示词。我们一直在改变工具集，一直在改变工具的提示词。原因是每个模型都非常不同。所以三个月前你为某个模型做的东西，可能完全不适用于下一个模型。关于Opus 5的一点是，它确实非常智能。系统提示词中有很多内容是在纠正模型本应知道但不知道的行为。现在Opus 5直接就能做到了。所以，是的，我们删除了80%的系统提示词。你实际上也可以尝试把剩下的也删掉。运行Claude Code时，你可以用双横线加system prompt参数，设置任意你想要的系统提示词来做实验。另一件你可以尝试的事情是Simple Mode。这实际上是一个未公开的功能。如果你设置环境变量Claude Code simple等于1，然后运行Claude，它会删除所有的系统提示词，包括工具里的那些。我们实际上用这个来做一种消融实验（ablation），以判断提示词是否有用。有趣的是，没有这些提示词时，模型实际上变得更聪明了一点。这是我们一直在发现的。但当Claude Code作为产品使用时，你确实需要其中一些提示词，因为它们能帮助你使用产品，帮助产品以及模型以你作为用户所期望的方式行事。

Diana：我觉得在这个构建时代，真正令人着迷的是，你基本上为Claude打造了世界上最好的测试平台，那就是Claude Code。据我所听到的，每次发布新模型，你基本上都会删除整个代码库、删除所有提示词，然后每次都从头开始。在旧世界里，创业公司不会这么对待自己的产品。这就像每六个月按一次删除键，删除所有东西。

Boris：没错。但公平地说，我们不会删除整个代码库，但确实会删除很多。每次有新模型，在研究里我们称之为消融。这意味着删除整个系统提示词，然后逐行把它加回来，以确定每一行的影响。这就像一个评测（eval），你可以去评估。消融本质上就是评测，只不过你是通过删除东西来判断影响。我们对工具也做同样的事情。我们一直在下架工具。我们一直在删除测试平台中的代码。如果你看看今天Claude Code测试平台中的代码，几乎全部都是关于安全性、权限和静态分析的。还有一堆UI代码。我们已经把很多其他代码下架了。

Diana：你觉得这种构建Agent产品和测试平台的方式——基本上每次有新的模型发布就做消融——在座所有正在构建AI产品的人是不是都应该这么做？舒服地、勇敢地去按删除键？

Boris：百分之百。对于不在构建Agent产品、而是在使用Claude Code的人来说，每六个月，删除你的quantum D，删除你的skills，删除你的hooks。看看模型会怎么做，它可能会给你惊喜。对于Opus 5，我们确实推荐这样做——试着删除所有这些，因为模型可能不需要你为以前的模型准备的那些指令。

Diana：我们来谈谈你如何构建这个新提示词。当有新模型发布时，在座每个人都会想试试Opus 5，他们会按下删除键清空系统提示词。他们应该如何重建系统提示词？你如何搭建你的环境？

Boris：你逐块来做。第一步是删除。下一步是使用它。你不想去猜测模型需要什么指令，因为你可能猜不对。你要做的是运行它。如果你在构建一个自定义的Agent产品，你要去运行这个产品。看看它在模型上哪里失败，哪里做得好。如果你在使用Claude Code，看看它在你的代码库上哪里表现好，或者在哪里被架构或其他东西绊住。只有当你看到它在同一件事上反复出错时，那才是你把它加回来的时候。但你不想太早加回来。记住，模型每次使用都会读到这条指令。你确实要确保模型需要这条指令。我觉得这就是构建在模型之上最疯狂的地方。它与我做过的所有工程都不一样。过去，当你在系统之上构建时，你建造那些庞大而优美的系统，你在前期仔细思考系统设计。你有一套庞大的单元测试。你考虑所有事情。重新架构是一个大工程，有时要花几个月。我在大公司做过耗时数年的重新架构项目。模型不是这样的。思考它的方式几乎就像对待一个活的生物，一种更有机的东西。每一代模型行为都会不同，性格也会有细微差异。你必须花时间去了解它，然后根据这一点来调整测试平台。这非常依赖于经验和科学。你必须以科学的心态来对待：尝试一些东西，观察结果，然后在此基础上迭代。如果

Diana：你现在就在这个世界里构建，那么什么才是稳定的？评测（evals）是不是你会从之前的模型保留下来、并在每个新模型版本中继续使用的东西？

Boris：我们会一直用，直到评测被刷满为止。

Diana：所以这就是给所有人的建议。代码和系统提示词——如果你想站在最前沿，获得模型的最大能力，你必须删除这些东西。但评测是不变的，你基本上可以不断往里追加。

Boris：是的，你不断追加。实际情况是——说实话，我甚至不会说得那么绝对。我认为评测比测试平台的寿命稍微长一点，但没有长多少。一个评测可能存活一到三代模型。但现在我们处在指数曲线上。模型改进得太快了。很多时候我们直接把评测刷爆了，然后不得不扔掉它，想出新的评测。这只是过程的一部分。再说一次，关键在于经验主义。你必须使用产品，你必须使用模型，你必须看到它在哪里挣扎。基于这些，那就是你应该构建的评测集。

Diana：我记得你描述过的一个术语——如何在Claude之上构建最好的Agent产品——就是“给Claude解绑”（unhobbling）这个概念。请详细讲讲这意味着什么。

Boris：是的。"hobbling“（束缚）是研究中的一个概念，指模型正在做某件事，而你在妨碍它。有一种思考方式我非常喜欢，在构建产品时非常有用，叫做”产品过剩“（product overhang）。这个想法是，今天的模型——不是未来的模型，而是今天的模型——能够做各种各样我们还没有实现的事情。模型有太多这样的能力是人们没有意识到的。比如使用特定工具、使用特定语言、解决特定类型问题、以我们认为超出模型能力范围的特定方式做事。这种过剩的存在是因为模型在每一代都能做到这些，但往往没有一款产品能让模型做到、能让它表达这种能力。另一方面，经常发生的情况是产品妨碍了模型。这种妨碍我们称之为hobbling，而没有从模型中激发出正确的行为，我们称之为产品过剩。所以这是一枚硬币的两面。Claude Code最初就是一个例子。我刚着手做这个项目时，大约是一年半到两年前。当时是Sonnet 3.5。那时候，那是一个令人难以置信的编码模型，是当时存在的最高水平的编码模型。如今，以现代标准来看，它是一个相当糟糕的编码模型。但我想那是我们在Anthropic构建的第一个伟大的编码模型。当时，如果你看看当时的编码产品，它们在做什么？它们在做单行自动补全。有时候做多行自动补全。那已经是个新想法了。它们还做聊天，你可以和Agent对话，但没有写入权限。你只能读。你可以询问代码库的情况。所以当时的感觉是，没有一个产品能够充分激发模型一次编写整个函数、整个文件的能力。当时还没到整个功能模块，我们还没到那一步，但可能是整个文件。那是当时的模型能力水平。所以Claude Code的想法就是：好吧，我们认为模型大概能做到这一点。如果我们去掉所有脚手架，只给模型最简单的测试平台，让它能一次写一个完整的文件、构建一个完整的功能呢？基本上就是这样。这就是当时的产品过剩。模型有能力做某件事，而一切都挡在它的路上。我认为如今有了现代模型，存在大量的产品过剩，而我没有看到创业公司去抓住它。我认为确实有人在思考这些问题，但激发出模型这些令人惊叹、有趣并且有商业价值的行为，有着巨大的机会。

Diana：我觉得这对在座的每个人来说都是一个非常特别的洞见。基本上，如果你们弄清楚了如何给模型解绑，你们所有人都能创造出下一个Claude Code，因为这实际上就是Claude Code诞生的故事。你给Sonnet 3.5解绑，因为之前所有的迭代版本都让模型在IDE里变得非常僵化。而Claude Code是最早给予模型完整终端访问权的实例之一。

Boris：是的。

Diana：然后这就创造出了这个不可思议的产品，而且一直在持续进化。那么让我们谈谈有哪些领域，在座的未来创始人们应该如何思考给Claude解绑和解决产品过剩的问题？

Boris：有几件事我会考虑。一是你应该给模型稍微超出你认为它能力范围的任务。我发现一个非常常见的错误是，人们使用Claude Code、使用Claude时，给了它过于具体的指令。他们会说：”我想要你做这个，但我要你这样做、这样做、这样做。你必须先做一，然后二，然后三，然后四。“对现代模型来说，这真的不是正确做法。你要放高层次一点。你要描述任务，描述护栏，描述退出标准，然后放手让模型去做，过一会儿再回来。我觉得它会让你惊讶。再说一次，这六个月前还不管用，但今天确实管用了。

Diana：你能举一些例子吗？那些人们应该去探索的、模型现在能做而六个月前不能做的具有挑战性的任务或能力？

Boris：是的。那么，好吧。一个例子是，模型现在基本上可以把任何代码库从一种语言重写成另一种语言。这简直太疯狂了。这种工作如果由工程师来做，需要花很长时间，而现在模型做得相当快。举个例子，Claude Code构建在Bun JavaScript运行时之上。那是一个开源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的一个功能，本质上让你编排几十个、几百个、几千个Agent来高效地完成工作。它运行了11天，重写了整个代码库。

Diana：而且这是一次性完成的？

Boris：是一次性的，有——嗯，不，不是一次性的，但有引导（steering）。有引导。但之前的模型就是做不到，即使有引导也不行。那根本不可能。

Diana：只有11天。天哪。这在过去，即使是最好的工程师团队，也需要好几个月、甚至好几年吧？

Boris：肯定超过一年。是的，超过一年。这超过了10万行。JavaScript运行时真的非常复杂，里面有很多东西。而且，是的，它跑通了。现在已经投入生产了。现在你运行Claude Code时用的就是它。所以这是一个例子。我再举一个关于产品过剩的例子。这是一个实际用例，你在解决一个问题——一个商业问题、工程问题或产品问题。你应该不断把最新模型投到这个问题上，看看它是不是就能解决了。因为即使之前的模型做不到，新模型可能做到。我认为第二种思考方式是实验。给自己自由去玩弄模型，做有创意的事情。它经常会让你惊讶。最近几周在Anthropic内部非常流行、已经火遍全公司的一件事是，有人发现你可以给Opus 5一个OpenCV，让它画画。你可以这样做：问Opus”嘿，用OpenCV画这幅图。“它实际上画得相当好。它能画肖像，能画动物，能画风景。我们没有训练模型去画画。这就是一个”引导差距“（solicitation gap）。如果你用正确的方式要求它，它就能做到。我们发现这个纯属偶然，就是在那里玩，尝试一些没有直接商业应用的有创意的东西。但很有趣。我的假设是，今天的模型身上可能有几十个、几百个这样的机会，还没有人意识到。

Diana：而这方面的大研究领域基本上就是模型引导（model elicitation），对吧？变得非常擅长找出所有这些能力，并让模型去做正确的事情，对吗？

Boris：是的。

Diana：人们如何在这方面变得更好？实际上，人们如何更好地进行提示工程（prompt engineering）？人们还需要做很多提示工程吗？还是说这也在变化？请告诉我们这个领域的发展方向。

Boris：是的。我记得一年前，最热门的职位之一是提示工程师（prompt engineer）。后来它变了，我觉得变成了上下文工程师（context engineer）。所以有这些一波一波的变化，我认为它们会来了又去。我认为如今的技能不太关乎提示工程，更多在于弄清楚如何给Claude一个看起来有点太难的任务。然后如何让Claude在过程中能够验证自己的工作。验证可能是最重要的一件事，而大部分人在这一点上做得不对。其中一个例子是——我们有一个Claude的桌面应用，是用Electron构建的。我们让它变得相当快了。现在体验非常棒。六个月前它还非常卡顿，不太可靠。现在它非常棒。这是团队里大多数人都在用的工具。作为一项实验，我想看看如果它是原生应用会是什么感觉。所以我做的是，我开启了一个Claude Tag会话。Claude Tag是我们的一个新产品，就是跑在Slack里的Claude。我的第一个问题是：”嘿，Tag，你有GitHub上的Mac OS runner的访问权限吗？“它说没有。然后我接了一个runner。它就能用GitHub启动一个Mac虚拟机了。我的第二个问题是——我创建了一个空的代码库，是一个用Swift重写的Claude桌面应用框架。我问：”你能访问这个代码库吗？“它说不能。然后我给了它访问权限，它说：”好的，太好了。现在我有权限了。“然后我说：”好的，现在我要你做的是，我要你用Swift重写这个Electron应用。我要你在Mac虚拟机里运行这个Electron应用，截图，然后逐像素地看。把它和Swift版本对比。不完成不要停下来。“

Diana：那基本上就是你的提示词？

Boris：那就是我的提示词。

Diana：这跑了多久？

Boris：它还在跑。

Diana：你什么时候开始的？

Boris：已经两周多一点了。大概14天、15天。

Diana：好吧。不知道在座有没有人让Claude连续跑一个任务超过两周。我不知道。举个手。在座有人吗？

Boris：这就是关于引导（elicitation）。这就是那些”模型今天就能做到“的例子之一。你只需要放手让它做。你不需要那些花哨的东西。你不需要slash go。你不需要slash loop。这些有帮助。但你真正需要的是给模型任务，给它一种验证工作输出的方式，这样它就不会卡住，然后它就会一直跑下去。实际上在这个案例中，Claude还决定做实时播报。它做的是在内部创建了一个Slack频道，然后每隔几分钟就发布一张进度截图。

Diana：哇。

Diana：这个提示词听起来太简单了。在座每个人都能做到。那么，我想知道，是什么区分了在座这些人中能成为前1%Claude Code用户的人？人们怎样才能学会像Boris一样使用Claude Code？

Boris：也许不要听LinkedIn上那些网红的话。

Diana：不要听他们的。不要看Twitter。

Boris：这就是关于模型的关键。我觉得每个人都在寻找某个神奇的诀窍。那不存在。没有那样的东西。模型的工作方式是你必须用经验主义的方式去对待它。你必须给它一个太难的任务。你必须给它验证工作的工具，就像你验证自己工作那样，就像你自己在做事时那样。你必须看到它在哪里挣扎，然后你必须修复这个问题——用更好的提示词，或者用skill。如果模型缺少上下文，给它一个MCP，让它能拉取所需的上下文。基本上就是这样。

Diana：听起来非常简单。

Boris：我觉得人们倾向于想太多。人们倾向于过度工程化，因为在很多方面，过去我们构建系统时，你必须那样做。所以当我看到那些编程很久的工程师——几年或几十年的——这是一个非常非常常见的失败模式：试图过度规定、过度具体，想让模型以你本来会做的方式完全照做任务。那不是模型的运作方式。但我认为很多人在摆脱这种思维，而摆脱它是一个过程。去弄清楚如何像对待同事那样对待这个东西，也是一个过程。我认为它现在的智能水平就是这样的。

Diana：作为其中的一部分，让我们深入谈谈这个从你两周前启动到现在仍在运行的任务。它生成了多少个Agent？

Boris：我不确定。我可以问问Claude，然后回来告诉你。我猜是几千个、几万个……

Diana：几千个。在座有人向任何模型发出过生成超过一千个Agent的提示词吗？没有。我想这是又一个技巧。最好的Claude用户能够生成真正给你带来巨大杠杆效应的任务，比如几千个Agent。

Boris：是的。

Diana：你是怎么做到的？

Boris：有几种不同的方式。最简单的是动态工作流（dynamic workflows）。要使用动态工作流，这是Claude Code里一个相当新的功能。你只需要说”使用一个工作流“。就这样。然后Claude就会触发动态工作流。动态工作流是什么？基本上我们有Bun运行时。我们用Bun作为沙箱，在Bun里启动一个虚拟机。我们让Claude启动很多Agent并编排它们。它不只是做一个Agent，也不只是做10个并行Agent。它可能会做的是——假设任务是重写代码库，或者对非常复杂的数据做深入的数据分析，或者构建一个需要多个阶段、可能涉及几十个pull request的非常复杂的功能——它会启动一批Agent来做第一遍。基于那个结果，它可能会做第二步，用另一组Agent来验证工作或总结工作。然后它可能会做第三阶段，再次发散。所以它会高效地编排一堆不同的Agent。我的背景是函数式编程。所以我们设计这个的方式，本质上就是Agent的代数。有办法按顺序运行Agent，有办法并行运行Agent。Claude有不同的工具来在沙箱内编排这些Agent，以高效地使用token来做非常非常复杂的工作。这挺酷的，而且确实没太多人写过。这实际上是测试时计算（test time compute）的一种新形式。当我们谈论缩放定律，谈论模型随时间推移变得更智能时，历史上它是神经网络大小、训练数据量和训练时投入的FLOPs的函数。然后最近我们又加入了测试时计算。这基本上是研究者用花哨的方式说”它生成了多少token？“现在动态工作流本质上是一种编排测试时计算的新方式，是真正大幅提升你用来完成困难任务的测试时计算量的新方式。所以绕了一大圈，就是说这是启动数千个Agent的、高效且有效的一种方式。第二种方式是loops和routines。Loop本质上是一个在本地为Claude运行的cron任务。Routine是同样的东西，但在云端运行，所以你可以合上笔记本电脑。这略有不同，因为对于动态工作流，它是一个任务，你把它分解成块。对于loops和routines，它是一类重复性任务，不共享上下文，但可能共享记忆。你一遍又一遍地做。你可以每小时做一次，每五分钟做一次，每天做一次。我们已经开始做的一件事是，我们现在让Claude自我维护。我们的做法是，我们有一个Slack频道，让Claude启动一堆不同的routines来维护自己的代码库。我们实际上对CLI、iOS应用、Android应用、桌面应用都这么做。例如，一个routine是清理死代码。这只是一个提示词——只有一个句子。Claude每天运行这个。它会用静态和动态分析在所有代码库中查找死代码。我们没有给它这个提示，它自己想出来的。它每天会提出pull request来删除死代码。另一个例子是发布应该上线的实验。实验已经100%放量了。它会把它从代码库中删除，然后直接发布。另一个是为代码库中需要测试覆盖的地方编写测试。还有一个是删除不需要存在的测试，因为那些是老模型或某些时候的人添加的无用测试。一个我非常喜欢的是——我忘了我们叫它什么了。我想我们叫它”抽象警察“（abstraction police）。想法是，在一个大型代码库中，经常有相同的抽象出现多次。如果你眯起眼睛看，实际上它也许应该是同一个抽象，但随着时间的推移，出于某种原因，你在代码库的不同部分以多种方式重建了它。所以Claude每天出去，遍历我们所有的代码库，找到这些几乎重复的抽象并把它们统一起来。现在我们每天有大概20到30个这样的routines在我们所有的代码库中运行。还没有完全到位，但我们正走在通过这种方式完全自动化应用维护的路上。这又是每天运行数百个Agent，有时每天数千个Agent。它在做几十个或几百个工程师的工作——这就是过去做这种工作需要的人力。这意味着工程师可以去做他们真正想做的事，也就是发布新产品、和用户交流、做那些真正有趣的事情。

Diana：我想下一个结论是，你过去提到过的，基本上编码问题已经解决了，对吧？你提到过这个。我很好奇，现在既然每个人都能写软件了，是什么让杰出的构建者与众不同？现在每个人都能发布代码了，那些品质是什么？

Boris：我要加一个前提。编码问题对于我所做的那类编码来说已经解决了。并不是对所有人都解决了。仍然有一些非常深层的系统级代码库，Claude仍然会在那里挣扎。有些分布式系统，Claude仍然会挣扎。还有那些真正较真的UI验证，比如某处偏了一个像素之类的。Claude在这方面还不完美。Opus 5在视觉和计算机使用上是一个巨大的飞跃，但还不完美。但事实上我很好奇，在座的人，如果你的代码100%是由Agent编写的，请举手。你不再手写任何代码了。这已经很好了。好的。那超过50%呢？手稍微少了一点，也许差不多。是的。所以我认为它正在接近那个目标。越来越多的代码类型正在被解决，这很酷。当我想到最擅长使用Claude的人，我认为有一种心态是非常有效的。那就是经验主义。忘记你了解到的关于过去模型的一切。忘记你在课堂上学到的所有计算机科学理论。看看模型，试着做一个任务，看它在哪里挣扎，然后在此基础上调整。所以它很大程度上已经变成了——不是理论科学，而是经验科学。我认为那些真正擅长这一点的人，那些真正擅长忘记自己先验、放下”以前不管用"的想法、并愿意再试一次的人——这种技能现在非常非常有效。

Diana：现在我的最后一个问题是，基于我们讨论的一切，如果这里有人正在学习计算机科学，而且你在AI Agent编码时代之前就学会了编程，那么学生仍然应该以艰苦的方式、传统的方式学习什么？

Boris：对我来说，我是通过实践学习计算机科学的。我通过自学编程来解决问题。每次我这么做，都是为了解决一个我面临的具体问题。我实际上最早是在TI-83计算器上学会编程的。那是在初中。我最终在互联网上写了一份TI-83计算器编程指南。它现在还在互联网某个角落。那是BASIC——那是我的第一门语言。我在计算器上学习编程，是为了在数学考试中作弊来取得更好的成绩。所以这是关于实用性的。对初中生的我来说，那是我能想到的最实用的事情。我最终取得了好成绩，然后我弄了一条小串口线，把程序传给我的同学们，他们也取得了很好的成绩。然后数学变难了一点。那不再是能用BASIC解决的问题了。所以我从那个用BASIC编写的代数求解器出发，必须解决更难的问题。等我们进入微积分之后，我不得不运行汇编，这样我才能写出更好的求解器，让我在微积分考试中更好地作弊。对我来说，编程一直是非常实用的。我想这始终是我给学校里的人的建议：不仅要学习计算机科学——那在智识上令人着迷，了解它确实很有趣——还要学习如何应用它。这通常关系到创办初创公司，关系到构建产品，关系到发展你自己的设计感、发展你的商业感、学习如何做数据科学、学习如何与用户交流。所有这些技能。当你把它们与计算机科学和工程结合起来时，那就变得真正有价值了。所以那些是我仍然会以手工方式去练的硬技能。

Diana：所以如果我听到的可以总结为，先为自己做一件你想要的东西，然后升级，做出人们想要的东西。

Boris：是的。

Diana：我们还有一个最后的特别宣布，Boris。最后一件事。

Boris：是的。今天在座的每个人，你们都将获得Max 20X。

Diana：太不可思议了。

Boris：请留意邮件里的报价。我迫不及待想看到你们构建的东西。

Diana：所以我很好奇，既然你们现在已经有这样的账户去做了，在座的某个人应该构建一个能运行好几个月、有数千个Agent的东西。那就这样，非常感谢你，Boris。

Boris：谢谢。