与 Boris Cherny 聊 Claude Code 是怎么造出来的

无论你是使用编程助手，还是通过 agent workflow 进行规模化开发，Sonar 都能提供自动化验证——75% 的 Fortune 100 企业都依赖它。它让开发者能够自由创新，不必担心破坏代码库。访问 sonarsource.com/pragmatic，了解更多关于 Sonar 如何让你有信心以 AI 的速度进行开发。说完这个，让我们回到 Boris 的职业生涯，以及他在创业公司学到的经验。

我的第一份工作，我想应该是 16 岁那年。我当时就想买一把电吉他。于是我就开始接自由职业的项目。我想，好吧，那我大概可以做网站。那时候 Fiverr 应该还不存在，所以有一些别的自由职业网站。我就建了个网站，开始竞标项目。第一笔薪水我全拿去买了电吉他。但这其实很务实，对吧？因为在这种模式下，你既要搞工程，又要做账，又要做设计，还得跟客户沟通。所以我一直都是这样的。

在经历了这几家创业公司之后，你最终去了 Facebook，现在叫 Meta。你在那里待了 7 年。能给我们讲讲你在那里做了什么、学到了什么吗？你的职业发展也非常瞩目，7 年内晋升了四次。这段经历给你带来了什么？

是的，我最初做的是 Facebook groups。那是 Vlad Kolesnikov 招我进去的，我想他其实还在 Facebook，只不过现在在某个别的团队。那其实挺酷的。当时跟我一起合作的有一大群人，都是早期搞 JavaScript 的。我也做了很多 JavaScript 相关的事，有趣的是我一直跟这些人有交集。Vlad 做过 Bolt JS，就是支撑 Ads Manager 的那个框架，后来演变成了 React JS。

我一直跟这些人有交集，后来还有更多这样的人。但总之，我当时在做 Facebook groups。我对这个特别兴奋，是因为它有连接人们与社区的使命，这正是吸引我的地方。那时候我也是 Reddit 的重度用户。我从十几岁就开始用 Reddit，因为我不认识其他会编程的人。甚至到了大学，我也不太认识会编程的人。说实话，我一直对此有点难为情，因为我觉得这是很宅的事。我会这个，但又想做个酷小孩，所以没法跟人说我写代码。

太宅了。后来有一天我在 Reddit 上发现了一个编程社区，我简直震惊了。原来还有其他人也喜欢这个。这爱好多奇怪，多小众啊。能找到志同道合的人、获得这种联结，让我特别兴奋。所以我就想做这个，想以某种方式为此出一份力。于是我在 Facebook groups 做了一段时间。然后还有一堆别的项目，如果你感兴趣我可以细说。最终我成了 Facebook groups 的 tech lead。逐渐成长起来，工作范围也变大了。

工作重心从搭建系统变成了大量写文档、协调和委派给别人。当时文化也在变。Facebook 早期的那种文化正在消失。文档越来越多，对齐会议也越来越多。在隐私、安全这类基础工作上的投入大了很多。说实话，早期为了增长确实走了很多捷径，但到某个阶段你就得还这笔债。

那件事就是那时候发生的。之后我在 Instagram 待了几年。那也是个有趣的故事。我妻子收到了一份工作邀请，她特别兴奋，过来跟我说：“嘿，我拿到了这个 offer，但我们要搬家，可以吗？”我说：“行啊，没问题，你知道的，我做科技行业，在哪儿都能远程办公。工作在哪儿？”她说：“在奈良。”我说：“奈良是哪儿？”奈良就是日本的乡下。那时候——

时差不一样，对吧。

差了大概 12 个小时之类的。

大概是那样，没错。那是 2021 年左右。

哇。

然后我试着找一个愿意接收我的团队，因为人力资源那边有些很古怪的规定，比如你所在的时区、必须和团队同地办公之类的。当时东京有一个刚起步的小团队，是 Instagram 在那边的分支。Will Bailey 带这个团队，他也是做了 Instagram Stories 的人。所以他有一段时间是我的经理。我们决定一起壮大这个团队，我在奈良远程办公，团队大部分人在东京。那段时间我在 Instagram 上折腾东西，技术栈简直让人抓狂。

Facebook 拥有全世界最好的 Web 服务技术栈，从 Hack 语言到 HHVM 运行时，再到 GraphQL 作为传输层，还有 Relay 这些客户端库，所有东西都被优化到了极致，再加上 React，太惊艳了。全世界没有比这更好的开发栈了，完全是高度优化的。结果我到了 Instagram，用的是 Python，类型检查器跑不通，点击跳转定义也跳不了。就是东拼西凑的 Django，再 fork 一个 CPython 运行时，基本上什么都不好用。

所以我到了 Instagram 之后，加入了在日本的 Labs 团队，初衷是给 Instagram 寻找下一个大机会。我们尝试了一些东西，但我很快意识到，在这个技术栈上干活效率太低了，因为它太烂了。于是我就去搞 Dev Infra，因为必须把它修好。我们做了几个项目，一个是把 Python 迁移到 Facebook 那个庞大的单体代码库里，另一个是把 Instagram 的 GraphQL 迁移过去。

这些项目其实都还在进行中，这种迁移需要几百个工程师花很多年才能完成，代码库很大，迁移量很大。

现在应该快多了吧。

对，有了我们现在这些 AI 工具，迁移简直是它们的绝佳应用场景。

没错，这简直是 AI 工具最理想的用武之地。

然后我就开始越陷越深。到我离开 Instagram 的时候，我一直在做 Dev Infra，还牵头了其中不少迁移项目。也是在那段时间我认识了 Fiona Fung，她现在是 Quad Code 团队的经理。我跟她共事过，她是一位非常出色的领导者，在技术领域有着极深的积淀和背景。我当时就觉得，没有比她更适合带这个团队的人了。后来我也开始涉足代码质量方面的工作，所以在 Instagram 的职责范围扩大了一些。

等我离职时，我已经在牵头整个 Meta 的代码质量工作了。我要对 Instagram、Facebook、Messenger、WhatsApp、Reality Labs 这些代码库的质量负责。Meta 内部有个项目叫 Better Engineering，我记得大概是 2016 或 2018 年启动的。Zuck 规定公司每个工程师必须用 20% 的时间来偿还技术债。

哦，有意思。

我们把它叫做 Better Engineering。

嗯。

其中一部分是自下而上的，毕竟团队最清楚自己有哪些技术债要还；另一部分则是自上而下的，比如需要做大型迁移，迁移到新的语言特性、新框架之类。以 Facebook 的体量，每年这类迁移就有成千上万个。于是我就牵头做这些，很快发现需要更有条理一些。当时没有目标，没人知道最终要达成什么结果，也没有追踪机制。所以我们开发了一套东西。其中一个想法是用集中化的方式来给各类代码质量工作排优先级；第二件事是弄清楚代码质量对工程效率的影响，结果发现影响非常显著。

你们怎么衡量的？发现了什么？

有很多方法。我觉得其中一些已经公开发表了，但不确定是不是全部。本质上我们是做因果分析和因果推断，这是方法论。你试图找出那些让工程师更高效的因素，有些是代码质量，有些则无关。比如 Meta 后来要求回办公室、不再居家办公，部分原因就是出于这个研究。因为我们发现了一些相当强的相关性，而且我们认为这是因果关系。

明白了。

关于这个，代码质量其实能给生产力带来两位数的百分比贡献，即便在最大规模下也是如此。

听到这个挺让人安心的，因为我觉得很少有地方真的会去度量这个，但我们都能感觉到。代码库干净、模块化，用起来就更顺手，而且我觉得对 LLM 来说可能也更容易处理，我的直觉是应该会更简单，对吧？只是目前数据很少，但这是我个人的感觉。

对，很多大公司都发表过这方面的研究，Facebook 发过，Microsoft 发了不少，Google 也有。不过完全同意。如果你每次做一个功能都要想，我到底用框架 X、Y 还是 Z？这些选项之所以都存在，是因为代码库处于部分迁移状态，各种框架的代码还散落在各处。作为工程师，你会很难受；作为新人，你也会很难受；作为模型，你可能会选错，然后用户就得来纠正你。所以实际上最好的办法就是始终保持代码库干净。一旦开始迁移，就要确保把它做完。这对工程师很好，到了现在，对模型来说也同样重要。

然后你加入了 Anthropic。我听过一个故事，你可以证实一下，或者多讲点细节——据说你的第一个 pull request 被 Adam Wolf 拒了。

他当时是我的 ramp up buddy。

所以我加入了 Anthropic。当时我在考虑接下来该做什么，见了各大实验室的很多人，而 Anthropic 对我来说是不二之选，因为它的使命。这是我个人最看重的东西。而且面对正在发生的所有这些变化，我们需要某种框架来思考这件事，思考我们在其中的角色。我还是个科幻小说迷，那绝对是我的最爱。我很爱读书，家里有一个巨大的书架什么的。我太清楚这事如果搞砸会有多糟。所以我觉得 Anthropic 是一个真正有严肃思考者的地方。

人们非常重视这件事，并思考我们能做些什么来让事情进展得更顺利。所以，当我加入 Anthropic 时，我做了一些上手项目，就是各种我在捣鼓的东西。我亲手写了我的第一个 pull request，因为我觉得代码就该这么写。过去确实是这样写代码的。但即便在当时的 Anthropic，也已经有一个叫 Claude 的东西了，它是 Claude code 的前身。它非常简陋，是用 Python 写的，启动要花 40 秒，属于研究性质的代码，并不具备 agentic 能力。

