Claude Code之父：每半年清空一次claude.md、skills和hooks，模型自己会想办法

极客邦科技InfoQ·2026年07月31日 11:48

当一切都在快速过期，什么才是稳定的？

前不久，Claude Code 的重度用户 Garry Tan 在谈到如何用好 AI 编程智能体时，提出了一个很有传播力的说法：一个 Skill 文件，就像一名员工；公司真正需要建立的，是一套由知识库、记忆和“图书管理员”组成的大脑。模型本身足够聪明，但要让它长期理解一家公司的业务、流程和偏好，仍然需要不断补充 Skills，为它构建一个可以反复调用的“头脑”。

然而，在 Claude Code 创始人 Boris Cherny 看来，这个头脑可能每隔半年就应该清空一次。

他认为我们应该把模型视为一种“一种活着的生物”，每一代模型都有不同的性格。因此，每隔六个月，删掉自己的 CLAUDE.md、Skills 和 Hooks，重新看看最新模型还需要多少指令。Claude Code 自己也在这样做。Opus 5 发布后，团队一次删除了超过 80% 的系统提示词；每一代新模型上线，他们都会先清空系统提示词，再逐行加回来，通过消融实验判断哪些内容仍然有价值。

快速失效的不只有提示词和 Skills。Harness 的代码、工具集合，甚至评测本身，也在不断变化。在 Boris 看来，使用 AI 编程工具正在从一门依赖理论和固定方法的学问，变成一门不断试错、重新验证的经验科学。

另外，继 OpenCode 2.0 将桌面端迁移到 Electron 后，Boris 最近也启动了一项实验：让 Claude 把基于 Electron 的 Claude 桌面应用重写成 Swift，并通过 Mac 虚拟机截图进行逐像素验证。任务已经连续运行两个多星期，背后可能调用了数千甚至数万个智能体，至今仍未结束。

以下是本期播客内容的完整翻译。

1 不依赖 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 不会。

事实上，从 Opus 4.7、4.8 开始，情况就已经有所改善。Sonnet 5 在这方面做得很好，Fable 也做得很好，但 Opus 5 又将这项能力推进到了一个新的前沿。

本质上，我们把一个经过良好对齐的模型——背后大约凝聚了三年的对齐研究——与一个提示词注入分类器结合起来。所有流量都会经过这个分类器。它基于 Crysola 的机制可解释性研究：当提示词注入发生时，我们会直接观察模型“大脑”中哪些神经元被激活。

模型自己甚至不会告诉你发生了提示词注入，但我们能够看到这些神经元，并据此判断和诊断注入行为。然后，我们再把它与 Auto Mode 的分类器结合起来。有了这三层防护，我们现在已经无法再演示出有效的提示词注入攻击了。

2 每隔六个月按一次删除键

Diana：说到提示词注入，硬币的另一面就是系统提示词。我们谈谈这次的新版本。你们实际上删除了 Claude Code 超过 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，也就是 Claude Code。但按照我刚才听到的说法，每发布一代新模型，你们似乎都会删除原来的代码库，删除原来的提示词，然后重新开始。在传统软件时代，创业公司通常不会这样做。感觉就像每隔六个月，就对一切按一次删除键。

Boris：没错。不过公平地说，我们不会删除整个代码库，但确实会删除其中很大一部分。

每当一代新模型发布时，我们都会做研究中所说的“消融实验”。它的意思是，先删除整个系统提示词，再逐行把内容加回来，以判断每一行具体产生了什么影响。

它有点像评测，你可以对它进行评估。消融实验本质上也是一种评测，只不过你是通过删除东西来判断它们的影响。

对工具，我们也会采取同样的方式。我们经常下线已经发布的工具，也会持续删除 Harness 中的代码。如果你看看今天 Claude Code Harness 里的代码，会发现其中几乎所有内容都与安全、权限和静态分析有关，另外还有相当一部分用户界面代码。

其他许多代码实际上已经被我们下线了。

Diana：你认为，这种构建智能体产品和 Harness 的方式——每当新模型发布时都重新进行消融实验——是不是所有正在构建 AI 产品的人都应该采用？大家是不是都应该更习惯、更勇敢地按下删除键？

Boris：百分之百应该。

即使有些人并不构建智能体产品，只是在使用 Claude Code，我也建议每隔六个月删除一次你的 CLAUDE.md、Skills 和 Hooks，看看模型自己会怎么做。结果可能会让你吃惊。

对于 Opus 5，我们确实非常建议大家这样尝试：把这些东西都删掉看看，因为新模型可能已经不再需要过去那些模型所依赖的指令。

Diana：我们再谈谈如何构建新的提示词。每当新模型发布时，在场所有人都会想试用 Opus 5，也会想按下删除键，清空系统提示词。那么，他们接下来应该怎样重新构建系统提示词？你们会如何设置环境？

