“软件工程师”头衔要没了？Claude Code之父YC访谈：一个月后不再用plan mode，多Agent开始自己组队干活

放出这话的，正是 Claude Code 的创始人 Boris Cherny。

他最近在 Y Combinator 的一场圆桌访谈中，一人对阵四位 YC 高管，几乎句句都带着点“重锤感”。

在他看来，编程正在被“解决”。在 Anthropic，很多人已经 70%–100% 用 Claude 写代码，IDE 的存在感正在下降。写代码这件事，正在从“核心能力”变成“默认能力”。

而另一边，模型能力会指数增长，今天的“勉强可用”，六个月后可能原生支持，如果只围绕当前模型做 PMF，很快会被下一代能力抹平：

“在 Anthropic，我们一直有一个核心理念：我们不是为‘今天的模型’做产品，而是为‘六个月后的模型’做产品。”

这，也是他给所有 LLM 创始人的一条建议。

本次访谈，除了 Boris 本人外，其余几位包括：YC 总裁兼 CEO Garry Tan、合伙人 Harj Taggar、Diana Hu，以及 Jared Friedman。

YC 总裁兼 CEO Garry 开场就说了句：“谢谢你做了 Claude Code。它让我连续三周没睡好。”

这不纯是客套。Claude Code 不仅对外很火，对内也像一台“超级引擎”，自其推出后，Anthropic 的人均工程产出提升了 150%。

用 Boris 的话来说，就是：

“我以前在 Meta 负责代码质量，也负责跨多个产品线的代码库质量。当时我们做“提升生产力”，看到 2% 的提升，都可能需要几百人干一年。所以这种 100% 级别的提升，是完全没见过的，闻所未闻。”

但这场对话最值得看的，并不是“又一个 AI 编程工具爆火”的故事，而是 Boris 如何把一个终端里的小聊天程序，迭代成今天这个能调工具、会 plan、甚至会主动找人沟通的开发 agent。

除了上文提到了，本次访谈中，还有 一些很有意义的判断和观点，核心内容提炼如下：

• 代码的保质期只有几个月。
  Claude Code 被反复重写，六个月前的代码几乎全部消失；重构不是例外，而是常态。

• Plan mode 未来可能自动进入，再往后可能会消失。
   其本质，只是 prompt 里加一句“先别写代码”，最终可能一发 prompt 就能完成。

• 不要和模型对赌。
   加很多脚手架也许能多拿 10% 的效果，但下一代模型可能直接“白送”；所有非模型能力最终都会变成技术债。

• 功能不是规划出来的，是从用户行为里“长”出来的。
  plan mode、CLAUDE.md、co-work 都源于用户已经在做的事，产品只是把它们收拢进来。不要教育用户改变行为，而是顺着他们已经发生的行为去放大它。

• Agent 的能力边界，会每几个月重写一次
  。你对“它能不能做”的判断很快会过时，工程师必须不断重置认知。多 agent 协作，是能力放大的关键变量。并行 sub-agent、本质上是 test-time compute 和上下文隔离的组合，会显著提升复杂任务能力。

• 迭代速度本身就是护城河。
  Claude Code 可以一天做 20 个原型，快速试错比“设计完美方案”更重要。

对处于 AI 洪流中的技术开发者和创始人，Boris 给出的建议是，是 新时代最重要的能力是“新手心态”。 能承认自己错、能丢掉旧经验、能从第一性原理重新思考，比资历更重要。

以下为本段访谈的全部重点内容， AI 前线在不改变原意的前提下，对内容进行了整理编辑。

Garry：谢谢你做出了这个东西（Claude Code)，它让我连续三周都没睡好。我已经对 Claude Code 上瘾了，感觉像给人装上了火箭助推器。这个体验大家已经持续感受好几个月了，我记得大概从 11 月底开始，很多朋友都说“感觉不一样了”。

Boris： 我自己第一次有这种感觉，是在刚做出 Claude Code 的时候——那会儿我还不确定自己是不是做对了方向。我隐约觉得“可能成了”，然后我就开始睡不着了。

那是 2024 年 9 月。连续三个月，我没休过一天假，周末也在干，每晚都在工作。

我一直在想：“天啊，这东西可能会变成一个真正的产品。”但当时我也不知道它到底有没有用，因为那时候它其实还不会写代码。

Boris：最不可思议的是：我们到现在居然还在用终端。终端本来只是起点，我没想到它最后会变成终点。

第二个意外是，它居然真的变得有用了。 因为一开始它几乎不会写代码。甚至到 2 月份，它大概也就写了我 10% 的代码。我当时并不靠它写代码，它写得不够好，我还是大部分都手写。现在能做到我们当初下注的那个方向，说明赌对了；但当时这件事一点也不明显。

