AI之Interview：Claude Code之父Boris Cherny深度访谈—删除80%提示词、产品悬余、解缚思维与AI编程的范式转移

AI之Interview：Claude Code之父Boris Cherny深度访谈—删除80%提示词、产品悬余、解缚思维与AI编程的范式转移

导读：本次访谈是Claude Code创始人Boris Cherny对当前AI产品构建范式的一次系统性“方法论交付”。在访谈中，Boris Cherny首次系统披露了Anthropic面对模型能力指数级跃迁时的产品方法论：每六个月对系统提示词按下删除键、用“消融实验”替代传统系统设计、将模型视为“活体生物”而非固定系统。本文基于完整访谈记录，逐章拆解Boris关于Opus 5新特性、产品悬余（Product Overhang）、解缚（Unhobbling）、动态工作流以及编程教育的核心观点，为每一位AI产品构建者提供可落地的思考框架。

核心价值在于三个层面：

第一，产品迭代的范式切换。Boris反复强调，AI产品的构建与传统软件工程截然不同——传统工程强调前置设计、系统规划和长期稳定性，而AI产品需要“经验主义+持续消融”的科学心态。每六个月主动删除所有提示词、工具和hooks，通过实证而非直觉判断哪些组件真正有效，这一方法不仅适用于Anthropic内部，也适用于所有构建AI产品的团队。

第二，模型能力释放的思维框架。“产品悬余”和“解缚”是贯穿全篇的两个核心概念——当前每一代模型都有远超产品所释放的能力储备，而大多数产品设计反而在“掣肘”（Hobbling）模型而非激发其潜力。正确做法是：给模型比直觉判断更难的任务、提供高层级目标而非具体步骤、以及最关键地——设计让模型可自主验证工作的闭环机制。Bun的11天跨语言重写和Claude Desktop的两周Swift重写是这一框架的极致体现。

第三，对AI时代的角色重新定义。对产品构建者，核心技能已从提示词工程转向“验证机制设计”与“Agent编排”（动态工作流、Routines）；对编程学习者，纯计算机科学理论的壁垒正在降低，真正的差异化来自商业感、设计感、用户洞察等综合能力的组合。Boris最后的“先做自己想要的东西，再升级去做别人想要的东西”，既是对个人成长路径的总结，也是对AI时代所有创新者的核心建议——从自己的真实需求出发，让模型作为杠杆，撬动此前不可能的任务规模。

整体而言，这不仅是一场关于Claude Code的产品分享，更是一套面向“指数级能力跃迁”时代的构建哲学：拥抱不确定性、信任模型的本能、用实验代替预测、用验证代替控制。

目录

Claude Code之父Boris Cherny深度访谈—删除80%提示词、产品悬余、解缚思维与AI编程的范式转移

1、Opus 5的突破性能力

核心要点

经验技巧

2、提示注入的三层防御体系

核心要点

经验技巧

3、为何删除80%的系统提示词

核心要点

经验技巧

4、勇敢按下删除键——消融实验思维

核心要点

经验技巧

5、如何科学地重建系统提示词

核心要点

经验技巧

6、产品悬余与“解缚”思维

核心要点

经验技巧

7、让模型处理更难的任务

核心要点

经验技巧

8、提示工程的范式转移

核心要点

经验技巧

9、两周任务实录——验证即生命线

核心要点

经验技巧

10、运行数千个AI智能体

核心要点

经验技巧

11、编程（几乎）被解决了

核心要点

经验技巧

12、每个CS学生今天仍需学习的技能

核心要点

经验技巧

Claude Code之父Boris Cherny深度访谈—删除80%提示词、产品悬余、解缚思维与AI编程的范式转移

1、Opus 5的突破性能力

