从 Meta 离职、加入 Anthropic，这个决定在今天看来并不意外，但在当时却并非顺水推舟。

对 Claude Code 创建者 Boris Cherny 来说，这并不是一次普通的职业跳槽，而是一种价值判断：当大模型从“工具”逐步演化为具备自主生成与推理能力的系统，工程师究竟应该站在什么位置？是把它当作效率插件，还是把它视为一种需要被认真约束、引导和共同演化的新型技术力量？

近日，Boris Cherny 做客一档名为《The Peterman Pod》的访谈栏目，主持人 Ryan Peterman 与 Boris 围绕这一系列问题展开了长达一个半小时的深度对话。

访谈的前半部分，Boris 回溯了自己从 Meta 转向 Anthropic 的动机。他并未从公司前景或个人发展谈起，而是从第一次使用 ChatGPT 的震撼说起。在他看来，大语言模型并不只是“更聪明的软件”，而更像一种尚处在早期阶段的“新生命形态”——它的能力增长呈指数级，影响范围远超工程本身，最终会重塑社会运行方式。正因为如此，他选择加入一个将安全、对齐与长期风险置于核心位置的研究机构，而不是继续在以产品速度和规模为优先目标的大厂体系内工作。

这种价值取向，也直接塑造了 Anthropic 内部截然不同的工程文化。在鲍里斯的描述中，Anthropic 依然保留着创业公司式的“常识感”：工程决策不需要层层说服，安全不被视为拖慢产品的负担，而是与模型能力同步演进的前提条件。随着模型能力提升，风险不再只是内容失误或选举操纵，而是逐步逼近生物安全、社会系统性破坏等更高等级的问题。这并非科幻设想，而是工程师当下必须正视的现实边界。

在此背景下，Claude Code 的诞生与演进，成为这次访谈的另一条主线。Boris 坦言，Claude Code 在相当长时间里并不是一款“好用的产品”。它之所以最终跑出来，并非因为早期体验领先，而是因为团队在一开始就选择“为未来六个月后的模型能力而设计”，而不是围绕当下模型的短板打补丁。

随着 Sonnet 和 Opus 4 等模型上线，Claude Code 从辅助工具迅速跃迁为主力生产方式，在 Anthropic 内部，大量代码已经由模型生成，工程师的角色也随之发生变化。

但这并不意味着“氛围编码”可以无条件替代人类判断。Boris 反复强调，模型生成的代码与人写的代码必须接受同一套质量标准：不合格就不合并。不同任务对应不同协作方式——原型、临时代码可以交给模型快速推进，而核心逻辑仍需要工程师逐行审视。这不是“人被 AI 取代”，而是人类工程师与模型之间形成一种新的协同分工。

更重要的是，Claude Code 的使用场景正在溢出传统的软件工程边界。数据科学家、分析师、甚至销售团队，都在把它当作通用的工作执行工具，连接数据库、业务系统和数据源完成实际任务。这种扩散并非最初的产品设计目标，却揭示了一个趋势：当“写代码”本身变得门槛更低，软件能力正在被重新分配到更多角色手中。

贯穿整场对话的，是一个清晰却并不轻松的判断：软件工程正在经历一次结构性重写。工程师不再只是代码的直接生产者，而正在成为“智能体系统”的设计者、管理者和最后的责任人。Claude Code 只是一个具体案例，但它所揭示的，是一个更大的变化——当模型能力以指数级提升，工程文化、工作方式乃至风险边界，都必须随之重构。

以下为访谈实录，经由 InfoQ 翻译及整理：

Claude Code 创建者，职业生涯起步于 Facebook

Ryan：我想从你晋升为 Meta 高级工程师开始讲起你的故事。你晋升的那些项目背后有什么故事？当时你在哪里？

Boris：如果我没记错的话，这个项目叫做“群组聊天”，目的是为了让 Messenger 和 Facebook 之间的联系更加紧密。

我在 Meta 参与的最初几个项目都与 Messenger 和 Facebook 有关。第一个项目是扎克伯格提出的将 Messenger 聊天记录和 Facebook 群组同步的想法。当时有几个项目旨在拉近 Messenger 和 Facebook 之间的距离。

最初的动机是，我们感觉公共空间社交产品正在消失，而人们的注意力更多地转移到聊天和更随意的实时空间。我们尝试了几个产品版本，最终“聊天和群组”版本取得了成功。

我记得当时应该是第三个或第四个项目。那时我在 Facebook Groups 部门，主要负责 Messenger 的相关工作，但 Messenger 的组织架构和我们离得很远。这个想法是当时的 PM Steve 提出的。我听了之后觉得，好啊，太棒了！就这么办！我就开始着手开发。很快有了进展，于是我申请了更多工程师，有三位工程师加入了。

我们获得了一些数据科学和设计方面的支持。项目最初在网页端启动，后来也稍微拓展到了移动端。我们验证了在 Facebook 群组内进行聊天的想法，并证明了这类产品是可行的。当然，也有很多方面最终都失败了。

以现在的产品标准来看，当时的体验简直糟透了。那时候，大家都在用 Web 开发，各种各样的 bug 都完全可以接受。但现在，视觉效果和质量标准要高得多。产品不断发展壮大，而我们团队很小，所以每个人都得包揽所有工作。

