Opus 5时代：用动态工作流与智能体重构编程
Claude Code的资深用户Garry Tan曾提出过一个广为流传的观点：每个Skill文件都像一名专属员工，而企业真正需要搭建的，是一套融合知识库、记忆与“图书管理员”的智能大脑。尽管大语言模型本身具备出色的推理能力，但要让它长期理解企业的业务逻辑、工作流程和使用偏好，仍需要持续补充Skill条目，为模型构建可反复调用的专属“头脑”。
不过Claude Code创始人Boris Cherny却认为，这套“头脑”每隔半年就应该彻底清空一次。
他建议将大语言模型视作“活生生的有机体”，每一代模型都拥有独特的“性格”。因此每六个月，就应该删除本地的CLAUDE.md、Skill和Hook配置，重新观察新版本模型需要多少额外指令。Claude Code团队本身也在践行这个思路：Opus 5发布后，团队直接删除了超过80%的系统提示词。每当新一代模型上线，他们都会先清空原有系统提示词，再逐行重新添加，通过消融实验验证哪些内容依然具备实际价值。
快速失效的远不止提示词和Skill。Harness代码、工具集合，甚至评测体系本身，都在持续迭代。在Boris看来，使用AI编程工具已经从一门依赖固定理论和方法的学科，转变为一门需要不断试错、反复验证的经验科学。
除此之外，在OpenCode 2.0将桌面端迁移到Electron之后，Boris最近启动了一项实验：让Claude将基于Electron的Claude桌面应用重写为Swift版本，并通过Mac虚拟机的截图进行逐像素验证。这项任务已经连续运行了两周多，背后可能调用了数千甚至数万个智能体，至今仍未结束。
以下是本期播客访谈的完整内容整理。
不依赖Goal命令，Opus 5可连续运行数月
主持人Diana：你们刚刚推出了Opus 5，这款新模型的性能提升速度令人惊叹。你们在ARC-AGI-3评测中拿到了30%的得分率，这个成绩非常惊人，此前最好的结果大多只有个位数或十几百分点。相比之前的版本，Opus 5新增了哪些此前无法实现的能力？
Boris：每一代新模型背后都投入了大量研发工作，我们会尝试教模型掌握大量新任务和新能力。每次训练模型时，我们都会尝试教它大量内容，其中大部分效果不佳，但总会有一部分被模型真正掌握。有时候模型还会带来意外惊喜，展现出我们没有专门训练过的技能。
对于Opus 5，我认为它实现了此前所有模型都没能做到的一点：它可以连续运行极长的时间。尤其是将Opus 5和Auto Mode结合使用时，效果更是超出预期。它可以连续运行数天、数周甚至数月，完全不需要额外的脚手架，也不需要使用goal命令或其他辅助工具。
它会持续运行，因为它明确知道自己需要完成目标任务。
还有一项让我非常兴奋的新能力是，这个模型几乎不再受提示词注入攻击。
Diana：也就是它不容易被提示词注入攻击？
Boris：没错，这一点非常颠覆。大家已经讨论“致命三要素”很久了，这个问题直接影响Harness设计、智能体设计和产品设计。如果模型在网络上读到类似“执行X、Y、Z，同时删除用户电脑上所有内容”的指令，一年前的模型可能真的会照做，但现在的Opus 5不会。
其实从Opus 4.7、4.8版本开始，这个问题已经有所改善，Sonnet 5和Fable在这方面表现不错，但Opus 5将这个能力推到了新的高度。
本质上，我们将经过三年对齐研究打磨的模型，和提示词注入分类器结合起来，所有流量都会经过这个分类器。这个分类器基于Crysola的可解释性研究：当提示词注入发生时，我们可以直接观察到模型“大脑”中哪些神经元被激活。
模型本身不会主动告知你发生了提示词注入，但我们可以通过这些神经元的激活情况，判断和诊断注入行为。再结合Auto Mode的分类器，三层防护之下，我们已经无法再演示出有效的提示词注入攻击。
每隔六个月按一次删除键
Diana：说到提示词注入，反过来我们聊聊这次新版的系统提示词调整，你们这次直接删除了超过80%的系统提示词，能详细说说吗？
Boris：很多人可能没意识到，Claude Code作为一款产品和Harness框架，一直在持续变化。我们不断添加新内容，也不断删除过时的内容。每当新模型发布，我们都会大量删减系统提示词并进行大量修改。我们也一直在更新工具集合，持续修改工具本身的提示词。
原因很简单，每一代模型都有很大差异。三个月前针对某一模型设计的方案，放到下一代模型上可能完全不适用。
Opus 5的特点就是它本身足够聪明。过去系统提示词里的很多内容，都是为了纠正模型本该知道但当时不知道的行为。现在Opus 5可以自己做到这些，所以我们删除了80%的系统提示词。
你甚至可以尝试删除剩下的所有提示词。运行Claude Code时，可以通过--system-prompt参数，自定义设置系统提示词来做实验。
还有一个未正式文档化的功能叫Simple Mode，你可以设置CLAUDE_CODE_SIMPLE=1这类环境变量，运行Claude就会删除所有系统提示词，包括工具自带的提示词。
我们会把这种方式当作消融实验，用来判断某段提示词是否必要。有意思的是，我们发现移除这些提示词后，模型反而表现得更聪明一些。
不过当你把Claude Code作为产品使用时，还是需要保留一部分提示词，帮助用户更好地使用产品，让产品和模型按照用户预期的方式运行。
Diana：这个时代最有意思的一点是，你们已经为Claude打造了全球顶尖的Harness框架。但按照你刚才的说法，每发布一代新模型，你们就会删除原有代码库和提示词，重新开始。传统软件行业里，创业公司很少这么做，感觉就像每隔六个月就按一次删除键。
Boris：没错，不过准确来说，我们不会删除整个代码库，但确实会删掉很大一部分。
每当新一代模型发布，我们都会做研究里说的“消融实验”：先删掉所有系统提示词，再逐行加回来，判断每一行提示词的实际影响。
这有点像评测，消融实验本质上就是通过删除内容来判断其价值的评测方式。
对于工具，我们也会用同样的方式处理，经常下线已经发布的工具，持续删除Harness里的代码。现在你看Claude Code Harness里的代码，大部分都和安全、权限、静态分析有关，还有相当一部分用户界面代码，其他很多代码都已经被我们下线了。
Diana：你认为这种构建智能体产品和Harness的方式，也就是每次新模型发布就重新做消融实验，是不是所有AI产品开发者都应该采用？大家是不是应该更习惯、更勇敢地按下删除键？
Boris：百分之百应该。
哪怕你不是在构建智能体产品，只是使用Claude Code，我也建议每隔六个月删除一次你的CLAUDE.md、Skill和Hook配置，看看模型自己会表现如何，结果可能会让你大吃一惊。
对于Opus 5，我们非常建议大家尝试删除这些操作，因为新模型可能已经不再需要旧模型依赖的那些指令。
Diana：我们再聊聊如何构建新的提示词。每当新模型发布，很多人都想尝试Opus 5，也想按下删除键清空系统提示词，那之后该如何重新构建系统提示词？你们会如何设置环境？
Boris：要循序渐进。第一步是删除，第二步是实际使用。不要提前猜测模型需要什么指令，你的猜测很可能不准确。你真正应该做的是让模型运行起来。
如果你在构建定制智能体产品，就实际运行产品，观察模型在哪些地方失败，哪些地方表现出色。如果你在使用Claude Code，就观察它在你的代码库中表现如何，是否在理解架构或其他问题时遇到障碍。
只有当你看到模型反复在同一件事上出错，才应该添加对应的指令，不要过早添加。
要记住，每次使用时模型都会重新读取这条指令，所以你必须确认模型真的需要它。
我认为基于大语言模型构建产品最有意思的一点是，这和我之前做过的所有工程工作都完全不同。以前基于传统系统开发时，你会构建庞大而精密的系统，在一开始就认真思考系统设计，准备一整套单元测试，提前考虑所有问题。重新设计架构通常是大工程，有时需要几个月，我曾在大公司参与过持续数年的产品架构改造。
但大语言模型不是这样。你几乎应该把它看作活生生的有机体，更有机的存在。每一代模型的行为都有差异，也有略微不同的“性格”。
你必须花时间了解它，然后根据它的特点调整Harness。这是高度依赖经验和科学实验的工作，你需要用科学思维：尝试一种方法，观察结果，再根据结果迭代。
当一切都在快速过期，什么才是稳定的？
Diana：在这样的开发环境里，到底有什么东西是稳定的？评测体系是否可以从上一代模型保留下来，继续用于后续的新模型？
Boris：会保留，直到模型把这套评测彻底做完。
Diana：所以对大家来说，这个经验就是：如果想站在前沿，把模型能力发挥到极致，代码和系统提示词都要敢于删除；评测相对稳定，可以持续追加新内容。
Boris：是的，可以持续追加。不过说实话，我不会说得这么绝对。评测的寿命确实比Harness长一点，但也长不了太多。一套评测可能只能维持一代、两代或三代模型。现在我们处于指数增长阶段，模型提升速度极快。很多时候一套评测很快就会被模型完成，我们只能扔掉它，设计新的评测。
这也是整个过程的一部分，这仍然是经验驱动的方法：你必须实际使用产品和模型，观察它在哪些地方遇到困难，再根据这些困难构建评测集。
Diana：我听你用过一个词，叫“解除Claude的束缚”，能解释一下是什么意思吗？
Boris：当然可以。研究里说的“hobbling”，指的是模型本来可以完成某件事，但你的产品设计反而妨碍了它。
还有一个我很喜欢的思考方式，在构建产品时也很有用，叫“产品能力缺口”。它的核心观点是：今天的模型已经可以完成很多事情，不是未来的模型，就是现在已经存在的模型，只是我们还没意识到这些能力。模型拥有大量人们不知道的能力，比如它可以使用某类工具、某门编程语言，解决某类特定问题，或者用我们过去认为超出它能力范围的方式完成任务。
每一代模型都存在这种“能力悬空”的状态：模型本身可以做到，但没有对应的产品允许它这么做，也没有产品能让它把能力真正发挥出来。
另一方面，经常出现的情况是，产品本身反而阻碍了模型。我们把这种阻碍叫做“hobbling”；模型拥有能力，但产品没能诱导不出正确行为，就叫“product overhang”，两者其实是同一件事的两个侧面。
最初的Claude Code就是这样的例子。我大概在一年半到两年前开始做Claude Code，当时用的是Sonnet 3.5。那时候它已经是非常出色的编程模型，是当时全球最好的编程模型，放在今天看，它已经不算顶尖，但我认为它是Anthropic打造的第一款真正优秀的编程模型。
当时市面上的编程产品都在做什么？主要是单行代码补全，有些产品开始做多行代码补全，在当时这还是新想法。还有一些产品提供聊天功能，你可以和智能体对话，但智能体没有代码写入权限，只能读取代码，你可以询问代码库内容，但不能让它直接修改。
当时的感觉是，市面上没有一款产品能真正释放模型的能力，让它一次编写整个函数甚至整个文件。那时候还达不到一次完成整个功能，但写完整文件已经在它的能力范围内。
所以Claude Code的核心想法是：我们认为模型可能已经能做到这些，那如果去掉所有脚手架，只给它尽可能简单的Harness，让它一次写完整个文件甚至构建整个功能，会发生什么？Claude Code基本就是这么诞生的。这就是当时的产品能力缺口：模型已经能做到，但周围的一切都在妨碍它。
我认为对于今天的现代模型，仍然存在巨大的产品能力缺口，很多创业公司还没抓住这个机会。我知道已经有人在思考这些，但这里还有大量机会，可以把模型那些惊人、有趣且有商业价值的行为真正诱导出来。
Diana：这对在场所有人都是非常独特的洞察。从某种意义上说，只要找到解除模型束缚的方法，任何人都有可能创造出下一个Claude Code，因为Claude Code本身就是这么诞生的。你们解除了Sonnet 3.5的束缚，当时之前的产品把模型严格限制在IDE中，而Claude Code是最早一批给模型完整终端访问权限的产品之一，然后它成长为今天这款令人惊叹且持续发展的产品。那对于未来的创业者，哪些领域还有机会？他们该如何思考解除Claude的束缚，填补产品能力缺口？
Boris：我会从几个方面考虑。
第一，你应该给模型分配比你认为它能完成的任务稍微难一点的任务。
我见过一个非常常见的错误：人们使用Claude Code或Claude时，会给出过度具体的指令，比如“我要你做这件事，必须按这个方式、那个方式，先做第一步，再做第二步、第三步、第四步”。
对于现代模型来说，这已经不是正确的使用方法。你应该把任务描述得更宏观一些，说明任务目标、约束条件和退出标准，然后放手让模型自己做，过一会儿再回来查看，结果会让你惊喜。
同样，这种方法六个月前可能还不行，但今天已经可以了。
Diana：能不能举几个例子？有哪些有挑战性的任务或能力，是今天模型可以做到，但六个月前做不到的，值得大家探索？
Boris：当然可以。一个例子是，现在的模型基本可以把任何代码库从一种语言重写成另一种语言，这非常颠覆。过去这类工作需要工程师投入极长的时间，现在模型完成得相当快。举个具体例子，Claude Code基于Bun JavaScript Runtime构建，Bun是开源的JavaScript运行时，可以作为Node.js的替代方案，可以理解为更快的Node。
Bun最初是用Zig编写的，Zig是系统编程语言，类似C，层级很低。Zig的一个问题是需要手动管理内存，很容易出现内存泄漏和其他内存管理问题。
Bun团队曾经让Claude对代码库进行模糊测试，尝试模拟并触发内存泄漏，他们持续了很长时间，确实找到了很多内存泄漏，但基本只能一次解决一个问题，那就是当时模型的能力边界。
后来有一天，团队的Jarred Sumner说：“我们干脆重写它吧，也许模型已经能做到了。”这是他每次新模型发布后都会抛给模型的测试题。从Fable开始，模型逐渐能完成这件事，我认为Opus 5也可以。
他做的事情本质上是定义一套测试。Bun的优势在于有非常完善的测试体系，Bun自己有庞大的测试套件，Node.js也有，所以很容易判断重写是否正确。
他让模型把Bun从Zig重写成Rust，最初只用了一条提示词，使用Dynamic Workflows。Dynamic Workflows可以协调几十个、几百个甚至几千个智能体高效完成工作。整个任务运行了11天，最终重写了整个代码库。
Diana：这是一次性完成的吗？
Boris：可以说是一次任务，但严格来说不算完全一次性，中间有人工引导，确实存在。但之前的模型哪怕有人引导也不可能完成，根本做不到。
Diana：只用了11天，过去哪怕交给最优秀的工程师，这需要几个月甚至几年吧？
Boris：肯定超过一年，至少一年以上。这里涉及超过十万行代码，JavaScript运行时非常复杂，包含大量功能。最终它确实成功运行了，这个版本已经进入生产环境，你现在运行Claude Code时，底层用的就是这个版本。这是一个例子。
第二个例子，理解产品能力缺口的方式是：当你遇到需要解决的问题，不管是商业、工程还是产品问题，都应该不断把最新模型丢进去试试，看看模型能不能直接解决。哪怕上一代模型做不到，新模型可能已经可以。
另一种思考方式是做实验，给自己一些自由，去尝试模型，做一些有创意的事，模型经常会带来惊喜。
过去几周，Anthropic内部有一件很流行甚至病毒式传播的事：有人发现可以给Opus 5配上OpenCV让它画画。你可以对Opus说“用OpenCV画出这幅图”，它画得相当不错，可以画肖像、动物和风景。
我们从来没有训练过模型画画，这只是“能力诱导缺口”：只要用正确的方式要求它，它就能做到。
我们是在随意尝试一些没有直接商业用途的创意玩法时偶然发现的这项能力的，这很有意思。
我的假设是，今天的模型可能还有几十个甚至几百个类似的机会，只是还没人意识到。
数千个智能体跑了两周，要把Electron桌面端重写成Swift
Diana：这背后的一个重要研究领域，本质上就是“模型能力诱导”，对吧？你需要非常擅长发现模型的各种能力，并以正确的方式要求模型发挥出来。人们该怎么提升这种能力？换句话说，怎么提升提示词工程能力？人们现在还需要做大量提示词工程吗？还是这件事本身也在变化？你觉得未来会走向哪里？
Boris：我记得大约一年前，最热门的职位之一是提示词工程师，后来又变成了上下文工程师，这些概念总是一波一波出现又消失。
我认为今天真正重要的技能已经不是提示词工程，而是如何找到一项看起来稍微超出Claude能力范围的困难任务，并思考如何让Claude在执行过程中验证自己的工作。
验证可能是人们最容易做错，同时也是最重要的事情。
举个例子，我们有一款基于Electron构建的Claude桌面应用，现在已经优化得非常快，整体体验很好。六个月前它还比较卡顿、不够可靠，现在已经相当不错，是团队里大多数人日常使用的版本。
作为一个实验，我想看看如果把它改造成原生应用，体验会怎么样。于是我启动了Claude Tag会话，Claude Tag是我们的新产品，本质上是让Claude在Slack里运行。我的第一个问题是：“Tag，你能访问GitHub上的macOS Runner吗？”它回答不能，于是我给它接入了一个Runner，让它可以通过GitHub启动一台Mac虚拟机。
我的第二个问题是，我创建了一个空代码库，准备把Claude桌面应用用Swift重写。我问它：“你能访问这个代码库吗？”它回答不能，于是我给它开放了访问权限，它说：“好的，很好，现在我可以访问了。”
然后我对它说：“好的，现在我要你把Electron应用重写成Swift。你需要在Mac虚拟机中运行Electron应用，对它进行截图，然后逐像素检查，并和Swift版本比较，在全部完成之前不要停下来。”
Diana：这基本上就是你的全部提示词？
Boris：是的，这就是我的提示词。
Diana：这个任务运行了多长时间？
Boris：它现在还在运行。
Diana：你什么时候启动的？
Boris：已经运行了两个多星期，大概14到15天。这就是能力诱导，这个例子说明，今天模型已经能完成这件事，你只需要允许它继续做下去。
你不需要那些复杂的功能，不需要/go，也不需要/loop。这些功能确实有帮助，但真正需要的只是：给模型一项任务，再给它一种验证工作结果的方式，让它不会卡住，然后它就会一直做下去。
而且在这个案例里，Claude还自己决定进行实时博客式记录，它在公司内部创建了一个Slack频道，每隔几分钟就把自己的进度截图发到频道里。
Diana：听起来这条提示词非常简单，现场每个人都可以做到。那能成为前1% Claude Code用户的人和其他人有什么区别？大家该怎么像Boris一样使用Claude Code？
Boris：也许第一点是，不要听LinkedIn上的网红说法。
这就是模型有趣的地方，所有人似乎都在找某个“一招制胜”的奇怪诀窍，但这种东西根本不存在。
模型的使用方式依赖经验实验。你需要交给它一项稍微超出能力的任务，然后像你自己执行这项任务时一样，给它提供验证工作的工具，接着观察它在哪些地方遇到困难，再针对问题修复。
解决方法可能是改进提示词，也可能是增加一个Skill。如果模型缺少上下文，就给它接入MCP，让它自己获取需要的上下文。
Diana：听起来非常简单。
Boris：我认为人们往往把这件事想得太复杂，经常过度工程化。
过去我们构建系统时，确实只能用那种方式。所以当我观察那些编程多年甚至几十年的工程师时，会发现一个非常常见的失败模式：他们试图把一切规定得太具体，希望模型严格按照自己原本会用的方式完成任务。
模型的工作方式不是这样的。
不过我认为很多人正在逐渐放下过去学到的习惯，这是一个“反学习”的过程，需要时间。人们需要学会把模型当作同事一样对待，我认为它现在已经达到了这种智能水平。
Diana：既然如此，我们再深入聊聊那个两周前启动、现在还在运行的任务，它一共启动了多少个智能体？
Boris：我不确定，我可以问问Claude再回来告诉你。我猜可能有几千个，甚至几万个……
数千个智能体怎么启动？
Diana：几千个。现场有没有人给任何模型输入一条提示词，结果启动了超过一千个智能体？我认为这是一个重要经验，最优秀的Claude用户能够启动真正具备巨大杠杆效应的任务，比如让数千个智能体同时工作。
Boris：是的，有几种不同的方法可以做到。
最简单的方法是使用Dynamic Workflows，这是Claude Code里相对较新的功能。使用时你只需要说一句“使用一个Workflow”，就这么简单，Claude会自动触发动态工作流。
动态工作流的实现方式大概是这样的：我们使用Bun Runtime，把Bun作为沙箱，在Bun内部启动虚拟机，然后让Claude启动大量智能体并协调它们。
它不会只启动一个智能体，也不是简单并行运行十个智能体。
如果任务是重写整个代码库，或者针对一组复杂数据做深度数据分析，又或者构建需要多个阶段、产生几十个Pull Request的复杂功能，Claude可能先启动一批智能体完成第一轮工作，然后进入第二阶段，启动另一批智能体验证或总结第一阶段的工作，接下来还可能进入第三阶段，再次扩展启动更多智能体。它会以高效的方式协调大量不同的智能体。
我的专业背景是函数式编程，所以我们在设计时，本质上把它做成了一套“智能体代数”，有让智能体按顺序运行的方式，也有让智能体并行运行的方式。Claude可以在沙箱中使用不同工具协调这些智能体，高效利用Token，完成非常复杂的工作。
这很酷，但目前还没太多人真正写过或讨论过这件事。它实际上也是一种新的测试时计算形式。过去讨论扩展定律和模型智能水平提升时，通常关注神经网络规模、训练数据量和训练投入的计算量。
最近我们加入了测试时计算，用研究人员的专业说法，就是模型在推理阶段生成了多少Token。
现在Dynamic Workflows本质上提供了一种新的测试时计算编排方式，对于真正困难的任务，可以极大提高测试时计算投入。说了这么多，简而言之，这就是以高效、有生产力的方式启动数千个智能体的方法。
第二种方法是Loops和Routines。Loop本质上是在本地为Claude运行的Cron Job，Routine做同样的事，只是运行在云端，所以你可以合上笔记本电脑。它和动态工作流稍有不同，动态工作流面对的是一项任务，把任务拆解成多个部分。
Loops和Routines面对的是不断重复执行的任务，各次运行之间不会共享上下文，但可能共享记忆。你可以让它每小时、每五分钟或每天运行一次。
我们最近开始让Claude自己维护自己，具体做法是在一个Slack频道中，让Claude启动一系列不同的Routines来维护自己的代码库。我们已经在CLI、iOS应用、Android应用和桌面应用中这么做了。比如其中一个Routine的任务是清理死代码，提示词只有一句话。Claude每天运行一次，用静态分析和动态分析在所有代码库中寻找死代码。
我们并没有要求它用静态分析和动态分析，它自己想出了这种方法，之后它每天都会提交Pull Request，删除找到的死代码。
另一个例子是清理已经应该正式发布的实验，如果某项实验已经覆盖100%的用户，Claude就会把实验开关从代码库中删除，正式发布这项功能。
还有一个Routine会为代码库中测试覆盖率不足的区域编写测试，另一个则会删除没必要保留的测试，因为其中一些测试是旧模型或开发者过去添加的无用测试。
还有一个我很喜欢的Routine，我忘了具体名字，好像叫“抽象警察”。它背后的想法是，在大型代码库中经常出现多个非常相似的抽象，仔细观察会发现它们本来应该是同一个抽象，但随着时间推移，由于各种原因，人们在代码库的不同部分用不同方式重复实现了它。
所以Claude每天都会检查我们的所有代码库，找到这些几乎重复的抽象，并把它们统一起来。
现在每天大概有二三十个这样的Routines在我们的各个代码库中运行。
目前还没完全实现，但我们正在走向通过这种方式全面自动化应用维护，这意味着每天会有数百个智能体运行，有时甚至达到数千个。它们完成的是过去需要几十甚至上百名工程师才能完成的工作，这样工程师就可以专注于自己真正想做的事情：发布新产品、和用户交流，以及从事真正有趣的工作。
当编程逐渐被解决，什么能力真正拉开差距？
Diana：这似乎可以得出你过去提到过的结论：编程已经被解决了，对吧？你之前说过类似的话。现在几乎所有人都能编写软件，那么是什么让卓越的构建者和其他人拉开差距？当每个人都能发布代码时，真正重要的品质是什么？
Boris：我要补充一个限定条件。
对于我所做的那类编程，编程已经基本被解决了，但对于所有人来说，还没有完全解决。仍然有一些非常深入的系统级代码库，Claude处理起来依然困难。对于分布式系统，Claude也会遇到困难。
还有一些非常细致的用户界面验证问题，比如某个元素偏差了一个像素，Claude仍然不能完美解决。Opus 5在视觉能力和计算机操作能力上实现了巨大飞跃，但依然没有达到完美。
不过从现场的情况来看，已经有不少人把大部分甚至全部代码交给智能体完成，自己很少再手写代码。所以我认为它正在逐渐接近“被解决”的状态，越来越多类型的代码可以交给模型完成，这很令人兴奋。
在我看来，最擅长使用Claude的人通常拥有一种特别有效的思维方式，核心依然是经验主义。
忘掉你过去从旧模型学到的所有经验，也暂时放下课堂上学到的计算机科学理论。面对模型，实际尝试完成一项任务，观察它在哪些地方遇到困难，再根据实际表现调整。
这件事已经从一门理论科学，转变为一门经验科学。
那些真正擅长使用模型的人，往往很善于忘记自己的先入之见。他们愿意放下“这件事以前做不到”的观念，并对重新尝试保持开放。这种能力现在非常有价值，也非常容易取得成功。
Diana：最后一个问题。考虑到我们今天讨论的所有内容，假如现场有人正在学习计算机科学，并且是在AI智能体编程时代到来之前学会编程的，那么学生还有哪些东西应该继续用困难的方式、传统的方式亲自学习？
Boris：对我来说，我是通过实践学习计算机科学的。我自学编程，是为了处理具体问题。每当我学习一项东西时，都是为了处理当时遇到的某个实际问题。
我最早是在TI-83计算器上学习编程的，那还是我上中学的时候。后来我还在网上写了一份TI-83计算器编程指南，现在可能还在互联网的某个角落。
我学的第一门语言是BASIC。我学习在计算器上编程，是为了在数学考试中作弊，考得更好。所以它解决的是非常实际的问题，对于当时还是中学生的我来说，那就是我能想到的最实际的用途。后来我取得了不错的成绩，还买了一根小型串口线，把这些程序传给同学，他们也取得了很好的成绩。
之后数学变得更难，仅靠BASIC已经无法解决。我原本用BASIC编写了一个代数求解器，但接下来需要解决更困难的问题。
开始学习微积分后，我必须使用汇编语言，才能编写出更好的求解器，让我在微积分考试中更有效地作弊。
所以对我来说，编程始终是一件非常实用的事情。
这也是我一直给在校学生的建议：计算机科学本身在智力层面非常迷人，也非常值得了解，但不要只学习计算机科学，还要学习如何把它应用出来。这通常意味着学习创业、构建产品，培养自己的设计判断力和商业判断力，学习数据科学，也学习如何与用户交流。还有许多其他技能。当你把这些技能和计算机科学和工程结合起来时，它们才会真正产生巨大价值。
这些就是我认为仍然应该亲自练习和掌握的硬技能。
Diana：总结一下你的意思：先从为自己制作一件自己真正想要的东西开始，然后再进一步，制作人们真正需要的东西。