在 Anthropic，我们一直的思路是：不要只为“今天的模型”做产品，而是为“六个月后的模型”做产品。

这也是我给所有基于 LLM 做产品的创始人的建议：尽量去想——今天模型还不太擅长、但很快会变强的前沿点 在哪里。它会变好，你只需要等它到位。

Boris： 其实它非常“意外”，就是一路演化出来的。

对 Anthropic 来说，我们很早就押注“编程”这条路：我们认为通往安全 AGI 的路径之一，就是通过编程能力。

整体思路一直是：先教模型写代码，再教它用工具，再教它用电脑。你也能从我加入的第一个团队看出来——当时叫 Anthropic Labs，做了三个产品：Claude Code、MCP 和桌面端 App，这些其实是串在一起的。

具体到 Claude Code，其实没人让我做 CLI。我们大概知道模型可能已经到了适合做编程产品的阶段，但还没有人真的做出一个能把这种能力“吃干榨净”的产品，所以当时有一种很强烈的“产品能力悬空感”（product overhang）。那会儿这种感觉更夸张，因为根本没人做过。

于是我就开始随便 hack。一开始我想：“要做编程产品，我得先学会怎么用 API。”

因为那时候我还没用过 Anthropic 的 API。

我就做了一个很小的终端程序来调用 API，本质就是个小聊天应用。因为当时大多数 AI 应用就是聊天形态，所以我也这么做：在终端里提问、回答。后来 tool use 出来了，我只是想试一下，我也不太懂它到底是什么。我当时想：“工具调用很酷，但可能没什么用吧？先试试。”

Boris： 对，因为不用做 UI。那时就我一个人。

Boris： 没有压力，因为我们自己都不知道要做什么。团队当时就是探索模式：我们隐约觉得要做点和编程有关的东西，但具体做什么完全不明朗，也没人能高置信拍板。

而我的工作就是把这个方向跑出来。

所以我先给模型接了 batch tool——因为那就是我们文档里的示例。

我把 Python 示例直接搬到 TypeScript，因为我用 TypeScript 写。然后我也不知道模型能不能用 bash，就让它去读文件，它能 cat 文件，还挺酷的。接着我就继续试：“那你到底还能干啥？”我问它“我现在在听什么歌”，它写了段 AppleScript 去控制我的 Mac，去我的播放器里查当前音乐，这还是 Sonnet 3.5 的时候，我完全没想到它能做到。

这是我第一次那种“燃料级 AGI 时刻”。我当时想：“天啊，模型就是想用工具，它只想用工具。”

Boris： 对，完全是意外。

终端这个形态在内部开始火起来之后——其实我做出第一个原型两天后，就把它给团队 dogfooding 了。因为 当你有一个看起来可能有用的点子时，第一反应就是赶紧给别人用，看看他们会怎么用。

第二天我来上班，坐在我对面的同事 Robert，已经在电脑上用 Claude Code 写代码了。我当时特别震惊：“你在干嘛？这东西还没准备好，这只是个原型。”但它已经在那个形态下变得有用了。

后来我们做上线评审，准备对外发布 Claude Code，大概是 2024 年 11 月或 12 月。Dario 问我：“内部使用曲线都快竖直了，你是不是强制工程师用？是不是在 mandate？”我说：“没有，没有。我只是发了个帖子，然后大家互相转告，就这么传开了。”

整个过程都很偶然。我们一开始选择 CLI，只是因为成本最低，没想到它就这样自然地停留在那个形态里，并且跑了起来。

Boris ： 那时模型还不太会写代码。我自己最早用它来自动化 git。

我感觉我现在都快忘了 git 了，因为 Claude Code 帮我做太久了。

还有就是自动化 bash 命令、操作 Kubernetes 之类。也有人开始用它写代码，算是早期迹象。最早的一个典型用例其实是写单元测试，因为风险更低。 模型当时写得也挺一般，但大家开始摸索怎么用。

我们还看到一个现象：大家开始给自己写 markdown 文件，然后让模型读这个 markdown 文件——这就是 CLAUDE.md 的来源。

对我来说，产品里最大的原则就是 latent demand（潜在需求）。这个产品几乎每一块都是从潜在需求里长出来的，CLAUDE.md 就是例子。

另外还有一个我觉得挺关键的产品原则：你可以 围绕模型做“脚手架”（scaffolding） 去提升一点性能，视领域不同，可能提升 10%～20%。

