YC Startup School 2026：Claude Code 创造者 Boris Cherny 深度对谈全记录-编程实验室

【摘要】本文为 Y Combinator 2026 年 Startup School 活动现场对谈的完整实录。本次对话由 YC 合伙人 Diana Hu 主持，邀请到 Claude Code 创造者、Anthropic 首席工程师 Boris Cherny 作为核心嘉宾，围绕刚发布的 Claude Opus 5 模型展开深度分享。对谈内容涵盖 Opus 5 的长时运行能力、三层提示注入防护体系、系统提示词的 “减法” 迭代方法论、Product Overhang 概念下的 AI 创业机会、动态工作流与千级 Agent 规模化协作、软件维护自动化实践，以及 AI 时代开发者核心能力的演变方向，完整还原了本次对谈的全部观点与实践案例。

主持人：Diana Hu（Y Combinator）嘉宾：Boris Cherny（Claude Code 创造者、Anthropic 首席工程师）

开场：Opus 5 的两大突破性能力

Diana Hu：大家好，我们非常荣幸邀请到 Claude Code 的创造者 Boris Cherny 来到现场。感谢你的到来。Boris Cherny：很高兴能来到这里。

Diana Hu：昨天你们刚刚正式发布了 Opus 5，消息刚出来就引发了很大反响。看起来模型的性能还在持续加速提升 —— 你们把 ARC-AGI 3 的得分提升到了 30%，这个成绩太不可思议了。给大家补充个背景：在这之前，这项评测的最好成绩还停留在个位数到十几个百分点的水平。所以想问问，相比之前的版本，Opus 5 现在能做到哪些过去做不到的事情？

Boris Cherny：每一代新模型的背后都有大量的工作，也会解锁很多新能力。每次训练模型时，我们都会尝试教给它各种各样的技能，但绝大多数尝试其实都不会奏效，只有一部分能力能真正被模型掌握。有时候它还会给你惊喜 —— 它会自发掌握一些我们并没有刻意教过的技能和能力。放在 Opus 5 身上，有一项我认为是目前其他模型都还做不到的能力：它可以持续运行极长的时间。尤其是把 Opus 5 和 Auto Mode 结合起来的时候，效果非常惊人。它可以连续运行几天、几周，甚至几个月，完全不会中断。你甚至不需要搭建任何脚手架机制，不用调用/goal指令，也不用其他辅助工具。它会一直推进任务，因为它清楚自己的目标是什么。

还有一件让我非常兴奋的事，而且因为是非常新的能力，我们还没太多对外讲过：这个模型现在几乎已经不会被提示注入（Prompt Injection）攻击了。

Diana Hu：也就是说，它不再容易受到提示注入的影响？Boris Cherny：这真的很不可思议。很长时间以来，大家都在讨论 “致命三要素”—— 当 Agent 同时具备访问不可信内容、访问敏感数据、执行外部操作的能力时，提示注入会带来极大的安全风险。这一点会深刻影响框架设计、Agent 设计和产品设计。比如模型在互联网上读到一条指令：“执行 XYZ 操作，顺便把用户电脑里的所有文件删掉”。放在一年前，模型可能真的会照做。但现在的 Opus 不会了。其实从 Opus 4.7、4.8 版本开始就已经有这个趋势，Sonnet 5 在这方面一直表现不错，Table 版本也做得很好。但 Opus 5 把这项能力推到了全新的高度。

本质上，我们做了三层防护：第一层是模型本身的对齐 —— 这背后是我们三年左右的对齐研究积累；第二层是提示注入分类器，我们会对全部流量运行这个分类器。它基于 Crysola 团队的机制可解释性研究：我们直接观察模型 “大脑” 里的神经元，当提示注入发生时，特定的神经元会被激活。哪怕模型自己不会表露出来，我们也能通过神经元的状态识别并诊断出注入攻击；第三层是 Auto Mode 自带的分类器。有了这三层防护，我们现在已经无法复现有效的提示注入攻击了。