我记得当时我们没有用户研究员，所以我会在午餐时间去食堂。我们会推出一个新功能，然后向食堂工作人员展示，问他们能不能找到打开聊天窗口的方法。有时候他们能找到，有时候找不到。

这是一项观察性用户研究。你可以观察人们在特定情况下如何完成任务，而无需过多提示，从而了解他们在哪些方面遇到困难，以及最终取得了哪些成果。我教会了团队如何进行这项研究，很快我们就会利用午餐时间去食堂，询问食堂工作人员（作为用户的代表）这种方法是否合理。

Ryan：有趣的是，你当时所处的早期 Facebook 文化允许工程师们在代码之外做很多事情。例如，你当时在做用户体验研究。我记得在你的经历中，你也做过一些设计工作，并且指导过其他人进行设计。我认为这在 Facebook 的企业文化中是一个非常有趣且独特的事情。对吗？

Boris：我觉得这一点非常重要。直到今天，在我所在的 Claude 团队中，我们仍然非常重视通才型人才。

我喜欢和通才共事。如果你是一位既会写代码又能做产品开发、设计，并且具备产品意识的工程师，那么你肯定想和用户交流。我非常喜欢和这样的工程师一起工作。现在我们所有职位都是这样招聘的：我们的产品经理会写代码，我们的数据科学家会写代码，我们的用户研究员也会写一点代码。

我非常喜欢这些通才。我的成长经历也是如此。从 18 岁创办第一家公司开始，我就得事事亲力亲为。在加入 Facebook 之前，我也一直在一些规模较小的公司工作，那里也一样，什么都得做。在大公司里，你可能会被安排在某个特定领域，但这其实只是个形式。工程技能的范围很广，除了编写代码，完成整个流程还有很多其他方面需要考虑。当时能在一家真正重视这种能力的公司工作，感觉真的很棒。

我觉得在那半年结束时，我得到了晋升，然后我觉得在那半年结束后，所有的工程师也都得到了晋升。

Ryan：在那些早期产品中，存在着你多次提到的“潜在需求”概念，这正是许多产品方向的推动力。你能解释一下“潜在需求”吗？

Boris：潜在需求是产品设计中最重要的原则。纵观 Facebook 的成功产品，每一款都蕴含着潜在需求的元素。

例如，Marketplace 的诞生源于一项观察：当时 Facebook 群组中 40% 的帖子都是关于买卖物品的。Facebook 群组最初并非为商业用途而设计，但人们却用它来做这件事。你设计的产品要具有一定的可扩展性和易用性（即使被“滥用”）。然后，你分析数据，看看用户是如何“滥用”的，并以此为基础开发新的产品功能。

先是出现了 Facebook 群组，然后是买卖群组。买卖群组之所以发展迅速，是因为人们本来就想在 Facebook 群组里进行商业活动。接下来是 Marketplace，它只是人们这种意图的自然延伸。Facebook Dating 的发展也与之类似。观察发现，大约 60% 的个人资料浏览量来自互不相识的异性用户。这种传统的互相“窥探”行为证明了这种方法的有效性。

产品设计的核心原则是：你永远无法强迫人们去做他们原本不会做的事情。但你可以找到他们的潜在意图，并引导他们更好地利用这种意图，从而更轻松地实现目标。

“跨部门工作简直是一场噩梦”

Ryan：在你的叙述中，你提到你曾跨部门工作，因为你负责弥合 Messenger 和 Groups 工程团队之间的鸿沟。你说存在一些明显的文化差异，这很困难。对于在文化差异很大的组织之间工作，你有什么建议吗？

Boris：我的天哪，说困难都太轻描淡写了。简直是一场噩梦。当时 Facebook 的目标是尽快推出优秀的产品。而 Messenger 则完全专注于可靠性和性能，他们只关心这些。这完全是截然相反的价值观。

这不仅仅是文化差异或工程师之间的问题。那个团队的工程师对我们抱有戒心，因为我们的工作可能会影响他们的绩效指标。他们的组织目标是稳扎稳打，在不影响核心指标的前提下稳步推进产品发布；而我们的组织目标是快速发布。

目标完全不同。他们关注的是服务级别协议规定的正常运行时间，而我们只关注日活跃用户数和用户参与度。这些文化价值观根深蒂固，不仅体现在人们的言谈中，更体现在组织架构、目标设定等各个环节。

那个项目最终能部分成功，克服了价值观差异，关键在于：如果你想让价值观截然不同的团队成功合作，就必须找到某种共同的目标、共同的兴趣或共同的信念。让他们能够一起验证某个假设，并且如果验证成功，对双方都有益处。

Facebook 的“聊天和群组”功能很酷，但很多功能在 Messenger 上实现时却不太理想，原因就在于此。

Ryan：既然你现在知道了这些，你会如何改变现状？

Boris：我可能会去找高层（比如扎克伯格），然后说，如果你真的对这件事很认真，我们应该把 Messenger 并入 Facebook 的组织架构下。我觉得这件事后来确实以某种形式发生了。Messenger 最初在公司里，后来搬了出去，然后又搬了进来，之后又搬了出去。公司这么大，这种情况难免发生。

但我认为，从根本上来说，这类事情要想成功，不能只靠普通经理去协调。可能需要更高层的介入，调整组织架构，让它们更具合作性。