但如果你非常仔细地提示它，并且用对方法，它就能帮你写代码。于是，Adam 拒绝了我的 PR，他说：“其实，你应该用那个 Claude 工具来做。”我说：“好啊，酷。”我花了大概半天时间才搞明白怎么用这个工具，因为你得传入一堆参数，还要正确使用它。但之后它直接交出了一个能用的 PR，一次性就搞定了。哦，这大概是 2024 年，9 月或 8 月左右。我觉得对我来说，这是我在 Anthropic 第一次感受到 AI 的时刻。

我当时就想，天哪，我完全不知道模型能做到这个程度。我一直习惯了 IDE 里那种 tab 补全、行级别的补全。我完全没想到它能直接给我做出一个能用的 pull request。

刚才 War 提到他在工作中使用他们的 AI 模型时有过一次真正的“哇”时刻。另一种非常不同的“哇”时刻是，当你在工作中使用一个工具，它让事情变得前所未有的简单。这就自然引出了我们的赞助商 Statsig。Statsig 为工程团队提供实验和特性开关（feature flagging）工具，这类工具过去需要数年的内部开发才能建成。它复杂到只有 Meta 或 Uber 这样的大公司才有自己的定制化高级工具。

Statsig 的实际使用场景是这样的：你发布一个改动，先把它放在特性门（feature gate）后面，逐步灰度发布，比如先推送给 1% 或 10% 的用户。然后观察效果。不只是看有没有崩溃，而是看它对你关心的指标有什么影响：转化率、留存率、错误率、延迟。如果看起来有问题，你很快就能关掉；如果趋势向好，就继续推进。关键在于，度量是工作流的一部分。你不需要在三个工具之间切换，事后再去匹配用户分群和仪表盘。

特性开关、实验和分析都在同一个地方，使用相同的底层用户分组和数据。这就是为什么 Notion、Brex 和 Atlassian 等公司的团队都在使用 Statsig。Statsig 有慷慨的免费版可以入门，团队专业版定价每月 150 美元起。想了解更多并获取 30 天企业版试用，请访问 static.com/pragmatic。说完这些，让我们回到 Boris 和 Claude code 的起源故事。

**主持人**：是的，你加入 Anthropic 的时候，我们在一期深度访谈里聊过，但可以简单回顾一下 Claude code 是怎么诞生的，它最初看起来就像一个 side project 或者一个很酷的 hack。

**Boris**：是的，我一开始在捣鼓各种东西。我在做一些产品方面的工作。还短暂地做了强化学习，为了理解我所构建的东西下面的那一层。这至今是我给很多工程师的建议：永远要理解你下面那一层。这非常重要，因为它能给你深度，让你在实际工作的层面上有更多杠杆可以撬动。这是 10 年前的建议，今天依然适用。只是“下面那一层”现在有点不一样了。以前是说，如果你写 JavaScript，要去理解 JavaScript 虚拟机和框架之类的东西。现在则是要去理解模型。

所以我当时在捣鼓各种东西，有些发布了，有些没有。某个时候，我只是想了解一下 Anthropic 的公开 API，因为我从来没用过。我不想做 UI，只想快速 hack 点东西，因为当时还没有 Claude code，我们还在手写代码。我写了一个小小的 bash 工具，它做的就是调用 Anthropic API，本质上是一个基于聊天的应用，但跑在终端里，因为以前的 AI 就是这样。我现在仍然这么认为：工程师是最早的采纳者。

所以当我们从对话式 AI 转向 agentic AI 时，花了一点时间，但工程师们很快就理解了。我觉得现在如果你问非工程师 AI 是什么，他们会说这是一种对话式 AI，是聊天机器人之类的东西。这也是为什么我对我们新推出的产品 co-work 非常兴奋，因为它会把工程师很早以前就看到的东西带给其他所有人。

但当我想到 co-work 时，我会回想我们此刻聊到的这个非常早期的时刻。Claude code 最初不是 Claude code，它是一个聊天机器人。因为那就是我当时对 AI 的理解。但我们得去弄清楚，下一步是什么。所以我当时做了这个聊天机器人，它有点用，但只是个聊天机器人。接下来我尝试的是让它使用工具。因为 tool use 刚出来，我还不知道它是什么。我就想，做个实验吧。我给了它一个工具，就是 bash 工具，我也不知道拿这个 bash 工具做什么。

于是我就问它——其实我当时都不知道它能不能做到——我问它：我在听什么音乐？然后它就写了一段小小的 AppleScript 程序，用 sed 之类的命令，打开我的音乐播放器，然后查询我正在听什么歌。用 Sonnet 3.5 一次性就搞定了。这实际上是我的第二个 AGI 时刻，离第一个没过多久。我意识到，模型就是想用工具。这就是我发现的：如果你给它一个工具，它会想办法用它来完成任务。

我觉得当时人们在用 AI 做编码时的思路，基本上都有这样的心智模型：你把模型放进一个盒子里，然后去想界面应该是什么样的，你想怎么跟这个模型交互，你需要它做什么。本质上就像，如果你有一个程序，你 stub 出一些模块、一些函数，然后说“好了，这部分现在是 AI。”除此之外，剩下的程序还是普通程序。但这种思考方式是不对的。正确的思考方式是，模型就是它自己的东西。你给它工具，给它可以运行的程序，让它运行程序，让它写程序。但不要把它当成这种更大系统的一个组件。我觉得这就像是“苦涩的教训”（bitter lesson）的一个版本。“苦涩的教训”是一个非常具体的表述，但它有很多推论，这就是其中之一：让模型自己发挥，别试图把它塞进盒子里，别试图强迫它以特定方式行为。

**主持人**：你最早看到的方式就是给它工具，给它 bash 的权限，然后是文件系统，再到更多工具，对吗？

**Boris**：没错。是的，我们给了它 bash，然后——我说“我们”，其实前三个月只有我一个人，后来团队才壮大起来。所以先是 bash，然后是文件编辑，这是第二个。

上次深度访谈时我们聊到的一个有趣话题是，当你们把它做出来，它开始真正用你们手头的所有工具来写代码时，Anthropic 内部曾有一场争论：我们是不是应该把它留着自己用？因为它突然在整个工程团队里迅速铺开，让所有人的效率都大幅提升，对吧？

是的，没错。最终的决定是将其发布出去，以便我们能在真实环境中研究安全性。因为当你思考安全性——你知道，我一直在强调安全这个词——Anthropic 作为一家实验室存在的理由就是安全。这是它成立的原因，也是它存在的原因。如果你问 Anthropic 的任何人为什么选择这里，都是因为安全。所以，如果你思考模型安全，可以从不同层面来考量。有 alignment 和 mechanistic interpretability，这属于模型层面。

然后是 evals，有点像把模型放进培养皿里，用这种方式进行合成研究。接着你可以在真实环境中研究它，观察它的实际表现，观察用户如何谈论它，你能看到真实环境中存在哪些风险，而且通过这种方式能学到很多。正因如此，我们得以让模型变得更加安全。所以事后看来，这完全是正确的决定。

从你的视角听到这些很有意思，因为从外部看，我和很多工程师看到的是：哦，Anthropic 发布了 Claude Code。哇。第一次发布是随着 Sonnet 4 一起推出的。它最初是随 Sonnet 4 发布的，还是 Sonnet 4.5？我想是随 Sonnet 4。那是二月份的正式发布，但我觉得在那之前就有研究预览版了。没错，但当它发布时，我的理解是：这东西写代码写得相当好。而且随着时间推移，它变得越来越强。

所以从我们的视角来看，它就像是一个能力很强的编程工具，我们开始采用它，用它来做各种越来越高效的事情。而且我相信，它已经成为增长最快的开发者工具之一。而我总是很惊讶地听到，它其实源于研究，目标是理解人们如何使用模型。因为另一方面，有些创业公司一直在刻意构建开发者工具以获取用户，然而这个研究工具却获得了更多的采用。

要知道，Anthropic 是一家研究实验室，是一家安全实验室。产品某种程度上只是附带的东西。产品存在的意义是为了让我们更好地服务于研究，让模型更安全。这就是我们看待一切事物的方式。早期还有一个有趣的时刻，当时我们做了一个发布评审，决定是否要发布它。我记得那一刻，因为我们在一个房间里。当时有 Mike Krieger、Dario，还有其他一些人，我们在讨论该怎么办。我们看着内部采用率的图表，那简直就是一条垂直线。

太疯狂了。要知道，现在已经是 100% 了，对吧？就是 100%。现在 Anthropic 的每一位技术员工每天都在使用 Claude Code，几乎是 100%。对于非技术员工，实际上也相当接近 100% 了，增长速度非常快。比如，销售团队里大概有一半人在用 Claude Code，而且我觉得这个数字还在增加。简直太疯狂了。Dario 当时问，怎么增长得这么快？你是不是在强迫大家使用？我说，没有。

我们提供这个工具，大家用脚投票。我们只是让人们使用他们偏好的工具。

是啊，你看起来也不像是那种会强迫别人用你的工具的人。

对对。我们的做法是，先把这个东西发布出去，然后倾听用户，和人交流，观察他们怎么用，跟进反馈，不断改进。是的，现在我们已经到了这样的阶段：Claude Code 平均写了 Anthropic 大概 80% 的代码。而且可以肯定，它写了我的全部代码。

是的，对你来说，这始于你第一次提到的时候，我想是在十一月左右，它开始写你所有的代码。这个转变发生在什么时候？是什么让你信任它来编写你的代码，或者说你有多信任它？比如，你会 review 多少代码？

这个转变是瞬间发生的，当我们开始内部测试 Opus 4.5 的时候。那是在它正式发布之前，我们自己 dogfooding 了一段时间。然后一下子就切换了。这个模型的能力太强了，我发现自己根本不需要再打开 IDE 了。我直接卸载了 IDE，因为那时候我已经完全不需要它了。其实我大概过了一个月才卸载，因为我甚至没意识到自己已经不用它了。