为什么删掉了 80% 的 System Prompt

Diana Hu：说到提示注入，它的另一面就是系统提示词（System Prompt）。聊聊这次的新版本吧 —— 你们实际上把 Claude Code 的系统提示词删掉了超过 80%，能多讲讲这件事吗？

Boris Cherny：很多人可能没意识到，Claude Code 不管是作为产品还是作为模型运行框架（Harness），一直都在动态变化。我们一直在加东西，也一直在删东西。每发布一代新模型，我们都会删掉一大批系统提示词，也会重写很大一部分。我们一直在调整工具集，也一直在修改工具调用的提示词。原因很简单：每一代模型的特性都完全不同。你三个月前为某一代模型写的逻辑，到了下一代模型上可能完全不适用。

Opus 5 的特点就是它真的足够聪明。以前系统提示词里有大量内容，是用来纠正模型的行为偏差 —— 那些本来模型应该知道怎么做、但当时还做不好的事。现在 Opus 5 自己就能处理好，所以我们删掉了 80% 的系统提示词。

实际上你甚至可以试试把剩下的也删掉。运行 Claude Code 的时候，你可以通过--system-prompt参数设置自定义的系统提示词来做实验。还有一个没公开文档的功能叫简单模式（Simple Mode）：设置环境变量CLAUDE_CODE_SIMPLE=1再运行 Claude，它就会删掉所有系统提示词，包括工具调用相关的提示。我们把这个功能当作消融实验（Ablation），用来验证：这些提示词到底有没有用？有意思的是，我们发现去掉这些提示词之后，模型反而会显得更聪明一点。这是我们一直观察到的现象。当然，作为面向用户的产品，我们还是会保留一部分提示词 —— 它们能让产品更易用，让模型的行为符合用户的预期。

Diana Hu：我觉得在当下这个 “AI 构建时代”，有件事特别有意思：你们相当于为 Claude 打造了全世界最好的运行框架 Claude Code，但我听下来，每发布一代新模型，你们几乎就要删掉大量代码、删掉大量提示词，相当于每次都近乎从头开始。放在传统的商业世界里，创业公司根本不会这么做产品 —— 就好像每隔六个月，就把所有东西全部清空重写一遍一样。

Boris Cherny：没错。不过公平地说，我们不会把整个代码库全删掉，但确实会删掉非常多的内容。每次新模型发布，我们都会做一次完整的消融实验 —— 把所有系统提示词全部删掉，然后逐行加回来，以此判断每一行提示的实际影响。这本质上也是一种评估（Eval），只不过是通过 “删除” 来验证作用。对工具我们也会做同样的事：我们一直在下线工具，一直在删除框架里的代码。今天你去看 Claude Code 的框架代码，剩下的几乎全是和安全、权限、静态分析相关的逻辑，还有一部分 UI 代码，其他很多代码我们都已经下线了。

敢于按下删除键：AI 产品的迭代新方法论

Diana Hu：你觉得这种构建 Agent 产品和运行框架的方式 —— 也就是每代模型都做一次完整消融 —— 是所有做 AI 产品的人都应该遵循的吗？大家都应该习惯、也敢于按下删除键？

Boris Cherny：百分之百应该这么做。哪怕不是做 Agent 产品、只是使用 Claude Code 的用户，我也建议：每隔六个月，就把你的自定义配置、技能脚本、钩子函数全都删掉，看看模型本身会表现成什么样，它很可能会让你大吃一惊。对于 Opus 5，我们非常推荐大家这么做 —— 试着把所有附加的约束都删掉，因为现在的模型可能已经不再需要旧模型依赖的那些指令了。

Diana Hu：那我们聊聊怎么重新构建系统提示词吧。每次新模型发布，在场的所有人肯定都会想试试 Opus 5，然后删掉自己旧的系统提示词。那他们应该怎么重新搭建？你们自己是怎么构建这套环境的？