Ryan：在你职业生涯的这个阶段，我看到你做了很多非常有趣的副业项目，我很好奇这些项目会产生怎样的蝴蝶效应。例如，在你加入 Meta 之前，你曾参与过 Undux 的开发，这是一个 React 的状态管理框架。我很好奇这段经历对你的职业生涯产生了怎样的影响？

Boris：对我来说，支线任务非常重要。我招聘工程师时，这绝对是我会考虑的因素之一。我想要那些有副业项目的人，比如周末可以做一些有趣的事情。甚至包括那些对制作康普茶充满热情的人。你需要的是那些对工作以外的事物充满好奇心和兴趣的人。这些人全面发展，我喜欢和他们一起工作。我的很多成长都来自于参与这些副业项目。

说实话，像 Undux 这样的工具，源于我觉得当时用 React 管理状态太复杂了。当时最先进的技术是 Flux，后来又出现了 Redux，但我完全搞不懂 Redux。我自认为只是个水平一般的产品开发工程师，不是那种技术高超的系统工程师。Redux 的概念，比如 reducer，更新一个小小的状态都需要非常复杂的流程，我理解不了。

所以我做了一个更简单的版本，效果不错。当时我在一家非营利组织做志愿者，他们开始使用这个版本，他们的工程师也很喜欢。加入 Facebook 后，我发现很多人在使用 Redux 时遇到困难，公司内部有一个 Redux 用户群，里面有很多问题，和我当初问的都一样。

当你作为工程师遇到问题时，有时可能只有你一个人遇到；但很多时候，其他人也会遇到同样的问题。培养一种“直觉”，能够预判其他人可能也遇到的类似问题，这非常重要。我遇到的这个问题显然是其他人也遇到的，我在用户支持帖子里也看到了。

我在公司内部推出了 Undux。它还不错；虽然算不上很棒的产品，但比 Redux 简单。在 Facebook 的时候，我不知道该如何推广它，所以我就发帖宣传了一下。结果有几个人开始用了。我记得通知团队的 Jeff Case 是这项功能的早期积极使用者，我们因此熬了好几个通宵，调试一些棘手的通知相关 bug。

为了推广这项功能，我写了个小脚本，抓取了提交问题的用户群体，并按团队进行了统计。我通过聊天工具联系了每个团队的技术负责人和经理，并为每个团队安排了一场技术讲座。在几周的时间里，我大概做了二三十场，甚至四五十场技术讲座。我记得当时骑着自行车在 Meta 园区里四处演讲，感觉特别棒，因为大家都很投入，也很兴奋有人关心这个问题并想解决它。

曾经，Undux 是 Facebook 最流行的状态管理框架之一。但很快它就被 Recoil 和其他更现代的方案取代了。如今，Relay 之类的框架又开始流行。

Ryan：这种副业项目会出现在你的绩效考核中吗？或者对你有什么帮助？

Boris：我觉得它应该写在我的绩效考核里了。按 Meta 的标准来说，这算是锦上添花。它本身并不能让你直接晋升到下一个级别。那段时间我还有很多其他的支线任务。

后来，我突然对 TypeScript 非常着迷。这是我之前在一家公司用过的。当时相关的资源不多，所以我开始写一本关于它的书，因为总得有人做这件事。这门语言太棒了，设计非常出色，包含了很多当时其他语言不具备的理念，像条件类型、字面量类型、映射类型之类的，简直太疯狂了。即使是最资深的 Haskell 程序员也会惊叹，但之前却没有人系统性地写过这些内容。

我当时完全沉迷其中，写了这本书，几乎耗尽了我整整一年的业余时间。我不推荐别人也这样做，但深入研究的过程真的很有趣。当时我还在旧金山创办了世界上最大的 TypeScript 聚会。能见到 Node.js 的创始人 Ryan Dahl 以及其他这些著名的 JavaScript 大咖，真是太棒了。这让我意识到，他们也只是普通人；每个人都能创造出很酷的东西。

Ryan：后来你在 Meta 工作期间，或者甚至在 Anthropic 工作期间，最终有没有大量使用 TypeScript 或达到那种技术深度？

Boris：是啊，说起来挺有意思的；我以前其实对编程语言本身一点兴趣都没有。大概十年前，我骑摩托车的时候出了一场很严重的车祸，双臂都骨折了，身上绑着两个吊带。

Ryan：我的天哪。你是怎么写出代码的？

Boris：那才是最难的部分。我整整一个月都不能写代码，而且我的手现在还有点疼。我写不了 JavaScript（按键多），所以我不得不学习其他按键次数更少的语言。我一开始学的是 CoffeeScript，因为它的括号比较少。这门语言现在应该已经没什么人用了。我也是通过 CoffeeScript 接触到 Haskell 和函数式编程的。你可以用更少的击键次数完成同样的事情，这正是我当时的动力。

在加入 Facebook 之前，我在一家对冲基金工作，我的同事 Rick 对 Scala 非常着迷。他带我入门，也让我接触到了函数式编程。如果让我推荐一本对我的工程师生涯影响最大的技术书籍，我会毫不犹豫地推荐《Scala 函数式编程》。你可能永远不会每天都用 Scala，但它教你思考编程问题的方式，与大多数人在学校或实践中接触的方式截然不同，这彻底改变了我的编码方式。

