Claude Code 创造者直言：软件工程师这个头衔，可能要消失了

最近看了一期 Y Combinator 的播客节目 Lightcone，嘉宾是 Boris Cherny，Claude Code 的创造者。这期节目信息量非常大，Boris 从 Claude Code 的诞生讲起，一路聊到 AI 编程的未来、产品哲学、团队协作，甚至聊到了软件工程师这个职业本身会发生什么变化。

我把里面最有价值的观点都提炼出来，尽量用大白话讲清楚。

一切都是意外开始的

Claude Code 的诞生过程，说出来可能很多人不信，完全是一个意外。

Boris 当时刚加入 Anthropic，被分到一个叫 Anthropic Labs 的团队。团队大致知道要做一个跟编程相关的产品，但具体做什么，谁也没想清楚。Boris 的第一步特别朴素：他想先搞懂 Anthropic 的 API 怎么用，因为他之前根本没用过。于是他随手写了一个终端里的小聊天工具，就是为了方便自己调 API。

后来 Anthropic 推出了工具调用功能，Boris 想试试这个新东西到底能干嘛。他让模型读了一个文件，能读。然后他随口问了一句：我现在在听什么歌？模型居然自己写了一段 AppleScript，去他的 Mac 上查了音乐播放器，然后告诉他答案。

Boris 说，那是他第一次真正感受到 AGI 的影子。他意识到，这个模型就是想用工具，它想跟真实世界互动，这就是它最想做的事情。

这个故事其实挺有意思的。很多改变世界的产品，起点都不是什么宏大的规划，就是一个人在解决自己手头的小问题，然后发现这个东西好像比想象中有用得多。

为什么是终端？因为最便宜

很多人可能会觉得，Claude Code 选择终端作为界面，背后一定有什么深思熟虑的设计哲学。Boris 的回答非常坦诚：因为不用做 UI，这是最快能跑起来的方式。

当时 Cursor、Windsurf 这些 IDE 产品已经在起飞了，但 Boris 团队并没有感受到要做 IDE 的压力，因为他们连自己要做什么都还没想清楚。终端只是一个起点，Boris 原本以为很快就会换到别的形态上去。

结果一年过去了，终端还在。Boris 自己都觉得不可思议。

他说，如果一年前你问我终端还能活多久，我会说三个月。但事实证明他一直在低估终端的生命力。Claude Code 后来扩展到了网页版、桌面应用、iOS 和 Android 的代码标签页、Slack、GitHub，甚至还有 VS Code 和 JetBrains 的插件。他们一直在尝试不同的形态，但终端始终没被淘汰。

这件事有一个很值得琢磨的道理：有时候最简单、最粗糙的方案，反而有一种意想不到的生命力。你以为它只是个过渡，结果它就是答案本身。

两天之后，同事就开始用了

Boris 做出第一个原型之后，大概两天就开始给团队用了。第二天他到办公室，发现对面的工程师 Robert 已经在用 Claude Code 写代码了。Boris 当时还挺惊讶的，心想这东西还只是个原型啊，你怎么就用上了。

后来在内部发布评审的时候，Anthropic 的 CEO Dario 看到内部使用量的增长曲线几乎是垂直的，问 Boris：你是不是强制工程师用的？Boris 说没有，他就是发了个帖子，然后大家自己传开了。

这个细节其实很能说明问题。一个真正好用的产品，你不需要推它，用户自己会拉着别人来用。Boris 后来反复提到一个概念叫「潜在需求」，就是说人们本来就在做某件事，你只是让这件事变得更容易了。你不需要教育用户，不需要改变他们的习惯，你只需要顺着他们已有的行为去优化。

潜在需求：Boris 眼中最重要的产品理念

Boris 在整个访谈里反复强调一个词：latent demand，潜在需求。他说这是他做产品这么多年来，学到的最重要的一个概念。

什么意思呢？就是人们只会做他们已经在做的事情。你没办法让人去做一件全新的事。如果人们正在尝试做某件事，你让它变得更简单，这就是好产品。但如果你试图让人们去做一件他们从来没做过的事，那基本上不会成功。