是的，一旦 Opus 4.5 对外发布，我们很多人都有类似的经历，尤其是寒假期间。我也有类似的经历，我意识到这东西写的代码——说实话，在我非常熟悉的栈里，在我了解的个人项目代码库中，写得和我自己写的一样好；而在我不那么熟悉的代码库或技术栈里，写得比我好得多。

是的，说实话，它写得比我好。我不想承认这一点。我还想保留点自尊，但很可能是真的。

对对。我意识到这一点还因为十二月份我出去旅行了一段时间，算是进行了一次编程度假。我们之前聊过这个，我去了欧洲，在不同的时区，有点像数字游民那样四处漂泊。特别有意思，因为我每天都在写代码，这是我最喜欢做的事。我大概每天写 10 到 20 个 pull request 左右。Opus 4.5 和 Claude Code 写了每一个的 100%，我没有手动编辑过一行代码。那个月底我意识到，Opus 大概给我引入了两个 bug。而如果是我手写的话，那可能会有，你知道，20 来个吧。

我们能聊聊你的开发工作流吗？你写过一些关于这个的 threads，太棒了。是在社交媒体 Threads 和 X 上。你能告诉我们，如今你如何使用 Claude Code 吗？比如并行处理，还有你和团队学到并在团队内互相分享的一些技巧和窍门？

好的，我的意思是，使用 Claude Code 没有唯一正确的方法。我可以分享一些技巧，但我认为错误的结论是直接照搬这些用法。我们构建 Claude Code 的方式是让它可被 hackable。因为我们知道每个工程师的工作流都不同。做事没有唯一的方法，不存在两个工程师有完全相同的工作流，每个工程师都不一样。

工作站设置也是，对吧？比如键盘、显示器摆放，这些每个人都不同。

是的，就像我们手艺人一样，对吧？你选择你的工具。我们对此非常在意。所以没有唯一正确的做法。对我来说，通常的做法是开五个终端标签页，每个都 checkout 一份代码库。也就是五个并行的 checkout。通常我会 round robin 在每个标签页里启动 Claude Code。几乎每次我都以 plain 模式启动，也就是在终端里按两下 shift tab。

终端标签页总是有限的，满了之后我也得溢出。以前我经常用网页端来处理，比如 quad.ai/code，那就是我溢出时去的地方。现在我其实用桌面应用，更方便。quad code 已经集成在我们的桌面应用里好几个月了，就是 quad app 里的一个代码标签页。我很喜欢它，因为它内置了 work tree 支持，这功能已经存在一段时间了，对并行工作很有用。你不需要多个 checkout，只需要一个，然后我们自动为你设置 Git worktrees，这样就能实现环境隔离。我这么做是因为我真的很讨厌在命令行里折腾 Git worktrees，因为太麻烦了。你得知道怎么 cd 和……

对于那些不太熟悉 worktree 的人来说，它是什么？

就是你可以执行 checkout，但不用单独的本地文件夹，更像是检出了一个独立的分支，对吧？然后你可以在上面单独工作，冲突只在合并时才出现。

没错。想象一下你有一个文件夹，Git 以非常廉价且易于丢弃的方式复制出五份，这样就能实现隔离，你可以并行工作，各个 quads 互不干扰。

对了，你知道这个功能的支持，我记得你们最近才加入原生支持？但对你的工作流来说，你还是沿用老办法，用单独文件夹 checkout，对吧？

是的，没错。其实随着时间推移，我越来越多地用桌面应用来做这些，因为我不需要那些单独的 checkout 了，我只需要并行运行一堆 quads，完全不用操心。另一个让我意外的惊喜是 iOS 应用。每天我醒来，就会在手机上启动几个 agent。

哦，是原生那个？

对，原生应用。就是 quad app，quad app 里的代码标签页，和 quad code 完全一样。

只不过它运行在云端，对吧？

运行在云端。所以你得稍微配置一下环境。你的环境比较简单，所以我们只用了 hooks，用 session start hook 来配置。这也是 quad code 做得非常 hackable 的好处之一，这种配置很容易做。说实话，这是我以前完全没想到的，因为我一直是在电脑上写代码。如果六个月前你告诉我，我会用手机写——我没拉数据——大概三分之一，甚至一半的代码，那太疯狂了。但我今天就是这么做的。

而且你用的是并行 agent。你是什么时候开始用它们的，这改变了你的工作方式吗？因为我自己注意到，我其实不会同时开那么多并行 agent，可能也就两个。但我是个喜欢掌控局面的人，尤其是用 Claude。Claude 这个工具你可以跟着它一步步看，它会告诉你它在做什么。你还可以用比如 learn mode，这个功能很早就上线了，你可以跟着它的思路走，它会给你分派任务。我觉得待在一个标签页里跟着看就行，模型速度也挺快的，我能跟得上。我猜你肯定也有过这种做法，但后来为什么转向并行了呢？你会觉得失控吗，还是其实没那么重要？

我觉得这可以分为两种模式，或者说两种工作流。当你刚接触一个新代码库时，learn mode 非常棒，强烈推荐。对于刚加入 Quack Co 团队的人，或者刚加入 Anthropic 的人，我们的建议是——如果你还没试过的话——输入 slash config，在 Quack Co 里选择输出样式，可以选 learn 或 explanatory。我们通常推荐 explanatory，因为对于你还没熟悉的新代码库，这个模式更好。

对我来说，一旦熟悉了一个代码库，你就只想提高效率，对吧？就想尽可能多地交付，而且想做得高效。所以角色就变了。我不再深入跟进具体任务，而是把 Claude 开到 plan mode，让它去启动某个任务。Opus 4.5 我觉得已经能做到这点了，4.6 就真的非常稳。只要计划做得好，它几乎每次都能 one-shot 完成实现。所以最重要的是来回沟通几次，把计划定对。我的做法是：开一个，进入 plan mode，给它 prompt。

它在跑的时候，我就去第二个标签页，再开一个 Claude，也进到 plan mode，让它跑起来，然后去第三个、第四个。等第一个完成时我收到通知，再回来看，然后继续跟进。

通知开着还是关掉？

其实我两种都用。有时候我在 Mac 上开 focus mode，就把通知关了，但有时候也会用系统通知。

你的 PR 产出也非常非常高。我的意思是，就连假期前后在社交媒体上都很明显，有人在报 bug 或提功能请求——我不确定是哪种——然后你一两个小时后就做好了，因为你亲自做了。你也提到过一天能发多少个 pull request，不是为了炫耀，只是作为背景。一个 pull request 通常涉及多大复杂度？有些是不是特别小，有些其实是比较大的工作量？

每个 pull request 差别很大。有时候几行，有时候几百甚至几千行，全都不一样。变化太大了。以前在 Instagram 的时候，我觉得按代码量算，我是全公司产出最高的一两名，或者前三。

哇。

所以我一直都写很多代码，编码是我表达自我的方式，也是我大脑的思维方式。现在我依然在做这些，但有了 quad code，如果你效率很高，PR 数量其实低估了实际发生的东西。因为我觉得以前没有 AI 助手时，那些高产工程师写的很多可能是 code migrations 之类的。所以有人一天发 20、30 个 PR，很多都是一行改动，或者把 A 迁移到 B 之类的。现在我每天也发 20、30 个 PR，但每个 PR 都完全不同。有些上千行，有些几百行，有些几十行，有些一行。没有一个是 code migrations，因为 Quad 直接做那些，我不需要参与。

提交这么多代码，或者说这么多生产环境代码，任何软件从业者都会想到一个明显的问题：review。以前团队的工作方式——我不确定 Instagram 是不是这样，但很多其他公司是这样——你提交一个 pull request，放上去，必须有人工 reviewer。在 Google，其实要有两个人，因为还有一个负责代码质量。这个流程是怎么变的？

Quad Code 团队如何看待代码审查，以及这种看法随时间发生了怎样的变化？

我先谈谈以前我是怎么做代码审查的。我以前也是代码审查量最大的人之一。

哦，这样啊。所以写代码和审查代码两方面都是。

我可能……对，对。写代码和审查代码都是。这其实是不同时区带来的好处之一。我不是超人，只是当时没有会议要开。我做代码审查的方法是，每次需要对某处写评论时，我就把它记到一张表格里，并描述这个问题。比如说，有人在函数里给参数起了个糟糕的名字，我就会记下来；如果有人用了不好的 React 模式，我也会记进去。随着时间推移，我会统计这张表，当某一行出现超过三四次时，我就会为它写一条 lint rule，也就是用静态分析来自动化掉。以前就是这样。我一直试图把自己自动化掉，因为有太多事情要做。这是我们作为工程师的超能力之一——我们能够把所有繁琐的工作自动化。很少有其他领域能做到这件事，这是我们独有的能力。而且我一直很喜欢这样做，因为这给我更多空闲时间，让我去做真正享受的工作。

如今的做法看起来有些不同，但本质上还是类似的。当 Quad Code 写代码时，它通常会在本地运行测试——这是 Claude 在相关场景下经常自主决定去做的事，或者它会写新的测试。你会做这种验证。当我们修改 Claude Code 时，Claude 也会自我测试。它会以子进程的方式启动自己，进行自我验证，并进行端到端自测。

这是指你们内部 Claude Code 的实现。所以你们有一套测试套件，让它能自我测试。

对，没错。但它 literally 只是在一个 bash 进程里启动自己，然后看看"嘿，我还能正常工作吗？"它会做这件事。而且这完全不是我们编码指定去做的。特别是在 Opus 4.5 上，它就是自发开始这么做的。它就是想检查一下。所以我们这么做，然后还会运行 Claude-P。这是 Claude agent SDK，跑在 CI 里。Anthropic 的每一个 pull request 都会由 Claude Code 进行代码审查。这大概能 catch 住 80% 的 bug 左右。这是第一轮代码审查。Claude 会自动处理其中一些问题，有些则会留给人类，因为它不确定该怎么做。总会有工程师来做第二轮代码审查。而且必须有人在闭环中批准变更。