Boris：要一点一点来。第一步是删除，下一步是使用。不要提前猜测模型需要什么指令，因为你的预测很可能并不准确。你真正应该做的是让它运行起来。

假如你正在构建一款定制的智能体产品，就实际运行这款产品，观察模型在哪些地方失败、哪些地方做得很好。假如你在使用 Claude Code，就观察它在你的代码库里哪些地方表现良好，又会不会在理解架构或其他问题时遇到障碍。

只有当你看到它反复在同一件事情上出错时，才应该把相应的指令加回来，不要加得太早。

要记住，每次使用时，模型都会重新读取这条指令。因此，你必须确认模型真的需要它。

我认为，基于模型构建产品最疯狂的一点是，它与我过去做过的所有工程工作都非常不同。以前，当你基于传统系统进行开发时，会构建庞大而精美的系统，并在一开始就认真思考系统设计。你会准备一整套庞大的单元测试，并提前考虑各种问题。重新设计架构通常是一项大工程，有时需要几个月。我曾经在大公司参与过持续数年的产品架构改造。

模型却不是这样。你几乎应该把它看成一种活着的生物，一种更加有机的东西。每一代模型的行为都会有所不同，也会拥有略微不同的“性格”。

你必须花时间了解它，然后根据它的特点调整 Harness。这是一件高度依赖经验和科学实验的事情。你需要采用科学思维：尝试一种方式，观察结果，再根据结果继续迭代。

3 当一切都在快速过期，什么才是稳定的？

Diana：在这样一个构建环境中，究竟还有什么东西是稳定的？评测是否会从上一代模型保留下来，并继续用于之后发布的每一代新模型？

Boris：会，直到模型把这个评测彻底做满。

Diana：所以，对大家来说，这里有一条经验：如果希望站在最前沿，把模型能力发挥到极致，代码和系统提示词都应该敢于删除；评测则相对稳定，可以不断追加新的内容。

Boris：是的，可以持续追加。不过坦率地说，我甚至不会把话说到这么绝对。评测的寿命确实会比 Harness 稍微长一些，但也长不了太多。一套评测可能只能维持一代、两代或三代模型。如今，我们处在指数增长阶段，模型提升的速度非常快。很多时候，一套评测很快就会被模型做满，我们只能把它扔掉，再设计一套新的评测。

这就是整个过程的一部分。它仍然是一种经验驱动的方法：你必须实际使用产品和模型，观察它在哪些地方遇到困难，再根据这些困难构建评测集。

Diana：我听你用过一个词来描述如何在 Claude 之上打造最好的智能体产品，那就是“解除 Claude 的束缚”，也就是 unhobbling Claude。能不能解释一下它是什么意思？

Boris：可以。研究中所说的 hobbling，指的是模型原本能够完成某件事情，但你的设计反而妨碍了它。

这里还有一种我非常喜欢的思考方式，在构建产品时也很有用，叫作“产品能力缺口”，也就是 product overhang。它的核心观点是：今天的模型已经能够完成许多事情。这里说的不是未来的模型，就是今天已经存在的模型，只是我们尚未意识到这些能力。模型拥有大量人们并不知道的能力。它可能能够使用某一种特定工具、某一种编程语言，解决某一类特定问题，或者采用某一种我们过去认为超出它能力范围的方式完成任务。

每一代模型都会存在这种“能力悬空”的状态：模型本身已经能够做到，但没有相应的产品允许它这样做，也没有产品能够让它把这种能力真正表达出来。

另一方面，经常发生的情况是，产品本身反而挡住了模型。我们把这种妨碍叫作 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 画出这幅图。”它画得其实相当不错，能够画肖像、动物和风景。

我们从来没有训练模型画画。这只是一个“能力诱导缺口”：只要用正确的方式要求它，它就能够做到。

我们是在随意尝试一些没有直接商业用途的创意玩法时，偶然发现这项能力的。但它很有意思。

我的假设是，今天的模型可能还存在几十个、甚至几百个类似的机会，只是还没有任何人意识到。

4 数千个智能体跑了两周，要把 Electron 桌面端重写成 Swift

Diana：这背后的一个重要研究领域，本质上就是“模型能力诱导”，也就是 model elicitation，对吧？你需要非常擅长发现模型的各种能力，并以正确方式要求模型把它们发挥出来。人们应该怎样提升这种能力？换句话说，怎样提升提示词工程能力？人们现在是否还需要做大量提示词工程，还是这件事本身也在发生变化？你觉得未来会走向哪里？

Boris：我记得大约一年前，最热门的职位之一是提示词工程师。后来，它又变成了所谓的上下文工程师。这些概念总是一波一波地出现，也会一波一波地消退。