他举了 plan mode 的例子。plan mode 就是让 Claude 先想清楚要怎么做，列个计划，但先不写代码。这个功能是怎么来的呢？Boris 某个周日晚上十点，在翻 GitHub 的 issue 和内部 Slack 的反馈频道，发现很多用户已经在手动做这件事了。他们会对 Claude 说：帮我想想这个问题怎么解决，但先别写代码。有人是在讨论思路，有人是让 Claude 写详细的技术方案，但共同点都是「先想后做」。

Boris 花了三十分钟写完了 plan mode，当晚就发布了，第二天早上用户就用上了。

这个故事特别有启发性。很多时候我们做产品、做内容，总想着去创造需求，去教育市场。但真正聪明的做法是去观察人们已经在做什么，然后把那个过程变得更顺畅。需求从来都不是被创造出来的，它一直在那里，只是等着被发现。

CLAUDE.md 应该越短越好

访谈里有一段关于 CLAUDE.md 的讨论很有意思。CLAUDE.md 是一个配置文件，用户可以在里面写一些指令，告诉 Claude Code 在工作时应该遵循什么规则。

很多人可能会觉得，Boris 作为 Claude Code 的创造者，他的 CLAUDE.md 一定写得特别长、特别精细。但实际上他的个人 CLAUDE.md 只有两行。第一行是：每次提交 PR 的时候自动开启 automerge。第二行是：每次提交 PR 的时候在团队的内部频道发个消息，好让别人帮忙审核。

就这两行。其他所有的指令都写在团队共享的 CLAUDE.md 里，整个团队每周都会更新好几次。

Boris 的建议是，如果你的 CLAUDE.md 变得很长，最好的办法是删掉它，从零开始。因为模型的能力在不断变化，每出一个新模型，你需要写的指令就会更少。CLAUDE.md 本质上就是一个快捷方式，如果你发现自己总在重复同一句话，就把它加进去。否则，直接在对话里说就行了。

这个思路其实可以推广到很多场景。我们总喜欢把东西搞得很复杂，写很长的规范、很详细的流程。但有时候，保持简单、保持灵活，反而效果更好。尤其是在变化很快的领域，今天精心设计的东西，明天可能就不需要了。

不要为今天的模型做产品，要为六个月后的模型做

这是 Boris 给所有在 AI 领域创业的人最核心的一条建议。

他说，在 Anthropic 内部，他们的思路一直是：不为今天的模型做产品，而是为六个月后的模型做产品。你要去感受模型能力的边界在哪里，找到那些模型今天还做不好、但很快就能做好的事情，然后围绕那个方向去建设。

Claude Code 本身就是这个思路的产物。Boris 在 2024 年 9 月开始做的时候，模型写代码的能力其实很差。到 2025 年 2 月，模型大概也只能写他 10% 的代码，剩下的还是得自己手写。但他赌的是模型会变好，结果这个赌注赢了。

他还提到一个反面教训：如果你只为当前的模型做产品，你可能很快就找到了产品市场契合度，但下一个模型出来的时候，别人直接跳过了你的阶段，你就被超越了。

这个道理放到个人身上也一样。我们学一个技能、选一个方向的时候，如果只看当下什么热门，很容易被快速变化的技术甩在后面。更聪明的做法是想一想，半年后、一年后，什么东西会变得重要？然后提前往那个方向走。

永远不要跟模型对赌

Boris 提到，在 Claude Code 团队的办公区域，墙上挂着一篇文章的打印版，叫 The Bitter Lesson，作者是强化学习之父 Rich Sutton。这篇文章的核心观点是：更通用的方法最终总会打败更专门的方法。

Boris 把这个原则应用到了产品开发中。他说，他们在做 Claude Code 的时候，经常面临一个选择：是花工程资源去搭建一些辅助代码，让模型在某个方面表现好 10% 到 20%？还是干脆等几个月，让下一代模型自己解决这个问题？

他们把那些围绕模型搭建的辅助代码叫做「脚手架」。脚手架的特点是，你花了很多精力搭起来，但下一个模型一出来，这些增益就被抹平了，你又得重新搭。

所以 Claude Code 的代码库一直在被反复重写。Boris 说，Claude Code 里没有任何一行代码是六个月前写的。他们每隔几周就会下掉一些工具，再加上一些新的。整个代码库大概 80% 的内容都不超过两个月。

这种「代码保质期只有几个月」的现实，对很多做技术的人来说可能有点冲击。我们习惯了把代码当成资产，觉得写得越多积累越深。但在 AI 时代，代码更像是消耗品，重要的是你能不能快速迭代、快速重写，而不是你写了多少。

