深入了解 X 的 Community Notes | Keith Coleman & Jay Baxter

Keith Coleman & Jay Baxter 2025-02-27

深入了解 X 的 Community Notes | Keith Coleman & Jay Baxter

转录文本

开场预览

Lenny Rachitsky： 你们所做的工作对世界的运作方式产生了如此巨大的影响。我想先让大家简要了解一下什么是 Community Notes。

Keith Coleman： X 上的用户可以看到一条帖子。如果认为它有误导性，就可以提出一条他们认为其他人会觉得有帮助的注释。然后其他用户可以对这条注释进行评分。

Jay Baxter： 我们实际上是在寻找过去曾经持不同意见的人之间的共识。我们发现，当人们真正达成那种出人意料的共识时，注释就会变得非常中立、准确，总体来说写得非常好。

Lenny Rachitsky： 有很多人立场非常极化。你们怎么应对那些超级反疫苗的、超级挺 1 月 6 日事件的人？

Keith Coleman： 一个重要的理念是，我们希望全人类都能参与，有时候人们对此感到惊讶。我们拥有全人类（的数据），然后就有数据来判断哪些注释对真正的人类是有帮助的。每条帖子都有资格获得注释。我们不应该豁免 Elon，不应该豁免政府人物，应该一视同仁……甚至广告商也能收到注释。

Jay Baxter： 有完全独立于我们的外部研究，他们发现如果你把一条带有和不带有 Community Note 的帖子做对比，人们在看到带注释和不带注释时，对帖子核心主张的认同程度确实会发生变化。

Lenny Rachitsky： 关于在 Elon 运营的组织中为他工作这件事，还有什么可能让人惊讶的？

Keith Coleman： 如果我要在那种公司里创业，我会把它做得比我以前做的更精简。我对这个小团队能够完成这么多工作感到惊讶，我觉得正是因为是小团队——

节目介绍

Lenny Rachitsky： 今天我的嘉宾是 Keith Coleman，Community Notes 的产品负责人，以及 Jay Baxter，Community Notes 的创始机器学习工程师和研究员。这次对话可能是我迄今为止最喜欢的一期播客。Community Notes 是目前世界上最具影响力、最巧妙，同时也是最被低估的产品之一。

如果你用过 X/Twitter，并在一条推文下面看到一条纠正该推文中错误信息的注释，那就是 Community Notes。我从未听过关于这个产品背后故事和构建团队的深入介绍，我很高兴能为你带来这些。我们会谈到这个产品令人惊讶的起源故事、算法实际的工作原理、算法如何从 Twitter 内部竞赛中诞生、Community Notes 背后的原则，以及为什么忠于这些原则对其成功如此关键。还有，它如何在四位不同的领导者——包括 Elon 和 Jack——手下幸存下来，以及为什么它现在已成为解决互联网错误信息方案的重要组成部分，包括最近被 Meta 采用作为其主要事实核查工具。这是一期非常特别的节目，我非常激动能带给你。

正式访谈

Lenny Rachitsky： Keith 和 Jay，非常感谢你们来到这里。欢迎收听播客。

Keith Coleman： 很高兴来到这里。

Jay Baxter： 谢谢邀请我们。

Lenny Rachitsky： 这是我的荣幸。我非常激动能有这次对话。你们所做的工作对世界的运作方式产生了如此巨大的影响。很多产品团队总是在谈论推动影响力、想要推动影响力，而你们真正构建了以有意义的方式改变世界的东西，并且继续在做。我真的从未听过 Community Notes 是如何诞生的、如何运作的等等这些背后的故事，所以我非常感谢你们抽出时间来聊。

Keith Coleman： 是的。首先，谢谢你这么说。这就是我们构建这个东西的原因——帮助人们，很高兴听到你这样说。很高兴看到人们喜欢它、觉得它有用。

Community Notes 是什么

Lenny Rachitsky： 我想先让大家简要了解一下什么是 Community Notes。我想很多人大概听说过它，大概在 X 上见过——刷的时候看到这些注释，但他们会说：“我不太清楚这到底是什么。“所以你能否简要描述一下什么是 Community Notes？

Keith Coleman： Community Notes 是一种让公众——让普通人——为可能有误导性的帖子添加上下文的方式。它的基本运作方式是：X 上的用户看到一条帖子，如果认为它有误导性，就可以提出一条他们认为其他人会觉得有帮助的注释。然后其他人可以对这些注释进行评分。如果一条注释被那些通常持不同意见的人认为是有帮助的——这表明它可能是准确的、措辞可能是真正中立的、可能是提供有用信息的——那么它就会展示给 X 上的所有人。目标就是让人们获得更多关于他们所看到内容的信息，以便在生活中做出更好的决定。

算法如何运作

Lenny Rachitsky： 太棒了。我听到这些，觉得这能运行简直不可思议。我想人们最初听到这个想法的时候，都会说”这不可能行得通”。那么，再深入一点，你能否让我们更深入地理解它究竟是怎么运作的？因为我觉得关键是你们设计的那个算法太巧妙了，才让这一切成为可能。请谈谈那个算法。

Jay Baxter： 是的。我觉得很多人的一个关键误解是，如果他们没有真正深入了解细节，就会以为也许有人写了一条注释，它就立刻出现了，或者我们只是用少数服从多数的投票来决定谁觉得注释好。我觉得这两种做法都可能导致有偏见或不准确的注释。我认为我们做的真正关键的一点是，我们实际上寻找的是过去持不同意见的人之间的共识。

当我们看到人们真正达成那种出人意料的共识时，这正是注释之所以如此中立、准确、措辞精良的原因。那些在整体上非常极化的人，在不准确的事情上往往是找不到共识的，对吧？我认为这也提供了一些很好的防操纵特性。人们经常……如果说……回想2020年我们还没开始构建这些的时候，这到底能不能行，我想一屋子机器学习工程师会说：“哦，你必须保持闭源。人们会一直操纵这个系统。你必须使用事实核查员提供的真值标签。没有外部标签，你不可能引导这个系统启动。“但事实证明，你可以用这种我们称之为基于桥接的共识算法（bridging-based agreement algorithm）来实现。

Lenny Rachitsky： 好的。总结一下，说得清楚一些。就是人们……有人写了一条注释。这个信息是错误的……举个什么好例子呢，我们聊到这里，一个经典的例子是什么？

Keith Coleman： 一个非常经典的例子是 AI 生成的图片，或者是脱离了上下文的图片——“看看这里发生了什么。“但实际上那是五年前在另一个国家、完全不同的主题下的照片——

Lenny Rachitsky： 天哪，这种我见过太多次了，就是那种”看看旧金山发生了什么”，然后我一看，“不，这完全是另一个城市，那根本不是——”

Keith Coleman： 完全正确，是的。

Lenny Rachitsky： 好。所以有人发了这张 AI 图片。有人写了一条注释：“这实际上是五年前在另一个城市拍的。“然后这个算法帮助判断这条注释是否真实，而做这些的就是普通人。

Jay Baxter： 没错。是注册成为 Community Notes 贡献者的普通人。所以会有一些门槛，比如你必须有一个经过验证的电话号码。但归根结底，这些就是普通人，不一定是职业事实核查员之类的。

开放参与的原则

Keith Coleman： 是的，这一点对我们来说也非常重要。最开始就有这样一个问题，也是 Jay 刚才提到的——“有没有人觉得这能行？“显然，这是一个疯狂的想法。我们不知道普通人能不能完成这项任务，人们当然也担心他们能不能做得好。

最初，公司内部一些人建议说：“嘿，你们为什么不找记者或者某个特定群体来做第一批参与者呢？“但我们非常明确地说：“不。我们试图摆脱的就是围绕这件事做编辑筛选式决策的思路。这应该对所有人开放。“所以我们非常刻意地让所有人都能参与进来。参与者是随机选择的，这对于让人觉得公平、开放、值得信赖非常重要。

Lenny Rachitsky： 是的。再说一次，这听起来就像是辨别真相的圣杯，而它居然真的有效。而且效果好到 Meta 最近——大家都知道——决定采用完全一样的系统来替代他们原本数以万计的事实核查员审核内容的方式。

Jay Baxter： 我想做一个区分，也许听起来有点吹毛求疵，但我觉得很重要——Community Notes 是添加额外的上下文，它不一定是事实核查，对吧？所以有些情况下帖子本身可能是真的，但只是有误导性，因为没有上下文或缺少上下文。这些情况我们也能覆盖到，我觉得这是一个重要的区别。我们的理念就是用户应该能够自己做判断，对吧？就像”这里是额外的上下文，接受不接受随你。“

Community Notes 的趣味案例

Lenny Rachitsky： 对。我想起来了，你跟我分享过这个例子——一张猫的照片，然后有人的 Community Notes 就写了”那是一条狗”。还是反过来，那个——

Jay Baxter： 对。原帖是”一个巴勒斯坦男孩把面包分给一只狗”，配了一张猫的照片。所以这条注释确实不是特别必要，因为它只是说”那是一只猫”，然后附了一个猫的维基百科链接。这是一个很好的例子，说明这个系统——这不是什么职业事实核查员会觉得需要核查的事情。但它证明了归根结底这个系统确实是由用户在运行，而且也增添了一些喜剧效果吧。而且注释本身是正确的。

Lenny Rachitsky： 好，这很重要。

Jay Baxter： 是的。

什么样的帖子可以触发 Community Notes

Lenny Rachitsky： 一条帖子什么时候会触发 Community Notes 的审核？有没有一个门槛？还是说你可以给任何帖子写 Community Notes，然后由人们来投票决定？这是怎么运作的？

Keith Coleman： 每条帖子都有资格获得注释，这又是一个非常重要的原则。就像——“我们不应该豁免 Elon，不应该豁免政府官员，我们应该……”所有人，甚至广告主，都可能被加上注释。所以平台上的任何帖子都可能获得注释。你在实际中可以看到，注释出现在世界各国领导人、Elon、广告、媒体机构的帖子下面，当然也出现在普通社交媒体用户的帖子下面。但没错，核心理念就是一个公平的竞争环境。要提出一条注释，提出者必须已经获得了写注释的资格。所以确实有这方面的要求——你必须先取得资格才能做这件事。而获得这个资格的方式是通过你的评分记录来证明你有能力帮助识别那些被广泛人群认为有帮助的注释。基本上，如果你有能力辨别、识别什么对很多人来说是有帮助的，那你就获得了开始撰写注释的资格。

Lenny Rachitsky： 我其实注册成了……你们怎么称呼这些人？写注释的——

Jay Baxter： 贡献者（Contributors）。

Lenny Rachitsky： 好，贡献者。是的，我一直在评分。我还没有达到——

Keith Coleman： 不错。

Lenny Rachitsky： 我还写不了注释。

Keith Coleman： 是的，这不是特别容易，需要一些努力。

Community Notes 的规模

Lenny Rachitsky： 你能分享一些关于目前 Community Notes 规模的数据吗，尤其是那些可能会让人们感到意外的？

Keith Coleman： 好的。这个服务正在快速增长，目前每天有数百条注释。作为一个对比参照，我最近看到 UC Berkeley 有人提供的数据，说传统的专业事实核查每天大约只有10条。相比之下，每天有数百条注释被展示出来。它们涵盖的话题非常广泛——从显而易见的政治、新闻，到娱乐、体育、游戏。基本上就是当天发生的任何事情。

注释的覆盖范围与增长