Boris Cherny介绍了刚发布的Opus 5相较于前代模型的核心突破。他强调Opus 5在Arc AGI 3上取得30%的得分（此前最好成绩仅为个位数或低双位数），但真正的杀手锏并非基准测试分数，而是两项颠覆性的产品级能力：超长时程自主运行（可持续数天、数周甚至数月而无需额外脚手架）以及近乎免疫的提示注入防御。这两项能力直接重塑了Agent产品的设计范式。

核心要点

>> 超长时程自主运行能力：Opus 5结合Auto Mode后可持续运行数天至数月而不停止，无需使用/goal、/loop等脚手架指令，模型凭借自身对任务的理解持续推进；

>> Arc AGI 3性能跃升：Opus 5在Arc AGI 3基准上达到30%的得分，相较于此前模型低个位数或低双位数的成绩实现了质的飞跃；

>> 提示注入防御达到新前沿：Opus 5几乎不再受提示注入攻击影响，这一能力实际上从Opus 4.7、4.8开始逐步显现，Sonnet 5和Fable也已表现良好，但Opus 5将此能力提升至全新水平。

经验技巧

>> 评估模型时关注“意外习得能力”：模型训练中会意外习得未被明确教导的技能（如超长时程运行），产品构建者应通过开放式测试而非仅依赖预设基准来发现这些能力；

>> 将长时程运行作为Agent产品的基础能力考量：若模型本身已具备数天自主运行能力，产品的脚手架设计应从“引导”转向“护航”——提供退出条件和验证机制即可，无需过度干预。

2、提示注入的三层防御体系

Boris详细拆解了Anthropic如何实现对提示注入的近乎完全防御。他强调这不是单一技术，而是三层机制的组合：对齐研究（三年累积的模型对齐训练）、基于机制可解释性的神经元监测（直接观察模型大脑中因提示注入而“点亮”的神经元，即使模型不主动报告也能诊断攻击）、以及自动模式分类器。三者叠加后，团队已无法再演示出成功的提示注入攻击。

核心要点

>> 三层防御架构：① 经过三年研究积累的强对齐模型；② 基于Crysola机制可解释性工作的提示注入分类器（直接观察模型中因提示注入而激活的神经元）；③ 自动模式分类器——三者结合后已无法成功演示提示注入攻击；

>> 主动检测优于被动依赖：系统能通过神经元层面的监测主动诊断提示注入，无需等待模型自身报告异常。

经验技巧

>> Agent产品需建立多层安全护栏：不能仅依赖模型本身的“道德判断”，应在架构层面叠加行为监控和异常检测层；

>> 机制可解释性的商业化应用：监测特定神经元激活模式可作为实时安全检测信号，这一思路可推广至其他安全风险场景（如越狱、目标偏离）。

3、为何删除80%的系统提示词

本章揭示了一个反直觉的产品事实：Claude Code的产品和harness始终在剧烈变动，每一次新模型发布都会触发大量删除和重写。Boris解释，旧模型的系统提示词中大量内容是在“矫正模型本该知道却不知道的行为”，而Opus 5足够智能，已经天然具备这些能力，因此删除了80%的提示词。他甚至透露，用户可通过–system-prompt参数自定义提示词，或设置CLAUDE_CODE_SIMPLE=1环境变量来完全删除所有系统提示（包括工具提示），且实验发现无提示词时模型反而更聪明。

核心要点

>> 提示词删除的根本原因：旧提示词修正的是旧模型的缺陷行为，新模型已内化这些能力，保留反而多余甚至干扰；

>> 产品的持续性变动：Claude Code的提示词、工具集、工具提示均在持续增删，每次新模型发布都触发大幅调整；

>> “无提示词更聪明”的实验发现：通过Simple Mode（CLAUDE_CODE_SIMPLE=1）完全删除所有提示后发现模型在某些维度上更智能，但作为产品仍需保留部分提示以保证行为符合用户预期。

经验技巧

>> 不要将模型视为固定目标：每一代模型都有不同的“性格”和能力边界，旧提示词无法平移，应主动做减法而非仅做加法；

>> 定期执行“提示词消融”：完全删除所有提示词后运行产品，观察模型原生行为，以此判断哪些指令真正必要；