初学者心态比经验更重要

Boris 讲了一个让他印象很深的故事。有一次团队遇到了一个内存泄漏的 bug，Boris 用传统方法去排查，打开 DevTools，看堆内存快照，一行一行地分析代码。与此同时，团队里另一个工程师 Chris 直接问 Claude Code：我觉得这里有内存泄漏，你帮我查一下。Claude Code 自己做了堆内存转储，还给自己写了一个分析工具，然后比 Boris 更快地找到了泄漏点。

Boris 说，这种事情他需要不断重新学习，因为他的大脑总是停留在六个月前的认知里。模型的能力每隔几个月就会跳一个台阶，如果你还用老经验去判断它能做什么、不能做什么，你就会错过很多。

他观察到一个有趣的现象：刚入行的新人，或者刚毕业的学生，有时候反而比资深工程师更会用 AI 工具。因为他们没有包袱，没有「这个事情应该怎么做」的固有印象，他们就是直接让 AI 去试。

Boris 在招人的时候，会问一个问题：能不能举一个你犯错的例子？他想看的是这个人能不能承认自己的错误，能不能从错误中学到东西。他说自己大概有一半的想法是错的，做产品就是不断试错、不断跟用户聊、不断学习的过程。

这一点对任何人都适用。在一个变化极快的时代，经验当然有价值，但如果经验变成了思维定式，它反而会成为障碍。保持好奇心，保持「也许我是错的」这种心态，可能比任何具体技能都重要。

极端专才和极端通才，都能活得很好

Boris 观察到，在他的团队里，最有效率的人分成了非常鲜明的两类。

一类是极端专才。比如他提到的 Jared，专门负责性能优化和内存泄漏，对 JavaScript 运行时系统的理解深到没人能比。还有 Bun 团队的人，对开发工具的底层原理了如指掌。

另一类是极端通才。这些人横跨产品、设计、用户研究、商业等多个领域，什么都能干一点，而且能把不同领域的知识串起来。

Boris 说他特别喜欢那种「做奇怪事情」的人。以前这种人可能会被质疑：你到底能不能做出有用的东西？但现在，这种跳出常规思维的能力变得特别珍贵。

他举了一个例子。团队里有个工程师叫 Daisy，她加入后不久就给 Claude Code 提了一个 PR。但她没有直接去实现那个新功能，而是先写了一个工具，让 Claude Code 可以自己测试任意工具是否正常工作。然后她让 Claude 自己去写那个新功能。这种「让 AI 给自己造工具」的思路，当时很少有人想到。

中间地带反而变得尴尬了。如果你既不够深，也不够广，在 AI 时代就容易被替代。要么往深处钻，成为某个领域无可替代的专家；要么往广处走，成为能把各种资源和能力串联起来的人。

子代理：让 AI 管理 AI

访谈里有一个技术概念特别值得关注，叫子代理。简单来说，就是一个 Claude Code 可以启动多个小的 Claude Code，让它们并行去做不同的事情。

Boris 透露了一个数据：现在大多数 Claude Code 的代理，其实都是由另一个 Claude Code 启动的。他们内部管那个主代理叫「妈妈 Claude」。

他举了一个真实案例。Claude Code 的插件功能，是一个工程师在一个周末用代理集群搭出来的。这个工程师给 Claude 写了一份技术方案，然后让 Claude 在 Asana 上创建了一堆任务，接着 Claude 自己启动了一批子代理，每个子代理领一个任务，它们之间互相协调，最后把整个功能做完了。中间几乎没有人工干预。

Boris 自己的工作方式也很有意思。他 80% 的工作会话都是从 plan mode 开始的。他会在一个终端标签页里让 Claude 做计划，然后切到下一个标签页再开一个计划，标签页用完了就打开桌面应用继续开。等所有计划都确认好了，就让它们各自去执行。

他说，以前你需要在计划阶段和执行阶段都盯着，现在只需要在计划阶段盯着就行了。一旦计划定好了，模型基本上能自己完成，几乎不会跑偏。

这意味着一个人能同时推进的事情数量，正在被急剧放大。以前一个工程师一天能做一两个任务，现在 Boris 一天能提交 20 个 PR。这种效率的跃升，已经不是「提高了百分之多少」的问题了，是整个工作方式都变了。