Keith Coleman： 除了每天有数百条独立的注释之外，一条注释还可以匹配到多条帖子。比如有人对一张图片或一段视频写了注释，假设它是 AI 生成的之类的，这条注释会自动匹配到所有包含相同图片的帖子。所以一条注释可以匹配到数千条帖子。以2024年为例，我们大约有95,000条注释，被展示了约300亿次。这比前一年翻了一倍多。前一年大约是37,000条注释，被展示140亿次。增长速度非常惊人——300亿次浏览，意味着大量原本不会出现的信息得以传播，这非常了不起。增长如此迅速的部分原因是贡献者群体在不断扩大。全球大约有950,000名贡献者，将近一百万人参与其中，这太了不起了。

Lenny Rachitsky： 哇，我也算其中一个，对吧？我也算贡献者？

Keith Coleman： 是的，没错。如果你注册成为贡献者，就算。

Lenny Rachitsky： 好的，太酷了。

Jay Baxter： 而且候补名单上还有很多人，所以增长空间还很大。关于媒体和URL的匹配，我认为这是扩大覆盖面的一个巨大途径。同时，我们也非常谨慎地确保这些匹配是精确的。因为我认为与其他类型的事实核查相比，人们喜欢 Community Notes 的一个原因是，注释确实是针对你看到的特定说法量身定制的，对吧？传统的事实核查警告通常只会说类似”点击此处获取事实”之类的话，然后链接到一个关于投票信息的通用页面，把信息藏在一次点击之后，这种方式毫无帮助。所以把上下文直接呈现出来，让你零点击就能看到，并且保持针对性，这是极其重要的。

用户反馈与通知机制

Lenny Rachitsky： 有一个我很喜欢的功能，我想你们一定对此深思熟虑过——如果我之前给某条帖子点了赞，后来出现了 Community Note，我会收到通知，这样我就不会继续记住那条错误信息。

Keith Coleman： 是的。我们尽可能让注释更快出现，理想情况下希望它们即时显示。但不可避免地，从帖子发布到人们搞清楚怎么回事、再到注释上线，中间总会有一个时间差。所以我们发送这些通知来尽量弥补这个时间差。是的，这个功能收获了很多好评。我们看到人们截图分享，对此很兴奋。这也是互联网和社交媒体世界能做到的一件很酷的事——在印刷媒体或传统新闻领域很难做到。在报纸上你可能第二天才能在一个不起眼的角落看到一条更正。而在这里，只要你与某条帖子有过互动，注释出现时你就会收到推送通知。

Lenny Rachitsky： 一个用户反馈是——我希望推送能直接告诉我”你看到的这条有误”。因为我觉得我得点进去自己读，而我觉得推送完全可以直接写”这条内容有更多背景”。就像——

Jay Baxter： 同意。

Keith Coleman： 我们会去看看这个建议——

Lenny Rachitsky： 好了，实时用户反馈。

Keith Coleman： 不错。

注释的触发阈值

Lenny Rachitsky： 好的。我想聊聊这整个事情的起源故事。但还有两个问题，因为我们正聊到这儿。第一个是，一条注释要在什么条件下才会显示出来？这个信息能分享吗，具体是怎么运作的？

Jay Baxter： 简单来说，由于算法的具体实现方式，它使用了一种叫 Matrix Factorization（矩阵分解）的机器学习算法，通过 Gradient Descent（梯度下降）等方式来拟合。阈值是这个人为设定的尺度上的0.4——

Lenny Rachitsky： 0.4，好的。

Jay Baxter： 对。实际操作中，它基本上意味着……如果存在与注释相关的对立分歧。显然，有些注释不涉及政治或其他引发分歧的话题。但如果存在分歧的话，那么双方中相当多的人都通常需要认为这条注释是有帮助的。除此之外还有其他规则会发挥作用。所以即使超过那个阈值，也可能被过滤掉——有一个单独的算法会审查人们对”不正确”标签之间的一致性。比如，有人可能觉得注释有帮助但不正确，对吧？这种情况是有的。在这些情况下，不管有没有超过有帮助的阈值都不行。

Lenny Rachitsky： 我这种理解可能不对，但意思是40%通常持不同意见的人表示同意——

Jay Baxter： 不是。

Lenny Rachitsky： 好的，那是——

Jay Baxter： 完全不是那个意思。它只是某个任意尺度上的一个数字——

Lenny Rachitsky： 好的。

Jay Baxter： 对。

Keith Coleman： 是的。如果我们改变算法中的其他随机因素，这个数字也得相应变成另一个看起来同样任意的数字。我们是通过收集用户反馈来确定这些数字的。我们可以向人们展示大量注释，收集哪些是有帮助的反馈，然后一条分界线就自然浮现出来了——标示着从”有争议”到”相当明确有帮助”的界限。

Jay Baxter： 是的。而且顺便说一句，目前的阈值设置是非常保守的。我们对质量非常讲究，真的希望注释质量非常高。我和 Keith 都相信，归根结底我们成败取决于注释的质量。所以我们宁可不去展示一条可能不错但信号不够充足的注释，也不愿反过来。

Lenny Rachitsky： 这太有道理了。我从没见过一条错误的 Community Note，打破这个承诺后果很严重。所以我完全理解你们为什么在那方面超级保守。

注释的通过率

好的，还有两个问题，因为我就好奇。这些不在我的问题清单上，但我觉得大家会想知道。写了多少注释，最终实际展示出来的又有多少——

Keith Coleman： 提交的注释中我们大约展示8%左右。随着时间推移，这个比例大概在7%到10%或11%之间浮动。数字可能会有一些变化。正如 Jay 所说，毫无疑问……你也看得出来，确实有比我们展示的更多的好注释，但我们的目标是保持极高的标准。我们希望在注释确实有帮助的时候才展示，在不会显得有偏见、不会损害系统公信力的时候才展示。我们希望这些注释是中立的、信息丰富的、有帮助的。正如 Jay 所说，我们认为最糟糕的错误就是展示了一条不好的注释，因为那会损害公信力，而公信力正是人们喜欢这个产品的原因。

所以门槛就在那里。正如我所说，剩下的那90%里，确实有一些是好的。然后有很多就是质量一般的，还有一些是不好的。如果你写了一条不好的——“不好”的定义是：通常持不同意见的人都认为这条注释没有帮助，正好和我们展示的那些相反——如果你写了一条通常持不同意见的人都认为没有帮助的注释，你最终会失去写注释的权限，需要重新挣回来。那90%是一个混合体。有时候人们看到这个数字会说：“哎，你们为什么不多展示一些？“答案就是：“你大概实际上不希望我们展示那些中的大部分。“这个系统的价值所在，就是能够筛选出好的那些。

极端观点用户的处理

Lenny Rachitsky： 这说得通。还有一个问题是，有很多人观点非常两极化，对很多事情都极度持反对态度。他们在算法中是怎么被筛选的？你们怎么处理那些极度反疫苗、与1月6日事件相关、持有各种极端观点的人？

Jay Baxter： 如果人们确实如此两极化，以至于在通常持不同意见的人之间都无法达成共识，那这条注释可能是正确的，但作为上下文展示出来未必有帮助。也许它涉及的是一个人们已经形成了根深蒂固观点的话题，而且他们已经阅读了大量相关内容。这可能确实不会增进人们的理解，也不会带来好的用户体验。所以在这些情况下，不展示注释未必是坏事。

几年前，人们相当悲观，认为事实核查永远不会改变人们对真相的认知。实际上，有一些完全独立于我们的外部研究发现，如果把带有 Community Note 的帖子和不带 Community Note 的帖子做对比，人们在看到注释后，对帖子核心主张的认同度确实会发生变化。所以我们确实在影响这个人们以前认为可能很难做到的事情。因此，聚焦在能达成桥接共识的案例上是很好的。我还想说，算法中也有一个声誉机制。如果你持续以违背基于桥接的共识算法所达成的共识的方式对注释进行评分，我们就会停止计入你的评分。如果你是那种不断把差评注释评为”有帮助”的人，我们确实会把你过滤掉。所以这两种人——那些恶意评分的人和那些只是观点两极化但诚实参与的人——是有区别的。

让全人类参与的哲学

Keith Coleman： 对。我认为一个重要的哲学理念是，我们希望全人类都能参与。有时候人们听到这个会感到惊讶，他们会说：“不是有些人不应该参与吗？“或者”他们的思想太极端了，也许不应该让他们参与。“但我们的观点是，实际上我们希望全人类都在这里。因为如果我们拥有全人类，我们就有了数据，可以理解什么样的注释对真正的人类是有帮助的。我们可以更好地建模、更好地理解、更好地展示这些注释。所以，拥有持有各种各样观点的人对我们是有利的。我们不期望每条注释都能被每个人喜欢——这是不可能的标准。但我们确实希望展示那些80%的人看了会说”哇，我很高兴知道了这个信息”的注释。从这个意义上说，不管别人觉得某个人的观点有多极端，让他们参与进来仍然是件好事。所以无论你的观点是什么，请注册并参与进来，这有助于识别真正有帮助的内容。

Lenny Rachitsky： 好。我们会附上链接，方便想注册的人知道怎么操作。有一点我们之前没有明确说明，这些都是志愿者。没有人因为写注释和投票而获得报酬，对吧？

志愿者的动机与影响力

Keith Coleman： 对。完全基于内在动机，我们认为这是一个很好的参与理由。如果你和最活跃的贡献者交流，他们中的很多人希望世界上有更好的信息环境，这是一个很棒的动机。想想看，对这些人来说，他们能产生的影响力是惊人的。我们最初在美国全面推出的时候，大概是2022年，一条注释出现在了一条白宫推文上，白宫随后删除了那条推文并重新发布了一份修正后的声明。想象一下写那条注释的人。你可能只有12个粉丝，你的帖子可能只得到几个赞。而在这一刻，你在白宫的推文上加了一条注释，他们根据你的行为修改了公开声明。这是不可思议的影响力。所以你能理解，当人们关心世界上正在发生的事情时，他们为什么会有动力去做这件事。你不需要是一个大人物、知名人士，也能以有益的方式塑造公共讨论和信息传播。

Lenny Rachitsky： 太不可思议了。这个系统有太多值得称道的地方。一是整个机制的精英属性——任何真实、正确的人都可以参与并产生影响。另外，它也让我们看到了我们接收到的信息中有多少是错误的。我们以前根本不知道自己看到错误信息的频率有多高，现在我们知道了。

Keith Coleman： 做这个产品让我意识到，以前我默认信任的很多东西，现在我会用更审慎的眼光去看待。

Lenny Rachitsky： 如今确实如此。好的，在我们进入起源故事之前，你们还有什么觉得非常重要或非常有趣的事情想分享的吗？

Community Notes 对传播的巨大影响

Jay Baxter： 好的。还有一点，虽然我们实际上并没有把帖子被添加注释这一事实用于核心排序算法中——我们认为这是一个很好的特性——但确实存在一个非常大的有机影响，也就是说不是来自算法的影响，而是来自用户行为本身的影响。当帖子被添加注释后，人们的点赞、转发或引用转发的行为会大幅减少。对于在大型平台上运行 A/B 测试的人来说，你们可能已经知道这一点，但对于任何算法改动来说，1% 通常已经是非常好的效果了。我们在 A/B 测试中观察到，展示和不展示注释的情况下，点赞和转发的参与率下降了大约30%到40%，这个数字大得惊人。这只是参与率的 A/B 测试结果，还不包括网络效应。如果把帖子通过转发减少而减少传播的整体网络效应考虑进去，用双重差分方法来看，多个不同的外部研究团队都一致发现，总转发量下降了50%到60%，这在帖子被添加注释后简直是惊人的数字。它对信息传播确实产生了非常大的影响。