但这些提升往往会被下一代模型进步直接抹平。所以要么你不停地搭脚手架、再重建；要么你等下一代模型，很多能力会“免费”出现。某种程度上，这也是我们一直留在 CLI 的原因：我们觉得没有任何 UI 能保证六个月后仍然相关，因为模型进步太快了。

Boris： 我来之前还特意看了下，我自己的 CLAUDE.md 只有两行。第一行是：每次提 PR 都开启 automerge，只要有人 approve 就自动合并。 这样我就能一直写代码，不用在 CR 来回折返。

第二行是：每次提 PR 都发到内部 stamps 频道， 让人来 stamp 一下，这样我就能更快 unblock。

其他指令都在我们团队共享的 CLAUDE.md 里，它直接放在代码仓库里，全队每周都会贡献好几次。我经常看到有人 PR 里犯了那种完全可以避免的错，我就直接在 PR 里 @Claude，说“把这个加进 CLAUDE.md”，这种事我一周会做很多次。

Boris： 我们团队的 CLAUDE.md 其实也不算长，大概几千 token。

如果你遇到这种情况，我的建议是：直接删掉，重新开始。

很多人会过度工程化，想把一切都写进去。但模型能力每次都会变，所以更好的方式是：用最少的指令把模型拉回正轨。如果你删掉之后模型开始跑偏、做错事，那时候你再一点点加回来。你很可能会发现：随着模型变强，你需要写的反而越来越少。

我觉得自己是个挺普通的工程师。我不用很多花哨工具，不用 Vim，我用 VS Code，因为简单。

Boris： 团队里有这种人，比如 Adam Wolf，他就是那种“除非我死，否则你别想从我手里夺走 Vim”的类型。

我早期学到的一件事是：每个工程师握着自己的开发工具的方式都不一样，没有一种工具适合所有人。但也正是这种差异，让 Claude Code 有机会变得很好。

我会问自己：什么样的产品是我自己愿意用、对我来说顺手的？

用 Claude Code，你不需要懂 Vim、不需要懂 tmux、不需要懂 SSH、不需要懂一堆东西，你只要打开它，它会引导你、帮你把这些都做掉。

Boris： 你怎么看？现在是不是太 verbose 了？

Boris： 这块我们确实经常改。大概六个月前，我试过把 bash 输出都隐藏掉，只给总结，因为我觉得那么长的输出我不关心。结果我给内部员工试了一天，大家集体“起义”：“我要看我的 bash！”因为很多时候它其实很有用，比如 git 输出可能不重要，但跑 Kubernetes job 这种你就真的想看细节。

我们最近把 file read、file search 这种输出也做了隐藏，你会看到现在它不再显示“读了 food.md”，而是显示“读了 1 个文件、搜索了 1 个 pattern”。这在六个月前根本不敢发，因为模型那时还不够稳，常常会读错，你作为用户得盯着它纠错。但现在我发现它几乎每次都在正确轨道上。因为它用工具太多了，很多时候总结反而更好。

但我们发出去之后，GitHub 上很多人不喜欢，有个大 issue：大家说“不，我就想看细节。”这反馈很好。

于是我们加了一个 verbose mode，在 /config 里就能开；你想看所有文件输出就可以继续看。

我在 issue 里回复之后，大家还是不满意，我反而很开心，因为我最喜欢的事情就是听用户反馈，知道他们到底想怎么用。于是我们就一直迭代，迭代到更贴近大家想要的样子。

Boris：Dan Shipper 也经常讲：每次看到模型犯错，就尽量把它写进 CLAUDE.md 或 skills 里，让它变成可复用的经验。

但我自己其实一直在纠结一个“元问题”：很多人说 agents 能做这个、能做那个，但 agents 真正能做什么，会随着每一代模型变化。

有时新同事加入团队，他们用 Claude Code 的方式甚至比我更激进，我会不断被他们震到。比如我们曾经有个 memory leak，要 debug。

我当时做法是：导 heap dump，打开 DevTools，看 profile，再去翻代码。我在那儿慢慢找。然后团队里另一个工程师 Chris 直接问 Claude Code：“我怀疑有内存泄漏，你能跑一下吗？然后帮我找。”Claude Code 拿到 heap dump 后，甚至给自己写了一个小工具来分析 dump，然后比我更快定位到了泄漏。

这个事情让我不得不反复“重置认知”，因为我的大脑有时还停留在六个月前。

Boris： 我觉得关键是 beginner mindset（新手心态），还有一点“谦逊”。

工程师这个职业经常被训练成有强观点，资深工程师甚至会因此被奖励。在我以前的大公司工作时，我招的架构师类型，往往就是经验多、观点强的人。但现在很多经验其实不再相关，很多观点都得改，因为模型在变强。所以我觉得最大的能力是：能科学地思考、能从第一性原理出发。

