2025 年 2 月，Claude Code 以终端工具的形态悄悄发布。一年后，SemiAnalysis 的报告显示，它已经贡献了 GitHub 上 4% 的代码提交量，预计到年底将接近五分之一。Boris Cherny 是这个项目从零到一的推动者，也是 Anthropic 的 Claude Code 负责人。最近他密集做了两期播客访谈（Lenny's Podcast 和 Y Combinator Light Cone），大量信息值得反复咀嚼。
我从两期对话中提炼了对开发者最有参考价值的核心信息，试着把它们编织成一条可以跟着走的思考线索。
一、一个终端工具凭什么赢？意外与潜在需求
Claude Code 的起源故事比大多数人想象的要随意得多。
Boris 加入 Anthropic 后，先花了一个月做各种古怪的原型，大部分都没发布。然后他又花了一个月研究模型训练。做 Claude Code 时只有他一个人，选择终端纯粹是因为不用写 UI，成本最低。他给模型一个 bash 工具，问了一句「我正在听什么音乐」，模型就自己写了一段 AppleScript 去查音乐播放器。Boris 说这是他第一次感受到 AGI 的时刻：「模型只是想使用工具，这就是它想要的全部。」
他在内部发帖宣布这个项目，只收到了两个赞。因为所有人想到编程工具，想到的是 IDE，没人觉得一个终端工具能成。
但它确实成了。先在内部扩散，坐他对面的工程师 Robert 第二天就装上了。内部发布评审时，Dario 看到日活曲线几乎垂直，问 Boris 是不是强制工程师使用，Boris 说没有，只是发了个帖子。然后是外部发布，早期吸引了一批人，但没有立刻引爆；真正的拐点是 Opus 4 发布，以及去年 11 月的又一次跃迁。
这个过程里最核心的产品思维是 Boris 反复提到的「潜在需求」（Latent Demand）。
他用 Facebook Marketplace 的例子来解释：2016 年 Facebook 发现群组里 40% 的帖子是买卖东西。没有人为此设计过产品，但用户自己发明了用法。当你看到用户在以一种你没预想到的方式使用你的产品去完成某件事时，说明你该为它专门做一个产品了。
Claude Code 身上发生了完全一样的事。越来越多非技术人员开始在终端里用它做跟编程无关的事：有人用它种番茄，有人分析基因组，有人从损坏硬盘里恢复婚礼照片，有人分析核磁共振图像。Anthropic 内部的数据科学家 Brendan 甚至自学了怎么打开终端、下载 Node.js，只为了在终端里做 SQL 分析。这直接催生了后来的 Cowork 产品。
潜在需求还有第二个维度，Boris 称之为「观察模型想做什么」。传统做法是把模型塞进一个预设好的盒子里，规定好它和工具交互的方式。Claude Code 反过来了，产品就是模型本身，给它最基本的工具集，让它自己决定该运行什么、以什么顺序运行。用研究术语说，这叫「处于数据分布内」；用产品术语说，就是把用户研究的方法论应用到了模型上。
如果你正在构建 AI 产品，这里有一个很实用的思考角度：不要只观察用户在做什么，也要观察模型试图做什么。两种潜在需求叠加在一起，往往指向最有价值的产品方向。
二、为六个月后的模型构建，而不是今天的
这大概是 Boris 在两次访谈中强调次数最多的一句话了。
Claude Code 刚起步时，模型其实很差。2 月份发布时大概只能写 10%-20% 的代码，到 5 月份也只有 30% 左右，Boris 大部分代码还是用 Cursor 手写。直到 11 月，比例才跨过 100%。但从一开始，整个产品就是按照「模型迟早会变好」的假设来设计的。
这个策略有一个不舒服的副作用：前六个月产品市场契合度可能极差。Boris 对此直言不讳，「这会让人很不舒服，但如果你是为六个月后的模型构建产品，当那个模型问世时，你就能立刻起飞。」
与之配套的是 Claude Code 团队极度推崇的一篇文章：Rich Sutton 大约十年前写的 The Bitter Lesson（苦涩的教训）。核心观点是更通用的模型总是会击败特定领域的模型。
Boris 把这个原则翻译成了具体的工程决策框架。每次团队需要在「花工程时间做脚手架提升一点性能」和「等下个模型自带这个能力」之间做选择时，都会认真权衡。他的经验是，脚手架能带来 10%-20% 的性能提升，但新模型一出来，这些收益基本被抹平。「你要么不断重建脚手架，要么直接等待下一个模型。」
一个非常具体的例子是 CLAUDE.md 文件。很多用户花大量精力去过度设计这个配置文件，Boris 自己的 CLAUDE.md 只有两行指令。他的建议是：如果文件变得太长，删掉重新开始。只保留让模型回到正轨所需的最少内容。因为模型能力一直在变，你会发现随着更新，需要添加的指令越来越少。
同样的逻辑也解释了为什么 Claude Code 始终保持终端形态。Boris 说团队觉得无论构建什么 UI，六个月后都会随着模型进步而变得不适用。终端是他们能想到的唯一跟得上模型演进速度的形态。整个 Claude Code 的代码库一直在被重写，现在的代码中几乎没有六个月前的东西，大概 80% 都是近几个月写的。Boris 说「代码的保质期缩短到了几个月」。
这个判断其实对所有在 AI 上层做应用的开发者都适用。如果你现在构建的东西只有在模型不进步的情况下才有价值，那它大概率是短命的。反过来想，你构建的东西能不能随着模型变强而变得更有价值？这个问题值得经常拿出来问自己。
三、新工程范式：从「写代码」到「驱动智能体」
Boris 自己的工作状态可能是对未来最直观的预演。
从去年 11 月起，他 100% 的代码由 Claude Code 编写，再也没有手动编辑过一行。他每天提交 10 到 30 个 PR，录制 Lenny's Podcast 时大概同时跑着 5 个智能体。他卸载了 IDE。
这听起来像是「高级工程师不用写代码了」的简单叙事，但实际上远比这微妙。
Boris 提到了一个让他印象深刻的内部案例。他遇到一个内存泄漏问题，按照多年养成的习惯去提取堆快照、打开调试器、翻阅跟踪记录。结果团队里一个比较新的工程师直接问 Claude Code：「好像有泄漏，你能找出来吗？」Claude Code 做了跟 Boris 完全一样的事：提取堆快照、给自己写分析工具，然后比 Boris 更快地定位了问题并提交了 PR。
Boris 从中得到的反思是，资深工程师的经验有时反而会成为障碍。他说自己「有时候思维还停留在六个月前的模型上」，而新加入的工程师因为没有旧包袱，反而能更自然地让 AI 去做事。
他给团队制定了一条原则：有什么比亲自做更好的？让 Claude 去做。配合这条原则的还有另外两条，一是稍微少给点资源（人少的时候反而能从 AI 工具中榨取更多价值），二是如果今天能做完就今天做。
关于多智能体协作，Boris 分享了一个很有说服力的案例。Claude Code 的插件功能完全是由一个智能体集群在一个周末建成的，运行了几天，几乎没有人工干预。团队里一个工程师给 Claude 一份需求文档，让它使用 Asana 面板。Claude 就在 Asana 上创建了一堆任务，生成了一堆子智能体，主 Claude 给它们下达指令，然后就自行完成了。Boris 把主智能体叫做 Mama Claude。
他自己处理难题的时候也会调整子智能体的数量，如果是非常难的研究任务，他会说「使用 3 个、5 个甚至 10 个子智能体并行研究」。
Anthropic 内部的数据印证了这种范式转变的效果。过去一年工程团队规模大约扩大了四倍，但每位工程师的 PR 数量增长了约 70%，人均生产力提高了 150%-200%。Boris 在 Meta 做过全公司代码质量控制，当时「几百个工程师努力一整年，可能也就换来百分之几的生产力提升」。
经验曾经是工程师最值钱的资产，但现在「保持初学者心态」可能比经验本身更值钱。Boris 在招聘时最喜欢问的面试题是「举一个你犯错的例子」，他通过这个问题判断候选人是否能承认错误、承担责任、从中学习。在模型快速迭代的时代，这种品质比「强烈的技术观点」更有价值。
四、印刷术类比与「构建者」时代的到来
Boris 花了不少时间去寻找当下这场变革的历史类比，最终锁定了 15 世纪的印刷术。
在印刷术发明前，欧洲识字率不到 1%。所有读写工作都由一小撮抄写员完成，他们的雇主（领主和国王）通常自己也不识字。古腾堡印刷术出现后的 50 年里，产生的印刷材料比之前一千年所有文字材料加起来还要多。印刷成本在 50 年内降了大约 100 倍。之后的两百年里，全球识字率从不到 1% 提升到了 70% 左右。
Boris 提到了一份历史文献中对 15 世纪某位抄写员的采访。这位抄写员对印刷术其实很兴奋，他说自己最不喜欢的工作就是在书本之间抄写，真正喜欢的是给书画插画、做装订。印刷术让他能腾出时间去做这些。
Boris 说自己对此深有同感。「我不用再处理那些乏味的编码细节了。摆弄 git 和各种工具链根本不是好玩的部分。真正有趣的是弄清楚该构建什么，构思创意，与用户交谈，思考系统和未来。」
这个类比也指向了一个更大的判断。Boris 认为编程在很大程度上已经被解决了。至少对他所从事的编程类型来说，这是一个已解决的问题。「Claude 可以做到」这句话在一年前还像是吹牛，现在却是一个正在被验证的事实。
从这个判断出发，他对未来角色的预测也很直接：软件工程师这个头衔将逐渐消失，取而代之的是「构建者」。团队里所有人都在写代码，产品经理、工程经理、设计师、财务、数据科学家。角色之间可能有 50% 的重叠，区别在于各自的专长方向。
对于「还需不需要学编程」这个问题，Boris 的回答是：对于今天使用 Claude Code 的人，你仍然需要理解底层逻辑。但一两年后，这真的无关紧要了。他把编程技能比作汇编语言，你仍然可以去了解它，它能让你成为更好的工程师，但它不再是必需品。
在对 Lenny 的访谈中他说了一句让我印象很深的话：「我想象几年后的未来，当每个人都能编程时，那将解锁什么？就像 15 世纪的人们无法预测我们的时代一样，我也无法想象。」
Boris 观察到最有效的工程师呈现出两极分化的状态，一端是极端专家（比某个领域的所有人都懂得多），另一端是超级通才（跨越产品、设计、基础设施等多个领域）。对大多数人来说，后一条路的回报可能更大。当编程不再是稀缺技能，真正稀缺的是判断力、品味和把不同领域串起来的能力。
五、尽早发布的安全观：三层模型与真实世界验证
Boris 当初离开 Anthropic 去了 Cursor，两周后又回来了。触发他回归的原因，他说得很干脆：使命感。这个使命感具体到产品层面，就是一套三层安全方法论，它的思路对任何在做智能体应用的开发者都有参考价值。
第一层是对齐和机制可解释性，在训练阶段就介入。目前已经有相对成熟的技术来理解模型内部神经元的行为，比如监测与特定概念相关的神经元是否被激活。Boris 推荐了 Chris Olah 在这个领域的研究。
第二层是评估，在实验室环境中给模型合成场景，测试它在可控条件下的反应是否符合预期。
第三层是观察模型在真实世界中的行为。这一层也是 Boris 着墨最多的部分。他的核心观点是，随着模型变得更复杂，它在前两层可能表现完美，但在第三层未必。实验室环境终究是有限的，很多问题只有在真实用户和真实场景中才会暴露出来。
这就带出了一个听起来有点反直觉的结论：尽早发布本身就是安全策略的一部分。大多数人会认为安全意味着慢一点、多测试、等更稳定了再发。但 Boris 的逻辑是，只有让模型尽早接触真实世界，你才能发现那些实验室里发现不了的安全问题。Claude Code 在对外发布前，在 Anthropic 内部使用了四五个月。Cowork 发布时被标记为「研究预览版」，也是同样的逻辑。
这套方法论的核心思路其实可以迁移到任何智能体应用的开发中：训练阶段的约束、可控环境的测试、真实场景的验证，三层缺一不可。很多团队只做了前两层就上线了，然后在第三层翻车。也有团队过度依赖第三层（「先发了再说」），结果连基本的对齐都没做好。Boris 的经验说明，三层之间需要形成一个持续反馈的闭环，而不是线性的流水线。
写在最后
回顾 Boris 这两次访谈，有几个信号对于开发者来说值得认真对待。
首先是智能体开发的产品思维，正在从「把模型装进盒子里」转向「让模型自己决定怎么做」。这意味着好的智能体应用开发越来越不像传统的软件工程，而更像是在设计一个环境和规则集，再观察模型在其中的行为。CLAUDE.md 的极简主义、潜在需求的双重视角，以及「为未来模型构建」的策略，本质上都指向同一个方向：少控制，多赋能。
其次是开发者自身角色的转变已经在加速。Boris 每天提交 30 个 PR 却不写一行代码，Mama Claude 带着子智能体集群在周末完成一个完整功能，这些不再是愿景，而是正在发生的日常。对于还在观望的开发者来说，现在开始实际使用这些工具、建立与智能体协作的肌肉记忆，可能比讨论「AI 会不会取代程序员」更有意义。
最后，Boris 反复提到的「苦涩的教训」值得每个做 AI 应用的人贴在屏幕旁边：永远不要对立于模型的发展趋势下注。你今天精心搭建的脚手架和 workaround，很可能在下一个模型发布时就变得多余。把精力花在那些会随着模型变强而增值的事情上，这可能是当下最值得内化的一条原则。
参考资料 （附访谈全文中文文字稿）