Lenny Rachitsky： 听到这个太好了。这正是我希望看到的，而且影响力令人难以置信。基本上，一张虚假的 AI 图片以前会在 Twitter 上疯传，在 Community Notes 出现之前确实如此。而现在你说的是，仅仅是添加了那个上下文——而且如你所说，算法并没有对其进行降权——如果内容有误，人们就会说：“好吧，这是假的，我为什么要转发这个？“这很合理。

Keith Coleman： 对。

Jay Baxter： 没错。

Keith Coleman： 是的，注释完全是给这些热门内容釜底抽薪。一个内容正在疯传，注释出现，转发量骤降50%到60%，就这样了。每经过一轮传播减少50%到60%，病毒的传播力很快就归零了。

Jay Baxter： 顺便说一下，我对接下来这个数据感受很矛盾。作者在收到注释后删除帖子的可能性增加了80%——好吧，这很好，因为错误信息少了，但我又觉得有点遗憾，因为那些通常是最好的注释。如果一条注释写得好到让作者别无选择只能删帖，那其他人是看不到这条注释的，对吧？因为——

Lenny Rachitsky： 这确实很矛盾。

Jay Baxter： 有一种观点认为，因为你可能在 X 之外的其他地方，或者 X 上的其他地方看到同样的误导性说法，所以实际上展示带注释的帖子可能比完全不看到这个帖子要好。

Lenny Rachitsky： 对。

Jay Baxter： 不过我对这个说法也不太确定。

Lenny Rachitsky： 这太有意思了。

Jay Baxter： 是的。

Lenny Rachitsky： 是啊，如果我就是那条 Community Notes 的撰写者，我肯定特别沮丧……天哪，写得那么好，结果帖子直接被删了。好吧。回到当下——如今这么一小段代码正在改变人们理解世界和形成信念的方式，甚至让白宫撤回了他们的公告——我们把镜头拉回到这个项目最初是怎么开始的。我听到的简短版本是：Keith，你当时厌倦了管理产品经理，想自己亲手做点东西，想做有意义的事情，想远离那些公司里的破事，于是你开始寻找真正有影响力、重要的事情来做，然后你找到了这个。跟我们聊聊这一切最初是怎么来的吧。

加入 Twitter 的契机

Keith Coleman： 好。对我来说，这个故事实际上要追溯到当初为什么加入当时还叫 Twitter 的这家公司，那是 2016 年。我当时有一家创业公司，收到了一些收购要约，其中一个就来自 Twitter。那是 2016 年，正值 Donald Trump 和 Hillary Clinton 之间的选举期间，电视上播了三场辩论，但每一天，Twitter 上都在上演辩论。非常明显，人们就是在讨论这些重要的事情，信息在这里被分享，观点在这里被形成。作为用户，我明显能从这里获取好的信息，但同样明显的是，也有存疑的信息在流传。我记得当时作为一个局外人看着这些，心想，“哇，这是一个非常难的问题，而且看起来也非常重要。“于是我们最终去了 Twitter，而当时的公司正处于转型期。

我的前三年就是帮助公司重新恢复增长，负责消费者产品的所有工作，让用户增长重回正轨，让人们重新愿意来这里工作，等等。但过了几年，我开始回顾我们做的事情。我觉得我们在恢复势头方面做了很多好的工作，美国和行业内的人也尝试了各种方法来应对误导性信息，但没有什么真正奏效的。很显然，没有一种方法奏效。没有一种方法能应对这个问题的规模，没有一种方法能应对这个问题的速度，而且很多人也不信任现有的方案。现有的方案要么是事实核查机构，要么是内部的信任与安全团队来判定什么是或不是误导性信息。很多人就是不想、也不信任由这种方式来做决定，这非常合理。

放下管理岗，寻找新方向

我当时看着这一切，还在管理一个很大的产品经理团队。这本身就是一个很长的故事。那个职位需要投入大量精力，但我常常觉得看不到我期望的产出。我看不到产品上我想要看到的变化。我在考虑，“我是不是应该去创办一家公司？是不是应该做点别的？“但我不断回到这个问题上。我在想，“这个世界到底要怎么应对社交媒体上的信息质量问题？“不管你在哪里获取信息。我就在这家公司，在这里你可以对这个问题产生影响，为什么不去试试一些疯狂的想法，看看其中有没有哪个能行呢？我当时刚有了一个孩子，休完陪产假回来，去找我的上司 Kayvon。我说，“嘿，Kayvon，我能不能不做现在的工作了，转去做这个？""这个”就是指尝试一些疯狂的想法，看看能不能解决误导性信息的问题。

他非常支持，于是我就开始着手了。一开始就是尽可能多地阅读关于这个问题和现有方案的研究资料。哪些有效，哪些无效，问题在哪里，然后进入原型开发阶段。最终，我们构建并试运行了这个后来成为 Community Notes 的想法。

2016 年 Twitter 的状况

Lenny Rachitsky： 太精彩了。我有很多问题想问，我们会继续聊这个故事，但当你加入的时候……当时它还叫 Twitter。我现在会尽量叫它 X，我知道这对你老板很重要。那个时候 Twitter 处于什么阶段？Kayvon 已经在了，当时的 CEO 是谁？因为中间换过好几位。

Keith Coleman： 好，是的。我是 2016 年 12 月加入的，当时 Jack 相对较近才重新回来担任 CEO 来扭转公司局面。给你一个公司当时状况的概念——大概每年有三分之一的员工离职。想象一下，你的团队每年有三分之一的人离开。股价跌到了谷底，产品基本没有增长。所以 Jack 正在做转型工作，Kayvon 已经在了。Kayvon 当时在负责 Periscope，做一些视频相关的东西，那个团队后来继续……Jack 一直在那里，直到 Community Notes 启动的时候，当时还叫 Birdwatch 项目，然后……对。

从 Birdwatch 到 Community Notes

Lenny Rachitsky： 好，它当时叫 Birdwatch。我觉得我们之前还没用过这个名字，但这是一个重要的点。它最初叫 Birdwatch。

Keith Coleman： 对。我们开始这个项目的时候，它最初叫 Birdwatch，但显然，后来名字改了，这件事某种程度上还挺有名的。

Lenny Rachitsky： 对，也许我们可以快速讲讲这个故事。我知道我们在时间线上往前跳了，但是……我看到了 Jack 和 Elon 之间的一条推文串，他们在讨论该叫什么名字，Elon 说 “Birdwatch 听起来有点阴森，我想改掉它”。关于这个你有什么可以分享的吗？

Keith Coleman： 好的，那个故事……那个故事挺有意思的。Elon 收购了公司，而我们刚刚在美国相对不久前才发布了这个产品。它之前已经试运行了一年，但我们刚刚把它推广到全美范围。他应该已经看到了那些注释。收购完成后不久，他给我发了私信，说，“嘿，这个 Community Notes 的东西太棒了。“我说，“很高兴你喜欢，我们聊聊吧。“于是我们第二天聊了，他一直管它叫 “这个 Community Notes 的东西”。我心想，“你一直这么叫它，这很有意思，因为那其实是我最初给它起的名字。“我做的第一个描绘这个东西的 Figma 模型就叫 “Community Notes”。不知道为什么，就是感觉很自然。所以那是我们测试的第一个原型的名字。

后来，项目的名字改成了 Birdwatch，但 Elon 说，“嘿，就叫那个名字吧。“第二天，我们就改了名字。对于一个团队来说，改名总是一件值得注意的事，但实际上，团队很兴奋。我觉得这是一个好理解得多的名字。Jack 还调侃过它，说它是 “最典型的 Facebook 名字” 之类的。

Jay Baxter： 最无聊的 Facebook 名字……

Keith Coleman： 无聊的名字，这很好笑，因为他们现在也在推出 Community Notes。我觉得这是一个非常容易理解、直觉化的名字，而且我认为它很好地服务了这个产品。它之所以成为第一个模型里的名字，是有原因的。

Lenny Rachitsky： 是的，我觉得描述性的名字就是更合理。关于你和 Elon 的这段联系——我之后想聊聊你是怎么在这么多强势人物之间周旋、在这么多变化中让这个项目存活下来的——但在这之前，你做了一件我觉得很多产品负责人、管理层的领导者、所有管过人的人都梦寐以求的事情：放弃了所有那些加了引号的”权力”，放弃了职业上升路径和影响力，然后说，“管他呢，我要回到一个小团队，就去做一个很棒的东西。“关于这段经历，你有没有什么建议可以分享，是你觉得其他领导者可能需要听到、可能帮助他们做出同样跳跃的？因为这件事实际操作起来真的很难。说起来容易，做起来难。

回归小团队的锯齿形路径

Keith Coleman： 是的，我觉得这确实是一个艰难的跳跃。我在职业生涯中做过好几次这样的事情，每次都非常开心——从一个小团队开始，它发展成更大的东西，然后我就想，“我们在处理很多大型产品的事情，团队真的很大了。我想回到小团队，去做一些疯狂的新东西。“这种锯齿形的跳跃我经历过很多次，但确实不容易，因为很自然地……经典的职业路径是，怎么说呢，追求回报、管理大型组织、做管理者之类的，但我觉得归根结底，你得做自己热爱的事情，得享受其中，而且我认为人们想要的是产生影响力。

我觉得有一个迷思会阻碍人们，就是认为你管理的人越多、范围越大，影响力就越大。我绝对不认为这是真的。你看 Community Notes 就是一个例子。如果我继续管理一个大型消费者产品经理团队，我会产出什么？十六页 OKR？还是一堆文档？我觉得打造 Community Notes 对世界的影响力要大得多。它已经成为行业处理此类问题的标准做法，这真的很酷。人们喜欢它，它是第一个有可能真正应对互联网规模信息质量问题的方案。我觉得这毫无疑问比我继续做以前那种标准管理路径上的事情影响力要大得多。我认为这对许多小公司和创业团队来说也是如此。前几天有人截图了，好像是 Blake Scholl 的 LinkedIn。他从优惠券总监之类的职位，转而去打造第一架超音速……

Lenny Rachitsky： 对，从 Groupon 出来的。

Keith Coleman： 这种故事到处都是，只要你去找。所以我确实发现，对我来说，我热爱亲自动手打造，热爱尝试疯狂的新想法。我热爱从零到一的体验。规模化运作也很有趣，大规模运营也可以很有意思，但这个团队就是一个很好的例子——它在大规模上运作，但团队本身仍然非常小。

Lenny Rachitsky： 对，我觉得你们团队的运作方式正是越来越多公司想要做到的——去掉中间管理层，创建小团队，直接执行、产出影响力，就像 IC 一样。每次我说 IC，YouTube 上都会有人评论问，“IC 是什么？“我就解释一下，IC 就是指个人贡献者（Individual Contributor），也就是非管理岗。说到这个话题，当我问大家你们是怎么组建团队、让团队高效运作并在初期保护好它的，有一个词频繁出现，就是”Thermal”。好像是叫 Thermal 团队，不知道是不是这么说的。

Keith Coleman： 对。

Thermal：隔离式创新团队机制

Lenny Rachitsky： 什么是 Thermal？

Keith Coleman： 在大公司工作过的人大概都知道，事情容易变得官僚化或陷入泥沼，决策可以很慢。有那种大型的规划周期，人们可能随意就把某人从一个团队调到另一个团队，打乱整个项目，诸如此类的事情。我们公司，这是好几年前我们开始这个项目的时候了，公司里有很多创始人。Kayvon 就是一位参与公司运营的创始人，他提出了一个想法，“嘿，我们为什么不做这样一个项目，叫做 Thermal，让团队在一定程度上与那些东西隔离。“它们可以按自己的流程运作，有一个明确的负责人。团队完全专注于那个项目，然后我们就反复做资金决策，决定是否继续推进。