对我来说，Scala 和 Haskell、CoffeeScript 一样，是少数几种改变我思维的语言。第一步是 CoffeeScript，然后是 Scala，再然后是 TypeScript。这改变了我的思维方式，因为现在我编码时会用类型来思考。代码中最重要的就是类型签名，这比代码本身更重要。做好这一点能写出非常简洁、健壮的代码。

即使在 Facebook，我主要用 Flow 和 Hack，后来在 Instagram 用 Python，这种思维方式也很有帮助。在 Anthropic，我主要用 TypeScript 和 Python，所以这一点仍然非常重要。更重要的教训就是要学会用类型来思考。

Ryan：在你职业生涯的这个阶段，你提到你刚入职时级别偏低，只是个中级工程师，尽管你经验丰富。你说现在回想起来，当时级别低反而是件好事。我很好奇你当时是怎么想的。

Boris：在大公司里，对于项目影响和人员影响方面都有很多期望，具体标准因公司而异。很多事情要么关乎项目的影响，要么就是为了完成一堆任务，而这一切都非常耗时。刚开始的时候等级不够，反而给了我探索的空间，让我可以纯粹为了创造而创造，没有太多绩效压力。

Ryan：没错。我很好奇这是否也有助于积累势头。如果你以中级级别加入，然后表现出色，所有人都会说“Boris 太棒了”。这很不可思议。而如果你以更高预期级别加入，表现平平，情况就完全不同了。当你一加入就让所有人眼前一亮时，会产生一种奇妙的效果，你会给人留下非常深刻的第一印象。我认为这有助于建立良好的声誉，从而在未来获得更多的信任、更多的项目等等。

Boris：是的，我觉得完全正确。这对于任何公司来说都是很好的建议。很多时候，工程师跳槽的时候会非常积极地争取更高级别，比如“我想去另一家公司，我想升一级”之类的。这样做有很多弊端。

Ryan：接下来我想问一下是什么让你在 Meta 晋升为资深工程师（E6）。我很好奇你当时的职位，以及是什么推动你晋升到这个更高层级的领导岗位。

Boris：当时的情况是，Facebook 推出了群组聊天功能，并且有一个团队负责开发。在加入 Facebook 之前，我写过很多 JavaScript，但在 Facebook 内部，我之前从未真正写过 JavaScript，因为当时主要用 PHP。我真的很想写 JavaScript。

我们当时专门为 Facebook 群组开发了一个网页界面。很多人使用网页版而不是手机版，因为群组管理员在电脑上用键盘操作起来更方便。但当时这个网站真的很糟糕，它是一个静态网站，完全用 PHP 编写，只是在不同的地方零散地注入了一些 JavaScript 代码，结果导致了各种不一致的状态和问题，用户体验很差。

我当时想用 JavaScript 重写整个界面，但遭到了公司内部的强烈反对，主要原因是我们已有的基础设施还没准备好。幸运的是，与此同时，Comet 项目启动了，该项目旨在重写 facebook.com 的桌面版。

当时有很多核心成员在做这个项目，我真的很想参与。我主动联系他们，询问我能如何帮忙，并提议先在 Facebook 群组里进行测试和探索。我几乎是没问任何人就直接开始做了。

后来，我跟 Facebook 群组部门的领导们说：“嘿，Comet 项目马上就要全面推行了。这会是一项艰巨的工作。但我们可以提前做好准备，为所有其他团队树立一个迁移标准，并与其他团队建立联系。”我仍然遇到了阻力，比如他们说“你不能安排 20 个工程师来做这件事”。经过多次讨论和讨价还价，我们最终组建了大约 12 名工程师的团队，因为这是一个相当大的迁移项目，大约需要一年时间。

“群组”是 Facebook 所有产品中规模最大的一个，这有点出乎意料。这次迁移很成功。除了与这个基础架构团队建立联系和友谊之外，有趣的是，我们因此有机会影响 Comet 项目的发展方向。对于基础设施项目而言，产品团队通常无法左右项目方向，他们更像是客户。但在这个项目中，由于我们早期深度参与，我们创建了许多抽象概念，后来被其他基于 Comet 进行开发的团队所使用。

举一个具体的例子，比如“中继变更”。你需要发送 API 请求，并且需要某种状态一致性。之前存在一个 bug：假设有一个按钮，每次按下它都会发送一个 POST 请求。为了良好的用户体验，你希望在按下按钮后，按钮的状态立刻切换，这需要使用乐观更新。当网络请求返回时，你还需要更新本地缓存以确保一致性。但如果你连续快速点击按钮，响应可能会乱序到达，最终得到的状态可能与用户界面上显示的状态不同。

我写了一个系统来排队处理这些变更，这样虽然保证了一致性，但牺牲了一点即时性。在当时这是一个合理的权衡，这个方案最终被广泛采用。我就是在这个过程中认识了 Joseph 和 Relay 团队里负责数据存储的其他人。这段经历真的很有趣。每当我看到工程师深入钻研，努力弄明白复杂系统到底发生了什么时，我都很欣赏。产品工程师并不意味着你不能构建基础设施，基础设施工程师也不意味着你不能和用户交流。对技术栈的其他部分保持好奇心就好。

