2024 年 Anthropic 内部,一个名叫 Boris Churnney 的工程师做了一个 hack。他给 Claude 一个 bash tool,问"我现在在听什么音乐"。模型没有被告诉这个 tool 可以怎么用——它自己写了一段代码、调用 bash、查清楚答案。Boris 把这段 demo 录下来发到内部频道,总共得到了 2 个 like。整个 Anthropic 当时没人觉得这是一个产品方向——大家想象中的"AI 编程工具"应该长得像 IDE,terminal 是个奇怪的选择。 18 个月后,这个最初拿了 2 个赞的 hack 已经长成另一个东西。Claude Code 占全球 GitHub 公开仓库约 4% 的 commit,半数预测认为这个数字到 2026 年底会冲到 20%——按 SemiAnalysis 的说法是"我们眨了一下眼,AI 已经吃下了所有软件开发"。Anthropic 内部工程团队过去一年扩张大约 4 倍,但人均 PR 产出提升了 200%。Spotify 在采访录制当天发出标题:他们最好的工程师从 12 月开始没有手写过一行代码。Claude Code 自己在 Anthropic 整体 150 亿美元 ARR 里贡献接近 20 亿——也就是说,从一个 hack 到一个十亿级业务,中间隔了大约一年。 这场和 Lenny's Podcast 的跨度对话因此值得逐段读。Boris 给出几个判断都比同行更尖锐:coding 已经被解决;"software engineer"这个头衔到年底就会开始消失;设计师在 AI 转型里比工程师明显更难享受工作;不要把 model 装进盒子,要看 model 自己想做什么;为 6 个月后的模型设计产品,而不是为今天的模型。但他在同一场对话里也反复承认,自己——内部最熟悉 Claude 的人之一——也常常卡在"旧 model 时代的工程直觉"里没及时切换。这个"承认"可能是整场对话最值得做产品决策的人停下来读两遍的部分。
从 hack 项目到 4% GitHub commits:Claude Code 的一年内部路径
这部分是 Anthropic 这一年里最容易被外界误读的故事——大家看到的是 Claude Code 突然席卷,但内部路径其实是分成几段、各有 inflection point 的。
起点是 2024 年中后段,Boris 加入 Anthropic 后的"打杂阶段"。他用一个月写了一堆 prototype,大部分没有发布;再用一个月做 post-training,理解模型本身怎么训出来——他自己的总结是,"做工程要理解你工作那一层之下的那一层"。然后他回来,基于 model 已经具备的 tool use 能力开始 prototype,做出了第一个版本叫 Claude CLI。"我在听什么音乐"那个 demo 是这个 prototype 的标志——不是因为答案重要,而是因为 model 在没有任何特定指令的前提下,自己想清楚了用哪个 tool 才能回答问题。这是 agent 行为最早期的清晰信号。
Terminal 这个形态选择经常被外界解读成"反直觉的 brilliant 设计",但 Boris 在采访里直接讲了真实理由——因为只有他一个人在做,terminal 是工程上最简单的开发方式。后来选择保留 terminal 也不是因为 terminal 在体验上最优,而是因为 model 迭代太快,其他任何更复杂的形态都跟不上 model 升级的节奏。这是一个产品哲学层面值得注意的反例:很多被复盘成"远见卓识"的产品决策,真实原因是当时资源极少导致的工程妥协。
2025 年 2 月 Claude Code 公开发布,没有立刻成为爆款。Boris 在采访里特意点明这一点——早期采用者来了,但很多人不理解 terminal-based 的编码 agent 是什么东西。第一个真正的 inflection point 是 5 月 Opus 4 发布,这是 Anthropic 第一个 ASL-3 级别的模型,Claude Code 的 DAU 第一次走出陡峭曲线。第二个 inflection point 是 11 月——Boris 自己的代码 100% 由 Claude Code 完成,从那天起他没有手写过一行代码。这两个 inflection 几乎完全对应模型能力的台阶。这意味着 Claude Code 的增长曲线本质上不是产品迭代曲线,是 model 能力曲线的镜像——这一判断对所有 AI 产品创业者都有相当直接的含义。
到采访录制的时间点,Claude Code 已经有 iOS/Android app、桌面应用、网页版本、IDE 扩展、Slack 集成、GitHub 集成,terminal 只是其中一个表面。Boris 自己的代码大约 1/3 在 terminal、1/3 在桌面 app、1/3 在 iOS。他把这种"同一个 agent 跑在多种 surface 上"的状态称为 multi-Claude——一种工作方式,不只是一种产品形态。这是它和 Cursor、Codex CLI、Aider、Copilot 的核心差异之一:这些竞品大部分仍绑定一种主 surface,Claude Code 是 surface-agnostic 的。 Anthropic 内部数据点更激进。工程团队过去一年扩张大约 4 倍,但人均 PR 产出涨了 200%。Boris 在 Meta 时负责整个公司的代码质量(Facebook、Instagram、WhatsApp 全部),他给的对比基线是:在 Meta 那种规模下,几百个工程师投入一年,人均生产力提升通常是几个百分点。几百个百分点这种数字在他过往经验里"完全没有 reference"。这是一个值得记下来的评价句——它意味着,AI 编程工具对工程团队产出的影响,可能不是连续优化曲线,而是阶跃曲线。
更值得记下来的是,Anthropic 内部已经出现"工程师每月在 token 上花费几十万美元"的情况。这是 Boris 顺嘴提的数据。换算下来,这种工程师的 token 消耗已经接近甚至超过他们自己的人力薪资成本——按传统软件公司的财务模型这是离谱的,但 Boris 给的判断是:别太早 cost-cut,先让工程师无限用 token,等找到 working idea 再优化。这个判断和 Anthropic 给员工的 token 政策一致,也越来越多被其他公司当作招聘 perk。
"Coding solved" 的判断,和"为 6 个月后模型设计"的押注
Boris 在整场对话里最具争议的判断是这一句:"Coding is largely solved."
这句话需要细读上下文。他没有说所有编程都解决了——他说的是"对我做的这种类型的工程",coding 已经是 solved problem。"我做的这种类型"在采访里有具体定义:产品工程、infrastructure、TypeScript/Go/Python 主流语言、互联网应用范式。Boris 没有断言 C++ kernel 工程、嵌入式、密码学实现、新颖算法研究等场景已经被解决——这些他没有点评。
为什么这个边界重要?因为 Anthropic 内部有工程师还在周末手写 C++,Boris 提到这位同事 Lena,说"这种空间会一直存在"。这句话和"coding solved"放一起读,会得到一个更精确的判断:业界 80%-90% 的应用层编程会快速被 AI 吞下,剩下 10%-20% 的硬核场景(系统层、性能极致、新算法、形式化验证)会留更久。Boris 没有给具体的时间分布,但他给的整体节奏是,2025 年是 coding agent 元年,2026 年是 general agent 元年。
如果 coding 已经基本解决,那产品决策应该向哪走?Boris 给了一条相当激进的押注哲学——为 6 个月后的模型设计,而不是为今天的模型。
这条原则在 Claude Code 自己的演进上得到验证。早期版本里,model 大约只写他 20%-30% 的代码——也就是说,以"今天的可用性"评估,Claude Code 早期是个普通工具,远不如 Cursor 那种专门优化 IDE 体验的产品。但 Boris 选择从一开始就 bet on "model 会变得好到能写大部分代码"这件事——所以产品架构上把 model 放在中心、scaffolding 做到最薄。当 Opus 4 出来时,这个架构 instantly click,因为它早就是为这种 model 能力准备的。Cursor、Copilot 这一类产品,某种程度上是为"今天的 model"做了过度优化——这是 Boris 没有点名但隐含的判断。
这条原则有一个具体推论是 bitter lesson 的产品化应用。Rich Sutton 这篇 2019 年的博文里讲的是研究范式,Boris 把它翻译成了产品决策:永远押更通用的模型,不要 fine-tune,不要用小模型省成本,不要写复杂的 workflow scaffolding。理由是,scaffolding 通常能带来 10%-20% 的性能提升,但下一个模型出来这种提升会被磨平——你为了保住 20% 的优势写的复杂工程,在下一个 release cycle 后变成产品的负担。这条经验和 OpenAI 早期围绕 GPT-3.5 做的大量 prompt engineering 中间件后来集体失效是吻合的。
Boris 给创业者的建议直接:"早期 6 个月的 PMF 会很差,但模型升级时立刻 click"。这种押注模式有明显代价——如果你的资金跑不到模型升级那一刻,产品就死在了"为了不存在的 model 设计"的尴尬位置。这是一个高风险高回报的姿态,不是普适建议。值得对比的是 Cursor 的策略——它选择在每一代 model 上都把当前能力榨到极致,代价是每次 model 升级都要做大量重构,但好处是任何时刻都有 PMF。两种姿态没有绝对优劣,但你必须知道自己选了哪一种。
Latent Demand 的双轨框架:既看人,也看 model
如果说"为 6 个月后模型设计"是哲学层,那 latent demand 是 Boris 在采访里给的最具操作性的产品方法论——而且他对这个原则做了一个值得专门记下来的更新。
传统 latent demand 框架是观察人。Facebook Marketplace 来自一个观察:Facebook 群组里 40% 的帖子是在买卖东西——不是设计意图,是用户硬把群组功能扭成跳蚤市场。Facebook Dating 来自另一个观察:60% 的 profile views 来自非好友异性——不是设计意图,是用户在 Facebook 上做约会软件该做的事。识别这种"用户在硬扭产品做某件事"的信号,然后建一个专门的产品给他们,这就是 latent demand。
Cowork 是 Boris 在采访里给的最完整的 latent demand 案例。Anthropic 团队观察到,过去 6 个月里很多人在用 Claude Code 做和编程毫无关系的事——一个人在用它管理种番茄的进度;另一个在分析自己的基因组;有人在用它从损坏的硬盘里恢复婚礼照片;还有人在用 Claude Code 分析 MRI 影像。Anthropic 内部第一个非工程师上手 Claude Code 的是数据科学家 Brendan,他自己摸索装了 Node.js,把 Claude Code 装在终端里跑 SQL 分析。"工程师都不爱用 terminal,他一个数据科学家居然搞通了。" 这是 Boris 当时的反应。第二周整个数据科学团队都开始用同样的方式工作。
这种"明明很难用但用户硬要用"的信号,是产品下一步最强烈的指引。Anthropic 顺着这个信号建了 Cowork——把 Claude Code 的能力放在 Claude 桌面 app 的另一个 tab 里,让非工程师可以不开 terminal 用同一个 agent。开发花了 10 天,完全用 Claude Code 自己写——包括一整套虚拟机沙箱安全系统(给非工程师用必须做的安全保护)。Cowork 发布即受欢迎,起势速度比 Claude Code 当年快得多。
值得专门记下来的细节是:Anthropic 内部用作 Cowork 发布前 eval 的 50 个非编程用例,其中 50 个是 Lenny 自己几个月前那篇博文整理的——Cowork 在这 50 个用例上做到 48 个 pass 之后才被允许公开发布。这是一个外部 PM 写的清单,意外变成了 frontier 实验室的内部 eval set——这种事情本身就是当前 AI 产品节奏混乱程度的体现。
但 Boris 给的更新部分更值得记下来。他说,过去 6 个月他自己在用一个新版的 latent demand 框架——不是看人,是看 model 在尝试做什么。
这一段需要展开讲。早期 LLM 应用模式是把 model "装进盒子"——开发者预先决定 model 在系统里扮演的角色,设计好它能调哪些 tool、按什么顺序调、收到什么样的 response 后做什么。这种模式在 GPT-3.5 时代是必要的,因为 model 自己不够聪明,scaffolding 必须严格。但 Boris 的判断是,到了今天这一代模型,装盒已经在拖产品后腿。Claude Code 的设计反过来——产品就是 model 自己,周围只放最薄的 scaffolding,给 model 一组最小可用的 tools,让它自己决定调用哪个、按什么顺序、什么时候停。
研究术语里这叫 "on distribution"——你要让 model 跑在它训练时见过的分布上,而不是用复杂工程把它拉离训练分布。产品术语翻译过来就是 latent demand 的第二轨:观察 model 在尝试做什么,然后让那件事变得更容易,而不是给它一堆它不想做的限制。这条判断对当前一大批用 LangChain、LangGraph、CrewAI 这类编排框架在 LLM 上做"复杂工作流"的产品是相当严厉的反对——Boris 的观点是,这种复杂编排在 model 不够强时是必要的,但每升级一代 model 就会被磨平更多。最终 model 自己具备 tool 选择、流程规划、错误恢复的能力,scaffolding 应该越来越薄。
这条原则和前面的 bitter lesson 是同一件事的两个面:通用模型 + 薄 scaffolding 永远赢复杂 workflow——只是在产品层面表达。
"Software engineer" 头衔的消失:从 builder 到设计师都得写代码
Claude Code 的下一个前沿,Boris 在采访里描述得相当具体——Claude 自己提想法。已经在跑的版本:Claude 看 Anthropic 内部的 feedback channel、bug reports、telemetry,自己识别出哪些问题值得修,自己提 PR。这个版本还在内部完善,但 Boris 把它形容为"开始有点像 coworker 了,而不只是一个 tool"。这一步如果在 2026 年广泛 ship,意味着 PM 这个角色的核心工作——决定产品做什么——会面临直接挑战。
但比"Claude 提想法"更激进的判断,是 Boris 直接说的这一句:"年底,'software engineer' 这个头衔会开始消失,被'builder'取代"——或者更激进的版本,"所有人都是 product manager,而所有人都写代码"。
这个判断在 Anthropic 内部已经在落地。Claude Code 团队的运作方式是所有人都写代码——产品经理写代码,工程经理写代码,设计师写代码,财务也写代码,数据科学家写代码。Boris 在采访里举的例子是一个写 Go 的工程师做了一个月某个服务,效果还不错——但这个工程师告诉 Boris:"我其实还不太懂 Go。" Boris 的反应是,如果能做出正确高效的产品,你不需要懂 Go 的所有细节——这是过去一年职业边界被 AI 模糊的最直接信号。
需要注意的是,这种边界模糊并不对所有人均匀分布。Lenny 在采访里报了一个他自己做的 Twitter 民调结果:70% 的工程师和 PM 说他们用了 AI 后更享受工作,但只有 55% 的设计师这么说;同时设计师报告"享受减少"的比例也最高。Boris 没有否认这个差距,只能给一个解释——Anthropic 内部的设计师大部分自己写代码,所以他们的体验比业界平均更好。但他也承认他不真正理解为什么设计师群体更难享受 AI 转型,这是一个开放问题。
这是一个值得任何在做 AI 工具的产品团队认真停下来想的数据。它隐含的可能性是:当前 AI 工具的设计哲学,是被工程师视角主导的——设计哲学的优先项是"自动化重复"和"消除繁琐",而设计师的工作里很大一部分价值不来自"消除繁琐",来自"在繁琐中找到可能性"。如果这个解读成立,那针对设计师的 AI 工具需要根本不同的产品哲学,而不是把 Cursor 改个 UI 就行。Figma AI、Adobe Firefly、各家做 design agent 的产品到目前为止还没真正解决这个差距——这是 2026 年仍然敞开的产品机会。 Boris 自己给所有想在这一波里活下来的人的建议有两条。第一条是用 AI 工具用到极致——这条所有人都说,差异不大。第二条更值得记:做 generalist,不要做单一专长。他的观察是,Claude Code 团队最强的工程师都是 hybrid 类型——产品+infrastructure、产品工程师+设计 sense、工程师+商业 sense、工程师+用户共情。不善跨界的人,接下来几年的处境会越来越尴尬。这个判断和 Demis Hassabis 在 YC 演讲里说"跨学科是 deep tech 创业最重要的护城河"在结构上一致——两个 frontier 实验室的核心人物在不同场合、用不同框架,得出了同一个结论。
历史类比 Boris 用的是印刷术。古登堡发明印刷机后,印刷量在 50 年内超过此前 1000 年的总和,成本下降约 100 倍。识字率从 1% 不到爬到 70% 用了 200 年——因为识字需要教育系统、自由时间、不用整天在农场里干活。但他特别提了一份历史档案——15 世纪某位 scribe(抄写员,当时最稀缺的职业之一)被采访,他对印刷机的反应是兴奋:"我不喜欢的是抄抄写写,我喜欢的是画书里的插图和装订书。印刷机让我不用做我不喜欢的部分了。"
Boris 借这段说,他自己对编码的体验和这个 scribe 完全一样——他没有失去什么,只是不用再做"git 操作 / 依赖 debug / 库查找"这些过去耗他时间最多的部分。但他在采访里也承认,这种"被解放"的体验不是普世的。设计师民调的差距、Twitter 上无数对"看着年轻人用 Cursor 出结果"产生焦虑的资深工程师、被 AI 直接挤掉的 outsourcing 团队——所有这些是同一个工业转型的另一面。"对一些人这是解放,对另一些人是失去"——他原话没有说,但他描述印刷术那段的语气接近这个判断。
局限与未解:agent 焦虑、AGI-forward 思维的盲区、设计师民调的差距
把整场采访里 Boris 自己点明、或在他论述里隐含的"还做不到"和"还没想清楚"集中起来,大致分成四类。
第一类是 agent 自身的运行体验问题——Lenny 在采访里直接问到的"agent 焦虑"。当工程师同时在跑 5-10 个 agent 时,会出现一种新形态的精神状态:任何一个 agent 卡住、需要确认、或者出错,都会立刻打断当前思考。手机推送、Slack 提醒、agent 状态变化,这些信号叠在一起会形成新的注意力碎片化。Boris 自己承认有一些这种体验,但他的解决方式是"始终保持多个 agent 在跑",从而模糊单个 agent 阻塞带来的焦虑。这显然不是普适的解法——它建立在他作为 Claude Code 主管对 model 行为有极强直觉的前提上,普通用户没有这种直觉,焦虑只会更强。这是 2026 年 agent UX 设计层面尚未解决的核心问题。
第二类是"AGI forward 思维"的盲区——Boris 自己最坦诚的承认。他举了一个具体例子:几个月前 Claude Code 出现内存泄漏,他作为内部最资深的工程师之一,本能反应是用传统调试器、跑 heap snapshot、手动分析。与此同时,一个新加入团队的工程师直接问 Claude:"看起来有内存泄漏,你能搞清楚吗?" Claude 自己写了一个 just-in-time 工具分析 heap snapshot,找出问题,提了 PR——比 Boris 手动调试更快。
这件事的含义比"AI 真厉害"深得多。在内部最熟悉 Claude 的人,也仍然会卡在 Sonnet 3.5 时代的工程直觉里没切换过来。如果 Boris 都会卡在旧 model 思维,整个工程师群体里有多大比例的人,实际上是在用今天 model 的能力解决昨天 model 时代的问题? 这个差距是产品层面的现实威胁——不是因为 model 能力不够,而是因为人类用户的认知更新速度跟不上 model 升级速度。Boris 没有给这个问题的解,他自己的方式是"和团队里更年轻的工程师多互动,看他们怎么用",但这显然不是规模化方案。
第三类是 Boris 自己也不理解的设计师民调差距——70% 工程师/PM 享受工作更多,但只有 55% 设计师如此,设计师报告"享受减少"的比例最高(20%)。Anthropic 内部因为设计师都写代码所以体验好,但业界整体的设计师群体,目前的 AI 工具明显不像 Cursor/Claude Code 对工程师那样让人享受。Boris 在采访里直接说他想和这些设计师多聊聊,搞清楚为什么——但他没有现成解释,没有 roadmap,没有解决方案。这是 frontier 实验室对一个明显存在的产品鸿沟的真实姿态:承认它存在,但还不知道怎么填。这意味着针对设计师群体的 AI 工具,在 2026 年仍然是一个相对开放的赛道。
第四类是 Boris 给的方法论原则在更广泛 context 下未必成立。"Underfund everything a little bit"(每件事都稍微少投资源,逼出加速)是 Claude Code 团队的工作哲学——但这条建议的前提是团队成员能力极高、token 预算充裕、安全网厚。在工程文化薄弱的公司套用这条原则会得到完全不同的结果——人会被压垮,质量会塌,出 bug 出事故。Boris 没有给这个边界,但任何想直接复制 Anthropic 工作方式的团队需要先想清楚自己的前置条件是什么。同样,"build for the model 6 months out" 在跑钱跑不到 6 个月升级周期的小公司就是死路。这些原则看起来是普适方法论,但实际上有相当严格的适用条件——这一点采访里没有专门讨论,值得任何把 Anthropic 经验拿去引用的人自己 caveat 一下。
需要注意的是,这四类局限并不彼此独立。Agent 运行焦虑在长期使用者身上会强化"AGI forward 思维"的盲区——长期用户被 burnout 之后更倾向于沿用熟悉模式。设计师群体的差距,如果背后真因是工具哲学的工程师视角偏向,那它和"underfund 原则普适性"是同一个问题的不同投影:当前 AI 工具的设计基础假设是工程师文化,这个假设需要被显式挑战才能产出真正服务于其他职业的产品。把这几类问题放一起看,2026 年 AI 工具最有空间的产品方向不是"做一个更好的 Cursor",而是重新审视那些被工程师文化默认掉的产品哲学——focus、注意力、节奏、交付物形态——然后在这些维度上做出工程师工具不会做的决策。