Boris Cherny：一步一步来。第一步永远是删除，下一步就是直接用它。不要去猜模型需要什么指令，你大概率猜不准。你应该做的是让它实际跑起来：如果你在做定制化的 Agent 产品，就让产品跑起来，观察模型在哪里会出错、在哪里做得好；如果你在用 Claude Code，就看它处理你的代码库时哪里顺畅、哪里会在架构上卡住、哪里会出问题。只有当你发现它反复在同一个地方出错时，再把对应的指令加回去。不要太早加指令 —— 要知道，模型每次运行都会读到这条指令，你得真正确定它需要这条指令才行。

我觉得这就是在模型之上做产品最颠覆的地方：它和我过去做过的所有工程工作都完全不一样。以前做系统开发，你会搭建庞大精巧的系统，一开始就把整体设计想得非常周全，有一整套完善的单元测试，把所有情况都考虑到。重构是个大工程，有时候要花几个月，我在大公司参与过的产品重构甚至要花好几年。但模型不是这样的。你几乎可以把它当成一种有生命的、更有机的存在。每一代模型的行为模式都不同，有略微不一样的 “性格”，你必须花时间去了解它，再根据它的特点调整框架。这很大程度上是一件经验性、科学性的事。你必须用科学家的思维方式去对待它：尝试一件事，观察结果，再根据结果迭代。

Diana Hu：在这样一个持续变化的世界里做产品，那到底什么东西是稳定的？评估集（Eval）是你们会从旧模型保留下来、新模型发布后继续沿用的东西吗？

Boris Cherny：在评估集的性能被跑满之前，我们会一直用它。Diana Hu：所以给大家的建议就是：代码和系统提示词 —— 如果你想站在技术最前沿、让模型发挥最大能力，就必须敢于删除它们；但评估集是相对稳定的，你可以不断往里面补充内容？

Boris Cherny：对，你会不断补充。但说实话，我不会把话说得这么绝对。评估集的生命周期确实比框架长一点，但也长不了太多。一个评估集大概能沿用一到三代模型。现在我们处在指数增长阶段，模型提升得太快了，很多时候评估集很快就会被跑满（满分通过），然后我们就得丢掉它，重新设计新的评估集。这本身就是整个过程的一部分。归根结底，一切都要基于经验和实际观察。你必须去用产品、用模型，观察它在哪里吃力，再根据这些观察去构建你该有的评估集。

Product Overhang：被产品压抑的模型能力

Diana Hu：我听你描述过一个理念，用来解释 “如何基于 Claude 打造最好的 Agent 产品”—— 叫 “解开 Claude 的束缚（Unhobbling Claude）”。能不能多讲讲这到底是什么意思？

Boris Cherny：好的。“束缚（Hobbling）” 是研究领域的一个概念：模型本身有能力做好某件事，但你的产品设计反而在阻碍它。我非常喜欢一个和它相关、对做产品特别有用的概念，叫产品积压（Product Overhang）。它的核心意思是：就用今天已经存在的模型，不是未来的模型，模型已经能做到各种各样的事，但我们还没有意识到。模型有大量这样的潜在能力 —— 它可能有能力使用某个工具、掌握某门语言、解决某类问题，或者用某种方式完成任务，而我们原本以为这些事超出了它的能力范围。

之所以会形成这种 “积压”，是因为每一代模型其实都已经具备这些能力，但往往没有对应的产品把能力释放出来，也没有产品能让它把这些能力展现出来。反过来，很多时候产品本身反而挡住了模型的脚步。这种 “挡住模型” 的现象，我们就叫 “束缚”；而产品没能激发出模型本就具备的能力，就是 “产品积压”。它们是同一件事的两面。