成功搞定大项目后，才有更多话语权

Ryan：当然。你抢先一步进行 Comet 迁移和大规模的 JavaScript 重写，正如你提到的，这实际上让你拥有了更大的影响力和话语权。你所说的机会，是指构建这些对所有使用新平台的人都至关重要的基础产品架构吗？

Boris：是的，这就是一个例子。另一个例子是，Comet 的质量比之前的版本高得多，因为它是一个单页 Web 应用，所以感觉更加流畅和完善。但我们当时还没有完全弄清楚“产品层面的质量”究竟意味着什么。我写了很多笔记试图定义它，也做了很多演讲，向其他团队的成员讲解我们对质量的理解，并就此展开讨论，共同塑造标准。

Ryan：您提到迁移到 Comet 需要大量人手。我很想知道，如果现在有了 Claude Code、Codex 等新的 AI 编码工具，情况会是怎样的。以您现在对 Claude Code 的了解，如果您负责评估这项工作，您认为现在需要多少工程师才能完成原本需要 12 名工程师花费一年才能完成的工作？

Boris：为了迁移 Facebook 群组，最初是 12 位工程师，但最后可能动用了 20 到 30 位工程师，持续了大约两年时间，最终变成了一个相当大的项目。现在来看，可能只需要 5 位工程师，耗时六个月左右就够了。

Ryan：也就是说，只需要四分之一的时间，以及不到一半的工程师？

Boris：是的，因为现在你可以让 AI 并行工作。你让它运行几个小时，它就能生成一个可用的 PR。你甚至可以给它装上 Puppeteer 之类的工具，让它能看到 UI 并进行视觉调整。大概就是这样。现在，从编码的角度来看，环境已经截然不同了，因为模型更新迭代太快了。如果你三个月或六个月后再问我这个问题，我的答案肯定会完全不同。六个月后，答案可能就变成了：这实际上只需要一个工程师就能完成。现在的变化实在太快了，很难做出准确的估算，也很难预测它们未来会如何演变。

Ryan：在你职业生涯的这个阶段，你曾提到过一件事，也许是半开玩笑地说，那时你学会了在向副总裁评审提案时，总是提出三个选项。因为 80%的情况下他们只会选择中间的那个。你这么做的想法是什么？

Boris：这话虽然有点讽刺，但或许当时在 Meta 公司那种特定环境下有点道理。那些远离一线具体工作的决策者，他们想知道你是否认真研究过各种方案和权衡利弊，是否真的做了充分的工作。但同时，他们也想以某种方式参与决策。提供一个“折中”选项，对他们来说比较容易理解和接受。我这么说确实带有讽刺意味，因为并非所有领导者都这样。很多领导者会亲自深入参与决策，他们或多或少信任自己的团队。管理风格有很多种。我记得当时我们有一位技术水平可能不那么深入细节的领导，而这种方法算是帮助她进行决策的一种沟通方式。

Ryan：在你职业生涯的这个阶段，你与高层管理人员的接触最为密切。你提到你曾向一位高级总监汇报工作，并且参与了很多重要的项目规划讨论。我很好奇，向这样一位资深人士汇报工作，对你后续的成长产生了哪些影响？

Boris：是的，我觉得这很大程度上取决于工程师个人和公司文化。比如，我现在在 Anthropic，我觉得在 Anthropic，你向哪个层级汇报并不重要。公司里一些最资深的员工也是向部门经理汇报的。很多部门经理本身就是前首席技术官或非常资深的人士，所以实际上这并不构成障碍。

我认为向高级别汇报带来的压力，在某种程度上是 Meta 公司特有的文化现象。我觉得这里存在两种情况。一是，在 Meta，你需要非常主动地找到自己的发展方向和上升路径。有些机会你可以自己发现，有些则需要你的经理或技术领导帮你识别和引荐。

Meta 的 PSC（绩效评估）流程出了名的严苛，你必须不断地强调和证明你的影响力。而“职责范围”是造成这种严苛体验的最大因素。如果你有足够大的职责范围，并且执行得当，就能产生显著的影响力。这就是秘诀。

我觉得在 Meta，另一个特点是大家都没有很花哨的头衔。即使是最资深的工程师，头衔也只是“软件工程师”，我非常喜欢这一点。贝尔实验室的技术人员也是如此，Anthropic 也是如此，但我们在这里更进一步：所有人的头衔都是“技术人员”。不管你是工程师、项目经理还是设计师，头衔都一样。我其实很喜欢这样，因为这样一来，你就可以跳出自己被默认设定的职责范围，去做那些你认为正确和必要的事情，而不用过分在意别人期望你做什么。我认为这种文化正是促成这种灵活性的原因。

Ryan：我看到了不设复杂头衔的很多好处。但我也能想到一种情况，也许这只适用于大公司：当你联系公司里的某个人，说“嘿，我想参与这个合作”，如果你的头衔是“总监”之类的，这就能让他们更容易理解你的层级、影响力和协作方式。如果你是设计师或其他职位，在 Anthropic 规模扩大了一些的现在，你感受到这一点了吗？也许因为大家现在都认识你，所以你没怎么感受到。