>> 将删除作为标准迭代步骤：在新模型发布时，不要先问“加什么”，而应先问“删什么”。

4、勇敢按下删除键——消融实验思维

Boris提出一个大胆主张：每隔六个月，不仅应删除系统提示词，还应删除CLAUDE.md、skills、hooks等所有附加物，观察模型在“裸奔”状态下的表现。他将此称为消融实验（Ablation）——删除整个系统提示词后逐行加回以评估每行指令的实际贡献。对于产品构建者，他建议每次模型更新时对代码库和工具集同样执行消融，因为今天Claude Code的harness代码中几乎只剩下安全、权限和静态分析相关的内容，大量早期代码已被“下架”（unshipped）。

核心要点

>> 消融实验的操作定义：完全删除系统提示词后逐行加回，以评估每一行指令的真实影响，本质上是一种特殊的评估（Eval）；

>> 删除范围扩展：不仅删除提示词，还应定期删除CLAUDE.md、skills、hooks及harness代码，观察模型在新版本下的实际表现；

>> harness代码的演化：当前Claude Code的harness代码几乎仅剩安全、权限和静态分析及UI相关功能，大量早期功能代码已被下架。

经验技巧

>> 每六个月主动执行一次“完整删除测试”：删除所有自定义提示词、技能、钩子，运行产品，让新模型展示其原生能力，往往会有惊喜；

>> 将消融实验纳入产品迭代的标准流程：不要因为过去的投入而保留无用指令，每个遗留模块都应能证明其当前价值；

>> 区分“产品必需指令”与“模型缺陷补丁”：若指令仅在旧模型上有用，果断删除。

5、如何科学地重建系统提示词

本章提供了具体的重建方法论。Boris强调不要预判模型需要什么指令（因为几乎必然猜错），正确做法是：第一步删除全部提示词，第二步直接运行产品，第三步观察模型在何处反复失败或卡住，第四步仅在模型反复在同一问题上跌倒时才添加回该指令。他指出，这与传统工程完全不同——后者需要预先做系统设计、单元测试、全面规划，而AI产品构建更像对待一个“活体生物”，需要经验主义心态：尝试→观察结果→迭代。

核心要点

>> 四步重建法：① 删除全部提示词；② 直接运行产品（不预判）；③ 观察模型反复失败的场景；④ 仅在重复性失败点上添加回指令；

>> 加回时机原则：不要过早添加指令，模型会在每次调用时读取这些指令，必须确保其确有必要；

>> 与传统工程的本质区别：传统工程强调前置系统设计和全面规划，AI产品构建则是“经验性科学”和“有机的”，需先尝试再根据结果调整；

>> 模型的“生物属性”：每一代模型有不同“性格”，需要花时间去了解它，再据此调整harness。

经验技巧

>> 放弃“预判式设计”思维：不要试图在事前设计完美系统，应允许试错并基于实证数据做决策；

>> 引入“科学家心态”而非“工程师心态”：将产品视为实验对象，提出假设→执行测试→观察结果→修正假设；

>> 指令添加的最低必要原则：每条新增指令都必须有实证依据（观察到模型重复失败），而非基于直觉或旧经验。

6、产品悬余与“解缚”思维

本章提出了全篇最核心的概念框架。产品悬余（Product Overhang） 指模型已具备的、但产品尚未释放出来的能力集合——每一代模型都有大量未被产品挖掘的能力。而掣肘（Hobbling） 则是产品主动或被动地阻碍模型能力发挥的反面。Boris以Claude Code的诞生为例：Sonnet 3.5时期模型已能一次编写整个文件，但当时所有编程产品仅做单行补全或只读聊天，产品悬余巨大。Claude Code的本质就是“去掉所有脚手架，给模型最简单的harness和完整终端权限”，从而“解缚（Unhobble）”了模型。他断言，当前现代模型仍有巨大的产品悬余未被初创公司捕获。

