对话 Claude Code 创造者 Boris Cherny
摘要
本期 The Light Cone 播客邀请到 Claude Code 的创造者 Boris Cherny 进行深度对话。Boris 曾在 Meta 负责全公司代码质量，后加入 Anthropic，从零开始打造了 Claude Code。他分享了 Claude Code 诞生于一个纯粹的意外——最初只是他为了学习 Anthropic API 而搭建的一个终端聊天应用，当他给模型加上 Bash 工具后，模型自己写出了 AppleScript 来查询他 Mac 上的音乐播放器，那是他第一次感受到"AGI 时刻"。Boris 揭示了多个核心洞见：不要为今天的模型构建产品，要为六个月后的模型构建；终端只是起点，没想到它成了终点；Claude Code 的全部代码每隔几个月就被重写一次，没有任何部分存在超过六个月；他个人的 CLAUDE.md 仅有两行——自动合并和发布到 stamps 频道。对话还涉及计划模式 (Plan Mode) 的有限寿命、"苦涩教训" (The Bitter Lesson) 对产品决策的影响、Claude Teams 的非相关上下文窗口 (Uncorrelated Context Windows) 架构、以及 Anthropic 工程师自 Claude Code 推出以来生产力增长 150% 的惊人数据。Boris 预测编码将被普遍解决，"软件工程师"的职位将消失，取而代之的是"构建者" (Builder)。
正文
从意外到必然：Claude Code 的诞生
Boris 回忆，Claude Code 的诞生纯属偶然。Anthropic 很久以来一直押注编码，认为通向安全 AGI (Safe AGI) 的路径就是通过编码——教模型编码，然后教它使用工具，再教它使用计算机。Boris 加入的第一个团队是"Anthropic Labs 团队"，产出了三个产品：Claude Code、MCP 和桌面应用。
没有人要求 Boris 构建 CLI。团队只是模糊地知道应该构建某种编码产品，但没有人有足够高的信心。Boris 的起点极为朴素：他只想学习 Anthropic 的 API，于是搭建了一个终端聊天应用。然后工具使用 (Tool Use) 功能发布，他把文档中的 Bash 工具示例从 Python 移植到 TypeScript，试着让模型读文件——成功了。接着他问模型"我在听什么音乐？"模型自己写了一段 AppleScript 去查询 Mac 的音乐播放器。这是 Sonnet 3.5 时代的成果，Boris 称之为他第一次真正的"AGI 时刻"——"模型就是想使用工具，这就是它想要的全部。"
终端：从最廉价起点到意外终点
Boris 选择终端的原因极其简单：不需要构建 UI，只有他一个人在用。当 Cursor 和 Windsurf 在 IDE 领域高歌猛进时，没有人给他压力去构建插件或 IDE。
终端开始内部传播的方式也出乎意料。Boris 在搭建原型两天后就交给团队内部试用（吃自己的狗粮 / Dogfooding），第二天发现对面的工程师 Robert 已经在用它写代码了。"这东西还没准备好，只是个原型！"但它在那个形态下已经够用了。
2024 年 11-12 月的发布评审会上，Dario Amodei 看着内部使用数据的曲线近乎垂直上升，问道："你是不是在强制工程师使用？为什么你要推行这个？"Boris 回答："没有，我们只是发了个通知，他们就口口相传了。"
早期使用场景与演进
2024 年初，模型还不太擅长编码。Boris 本人主要用它自动化 Git 操作——到今天他可能已经忘了大部分 Git 命令。其他人用它做各种非编码任务：自动化工作流、查询数据等。
一个关键的转折点是 Claude Code 发现内存泄漏的故事。Boris 自己拿了堆转储 (Heap Dump)，在 DevTools 里看 Profile，翻代码——然后队友 Chris 直接让 Claude Code 跑堆转储分析。Claude Code 为自己写了一个小工具来分析堆转储，比 Boris 更快地找到了泄漏。这让他不得不反复提醒自己：我的大脑还停留在六个月前的认知水平。
给创始人的核心建议
不要为今天的模型构建：Boris 反复强调，要为六个月后的模型构建产品。找到模型今天不擅长但将会擅长的边界。否则你为当前模型找到了产品市场契合 (PMF)，但会被为下一版模型构建的竞争对手超越。
苦涩教训 (The Bitter Lesson)：在 Claude Code 团队的办公区墙上，挂着 Rich Sutton 的《苦涩教训》——更通用的模型终将击败更特定的模型。这转化为产品决策就是：你可以花工程时间构建脚手架 (Scaffolding) 来扩展 10-20% 的能力，或者等几个月让新模型直接做到。Claude Code 的全部代码每隔几周就重写一次，每隔几周就淘汰旧工具、添加新工具，没有任何部分存在超过六个月。
潜在需求 (Latent Demand)：Boris 称这是产品领域最重要的概念。人们只会做他们已经在做的事情。你不能让人做新事情，但可以让他们正在做的事情变容易。Plan Mode 就是一个典型例子——用户已经在用 Claude Chat 规划但不想写代码，Plan Mode 只是让这个已有行为更容易。
计划模式的有限寿命
Plan Mode 的诞生同样源于观察用户行为。Boris 在某个周日晚上 10 点浏览 GitHub Issues 和内部 Slack 反馈频道，发现用户反复表达"帮我规划但先别写代码"的需求。他花了 30 分钟写了 Plan Mode，当晚上线，周一早上发布。
但 Boris 认为 Plan Mode 有有限寿命。现在他 80% 的会话以 Plan Mode 开启——在多个终端标签页同时规划，计划完善后执行。使用 Opus 4.5 之后，一旦计划好，代理就能准确执行，几乎不再需要监督。从"计划前后都需要监督"到"只需计划前监督"，下一步可能就是完全不需要监督——Claude 自己就能判断何时该进入 Plan Mode。
Claude Teams 与非相关上下文窗口
Claude Teams 的核心理念是非相关上下文窗口 (Uncorrelated Context Windows)：多个代理拥有各自新鲜的上下文窗口，互不被彼此或自己之前的上下文污染。向一个问题投入更多上下文，本质上是一种测试时计算 (Test Time Compute) 的扩展。如果在之上加上正确的拓扑结构 (Topology)——代理以正确的方式通信和排列——就能构建更大的东西。
Teams 的第一个成功案例是插件 (Plugins) 功能：整个功能由一群代理在一个周末构建完成，几乎没有人类干预。一位工程师给了 Claude 一个规格说明和 Asana 看板，Claude 自动拆分为工单、派生代理、代理领取任务——"Mama Claude"给出指令，子代理们各自动手。
生产力数据：150% 的增长
Boris 分享了一组惊人的内部数据：Anthropic 团队去年规模翻倍，但每位工程师的生产力增长了约 70%（以最简单的 PR 数量衡量，同时交叉验证了提交数和提交存活时间等指标）。自 Claude Code 推出以来，Anthropic 每位工程师的生产力增长了 150%。
作为对比，Boris 在 Meta 负责代码质量时，全公司数百人花一年时间才能实现 2% 的生产力提升。150% 的增长在传统意义上完全闻所未闻。
Steve Yegge 的文章称 Anthropic 工程师的生产力是 Google 巅峰期工程师的 1000 倍。Boris 没有否认这个量级——内部数据显示，所有技术员工每天都在用 Claude Code，甚至一半的销售团队也在用（虽然他们正转向更易用的 Co-work）。
TypeScript 的类比与终端设计哲学
Boris 早年写过一本关于 TypeScript 的书。他发现 Claude Code 在终端中的定位与 TypeScript 有着深刻的平行。TypeScript 做出了很多"奇怪"的语言决策——字面量类型 (Literal Type)、条件类型 (Conditional Type)——这些连 Haskell 都没有的特性，纯粹来自对 JavaScript 程序员实际编码方式的观察，而非学术理论。TypeScript 没有要求开发者改变编码习惯，而是围绕他们的习惯构建了类型系统。
Claude Code 同样如此——它不是某种学术化的、原则性的产品，而是为用户（首先是 Boris 自己，然后是团队，然后是 Anthropic 员工，最后是外部用户）构建的实用工具。15 年后，Haskell 的代码库寥寥无几，而 TypeScript 遍地开花——因为实用性胜过学术优雅。
终端设计本身也是一项独特的挑战。80×100 字符、256 色、单一字号、没有鼠标交互……Boris 团队不得不从零开始发明终端 UX 原则。仅旋转加载动画 (Spinner) 就迭代了 50-100 次，80% 没有发布。Claude Code 的终端实际上使用 React Terminal 构建，是"最美丽的终端应用之一"。
为模型而构建
Boris 给 DevTool 创始人的建议是：思考模型想要做什么，然后让那件事变容易。模型想使用工具、与世界交互。错误的做法是把它关在盒子里，规定"这是 API，这是你与我交互的方式"。正确的做法是观察它想用什么工具、想做什么，然后像服务用户一样为其赋能。
关于 Claude Code 的未来形态，Boris 承认一年前他认为终端只有三个月寿命，但事实证明他错了。Claude Code 现在已经扩展到 Web、桌面应用、iOS/Android 的 Code 标签页、Slack、GitHub、VS Code 扩展和 JetBrains 扩展——但他们始终在实验不同的形态。
加入 Anthropic 的原因
Boris 当时住在日本乡村，每天早上打开 Hacker News，看到的都是 AI 新闻。他开始使用早期产品，第一次使用时"简直令人屏息"（这是 Claude 2 时代的产物）。他开始与 Anthropic Labs 的朋友交流，认识了联合创始人 Ben Mann，随即被团队吸引。
两个原因让他选择 Anthropic：一是它作为研究实验室运作，产品极小，核心是构建安全模型——与模型紧密合作、贴近研发的理念深得他心；二是使命感——Boris 是重度科幻读者，"我知道这件事可能变得非常糟糕"，而 Anthropic 走廊和午餐室里人们谈论的是 AI 安全，这是所有人最关心的事。
2026 年展望
Dario 预测 Anthropic 90% 的代码将由 Claude 编写——这已成为现实。Boris 本人自 Opus 4.5 以来 100% 的代码由 Claude Code 编写，他已经卸载了 IDE，不再手动编辑任何代码行，每天合并约 20 个 PR。Anthropic 整体的比例为 70-90%，许多团队是 100%。
继续追踪指数曲线，Boris 预测编码将被普遍解决——不仅对他，对所有人、所有领域。我们将看到"软件工程师"这一头衔消失，取而代之的可能是"构建者" (Builder) 或"产品经理" (Product Manager)，但实际工作不再仅仅是编码——工程师也将写规格、与用户交谈。在 Claude Code 团队中，PM 编码、设计师编码、工程经理编码、甚至财务人员也编码——每个人都编码。这将扩展到整个行业。
上限则更为可怕：如果达到 ASL4（Anthropic 安全等级 4），意味着模型递归自我改进 (Recursively Self-Improving)，或者出现灾难性滥用——如设计生物病毒、零日漏洞等。Anthropic 正在全力防止这种情况发生。
Co-work 的诞生
Co-work 同样源于潜在需求。Boris 在 Twitter 上看到有人用 Claude Code监控番茄植物、从损坏的硬盘中恢复婚礼照片、做金融分析。内部看，每个设计师、整个财务团队、整个数据科学团队都在用——不是为了编码，而是因为 Claude Code 太有用了。非技术用户不惜跨越重重障碍安装终端程序来使用它。
因此他们知道需要为非技术用户构建产品。Felix（Electron 早期贡献者）和团队在约 10 天内用 Claude Code 100% 编写了 Co-work——它本质上就是 Claude Code 的一个 GUI 包装器，同一个代理在底层运行。不同之处在于：代码运行在虚拟机 (VM) 中，有删除保护、更频繁的权限提示和其他安全护栏。