Lenny Rachitsky： 对了，为什么叫 Thermal？这背后的想法是什么？

Keith Coleman： 我觉得是一个老的鸟类比喻，热气流托起鸟的翅膀。Twitter 1.0 显然有很多鸟类相关的比喻，愿它安好吧，这就是其中之一。我喜欢这个想法，作为一个喜欢创业环境的人，所以当我们启动这个项目的时候，我就说，“嘿，Kayvon，我们把这个做成第一个 Thermal 项目怎么样？“他说，“好，干吧。“于是我们就以那种方式开始运作，从第一天起就赋予了我们大量的自由和自主权，我觉得这对产品的成功真的非常重要。

Thermal 的关键设计要素

Lenny Rachitsky： 能具体说说吗？什么让一个项目成为 Thermal 项目？你是怎么搭建的？这是从一个公司的角度来问，如果一家公司想建一个类似的东西，具体是什么样的？

Keith Coleman： 我觉得有几个关键要素。一个关键要素是有唯一明确的项目推动者，实际上就是一个创始人角色。也许可以有两个人之类的，但必须非常清楚谁是项目推动者，同时团队外部也有一个唯一的明确决策者。

Lenny Rachitsky： 团队外部的？

Keith Coleman： 团队外部的。从一开始就是这样，现在也是。如果我们需要什么，或者对什么有疑问，我就去找 Elon。从一开始就是这样，现在也是，我觉得这就是我们能够高效、快速、简单地做出决策的一个重要原因。

Lenny Rachitsky： 这个人应该得是非常高层的人，不能是普通经理吧。

Keith Coleman： 一个能做出你需要的各种决策的高层人士。我觉得这一点非常重要，就是那种清晰的决策结构。另一个要素是百分之百的专注，所以项目上的每个人都被期望完全专注于它。在很多公司，人们的注意力很容易分散在很多事情上，这让推进事情变得困难。你去找某个人，请他在某个事情上帮忙，他会说，“好，我帮你。我得先完成这个东西，可能要一两周，然后我来处理。“一两周的延迟完全会改变一个项目的势头。当我们百分之百专注的时候，我们早上讨论，“嘿，Jay，我们试试在算法里做这个调整？“他说，“好。“然后当天下午或者第二天，我们就在看结果了。因为这种完全的专注，迭代速度大幅提升。除此之外，我们还可以使用自己的决策流程。我们不需要写 OKR 或者……其他标准做法。显然，我们得确保负责任地打造产品等等，但我们不需要使用那些标准做法。我觉得 OKR 是另一个很好的例子，我理解它们为什么有用，但它们也不一定就是设定目标的正确节奏。我认为季度或年度目标到底是不是正确的步调，这一点其实很不清楚。我们会为下一个重要里程碑设定目标，然后为此努力。达到那个里程碑后，我们对接下来要做什么会有想法，等我们完成了那个，再设定下一个里程碑。不管是两周、一个月、三个月，还是多长时间。我们按照自己的节奏，以那个节奏设定目标，我觉得这对开发一个东西来说要自然得多。

Jay Baxter： 整个 OKR 制定和规划流程花的时间，比我们选定一个目标然后执行完毕还要长。

Lenny Rachitsky： 你们早期搭建的团队有多大？多少个工程师？

早期团队构成

Keith Coleman： 一开始只有我一个人，后来当我们决定要把这个东西做出来的时候，我们觉得大概需要五个人。我们希望团队尽可能小。很明显我们需要一个做机器学习的人负责打分，需要一个做客户端工程的人，一个做后端工程的人。可能还有一两个其他角色。我们需要一个设计师和一个研究员来帮助我们理解用户群体，确保我们做出来的东西能真正引起人们的共鸣。我记得是后端、前端、机器学习、设计和研究。据我回忆，这就是最初的团队。

Lenny Rachitsky： 太棒了。基本上每个职能一个人。我有个问题想问 Jay，大家总说小团队、快速推进，但有时候你就是需要更多工程师才能把东西做出来。关于如何在保持如此快的速度的同时让团队保持精简，不需要也不需要招聘更多工程师，你有什么心得吗？

算法的演进：从 PageRank 到桥接算法

Jay Baxter： 我觉得在最初我们还在探索需求到底是什么的时候，只有一个机器学习工程师肯定是好的。但到了某个阶段，我们对算法的目标变得非常清晰了，我们尝试了……我觉得在最开始，我们并不清楚需要构建这种基于桥接的共识算法（bridging-based agreement algorithm）。我实际上线部署的第一个算法非常专注于反操控。它是一个 PageRank 的变体，但它基本上没有解决偏见问题。如果一方的用户更多，PageRank 这种图算法实际上会放大那些偏见。我觉得在构建了那个原型并从中获取数据之后，就很清楚基于桥接的共识算法才是我们需要解决问题的方式。于是在那个时候，基本上我搞了一个内部竞赛。类似于 Kaggle 竞赛那种形式。那是一个关键时期，引入其他工程师非常重要。

Lenny Rachitsky： 这个故事太酷了。我想顺着这条线往下聊。在这之前，你刚才提到你们会喊 “Thermal”。这是什么意思？是 YOLO 那种，类似于……好吧。

Keith Coleman： 就是直接上线，因为我们是 Thermal 项目。

Jay Baxter： 上线。

[广告已跳过]

Lenny Rachitsky： 好，回到算法这个话题，这其实非常有趣，因为这些我从来没听说过。我本来就想问这个算法本身的灵感来源是什么，而你们基本上是在机器学习工程师之间搞了一个内部竞赛，看谁的算法最成功。Netflix 大赛那种风格，Kaggle 那种风格。

Jay Baxter： 对，对。寻找那些被立场对立、通常持不同意见的人共同认可的内容——这个想法并不是凭空而来的。我觉得 Keith 之前发现了一些 Chris Bale 的研究，他整理了一个账号列表，那些账号经常被政治立场两边的人同时点赞。还有其他一些项目，比如一些民调也在寻找通常持不同意见的人之间的共识。但我觉得从一开始就确定我们的项目一定需要用到这个思路，这并不是显而易见的。当你把它实现出来，和其他类型的算法做比较……PageRank 看起来显然是设计来抗操控的。如果你的投票环里一群人互相给自己投票，PageRank 能很好地过滤掉这种情况，但那并不是主要的攻击向量。

我们得从试点中获取一些真实数据才能意识到，“好吧，这里真正的问题是人们的极化。“所以我认为直到我们从试点中拿到了真实数据之后，才清楚地看到基于桥接的共识算法是我们真正需要走的方向。

团队运作方式

Lenny Rachitsky： 我想回到你们团队运作方式的话题。我听说你们整个团队就靠一个 Google 文档来运转，一个用了四年的文档，不断往里面加目标和要点。这是真的吗？

Keith Coleman： 确实有一个运行了很长时间的文档，而且不得不定期裁剪和清理，因为它有时候会导致 Chrome 里的 Google Docs 崩掉。它就像一个笔记文档，真的是我们协调工作的地方。团队每天开会，花我们需要的任何时间来对齐我们正在构建什么。我们可能讨论从”现在最重要的是什么”到”我们接下来应该做什么？“到”我们现在正试图上线什么，为什么还没上线？是什么阻碍了上线？“我们可能会审查新的建模或打分算法更新，试着理解哪些地方有效，哪些不行。我们就讨论任何想讨论的或者觉得最重要的事情。正如你所说，我们非常动态地设定目标，所以对我们来说现在和接下来最重要的事情就是我们要花时间做的。我觉得这对项目来说效果非常好，而不是执着于某些季度目标之类的东西。我们会看”什么最能帮助用户？“或者”现在最大的问题是什么？“两者中任何一个是什么？然后我们就去解决它。我们可能根据我们看到的情况，在两周内多次改变路线图。

Lenny Rachitsky： 我听到的是没有 Jira，没有 Asana，没有 Monday.com。

Keith Coleman： 没有。

Lenny Rachitsky： 好的。

Keith Coleman： 是的，我的意思是，我们必须用 Jira 来和其他一些团队协调。有时候我们提交请求的时候，必须创建一个 Jira 工单。但确实，我不喜欢重量级的任务管理。我喜欢大家保持信息同步，能把大部分事情记在脑子里，然后用一种非常轻量的方式把团队记不住的东西写下来。

Jay Baxter： 我们确实短暂用过 Asana，但我的记忆是，你花在会议上整理一堆无关紧要的待办事项上的时间，比真正讨论正确的优先级还要多。我觉得 Google 文档的好处是，如果某件事变得不相关了，它可以自然地消失，而不需要显式地清理待办列表。

团队运作方式总结

Lenny Rachitsky： 也许可以总结一下你们的运作方式，可能会启发其他公司也这样组建团队。我来梳理一下你们分享的几个要点。首先，团队有一个负责人，几乎就像创始人一样，基本上就是团队的创始人。他们有一个非常资深的管理者/决策者作为对接人，在你们这里就是 Elon，不是什么小事。在其他情况下，可能是 CTO、CPO 之类的角色。团队百分之百专注于自己的产品和目标。保持团队非常小，每个职能一开始只设一个人——一个前端工程师、后端工程师、ML 工程师、设计师、研究员、PM，然后项目管理基本上就用 Google 文档。没错，基本上就是用 Google 文档跑起来的，别用那些又大又复杂的产品。

Keith Coleman： 我觉得这是一个相当好的配方。Google 文档那部分，大家想用什么都可以，如果有人喜欢用便利贴，尽管用。但我认为前面提到的那些要素，在结构上才是真正关键的。除此之外，还需要有一个让人热血沸腾的远大目标，激发大家去做伟大的工作。

Lenny Rachitsky： 是的，太棒了。我觉得这里面很多东西，很多人在组建这类团队时觉得自己应该做，但实际上并没有做到，而每一个要素似乎都是真正成功的关键。

Keith Coleman： 这些确实极大地帮助了我们成功。如果不是因为其中一些要素，我不确定这个项目能不能走到今天。

Lenny Rachitsky： 这句话分量很重。这个改变了世界认知何为真实的东西，如果不是你们以这种特定方式组建起来，就不会存在。

团队架构的关键性

Keith Coleman： 是的，如果不是事先知道我们有那样的结构——那种决策能力、自主权、速度、快速推进的能力——我可能根本不会启动这个项目。我们从 1.0 版本开始就有这样的架构，一直延续下来，到了 X 甚至进一步强化了。X 作为一家公司整体上就以很多这样的特质在运作，我认为这是产品成功的原因之一。我想至少对我来说——Jay 可以代表自己说话——这些正是我在这个项目上工作得如此开心的原因。我热爱这个工作。每天醒来去解决这些问题，感觉很棒。我们能高效地推进，快速做出决策，构建出帮助很多人的东西。太棒了。

Jay Baxter： 无论是 Thermal 还是 Elon 式的运营方式，确实更有趣。而且……这一点加上令人振奋的使命，对内部招聘来说极其重要。我记得 2020 年初刚开始和 Keith 聊这个项目的时候，我手上还有别的项目。我做了几个，其中一个大概是优化推送通知的发送数量，它在没有显著增加用户关闭通知的情况下大幅提升了 DAU。所以那条路是稳妥的，如果我继续做下去，大概率可以低风险地拿到晋升。但我也可以选择承担这个巨大的职业……虽然不像加入或创办一个真正的外部创业公司那样风险巨大，但加入这样一个团队确实还是有一定的职业风险。我觉得外部创业公司招聘的所有要素，同样适用于内部。如果你能有一个令人兴奋的愿景，那就是关键。

自选择机制