核心要点

>> 产品悬余定义：在任一模型代际，模型已能完成但尚未被任何产品充分利用的能力集合，源于产品设计未能跟上的能力滞后；

>> 掣肘与解缚：产品若以刚性流程限制模型（如强制特定步骤、仅提供有限工具）即构成掣肘；解缚则是移除这些限制，让模型自由表达能力；

>> Claude Code的诞生案例：Sonnet 3.5能一次编写整个文件甚至整个文件集的代码，但当时IDE产品仅做单行补全和多行补全，巨大产品悬余催生了Claude Code——提供完整终端访问权限的最简harness；

>> 当前的巨大机会：Boris认为现代模型存在海量产品悬余，虽然已有创业者在思考这些问题，但仍有巨大的商业机会待挖掘。

经验技巧

>> 识别产品中的“掣肘点”：检查产品是否强制模型遵循特定步骤、限制工具访问、或预设了过窄的输出格式，这些可能正是掣肘；

>> 定期做“能力边界测试”：给模型完全开放的环境和工具，观察其自主行为中哪些超出了当前产品允许范围；

>> 将“最小可行harness”作为探索起点：不要一开始就构建复杂脚手架，先给模型最基础的访问权限和工具集，再观察其自然表现。

7、让模型处理更难的任务

Boris指出了AI产品使用中的常见错误：用户往往给出过度具体、步骤化的指令（“先做1，再做2，再做3，再做4”），这在旧模型时代是必需的，但对现代模型而言适得其反。正确做法是提高抽象层级：描述任务目标、设定安全围栏、明确退出条件，然后“让模型自己去煮”（let the model cook）。他提供了两个震撼案例：① Bun团队用Claude将整个代码库从Zig重写为Rust，动态工作流运行11天后成功上线；② 将Claude Desktop的Electron应用重写为Swift，已持续运行两周以上。这些任务此前即使最优秀的工程师团队也需要一年以上。

核心要点

>> 常见错误：过度指定：给模型列出一步步操作指令是旧范式，现代模型反而因此受限；

>> 正确方法：高层级任务描述：描述目标、安全围栏和退出条件，然后放手让模型自主推进；

>> Bun重写案例：Bun团队让Claude将整个JavaScript运行时从Zig重写为Rust，利用动态工作流运行11天，一次性完成超过10万行代码的跨语言迁移，现已投入生产；

>> 任务难度的重新定义：此前认为不可能的任务（如跨语言重写整个运行时）现在已可让模型独立完成，并且仅需11天（人类工程师需要一年以上）。

经验技巧

>> 给任务时“拔高一个难度等级”：当前模型的能力总超出你的预期，应故意分配比直觉判断更困难的任务；

>> 以“退出条件”替代“操作步骤”：告诉模型任务完成的验收标准，而非一步步怎么做；

>> 允许长时间自主运行：不要因任务运行数天而焦虑，对现代模型而言这是正常行为。

8、提示工程的范式转移

本章重新定义了“提示工程”的未来方向。Boris认为，从“提示词工程师”到“上下文工程师”的职位名称变迁只是表象，真正的核心技能已从“如何写提示词”转变为 “如何设计任务的验证机制” 。当给模型分配一个极难的任务时，最关键的并非初始指令有多精巧，而是模型能否在任务推进过程中自行验证每一步的输出是否正确——这决定了模型能否长时间独立运行而不偏离目标。

核心要点

>> 技能重心迁移：现代AI产品构建的核心技能不再是提示词撰写，而是“如何为模型设计自主验证能力”；

>> 验证是最被低估的环节：绝大多数开发者未做好的正是验证设计，没有验证机制模型就无法长时间可靠运行；

>> Prompt Engineer角色的演变：从一年前的热门岗位“提示词工程师”到“上下文工程师”，这些称谓将随模型能力提升而快速迭代，但“验证设计”是底层不变的核心问题。

经验技巧