Boris：是的，这绝对是一个潜在的缺点。但我认为优点大于缺点。那就是你必须努力争取，用实力和贡献赢得尊重。我觉得这条原则无论在哪家公司都适用。仅仅因为你以前做过一件很棒的事，并不意味着你在新的环境里就理应自动获得权力和尊重。当然，每个人都应该得到基本尊重；但这不意味着你在一家新公司、一个新项目中就理应拥有决策权。即使是那些一开始就拥有“经理”头衔的人，也需要努力争取团队的信任。在某种程度上，拥有经理头衔反而可能让赢得这种信任变得更难。作为独立贡献者，无论如何你都必须用行动证明自己。我认为，正是因为没有那些预设的、等级森严的头衔，才使得这一切变得稍微容易一些，更注重实际贡献。

如何从技术人转型为高管

Ryan：在你职业生涯的这个阶段，你逐渐转型为技术主管或高级技术主管，我记得你讲过一些为数百名工程师制定工作计划的故事。你是怎么做到的？如果工作量如此庞大，而你又只有一个人，你是如何向领导层提出如此大规模的工作计划请求的？

Boris：是的，那段时间真是太疯狂了。我当时和蒂娜·萨奇曼共事很多，她现在在微软，但当时是我的经理。然后是我的上级伊芙。当时公司决定对 Facebook 群组投入更多资源。我刚加入的时候，群组部门大概只有 150 到 200 人，等我离开去 Instagram 的时候，好像已经有 600 到 800 人了。扎克伯格一直觉得 Facebook 应用的核心应该是社群，他希望我们加快速度，把这个想法变成现实。

作为高管，最重要的就是让合适的人负责决策，然后给他们提供资源。在 Meta，资源主要就是工程师。我们向扎克伯格推介了这个名为“社区即新组织”的内部项目。他为此投入了一大批人手，我们只需要弄清楚这些人具体要做什么。对他来说，如果事情很重要，就得投入大量人力。事后看来，我会采取不同的做法，大幅减少初期投入的人员，因为真正重要的是解决用户的问题，打造出色的产品，这必须自下而上地进行，需要随着新产品线找到市场契合点而逐步推进，不能一口气做完所有事情。

但当时，我们必须先把所有事情都规划好。有好几个星期，我都要写一份庞大的规划文档，内容大致是：“好，我们要安排 30 个工程师负责 A 项目。这里有三个技术方案，我们选方案二。下一个 B 项目，我们要安排 20 个工程师。这里有三个方案，我们选方案一。”就这样一遍又一遍地重复，才能确保这个庞大的项目计划不是完全异想天开。我们进行了一些基础的技术范围界定，大致估算了每个子项目需要的工程师人数。

其中有些事情很有意思。我记得我们曾经尝试合并 Facebook 群组和主页的数据模型。那真是一次非常棘手的迁移。要彻底实现这一点，需要很多年时间，可能还需要数百名工程师，因为必须跨数据模型、产品层、完整性系统和广告系统进行操作。当时，Yosef Carver 刚刚加入；我记得他之前在 Profile 或 Events 部门工作，这两个部门与 Groups 部门合作推进这项工作。他当时正在研究这个问题，但还在犹豫不决，无法就数据模型做出最终决定。

于是我召集了一群人，说：“好了，公司所有相关的技术主管都来了，我们今天花三个小时，像玩游戏一样，来讨论一下架构设计。”我把大家分成两队，好像是蓝队和绿队（记不清了）。我们给每个人布置了同一个问题：如何合并这些数据模型，并给出了具体的要求。每个人都有三个小时的时间在白板上设计方案。

最酷的是，一开始我们都觉得这个问题棘手，不知道该怎么做。但最后，我们两队得到的两个方案竟然有 80%的相似度！我们可以采取的行动变得非常明确，而那 20%的差异也清楚地揭示了风险所在。我们可以通过一些技术性操作来预先承担一部分风险，但我们也清楚地知道可以立即开始执行哪些部分。

Ryan：是啊，我觉得这个形式很有意思：就像一个技术设计竞赛，所有资深工程师都参与其中，分成几个小组，在不同房间里同步进行设计。我以前从没听说过这种形式。你当初在公司内部提出这个设计竞赛的想法时，大家是觉得很兴奋，还是觉得这有点异想天开？

Boris：是有点非常规。这种事，你只能硬着头皮去做，靠行动推动。我直接跟所有相关的人说：“嘿，我们要这么做了”，然后就把会议日期记在了每个人的日历上。感觉挺有意思的；作为工程师，你肯定也想参与这种创造性的解决问题的过程。但有时候你需要漫长的过程来达成共识，有时候你则需要快速行动来打破僵局。

在这种情况下，由于技术方向不明朗，采取行动至关重要。但同时，我自己也不知道确切的最佳路径，所以我们必须召集所有关键人员，通过这种高强度、高协作的方式快速达成共识。作为技术领导者，你总是需要在“推动共识”和“果断行动”这两件事之间寻求平衡。

Ryan：有了那次为数百名工程师规划项目的经历，你对那些需要快速进行项目范围界定的技术主管有什么建议吗？有什么对你来说行之有效的方法或原则？

Boris：我觉得我看到的最大问题是人们花费的时间太长，而且过于纠结细节。细节总是无穷无尽的。最好从宏观层面入手。大多数技术范围界定都可以在 30 分钟内完成一个非常粗略的版本。

