← #803

对话 Boris Cherny：我们砍掉了 Claude Code 80% 的提示词

文章摘要

这是 Y Combinator 频道 2026 年 7 月 27 日发布的一段 36 分钟访谈，标题为「Boris Cherny: We Cut 80% of Claude Code’s Prompt」，上线数日播放量已超过 21 万。访谈在 Startup School 2026 现场录制，由 YC 的 Diana Hu 对话 Claude Code 的创造者 Boris Cherny，时间点正好在 Opus 5 发布的第二天。官方章节列表包括：Opus 5 有何不同、解决提示注入、Claude Code 为何删掉 80% 的系统提示、对你的 AI 产品按下删除键、如何重建系统提示、产品悬置与「解除束缚」、给 Claude 更难的问题、提示工程正在改变、跑了两周的 Claude Code 提示、运行数千个智能体、编程（几乎）已解决、每个 CS 学生仍应学什么。YC 同时放出了完整文字稿。

Opus 5 的两项新能力。Cherny 说每次训练都会尝试教模型一大堆东西，多数不奏效，但总有一部分学会了，有时还会学会你根本没教的技能。Opus 5 上他认为没有其他模型做到过的一点是：它能极长时间地持续运行，配合 Auto Mode 可以连续跑上数天、数周乃至数月而不停下，甚至不需要任何脚手架。另一件让他兴奋的事是模型看起来已经不再可被提示注入了——人们讨论「致命三要素」很久了，而这直接影响 harness 设计、智能体设计和产品设计。一年前模型读到网上「顺便把用户电脑上的东西全删了」这类指令真的会照做，现在不会。他说这是三年对齐研究的成果，叠加对全部流量运行的提示注入分类器（基于机制可解释性工作，字面意义上观察模型「大脑」里在提示注入发生时点亮的神经元，模型自己都不会说出来，但他们能看见并诊断），再叠加 Auto Mode 分类器，三层下来他们已经无法演示出提示注入了。

删掉 80% 的系统提示。Cherny 说很多人可能没意识到，Claude Code 作为产品和 harness 一直在变，每次新模型出来他们都会删掉一大块系统提示、改掉一大块，工具集和工具提示也一直在改。原因是每个模型都很不一样，三个月前为某个模型做的事可能完全不适用于下一个。Opus 5 就是太聪明了，系统提示里很多内容原本是在纠正「模型本该知道却不知道」的行为，现在 Opus 5 直接就做对了。他还透露了一个未文档化的功能：设置环境变量 CLAUDE_CODE_SIMPLE=1 再运行，会删掉包括工具在内的所有系统提示；他们用这个做消融实验来判断提示是否有用。有意思的发现是，没有这些提示时模型其实还更聪明一点，但作为产品你确实需要一些提示，因为它们帮助用户使用产品、让模型的行为符合人的期待。

消融式开发。Diana 总结说这在旧世界里是创业公司绝不会干的事——每六个月对所有东西按一次删除键。Cherny 澄清他们不会删掉整个代码库，但确实删掉很多。他解释「消融」（ablation）来自研究：删掉整个系统提示，然后一行一行加回来，以判断每一行的影响；这本质上是一种 eval。工具也一样，他们经常下线工具、经常删 harness 代码。他说今天 Claude Code harness 里的代码几乎全是关于安全、权限和静态分析的，还有一堆 UI 代码，其他很多代码早就下线了。他建议所有构建智能体产品的人都这么做，对于只是使用 Claude Code 的用户，他的建议是每六个月删掉你的配置、skills 和 hooks，看看模型会怎么做，可能会让你吃惊。

重建的方法与「反工程化」心态。重建要一块一块来：先删，然后用；不要猜模型需要什么指令，因为你可能猜错。只有当你反复看到它在同一件事上栽跟头时，才把那条指令加回来。要记住模型每次使用都会读这条指令。他说这与他做过的所有工程都不同：过去你构建大而美的系统，前期认真设计，有大量单元测试，重构是一个持续数月甚至数年的大项目；模型不是这样，更像一个活物、一个有机体，每一代都有略微不同的性格，你得花时间去了解它，然后据此调整 harness。这是彻底经验主义、科学式的过程。关于 eval，他认为 eval 比 harness 活得久一点，但也没久多少——一个 eval 大概能活一到三代模型，如今曲线太陡，往往刚跑饱和就得扔掉重做。