Keith Coleman： 跟这点相关的，还有你刚才列的那个清单，Lenny，我们漏了一个非常重要的东西——在这个项目上，以及我认为类似的成功的创业项目中，人们是主动选择加入的。我们没有把任何人分配到这个项目上。人们是主动联系要加入的，或者申请了这个岗位。我和团队面试了每一个加入团队的人，我们会说”我们想让这个人在团队里，而他也想加入”。所以每个人对目标、使命、团队的工作方式以及将要共事的人，都是完全认同的。这产生了巨大的差别。

所以做这件事最好的时机是在一开始。如果你要做一件疯狂的事情，只是随机分配人员上去的话会很艰难。但如果你让人们自主选择加入，成功的可能性要大得多。而我在 X 观察到的一件事，真的让我惊讶——这在很大规模上也是可行的。Elon 收购公司时做的事情之一，就是基本上让人们自主选择留下。你必须点击一个按钮。他发了一封邮件，大意是”嘿，Twitter 2.0。”

Lenny Rachitsky： “分岔路口”，对吧？

Keith Coleman： 分岔路口，没错。他说”Twitter 2.0，现在叫 X，将会是非常硬核的。我们要做有野心的事，你们会拼命工作。“你必须在表单上点击，说”是的，我要加入。“我认为这对公司来说非常重要，因为你要让人们主动选择加入。你要让那些人说”对，这就是我想做的”，这样公司会成功得多。如果有人不确定，他们可能更适合去做别的事情，去一个他们天然更认同、更开心的地方。我觉得这是一个很好的方式，把一家大公司精简到那些真正对一起为使命奋斗而兴奋的人。对我们来说，我们从第一天就这样做了，我觉得这是一种比较容易做到的方式，但后来再做也是可以的。

Lenny Rachitsky： 我很喜欢你用”有趣”来形容它。我觉得很多人看到 Elon 大规模裁员、自己也非常硬核的时候，不会想象那是一个有趣的工作场所。但很显然你们有多么热爱做这件事，它有多么有趣、多么有意思。听到这些很有意思，因为我觉得很多外部的人感受不到这一点。关于在 Elon 管理的组织里为他工作，还有什么其他方面会让人们感到惊讶的吗？关于工作方式有什么有趣的、令人惊讶的、或者你认为其他公司可能会想借鉴的东西？

更精简的团队

Keith Coleman： 我一直偏好精简的团队，但我在 X 的经历改变了我对未来运营组织的思考方式——如果我创办一家公司的话，我不得不改变我对创办那家公司的方式的想法，我会比以前做得更加精简。我对一个小团队能完成如此多的事情感到惊叹。我认为正是因为团队小——收购后不久，我们有一个叫 Spaces 的产品。这个产品之前就存在于产品中，但规模很小，Elon 想运营大规模的 Spaces。我忘了第一批要上来的嘉宾是谁，但他本人会在场。后来这些活动发展到能接待政治人物等等。他说”伙计们，我们得把这个扩容。“我忘了具体的数字。

Keith Coleman： 他说，“我们得支持一百万人同时在线，“大概是这样的。具体数字我记不清了。“你们得把容量大幅提升上去。“这种事放在 1.0 时代，就算能做也要一年时间，而团队两三周就搞定了。看到这个过程真的令人兴奋和振奋。我没有参与那个项目，但我是从外面旁观的。我当时就想，“哇，就这么一个小团队，在一个宏大目标驱动下——那个目标不是说’嘿，大家，我们要不要做这个？‘而是’我们一定要把这个做出来。‘“他们两三周就完成了。对他们来说那一定感觉太棒了。对我来说也绝对是激动人心的。我确实开始深刻体会到，一个团队可以精简到什么程度，不仅能够撑下去，而且正因为精简反而能够蓬勃发展。

Lenny Rachitsky： 你提到的”主动选择加入”这一点很重要，因为我觉得很多人听到这些会想，“我才不想被要求两周内做出那种东西。“但我也觉得很多人会愿意，我们热爱那种体验，尤其是和 Elon 一起工作，尤其是发布那种规模的产品。不过我觉得其中有一个关键要素就是，“好吧，我不想做这个。我除了上线 Spaces 之外还有别的事情要做。“所以我觉得你提到的”主动选择”是一个关键点。

Keith Coleman： 完全同意。我觉得主动选择很重要，而且可能你在人生的某个阶段愿意选择加入，而另一个阶段可能别的选择更好。我觉得无论你选择做什么，能够主动选择、感觉它与你想如何度过自己的时间相一致，这是很好的。

裁员 80% 之后为什么没有崩溃

Lenny Rachitsky： 我一直在想一个问题，不知道你们愿不愿意聊，但我觉得很多人都在想：Elon 进来之后，裁掉了 80% 的人。所有人都说，“Twitter 完了。一切都会崩溃。那么少的人根本不可能运转起来。“但显然他们错了。显然，现在一切运转得很好。它在世界上变得越来越重要，而且持续增长。关于这一点，你有什么感到惊讶的吗？或者关于为什么在经历了这么大的变动之后它仍然运转得这么好，你有什么看法？

Keith Coleman： 我认为更精简的团队、更少的流程和官僚主义，是它能如此快速运转的一个重要原因。在这里更容易更快地把事情做成。是的。我认为那次缩减实际上正是发布节奏加快、实验节奏加快的一个重要原因。我注意到的另一个结果是，现在在这里的人，他们似乎都真的有主人翁意识。他们像产品所有者那样承担责任。他们会去追踪问题出在哪里，修复需要修复的东西，跳进来帮助构建或修复、改进任何需要帮助的系统，即使那不是他们负责的领域。这还有另一面。在大公司工作过的人可能都有过这种经历——你想修改另一个系统或产品中的某些东西，于是你联系那个团队。他们可能有点抵触，可能会说，“哦，我们下个季度再说吧——”

Lenny Rachitsky： 他们有自己的目标要完成。是的。

Keith Coleman： 是的，没错。他们不一定想帮你，或者他们很忙。但在我们这里，你说，“嘿，大家，我们需要在你负责的那个系统上做件事。“他们会说，“太好了！这是代码，这是文档，有问题在 fab 上发消息，我们把它合进去。“事情就是这样，你可以直接跳进去把它搞定。这种协作方式，这种共享的主人翁意识，根据我的经验，正是来源于团队缩减到那些愿意留在这里、愿意一起构建这个产品的人。所以我认为这是一个非常积极的影响。这并不总是轻松的。当然，很多人肩负着很多责任，但他们在这里是因为他们愿意承担。

Jay Baxter： 是的。我认为另一个关键点是，当你被迫拥有这么小的团队时——其实不管团队大小这都很重要——删除代码很多时候比写代码更重要。我觉得很多时候，也许是因为晋升激励，或者只是人的天性，工程师倾向于不断添加那些看似微小但实际带来增量的改进，而这些改进带来的长期维护成本比表面上看要大得多。因为你只做了一个月的 A/B 测试，看到了一个显著的收益，却没有意识到你刚刚给自己的团队增加了永远的维护负担，直到你把那个功能关掉为止。所以我觉得这里面有很大的收益空间，而且当你拥有这么小的团队时，你不得不这么做。就是审计你的系统的各个部分，删除那些维护成本大于收益的东西。所以我认为在大裁员之后，我们在全公司范围内确实不得不做这件事，现在系统更精简了，可以用更少的人来维护。

Lenny Rachitsky： 这点说得太好了。我记得 Elon 当时说，“我们必须把整个东西扔掉。必须重新架构一切。现在这种构建方式太蠢了。“听起来这招确实奏效了。

Jay Baxter： 是的，所以——

Lenny Rachitsky： 嗯。

Jay Baxter： 你不需要把所有东西都从头重写。有些东西确实值得重写。但仅仅是删除不必要的冗余代码，保留核心系统的其余部分，这就已经很棒了。

Birdwatch 的低调发布策略

Lenny Rachitsky： 我很喜欢我们正在总结出一套运营这类公司和团队的公式。这里面有太多内容了。我想回到最初产品的构建过程。我们刚才聊了很长的一段题外话，一段非常精彩的题外话，但我听过一个故事，说你们当时发布 Birdwatch 的时候，特别想把预期压得很低，里面还放了一个 GIF，看起来明显就是一个还没准备好的产品。聊聊你们是怎么做的吧，你们是怎么以一种让人觉得”这东西永远不可能行”的方式来发布的。

Keith Coleman： 我们非常自律，可以说，让产品在每一个阶段都自己证明自己。当我们构建第一批原型图的时候，那些只是描绘 Community Notes 可能呈现效果的图片。我们把这些拿给不同政治立场的人看。我们发现，嘿，人们真的很喜欢这些。无论他们是在右翼还是左翼，他们似乎都很乐意阅读这些 Community Notes，即使这些 Notes 对自己阵营的人持批评态度。所以我们觉得，“好的。这给了我们信心：如果我们能把这个做出来，如果我们能让它成为现实，它就会成功。“接下来就是，我们能不能把它变成现实？现实世界中的人能不能写出这种质量的 Notes？

于是我们先做了一个内部试点测试版本，你可以写 Notes。我们首先基本上通过类似 Amazon MTurk 的方式做了一个参与者测试，就是看看如果你放一些普通人进去，他们能不能写出这些 Notes。那些 Notes 并不都好，但很明显有些人确实能写出好的 Notes。于是我们想，“好的，这是可行的。如果我们真正在现实世界中做这件事会发生什么？我们来运行一个试点，看看结果。“所以我们把之前做过 MTurk 测试的那个试点拿了出来，先向 1000 人开放，完全公开，我们不知道会出现什么内容。你可以想象那些 Notes 可能会很糟糕。

于是我们讨论，“那我们该怎么办？我们把这个东西放出去，所有人都会有一堆问题。他们可能会非常怀疑，而且我们知道它可能完全是一场灾难。那我们该怎么合理地设置预期？“我们觉得最终应该能把这事做好，但一开始会怎样真的不知道。我们想设定好预期，于是我们就想，“那我们干脆放一个……”你知道那个页面吧，你在上面看到一条帖子，下面是 Notes。我们就说，“我们干脆在那个页面上放一个垃圾桶着火的 GIF？“你点进去一看，“嘿，你在下面看到的任何东西可能都是一场彻底的灾难。至少这能表明我们意识到了这个风险。“最后我们没那么做。虽然我觉得特别搞笑，但我们觉得——

Lenny Rachitsky： 哦，你们没有真的上线那个 GIF。好的。那只是一个概念而已。好的。

Keith Coleman： 我们做了原型图，每次我看着那个原型图都会笑，但最终那个页面上有太多东西需要解释，比如，这东西是什么，它是怎么运作的？最终我们觉得，“好吧，这个 GIF 可能会分散注意力。“所以我们把它撤掉了。我有时候觉得如果它能见一次天日也挺好的，但最终我们保持了简洁，让那个页面专注于解释这里正在发生什么。不过，和这个项目很多次的情况一样，我们把试点放出去之后，Notes 的质量是好的。

不是全部都好。参差不齐，但里面有真金。从最开始只有 1000 名贡献者的时候起，就很明显人们能写出信息丰富的、中立的 Notes，能谈论有争议的、棘手的话题，而且只要我们能把这些好的 Notes 从其余的里面筛选出来，这东西就能成功。它的效果会和我们最初做的那些原型图一样好。于是这就成了重点——怎么从其余的内容里筛出真金？

Elon 的早期关注

Lenny Rachitsky： 你可能跟我分享过这个——有人注意到你们在测试这个东西，截了图发到了推特上，我记得 Elon 回复说，“This is cool。”

