主持人：你会不会考虑根据一个候选人”使用 Claude Code 跟代理一起做功能”的转写记录来做招聘判断？我们现在正在这么做。我们最近加了一个小实验：你可以上传一段你用 Claude Code 或 Codex（或者别的工具）做一个功能的完整转写。Boris：我个人感觉这会行。你能看出来一个人怎么思考：比如他会不会去看日志；代理跑偏时他能不能把它拉回来；他会不会用 plan mode；他用 plan mode 时会不会确保有测试；以及各种类似的东西。你还可以看出来他有没有系统思维、懂不懂系统。这里面包含的信息太多了。我甚至想要一个”蜘蛛网图”（像 NBA 2K 里那种能力雷达图）：比如这个人投篮强、防守强……你可以想象做一个”Claude Code 技能水平”的雷达图。主持人：那这些技能维度会是什么？Boris：我觉得会有：系统、测试、用户行为……肯定还有设计部分、产品感觉（product sense），也可能包括自动化能力之类的。主持人：我在我的 CLAUDE.md 里最喜欢的一条是：对每一个 plan，都要判断它是”过度工程”（overengineered）、”不足工程”（underengineered）、还是”刚刚好”（perfectly engineered），并说明为什么。
极端专家 vs 超级通才
Boris：我觉得这也是我们在摸索的东西。因为当我看团队里最有效率的工程师时，会发现一种很明显的两极分化（bimodal）。一类是极端专家。我刚提到 Jared 是很典型的例子。像 Bun 团队那种也很典型——他们对开发工具的理解无人能及，对 JavaScript 运行时系统的理解无人能及。另一类则更像”超级通才”，大概是团队里剩下的人。很多人会跨产品和基础设施（product + infra），或者产品和设计（product + design），或者产品和用户研究、产品和业务。我很喜欢看到那些会做”怪事”（weird stuff）的人。过去这可能是个风险信号：你会担心他们到底能不能做出有用的东西，这是个极限测试。但现在我反而觉得它很有价值。Boris：比如我们团队有个工程师 Daisy。她原本在别的团队，后来转到我们团队。我之所以特别想让她转过来，是因为她加入后没多久就给 Claude Code 提了一个 PR：这个 PR 是加一个新功能。但她不是直接把功能加上去。她先提了一个 PR：给 Claude Code 加一个工具，让它能够”测试任意工具并验证它能用”。她把这个 PR 合进去之后，又让 Claude Code 自己去写它自己的工具，而不是她自己实现。我觉得这种跳出常规的思路非常有趣，因为现在还没有很多人真正理解这种做事方式。Boris：我们在内部用一套 agents SDK，把开发的几乎每个部分都自动化了：它做 code review、安全 review；给 issue 打标签；把东西 shepherd 到生产；几乎什么都做。但我也看到外部开始有人慢慢摸到这个门道。不过确实花了些时间：人们还在学习怎么以这种方式使用 LLM，怎么用这种新的自动化方式工作——这是一种新技能。
愿景型创始人”开挂”，团队协作的新张力
主持人：我最近跟一些创始人聊时，遇到一个挺好笑的模式：有一种”愿景型创始人”，他脑子里已经建好了一座水晶宫——产品要做成什么样、用户是谁、用户感受如何、动机是什么，全都装在脑子里。然后他坐在 Claude Code 前面，能做出 50 倍的工作量。但他手下的工程师没有那座”记忆水晶宫”（对产品的柏拉图式理想形态没完全内化），所以他们可能只能做到 5 倍。你有听过类似的故事吗？好像团队里常常会有一个核心的”设计者”，在把东西从脑子里”轰出来”。这种团队结构看上去像一种稳定态：愿景型的人现在被解放了，但其他人未必跟得上。你怎么看？Boris：这其实跟我现在的一些体验也很像。我会想：”我只是一个人，我要吃饭睡觉，我还有一份工作——我怎么做得完？”我们刚发布了 Claude Teams，这是一种方式；但你也完全可以自己搭一套方式，其实挺容易的。主持人：那你对 Claude Teams 的愿景是什么？
Claude Teams 的愿景：代理拓扑与”互不相关上下文窗口”
Boris：就是协作。现在有一个全新的领域在探索”代理拓扑”（agent topologies）：你可以用哪些方式去配置代理？其中一个子想法叫”互不相关的上下文窗口”（uncorrelated context windows）。意思是你让多个代理各自拥有全新的上下文窗口——不会被彼此的上下文污染，也不会被它们自己之前的上下文污染。你给一个问题投入更多上下文，本身就有点像一种”测试时算力”（test-time compute）：你会因此得到更多能力。然后如果你在这之上再叠加一个正确的拓扑结构——让代理以正确的方式沟通、以正确的方式排列——它们就能做更大的东西。Teams 只是其中一个想法。我们很快还会有更多。核心就是：也许它可以构建更大一点的东西。Boris：第一个比较大的、让我觉得”这个真的行”的例子，是我们的 plugins 功能：它完全是一个 swarm 在一个周末里做出来的。它跑了好几天，几乎没有人类介入。plugins 上线时的形态，基本就跟它第一次做出来时差不多。主持人：你们是怎么把它设置成那样的？你们先把想要的结果规格写出来，然后让它自己搞细节、自己跑起来吗？就这样让它跑？Boris：对。团队里有个工程师给了 Claude 一个 spec，然后让 Claude 用一个 Asana 看板。Claude 就在 Asana 里建了一堆任务，然后生成了一堆代理，代理开始认领任务。主 Claude（我们内部叫它”主 agent”）给它们指令，然后它们就像独立的代理一样把事情做完——这些子代理并没有更大 spec 的完整上下文。主持人：对，对。它们没有”大 spec”的上下文。Boris：如果你看现在我们的代理是怎么启动的——我还没拉过数据，但我敢打赌：今天绝大多数代理其实都是被 Claude 自己提示出来的，形式就是子代理（subagents）。因为子代理在代码里本质上就是一个”递归的 Claude Code”，就这么简单。它只是被我们叫做”妈妈 Claude”（mama Claude）的那个主 agent 提示出来的，仅此而已。我猜如果你看大多数代理，它们就是这样被启动的。
子代理（Subagents）与并行调试
Boris：我的 Claude Insights 最近也一直提醒我：调试时应该更多用这一套，因为我花很多时间在调试上。更好的方式是让多个子代理并行起来一起 debug。所以我就加了一条：下次你修 bug 的时候，让一个代理去看日志，让一个代理去看代码路径之类的。这看起来几乎是必然会发生的。主持人：遇到那种又怪又吓人的 bug，我也会尽量在 plan mode 里修，然后它好像会用代理把整个面都搜一遍。相对地，如果你只在普通模式里做，它就像是只做一个任务，而不是”广搜”。Boris：我也一直这么做。如果测试看起来很难、是那种需要研究的测试，我会根据任务难度去校准我让它开多少个子代理。比如如果特别难，我会说：用三个、或者五个、甚至十个子代理，并行研究，然后看看它们各自得出什么结论。主持人：那我好奇，你为什么不把这种”按难度开 N 个子代理”的规则也写进你的 CLAUDE.md？Boris：这有点 case by case。你知道，CLAUDE.md 是什么？它就是个快捷方式：如果你发现你自己在重复同一句话、重复同一个要求，你就把它写进 CLAUDE.md；但否则，你不需要把一切都写进去。你可以直接当场 prompt 它。
Plan Mode 可能不需要了？没有 Plan Mode 的世界会怎样？
主持人：你脑子里会不会也在想：也许六个月后，你都不需要明确去提示这些东西了？模型会强到可以自己想出来？Boris：也许一个月后就不用了。一个月后就不需要 plan mode 了。我的天。我觉得 plan mode 可能确实会有一个有限的生命周期。主持人：这对大家来说算是个很劲爆的信息了。那如果没有 plan mode，世界会是什么样？你只要在提示词层面描述一下，它就能一把梭、一次性做完？Boris：对。我们已经开始做实验，因为 Claude Code 现在已经可以自己进入 plan mode 了。我不知道你们有没有见过。所以我们在尝试把这个体验做得真正好：它会在”一个人类也会希望进入 plan mode 的那个时刻”自动进入 plan mode。但说到底，plan mode 没什么大秘密：它只是往提示词里加了一句话——”请不要写代码”。就这么一句。你其实自己也可以直接这么说。主持人：听起来 Claude Code 的很多功能开发，真的就是 YC 那套”去跟用户聊”，然后你回来实现；而不是你先有一个宏伟的主计划，再把功能一个个实现出来。Boris：对，对。plan mode 就是这样来的：我们看到用户经常会说，”Claude，先想一个方案，把它规划出来，但先别写代码。”这种说法有很多版本：有时候他们只是想把一个想法聊清楚；有时候他们会让 Claude 写一个非常复杂的规格说明。但共同点是：先做一件事，但暂时不要写代码。所以那就是一个周日晚上十点——我在刷 GitHub issues，看大家在讨论什么，也看我们内部 Slack 的反馈频道。我大概 30 分钟就把它写出来了，然后当晚就发版。周一早上它就上线了。这就是 plan mode。主持人：所以你的意思是，未来不需要 plan mode，是指”我不再担心模型会做错、会跑偏”？但你仍然需要一个地方去把想法想清楚、把要做的东西定义清楚，对吧？这件事总得发生在某个地方。Boris：对。我会把它放在”能力提升的阶段”里理解。比如六个月前，光有一个 plan 还不够，所以你让 Claude 写一个 plan。就算在 plan mode 里，你可能也得一直盯着，因为它会跑偏。但现在我做事的方式是：我大概 80% 的 session 都从 plan mode 开始。虽然我说 plan mode 生命周期可能有限，但我其实是重度 plan mode 用户。大概 80% 的时候，我一打开就先让 Claude 写计划。然后我会切到第二个终端标签页，让另一个也开始写计划；等标签页不够了，我就打开桌面应用，去 code tab，再开一堆标签页——它们也都从 plan mode 开始。计划写得差不多之后（有时候需要来回调几次），我就让 Claude 去执行。Boris：现在我发现，用 Opus 4.5 ——我觉得从 4.6 开始它就变得非常好——只要 plan 足够好，它几乎每次都会一直沿着轨道走下去，把事情做对。所以以前你在 plan 之前要 babysit、plan 之后也要 babysit；现在基本只需要在 plan 之前 babysit。下一步也许就是：你根本不需要 babysit 了。你给一个 prompt，Claude 自己就能搞清楚并完成。主持人：再下一步就是 Claude 直接跟你的用户对话了。Boris：对，它直接绕过你，跳过你这个人了。很有意思的是，这其实就是我们现在在做的事情：我们的 Claude 之间会互相交流；至少在内部，它们也经常在 Slack 上跟我们的用户交流。我的 Claude 偶尔还会想发推文。主持人：不会吧。Boris：会，但我一般会删掉。我觉得有点尬，我不太喜欢那个语气。主持人：它想发什么？Boris：有时候它会想回复某个人，因为我经常在后台开着 co-work。co-work 特别爱这么干，因为它喜欢用浏览器。主持人：这太好笑了。Boris：还有一个很常见的模式是：我让 Claude 构建某个东西，它会去看代码库，然后看到某段代码是谁改过（通过 git blame），它就会直接在 Slack 上私聊那个工程师问澄清问题。等它收到回复，它就继续往下做。
给创始人的建议：在变化中什么会不变？
主持人：那你现在对创始人有什么建议，帮助他们面向未来构建？听起来一切都在变化。有哪些原则会一直成立？哪些会改变？Boris：我觉得有些建议很基础，但现在比以前更重要。一个例子就是我提过很多次的”潜在需求”（latent demand）。对我来说，这是产品里最重要的一个概念。几乎没人真正理解它——我自己在前几次创业时也完全不理解。它的意思是：人们只会去做他们本来就在做的事情。你很难让人去做一件全新的事情。如果人们正在努力做某件事，而你让那件事更容易，那通常是个好主意；但如果人们正在做一件事，而你试图让他们改做另一件事，他们通常不会这么做。所以你要做的，是让他们本来就想做的那件事更容易。Boris：我也觉得 Claude 会越来越擅长替你发现这类产品机会：因为它可以看反馈、看 debug 日志，然后把东西推出来。主持人：所以你说 plan mode 也是一种”潜在需求”：人们本来就会在浏览器里开个 Claude 聊天窗口，跟它一起把 spec 和要做的东西聊清楚；而 plan mode 只是把这件事搬进 Claude Code 里。Boris：对，对，就是这样。我有时候会在办公室里到处走走，在我们那层楼转一圈，站在别人背后看看他们怎么用 Claude Code。我会先打个招呼，免得太怪。然后我就观察他们的用法。这件事我在 GitHub issues 里也看到很多人在聊。
终端还能活多久？会不会需要新 UI？
主持人：你之前说你很意外终端被推到了这么远。那在这个多代理的世界里，你觉得终端还剩多少”寿命”？会不会需要一个完全不同的 UI 在它之上？Boris：很有意思：如果你一年前问我，我会说终端只有三个月寿命，然后我们就会转向下一个东西。但你也能看到我们一直在实验不同形态：Claude Code 从终端起步，但现在它也在 web 上；也在桌面应用里（比如 code tab）；也在 iOS 和 Android 的 code tab 里；也在 Slack、在 GitHub；还有 VS Code 插件、JetBrains 插件。我们一直在实验各种 form factor，去找”下一步是什么”。我对 CLI 的预测到目前为止一直都错，所以我可能不是预测这个的人。
Boris：我觉得还有一件挺酷的事，很多人可能不知道：这个终端应用在同类里其实算很好看的之一，而且它是用 React 的终端渲染方式写的。我最开始做它的时候，我以前做过一段时间前端；而且我也算是混合型的人：我会做设计、做用户研究、写代码这些。我们也很喜欢招这种工程师——我们很喜欢通才（generalists）。Boris：所以对我来说问题是：我在为终端做一个东西，但我其实 Vim 用得挺烂的。那我怎么给像我这样的人做一个终端里的产品？我觉得”愉悦感”（delight）非常重要。YC 也经常讲”做一个人们会爱上的产品”。产品有用但没人爱它，也不够好。所以它得两者兼具。Boris：但说实话，为终端做设计很难：大概就 80×100 个字符左右的空间；你只有 256 色；你只有一种字号；你没有鼠标交互——有很多事情做不了，而且都是很难的权衡。比如一个不太为人知的点是：终端其实可以启用鼠标交互，你可以支持点击之类的。主持人：那在 Claude Code 里怎么启用？我一直想搞清楚。Boris：我们在 Claude Code 里没有做，因为我们确实原型过几次，体验很差。你要支持鼠标，代价之一是你得把滚动虚拟化（virtualize scrolling），然后就会出现一堆很怪的权衡。因为终端的工作方式里没有 DOM；它是 ANSI escape code 那套东西，是从六十年代一路有机演化出来的各种规范。主持人：对，这感觉像 BBS，一种 BBS 的门游（door game）。Boris：天啊，这评价太棒了。它就应该有那种”你在发现《红龙之王》（Lord of the Red Dragon）”的感觉。Boris：但我们确实不得不自己摸索出很多”终端 UX 原则”，因为几乎没人写这些东西。你看八九十年代、两千年前后的大型终端应用，它们用 curses，做很多窗口分割之类的东西，以现代审美看会显得很”糙”、很重、很复杂。所以我们得重做很多东西。Boris：举个例子：终端里的那个 spinner（加载转圈/状态提示），光是”spinner 的文字和呈现方式”，我们大概迭代了 50 次、甚至 100 次；其中可能 80% 都没上线。我们不断试：不舒服就换，下一个；不舒服就换，下一个。而 Claude Code 让这种迭代变得太快了：你可以连续做 20 个原型，看看哪个最好，然后就上线——可能只要几个小时。以前你可能得用 Origami、Framer 之类的工具，做三版原型都要两周，慢太多了。Boris：所以我们现在有一种”奢侈”：我们要去发现一种新的东西，我们要去做一个产品，我们并不知道正确终点是什么，但我们可以很快迭代到那里——这让它变得容易，也让我们能做出一种”用起来很快乐”的产品。
对构建者的另外两条建议
主持人：Boris，你刚才其实还有一些对构建者的建议，但我们一直打断你，因为问题太多了。你继续。Boris：好。可能有两条建议有点”怪”，因为它们都跟”为模型而建”有关。Boris：第一条是：不要为今天的模型造产品，要为六个月后的模型造产品。这听起来很怪，因为如果产品今天不好用，你找不到 PMF。但你仍然应该这么做，因为否则你会发生什么？你会投入大量工作，为”当下的产品形态”找到 PMF，然后你会被别人直接跨代超车——因为对方是为下一代模型在建，而新模型每几个月就来一次。所以你要去用模型，去摸清它能力的边界，然后为你认为”六个月后的模型”会具备的能力来建。Boris：第二条是：在我们坐的 Claude Code 区域，墙上裱着一份《The Bitter Lesson》（苦涩的教训）。作者是 Rich Sutton。我觉得每个人都应该读一读。它的核心想法是：更通用的方法最终会胜过更专用的方法。这里有很多推论，但归根结底就是一句：永远不要和模型对赌（never bet against the model）。在 Claude Code 里，我们经常面对一个选择：我们可以在产品里加一个功能，让它更好用——我们把这类”模型之外的代码”叫做 scaffolding（脚手架）。但我们也可以等几个月，因为下一代模型可能就能直接做到那件事。这总是一个权衡：要么现在做工程投入，把某个维度能力扩展一点（可能 10%～20%），要么就等下一代模型。你需要一直用这种方式思考：你到底该把工程力投在什么地方？并且假设你写的脚手架最终都会变成技术债。
Claude Code 重写频率与”脚手架淘汰”
主持人：那你们多久会重写一次？比如每六个月？有没有那种你们以前做过的脚手架，后来因为模型变强了就删掉、不需要了？Boris：太多了。Claude Code 的全部代码一直在被重写、重写、再重写。我们每隔几周就会把一些工具下线（unship），也每隔几周就会上线一些新工具。现在的 Claude Code 里，没有任何一部分是六个月前还在的——它就是持续不断地重写。主持人：那你会说现在代码库里，比如 80% 的代码，其实都不到几个月大？Boris：对，绝对是。甚至可能更少。两个月左右的感觉差不多。主持人：所以现在代码的生命周期就是这样了：你要预期它的”保质期”可能就几个月。Boris：对。
生产力、采用率与数据
主持人：你有看到 Steve Yaggi（转写可能有误）的那篇文章吗？他写了在 Anthropic 工作有多爽。我记得里面有一句话，说一个 Anthropic 工程师现在的平均生产力，大概是 Google 巅峰时期工程师的 1000 倍——这个数字太离谱了。1000 倍啊。三年前我们还在说 10x 工程师，现在是在说 1000x，还是相对于”巅峰期的 Google 工程师”。太不可思议了。Boris：是的。内部如果你看技术员工，他们每天都在用 Claude Code。甚至非技术员工——我觉得销售团队里可能有一半人在用。后来他们也开始转去用 co-work，因为 co-work 更容易用一些，而且它有一个 VM（虚拟机），所以更安全。我们确实拉过一个统计：去年团队规模翻了一倍，但人均生产力大概增长了 70%。我们用的是最简单、最”傻”的指标：PR 数量。但我们也会交叉验证：比如 commit、以及 commit 的生命周期之类的指标。自从 Claude Code 出来之后，Anthropic 的人均生产力增长了 150%。主持人：我的天。Boris：这真的很疯狂，因为我以前在 Meta 的工作之一就是负责代码质量；我负责过跨所有产品（Facebook、Instagram、WhatsApp 等）的代码库质量。我们团队也做过”提升生产力”的项目。在那种环境里，如果你能看到 2% 的生产力提升，那往往是几百人干一年才换来的结果。所以现在这种 100% 量级的提升，完全是前所未有的。
Boris 为什么加入 Anthropic
主持人：是什么驱使你来 Anthropic 的？你作为一个构建者，理论上可以去任何地方。是什么时刻让你觉得”就是这群人/这条路”？Boris：当时我住在日本的乡下。每天早上我会打开 Hacker News 看新闻。某个时刻开始，新闻全都是 AI 相关。我也开始用一些早期产品。我记得我第一次、第二次用它们的时候，那种感觉是——它真的让我屏住呼吸。说出来有点肉麻，但那就是当时的真实感受：作为一个构建者，我从来没感受过那样的体验。那大概是在”Claude 2″时代前后，差不多就是那个时期。然后我就开始跟在 Labs 的朋友聊，想看看里面到底在发生什么。后来我认识了 Ben Mann（Anthropic 的联合创始人之一），他几乎是立刻就打动了我。之后我又见了团队里更多人，也被打动了。我觉得大概有两点原因。Boris：第一，Anthropic 的运作方式非常像一个研究实验室：产品本身非常非常小，核心是构建一个安全的模型——那才是最重要的。产品不再是最重要的，模型才是最重要的。这种”非常贴近模型、贴近研发”的感觉，在我做了很多年产品之后特别能共鸣。Boris：第二，是它的使命感（mission-driven）。我自己是个重度科幻读者，我的书架几乎全是科幻。我知道这件事可能会变得有多糟。当我去想”今年会发生什么”的时候，我觉得会非常疯狂；而在最坏情况下，它可能会变得非常非常糟。所以我想待在一个真正理解这一点、并且把它内化到组织里的人们身边。在 Anthropic，你在食堂、走廊里听到别人聊天，大家谈的都是 AI safety——这是每个人最关心的事，比其他都重要。对我个人来说，这个使命感非常重要。
今年会发生什么？编码工作与安全上界
主持人：那今年会发生什么？Boris：如果你回看六个月前大家的预测——比如 Dario 预测 Anthropic 90% 的代码会由 Claude（这里指 Claude Code）来写——这已经成真了。对我个人来说，自从 Opus 4.5 之后就是 100%：我把 IDE 都卸载了，我不再手动编辑任何一行代码，完全就是 Claude Code + Opus。我每天能落地大概 20 个 PR。你看 Anthropic 整体，不同团队在 70% 到 90% 之间；很多团队很多人也是 100%。Boris：记得我在 5 月份我们发布 Claude Code 的时候做过一个预测：你将不再需要 IDE 来写代码。当时我说出来很离谱，我感觉台下的人都倒吸一口凉气，因为那在当时听起来太傻了。但本质上你只是在沿着指数曲线推演。这种”沿着指数推演”的思维，在 Anthropic 很深入：你知道我们三个创始人参与过 scaling laws 的论文，所以他们很早就看到这种趋势。所以继续沿着指数往前推，我认为会发生的事是：对所有人来说，编码会被”基本解决”。今天对我来说几乎已经解决了，我觉得很快对所有人、各种领域都会成立。Boris：然后我们会开始看到”软件工程师”这个头衔逐渐消失。也许会变成 builder，或者产品经理；也许这个头衔会以一种”残余器官”（vestigial）的形式保留下来，但人们实际做的工作不会只是写代码。软件工程师也会写规格、会跟用户对话。就像我们团队现在正在发生的事：工程师更像通才，而且我们团队每个职能都在写代码——PM 写代码，设计师写代码，EM 写代码，我们甚至财务同事也写代码——所有人都写代码。我们会在更多地方看到这种情况。Boris：这算是沿着趋势推演的”下界”。而我觉得”上界”要可怕得多。比如我们会触及 ASL4。我们在 Anthropic 讨论这些安全等级：ASL3 大概是现在模型所在的位置；ASL4 是指模型能够递归自我改进（recursively self-improving）。如果到了那一步，我们在发布模型前就必须满足一系列标准与条件。更极端的情况是：要么出现这种能力，要么出现灾难性的滥用——比如人们用模型设计生物病毒、设计 0day 漏洞之类的。这也是我们正在非常、非常投入去避免的事情。Boris：总之，看人们怎么用 Claude Code 真的既兴奋又让人谦卑。我当初只是想做一个酷东西，结果它变得非常有用，这既意外又令人兴奋。
假期后爆发、外部采用与”仍然只是开始”
主持人：我从推特、从外部看到的感觉是：大家假期一走开，然后回来突然发现 Claude Code，于是一切就疯狂了。你们内部也是这样吗？你是不是也在过圣诞假期，回来之后发现”发生了什么”？Boris：其实 12 月我一直在旅行。我算是搞了一个”coding vacation”：一边旅行一边每天写代码，所以挺爽的。那时我也开始用 Twitter（因为我以前在 Threads 工作过，所以我一直是 Threads 用户），我就想看看大家都在哪个平台上。我觉得对很多人来说，那时他们发现的是 Opus 4.5。我其实更早就知道了。而在内部，Claude Code 已经以指数级的速度增长了很多个月了，所以那时只是变得更陡峭，我们看到的是这种变化。Boris：如果你看现在 Claude Code 的情况，有人说 Mercury 的一个统计是：70% 的创业公司把 Claude 当作首选模型。还有 SemiAnalysis 的某个统计说：公开 commit 里有 4% 是由 Claude Code 生成的——就像”全世界写出来的代码”里的一部分。大公司、小公司都在用。甚至有人说它帮 Perseverance（火星车）规划过路线之类的——对我来说这太酷了。我们团队甚至还印了海报，因为大家觉得”NASA 选择用这个东西”实在太酷了。所以这很让人谦卑，但同时也感觉这只是个开始。
Claude Code 与 co-work：起源与去向
主持人：那 Claude Code 和 co-work 的关系是什么？它是 Claude Code 的一个 fork 吗？还是说你们让 Claude Code 看 Claude Code，然后给非技术用户写一个新 spec，把经验保留下来，然后它自己跑几天做出了一个新东西？它的起源是什么？你觉得它会往哪走？Boris：我这已经是第五次用”潜在需求”这个词了——它就是潜在需求。我们在 Twitter 上看到有人用 Claude Code 去监控番茄植株；有人用它从损坏的硬盘里找回婚礼照片；有人拿它做金融相关的事情。在 Anthropic 内部，我们看到每个设计师都在用；整个财务团队都在用；整个数据科学团队也在用——而且不是为了写代码。人们为了用它，愿意跨很多安装门槛，去终端里装一个东西。所以我们早就知道我们想做点什么，我们也尝试了很多不同的想法。最后真正起势的，是在桌面应用里做了一个小小的”图形界面封装”（GUI wrapper）——本质上就这些。Boris：它底下还是 Claude Code。它就是同一个 agent。主持人：哇。Boris：Felix 和团队把它做出来了。Felix 早期就参与过 Electron 的贡献，他对那套技术栈很熟。他一直在试各种想法，然后他们大概用十天就做出来了——而且基本是 100% 由 Claude Code 写出来的。做完之后就感觉已经可以发布。当然，为非技术用户我们还做了不少东西，所以它跟面向技术用户会有点不同：比如所有代码都运行在虚拟机里；对删除操作有很多保护；权限提示（permission prompting）和其他护栏也更多。总体上它的出现其实挺”显然”的。
夜雨聆风