Boris：我有时会问：“给我一个你曾经错了的例子。”

这是个很好的问题。很多经典的行为面试题，甚至不是编码题，都挺有用的。

因为你能看出来：他能不能事后意识到自己的错误、能不能承认错误、以及有没有从中学到东西。有些很资深的人，尤其是某些“创始人型人格”，反而挺擅长这个。

但也有些人永远不会承担错误。我自己大概一半时间都是错的：一半想法都很烂，你只能去试。试了给用户、跟用户聊、学到东西，最后可能才走到一个好点子。有时候也走不到。

但过去这可能是创始人最重要的能力，现在我觉得它对每个工程师都很重要。

Boris： 我们现在就这么做。

Boris：那会有哪些维度？具体是什么？

Boris： 这也是我们在摸索的。

我观察团队里效率最高的工程师，分布呈现一种很明显的“双峰”。

一类是 极端专家，比如我前面提到的 Jared，以及 bun 团队那类人。他们对开发工具、对 JS runtime 体系的理解都强到离谱。

另一类是 超强通才，差不多是团队里的其他人：很多人同时跨产品和基础设施，或跨产品和设计，或跨产品和用户研究，甚至跨产品和业务。

我很喜欢那种“做奇怪事情”的人。过去这可能是一个 warning sign，你会担心他们能不能做出有用的东西。

Boris： 对。但现在不一样了。比如团队里有个工程师 Daisy，她原本在别的组，后来转到我们组。

我希望她转来的原因是：她加入后没多久就给 Claude Code 提了一个 PR，做的是加新功能。但她不是直接把功能加进去——她先提了一个 PR：给 Claude Code 增加一个工具，让它可以测试任意工具并验证是否工作。这个 PR 合进去之后，她让 Claude 去写它自己的工具，而不是自己去实现。

我觉得这种“跳出盒子”的思路非常有意思，因为其实还没有多少人真正 get 到。

我们团队用 Claude Agents SDK 自动化了几乎所有开发环节：自动 code review、自动 security review、自动给 issue 打标签、自动把事情 shepherd 到生产环境……几乎什么都自动化了。我在外部也开始看到有人慢慢摸到这种用法，但它确实花了很久——大家在学习怎么用 LLM 做这种“新型自动化”。这是一种新的技能。

Boris： 我们刚发布了 Claude Teams，这是一种方式；你也可以自己搭，挺容易的。

Garry：Claude Teams 的愿景是什么？

Boris： 就是协作。现在有一个 全新的领域叫 agent topologies。

你怎么配置 agents？其中一个想法是 “uncorrelated context windows”。多个 agents 各自拥有干净的上下文窗口，不会被彼此的上下文、或者自己的历史上下文污染。

你往一个问题里投入更多上下文，本质上是一种 test-time compute，会带来更多能力。再加上合适的拓扑，让 agents 以合适的方式沟通、合适地排列，它们就能做更大的东西。Teams 是一种思路，接下来还会有更多很快上线。目标就是让它能 build 得更多、更大。

一个很典型的例子是：我们的 plugins 功能，几乎完全是一个 swarm 在一个周末“跑出来的”。它连续跑了几天，基本没什么人工干预。plugins 上线时的形态，和它跑出来时几乎一致。

Boris： 对。团队里有个工程师给 Claude 一个 spec，让 Claude 用 Asana board。Claude 在 Asana 上建了一堆 ticket，然后 spawn 了一堆 agents，agents 开始自己认领任务。主 Claude 负责给总体指令，大家就这样跑出来了。

Boris： 对。如果你看现在 agents 的启动方式——我没拉过数据，但我敢猜大多数 agents 其实都是由 Claude 触发的，以 sub agents 的形式。

sub agent 本质上就是递归版 Claude Code，在代码里就是这么实现的。它是被“mama Claude”提示出来的。我觉得如果你看大多数 agents，大概率都是这样被发起的。

Harj： 我的 Claude insights 最近也提示我，debug 的时候应该多这么做。我经常花很多时间 debug，如果能并行起多个 sub agents：一个看 log、一个看 code path，感觉是必然趋势。我已经把这个写进 CLAUDE.md 了：下次修 bug，就让多个 agent 并行分工。

Garry： 遇到那种又怪又吓人的 bug，我会用 plan mode 修，它就会用 agents 去广泛搜索。相比之下，你在线性模式下更像是“做一个任务”，而不是“宽搜”。