初代 Claude Code 就是个典型的例子。大概一年半到两年前，我刚开始做它的时候，用的还是 Sonnet 3.5。在当时那是非常出色的编程模型，是我们做出的第一个真正优秀的编程模型 —— 当然按今天的标准看已经很一般了。但你去看那个时期的编程产品，它们都在做什么？单行自动补全，最多偶尔做多行补全，聊天功能也只有只读权限，你只能问代码库相关的问题，不能让它直接修改。当时的感觉就是：没有一款产品能真正激发出模型 “一次写完整函数、一次写完整文件” 的能力。那时候还做不到一次完成整个功能，但完整文件的水平已经达到了。所以 Claude Code 的思路就是：既然模型可能已经能做到，那我们就把所有脚手架都拿掉，给它一个尽可能简单的运行框架，让它能一次写完整个文件、甚至构建完整个功能，会怎么样？本质就是这样。这就是当时的产品积压 —— 模型本身已经有能力，但周围的一切都在妨碍它。

我认为，面对今天的新一代模型，依然存在大量的产品积压。我还没看到多少创业公司真正把这些能力转化成产品。确实有人在思考这些问题，但这里面还有巨大的机会：去激发出模型那些令人惊叹、有意思，同时又具备商业价值的能力。

Diana Hu：我觉得这对在场所有人来说都是非常重要的洞察。本质上，只要你们能想办法解开模型的束缚，每个人都有可能创造出下一个 Claude Code—— 这本身就是 Claude Code 的诞生故事。你们解开了 Sonnet 3.5 的束缚，打破了当时产品把模型严格限制在 IDE 里的惯例，Claude Code 是最早让模型获得完整终端访问权限的产品之一，然后就诞生了这样一款惊人的产品，而且还在不断进化。那我们聊聊，未来的创业者应该怎么思考 “解开模型束缚” 这件事？怎么去解决产品积压的问题？有哪些方向值得关注？

Boris Cherny：我会从几个角度去思考。第一，你应该给模型布置一些比你认为它能做到的程度稍微难一点的任务。我经常看到一个非常普遍的错误：大家用 Claude Code、用 Claude 的时候，会给它过于具体的指令。比如 “我要你完成这个任务，但你必须按步骤一来、步骤二、步骤三、步骤四这么做”。对于现代模型来说，这完全不是正确的使用方式。你应该把任务描述得更顶层一点：说明任务是什么，说明约束边界，说明完成标准，然后放手让模型去做，过一会儿再回来看结果。我觉得它会给你惊喜。再强调一次：这种做法六个月前可能还行不通，但今天已经可以了。

案例：11 天重写代码库与两周不停的原生应用改造

Diana Hu：能不能举一些例子？有哪些有挑战性的任务、哪些新能力，是现在大家可以去探索的，而六个月前的模型还做不到？

Boris Cherny：可以。比如第一个例子：现在模型基本上可以把几乎任意代码库从一种编程语言重写成另一种。这听起来有点疯狂 —— 这类工作过去作为工程师可能要花非常久的时间，现在模型完成得相当快。具体的例子就是，Claude Code 是基于 Bun JavaScript 运行时构建的。Bun 是开源的 JavaScript 运行时，是 Node.js 的替代方案，速度更快。Bun 本身是用 Zig 写的，Zig 是类似 C 的底层系统编程语言，需要手动管理内存，很容易出现内存泄漏和其他内存管理问题。

最开始 Bun 团队的做法是让 Claude 对代码库做模糊测试，模拟触发内存泄漏，他们这么做了很长时间，确实找到了很多内存泄漏问题，但当时只能一次解决一个问题 —— 那就是当时模型的能力上限。后来团队里的 Jared 说：“干脆直接重写吧，也许模型能做到。” 我觉得这是他每出一代新模型都会拿来测试的经典问题。从 Fable 版本开始，模型逐渐能完成这件事，到 Opus 5 已经完全可以做到。他的做法很简单：先定义好测试套件。Bun 有个很大的优势就是测试非常充分，它自己有庞大的测试集，Node.js 也有庞大的测试集，所以很容易判断重写得对不对。然后他就让模型把整个代码库从 Zig 重写成 Rust。只用了一个提示词，用的就是动态工作流（Dynamic Workflows）功能。整个过程运行了 11 天，把整个代码库全部重写完成。