Plan Mode 可能很快就不需要了

访谈中有一个让所有人都吃惊的预测。主持人问 Boris：你觉得六个月后还需要手动进入 plan mode 吗？Boris 的回答是：也许一个月就不需要了。

他解释说，Claude Code 现在已经可以自己判断什么时候该进入 plan mode 了。他们正在优化这个体验，让模型能在人类想要进入计划模式的同一个时间点，自己切换过去。

而且 plan mode 本身其实没什么秘密。它做的事情就是在提示词里加了一句话：请不要写代码。就这么简单。

Boris 描述了一个趋势：六个月前，你在计划阶段和执行阶段都需要盯着。现在，你只需要在计划阶段盯着。再过一段时间，可能连计划阶段都不用盯了，你只需要给一个大方向，模型自己就能搞定。

这个趋势如果继续下去，意味着人类在编程过程中的角色会越来越往上层走。你不再需要关心具体的代码怎么写，甚至不需要关心计划怎么拆分，你只需要想清楚「我到底要做什么」就够了。

在终端里追求美感

一个很容易被忽略的细节是，Claude Code 的终端界面其实非常漂亮。Boris 提到，它是用 React 写的终端应用，这在终端工具里很少见。

Boris 说，产品光有用还不够，用户还得喜欢用它。如果一个产品有用但你不会爱上它，那还不够好。

但在终端里做设计是真的难。你只有大概 80 乘 100 个字符的空间，256 种颜色，一种字号，没有鼠标交互。他们尝试过在终端里加入鼠标点击功能，原型做了好几版，但体验都很差，最后放弃了。

光是终端里那个加载动画的小转圈，就迭代了大概 50 到 100 个版本，其中 80% 都没有发布。试一个，感觉不对，换下一个。试一个，还是不对，再换。

Boris 说，这恰恰是 Claude Code 的优势所在。你可以用它快速做 20 个原型，看哪个感觉最好，整个过程可能就花几个小时。以前用 Origami 或者 Framer 做原型，可能做三个就要两周。

这种对细节的执着，其实是很多成功产品的共同特点。用户可能说不出来哪里好，但他们能感受到。那种「用起来就是舒服」的感觉，往往来自于无数个你看不见的小决定。

TypeScript 的历史，和 Claude Code 惊人地相似

Boris 在加入 Anthropic 之前，写过一本关于 TypeScript 的书。主持人发现，TypeScript 的发展历程和 Claude Code 有很多相似之处。

TypeScript 刚出来的时候，很多人觉得它很奇怪。给 JavaScript 加类型？这语言本来就不是干这个的。但 TypeScript 团队做了一个非常聪明的决定：他们没有试图改变 JavaScript 程序员写代码的方式，而是围绕程序员已有的习惯去设计类型系统。

JavaScript 程序员喜欢用反射、用动态修改，这些在传统的强类型语言看来都是「不安全」的操作。但 TypeScript 没有说「你不能这样写」，它说「你继续这样写，我来想办法给你加上类型保护」。为此他们发明了很多学术界都没想到的类型系统特性，比如字面量类型、条件类型。

结果呢？十五年过去了，Haskell 这种更学术、更严谨的语言，代码库数量远远比不上 TypeScript。因为 TypeScript 解决了一个真实的问题，而且是用一种不强迫人改变的方式解决的。

Claude Code 也是一样的逻辑。它没有要求你学 Vim，没有要求你懂 SSH，没有要求你掌握任何高深的终端技巧。你打开它，它会引导你。Boris 说他自己就是一个很普通的工程师，不用 Vim，用 VS Code，因为简单。他做产品的思路就是：我会用的东西，大多数人也会用。

这里面有一个很朴素但很深刻的产品哲学：不要试图改变用户，去适应他们。

软件工程师这个头衔，可能要消失了

访谈最后，Boris 对未来做了一些预测。

首先是一个已经发生的事实：Anthropic 的 CEO Dario 曾预测 90% 的代码会由 AI 来写，这个预测已经实现了。Boris 自己从 Opus 4.5 开始就卸载了 IDE，100% 的代码都通过 Claude Code 完成，每天提交大约 20 个 PR。整个 Anthropic 内部，不同团队的 AI 写码比例在 70% 到 100% 之间。