Boris： 我也一直这么做。如果一个测试像“研究型测试”，比较难，我会按任务难度来校准 sub agents 数量：难一点就 3 个，或者 5 个，甚至 10 个，并行研究，看他们最后汇总出什么。

Boris： 看情况。这更像一个快捷方式：如果你发现自己反复重复同一句话，那就写进 CLAUDE.md；否则不需要把所有东西都写进去，你直接 prompt Claude 就行。

Boris： 也许一个月后就不用了。

Diana： 一个月后连 plan mode 都不需要了。

Boris：我觉得 plan mode 可能确实有一个比较有限的生命周期。

Boris： 对。我们已经开始在做这方面的实验了，因为 Claude Code 现在已经能自己进入 plan mode 了，你们可能也见过。我们正在努力把这个体验打磨到“刚刚好”：它会在 一个人类也会想要进入 plan mode 的那个节点 自动进入。

其实 plan mode 没什么秘密，它做的事非常简单，就是在 prompt 里加一句“请先不要写代码”。仅此而已。你其实也可以自己直接这么说。

Diana Hu：听起来，Claude Code 的很多功能开发方式都很符合 YC 常说的那套：先跟用户聊、看用户怎么用，然后再回来实现；而不是你先有一个宏大的 master plan，再把所有功能按计划做出来。

Boris：对，基本就是这样。比如 plan mode，就是我们看到用户经常会说：“Claude 先帮我想方案、规划一下，但先别写代码。”这种说法有很多版本：有时只是把想法聊透；有时是让 Claude 写非常复杂的 spec。

但 共同点都是：先做事、先想清楚，但暂时不要写代码。

所以那天就是周日晚上 10 点，我在看 GitHub issues、看内部 Slack 反馈频道，看到大家在讨论这个。我就用 30 分钟写出来，当晚就发了，周一早上就上线了——这就是 plan mode。

Boris： 我更愿意从 “模型能力在提升” 来理解这个变化。

比如六个月前，单有 plan 还不够。你让 Claude 做计划，即使开了 plan mode，你也还是得在旁边盯着、babysit，因为它可能跑偏。现在我的习惯是：大概 80% 的 session 我都从 plan mode 开始。

虽然我说 plan mode 的寿命可能有限，但我其实是重度用户。我会让 Claude 先做计划，然后切到第二个终端 tab，让另一个任务也先做计划；tab 不够我就开桌面端 app，再去 code tab 里开更多 tab，总之大多数时候都是从 plan mode 起手。计划一旦靠谱了（有时需要一点来回），我就让 Claude 直接执行。

而现在用 Opus 4.5 的感受是：我觉得 大概从 4.6 开始，它真的变得很稳了。只要 plan 是对的，它几乎每次都能一路保持在正确轨道上，把事情做对。

所以你会看到 babysit（意思是：全程盯着、随时纠正、手把手看着它别出错）的位置在变化——以前你要在 plan 前后都盯着；现在更多是只需要在 plan 之前盯着。再往后一步，也许你连 babysit 都不用了：你给一个 prompt，Claude 自己就能把它想清楚、做完。

Boris： 挺好玩的，这其实已经是我们现在在做的事了。

我们的 Claude 之间会互相交流，也会（至少在内部）挺经常直接在 Slack 上跟用户沟通。我自己的 Claude 偶尔还会想发推，但我一般会删掉——有点“尬”，我不太喜欢它的语气。

Boris： 有时候就是会去回复别人。因为我后台一直开着 co-work，co-work 特别爱这么干，它很喜欢用浏览器。

一个非常常见的模式是：我让 Claude 去 build 某个东西，它会先去看代码库；如果在 git blame 里看到某个工程师最近动过相关代码，它就会在 Slack 上直接给那位工程师发消息，问一个澄清问题。等对方回了，它就继续往下做。

Boris： 有些原则听起来很基础，但我觉得它们现在比以前更重要。

比如 latent demand（潜在需求），我提过无数次了，对我来说它就是产品里最重要的一条。

很多人不理解它，我在前几个创业项目里也没理解。它的意思大概是：人们只会去做他们本来就在做的事情，你很难让人去做一件全新的事。 如果人们已经在努力做某件事，你让它更容易，这是好想法；但如果人们正在做一件事，你非要让他们改去做另一件事，他们大概率不会做。所以你要做的，就是让他们“本来就想做的事”更容易。

而且 Claude，会越来越擅长帮你发现这些产品点子。因为它能看反馈、看 debug logs，它能自己把这些东西梳理出来。

Boris：对，就是这样。有时候我会在办公室里走一圈，在同事身后站一下（当然我会先打招呼，不是偷看那种），看看大家具体怎么用 Claude Code。我看到很多类似的用法，而且 GitHub issues 里也有人在讨论。