如果你不了解所涉及的系统，现在你甚至可以让 AI 来帮忙。你只需要在代码库中运行一个查询，或者直接问 AI：“要实现 X 功能，会涉及代码库中的哪些系统和模块？”它实际上可以帮你快速梳理出依赖关系。这真是个不可思议的改变。我以前做这些事情的时候，绝对想不到人工智能现在能帮我做到这些。

但回到一般性原则，我过去的建议是：设定严格的时间限制。用于初步范围界定的会议最多花 30 分钟。如果需要深入研究代码，最多几个小时。一定要联系专家，并列出所有需要咨询的专家名单。和他们所有人交流。但不要只是泛泛地征求他们的意见。给他们一个具体的假设或初步设计方案，这样他们才能真正给你有建设性的反馈，你才能以此为依据进行迭代和完善。

Ryan：继续你的职业经历。你晋升到高级职位的关键，似乎和 Facebook 的“公共群组”项目有关。我很想了解这背后的故事，以及其中发生了什么有趣的事？

Boris：是的。“公共群组”项目源于我们想让 Facebook 群组更开放。我们当时想做一个看似简单、但实际非常复杂的改动：让用户无需加入，就能查看和评论公开群组的内容。

这听起来像改一行代码，但实现起来异常困难。因为它触及了核心的数据模型问题：在数据库里，一个发表评论但未“加入”的用户，到底算不算“群组成员”？这引发了我们内部激烈的技术讨论。

过去的“加入”需要管理员批准，是一种信任投票。现在对于公开群组，行为变成了“关注”。那么，“关注”和“加入”在数据层面应该是同一回事吗？当时公司里一位资深的元老级工程师鲍勃，强烈认为这必须是两件不同的事，并要求进行大规模的数据迁移来区分它们。

这还引发了连锁反应：如果任何人都能评论，垃圾信息怎么办？我通过一个简单的蒙特卡罗模拟，展示了潜在的垃圾信息风险，最终成功说服了公司的诚信团队介入，帮助调整评论排名算法来应对。

为了完成数据迁移等所有工作，我们组建了一个大团队。当时我和其他几位资深工程师同级，都需要我来协调指导，这让我一度感到有些“冒名顶替”。但最终，正是因为我推翻了之前鲍勃关于数据迁移的决定，才促成了我后来的晋升。

我经过审核发现，最初的“成员”字段其实完全可以同时表示“关注者”和“群组成员”，强制区分只会让后续所有开发变得复杂。我敦促负责的工程师撤销了那次迁移。这个正确的技术判断，反而让鲍勃更认可我作为技术领导的能力，因为我能基于事实对资深人士的决定提出异议。

Ryan：你和高级技术主管之间存在严重技术分歧，但结果反而加强了关系。对于如何处理这类分歧而不损害关系，你有什么建议？

要敢于挑战权威

Boris：我认为核心是赢得信任。在你拥有足够的技术信任之前，很难去挑战权威。一开始，可以更多地倾听、执行，表现出尊重和合作意愿。同时，你必须通过实际行动积累扎实的技术判断力。在赢得信任后，你基于事实和专业提出的异议，才更容易被接受。

Ryan：关于“冒名顶替综合症”，以及领导那些和你同样优秀的工程师，你有什么建议？

Boris：别想太多。其实没人真正知道自己在每个新层面上具体该做什么，大家都在摸索。这种感觉会随着时间慢慢消失。某种程度上，始终保持一点点“冒名顶替”感是健康的，那说明你还在努力突破舒适区。

Ryan：在你职业生涯的这个阶段，你更像技术主管，编码减少。你曾提到，在 Meta，有时其他职能（如产品经理）支持不足，你认为这是让工程师更多关注产品、甚至参与产品管理的机会。你如何决定何时该自己顶上，而不是反复要求更多支持？

Boris：关键在于理解利弊和背景。你需要从决策者的角度思考：他们关心什么？手头有哪些项目？做这件事的代价是什么？是否能帮他们成功？有些组织可能确实资源紧张，或认为你的项目优先级不够。有些组织则可能资源充沛。了解你所在的环境和决策者的处境，才能判断是应该自己主动补位，还是能够争取到资源。

Ryan：你将自己的成功很大程度上归功于“副业项目”。你对工程师如何寻找这样的机会有什么建议？

Boris：我的很多想法来源于日常工作中那些重复、繁琐的部分。工程师的超能力就是自动化。我养成了一个习惯：在代码审查中，如果我多次评论同一类问题，我就会写一条规则来自动化检查它。很快，我几乎自动化了所有代码审查。

这些“副业”往往就是去改进那些拖慢日常开发速度的基础设施或工具。这不仅能解放自己，也能惠及整个团队。一个核心原则是：如果你遇到了某个问题，很可能其他人也遇到了。为自己打造解决方案，往往就是为很多人打造解决方案。

为何从 Meta 转向 Anthropic

Ryan：你从 Meta 离职加入 Anthropic，当时是怎么做出这个决定的？

Boris：我第一次用到 ChatGPT，是它刚推出不久的时候。当时我在日本，一个小地方，几乎没有人能和我讨论技术。我每天刷 Hacker News，用到 ChatGPT 后的第一反应是：这东西太不可思议了。