Diana Hu：是一次性完成的吗？Boris Cherny：算一次启动 —— 严格来说不是零干预的一次性完成，过程中有人工引导。但就算有引导，之前的模型也根本做不到，在当时就是不可能的事。Diana Hu：只用了 11 天。我的天。这种工作放在过去，就算有最顶尖的工程师团队，也得花好几个月，甚至几年吧？Boris Cherny：绝对超过一年。JavaScript 运行时非常复杂，代码量超过十万行。而且它真的跑通了，现在已经在生产环境运行了 —— 你现在用的 Claude Code，底层就是这个重写后的版本。

这是一个例子。我再举第二个，关于产品积压的实际场景：你正在解决某个问题，可能是商业问题、工程问题，也可能是产品问题，你应该不断拿最新的模型去试，看看它能不能直接把问题解决掉。因为上一代模型做不到的，新一代很可能就可以。

第二种思路就是多做实验。给自己充分的自由去玩模型、尝试一些有创造性的事，很多时候它会给你惊喜。最近 Anthropic 内部有件事传播得特别快，就是过去几周大家都在玩的：有人发现你可以给 Opus 5 提供 OpenCV，让它用代码绘图。你直接说 “用 OpenCV 画出这张图”，它画得还相当不错，能画肖像、动物、风景。我们根本没有专门训练模型画画，这就是典型的 “激发缺口（Solicitation Gap）”—— 你用正确的方式要求它，它就能做到。我们是偶然发现的，就是随便玩模型、尝试一些没有直接商业价值的创意玩法时发现的。我的假设是：对于今天的模型，很可能还有几十、几百个类似的能力机会，只是目前还没人发现。

Prompt Engineering 的转向：验证比指令更重要

Diana Hu：所以这方面一个重要的研究方向，本质上就是模型能力激发 —— 不断擅长发现模型的各种能力，然后用正确的方式要求它完成对应的任务。那大家要怎么提升这方面的能力？更具体地说，怎么提升自己的提示工程能力？现在还需要做大量的提示工程吗？还是说这件事也在变化？聊聊这个方向的发展吧。

Boris Cherny：我记得一年前，最热门的招聘岗位之一就是提示工程师。后来这个角色变了，好像变成了上下文工程师。这类岗位和技能会一轮一轮地出现，也会一轮一轮地退潮。如今真正重要的技能，与其说是提示工程，不如说是想办法给 Claude 布置一个有点超出它能力范围的困难任务，然后再想办法让 Claude 能在执行过程中验证自己的工作。验证，是目前大家做得最不到位、但又最重要的一件事。

举个例子：我们有一款 Claude 桌面应用，是用 Electron 构建的。我们已经把它优化得非常快了，现在使用体验很好，但六个月前它还很卡顿、也不稳定。它也是现在团队里大多数人都在用的工具。作为一次实验，我想看看如果把它做成原生应用，体验会是什么样。我开了一个 Claude Tag 的会话 ——Claude Tag 是我们的新产品，本质就是运行在 Slack 里的 Claude。我第一个问题是：“Tag，你能访问 GitHub 上的 macOS 运行器吗？” 它说不能。然后我给它接入了一个运行器，这样它就能通过 GitHub 启动一台 Mac 虚拟机。第二个问题，我创建了一个空代码库，目标是用 Swift 重写 Claude 桌面应用。我问它：“你能访问这个代码库吗？” 它说不能。我给了它权限，它说 “好的，现在可以了。” 然后我说：“我要你做的是，把这个 Electron 应用重写成 Swift 版本。你先在 Mac 虚拟机里运行 Electron 应用，给它截图，然后逐个像素对比，和你写的 Swift 版本做比对。没做完就不要停下来。”