Boris： 挺有意思的。如果你一年前问我，我会说终端最多还有三个月寿命，然后我们就会换到下一个形态。

你也能看到我们一直在做各种实验：Claude Code 从终端起步，但现在也在 web 上、在桌面端 app（code tab 里），大概我们做了三个月或六个月；它也在 iOS/Android app 的 code tab 里；在 Slack、在 GitHub；还有 VS Code 扩展、JetBrains 扩展。我们一直在尝试不同的 form factor，想弄清楚“下一个形态”是什么。

到目前为止，我对 CLI 的寿命判断一直错，所以我大概也不是最适合预测这件事的人。

Boris： 我会这样表述：去想清楚模型想做什么，然后让它更容易做到。

比如我最初 hack Claude Code 的时候，我意识到：它就是想用工具，它想和世界交互。那你怎么支持它？不要把它关在盒子里，然后告诉它“这是 API、这是你跟我交互的方式、这是你跟世界交互的方式”。正确做法是：去观察它想用哪些工具、它想完成什么，然后像你为用户做产品一样，把这些能力真正“放开”，让它能做到。

所以如果你在做 dev tool 初创公司，我会先问：你要为用户解决什么问题？然后当你用模型来解决这个问题时，模型“想做的动作”是什么？最后你的技术方案与产品方案，如何同时服务用户的需求与模型的需求，让两边的权重和需求都被满足。

Boris：TypeScript 做了很多很“奇怪”的语言设计。比如它的类型系统里几乎任何东西都可以变成 literal type，这非常极端，甚至 Haskell 都不这么做。它还有 conditional types，这种东西我觉得很多语言压根没想过。但它又很强类型。

早期 Joe Pamer、Anders 和团队构建 TypeScript 时的思路是：我们有很多大型、未类型化的 JavaScript 代码库，我们得把类型加进去；但你不可能让工程师改变写代码的方式。你也不可能让 JavaScript 程序员像 Java 程序员那样写 15 层 class inheritance。他们会按自己的方式写：用反射、用 mutation、用各种传统上很难做类型化的特性。

Boris：没错。所以他们没有逼人改变写法，而是 反过来围绕这种写法去构建类型系统。这太聪明了。

很多点子在当时连学界都没人做，完全来自实践：观察人们怎么写 JavaScript，理解他们想怎么写，然后把类型系统“贴合”到这个现实里。

Claude Code 也有点类似：你可以把它当作 Unix 工具来用，可以 pipe 进去、也可以 pipe 出来；在某些方面它挺“严谨”的。但在几乎其他所有方面，它只是我们想要的工具而已。

我先为自己做一个工具，然后团队为自己做，再给 Anthropic 员工用，再给用户用，最后它就变得非常有用。这不是一个“学院派、原则性很强”的产物。

Boris： 我一开始做它的时候，我曾经做过一段时间前端。我也算是个“混合型”：做设计、做用户研究、写代码，都会一点。

我们也很喜欢招这种工程师，所以我们确实偏爱 generalists。

对我来说，我在做一个终端里的产品，但我其实 Vim 用得也挺差的（笑）。所以我会想：怎么做一个让“像我这样的人”也用起来舒服的终端工具？

愉悦感非常重要。

YC 也经常讲 “做一个人们真正爱用的东西”。产品如果只是有用，但用起来不会爱上它，那不够好。它得同时做到“有用”和“让人爱”。

但为终端做设计真的很难：80×100 个字符左右、256 色、一个字号、几乎没有鼠标交互……你能做的事非常有限，trade-off 特别多。一个不太多人知道的点是：终端其实可以开鼠标交互，比如点击之类。

Jared： 那 Claude Code 里怎么开？我一直想弄明白这个。

Boris： 我们没有在 Claude Code 里做这个。我们其实原型过几次，但体验很糟。因为一旦你要做鼠标交互，就得虚拟化滚动，会带来很多很奇怪的 trade-off。终端的底层也很特殊——它没有 DOM，更多是 ANSI escape codes 之类的东西，是从 1960 年代一路“有机演化”出来的一堆规范。

Garry： 这感觉 BBS。像那种 BBS 门口小游戏。

Boris： 这评价太好了。

但我们确实得自己摸索出很多终端 UX 原则，因为几乎没人写这些。你看 80、90、00 年代的大型终端应用，它们用 curses，有一堆窗口，看起来以今天标准会比较“土”、比较厚重复杂。所以我们得重造很多东西。