Keith Coleman： 对。对。那是在非常早期的阶段，当时还只是一个 Figma 原型，我们在 usertesting.com 上跑受控的用户研究。大概有一个参与者把东西发给了一位 NBC 的记者，那位记者写了一系列报道。总之那天平台上议论纷纷，然后 Elon——把时间线拉回到当时，这大概是在 2020 年，收购之类的事情还两年之后呢——Elon 当时就是一个推特用户，造火箭、造电动车，做各种酷东西，然后偶然看到了这个描绘我们测试中原型的东西。他回复道，“Definitely worth trying, IMO.”我记得当时觉得挺酷的，而且有意思的是，他显然一直持有非常一致的看法。我觉得这个想法本身就吸引人，而他显然在产品层面一直是它的忠实粉丝，一直是坚定的支持者。所以是的，这份支持其实从非常早期就开始了，远在他涉足公司之前。

Lenny Rachitsky： 我太喜欢那个时刻了。Elon 对一个 Figma 原型测试发表评论，那种感觉一定非常不可思议吧。

Keith Coleman： 确实很酷。确实很酷。

Community Notes 的核心原则

Lenny Rachitsky： 天哪。在我们准备这次访谈的时候，我问你们最希望人们理解和认识到 Community Notes 为什么如此有效的核心要点是什么？Keith，你特别说到是你们在方法论背后的那些原则——你们从一开始就坚持并且一直贯彻至今的那些原则。我们之后也会聊到你们是怎么在这么多任 CEO 更替中把它保留下来的。但先来谈谈这些原则，具体是哪些原则，为什么它们对成功如此关键？

Keith Coleman： 有好几条原则。当我们第一次在公司内部向人们分享这些原则的时候，它们看起来可能有点疯狂。但我认为它们正是这个产品能运作的原因，我认为它们非常重要，而且我们也确实如此——我们今天仍然不断地回到这些原则上来。大概最疯狂的一条就是，这个东西将是人民的声音。它将代表人民的声音，而不是公司的声音。所以决定展示什么内容的不是某个科技公司，而是人民，这一点在设计上产生了很多影响。首先，我们没有按钮可以改变一条 Note 的状态。如果一条 Note 因为人们投票认为它有帮助而展示了，它就会展示。我们无法改变这一点。

而这正是我们最初提出时让人不安的地方。他们会说，“等等，所以一个东西可以上线，而公司无法撤下它，或者无法改变它的状态让它停止展示？“我们就说，“没错，而且它必须这样运作。如果它的质量不足以支撑这一点，那它就不算成功。“我们的核心原则之一就是，如果一条 Note 的问题严重到你想要干预，那问题出在系统身上。我们需要重新设计系统来展示好的 Notes。所以没错，我们必须让所有人都接受这个理念：没有一个按钮可以改变 Note 的状态。类似地，正如我们之前讨论过的，我们希望这个产品代表全人类。

所以我们不想充当仲裁者，决定谁可以进来当贡献者、谁不行。我们对所有人开放。你只需要满足一个非常基础客观的标准。你需要有一个已验证的电话号码，帮助降低机器人之类的东西参与的可能性。但除此之外，就是随机选择，而且今天仍然如此。同样，这一点也需要花时间让人们接受。但我认为，这代表了人民的声音，通过一个开放、透明的流程反映他们的产出，这一点对于它为什么好、为什么有效，以及为什么被信任，都是至关重要的。这是第一条原则，我认为它永远是这个产品的核心。另一条人们觉得疯狂的原则是透明度。

透明度原则

之前应对误导性信息的做法，在很多人看来就像是黑箱——科技公司或媒体公司或什么权威在做决策。我们的想法是，“人们需要对这件事感到安心。他们需要信任它。所以整个过程必须公开透明。“决定哪些 Note 被展示的代码必须公开。所有驱动它的数据和评分必须公开。人们应该能拿代码和数据复现整个服务，验证我们的确做了我们说要做的事。他们应该能够审计它。他们应该能去查看并说，“嘿，我觉得这部分可以改进。”

或者如果他们认为我们有偏见，他们应该能拿数据来指出这一点。如果人们提出了好的观察，那应该被纳入代码的改进中。同样，这也是一件很难让人安心的事情——所有东西都摆在那里，你无法遮掩任何事。但我认为这对于人们信任它至关重要。是的，我们从第一天就确立了这些原则。我们不断地回到它们，因为产品一直在演进，我们始终要确保每一个新变化都是开放的。每当我们更新评分系统，GitHub 上就会有更新；数据每天发布，你可以下载。所以是的，我认为这些原则对于这个东西的成功是根本性的。

开源的代价

Jay Baxter： 顺便说一下，这些并不是没有代价的。从终端用户的角度来说，要把实际运行的算法在实际数据上开源，其实非常困难。因为像这样的大规模服务，通常的架构方式天然不适合被别人下载一个 TSV 文件就能当脚本来跑。所以我们实际上不得不做一些不同寻常的架构决策，才让这件事成为可能。如果我们不是从一开始就带着这个假设从零做起，可能就得重写整个系统才能做到这一点。

Lenny Rachitsky： 能举个例子吗？

Jay Baxter： 比如我们训练了一个矩阵分解（matrix factorization）模型。通常你会训练一个矩阵分解模型，然后用一个独立的服务来部署它。但我们不想让外部的人还要去启动服务才能复现我们的系统。所以基本上，我觉得如果我们开源代码的方式让别人没法真正跑起来——不是那种下载下来就能跑的——那就不太酷了。现在你可以下载 Python 代码，运行一个脚本。你确实需要很大的内存，但可以在一台机器上完成。

Lenny Rachitsky： 好的，需要多少内存？

Jay Baxter： 哦，大概也就 500 GB 吧。

Lenny Rachitsky： 好的好的，那还算合理。

Jay Baxter： 如果你不做任何加速优化的话，大概要跑一天。了解一下就好。

Lenny Rachitsky： 挺酷的。

Jay Baxter： 关键是”能做到”，而且确实有人做到了。Vitalik Buterin 发过一篇博客，讲了他探索的过程，确认算法确实做了它声称要做的事。我觉得仅仅是有少数人做了这件事这个事实——已经有足够多的人验证过了，其中总有你愿意信任的人。

坚守原则的力量

Lenny Rachitsky： 而且这套东西还在向 Meta 推广。没什么大不了的。我只是听你描述这些原则的时候，能想象到一家公司的产品经理说，“好的各位，我要做这个项目。“这里面有太多理想主义，在现实中很少能成功——要开源，要给所有人用，我们对它会做什么没有实际控制权，别担心，它就是会改变人们看待这个东西的方式，而我们已经非常小心翼翼了——然后它居然真的成功了。我觉得这是非常罕见的，真的很令人印象深刻。我听出来的部分信息是，坚持这些原则实际上对它的成功是根本性的，而不是在有人说”不不不，我们不能这样做，要是我们改了这个部分呢？“的时候就妥协退让。

Keith Coleman： 我觉得如果我们违背了其中任何一条原则——如果有任何黑箱，如果有任何诸如此类的东西——这个产品就会难信任得多。所以我认为，正因为我们在这些原则上坚守得如此干净纯粹，人们才能信任它。

关键时刻：系统真正发挥作用

Lenny Rachitsky： 你们提到过几个让人惊叹的时刻，比如白宫因为 Community Note 修改了他们的公告，还有那个狗是猫的例子。发布之后还有没有其他让你觉得”天哪，这真的管用了？这真的能成功”的时刻？

Keith Coleman： 一直以来我们都在看到它在起作用。每当我们把它扩展到新的用户群、新的国家或其他什么范围时，我们都要确信它能正常运作。所以可能会稍微屏住呼吸看看它是否如我们预期的那样工作，但我们始终预期它能做到。话虽如此，确实有一些压力极大的案例。印象最深的是 2023 年 10 月以色列-哈马斯冲突爆发的时候。那可能是我见过的同时在互联网上传播的最大规模的误导信息洪流，铺天盖地。大量照片、视频和相关内容涌出来，简直疯狂。举个例子，在那场冲突的头三天左右，我们就有了 500 条 Note，覆盖了各种不同的……脱离上下文的图片。有人会说”嘿，这里正在发生这件事”，实际上那是 2013 年叙利亚的画面。还有人用视频游戏模拟器 Arma 3 制作假的战斗画面。所以有 Note 解释这些——这些东西看起来很逼真，除非你看到 Note，否则你真的分辨不出来。关于地面实际情况的各种说法层出不穷。那次确实是……当时产品还相当新。我们不到一年前才在美国推广，那一年一直在向全球推广，然后这个大事件就发生了。我感觉我们在恰当的时机做好了刚好足够的准备，让系统能够应对这一切。

可能在那之前我们做的最重要的一件事，就是上线了对图片和视频撰写 Note 并将它们匹配到其他帖子的功能。我记得当时想，“幸好我们在几个月前就上线了这个功能，而不是还搁置着，“因为那场冲突中它真的非常重要。我记得就在那之前几周，我们还做了一个大幅提速的更新。最初做这个产品时，第一要务始终是质量。我们知道这个产品成败系于 Note 的质量，这是我们不能放弃的东西。我们也知道它需要在速度和规模上达标，但我们想，“我们先把质量做到位，然后再逐步提速和扩展。“我们当时刚好上线了一个提速方案，把上线所需时间缩短了三个小时，而且距离那场冲突只有几周时间——再次庆幸那个更新已经推出了。冲突最初几天，从帖子发布到 Note 显示出来的中位时间是五个小时，快得疯狂。典型的事实核查通常是两到四天——至少两到四天是很常见的。这些 Note 在五个小时内就出现了，我们当时就想，太庆幸这些改进在那之前就推出了，让服务有用得多。

Jay Baxter： 还有一件事我觉得在那时看到了很好的效果。有些人对 Community Notes 的一个批评是，如果你总是需要通常持不同意见的人达成共识，那么在这些高度两极化的场景下——那场冲突大概是头号例子——你就不会看到任何 Note 出现。但实际上，有大量关于那场冲突的 Note 出现了。所以我觉得这是一种很好的属性：也许这是一个出人意料的事实——跨越两极化分歧的共识比传统认知所认为的要多，而人们达成共识的地方，确实是客观真实、可验证的。也许在越是两极化的场景下这一点越成立，但共识真正能带给你的，是那些非常中立地撰写、非常聚焦于事实、且信息易于验证的 Note。

Lenny Rachitsky： 有一种说法流传了一阵子——不再有事实了，没人相信还存在单一的真实事实了，一切都是主观的。我觉得 Community Notes 证明了恰恰相反。事实是重要的，存在我们可以共同认可的事实，哪怕是在最具争议的话题上。

匿名贡献者与信任机制

Keith Coleman： 是的，我们从第一天起就看到了这一点。当我们向人们展示那些仅仅描绘了这个想法的原型时，很明显人们非常在乎理解现实、了解正在发生的事情，而且他们愿意——姑且这么说——违背自己一方立场来承认这一点。我觉得这对很多人来说并不总是那么显而易见。这个世界确实感觉很两极化，但人们绝对愿意跨越党派边界去获取准确的信息，这正是这个产品能够运作的原因。

Lenny Rachitsky： 感觉随着我们越来越多地依赖从社交媒体上快速获取的在线信息来认知和理解世界，我真的非常庆幸这个东西存在，否则我们就完全不知道还能相信什么了。它的出现恰好满足了我们对这类机制的迫切需求。但与此同时，也有很多人我确实不信任。我觉得人们已经从”我相信我读到的内容”转变为”好吧，我不应该轻信我读到的所有东西”。关于人们如何看待他们看到的新闻，以及这种”我不再什么都信”的转变，你有没有注意到什么？在人类行为方面，或者在我们理解真相的方式发生的变化上，你有没有观察到什么？