产品悬置与解除束缚。「束缚」（hobbling）指模型本来能做某事，是你在挡路；「产品悬置」（product overhang）指今天的模型就已经具备很多能力，但没有产品让它表达出来。他举了 Claude Code 诞生的例子：一年半到两年前 Sonnet 3.5 是当时最好的编程模型，但那时的编程产品在做单行补全、多行补全，或者只读的代码库问答，没有产品能释放模型「一次写完整个函数、整个文件」的能力。于是 Claude Code 的想法就是——扔掉所有脚手架，给模型最简单的 harness。他认为今天的模型存在大量创业公司尚未捕捉的产品悬置。

具体案例。第一个是 Bun 的重写。Claude Code 构建在 Bun 之上，而 Bun 用 Zig 写成，需要手动内存管理，容易出内存泄漏。Bun 团队原先让 Claude 对代码库做模糊测试来触发内存泄漏，一次一个 case 地找。后来 Jared 决定干脆试试整体重写，用每一代新模型去试这道题；从 Fable 开始模型开始能做到，Opus 5 也能。做法是定义好测试套件（Bun 和 Node.js 都有很大的测试套件，所以容易判断对错），用一条提示启动一个动态工作流（dynamic workflow），跑了 11 天，重写了整个 10 万行以上的代码库，从 Zig 改到 Rust。Cherny 强调这不是一次性成功，中途有引导（steering），但此前的模型即使有引导也做不到。这份成果现在已经在生产环境，就是你今天运行 Claude Code 时用的东西。第二个例子是他自己的实验：想看看 Claude 桌面应用如果做成原生的会是什么感觉，于是在 Claude Tag（跑在 Slack 里的 Claude）里开了一个会话，先接上 GitHub 的 macOS runner，再给它一个空的 Swift 代码库，然后下了一条提示——把 Electron 应用重写成 Swift，在 Mac 虚拟机里运行 Electron 版、截图、逐像素与 Swift 版对比，不做完不要停。访谈录制时这个任务已经跑了两周多且仍在运行，Claude 还自己建了个 Slack 频道，每隔几分钟发截图直播进度。他估计它派生了数千甚至数万个子智能体。

动态工作流与自我维护。他解释动态工作流的做法是用 Bun 作为沙箱、在其中启动虚拟机，让 Claude 启动并编排大量智能体：先派一批做第一遍，再派一批验证或总结，再扇出第三阶段。他的背景是函数式编程，所以这套设计本质上是「智能体的代数」——有顺序执行的方式，有并行执行的方式。他称之为一种新形式的测试时计算（test time compute）。另一条路径是 loops 和 routines：loop 相当于本地跑的 cron，routine 是跑在云端的同一个东西（可以合上笔记本）。他们现在让 Claude 维护自己：在一个 Slack 频道里跑一堆 routine 来维护 CLI、iOS、Android、桌面应用的代码库。例如「清理死代码」是一条只有一句话的提示，Claude 每天用静态和动态分析在所有代码库里找死代码并提 PR——用静态分析这件事没人提示过，是它自己想出来的。其他 routine 包括把已经 100% 放量的实验代码清掉并发布、为覆盖不足的区域补测试、删掉旧模型或旧时代的人留下的无用测试。他最喜欢的一条叫「抽象警察」：在大代码库里找那些经过时间演化被重复实现了多次、其实应该合并的近似抽象，并把它们统一起来。他说现在每天有 20 到 30 条这样的 routine 在跑，「还没完全做到，但我们正走在完全自动化应用维护的路上」。

