Claude Code 创始人 Boris Cherny 在 Opus 5 发布后分享了 Agent 开发的新范式：模型已经能够连续工作数周，Claude Code 因此删除了超过 80% 的系统提示词；而决定长任务能否真正落地的关键，不是更复杂的 Prompt，而是清晰的目标、足够的工具与可验证的结束条件。
原视频：Boris Cherny: We Cut 80% of Claude Code’s Prompt
本文由 LobsterAI 自动翻译和发布。
一个编程 Agent 能连续工作多久？
在 Claude Code 创始人 Boris 的最新访谈里，答案已经不是几十分钟，也不是一夜。Opus 5 配合自动模式，可以持续运行数天、数周，甚至把任务拉长到数月。现场谈到的一个实验已经跑了两周多：它正在把一款 Electron 桌面应用重写成 Swift 原生应用，一边运行、一边截图，再逐像素比较两个版本，直到结果足够接近。
更反常识的是，模型变强之后，Claude Code 团队做的第一件事不是继续堆提示词，而是删掉了超过 80% 的系统提示词。
这场谈话真正讨论的并不是“怎样写出一条神奇 Prompt”，而是软件开发方式正在发生的一次倒转：过去，人围绕机器搭建庞大而精细的系统；现在，模型越来越像一个能力会持续变化的合作者，产品要做的反而是少挡路、给验证、让它工作。
Opus 5 的变化：从更聪明，到真正能长时间做事
访谈发生在 Opus 5 发布后的第二天。主持人提到，模型在 ARC AGI 3 上取得了 30% 的成绩，而此前最好的结果还停留在较低的个位数或十位数区间。Boris 没有把这种进步描述成一张能力清单，而是先讲了模型训练的不确定性。
训练新模型时，研究人员会尝试教它许多东西，大部分尝试不会按预期奏效；一部分能力会被学会，另一些能力甚至不是被直接教出来的，而是模型自己“长”出来的。
Opus 5 最突出的新能力之一，就是持续执行任务。
尤其与自动模式结合后，它可以一直向前推进，不必依赖复杂脚手架，也不一定需要 /goal 一类额外机制。它知道任务还没有完成，就会继续做下去。对 Agent 产品来说，这不只是“上下文更长”，而是模型开始具备一种过去很难稳定获得的工作连续性。
另一个变化更加敏感：Boris 称，Opus 5 已经很难再被提示注入攻破。
所谓提示注入，是模型在读取网页、文档或外部数据时，把其中恶意埋入的文字误当成高优先级指令。比如，网页正文突然要求 Agent 执行额外命令，甚至删除用户电脑里的内容。一年前的模型可能真的照做；Boris 表示，从较晚的 Opus 4.x 版本开始，这类风险已经明显下降，而 Opus 5 又把防线推到了新的水平。
他们采用的不是单一防护，而是三层组合：
- 经过长期对齐研究训练出的模型本身；
- 覆盖全部流量的提示注入分类器；
- 自动模式中的另一层分类机制。
其中，提示注入分类器借鉴了机制可解释性研究：系统观察模型内部在遭遇提示注入时会被激活的特征。模型未必主动报告“我正在被攻击”，但防护系统可以从内部信号判断异常。Boris 在现场的说法是，三层叠加之后，他们目前已经无法演示出有效的提示注入攻击。
这当然不等于世界上从此不存在攻击面。更准确的理解是：当模型本身的对齐能力与外部检测机制同时进步，Agent 产品过去因为安全顾虑而不敢开放的能力，开始有机会重新设计。
为什么 Claude Code 敢删掉 80% 的系统提示词
提示注入是外部文字试图控制模型，系统提示词则是产品主动给模型的约束。模型能力变化之后，这枚硬币的另一面也变了。
Boris 透露，Claude Code 在 Opus 5 上线时删除了超过 80% 的系统提示词。原因并不神秘：旧提示词中的大量内容，本来是在修正旧模型“不该犯、但确实会犯”的错误。Opus 5 已经自然具备这些行为，再把旧指令塞给它，不但多余，有时还会让模型表现得更笨。
Claude Code 的产品外壳一直在变。每次新模型发布，团队都会重新检查：
- 哪些系统提示词还需要；
- 哪些工具应该保留或下线；
- 工具提示词是否仍然有效；
- 外壳里的代码是在帮助模型，还是在妨碍模型。
团队采用的方法叫 ablation（消融实验）：先把整个系统提示词删除，再一行一行加回来，观察每一行究竟带来了什么影响。工具和外壳代码也做同样的实验。今天 Claude Code 外壳中留下来的内容，大量集中在安全、权限、静态分析和界面上；许多过去用于“教模型怎么做事”的代码已经被撤掉。
用户也可以自己尝试这种思路。访谈提到，可以自定义系统提示词；还可以通过一个未正式强调的 Simple 模式移除包括工具提示在内的全部系统提示，用来观察模型的裸能力。团队的实验甚至发现，没有这些提示时，模型在某些维度上会更聪明。
Boris 给普通 Claude Code 用户的建议也很激进：大约每六个月，把自己的 CLAUDE.md、Skills 和 Hooks 暂时删除一次，看看新模型在没有旧拐杖时能走到哪里。对 Opus 5，他尤其建议重新做这场实验，因为为旧模型准备的详细说明，很可能已经不再需要。
但这不代表产品应该完全没有提示词。真正面向人使用时，仍然需要一些说明来保证交互方式、行为边界和产品体验。关键不是追求“零提示”，而是让每一条留下来的指令都能证明自己的必要性。
Boris 给出的重建方法很朴素：先删，再用。
不要坐在会议室里猜模型需要什么。让它进入真实代码库或真实产品，观察它在哪里做得好、在哪里反复跌倒。只有当同一种失败持续出现时，才把相应指令加回来。因为这条指令以后会在每次运行时被模型重新读取，过早添加的代价会被不断重复。
就连评测集也不是永恒资产。它通常比产品外壳活得久一点，但可能只跨越一到三个模型世代。模型快速进步后，旧评测很快被打满，团队只能放弃它，再根据新模型真正困难的地方设计新评测。
这与传统工程经验几乎相反。过去，一次重构可能规划几个月，大公司的架构改造甚至持续几年；系统越成熟，越强调稳定设计。模型却更像一种有机体：每一代都有不同能力和“性格”。工程师需要先认识它，再调整周围的产品，而不是拿上一代的最佳实践硬套。
Product overhang 与 hobbling：模型会做，产品却没让它做
Boris 用两个概念解释这场变化：product overhang 和 hobbling。
Product overhang 指的是，今天的模型其实已经能做某些事，只是还没有产品把能力完整激发出来。Hobbling 则更直接：模型本来能做，产品外壳却因为过多限制、流程和脚手架挡住了它。
Claude Code 自己就是一个典型案例。
大约一年半到两年前，Sonnet 3.5 已经是当时很强的编程模型。可当时主流编程产品仍以单行补全、多行补全或只读聊天为主。模型也许已经可以一次写完整个函数、整份文件，但产品只允许它在狭窄的 IDE 交互里迈小步。
Claude Code 的起点，是去掉这些脚手架，给模型一个尽可能简单的外壳和完整终端访问，让它直接写整份文件、完成更大的任务。那不是模型突然升级，而是产品终于不再拦着它。
Boris 认为，今天仍有大量类似机会没有被创业公司抓住。发现它们的方法不是继续把任务切得更碎，而是有意把任务调高一个难度。
很多人习惯告诉模型：“先做一，再做二，然后严格按三和四执行。”这种写法适合过去能力不足的模型，却可能限制今天的模型。更好的方式是说清楚任务目标、护栏和退出条件，然后让模型自己决定路径。
不要只给模型你确信它能完成的任务。给它一个看上去稍微太难的任务，再给它证明自己做对了的办法。
六个月前行不通的做法，今天可能已经可用。理解模型能力的最好方式，不是阅读一堆“万能技巧”，而是不断拿新模型重试真实难题。
11 天重写 Bun：从 Zig 到 Rust，不是一条 Prompt 的魔法
Boris 给出的第一个大型案例来自 Bun。Bun 是 Claude Code 所使用的 JavaScript 运行时，原本用 Zig 编写。Zig 属于低层系统编程语言，需要手动处理内存，因此可能出现内存泄漏等问题。
早期，Bun 团队让 Claude 对代码库做模糊测试，模拟并触发内存泄漏。模型一次发现一个问题，这已经有价值，但仍属于局部修补。
后来，团队里的 Jared 把问题换了一个问法：既然模型一直在找内存问题，能不能干脆把相关代码从 Zig 重写成 Rust？这也是他会随着每一代新模型反复尝试的测试题。到字幕中提及的较新模型阶段，这件事开始变得可行，Opus 5 也能承担类似任务。
关键前提是验证机制。Bun 与 Node.js 都有规模很大的测试套件，可以持续判断重写是否正确。在此基础上，模型通过 Claude Code 的动态工作流执行任务，连续运行 11 天，完成了整个代码库的语言迁移。
这并不是“发出一条 Prompt 后再也没人碰”的神话。Boris 明确说，中途有人进行引导；但即便有人引导，旧模型也做不到。过去由优秀工程师完成，可能需要超过一年。访谈称，这次重写已经进入生产环境，并被 Claude Code 实际使用。
这个案例最值得记住的，不是“11 天”这个数字，而是任务定义发生了变化。旧思路是让 Agent 一次修一个内存泄漏；新思路是把整个语言迁移交给它，再用测试套件把长达 11 天的搜索过程拉回可靠轨道。
OpenCV 绘图：能力常常藏在没人认真试过的角落
Product overhang 不只存在于商业任务里。有时，最好的发现来自没有明确回报的玩耍。
Anthropic 内部一度流行给 Opus 5 使用 OpenCV，让它直接画图。它可以画肖像、动物和风景，而且效果出乎意料地好。团队并没有专门训练它“成为画家”，只是有人偶然找到了合适的工具和提问方式。
这类实验说明，模型能力并不总是整齐地写在发布说明里。它可能会使用某种语言、调用某个工具、解决某类问题，只是此前没人把正确的任务和环境放到它面前。
Boris 猜测，今天的模型里还藏着几十乃至上百个类似机会。它们不会自动变成产品，需要有人愿意暂时放下直接商业目标，允许自己试一些“看起来没什么用”的组合。
两周把 Electron 改写成 Swift：真正重要的是让模型会验收
如果说 Bun 的测试套件提供了清晰的成功标准，那么桌面应用重写展示了另一种验证方式。
Claude 的桌面应用使用 Electron 构建。Boris 想知道，如果改成 Swift 原生应用，体验会怎样。他先启动了一个让 Claude 在 Slack 中工作的会话，询问它能否访问 GitHub 上的 macOS runner。答案是否定的，于是他接入了 runner，让 Claude 能启动一台 Mac 虚拟机。
随后，他建立一个空代码库，并开放访问权限。最终任务只有几句话：
把 Electron 应用重写成 Swift；在 Mac 虚拟机里运行 Electron 版本并截图；再运行 Swift 版本，逐像素比较；在完成之前不要停。
访谈进行时，这个任务已经运行 14 到 15 天，而且还没有结束。Claude 还自己建了一个内部 Slack 频道，每隔几分钟发布进度截图，像是在为自己的长期工程做实时直播。
这件事把“怎样成为更好的 Prompt 工程师”换成了一个更实用的问题：模型如何知道自己做对了？
Boris 认为，验证是最常被忽略、也可能是最重要的一环。难任务本身并不可怕。只要模型拥有与人类完成同一任务时类似的检查工具，它就能在失败后调整，而不是靠一次生成碰运气。
也正因如此，这个实验不需要特别花哨的脚手架。/goal、/loop 等机制可以帮忙，但核心仍然是三件事：给任务，给工具，给可验证的结束条件。
Dynamic workflows、loops 与 routines：把算力组织成工作
那个持续两周的重写任务可能调动了多少 Agent？Boris 没有给出精确数字，只估计可能是数千，甚至数万。
Claude Code 中最直接的实现方式是 dynamic workflows（动态工作流）。用户只需要要求“使用 workflow”，Claude 就能在沙箱中启动并编排大量 Agent。它不是简单地并行开十个窗口，而是按任务进展动态组织多个阶段：
- 第一批 Agent 做初步实现或分析；
- 第二批 Agent 检查、总结或交叉验证；
- 后续阶段再根据结果扩散，继续处理新的子问题。
Boris 有函数式编程背景，因此团队把这套设计看作一种“Agent 代数”：Agent 可以串行，可以并行，也可以在沙箱里通过不同工具组合。这样既能提高 token 使用效率，也能完成横跨多阶段、多个拉取请求的大型任务。
他把动态工作流称为一种新的测试时计算组织方式。过去谈规模定律，常看神经网络大小、训练数据量和训练所需计算；后来，测试时计算把模型生成多少 token 也纳入能力扩展。动态工作流则进一步改变了这些计算如何被编排：不是让一个 Agent 单线思考得更久，而是让大量 Agent 分工、复核、汇总，再继续展开。
另外两种机制是 loops 和 routines。
Loop 类似在本地运行的定时任务；Routine 做的是同一类事情，但 Claude 在云端运行，用户可以合上电脑。动态工作流适合把一个复杂任务拆成有关联的阶段；loops 和 routines 更适合重复执行、彼此不共享上下文但可以共享记忆的任务，例如每五分钟、每小时或每天检查一次代码库。
让 Claude 维护 Claude：代码库开始拥有“日常保养”
Claude 团队已经让 Claude 参与维护自己的代码库，覆盖 CLI、iOS、Android 和桌面应用。做法并不复杂：在 Slack 频道里启动一批 routines，让它们每天执行固定职责。
其中包括：
- 查找并清理死代码，结合静态与动态分析提交拉取请求；
- 删除已经全量发布、不再需要保留的实验代码；
- 为测试覆盖不足的区域补测试；
- 删除旧模型或人类曾经加入、但实际没有价值的测试；
- 执行“抽象警察”任务，寻找不同位置重复出现、实质相近的抽象，并把它们统一起来。
团队每天大约运行 20 到 30 个 routines，遍历所有代码库。它还没有完全实现应用维护自动化，但方向已经清晰：每天有数百、偶尔数千个 Agent 工作，承担过去可能需要数十乃至数百名工程师才能持续处理的维护量。
这并不是把工程师变成旁观者。相反，它把人从死代码、实验清理和重复抽象中释放出来，把时间重新放到发布新产品、与用户交谈，以及那些真正有创造性的工作上。
“Coding is solved”有边界，不是所有代码都解决了
Boris 过去说过“coding is solved”，但在现场主动加上了限定：对他自己平时做的那类编程，编码问题已经基本解决；对所有人，还没有。
Claude 依然会在一些领域挣扎：
- 极深的系统级代码库；
- 复杂分布式系统；
- 需要钻进细节的界面验证；
- 像素级误差等视觉问题。
Opus 5 在视觉和计算机操作上迈出了一大步，但还不完美。现场调查也显示，一部分人已经把 100% 的代码交给 Agent，更多人超过了 50%，但这仍不是普遍状态。
因此，“编程已解决”更像一条不断向外扩张的边界。每一代模型都会覆盖更多类型的代码，却不意味着工程判断、验证和产品能力一夜之间消失。
真正拉开使用者差距的，是一种近乎实验科学的心态。
优秀使用者愿意忘掉旧模型留下的经验，也愿意暂时放下课堂里先验的理论判断。他们先让模型做，观察它在哪里失败，再调整 Prompt、补充 Skill；如果缺的是上下文，就接入 MCP，让模型自己取回需要的信息。
Boris 还开玩笑说，别听 LinkedIn 上的网红，也别沉迷 Twitter 上的“一个怪招”。因为不存在能瞬间成为顶尖 Claude Code 用户的秘密指令。最有效的方法恰恰很朴素：给一个略难的任务，提供验证工具，看它怎么做，然后迭代。
资深工程师反而可能更容易踩坑。他们过去习惯把系统描述得极其精确，要求模型严格按照自己会采用的步骤执行。面对今天的模型，这常常变成过度工程。更合适的关系，是把它当成一个能力已经接近同事的合作者：把目标和边界讲明白，允许它用自己的路径完成。
学生还应该学什么：从“我想解决的问题”开始
最后一个问题留给正在学习计算机科学的学生：当 Agent 能写越来越多代码，还有什么值得用旧方式亲手学？
Boris 的答案来自自己的经历。他最早在中学用 TI-83 计算器学编程，第一门语言是 BASIC。他甚至在网上写过一份 TI-83 编程指南。最初目的相当“实用”：写程序帮助自己在数学考试中取得更好成绩，还用串口线把程序分给同学。
后来数学越来越难，BASIC 写的代数求解器不够用了。学到微积分后，他又开始学汇编，只为了做出更强的求解器。这个故事带着一点学生时代的坏笑，却准确说明了他的学习逻辑：不是先把知识目录学完，再寻找用途；而是先有一个非解决不可的问题，再被问题逼着升级工具。
他并不否认计算机科学本身的智力魅力，但学生不能只学理论。仍然值得亲手练习的，是把技术放进现实：
- 构建产品或创业项目；
- 培养设计判断和商业感觉；
- 学会数据科学；
- 与真实用户交流；
- 把工程能力与其他领域组合起来。
计算机科学与工程的价值，不只在于能否独立敲出每一行代码，而在于它和设计、商业、数据、用户理解结合后，能否做出真正有人需要的东西。
主持人把这条路径压缩成一句话：先为自己做一个想要的东西，再升级到为别人做一个需要的东西。Boris 的回答是：“对。”
最后的彩蛋：现场观众获得 Max 20X
谈话结束前，Boris 宣布现场观众将获得 Max 20X，兑换码会通过邮件发送。全场随即欢呼。
主持人也顺势留下了一个挑战：既然账户和资源已经到手，这个房间里应该有人去构建一个能连续运行数月、调动数千个 Agent 的项目。
这或许也是整场访谈最贴切的结尾。模型的新能力不会因为发布会上的分数自动变成产品。真正有价值的东西，仍然要靠人去提出那个稍微太难的问题，拆掉不必要的限制，再给 Agent 一面能照见对错的镜子。