嗯。所以在团队里，任何东西上线之前，都会有工程师看过。

是的。

你考虑到代码审查时，会觉得每种项目都要这样做吗？还是说这只是因为你们现在知道它有真实世界的影响，人们依赖它，而且用户量很大。我换个方式问：你能想象在什么场景下可以不需要工程师审查代码吗？会是什么情况？

我觉得这取决于具体的使用方式。

是的，我同意。比如你在做一些个人 side project，你可以直接 YOLO 提交到 main 分支，对吧？甚至在 AI 出现之前，你也不会去审查。你就相信自己，或者直接部署到生产环境，或者 SSH 到生产环境改点东西。就是这类情况，对吧？

完全正确。Claude Code 最早的内部版本，我也是直接提交到 main 的。但一旦有了用户……对 Anthropic 来说，我们的主要客户群是企业，这是我们最重视的。出于安全考虑，security 非常重要，privacy 也很重要。这些都是相互关联的，对我们的客户来说也非常重要。所以因为这是一个 enterprise 产品，它必须安全，我们必须确保它达到一定的标准。因此，我们确实大量使用了自动化，但至少目前，必须有人类在闭环中把关。

关于 LLM 有一点是众所周知的，就是它们是非确定性的。如果把 LLM 作为审查者，让 Claude 来做 review，它确实能给出很好的反馈，但你怎么处理这个问题——你无法确定它是否总能给出反馈，也无法确定即使它有能力发现某个问题，它就一定会发现。你们在这个流程里有没有做什么确定性的事情？比如 linting 就是非常确定性的，你肯定很清楚。你们有没有考虑把这些思路结合起来，或者说，你们会在代码库上用 linter 吗，还是觉得自己不需要？

有的，绝对有。我们有 type checker，有 linter，会跑 build。Claude 其实非常擅长写 lint rule。所以实际上，我以前是把东西统计在表格里，现在呢，当同事提交了一个 pull request，我觉得"这可以用 lint 来解决"，我就会 @ Claude，请它在这个 PR 里写一条 lint rule。我们有一个……你只要在 QuadCode 里运行类似 slash 的命令，我记得是 set up GitHub 之类的，它就会安装 GitHub app，然后你就可以在任何 pull request 或 issue 里 @ Claude。

我每天都在用这个，非常有用。所以你需要这些确定性的步骤。不过，也有办法让 Claude 变得更确定性一些。比如你可以做 best of N，让它做多轮检查。

嗯。

而且这实际上很容易实现。比如我们内部用的 code review skill，它是开源的，就放在 Quad Code 的仓库里。我们所做的就是启动并行的 agent 来执行任务，然后再启动并行的 deduping agent 来检查 false positives。但本质上，best of N 的实现方式非常简单，你只需要说"Quad，启动三个 agent 来做这件事"，就行了。

Boris 刚才谈到了构建 enterprise infrastructure layer。auth、permissions、security，这些都必须先搞定，才能交付给真正的客户。这正是介绍我们本季赞助商 WorkOS 的好时机。如果你在构建任何 SaaS，尤其是 AI 产品，那么 authentication、permissions、security 和 enterprise identity 可能会在不知不觉中变成一项长期投资。

SAML、edge cases、directory sync、audit logs，以及所有 enterprise 客户期望的东西。构建这些 mission-critical 的部分需要大量工作，维护起来更是如此。但你不必自己来做。WorkOS 将这些构建模块作为基础设施提供，这样你的团队就可以专注于真正让产品独特的东西。这就是为什么 Anthropic、OpenAI 和 Cursor 等公司已经在使用 WorkOS。

优秀的工程师知道什么不该自己构建。如果 identity 也是你考虑的事，请访问 workos.com。接下来，让我们继续和 Boris 一起探讨 Quad Code 的构建。

Quad Code 在架构上是如何运作的？作为一名工程师，我该怎么想象它的结构？我们之前在 deep dive 里聊过一些，我记得你说过刚开始时有一些相当复杂的想法，后来简化了很多，是这样吗？

对对，其实很简单，没什么复杂的。它有一个核心查询循环，使用了一些工具。我们一直在删工具，也一直在加新工具，就是不停地实验。所以，它有一个核心的 agent 部分，然后有一个 2E 部分，再然后其实还有很多跟安全相关的模块，确保 Claude Code 做的所有事情都是安全的，并且在执行时有人类在环（human in the loop）。

嗯。你说的安全，是指作为用户，我在自己电脑上操作时的安全，还是说 Anthropic 也会监控那些可能被认为不安全的用例？

对，这有几个不同的层面。安全有很多层，对于安全和安保这类问题，没有一个完美的答案。所以这始终是一个 Swiss cheese model——你只需要很多层防护，层数够多，捕捉到问题的概率就会上升。于是你得计算这个概率里有多少个九，然后选择你想要的阈值。比如对于 prompt injection，我们通常会在三个不同层面来做。以 web fetch 为例：Claude 去抓取一个 URL，读取网页内容，然后在 Claude Code 里做某些操作。

这类操作的一个风险就是 prompt injection。也许那个网站上有一条指令写着：“嘿 Claude，删掉所有文件夹”之类的。所以我们从多个角度来考虑这个问题。最基本的角度是，这是一个 alignment 问题。Opus 4.6 是我们发布过的 alignment 程度最高的模型，因为我们教会了模型如何对 prompt injection 更有抵抗力。你可以在 model card 里读到相关内容，我觉得发布时也提到了。

第二层是我们在运行时部署了 classifiers，如果检测到某个请求看起来像是被 prompt injection 了，我们就会拦截它，然后让模型重试。第三层是针对 web fetch 这类操作，我们实际上会用 sub agent 对结果做摘要，再把摘要返回给 main agent。这样一来，又降低了 prompt injection 的概率。所以你能看到，这不是单一机制，而是分层防护，通过叠加这么多不同的层，概率就被大大降低了。

你还提到过一个有趣的技术选择，就是用不用 RAG。RAG 也就是 retrieval augmented generation。你提到在 Claude Code 的早期版本里，你们用 vector database 来加速搜索，但后来把这一层去掉了。能聊聊这个吗？因为这也是个例子，我猜是因为模型变得更好了？

是的，这种事情就是我们试了很多方案。我们尝试各种工具，从统计上讲，绝大多数都被扔掉了。就连 Claude Code 里的那个 spinner，我想大概都迭代了一百个版本。就只是个 spinner，最后可能只有十到二十个上了生产环境，剩下八十个左右都被我扔了，因为感觉不够好。所以从统计上看，我们写的代码几乎都被扔掉了，因为写代码做实验太容易了，试完就知道感觉对不对。至于 RAG，我们早期也试了很多不同方法。

第一种是用 RAG 做检索，因为当时我看大家都在怎么做检索，似乎所有论文都在讲 RAG。我的做法是搞了一个本地 vector database，好像是拿 TypeScript 写的，跑在用户机器上，然后用云端的一个 embedding model 来计算 embedding，再存进去。效果其实还行。但 RAG 有很多问题。比如我发现代码会不同步。如果我刚写了一个本地函数，它还没被索引，RAG 就搜不到。

还有索引的权限问题：谁能访问？我能访问，但怎么把这种规则编码到权限策略里？怎么确保别人访问不了？怎么确保公司里如果有 rogue 的 IT 人员，他也不能访问别人的数据？这一点真的非常重要。所以我们觉得，虽然 RAG 勉强能用，但 downside 也很多。于是我们又试了一堆别的。其中一个是让模型递归地给所有东西建索引，这个想法挺酷的。还有一个版本，我们直接试了 glob 和 grep。试了很多不同的东西。

结果 Agent-X search 完胜。那什么是 Agent-X search？其实就是 glob 和 grep 的一个花哨说法，仅此而已。漂亮。所以模型本身变得足够好了，而且你们也发现它能相当高效地使用这些工具。对。这其实部分受到了我在 Instagram 工作经历的启发。因为在 Instagram，click-to-definition 经常用不了，因为开发栈一半时间都是坏的。当然我觉得现在可能好点了。

所以工程师们会这么干：假设你要找函数 foo 的定义，不用点击跳转，而是直接用 Meta 内部那个相当好用的 global index，然后搜索 “foo 左括号”。这招挺好用的。有趣的是，这对模型来说也挺好用的。你看，一个领域里的想法就这样迁移到了另一个领域。

我们之前也聊过，Claude Code 里比较复杂的部分之一是权限系统。能说说它复杂在哪里吗？而且你们最近开源了 sandboxing 对吧？权限管理非常复杂。和其他所有跟安全相关的东西一样，它也是一个 Swiss cheese model。我们会运行一系列 classifiers 来确保命令是安全的。也会做 static analysis 来确保命令安全。作为用户，你也可以把某些你已知安全的模式加入 allow list。

比如，有些标准 Unix 工具我们是预先放行的，因为我们知道它们是只读的，不会 exfiltrate 数据之类的。所以我们不会向你索要权限。但实际上很少有工具能归到这一类，因为就连 find 命令，其实也有办法通过某些系统 flag 来执行任意代码。甚至 set 命令也有类似的用法。所以这些 Unix 工具里藏着很多这种冷门知识，实际上并不像你想的那么安全。因此，默认情况下，我们对允许执行的范围是相当保守的。

不过作为用户，你可以配置一个 allow list。比如你可以说这些模式允许，那些模式不允许。我们允许你自定义，并且也会检查这个 allow list 来确保安全性。