比如一个很小的细节：终端里的 spinner（加载转圈那种提示），到现在可能迭代了 50 次、甚至 100 次，里面大概 80% 都没上线。我们就是不断试：不舒服就换下一个，再试，不舒服再换。

Claude Code 的一个神奇之处是：你可以连做 20 个原型，选一个最喜欢的，然后发布，整个过程可能也就几个小时。

过去你可能要用 Origami、Framer 之类的工具，做三版原型都得两周，慢很多。现在我们有一种“奢侈”：我们要探索一个新终点，我们不知道正确答案是什么，但我们能用极快的迭代速度逼近它——这让我们更容易做出一个“快乐的、让人爱用”的产品。

Boris： 我大概还有两条建议，可能听起来有点“奇怪”，因为它们都跟“为模型构建”有关。

第一条是：不要为今天的模型构建，要为六个月后的模型构建。

这听起来有点反直觉，因为如果产品今天跑不通，就很难找到 PMF。但你还是应该这么做，否则你可能会花很多精力在“当下模型”的 PMF 上，然后很快被别人超车，因为他们在为下一个模型构建，而新模型几个月就来一次。

所以你要不断用模型，去摸清它能力的边界，然后为你认为“六个月后会出现的模型能力”做准备。

第二条建议是：在我们 Claude Code 团队的区域墙上，挂着一份 《The Bitter Lesson》 的装裱版。我觉得所有人都应该读这篇文章（作者是 Rich Sutton）。核心思想之一是：更通用的方法最终会赢过更特化的方法。推到极致，就是一句话：不要和模型对赌（never bet against the model）。

我们经常面临一个 trade-off：我们可以在 Claude Code 里加功能，让产品更好，这些非模型本体的代码我们叫 scaffolding（脚手架）；但我们也可以等几个月，新模型可能就能原生做到这些。

这个权衡一直存在：你现在投入工程精力，可能在某个能力维度上多拿到 10%～20% 的提升；或者你干脆等下一代模型，免费得到。所以要始终用这个 trade-off 来思考：你到底要在哪些地方投入？并且假设你做的 scaffolding 最终都会变成“技术债”。

Boris： 太多了。Claude Code 几乎就是写了又写、改了又改、重写了无数次。我们每隔几周就会下掉一些工具（unship），也会每隔几周加新工具。

六个月前存在的代码，现在几乎没有任何一部分还保留着——它一直在被重写。

Boris： 对，肯定。甚至可能更短。几个月这个感觉挺准确的。

Diana： 这也是另一个“alpha”：代码的 shelf life 可能只有几个月，顶尖的创始人应该预期这种生命周期。

Boris： 内部确实是这样。如果看技术员工，大家每天都用 Claude Code，甚至非技术员工也在用——我觉得销售团队里大概有一半人在用 Claude Code。他们后来开始转向 co-work，因为更容易用，而且有 VM，会更安全一点。

我们刚拉了个数据：团队去年规模翻倍，但“人均工程产出”大概涨了 70%。衡量方式很粗糙——就是 pull requests，但我们也会用 commits、以及 commit 的生命周期等指标交叉验证。

自从 Claude Code 推出后，Anthropic 的人均工程产出整体涨了 150%。

因为我以前在 Meta 负责代码质量，也负责跨多个产品线的代码库质量。当时我们做“提升生产力”，看到 2% 的提升，都可能需要几百人干一年。所以这种 100% 级别的提升，是完全没见过的，彻底闻所未闻。

Boris： 我当时住在日本乡下，每天早上刷 Hacker News。

后来某个时候开始，新闻全都是 AI。我开始用一些早期产品，记得第一次用的时候，真的有点“屏住呼吸”的感觉，说出来有点肉麻，但当时就是那种感觉：太惊艳了。那大概还是 Claude 2 的时代。

于是我开始跟 Labs 的朋友聊，看看他们在做什么。我认识了 Anthropic 的创始人之一 Ben Mann，他很快就说服了我。后来见到更多团队成员，也同样打动我，大概是两点：

第一，它真的像一个研究实验室在运转。产品本身非常小，核心只有一件事：把安全模型做出来。 离模型更近、离研发更近、产品不是最重要的——模型才是最重要的。这对我这种做了很多年产品的人来说，非常共鸣。

第二点是它的 mission-driven（这里的 mission 指：确保 AI 安全发展，避免灾难性后果）。我是重度科幻读者，书架全是科幻。我很清楚这件事最坏情况下会有多糟。我在想今年会发生什么时，我觉得会非常疯狂；在最坏情况下，它也可能非常非常糟。所以我想在一个真正理解这一点、真正把它内化的地方工作。