>> 在任务初始即植入验证指令：除了描述任务目标，还应明确要求模型“在每一步自行验证中间结果的正确性”；

>> 为模型提供可自动化执行的测试套件：如单元测试、像素级截图对比、静态分析工具等，让模型有客观的“对错”判断依据；

>> 设置“卡住即上报”机制：当模型发现验证失败或不确定时，应主动暂停并向人类请求澄清，而非盲目继续。

9、两周任务实录——验证即生命线

Boris以自己正在进行的实验为例，生动展示了上述原则的实际应用。他让Claude将Electron桌面应用重写为Swift原生应用，整个提示词极为简洁：“在Mac虚拟机中运行Electron应用并截图，与Swift版本逐像素对比，不完成不停止。”该任务已持续运行两周多，期间Claude还自主创建了Slack频道进行“直播”——每隔几分钟自动发布进度截图。Boris借此强调，模型达成这种超长时程任务不需要复杂脚手架，只需：① 合适的任务描述；② 自动化的验证闭环。

核心要点

>> 实验提示词的精简性：完整提示仅为——在Mac虚拟机中运行Electron应用并截图，逐像素与Swift版本对比，不完成不停止，仅此而已；

>> 超长运行时长：该任务已持续运行超过14～15天，并且仍在进行中；

>> 模型的自主行为扩展：Claude在任务过程中自主创建了内部Slack频道，每隔几分钟自动发布进度截图，“决定做直播”；

>> 无需复杂脚手架：/goal和/loop等高级功能有帮助，但本质上一段清晰的任务描述加验证机制已足够驱动模型持续工作数周。

经验技巧

>> 将“视觉/客观验证”嵌入任务：对于UI类任务，像素级对比是高效的自动验证手段；类似逻辑可推广至其他领域（如日志对比、测试覆盖率变化）；

>> 允许模型自主“告知”进度：模型自主创建Slack频道的行为提示产品设计者：可内置进度汇报机制，让长期运行任务对用户透明；

>> 验证即“拴绳”：验证机制不是为了限制模型，而是让模型在自主探索时有锚点，确保长时程运行不偏离主目标。

10、运行数千个AI智能体

本章是技术密度最高的部分。Boris介绍了Claude Code中大规模Agent编排的三个核心机制：动态工作流（Dynamic Workflows）——将单一复杂任务分解为可并行/顺序执行的子任务，由Claude自主协调成百上千个Agent（本质是一种Agent代数，可序列运行亦可并行运行）；Loops（本地循环）——类似本地cron定时任务；Routines（云端例程）——云端定时任务，可关闭笔记本电脑后持续运行。他分享了一个震撼的内部实践：Anthropic已让Claude“自我维护”——每天运行20～30个自动化例程（如删除死代码、清理已全量发布的实验代码、补充测试覆盖、删除无用测试、以及“抽象警察”——跨代码库查找并统一近似重复的抽象），相当于数十到数百名工程师的维护工作量，人类工程师由此解放出来专注新产品开发和用户沟通。

核心要点

>> 动态工作流（Dynamic Workflows）：基于Bun沙箱启动虚拟机，Claude可自主启动并编排大量Agent，将其分解为多阶段任务（如第一阶段fan-out执行，第二阶段验证/总结，第三阶段再次fan-out），本质上是一种Agent的代数系统（序列运行/并行运行）；

>> Loops和Routines：Loops为本地定时任务，Routines为云端定时任务（可关电脑运行），适用于周期性独立任务（共享内存但不共享上下文）；

>> 自我维护的实践：Claude已通过Routines实现代码库自我维护，包括每日删除死代码、清理已全量发布的实验代码、补充测试覆盖、删除无用测试、执行“抽象警察”检查（查找并统一跨代码库的近似重复抽象）；

>> 规模量化：每天运行20～30个例程，涉及数百至数千个Agent的执行，替代了传统需数十至数百名工程师的维护工作量；