对，然后你们还设计了一个很精巧的权限系统，每次运行需要权限的命令时，你都可以选择只运行一次、在整个 session 期间运行，或者不管什么范围直接全局允许，对吧？没错。这倒是个有趣的历史遗留产物。其实在 Claude Code 最早最早的第一个版本里，权限就是这么运作的。这是第一版发布时就有的设计。

那是在 2024 年 9 月左右，第一次内部发布。我记得当时我们甚至不确定 agentic safety 是否有可能解决。因此，安全团队内部其实有很多反对声音，他们的说法是：“你不能就这样让模型运行 bash 命令啊，这不安全。那能怎么办？这是个无解的问题。所以我们不能发布这个。”

我和 Ben Mann 一起头脑风暴，Ben 创办了 labs 团队，他是 Anthropic 的创始人之一，实际上也是他把我招进了 Anthropic。我们想出的办法是 permission prompts：如果你不确定，就去问人类，然后由人类来决定。

我想问问你 Anthropic 的软件工程总体是怎么做的。第一个问题——可能算是比较正式的，或者说外人比较关心的——就是头衔，或者说缺乏头衔。Anthropic 的每个人都有相同的头衔，member of technical staff。为什么会这样，这又带来了什么结果？基本上就是大家都没有头衔，对吧？只有一个例外。

我觉得这多少是在承认，大家都还在摸索。而且如果你仔细看大家做的工作，其实都很相似，而且相当通才。如果你去问普通的软件工程师，他们可能不只是写代码，还会做一点设计，也会和用户交流，可能会自己写产品需求，可能一边写软件一边做研究，可能既写产品代码也写基础设施代码。Anthropic 有很多通才。从我的背景来说，这也是我被吸引到这里的原因之一。我觉得 member of technical staff 这个头衔，某种程度上把这一点编码进了人们彼此交流的方式里，哪怕他们互不相识。

如果没有这个头衔，默认情况就是我在 Slack 上看到你的名字，下面写着 software engineer。那我就会想，好吧，你就是写代码的，所以我不会问你产品相关的问题。但当所有人的头衔都是 member of technical staff 时，默认情况下你就会假设每个人都无所不能。所以这某种程度上扭转了人与人之间的关系，哪怕你们不太熟。

从某种角度来说，这是把一种乐观主义内置进了组织结构里。我觉得这也预示了未来，因为我认为软件工程正朝这个方向发展，每个学科都在朝这种通才模式发展。

软件工程领域确实给人这种感觉。我听 Mark Andreessen 说过一个很有趣的评论，他说科技界正在上演一场“墨西哥对峙”：设计师说他们现在其实也在做 PM 和工程的工作；工程师说他们也在做设计……每个人都觉得自己在做别人的工作，彼此对峙，好像在说“你的工作我也在做”。但现实中，每个人的角色都在扩展，很大程度上得益于 AI，因为它让工程师更容易做产品工作，也让产品人员更容易做工程工作，诸如此类。就像你说的那样。

我记得去年六七月份的时候，我走进办公室——有一排数据科学家就坐在 Quadcode 团队旁边，至少当时是这样。我走进去，看到 Quadcode 团队的那位数据科学家电脑上正开着 Quadcode。他在用这个，我就说：“这挺有意思的，你不是数据科学家吗？为什么在用终端？你之前都没装 Node.js，因为我们那时候还依赖 Node.js。你是在 dogfooding 吗？还是就想试试这东西怎么用？”他说：“不不，我在用它跑查询。

”他就是用它跑 SQL，终端里还有一些 ASCII 可视化图表。然后到了下一周，整排数据科学家的电脑上都跑起了 Quadcode。接着这个现象就扩散开了。所以如果你看现在的团队，Quadcode 团队里每个人都在写代码。工程师写代码，我们的工程经理写代码，设计师写代码，数据科学家写代码，财务的同事也写代码。团队里每个人都在写代码。我觉得部分原因是 Quadcode 让这件事变得太简单了。你其实不需要理解整个代码库，可以直接上手，很容易做一些小改动。

但还有一点是，人们能够用 Quadcode 更好地完成自己的工作，不管是财务预测、数据科学还是别的什么。这样一来，顺势用它写点代码也就变得很自然了。这就像是先让你把脚趾伸进水里试试。

你们的工作方式中还有另一件有意思的事。Kat 提到——我猜你们的头衔都一样，但大家可能会稍微偏向某个角色一点，据我所知她更偏向产品方向。但你说在 Anthropic 内部其实不太写 PRD。PRD，也就是 product requirement document，在大厂和越来越多的大型创业公司里是一种很知名的文档形式，你写一份 spec，把你的想法写下来，大家对齐，发出去，然后就知道该做什么了。但显然你们不怎么这么做，或者说完全不这么做。

部分原因我觉得是 Anthropic 仍然还是一家创业公司。所以其实你不需要跟那么多人同步。通常随口聊聊，或者在 Slack 上说一下就行了。但还有一部分原因是，Kat 以前也是工程经理，她技术非常强。我觉得我们的产品团队也是这么想的：与其写文档，不如直接发一个 PR。你们更多的是在做原型。所以这也呼应了我们之前聊的，你早期做 Claude core 的时候，你展示过有一个完整的消息串，里面大概做了 15 或 20 个 to-do list 的原型，每一个都是可交互、可运行的。

这和我过去在科技行业的经历相比让我很惊讶，而且你说你只用了一天半就把这 20 个全做了，试了试，找找感觉。这对我来说简直不可思议。这要是在别的地方可能要花一到两周，而且人们也不会做 20 个，他们做 3 个就差不多了。

对。所以你是说，你现在看到原型制作、动手构建和演示变多了，而写东西变少了？是的，当然。在我们团队，文化就是：我们不怎么写东西，我们直接演示。以前是什么样的已经有点难回想了，因为现在做原型已经深深嵌入了我们的构建方式里。所有东西都会反复做多次原型。比如这周我们发布了 agent teams，这是我们实现的 swarms。这非常令人兴奋，因为它让 Claude 能够更长时间、更自主地完成更多工作。你有一堆互不相关的 context window，agent 之间还有这种通信机制。

它们能做更多事情。这是 Daisy、Suzanne 和团队里的其他人，还有 Karen，他们花了几个月时间做原型的成果。他们大概试了上百个版本，才最终得到一个体验非常好的用户界面。要把它做好真的非常非常难。

如果我们当初从 Figma 里的静态 mock 开始，或者从 pure D 之类的东西入手，那绝对做不出这个产品。这东西你必须亲手搭建出来，亲自去感受，亲自去体验它的手感。对我来说，一个很大的收获就是，我们可能应该多做原型，更大胆一些，放下那些关于「做一个原型要花多长时间」或者「该由谁来做」的先入之见。以前总觉得必须是工程师来做，但现在可能已经不是这样了。

对，没错。我们现在所处的这个时代，其实我们并不知道正确答案是什么。回想以前做产品的方式，构建成本很高，所以你必须在开枪前花大量精力仔细瞄准。因为一旦开枪，就很难修正航向了，你能开的枪就那么几发。但现在情况变了。构建成本变得很低，但与此同时我们也不知道该瞄准哪里。所以我们只能去尝试，去感受什么感觉是对的。整个过程是非常非常探索性的。我觉得还有一点很重要，就是保持谦逊。就我个人而言，我大概有一半的时间都是错的。我想说，我的大部分想法都不太好，至少有一半是不好的。而且在我尝试之前，我也不知道哪一半不好。嗯。有时候也要从别人那里获取反馈。对。就是我得自己先试一试，然后再看看别人怎么想，因为你知道，我的直觉并不总是和别人一致。

你之前给我展示那些任务是如何构建的原型时，你告诉我说，你会先做原型，然后你的流程总是这样的：你先自己看，亲自试用，找找感觉，然后对于那些你觉得不错的，再拿给别人看，有时候他们会反馈说「不行，这个行不通」。而有时候当你感觉不错时，你就会更广泛地分享出去。所以我觉得，这是一种混合模式，对吧？有时候你自己就能判断，有时候你需要听取反馈，最终一些好想法就这样产生了。

是的，这样的例子有很多。比如我们推出了这种文件读取和文件搜索的压缩视图，因为现在的模型太 agentic 了，我感觉半个屏幕都是文件读取的内容，而我其实并不关心这些。你知道，我读了一个东西，但我并不真的在乎它具体是什么。所以我们把它压缩了，让输出更易读一些。大概做了 30 个原型之后，我才真正喜欢上这个设计。为了让它感觉起来非常舒服和简洁，我们花了很大功夫。我们在 Anthropic 内部向员工推广了大约一个月，让所有人 dogfood，然后我又根据这些反馈修复了大概十几个 bug，做了十几处调整。

之后我们对外发布了，几乎所有用户都喜欢，但也有少数用户不喜欢，因为他们想要更展开的输出。于是在 GitHub issue 上，我就和大家来回沟通，问他们，你们到底不喜欢什么？人们给了很多反馈。我又发了一个版本，然后有人喜欢，有人还是不喜欢。于是我又迭代了一次，把它做得更好了。其实我觉得现在差不多到位了，人们可以按自己的喜好配置，但默认效果也已经很好了。但这就是过程。你知道，我们有时候能一次做对，但我们也必须向用户学习。

我们想听到大家的声音，这样才能做对。

你们工作会用工单系统吗？就是，在哪里记录，比如「这是要做的工作」，还是说你们基本上就是来什么活就干什么活？在 Anthropic，我们让各个团队自己决定。在 Quad Code 团队，我们让每个人自己决定。不同的人用法不一样。比如我就不用工单系统。有些人喜欢用 Asana 或者笔记之类的。我见过最酷的一件事，大概三个月前吧，我们推出了插件。推出的方式是 Daisy 用一个周末完成的。她有一个非常早期的 Swarms 版本。