我认为，今天真正重要的技能已经不太是提示词工程，而是如何找到一项看起来稍微超出 Claude 能力范围的困难任务，并思考怎样让 Claude 在执行过程中验证自己的工作。

验证可能是人们最容易做错、同时也是最重要的一件事情。

举一个例子。我们有一款 Claude 桌面应用，它是基于 Electron 构建的。现在，我们已经把它优化得非常快，整体体验也很出色。六个月前，它还比较卡顿，也不够可靠，现在已经相当不错，是团队里大多数人日常使用的版本。

作为一个实验，我想看看，如果把它改造成原生应用，体验会是什么样。于是，我启动了一个 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，再回来告诉你。我猜可能有几千个，甚至几万个……

5 数千个智能体怎么启动？

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 在我们的各个代码库中运行。

目前还没有完全实现，但我们正在走向通过这种方式全面自动化应用维护。这意味着每天会有数百个智能体运行，有时甚至达到数千个。它们完成的是过去需要几十名甚至上百名工程师才能完成的工作。这样一来，工程师就可以专注于自己真正想做的事情：发布新产品、与用户交流，以及从事真正有趣的工作。

6 当编程逐渐被解决，什么能力真正拉开差距？

Diana：由此似乎可以得出你过去提到过的一个结论：编程已经被解决了，对吧？你之前说过类似的话。现在，几乎所有人都能编写软件，那么，是什么让卓越的构建者与其他人拉开差距？当每个人都能发布代码时，真正重要的品质是什么？

Boris：我要补充一个限定条件。

对于我所做的那类编程，编程已经基本被解决了，但对于所有人来说，还没有完全解决。仍然有一些非常深入的系统级代码库，Claude 处理起来依然困难。对于分布式系统，Claude 也还会遇到困难。

还有一些非常细致的用户界面验证问题，比如某个元素偏差了一个像素，Claude 仍然不能完美解决。Opus 5 在视觉能力和计算机操作能力上实现了巨大飞跃，但依然没有达到完美。

不过，从现场的情况来看，已经有不少人把大部分甚至全部代码交给智能体完成，自己很少再手写代码。所以，我认为它正在逐渐接近“被解决”的状态。越来越多类型的代码已经可以交给模型完成，这很令人兴奋。

在我看来，最擅长使用 Claude 的人通常拥有一种特别有效的思维方式，核心依然是经验主义。

忘掉你过去从旧模型那里学到的所有经验，也暂时放下课堂上学到的计算机科学理论。面对模型，实际尝试完成一项任务，观察它在哪些地方遇到困难，再根据实际表现作出调整。

这件事已经从一门理论科学，转变为一门经验科学。

那些真正擅长使用模型的人，往往很善于忘记自己的先入之见。他们愿意放下“这件事情以前做不到”的观念，并对重新尝试保持开放。这种能力如今非常有价值，也非常容易取得成功。

Diana：最后一个问题。考虑到我们今天讨论的所有内容，假如现场有人正在学习计算机科学，并且是在 AI 智能体编程时代到来之前学会编程的，那么学生还有哪些东西应该继续用困难的方式、传统的方式亲自学习？

Boris：对我而言，我是通过实践学习计算机科学的。我自学编程，是为了处理具体问题。每当我学习一项东西时，都是为了处理当时遇到的某个实际问题。

我最早是在 TI-83 计算器上学习编程的，那还是我上中学的时候。后来，我还在网上写了一份 TI-83 计算器编程指南，现在它可能还在互联网的某个角落。

我学的第一门语言是 BASIC。我学习在计算器上编程，是为了在数学考试中作弊，从而考得更好。所以，它解决的是一个非常实际的问题。对于当时还是中学生的我来说，那就是我能想到的最实际的用途。后来，我取得了不错的成绩，还买了一根小型串口线，把这些程序传给同学，他们也取得了很好的成绩。

之后，数学开始变得更难，仅靠 BASIC 已经无法解决。我原本用 BASIC 编写了一个代数求解器，但接下来需要解决更加困难的问题。

开始学习微积分后，我必须使用汇编语言，才能编写出更好的求解器，让我在微积分考试中更有效地作弊。

所以，对我来说，编程始终是一件非常实用的事情。

这也是我一直给在校学生的建议：计算机科学本身在智力层面非常迷人，也非常值得了解，但不要只学习计算机科学，还要学习如何把它应用出来。这通常意味着学习创业、构建产品，培养自己的设计判断力和商业判断力，学习数据科学，也学习如何与用户交流。还有许多其他技能。当你把这些技能与计算机科学和工程结合起来时，它们才会真正产生巨大价值。

这些就是我认为仍然应该亲自练习和掌握的硬技能。

Diana：总结一下你的意思：先从为自己制作一件自己真正想要的东西开始，然后再进一步，制作人们真正需要的东西。