现在回头看我们已经习以为常，但当时的大模型给我的感觉，更像是一种“新生命”。它不仅是一项技术，而是一种可以被培育、被引导的存在。我本人很喜欢科幻小说，尤其是硬科幻，所以当我意识到这类模型意味着什么时，心里只有一个想法：我一定要参与其中。

后来我去了解哪些实验室在做这件事，也和一些在不同研究机构工作的朋友聊过。第一次和 Anthropic 的创始团队吃饭时，我随口提到了一本科幻小说，结果发现桌上几乎所有人都读过，还能继续讨论别的作品。那一刻我意识到，这是一个真正认真思考“这些技术会把世界带向哪里”的地方。

人工智能正在改变社会，而且是从工程领域开始，逐步扩散到各个层面。我也很清楚，这项技术存在很多潜在风险，甚至可能走向非常危险的方向。对我来说，加入 Anthropic 几乎是顺理成章的选择——如果我能做点什么，那就是站在一个真正把“安全”和“长期影响”当回事的地方。

在 Meta，安全往往被当成一种负担，是和产品对立的事情。但在 Anthropic 完全不同。我们在安全和对齐研究上投入了大量算力和人力，甚至因为不确定模型是否足够安全而推迟发布。随着模型能力提升，风险也在快速上升，这已经不是科幻，而是现实问题。我很庆幸自己能参与其中。

Ryan：加入 Anthropic 之后，你感受到的工程文化和以前最大的不同是什么？

 

Boris：有两点特别明显。第一，公司虽然已经不小了，但仍然保留着创业公司的“常识感”。很多事情不需要复杂的流程去推动，大家天然会做正确的决定。这是大公司最容易丢失的东西。

第二，对我个人来说，最重要的是使命感。它让我每天都愿意来上班，甚至周末也愿意写代码，不是因为 deadline，而是因为我想这么做。我在 Facebook 群组项目里感受过类似的氛围，但在 Anthropic，这种感觉更强烈，也更一致。

Claude Code 为什么能跑出来

Ryan：你是 Claude Code 的核心推动者之一。当初市面上也有不少类似工具，Claude Code 真正不同的地方在哪里？

Boris：一开始，大家对“AI 编程”的理解非常狭窄，基本等同于自动补全。即便有一些智能体的概念，也更多是问答工具，而不是能真正参与编程。

坦白说，在很长一段时间里，Claude Code 本身也并不好用。即便在内部，我可能只用它写了不到 10% 的代码。关键在于，我的主管一直提醒我：不要按“现在的模型能力”来设计产品，而要按“六个月后的模型能力”来设计。

后来 Sonnet 和 Opus 4 发布后，一切发生了变化。短短几个月，我自己有一半以上的代码都交给 Claude Code 来写。现在在 Anthropic，很多团队 80% 到 90% 的代码都是用 Claude Code 生成的。公司规模虽然扩大了，但工程师的整体生产力反而显著提升。

Ryan：有人担心模型生成大量代码，但质量不稳定、问题隐蔽，你怎么看？

Boris：AI 编程和任何工具一样，是需要学习如何使用的。我们内部的原则很简单：不管代码是人写的还是模型生成的，标准完全一致。代码不好，就不合并。

不同场景需要不同方式。原型、临时代码，可以更“感觉驱动”；核心代码，就必须逐行推敲。大多数时候，我是和模型一起写代码：先制定计划，再让模型生成，再不断修改、清理。某些关键部分，我仍然坚持手写。

现在的模型编码能力当然还不完美，但已经是“史上最差的一代”了。一年前还只是自动补全，现在已经是完全不同的世界。

Ryan：除了写代码，你觉得 Claude Code 还能用在哪些地方？

Boris：我们公司里的数据科学家、分析师，甚至销售团队都在用它。有人用它写 SQL、跑分析、搭数据管道；销售团队把它接入 Salesforce，直接干活。这完全超出了我们最初的设计预期。

Ryan：你怎么看 Claude Code 和 Codex、OpenAI 之间的竞争？

Boris：说实话，我几乎不看其他产品。过度关注竞争对手，很容易让团队迷失方向。我们只专注一件事：解决我们自己、Anthropic 研究人员以及用户真正遇到的问题。

Ryan：你不是计算机科班出身，这对你有影响吗？

Boris：几乎没有。我学的是经济学，后来辍学创业。编程是一项高度实践性的技能，最重要的是动手做、做出产品。理论当然有价值，但对我个人来说，从来不是关键。

Ryan：你效率很高，有什么秘诀？

Boris：现在我的答案只有一个：学会用 Claude Code，而且是同时用多个。你不再是亲自写每一行代码，而是在做统筹、调度和判断。这就是工程的未来。

Ryan：你觉得工程师会不会越来越像管理者？

Boris：某种程度上是的。但我依然很享受安静地写代码。现在我每天早上都会启动几个 Claude Code 代理，让它们先跑起来，等我到电脑前再检查、合并或修改。

这听起来很疯狂，但它确实有效。甚至一些多年不写代码的管理者，现在也能重新参与进来。我们熟悉的“写代码”这件事，正在发生根本性的变化，而且正在变得对更多人开放。

参考链接：

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