Keith Coleman： 我们没有做过任何研究来广泛考察人们的认知在那方面是如何变化的。但我自己确实有这种体会——尤其是在看到各种 Note 之后，我对最初读到的东西变得更加审慎了，我觉得这其实是有益的。我们也从用户那里听到类似的反馈，说他们会多想一想，我认为这是这类系统一个很好的副效应和好处——你越是看到自己读到的东西可能出错的各种模式，你就越能审慎地质疑它，并努力更好地理解到底发生了什么。所以从历史上看，我觉得这被称为媒介素养，但基本理念就是：你能否理解事物可能出错的方式，并尝试自己去甄别。

Jay Baxter： 我认为我们在另一个方面也有所帮助，那就是 Community Notes 的发现机制。我觉得在 Community Notes 出现之前，你可能一直生活在一个小小的新闻过滤气泡里，或者也许外面有一些你应该去看的事实核查，但你根本没有发现它们。而 Note 直接附加在帖子下面、任何看到帖子的人都能看到这一事实，有助于穿越那些过滤气泡，并且某种程度上……我觉得对一些人来说，这是他们第一次真正看到针对自己那个信息回音室里提出的论断的反驳论据。

Lenny Rachitsky： 这太了不起了。我很喜欢你说的这一点——它实际上教会人们对读到的东西多一些质疑。它不仅仅是一个教育系统，而不仅仅是说”嘿，这个东西是错的”。我很喜欢这一点。

好的，还有几个问题。之前我们在 Twitter 上问了大家想了解 Community Notes 的什么，其中一个是：为什么你们转向匿名贡献者，这个决定背后的考量是什么？

从实名到匿名的转变

Keith Coleman： 是的，我们当时进行了一个小规模试点，用几千名贡献者来测试，通过那个试点我们学到了很多。我们学到的最重要的东西，大概与贡献者的匿名性或化名性有关。我们最初假设人们在贡献时使用自己的真实账号、真实姓名之类的很重要。最初的原型就是这么设计的，我们认为这对于人们信任 Note 会很重要，但实际上完全错了。最佳方案恰恰与我们最初尝试的相反。

我们发现了几个问题。第一，人们不愿意在有争议的话题上撰写 Note，因为他们不想在网上被攻击或骚扰。所以有些人对此觉得没问题，但其他人并不这么觉得，这意味着本可以写出来的优质 Note 比实际写出来的要多得多，这是从试点中得到的非常明确的反馈。

第二，这个超级有趣——人们在匿名或化名的状态下，实际上比使用真名时更愿意跨越党派边界，而这一点从直觉上很容易理解。如果你公开使用自己的名字，你觉得自己属于某一方的阵营，你可能会犹豫是否要被认为背离了那一方。但实际上，你可能——举个例子——觉得一条批评你所在阵营的 Note 很有帮助。有很多研究表明，当人们处于匿名状态时，他们更愿意跨越党派边界，与另一方合作，认同另一方。我们也观察到了同样的现象。所以通过允许人们使用化名，你实际上获得了关于他们真实想法的更诚实的回答，这有助于发现真正的分歧——

Lenny Rachitsky： 这太反直觉了。

Keith Coleman： 是的。

Lenny Rachitsky： 你通常听到的总是相反的说法，结果实际上恰好相反，这太有意思了。

Keith Coleman： 是的，是的。

Jay Baxter： 我认为同样的原则也适用于将点赞设为私密。

Lenny Rachitsky： 我刚才正好在想这个。

Jay Baxter： 是的。

Lenny Rachitsky： 对，我现在点赞了更多稍微有点那个的东西——那些我以前肯定不会点赞的。

Keith Coleman： 它为诚实提供了自由空间，这相当棒。对化名制的一个批评是，它可能导致——也许人们达不到他们公开呈现时所保持的质量标准，但我们的系统中有如此多的质量保障机制，所以这并不是问题，我们可以在保持高质量的同时为那种诚实敞开大门。

推翻既有信任与安全机制

Lenny Rachitsky： 另一个问题——你之前稍微提到过一点，就是如何在 Twitter 既有的信任与安全体系中进行斡旋。正如你所描述的，以前基本上就是”我们来决定什么是真的、什么不是”，每家公司都是这样运作的。而你们基本上颠覆了这一点，说”这里有一种完全不同的方式，你们无法控制我们说什么真、什么不真”。谈谈那次经历吧——克服那个障碍，那个”好吧，忘掉那些，我们用完全不同的方式来做”的艰难挑战。

Keith Coleman： 是的，我们提出的东西确实非常不同。我想说的是，我觉得人们总体上对此是持开放态度的，我认为大家都有一种感觉，即当时的做法并不是很有效，也没有真正解决问题，人们愿意接受新的想法，所以这是一个不错的基础。

但我觉得我们做了一件可能非常有帮助的事，就是我们希望这个产品在任何阶段都能自我证明。首先它得证明人们有可能觉得 Note 有帮助，然后它得证明人们有可能写出高质量的 Note。所以每次我们提议对产品做什么事情——比如运行某项研究测试、启动试点、或扩大试点规模——我们手里总有数据说明这是一个好的决定，说明我们正在推进的下一步扩展是合理的。所以我猜我们很少提出任何看起来不明智的建议，因为我们自己就维持着如此高的质量标准，我怀疑这在很大程度上起了作用。

Lenny Rachitsky： 所以部分是——我听到的是——一步一步来，证明这确实有效；另一部分是，在试图说服信任与安全团队这就是正确的方向之前，先让自己确信它确实有效。

Keith Coleman： 正是如此。

从”不可能”到”真的可以考虑”

Lenny Rachitsky： 在这段历程中，有没有一个时刻，人们的反应从”这不可能行得通”转变成了”好吧，哇，让我们认真考虑一下”？还是说这是一个非常渐进的过程？

Keith Coleman： 你是说其他人从”不可能”到”哇，让我们认真……”

Lenny Rachitsky： 对，就是在公司内部，从”我们要继续沿用信任与安全团队的运作方式”到”转而依赖 Community Notes”，有没有这样一个时刻，说”好吧，我们真的要做这个切换了”？还是说这其实是 Elon 带来的，那才是最大的转折？

Keith Coleman： 最大的变化发生在 X 时期。在那之前，最大的决定只是把这个东西推出来，让它在公开环境下以全美规模运行。但确实，更大的转变是在 X 时期发生的。

Jay Baxter： 我觉得，即使在 Birdwatch 启动之前、Community Notes 启动之前，就已经有外部研究人员的原创研究，表明众包的事实核查员——普通人——能做到和专业事实核查员差不多好的程度，而且两组之间的共识率其实也挺接近的。但我觉得，即使有这些研究在那里，很多人确实是在它已经运作起来了之后，才真正相信它能行。

Lenny Rachitsky： 基本上就是用事实证明，证明它确实有效。对，这说得通——而不是一堆文档、策略和思考，就是”看，它真的在运作，你自己可以看到”。

Jay Baxter： 对。

项目在多次领导层更迭中存活下来的秘诀

Lenny Rachitsky： 有道理。好的，可能是最后一个问题了——看你们会引出什么问题分支来。我之前提过几次，这个项目取得的令人难以置信的成就：在 Jack 任内活了下来，然后我这儿记着 Kayvon 接手管理，然后 Parag 管理 Twitter，然后是 Elon，然后 Linda 接任 CEO——这相当罕见，尤其是这样一个如此高曝光度、对 X 的一切都如此有影响力的项目。对于这个项目在如此多的组织变革和领导者更迭中存活下来，你有什么经验或关键心得吗？

Keith Coleman： 做这件事的这段时期确实非常疯狂，但也很有趣，这种疯狂本身就很有娱乐性。我觉得这个产品之所以做得这么好、存活了下来，可能有一个原因是产品本身的性质。它被设计用来产出那些平时意见不合的人也会觉得有帮助的信息。所以即使你有意见相左的 CEO 或领导者，他们也很有可能觉得它有帮助——“哇，这东西确实产出了很有用的东西”。所以我觉得产品本身有一种特质，当人们看到它时，无论他们站在哪一边——左、右、上、下——都很有可能觉得它挺有帮助的，我认为这一点确实起了作用。

同时我也认为团队执行得非常好。我们有令人兴奋的远大目标，解决的是真实存在的问题，一个在世界上真正重要的问题。正如我们之前谈到的，在每一步，产品都需要自我证明，而我们会确保它证明了自己，然后把说服我们的结果拿出来与他人分享。于是他们会说，“哦对，我同意，它确实证明了自己，让我们迈出下一步吧。“我们一路上一直这样做，现在也继续以这种方式运作。我认为这种对重要的结果和目标的专注，以及扎实地执行，确实帮助很大。

在收购发生的那段时间里，团队几乎没有被什么东西分心。那段时期有很多让人分心的机会，但这个团队每周都在发布，我们高度专注于目标——让这个东西运作起来，让这些 Notes 出现在那里——我觉得人们看到了这种执行力，也愿意支持我们。

Lenny Rachitsky： 对，就像”它在运作，我们为什么要去动它？“而且它很重要，还省得我们雇几万人来做事实核查。

Keith Coleman： 这件事有意思的地方在于，在整个过程中，从来没有人问过我们、提起过、或似乎关心过任何与节约成本有关的事情。我觉得这是公司外部的人的一种假设，认为这一定是人们对它感兴趣的原因。但这从来不是目标，完全不是项目启动的原因，也不是人们对这个项目感到兴奋的原因。我觉得对于外面那些可能看不到内部对话的人来说，这也是一件令人感到暖心的事情——焦点始终放在解决问题上。另一种方式，即使你有一万个人在做，真正的问题在于它们效果不好，因为不被信任，或者无法扩展，或者太慢。所以目标始终就是帮助人们在大规模上保持信息灵通。让我们构建一个互联网规模的解决方案，来应对一个互联网规模的问题，而且是人们喜欢的解决方案。

低自我与项目成功

Lenny Rachitsky： Keith，当我向别人打听这件事是怎么运作的、为什么会这么成功的时候，有人跟我提到你，说你非常低自我（low ego），这让你能够放弃整个团队、权力和影响力，连名字都无所谓——“随便吧，你们想叫它 Community Notes 就叫 Community Notes，没问题。“关于这一点你有什么可以分享的吗？你怎么看待这件事？作为产品领导者，低自我有多重要？

Keith Coleman： 对我来说，这个项目——我觉得我在用这个项目做社区服务。我把我的工作视为为人和社区服务，这也是驱动我的东西。我唯一在乎的就是交付一个让世界觉得有帮助的成果。所以在某种意义上，这个项目从来不是关于自我，而是关于探求真相——不是”真相”意义上的什么信息是真的，而是让我们搞清楚到底怎样做才能让它运作起来。它需要怎样的结构，应该叫什么名字？任何能产生最好结果的做法就是我们应该做的。所以我觉得我更关注产品是否有帮助，而不是其他任何东西。所以在某种程度上，看起来像低自我，可能更多是因为我真的想把问题解决好。

Lenny Rachitsky： 我听到的部分意思还有——如果你赢了、成功了，好事自然会发生，所以专注在那上面就好。

Keith Coleman： 肯定会有令人满足的事情发生。看到人们欣赏它，这非常令人满足。左右两边的人都喜欢它，这令人满足。甚至连收到 Notes 的人都喜欢 Notes，主动联系作者、把它发出来——这太棒了，帮助人们获得这些让人感觉太好了。是的，这非常有驱动力，是每天早上醒来的一个很好的理由。