编程是否已解决。Cherny 主动加了限定：编程对他做的那类编程来说已经解决了，但不是对所有人。仍然有非常深的系统代码库让 Claude 吃力，分布式系统让 Claude 吃力，非常细的 UI 验证（差了一个像素之类）Claude 也还不完美——Opus 5 在视觉和计算机使用上是一次大跃进，但仍不完美。现场举手调查中，「100% 代码由智能体写」和「超过 50%」的举手人数相差不多。关于「验证」他强调这是人们最普遍做不对的一件事：给 Claude 一个稍微超出你认为它能力范围的任务，然后让它能像你自己做时那样验证自己的工作。至于 prompt engineering，他说一年前最热门的岗位是提示工程师，后来变成上下文工程师，这些浪潮会来来去去；他的建议是「别听 LinkedIn 网红的」，不存在什么一招鲜，只能经验主义地做。他观察到写了很多年代码的工程师有一个非常常见的失效模式：过度指定，试图让模型按自己会用的方式一步步做，而这不是模型的工作方式。

给学生的建议。Cherny 说他学计算机是实践式的：中学时在 TI-83 计算器上用 BASIC 写代数解题器来在数学考试上作弊，还写过一份 TI-83 编程指南发到网上，后来用串口线把程序分给同学，同学们成绩也变好了；等到微积分，BASIC 不够用了，他就转去写汇编以便「作弊得更好」。他的建议是不要只学计算机科学理论，还要学会应用它——做创业公司、做产品、培养自己的设计感和商业感、学数据科学、学会和用户对话，这些技能与工程结合起来才真正有价值。访谈最后他宣布现场所有人都能获得 Max 20X 订阅。

HN 评论精华

这个帖子拿到 74 分、80 条评论，规模不大但对抗性很强。HN 的整体反应远比访谈本身怀疑：一部分人认真讨论「删配置」这条建议的技术合理性，另一部分人直接把 Cherny 定性为 token 推销员。

关于「删掉你的 CLAUDE.md」

ventana 的摘要贴（也是最高票）把整段建议提炼为：删掉所有为旧模型准备的定制、CLAUDE.md、skills 和其他东西，不带这些跑新模型，模型可能会让你意外。knighthacker 也认为这是全场最有意思的部分。
georgemcbay 说他一直认为，即便对旧模型而言，人们裹在 LLM 外面的那一大堆上下文填充物更像是影响随机数的护身符（而且不总是往好的方向），很多人抓住它是一种自我安慰：「我可能不怎么写代码了，但我至少还能当个提示工程专家。」troupo 引用了自己去年写的一篇文章，称这些「实际上就是萨满仪式，结果建立在信仰、恐惧或兴奋之上，这不是工程」。
CuriouslyC 给出了这条支线里最有技术含量的解释：新模型真正的变化是 RL 相对预训练的比重，RL 通过把分布向期望结果收缩来让模型变稳定；那些老技巧（给智能体安角色「你是一位资深 XYZ 工程师」、往上下文里塞工程惯例）已经被 RL 训练到无关紧要了，但它们仍在浪费 token。他用图像生成做类比：SD 1.5 会因为提示和种子的微小变化产出天差地别的图，而最新的图像模型对种子几乎无感、对提示改动也能保持一致。
m_ke 提出了一个务实的产品诉求：所有 harness 都应该支持把配置文件和工具绑定到特定模型或模型家族，「每次模型发布都要调整所有东西、然后眼看这些改动把便宜模型搞坏，实在太累了」。albert_e 也提议 SKILL.md 和 CLAUDE.md 应该像 CloudFormation 模板那样带上版本号。verdverm 反驳说这假设了所有人用同一个模型，而他所在的团队用各种模型，他们的做法是把 AGENTS.md 保持简单、只聚焦 monorepo 的怪癖，不写针对特定智能体或模型的指令。crazylogger 提出了最激进的版本：这些文件就该是指向 CONTRIBUTING.md 和其他给人读的文档的符号链接，因为 LLM 的整个前提就是它们用和我们一样的语言和工具，我们不该为它们专门设计任何东西。
throwaway219450 提出了一个实际的团队协作问题：如果引导和纠正性指令现在都该放进 memories，而 memories 是不可移植的，那团队成员之间怎么共享、怎么避免每个人重复一遍？他同意不该往 agent 文件里写「写干净的代码」这种废话，但表示没看到足够证据说明模型在推断意图或假设正确性上有显著提升——他一直是「非常受限的指令」比「fix the install」得到更好结果。anon373839 更直白：「这就是想把你导向供应商锁定。记住，这帮人对自己的产品不安全感强到不肯支持 .agents/AGENTS.md 标准。」
joebates 提出了一个受欢迎的功能建议：类似 Chrome 无痕模式的「无配置」临时会话。kxxx 给出了现成答案：claude --bare --system-prompt "" 是个不错的起点。matltc 补充说 --bare 的（潜在）缺点是它以 print 模式运行，起不了交互会话，他自己用的是一组等价的长参数包装，以及一个固定到 Haiku 用于快速提问的变体。
bmitc 提出了最根本的质疑：这本该是他们该做的事，而不是客户该做的，「因为一家公司/产品偷懒就要我每六个月重新发明一次工作流，这在我的清单上排位不高」。lorey 顺着说：这段话的潜台词是用 CLAUDE.md 有可能让 Claude 变差，那就是他们那边的可用性问题。bmitc 补充说他见过 Anthropic 多次发出这类「哦，你只要这样那样就行了」的说法，而他的想法一直是「这不正是大家付钱给 Anthropic 要它做的事吗？」
mupuff1234 提供了一个反向数据点：他两天前还在用 Opus 4.6，没有任何 CLAUDE.md，体验很好；换到 Opus 5 后开箱体验反而非常烦人。sivanmz 从职业发展角度发问：如果所有 harness 定制都是转瞬即逝的（还记得提示工程吗），开发者还能在什么上面建立专长和差异化？他说这些概括、抽象、可组合性的本能，正如 Cherny 所言，都会被下一代模型的 RL 吸收掉。