然后是一个关于生产力的惊人数据。Steve Yegge 写过一篇文章说，Anthropic 的工程师平均生产力是 Google 巅峰时期工程师的 1000 倍。Boris 给出了更具体的数字：自从 Claude Code 推出以来，Anthropic 每个工程师的生产力提升了 150%。他说，他以前在 Meta 负责代码质量，当时整个团队几百人花一年时间，能把生产力提升 2% 就已经是巨大的成就了。150% 这个数字，放在以前是完全不可想象的。

Boris 预测，编程这件事很快会对所有人来说都变得「基本解决」。软件工程师这个头衔可能会逐渐消失，取而代之的可能是「builder」或者「产品经理」之类的称呼。因为工程师的工作不再只是写代码了，他们还要写方案、跟用户聊天、做产品决策。在 Anthropic 内部，这种趋势已经很明显了：PM 会写代码，设计师会写代码，工程经理会写代码，连财务的人都会写代码。

这个变化对每个人都有影响。如果「会写代码」不再是一个稀缺技能，那什么才是？Boris 的回答其实贯穿了整个访谈：是你能不能想清楚要做什么，能不能理解用户真正需要什么，能不能在快速变化的环境中保持学习和适应。

Co-work 的诞生：又是潜在需求

访谈快结束时聊到了 Co-work，这是 Claude Code 的一个面向非技术用户的版本。

Boris 说，他们在 Twitter 上看到有人用 Claude Code 监控番茄植物的生长，有人用它从损坏的硬盘里恢复婚礼照片，有人用它做财务分析。在 Anthropic 内部，所有设计师都在用它，整个财务团队在用它，整个数据科学团队也在用它。这些人都不是程序员，但他们愿意费劲去装一个终端工具，就为了能用上这个东西。

这就是典型的潜在需求。于是团队做了一个带图形界面的 Claude Code 包装层，放在桌面应用里。底层还是同一个代理，只是加了虚拟机运行环境、删除保护、权限提示这些面向普通用户的安全措施。整个东西 10 天就做完了，而且是 100% 由 Claude Code 自己写的。

Boris 说到这里的时候，又用了一次「潜在需求」这个词。他说这大概是他第五次在这期节目里提到它了。

AI 安全：Boris 加入 Anthropic 的真正原因

访谈里有一段很私人的分享。Boris 说，他加入 Anthropic 之前住在日本乡下，每天早上刷 Hacker News，发现新闻越来越多地被 AI 相关的内容占据。他开始试用一些早期的 AI 产品，第一次用的时候，他说「真的是被震住了」。

但真正让他决定加入 Anthropic 的，有两个原因。

第一个是 Anthropic 本质上是一个研究实验室，产品只是很小的一部分，最重要的事情是构建安全的模型。Boris 做了很多年产品，这种「产品不是最重要的东西」的理念反而让他觉得耳目一新。

第二个是使命感。Boris 是个科幻迷，书架上全是科幻小说。他太清楚 AI 如果失控会怎样。他提到 Anthropic 有一套安全等级体系，ASL3 是当前模型的等级，ASL4 意味着模型可以递归地自我改进。如果到了那个阶段，必须满足一系列严格的安全标准才能发布。

他说，在 Anthropic 的午餐室和走廊里，你听到人们聊的最多的话题就是 AI 安全。这是所有人最关心的事情。

这一点其实值得每个人认真想想。AI 的能力在飞速增长，这固然令人兴奋，但与此同时，确保这种力量被负责任地使用，可能是我们这个时代最重要的课题之一。

写在最后

整个访谈听下来，Boris Cherny 给我最深的印象是两个字：务实。

他不是那种会说漂亮话的人。他承认自己是个普通工程师，承认自己一半的想法是错的，承认 Claude Code 的诞生完全是意外。但正是这种务实，让他能够真正贴近用户，真正感受到需求在哪里，然后用最快的速度把东西做出来。

他反复强调的几个原则，其实都不复杂：观察用户已经在做什么，让那件事变得更容易；不要为今天做产品，要为未来做产品；不要跟模型对赌；保持初学者心态。

这些道理说起来简单，但真正能做到的人很少。也许这就是为什么 Claude Code 能从一个随手写的终端小工具，变成了改变整个编程世界的产品。

视频播客地址：https://youtu.be/PQU9o_5rHC4

最后，介绍一下，我的星球：「AIGC·掘金成长研习社」，主要分享三个板块的内容：