她让这个 swarm 跑起来，然后告诉它：「你的工作是构建插件。你得先想出一个 spec，然后要在 Asana 上建一个看板，把任务拆分。然后不同的 agent 要分别去构建。」她搭了一个容器，把 Claude 设成了 dangerous mode。然后她让它跑了整个周末。它生成了几百个 agent，在 Asana 看板上创建了 100 个任务。然后它们就实现了这个功能。这差不多就是我们发布出去的插件版本。

这种协调系统本来是为人类设计的，但我觉得现在它们对模型来说也同样重要。

我们来聊聊 Claude Colab。关于这个产品很重要的一点是，它看起来很棒。我试了一下。在 Claude 里面有一个 Colab 标签页，然后你可以……我觉得这是一种更视觉化的方式来运行 agent 并与它们交互。我听说最令人惊讶的一件事是，它只花了 10 天就做出来了。你能给我们讲讲构建它花了多少功夫吗？这具体意味着什么？是从有想法开始算，还是从决定做开始算？团队有多大？团队真的很小，就几个人。

很长一段时间以来，我们都觉得应该为 non-engineers 做一款产品。我们之所以这么想，是因为长期以来使用 Claude Code 的人里有很多都是 non-engineers。你知道，在产品领域，当你看到潜在需求时，当你看到人们费很大劲去使用一个并非为他们设计的产品时，这就是一个很好的信号，说明是时候做一款专门为他们设计的产品了。Twitter 上有很多人，比如有个人用 Claude Code 来监控他的番茄植株。

我特别喜欢这个例子。他好像装了一个摄像头，然后 Claude 会说：「天哪，我们的植物发芽了，我好开心。」因为它连着摄像头，每天都在监控，然后为番茄的生长感到特别开心。还有人用 Claude Code 从损坏的硬盘里恢复照片，而且是他的婚礼照片。哇。你知道，就像我说的，Anthropic 的整个财务团队都在用 Claude Code，销售团队也在用 Claude Code。所以有很多 non-engineers 在使用它。

那时候 Claude Code 已经有很多形态了，对吧？我们从终端开始，然后扩展了，增加了对 IDE 的支持。所以我们有面向所有基于 VS Code 的 IDE、所有基于 JetBrains 的 IDE 的扩展。还有 iOS 和 Android app，桌面端 app，网页版。然后还有 Slack 和 GitHub app。我们把产品扩展到所有这些地方，让 Squad code 对工程师来说更易用。

但归根结底，这些都不是为 non-engineers 设计的。所以 Squad code 演进了很多，但仍然感觉有一个缺口，有一款产品可以让这件事对人们来说更简单。所以在过去几个月里，团队一直在鼓捣，想看看正确的产品形态是什么。然后某个时刻有人想出了这个主意：如果我们拿 Squad code，加上一些 guardrails 会怎么样？比如，Squad 是在 virtual machine 里工作的。

这是我们确保它非常安全的诸多方式之一。特别是对于那些不想读 bash 命令来弄清楚它在干什么的 non-technical users 来说。然后他们就在这个方向上 hack，我想大概是 10 天出头。整个东西完全是用 Squad code 构建出来的。

然后我们发布了它。你能介绍一下这类应用背后的复杂程度吗？如果我们可以梳理一下都需要构建哪些部分的话。因为从外部很难判断——这只是一个漂亮的 UI 包装，甚至只有几百行代码？我这么说 obviously 是带有挑衅意味的，还是说背后其实是一套非常复杂的软件？我这么问的原因是，Uber 就是一个很好的例子：人们看着应用觉得很简单，我在那里工作过，知道它其实非常复杂，因为很多复杂性是看不见的。有很多区域化的东西，有很多后端的东西都是隐藏的。所以单看 Claude Co-work，很难判断这当中有多少是需要仔细思考的业务逻辑， versus 其实它只是模型之上一个薄薄的包装。

我觉得有些地方复杂度比你想象的要低，有些地方则更高。从产品层面看，它其实相当简单，因为它就是 Claude 桌面应用。你下载 Claude 应用，它是一个单一的桌面应用，有 Co-work、Code 和 Chat 三个标签页。所以它只是一个应用，我们可以继承很多产品逻辑。有一些 UI 渲染代码。在底层，运行的还是同样的 Claude Code，驱动 Claude Code 的也是同一个 Claude agent SDK。

实际上，很多复杂度在于安全性。因为正如我所说，我们知道用户是非技术背景的，所以我们只想确保他们有良好的体验。比如，如果有人打开应用，然后删除了一堆家庭照片，那就非常糟糕。因此我们想确保能防止这种情况，让你不会误操作。所以很多护栏机制由此而来。后端运行着一系列分类器，这是为了安全，同时也是对 prompt injection 等安全风险的额外缓解措施。前端方面，我们打包了一整个虚拟机，还有大量操作系统级别的集成，以确保人们不会误删文件。

所以光是安全性这一块，就有很多工作。然后我们还必须重新设计权限系统，因为我们继承的是 Claude Code 的权限系统。但另外，对于 Co-work 来说，其价值的一大部分不仅在于本地运行，还在于像 Claude Code 使用工具那样使用你的所有工具。但问题是，对非技术用户来说，你的工具并不是以 CLI 形式存在的。有些通过 MCP 提供，很多则在浏览器里。所以当你把它和 Chrome 扩展搭配使用时，Co-work 会非常好用。

这也是我通常的使用方式。比如，我每周都用它来做团队项目管理。我们有一个电子表格，在很高层面上跟踪每个人都在做什么。这算是我个人做项目管理的方式。就像我说的，其他人用 Asana，或者用笔记之类的。我自己的任务什么都不用，但对整个团队，我有这个表格。我让 Co-work 去检查。我每周就问 Co-work：“嘿，你能看看有没有哪一行的状态还没填吗？能不能在 Slack 上提醒一下那位工程师？”然后它会在 Chrome 里打开一个标签页显示表格，再打开一个 Slack 标签页，接着就开始在 Slack 里给工程师发消息。

它一次性就搞定了。好像有一位工程师的名字，出于某种原因它没法自动补全，但其他所有东西它都能拿到。所以从安全角度，我们也对这款 Chrome 扩展、它的工作原理、以及权限模型应该如何与本地权限模型交互做了相当深入的思考。所以也写了不少代码来确保这套体验顺畅。

那背后的技术栈是什么？我猜很多应该和 Claude 应用类似，但它是 Electron、TypeScript 这类技术，还是别的？对，就是 Electron 和 TypeScript。实际上，团队里有些人是早期的 Electron 成员。比如 Felix，他是 Co-work 的负责人，也是 Electron 非常早期的工程师，参与构建了它。太厉害了。而且 Co-work 最初只在 macOS 上发布。

选择先上这个平台、以及目前只上这个平台的原因是什么？是的，Windows 版本很快会来。我觉得可能到这期播客发布的时候，我们就已经支持 Windows 了。我们只是想尽早开始、尽早学习。你知道，就像我们在 Anthropic 做所有事情一样，这很符合我讲述自己经历的方式，也是我喜欢 Anthropic 的原因之一：它真的和这里的人思考问题的方式高度一致。就是说，我们对自己做的东西并没有很高的确定性。

我们的直觉常常是错的，所以我们必须向用户学习，弄清楚人们真正想要什么，你要花大量时间倾听用户、深入理解反馈。这就是我们构建产品的方式。所以我们总是在产品还没完全准备好之前就发布。Claude Code 就是这么做的。最初发布时，它甚至不支持 Windows，也不支持很多不同的技术栈，然后在接下来几周里，我们逐步添加了对所有栈的支持。现在 Claude Code 支持每一个栈。Windows、无论你用什么奇怪的 Linux 发行版、macOS，我们都支持。

所以对 Co-work 来说，我们也想尽早发布。Mac 只是一个起点。但没错，它最终会支持所有平台。

你提到的一点是要获取反馈。我好奇的是，无论是 Claude Code 还是 Claude Co-work，你们是怎么做可观测性、监控的？rollout 的时候用 feature flag 吗？我更感兴趣的是，你们为此自己搭建了工具，还是选择了某些供应商？因为特别是在可观测性方面，我确信这很重要，而且从用户规模来看，听起来也相当大，这不是一个小工程？是的，我们既用了一些现成供应商的产品，也写了一些自定义代码。

所以实际上是两者结合。这没什么太特别的。Anthropic 有一点比较有意思：因为我们是一家企业级公司，非常注重隐私和安全，所以我们看不到用户的数据。因此，如果有人报了一个 bug，我其实没法调出你的日志来看看到底发生了什么。我们花了很多精力去研究如何在保护隐私的前提下记录事件等信息。这对我们的运营方式来说非常重要。

对于 Co-work，你们目前学到了什么？它已经发布了大概几周时间。有没有遇到什么出乎意料的情况？你们是否正在根据收到的反馈来塑造产品？是的，团队每天都在提交大量修复。说实话，最让我惊讶的是大家居然这么喜欢它。Claude Code 刚发布的时候，其实并非一夜爆红。

人们可能以为它一上来就很火爆，但其实初期是缓慢起步的。我觉得第一个重大转折点是在五月发布 Opus 4 和 Sonnet 4 的时候，那时候才真正开窍，增长也开始呈指数级上升。但一开始它更像一个 research preview，大家不太知道该怎么用。有些人立刻就上手了，但大多数人没有，这需要一点时间。

Co-work 的增长轨迹比 Claude Code 初期陡峭得多。所以它一推出就大受欢迎，这实际上非常出乎意料，我真没预料到。

你们最近刚发布了一个新功能，大概就在昨天或者前天——我们录这期播客的时候——就是 agent teams。据我理解，agent teams 或者说 agent swarms 的思路是，不再只有一个 agent，而是可以有一个 lead agent，由它来委派给不同的队友。你们是怎么开始试验这个功能的，又是怎么决定现在发布的？