>> 完全自主发现：Claude自行“想出了”如何寻找死代码（结合静态和动态分析）、如何识别近似重复的抽象等方案，未被显式提示。

经验技巧

>> 大规模任务应分层编排：不要只启动一个Agent做全部事情，通过动态工作流让Claude自主规划并行/串行阶段；

>> 将重复性维护任务交给Routines：代码清理、测试维护、抽象统一等高频低判断成本任务非常适合转为云端定时Agent；

>> 信任Agent的自主方案设计：给模型高层级目标（如“清理死代码”），它会自行决定使用静态分析、动态分析或二者结合，无需预先规定方法；

>> 让AI维护AI的代码：将Agent应用于自身代码库的维护，形成“AI的自举式迭代”闭环。

11、编程（几乎）被解决了

面对主持人“编程是否已被解决”的问题，Boris给出了审慎而乐观的回应。他区分了“他所从事的编程类型”（已基本解决）和“所有类型的编程”（尚未完全解决）。当前模型仍在深度系统代码库、分布式系统以及精细UI验证（像素级偏差）等领域存在困难，但Opus 5在视觉和计算机使用上已有巨大飞跃。现场互动显示已有相当比例的开发者由AI生成超过50%乃至100%的代码。Boris认为编程正在“逐步被解决”更多类型，但真正的“解缚”心态是：忘记旧模型的能力边界、忘记课堂上学的计算机科学理论、用经验主义对待每一代新模型。

核心要点

>> “已解决”的限定条件：Claude能处理的编程类型（Boris日常所涉范围）已基本解决，但深度系统代码库、分布式系统、精密UI像素级校验仍是挑战；

>> Opus 5的视觉提升：Opus 5在视觉和计算机使用方面已实现巨大飞跃，但距离完美仍有差距；

>> 现场实证：访谈现场举手互动显示，已有相当比例的开发者由AI生成超过50%甚至100%的代码；

>> 编程“逐步被解决”的趋势：随着模型进化，被解决的编程类型将持续扩大。

经验技巧

>> 不因过去的失败而否定当前模型：即使某项任务三个月前失败过，新模型可能已能胜任，应持续重新测试；

>> 将“遗忘旧经验”作为核心能力：对旧模型和旧能力的经验可能成为使用新模型的障碍，保持开放的“再试一次”心态至关重要。

12、每个CS学生今天仍需学习的技能

在最后一个章节，Boris为当下的编程学习者提供了务实建议。他本人并非通过理论课程学习编程，而是为解决实际问题而自学（从TI-83计算器的BASIC编程开始，最初目的是在数学考试中“取得更好成绩”）。他认为，计算机科学理论固然引人入胜，但真正的价值在于如何应用——做产品、培养设计感、商业感、数据科学能力、用户沟通能力。当这些技能与计算机科学/工程相结合，才产生真正的商业价值。他最后将方法论总结为：先做自己想要的东西，再升级去做别人想要的东西。

核心要点

>> 编程学习应从实际问题出发：Boris本人的编程启蒙源于TI-83计算器的BASIC编程，目的是在数学考试中实际使用（“帮助自己”），随后演进到汇编以解决更难的微积分问题；

>> 纯CS理论不足以应对未来：计算机科学理论知识极具智力魅力，但必须与实践应用结合才能真正产生价值；

>> 关键组合技能：商业感、设计感、数据科学、用户沟通能力与工程能力的融合，是CS学生脱颖而出的关键；

>> “先为己用，再为人用”：从解决自己遇到的实际问题起步，再逐步升级为创造他人需要的产品和服务。

经验技巧

>> 以“解决问题”为导向学习编程：不要为学而学，将编程能力服务于一个具体且实际的目标；

>> 积累非工程类复合技能：产品设计、用户研究、商业分析等“软技能”在AI时代反而成为差异化的硬壁垒；

>> 保持对“实用性”的执念：技术本身不是目的，而是解决现实问题的手段，这一心态决定了一个人能否持续迭代和进步。