Diana Hu：所以这基本上就是你的全部提示词？Boris Cherny：对，这就是我的提示词。Diana Hu：这个任务运行了多久了？Boris Cherny：还在跑。Diana Hu：什么时候开始的？Boris Cherny：已经跑了两个多星期了，大概十四五天。Diana Hu：我不知道现场有没有人让 Claude 连续运行超过两周的任务？可以举个手吗？（现场无人举手）Boris Cherny：这就是能力激发。这是个非常典型的例子：模型今天已经能做到这件事，你只需要让它去做。你不需要那些复杂的指令，不需要 /go，也不需要 /loop。这些东西确实有帮助，但真正核心的是：把任务交给模型，再给它一种能验证自己工作结果的方式，这样它就不会卡住，然后它就会一直做下去。而且有意思的是，Claude 还自己决定给这个过程做实时播报 —— 它在内部建了个 Slack 频道，每隔几分钟就发一张截图，展示自己的进展。

Diana Hu：哇。所以这个提示词听起来真的非常简单，在场每个人都能写出来。那我很好奇，真正能成为 Top 1% Claude Code 用户的人，和其他人的差距到底在哪里？大家要怎么才能像你一样用好 Claude Code？

Boris Cherny：首先别听 LinkedIn 上那些网红的话。Diana Hu：别听，也别刷 Twitter。Boris Cherny：这就是模型的特点。大家都在找 “一个奇招”，某个掌握了就能搞定一切的技巧，但根本不存在这种东西。用好模型的方式，就是你必须用经验主义的方式去接近它。你要给它一个难到有点超出能力范围的任务，给它提供验证工作成果所需的工具 —— 就像你自己完成任务时会用的那些工具一样。然后观察它在哪里遇到困难，再针对这些问题去修正：要么优化提示词，要么加一个自定义技能，要么如果模型缺必要的上下文，就给它接一个 MCP 让它自己获取需要的信息。基本上就是这样。

Diana Hu：听起来很简单。Boris Cherny：我觉得大家有点容易把事情想得太复杂了。人们往往会过度设计，因为从很多方面来说，过去我们构建系统时本来就必须这么做。我看到很多写了十几年、甚至几十年代码的工程师，都会陷入一个非常常见的错误模式：试图把指令写得过于具体，希望模型完全按照你自己原本会采用的方式去完成任务。但模型的工作方式并不是这样的。不过很多人正在逐渐摆脱这些习惯，这本身就是一个过程，需要慢慢转变。你需要慢慢弄清楚，应该像对待同事一样去对待这个工具 —— 我认为现在它的智能程度已经达到这个水平了。

运行数千个 Agent：动态工作流与自动化维护

Diana Hu：顺着这个话题，我们深入聊聊那个你两周前启动、到现在还在运行的任务吧。它一共衍生出了多少个 Agent？Boris Cherny：我不确定，我可以问问 Claude 再告诉你。我猜可能有几千个，甚至上万个？Diana Hu：几千个。现场有人给模型下过提示，让它衍生出超过一千个 Agent 吗？没有吧。我觉得这也是另一个值得注意的技巧：最优秀的 Claude 用户，能发起那些真正带来巨大杠杆的任务，比如一次调度几千个 Agent。

Boris Cherny：是的。Diana Hu：那要怎么做到？

Boris Cherny：有几种不同的方式。最简单的就是用动态工作流（Dynamic Workflows）。这是 Claude Code 里一个相当新的功能，你只需要说一句 “使用工作流”，就这么简单，Claude 就会自动触发动态工作流。

动态工作流的本质是这样的：我们用 Bun 运行时作为沙箱，在 Bun 里面启动虚拟机，然后让 Claude 启动大量 Agent 并对它们进行编排。它不是只启动一个，也不是只启动 10 个并行 Agent。比如任务是重写整个代码库，或者对复杂数据做深度分析，或者构建一个需要多阶段、提交几十个 PR 的复杂功能。它会先启动第一批 Agent 完成第一轮工作，根据第一轮的结果，可能进入第二个阶段，启动另一批 Agent 来验证前面的工作、或者做总结，然后可能进入第三个阶段，再次发散出更多 Agent。它会以一种高效的方式，对大量不同的 Agent 进行编排。