我们一直在做实验，对吧？有很多方法可以让 Claude Code 发挥更大作用。一种方法是扩展 context；另一种是 auto compacting context，这样本质上就是无限 context，这也是我们目前的做法。还有一种方法是使用 sub agents，让多个 agent 协同工作。总之有很多不同方法可以让 context window 发挥更大价值。

我们有一个概念叫 uncorrelated context windows。顾名思义，就是你有多个 context window，但它们本质上都是重新开始的，彼此互不知晓。举个例子，correlated context window 的情况是：你有一个模型，它完成了一项任务，然后你在同一个 context window 里让它做第二项任务。这时第二项任务知道第一项任务的内容，因为它们在同一个 window 里。但对于 sub agent 来说，它是 uncorrelated 的，因为主 agent 给 sub agent 下指令时，sub agent 的 context window 是全新的。除了那条指令之外，它不知道父级 context window 里有什么。

这一点在 sub agents 和 skills 的对比中也能看出来。因为当你运行一个 skill，或者说 slash command 时，它能看到父级的 context window；而 sub agent 则看不到。所以它是 uncorrelated 的。有些情况下你需要那个上下文，有些情况下不需要。有意思的是，使用 uncorrelated context windows，给问题堆砌更多 context、更多 token，反而能得到更好的结果。这其实是一种 test time compute。

至于 teams 这类功能，我们已经试验了一段时间，大概从去年十月或九月就开始了。而直到 Opus 4.6，我们才感觉它真正开窍了，模型学会了如何运用这个机制。有时候你会看到一些很有意思的对话，agents 在互相交流、讨论事情，看起来非常酷，某种程度上很像人类。但另一些时候，你就是能得到非常好的结果。

比如我们做过一批内部评估，让 Claude 去构建非常复杂的东西，复杂到单个 Claude 无法完成的程度。而使用 Opus 4.6 和 teams，我们看到结果确实大大改善了。因此我们觉得这是发布的合适时机。但我们也想谨慎一些。之所以需要手动选择开启，之所以还是 research preview，是因为它消耗大量 token，毕竟是一堆 Claude 在同时运行。不是所有人时时刻刻都需要这个。所以我很期待看到大家怎么用它，也期待听到反馈。这种功能更适合相当复杂的任务，你可能不会想每件事都用它。

主 Claude 决定 sub Claude 们的规则。我们并没有一套僵化的做法。这取决于具体 context。我不认为存在唯一正确的方式。实际上，我觉得这其中的魔力很大程度上来自 uncorrelated context windows 这个概念。重点不在于 agent 的具体配置。但这确实是大家应该去试验的东西，我觉得没有放之四海而皆准的方案。

你有没有看到一些用例？我知道这还在研究阶段，但有没有哪些用例让你觉得这种思路、这种 swarm 的思路看起来很有前景？

嗯，我之前应该说过，plugins 完全是用 swarms 构建的。之后还有很多其他功能也是用这种方式搭建的。所以是的，我觉得只要看到单个 Claude 吃力的地方，swarms 就能帮上忙。这很值得关注。

泛泛地聊聊变化吧。去年十二月，你和 Andrej Karpathy 有一次很有意思的互动。他发帖说，因为 AI 的进步，他从未像现在这样感觉自己作为程序员如此落后。然后你分享了一个故事，说自己本来在用老办法调试一个内存泄漏，结果 Claude 一次就解决了。我觉得这反映了所有人的感受：变化太快了。在假期休息的时候，我开始感觉到事情真的发生了转变。你是怎么接受、或者说开始拥抱这种变化的？这是我个人非常挣扎的地方。

模型迭代太快了，旧模型上管用的思路，在新模型上可能就不行；在新模型上没跑通的东西，也许在旧模型上行，也可能在新模型上又行了。这很奇怪，因为很少有其他技术是这样的。所以我其实没有太多经验可以借鉴，来想清楚该怎么应对。这算是我必须学会的一项新技能。

某种程度上，你必须始终保持这种初学者心态。说实话，我最近常说“谦逊”这个词，但你确实得始终保持这种智识上的谦逊。因为之前行不通的想法现在能行了，反之亦然。我觉得说白了就是这样。这是我必须不断提醒自己的。

有意思的是，在过去，如果有人把一个我们以前试过但没成功的想法又拿出来试，通常的反馈就是：你怎么又在搞这个？对，对，他们会说你赶紧打住。我是说，我们以前会管这叫 gatekeeping，但某种程度上是合理的。比如在架构领域，有人提议“我们为什么不搞微服务”，另一个人就说“我们试过了，不行”。如果是一两年前甚至三年前试的，这话还算站得住脚，对吧？因为那时候没什么太大变化。

是的，没错。微服务这东西挺有意思的，好像每十年就会流行一阵、过气一阵。但现在，我觉得是有史以来第一次，每隔几个月就把同一个想法重新试一遍，其实也不是什么疯狂的事，因为模型在进步，它可能就管用了。

我在团队里的工程师身上也看到了这一点。比如新加入团队的成员，或者刚入行不久的工程师，有时候做事的方式比我更好。我只能看着他们，然后学习，调整自己的预期。举个例子，我们发布新功能的时候，我有时会截图自己在 X 或者 Threads 上使用这些功能的画面，发出来聊聊。但最近，Tariq，就是我们负责 devrel 的同事，他写了很多代码。他太厉害了。

他直接开始把这事自动化了。他在用 hot code 为自己的发布活动自动生成视频，就这么干起来了。你知道，这事我以前觉得也许可行，但不是我愿意尝试的，因为我不认为模型已经准备好了，但他直接做了，而且效果还行。

有一件事让我感到有些奇怪，我想很多开发者都能感同身受——自从 Opus 4.5 开始，我也慢慢接受了这个现实，而且类似的模型，比如 GPT 5.2，也给了我类似的感觉。这些模型写代码写得实在太好了，我意识到如果我真想做成什么事，我不会再手写代码了。如果我就是想享受写代码的乐趣，那当然可以写。但我不禁回想起，为了学好编程，我们付出了多少努力。我记得自己一开始只是瞎折腾，后来上大学学 C，再学 C++，那真是难死了。

还有我头几份工作，慢慢变得擅长调试，技术越来越好。曾经有那么一段时间，我的自我认同很大程度上就建立在“擅长写代码”这件事上。我们过去就是靠这个找工作、找高薪工作的。我做招聘经理的时候，在 Uber 设计面试流程，我们跟经理们讨论要筛选什么，聊的是：开发者大部分时间做什么？大约 50% 的时间在写代码。所以我们把大约 50% 的考察权重都放在了编程上。编程身上寄托了太多东西，因为它确实难。我们都知道这需要毅力，需要一定的聪明才智才能学好。

现在有种失落感：一方面模型能做到这些，我觉得很棒；但另一方面，好像有什么东西被很快地拿走了，而我个人真没想到会这么快。我想很多人都有这种感觉。有些人比较容易释怀，但确实有一种悲伤的情绪。你怎么看待这件事？毕竟你是那种在 Facebook 也写了很多代码的人，外面也写了很多。我知道这对你来说只是完成工作的工具，但不是很多人能做到你做的事。而现在模型的表现已经和你一样好，甚至更好。这就是挑战所在。

是的，我觉得这曾经是软件工程师专属的事情，现在正变成人人都能做的事。回想我开始写代码的时候，它是一件很务实的事，是用来完成工作的手段。但后来我渐渐爱上了编程这门艺术，爱上了语言和工具本身。再后来我就掉进了这个兔子洞。我写了一本书，关于一门编程语言的，TypeScript。

——你写了 O'Reilly 第一本 TypeScript 的书。

对对对，没错。其实挺有意思的，有件事让我印象特别深刻。我在日本一个小镇上，去书店的时候，发现我那本书居然有日文翻译版。就在那个小镇上，那感觉太酷了。然后我其实意识到，我根本不记得 TypeScript 了，因为那时候我已经只写 Python 写了好几年。

对，然后后来我在某个时间点创办了当时全球最大的 TypeScript meetup，在旧金山。我因此见到了很多偶像级的人物，比如 Chris Kowal，他写了 General Theory of Reactivity；还有 Ryan Dahl，做 Node 的那个人。那是我第一次真正深入这个社区，深入语言本身和工具本身。对于 TypeScript 来说，它的类型和类型系统里有一种美感，因为 Heilsberg 实在太厉害了。

conditional types 这种概念，任何东西都可以是 literal type，这些非常深刻的理念，即使是最硬核的函数式语言也没有。就算在 Haskell 这样的语言里，也没有走到这么远，而 Anders 接手之后，把它推到了前所未有的深度。后来 Joe Pamer 和其他一些人把这些理念推广出来，并做了大量思考。我觉得对他们来说，这也是非常务实的，因为他们面对的是庞大的 untyped JavaScript 代码库，如何逐步迁移到带类型的系统，你必须想出这些非常漂亮的办法。

对我来说，Scala 是另一个我掉进去的兔子洞，那个函数式编程的世界。直到现在，无论是我自己写代码，还是模型写代码，我始终先想类型。真正重要的是 type signature，那比代码本身更重要，要把那个弄对。所以这中间确实有美感，确实是一门艺术。但归根结底，它是实用的，是我们用来构建东西的手段，它是途径，不是目的本身。

我觉得对于当下这个时刻，我有一个比喻，就是 15 世纪左右的印刷机。

——嗯。