「他是个 token 推销员」

rvz 的评论定下了整个怀疑派的基调：推销员「建议」你浪费更多 token，「建议」你只用最新最强的模型跑递归循环，最后还「建议」你别看代码、别理解代码；这些「建议」的设计目的就是让你花更多 token、被 Opus / Fable 老虎机勾住，尽可能榨干你的钱包。ifwinterco 附议：无论他是否真的认为那是最高效的方式，他都会推荐一直派生大量智能体的工作流。
Diogenesian 给出了一个更宽厚的版本：Cherny 不是在玩世不恭地推销，他是自己嗑嗨了——他是真心为「Claude Code 是一坨他自己都不懂的过度工程化垃圾」而兴奋。hvb2 预言了下一个标题：一个存在 10 年以上的代码库被智能体接管后，公司虽然握有源码，却像是从供应商那里买来的一样，要为每次修改付钱给那个供应商——而这个「自家系统的供应商」就是那家卖 token 给你的 AI 公司。
iooi 对 Bun 重写案例提出了一个尖锐的质疑：如果模型真那么好，为什么需要「重写」？直接从零造出一个运行时不就完了。__alexs 补了一句「当活动本身取代成果被歌颂，那就是生产力表演，这在美国科技文化里到处都是」；whateveracct 更简单：「这部分是营销噱头。」不过 chromakode 给出了严肃的反驳：代码是捕捉需求的绝佳载体，尤其是随时间迭代出来的产品发现；从需求的具体实现（以及不变量的测试）出发，比从第一性原理开始容易得多。schainks 也说 Rust 对这个任务而言是好工具，现成工具能干的事为什么要造新的。sushid 则挖苦道：模型要真这么厉害，早该修好那些困扰 Claude Code 一年多的 TUI 问题了——nnx 接话「闪烁彻底修好了吗？」
jake_and_fatman 对现场举手环节提出了直接指控：Cherny 先问「100% 代码由智能体写的举手」，接着问「超过 50% 的呢」，能看到同一批举过手的人耸耸肩又举了一次，而他说「手略少了一些」，这只说明他看见了自己想看见的东西，「别信这个人」。他还挖苦了「工程师可以去做他们真正想做的事，也就是和用户聊天……真正有趣的事」这句话。

「harness 缺的不是并行智能体忍术」