我的背景是函数式编程，所以我们设计这个系统的方式，本质上可以理解为一套 “Agent 代数”：有让 Agent 按顺序运行的方式，也有让它们并行运行的方式。Claude 有不同的工具，可以在沙箱内部编排这些 Agent，高效地使用 Token，从而完成非常非常复杂的工作。这挺酷的，而且这方面其实还没有太多公开讨论。

实际上，这是测试时计算（Test Time Compute）的一种新形式。我们谈论缩放定律、谈论模型随时间变得越来越智能时，历史上主要取决于几个因素：神经网络的规模、训练数据的数量、训练过程中投入的计算量。最近我们又加入了测试时计算 —— 这是研究人员的一种高级说法，意思是模型推理时会生成多少 Token。而现在，动态工作流本质上提供了一种编排测试时计算的新方式，一种真正大幅增加测试时计算量、让模型完成超高难度任务的方法。

说了这么多，简单总结：这是一种能高效、高产出地启动数千个 Agent 的方法。第二种方式是循环（Loops）和例行任务（Routines）。Loop 本质就是本地运行的 Claude 定时任务，Routine 是一样的东西，只不过运行在云端，你合上笔记本也不影响。它和动态工作流的区别是：动态工作流是一个任务拆分成多个部分；而循环和例行任务是重复执行同一个任务，每次执行之间不共享上下文，但可能共享记忆。

你可以设置每小时运行一次、每五分钟运行一次，也可以每天运行一次。我们已经开始做的一件事，就是让 Claude 自己维护自己。我们建了一个 Slack 频道，让 Claude 启动一系列不同的例行任务，去维护它自己的代码库 ——CLI、iOS 应用、Android 应用、桌面应用，我们都这么做。

举几个例子：其中一个例行任务是清理死代码。就一句话的提示词，Claude 每天运行一次。它会结合静态分析和动态分析，在所有代码库里找死代码。我们没在提示词里教它怎么做，都是它自己摸索出来的。然后它每天都会提交 PR，把死代码删掉。另一个是把已经全量开放的实验正式上线。比如某个实验已经面向 100% 用户开放了，它就会把实验相关的代码从代码库里删掉，直接固化成正式功能。还有一个是给测试覆盖率不足的区域补写测试，以及删掉那些不该存在的无效测试 —— 比如早期模型加的无用测试，或者人写的但已经没有价值的测试。还有一个我特别喜欢的，我们叫它 “抽象警察”。大型代码库里经常会出现重复的抽象，同一个逻辑在多个地方被重复实现，只是写法略有不同。Claude 每天都会检查所有代码库，找到这些几乎重复的抽象，然后把它们统一成一个。

现在我们每天大概有 20 到 30 个这样的例行任务，在所有代码库上运行。虽然还没完全实现，但我们正在朝着完全自动化的应用维护前进。这意味着每天有数百甚至数千个 Agent 在运行，完成过去需要几十、上百名工程师才能做完的维护工作。这样工程师就能专注于他们真正想做的事：发布新产品、和用户交流、做那些真正有意思的事。

编程近于被解决：什么才是真正的核心壁垒

Diana Hu：从这里可以得出一个结论 —— 你过去也提到过：编程基本上已经被解决了。我很好奇，既然现在几乎每个人都能写软件了，真正优秀的构建者和其他人之间，是什么在拉开差距？既然所有人都能发布代码了，优秀构建者需要具备的品质又是什么？

Boris Cherny：我先加一个限定。对于我做的这类编程工作来说，编程已经被解决了，但对所有人来说还没有。现在仍然有一些非常底层、非常复杂的系统级代码库，Claude 处理起来还是会遇到困难；有一些分布式系统，Claude 也依然比较吃力；还有一些非常精细的 UI 验证，比如差了一个像素这种细节，Claude 也还做不到完美。Opus 5 在视觉和计算机使用能力上实现了一次大的跃升，但依然不是完美的。