因为在那个时刻，情况其实非常相似，对吧？有一群抄写员，他们懂得书写。当然我们没有亲身经历过，但据我理解，据我想象，学习这门技艺的过程非常艰难。你需要有工具设备，可能还需要赞助或者被选中。你需要不断练习，因为你需要一遍又一遍地复制同样的内容，很少有人能做到。我猜这门手艺要么地位很高，要么报酬丰厚，谁知道呢，就当是吧。但后来印刷机出现了。

——对。

至少在当时的欧洲，你需要领主或者国王之类的人来雇佣你，然后你要经过多年的训练。有这么一个抄写员阶层，他们懂得书写，受雇于这样的人，有时候就是国王本人，或者王后，而他们自己反而不识字。所以这是一项极其小众的技能，当时欧洲识字率不到 1%。然后印刷机出现了，发生了什么？印刷材料的成本下降了大约 100 倍，在接下来的三四十年还是五十年左右。印刷材料的数量增长了大约 10,000 倍，在接下来的五十到一百年间。

这是第一个效应。识字率的提升则花了一段时间才跟上。全球识字率后来上升到了大概 70%，但这又花了两三百年，因为学习阅读本身就非常难，学习书写也很难。这需要大量努力，需要教育体系，需要基础设施来提供纸张和墨水，还需要有农活儿之外的空闲时间来做这些事。所以某种程度上，这需要工业化早期阶段才能实现。但我认为，把原本锁在象牙塔里的东西变得人人可及，这个效应至关重要。我们今天周围的一切，没有印刷机就不会存在。

如果我们不识字，如果制造这个麦克风的人不识字，现代经济就很难出现，这一切都不会存在。

我有时会回想，如果当时人们必须预测印刷术出现时会发生什么，没人会料到麦克风这种东西的诞生。所以我觉得，这是对我们当下所处时刻最好的类比。而且你提到有些国王其实是文盲，却雇佣抄写员，这很有意思——因为说实话，我们现在的企业主知道自己想打造什么，于是雇佣软件工程师，恰恰因为他们自己不会写代码。我们总喜欢嘲笑那些涌入这个领域的 CEO，他们可能拿着手绘原型或者白板说"这个应该很简单"，但他们当然不理解这有多难。

但这似乎有点类似：有人清楚自己想要什么，但直到现在，他们都需要雇佣软件专家来实现，而想法和执行者之间始终存在脱节。就像印刷术一样，如果这些人真的能自己表达呢？就像国王真的能自己读写信件，他们就不需要中间人了，事情也会变得更高效。当然，对抄写员来说这不一定是好消息，但聪明的抄写员也可以做别的，比如写书、操作印刷机等等。

没错。如果你想想抄写员后来怎么样了——他们不再做抄写员了，但现在出现了一类作家和作者。这些人如今存在，是因为文学市场大大扩展了。而且我想，如果回想一下，过去抄写员的作品只有少数人阅读；而有了印刷机之后，作者数量大增，有些可能没什么读者，但有些人的影响力则超出了他们的想象。由此产生了新的职业。

我喜欢这个类比。对我来说最激动人心的是，今天我们完全无法断言这场变革、这次转型之后会发生什么。要知道，没有印刷术，我们所知的经济体系就不会存在。那么接下来呢？我们今天还无法预测、但将会出现的东西是什么？因为任何人都能做这件事了。

我们无法预测，但我觉得可以看看当下什么在奏效。看看你身边的环境，无论是对面的团队，还是软件工程师、构建者或技术人员——不管我们怎么称呼他们——在你眼中谁是出类拔萃的？他们在做什么？他们积累了哪些技能？又是怎样改变了工作方式的？

很难点名，因为说实话，这些人是我职业生涯中合作过的最优秀的人。有各种各样不同的类型。有些人是极出色的原型设计师，能把东西从 0 做到 0.5，去琢磨有哪些酷的想法、技术突破点在哪里。另一些人则特别擅长找到产品与市场契合度，大致是从 0.5 到 1，或者从 0 到 1。还有一些人横跨不同学科，而且我见到这样的人越来越多。就像我说的，有人同时横跨产品工程和基础设施工程，或者产品和设计，或者设计和工程。我觉得我见过越来越多这样的复合型人才。

从去年到今年，你有哪些想法发生了变化？也就是说，你曾经相信或坚信的某种东西，现在要么修正了，要么彻底抛弃了？

说实话，有一点我之前不太确定，那就是安全问题到底有多严重。我加入 Anthropic 是因为，就像我说的，我读了很多科幻小说，我知道如果这事往坏的方向发展会有多糟糕。但之前我对此并不确定。不过从内部观察，再看到过去一年浮现出的新风险，这让我对此担忧得多得多了。所以这对我来说曾经是件重要的事。而现在，最重要的事情就是如何确保这一切顺利发展。

可以肯定地说，早在 AI 浪潮兴起之前，你就是一名非常出色的软件工程师，而且现在你看起来依然非常高产。当然你也是团队的一员，但个人能力也很强。在软件工程师所需的技能中，哪些现在仍然很有价值，甚至可能比以前更有价值？又有哪些不那么重要了，最好放下？

大概是这样。最该放下的是对代码风格、编程语言这类东西的强烈执念。我迫不及待想越过那些无休止的语言之争、框架之争之类的讨论。因为模型可以用任何语言和框架，如果你不喜欢，它可以直接重写。所以这根本不重要了。

我觉得在今天仍然非常重要的一点是做事有条理、以假设为驱动。在一切都在被颠覆的世界里，这对产品设计很重要，我们需要弄清楚接下来该构建什么，这是每个人都在思考的问题。但这在日常工程中也很重要，比如调试，你必须非常有条理。模型也能做这件事，而且能帮上大忙。但我觉得我们仍处于一个过渡期，你仍然需要具备这项技能。我不知道六个月后你是否还需要。

我认为另一些更有价值的技能是保持好奇心，愿意做超出自己职责范围的事。如果你在搞工程，但真的理解商业端，你就能做出非常棒的产品。我觉得下一个价值十亿美元的产品，比如 Quad Code 之后，无论哪家初创公司成为下一个万亿级企业，可能都源于某个人有个很酷的想法，而他的大脑能够跨领域思考，比如同时跨越工程、产品、商业，或者设计、金融和其他什么领域。人们会越来越成为多面手，而这种能力也会越来越受重视。所以从某种意义上说，我认为这将是通才之年。

我觉得另一项实际上正在受到奖励的技能是注意力持续时间短。我现在看到这种情况正在得到回报。没错。你知道，青少年在用 TikTok 这类东西，我觉得从某些方面看这对社会有点危险，因为你希望人们能深入思考、沉思熟虑，而不是很快跳到下一个想法。但在某些方面，我觉得今年会是奖励这种状态的一年，就像是 ADHD 之年。因为对我来说，工作已经变成了在不同的云之间跳转，变成了管理各种云服务。所以重点不再是深度工作，而是我有多擅长上下文切换，能够快速在不同场景之间跳转。

我能否补充一点？从你说的所有内容来看，也许你可以加上一样东西，那就是适应力。因为你虽然提到了 ADHD 和跳来跳去，但显然你以前也非常擅长深入专注在一件事上。

让我印象深刻的是——也许其他人也是如此——你非常乐于调整自己的工作方式，去探索什么适合当下这个阶段，尤其是在世事变迁之时。我认为有一点是确定的：无论下一个模型发布会带来什么，情况都会再次改变，你需要保持好奇，并乐于调整自己的工作方式，对吧？

是的。

最后，你有什么书可以推荐吗？我近期深陷 Cixin Liu 的作品。他是《Three-Body Problem》的作者，但其实他还有很多其他非常优秀的作品。我特别喜欢他的短篇小说。他有几本短篇集。我是他的忠实粉丝。对于刚接触科幻、想读一点偏硬科幻的朋友，我非常推荐 Stross 的《Accelerando》。这本书我强烈推荐。它基本上就是未来50年的产品路线图。书中描述了 takeoff 开始发生、AI singularity 之类的情节，最后演变成了某种围绕木星运行的群体龙虾意识。

简直太棒了。我认为它真正捕捉到了那种节奏，就是这种不断加速、加速、再加速的紧迫感。这和当下的感受非常契合。然后在技术方面，我强烈推荐《Functional Programming in Scala》。即便编程语言的选择不再那么重要了，我认为函数式编程中仍有一种艺术，能教你如何更好地写代码。它会教你如何以类型来思考。如果你读这本书，我认为非常重要的一点是也要做课后习题。我通读并做完了所有习题，大概做了三遍，效果惊人。

它真的能把函数式类型的概念敲进你的脑子里，让你忍不住一直去想。

Boris，非常感谢。这次访谈太棒了。

是的，谢谢 Greg。这次对话非常有趣，而我一直在回想的是 Boris 的印刷机类比。中世纪的抄书吏是这样一小群精英，他们识文断字，受雇于国王，而国王自己往往并不识字；我们软件工程师今天可能也处于类似的境地。我们就是抄书吏。我们花了多年时间精通这门手艺，而现在印刷机正在到来。但 Boris 告诉我，抄书吏并没有消失。他们变成了作家和作者，而整个书面作品的市场扩张到了任何人都无法预见的程度。我确实觉得这个说法令人鼓舞，同时也欣赏 Boris 并没有粉饰太平。

另一件让我印象深刻的事是 Cloth 团队构建软件的方式如此不同。没有 PRDs，没有强制性的 ticketing 系统，设计师、数据科学家和财务人员都在写代码，在发布一个功能之前要构建几十个甚至上百个原型。Boris 每天发布 20 到 30 个 pull requests，而且不用手写一行代码。同时还有不同的验证机制：Cloth 的代码会自我审查、自动化的 lint rules、best of end passes，以及人工 code review。

如果你喜欢这档播客，请在你喜欢的播客平台和 YouTube 上订阅。如果你也能给节目评分，那更是特别感谢。谢谢收听，下期再见。