Lenny Rachitsky： 这件事居然成功了，这很荒诞，但同时又会觉得——当然它应该成功，当然这样的东西应该能行。就是非常有趣——

Keith Coleman： 这是互联网的产物，它属于互联网，这就是它能运作的原因。

Community Notes 的未来

Lenny Rachitsky： 天哪。Community Notes 接下来要往哪里去？正在发生什么，未来的方向是什么？

Keith Coleman： 我们基本上一直在朝着一个方向努力：更多、更好、更快的笔记。显然有机会让更多笔记涌现出来，我们希望它们保持现有水平甚至更好，同时希望它们更快地出现。所以我们一直在做核心产品的改动来实现这个目标。比如最近，我们刚刚发布了一项更新，就是所谓的 Community Notes 蝙蝠信号，也就是请求 Community Notes 的功能。X 上的任何人都可以说，“嘿，我觉得这条帖子需要一条 Community Notes”，现在他们甚至可以附上一个来源来解释原因，这样当潜在的写作者看到时，就能更容易地撰写笔记。所以我们一直在做诸如此类的核心改进和核心算法优化。

我觉得还有一些新的前沿领域展现出很大的潜力，AI 和 LLM 就是其中之一。很容易想象 AI 可以在很多方面帮助人们完成这项工作——快速地把信息传播出去。也许 Jay 可以谈谈我们和一些公司外部的人一起做的 Supernotes 项目。

Jay Baxter： 对，拥有公开数据和代码的一个很酷的好处就是，外部研究者可以和你合作。在这个案例中，Supernotes 团队提出了一个想法：我们可以把现有的笔记作为输入，把那些可能存在某些问题、只涵盖了部分事实、或者措辞带有某种偏见的已提交笔记都收集起来，把它们全部输入，让 LLM 生成大量不同的变体，然后基本上构建一个模拟陪审团——也就是模拟一组有代表性的 Community Notes 贡献者来给笔记评分，并根据他们过去的评分记录来预测他们会如何给这些 LLM 生成的笔记打分。这样一来，你实际上不是让 LLM 从零开始写一条笔记然后祈祷它写得好，而是可以模拟整个 Community Notes 的评分流程，明确地创建出很可能被人们评为有帮助的笔记。

我觉得这类想法对未来非常有前景，也是 LLM 和人类协作的一种很好的方式。当然，AI Agent 也可以浏览网页，你可以想象 Agent 辅助人类的一种方式就是检查笔记是否确实有来源支撑。不过这也会带来一些问题——人们还会那么认真地去核实吗？目前我觉得评分者非常认真，因为他们知道这只是一个 Community Notes 的贡献者写的，我最好在评为”有帮助”之前先核实一下。但我们希望能把产品设计成让人们不会盲目信任输出结果，而是在给出”有帮助”的评分之前自己去验证。

Lenny Rachitsky： 对，这真是一个非常值得探索的有趣领域——既要避免 AI 产生幻觉和垃圾内容，又要让它更容易扩展、覆盖面更广。真是一个有趣的挑战。

由人民构建的产品

Keith Coleman： 这个项目除了 AI 元素之外，还有一个很酷的地方，就是它是在公司外部完成的。我们之前谈到过开源透明性。我们把这一切开源的关键原因是让人们看到它是如何运作的，但梦想其实不止于此——不仅仅是笔记和评分的贡献来自人民，真正的梦想是这个产品由人民来构建。如果评分算法在很大程度上、甚至完全由公众来编写呢？那就太了不起了。而 Supernotes 可能是第一个非常有分量的、可能改变算法运作方式的潜在变更，而且它来自外部，有可能会成为核心的一部分。我们很希望看到产品朝这个方向发展。

Lenny Rachitsky： 太棒了，加油 Supernotes。两位，你们做的工作太了不起了。我觉得这是每个产品人的梦想——在一个小团队里，得到大量支持，产生巨大影响，而且本身就有天然的吸引力。我认为这会激励很多人。

那么让我问问你们，还有什么想分享的吗？还有什么觉得对听众有帮助的话想说？

Community Notes 的意外用途

Jay Baxter： 好的，我觉得在开发这个产品的过程中有一件事很有意思，就是……我觉得类似于转发功能最初并不是 Jack 想出来的，是用户自发开始这样做，然后它才成为产品的核心功能。Community Notes 也是如此，已经有很多令人意外的使用方式出现，人们在用 Community Notes 做的事情中有很多是我们没有预料到的，看到这些用户需求自然涌现真的很酷。

我觉得举个例子，我们一直设想的是政治类的不实信息，但不知为什么有很多人热衷于辩论 Messi 和 Ronaldo 谁进的球更多。这个挺有趣的。还有一个社区自治的方面——我们原本认为这专门用于为具有误导性或可能具有误导性的信息添加背景，但你可以看到有些笔记已经超出了这个范畴，转而举报那些他们认为是垃圾信息的内容。所以我觉得这也是 Community Notes 作为一款由人民驱动的产品的另一个维度。

Lenny Rachitsky： 这太美好了，基本上是他们在努力维护 Twitter/X 的健康生态，就像在说，不，这个应该被处理，这条推文是垃圾信息。

Jay Baxter： 对。

Lenny Rachitsky： 我太喜欢这个了。关于 Messi 对阵，另一个足球运动员是谁来着？

Jay Baxter： Ronaldo。

Lenny Rachitsky： Ronaldo，好的。这个有确定的事实答案吗，还是说根本就无法判断？

Jay Baxter： 对，我觉得这是一个很有意思的案例，因为评分者实际上两极分化很严重。这其实恰好契合我们的核心算法——有些人就是 Messi 或 Ronaldo 的铁杆粉丝，就像他们在政治议题上可能有的立场一样，所以我们实际上专门对那个话题以及其他一些话题进行了建模，这样我们就能估算人们在那场特定辩论中的立场。像这样的事情会涌现出来，还挺有趣的。

Lenny Rachitsky： 你是说那是 X 上最具争议的话题——Ronaldo 对阵 Messi。

Jay Baxter： 那确实是一个争议性很强的话题。

Lenny Rachitsky： 哇，谁能想到呢？好的。Keith，你还有什么要补充的吗？

对世界的乐观理由

Keith Coleman： 有的。Community Notes 本身就很酷，但它所揭示的关于社会的意义其实更大。社会经常让人觉得非常两极分化，你总是听到人们这样说，说没有人能在任何事情上达成共识。但实际上 Community Notes 向你展示了，人们真的可以在很多事情上达成共识。即便是在与政治等相关的极具争议的话题上，也存在大量共识，这正是笔记能够生效的原因。

我觉得这是对世界保持乐观的一个非常重要的理由——虽然世界看起来可能很两极分化，但可能大约 80% 的人在很多事情上是有共识的。想象一下，如果我们能把 Community Notes 中使用的同类方法用来寻找在立法、政策或其他人们希望政府或世界采取行动的事情上的共识，我们也许能为那些人民真正想要的想法积聚更多的推动力，每个人都会更幸福。也许处于两端的那 10% 的人不会满意，但我敢说有大量我们尚未识别的共识存在，如果我们去发现并落实它，我们大家都会相当满意。所以我不知道，我觉得人们很容易对世界感到悲观，但我认为这个产品是让我们对未来保持乐观的一个很好的理由。

Lenny Rachitsky： 用这种方式来收尾真是太棒了。Keith，我现在也能理解为什么大家想加入你、和你一起工作了。

Keith Coleman： 感谢。如果你确实想加入的话，我们正在招聘一位机器学习工程师。你可以和我们一起研究这些令人兴奋的问题，也会有很多乐趣，我们正在 x.com/communitynotes 接受申请。

Lenny Rachitsky： 好的，很高兴你给了网址。天哪，你们马上要被申请淹没了。各位，非常感谢你们来做这期节目。除了去那个地址加入团队做机器学习工程师之外，还有没有其他地方你想让大家关注的，比如你们的社交媒体或者其他什么？

Keith Coleman： 我在 X 上的账号是 KeithColeman，如果你有任何反馈或者想帮助我们，不管是想来这里工作还是想从外部参与贡献，都请联系我们，我们很乐意交流。

Jay Baxter： 我在 X 上是 @JayBaxter。我觉得除了使用 Community Notes 之外，如果能得到更多实质性的贡献就更好了——提交 pull request、合作像 Supernotes 这样的项目——如果大家确实想贡献的话，我觉得这是最令人兴奋的方式。

Lenny Rachitsky： 各位，去提交代码吧。太棒了。再次感谢你们来做这期节目。

Keith Coleman： 谢谢你的邀请，Lenny。

Jay Baxter： 谢谢，非常感谢。

Lenny Rachitsky： 这是我的荣幸。大家再见。非常感谢收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅本节目。也请考虑给我们评分或留言评论，这真的能帮助其他听众发现这个播客。你可以在 LennysPodcast.com 找到所有往期节目或了解更多关于本节目的信息。下期再见。

术语表

原文中文
A/B 测试A/B 测试（即对照实验，保留原文写法）
Amazon MTurkAmazon MTurk（亚马逊的众包微任务平台，保留原文）
Arma 3Arma 3（军事模拟视频游戏）
AsanaAsana（项目管理工具，保留原文）
BirdwatchBirdwatch（Community Notes 的项目原名）
Blake SchollBlake Scholl（Boom Supersonic 创始人兼 CEO）
bridging-based agreement algorithm基于桥接的共识算法（bridging-based agreement algorithm）
Chris BaleChris Bale（研究者，保留原文）
Community NotesCommunity Notes（X 平台的社区注释功能，暂保留原文）
Contributor贡献者（Contributor）
DAUDAU（Daily Active Users，日活跃用户数）
echo chamber回音室
ElonElon（指 Elon Musk，X/Twitter 所有者）
FigmaFigma（设计工具）
filter bubble过滤气泡
ICIC（Individual Contributor，个人贡献者，非管理岗）
JackJack（指 Jack Dorsey，Twitter 前CEO）
Jay BaxterJay Baxter（X 高级工程师，Community Notes 算法负责人）
JiraJira（项目管理工具，保留原文）
KaggleKaggle（数据科学竞赛平台，保留原文）
KayvonKayvon（Twitter/X 高管，Keith Coleman 的上司）
Keith ColemanKeith Coleman（X 副总裁，负责 Community Notes）
Lenny RachitskyLenny Rachitsky（播客主持人，《Lenny’s Newsletter》作者）
LindaLinda（Linda Yaccarino，X 现任 CEO，保留原文）
matrix factorization矩阵分解（matrix factorization，一种机器学习方法）
media literacy媒介素养
MessiMessi（Lionel Messi，阿根廷足球运动员）
MetaMeta（科技公司，Facebook 母公司）
Monday.comMonday.com（项目管理工具，保留原文）
OKROKR（Objectives and Key Results，目标与关键成果管理方法）
PageRankPageRank（Google 的网页排名算法，保留原文）
ParagParag（Parag Agrawal，Twitter 前CEO，保留原文）
PeriscopePeriscope（Twitter 旗下的直播视频应用）
pseudonymity化名性
RonaldoRonaldo（Cristiano Ronaldo，葡萄牙足球运动员）
SpacesSpaces（X/Twitter 的语音直播聊天室功能）
SupernotesSupernotes（一个利用 LLM 辅助生成 Community Notes 的外部研究项目）
ThermalThermal（Twitter 内部的隔离式创新团队机制）
Twitter 2.0Twitter 2.0（Elon Musk 收购 Twitter 后的改革计划名称）
Vitalik ButerinVitalik Buterin（以太坊联合创始人）
双重差分双重差分（difference in differences，一种因果推断方法）

此文档由 AI 分片翻译（translate_long_document）