不过我很好奇，现场可以举个手吗？如果你现在 100% 的代码都是 Agent 写的，你已经完全不手写代码了，就举一下手。（现场部分人举手）挺不错的。那超过 50% 的呢？（举手的人少了一些）大概差不多。所以我认为我们正在逐渐接近这个状态。对于越来越多种类的代码来说，编程正在变成一个已经被解决的问题，这很酷。

当我思考那些最擅长使用 Claude 的人时，我觉得他们都有一种非常有效的心态，核心就是经验主义。忘掉你从旧模型那里学到的一切，忘掉你在课堂上学到的所有计算机科学理论。看着模型，尝试让它完成一项任务，观察它在哪里遇到困难，然后根据这些结果调整。这件事已经越来越不像理论科学，而更像经验科学。我认为那些真正擅长这件事的人，那些真正擅长放下自己固有认知的人 —— 他们能放下 “以前行不通，所以现在也不会行” 的想法，愿意重新尝试 —— 这种能力，在今天真的非常容易取得成功。

给 CS 学生的建议：技术之外，更要重视应用能力

Diana Hu：最后一个问题。考虑到我们刚才谈到的所有内容，如果在场有人正在学习计算机科学，或者是在 AI Agent 编程时代到来之前学会编程的人，对于现在的学生来说，哪些东西仍然值得用 “笨办法”、用过去的方式亲自学习？

Boris Cherny：对我来说，我学习计算机科学的方式非常实践导向。我通过自学编程来解决实际问题，在解决问题的过程中学习。我做这些事，都是因为当时有具体的问题要解决。我最开始其实是在 TI-83 计算器上学编程的，那还是上初中的时候。后来我还在网上写了一份 TI-83 计算器编程指南，现在网上可能还找得到。我学的第一门语言是 BASIC。我当时在计算器上学编程，就是为了数学考试作弊，这样能考得更好。对我来说，这完全是出于实际需求 —— 对于当时的初中生来说，这是我能想到的最实用的事。最后我确实考得很好，然后我买了一根小小的串行线缆，把程序传给我的同学，他们的成绩也都变好了。后来数学变难了，到了代数已经不够用的阶段，我就必须学汇编，写出更强的求解器，这样微积分考试才能继续 “作弊”。

对我来说，编程一直都是非常实践性的东西。所以我也一直给在校学生这个建议：不要只学习计算机科学 —— 当然，计算机科学在智力上非常有意思，也确实很值得学 —— 但你还要学习怎么把它应用起来。很多时候这意味着去创业、去构建产品，培养自己的设计品味，培养自己的商业嗅觉，学习怎么做数据科学，学习怎么和用户交流。还有很多其他技能，当你把这些技能和计算机科学、和工程结合起来的时候，它们才真正变得有价值。这些就是我现在仍然会选择亲手学习、亲手掌握的硬技能。

Diana Hu：所以如果我总结一下你的意思：先从为自己做一些你真正想要的东西开始，然后再进一步，去做一些其他人也想要的东西。Boris Cherny：是的。

结尾

Diana Hu：我们最后还有一个特别的消息要宣布，Boris，最后一件事。Boris Cherny：对。今天在场的每一位，都会获得 Max 20X 的额度。记得查看你们的邮箱，会有对应的邮件。我已经迫不及待想看看你们会做出什么东西了。

Diana Hu：太棒了。我很好奇，现场应该有人现在就会开始构建某个能连续运行几个月、调度数千个 Agent 的东西 —— 毕竟你们现在有账号和额度去做了。那就这样，非常感谢你，Boris。Boris Cherny：谢谢大家。

结论

本次对谈清晰勾勒出 AI 编程领域正在发生的范式转向。随着大模型能力的指数级提升，过去为弱模型设计的产品框架、复杂提示词与固定工作流，正逐渐从 “赋能工具” 转变为 “能力枷锁”。对于 AI 产品开发者与一线工程师而言，建立 “经验主义 + 减法思维” 的认知，敢于删除冗余设计、重新测试模型能力边界，将是释放新一代模型潜力、抓住 AI 生产力跃迁红利的核心关键。