在 Anthropic，你在食堂、走廊里听到的对话，大家都在聊 AI safety，这就是所有人最关心的东西。我很想待在这样的地方。对我个人来说，这个 mission 太重要了。

Boris： 如果你回想六个月前大家做的预测，Dario 预测过：Anthropic 里 90% 的代码会由 Claude 写。这个预测是真的。

对我个人来说，自从 Opus 4.5 之后基本就是 100%：我把 IDE 都卸了，我不再手写任何一行代码，全都用 Claude Code 和 Opus。 我每天能落 20 个 PR。如果看 Anthropic 整体，不同团队在 70%～90% 之间浮动；很多团队、很多人其实也是 100%。

我记得今年 5 月我们发布 Claude Code 时，我还做过一个预测：以后写代码不需要 IDE 了。当时听起来特别离谱，我感觉台下都倒吸一口气，因为太夸张了。但其实你只要沿着指数曲线去推，这就是会发生的事情。

我们公司 DNA 里就有这条——因为我们的三位创始人是 scaling laws 那篇论文的共同作者，他们很早就看到这条曲线。所以这不是玄学，就是沿着指数走下去，而它确实发生了。

Boris： 继续沿着这条指数往前推，我觉得编程会逐渐对每个人都“被解决”。

今天对我来说基本已经解决了；我认为以后对所有人都会如此，不管是什么领域。我们会开始看到 “软件工程师”这个头衔慢慢消失。可能会变成 builder、product manager，或者头衔还保留，但只是一个遗留符号。因为大家做的工作不再只是写代码：软件工程师还会写 spec、还会跟用户沟通。

我们团队现在已经出现这种趋势：工程师是通才，每个职能都在写代码——PM 写、设计师写、EM 写、甚至我们的 finance 同事也写。未来你会在更多地方看到这一幕。

这算是沿趋势推演得到的“下限”。但“上限”更吓人。

比如我们提到 ASL4 在 Anthropic 我们有这些安全等级：ASL3 是目前模型所处的位置；ASL4 是模型具备递归自我改进能力。如果走到那一步，我们必须满足一堆条件才能发布模型。

最极端的情况，是出现递归自改；或者出现灾难性滥用，比如用模型设计生物病毒、设计 zero-day 等等。这些都是我们现在非常非常认真在防的事情，确保它不要发生。

我看到大家用 Claude Code 的方式，真的很震撼。我最初只是想做个酷东西，结果它变得这么有用，这既意外、又兴奋。

Boris：其实 12 月我一直在旅行，我给自己放了个“coding vacation”。到处走，但每天都在写代码，这种感觉还挺好。那段时间我也开始用 Twitter，因为我以前做过 Threads，所以我一直是 Threads 用户，我就想看看大家都在哪个平台活跃。

我觉得很多人就是在那时发现了 Opus 4.5。我其实早就知道 Opus 4.5 的能力了。内部这几个月 Claude Code 一直在指数式增长，所以假期之后曲线只是变得更陡了。

现在你看外部也有各种数据：比如 Mercury 说有 70% 的创业公司选择 Claude 作为首选模型；还有 SemiAnalysis 之类的数据说，公开 commits 里有 4% 是 Claude Code 产生的。

大公司用、小公司也用。甚至它还参与了 Perseverance（火星车）的航线规划，这对我来说太酷了。我们团队还专门印了海报，因为大家觉得“NASA 选择用这个东西”实在太酷了。但也感觉这才刚开始。

Boris： 我这大概是第五次用 “latent demand”（潜在需求） 这个词了（笑）。

我们当时看 Twitter：有人用 Claude Code 去监测番茄植物；有人用它从损坏硬盘里恢复婚礼照片；有人用它做金融相关的事情。

回到 Anthropic 内部：每个设计师都在用；整个财务团队都在用；数据科学团队也在用，但他们用它并不是为了写代码。很多人为了用它，愿意去折腾半天，在终端里安装一个东西。

我们很早就知道我们要做点什么，于是试了很多想法，最后真正“起势”的，就是桌面端 app 里那个简单的 GUI wrapper——本质就是 Claude Code 的外壳而已。底层还是同一个 agent，完全是 Claude Code。

Felix 是早期的重要贡献者，他很熟那套技术栈。当时他们在试各种想法，最后大概 10 天就把它做出来了，而且几乎 100% 都是 Claude Code 写的。 我们觉得它已经到了可以发布的状态。

当然，为非技术用户要补很多东西：它会在虚拟机里运行；有很多删除保护；有很多权限提示和 guardrails。整体来说，这条路其实挺明显的。

参考链接：

https://www.youtube.com/watch?v=PQU9o_5rHC4