firasd 贡献了整个帖子里最有建设性的批评，也引出了最长的技术支线。他认为 Claude Code 的大洞见是「给 AI 工具，实际上是给它你的笔记本」，一年半后这已经成为所有前沿实验室的旗舰产品形态。但他不认为这些 harness 作者的其他「想法」有多普适——他们最近连自己那套 skills.md/claude.md 装备都在唱衰。他尤其怀疑「派生智能体」这整件事：比如「找出这个代码库里的每个函数」，用脚本提取函数名显然比派 20 个智能体在 token 空间里「读」代码块要好，但后者的 token 消耗对卖推理的人很有利。他真正想要的是别的东西：为什么没有一个「把这个函数从这个文件移到那个文件」的工具（复制粘贴字符范围），非要看着 Claude/Codex 在 token 空间里手忙脚乱地重写大段代码？
这引发了一场关于 LSP 能力边界的激烈交锋。rescripting 说这个已经有了，装 LSP 就行。firasd 反驳说 LSP 更像是更好的 grep。throw478239 详细纠正说大多数 LSP 都提供文本编辑能力，协议里叫「code actions」，包括整理导入、展开宏、把选区提取为函数、转换控制流形式等，rust-analyzer 和 Ruff 都支持。firasd 追问：能不能给我看一个能从命令行把任意函数从 file1.ts 移到 file2.ts 的 LSP 服务器？jaggederest 回答说 LSP 不是命令行应用而是走 JSON-RPC 的交互式流程，需要客户端持有状态，而且它做的比「任意字符范围」聪明得多——那是 AST 变换，把解析树取出来放进另一个文件并更新所有引用该函数的导入，全部发生在 LSP 一侧因而是确定性的。henrymerrilees 补充了 TypeScript「Move to file」重构的实现链接和 ast-grep 项目。firasd 的最终立场是：这恰恰证明了他的观点——这个模式并没有默认集成进 Claude Code 或 Codex，你得自己想办法把这个服务器跑起来，「就像为了让 harness 管理 todo 而去跑一个 Redis」。bmitc 站在 firasd 一边并补充实战经验：即便通过 Claude 安装了 LSP 并明确指示要用，Claude Code 也经常无视它们，退回去用 grep 和 sed。senand 和 verdverm 分别推荐了 serena 和 Go 的 gopls（后者确实有跨文件移动函数的能力，且能省下大量 token）。
bmitc 把 firasd 的观点推得更远：软件开发里缺失了太多东西，我们从零直接跳到了一百，跳过了中间；这和电动车与自动驾驶如出一辙——所有人决定从「无辅助」直接跳到「完全自动驾驶」，而不是渐进地建设驾驶辅助能力。「我们的版本控制系统至今仍在操作一堆文本行，这挺荒唐的。」

用户实感

mfallon 说他花了一年时间在不会写代码的情况下用 Claude Code 做应用，至今仍惊讶于即便最新模型也会出这么多错；让它对他有效的做法是精确描述想要什么，然后真的去检查它交回来的每一样东西。EagleEdge 说他不信任 Claude Code 写一流的专业代码，用过所有前沿 Claude 模型，它总是做得潦草、需要 codex 来收拾，因此他的配置是所有执行和评审都交给 codex。wilj 描述了一套更复杂的组合：用 Claude Code 和 Codex 写规格，然后让 Deepseek v4 Pro 实现，因为给足次数它「真的会照做」。slopinthebag 说他正在过一批前沿模型生成的组件，虽然「能跑」但代码相当惊人，会造成显著的维护负担，而且完全不用团队的共享工具、重复了大量代码。troupo 补充说上下文管理救不了：他把要求明确写进了 AGENTS.md，但一分钟后它（和 Claude）就会忽略/遗忘一半内容，「因为宣传的 100 万 token 上下文不过是营销鬼话」。
DennisL123 提出了一个哲学性的收尾：构建软件是关于达成成果（outcome），不是关于生成产出（output，即 token）；而 AI 的商业模式明摆着卖的是 output，这两者怎么调和？yetihehe 类比说「造桥是关于成果和效用，但钢材和水泥供应商按吨卖」，miyoji 顺着这个类比补了整个帖子最好笑的一刀：vibe coding 就是从直升机上把钢材和水泥倒进水里，然后因为技术上能走过去就管它叫桥。