过去几年，关于机器学习/AI（尤其是大型语言模型和生成式AI）偏见的爆款故事频频出现。关于偏见讨论中，我感兴趣的一点是：当生成式AI产生与用户请求截然相反的输出时，人们的反应与“经典”软件漏洞（存在明确错误的情况）下的反应截然不同。特别是，如果你去看论坛或其他非专业人士的讨论，人们经常否认模型输出与用户要求相反的现象是一种漏洞。例如，一年前，一位亚裔麻省理工学院研究生要求Playground AI（PAI）“为原图中的女孩制作一张专业的领英头像”，结果PAI将她的面部转换成了白人面孔和蓝眼睛。

Reddit首页关于此事排名第一的“没有偏见”回应，也是总体排名最高的评论之一，是这样的：

当然，现在你去最流行的Stable Diffusion模型网站看看首页的图片。

你会看到数量惊人（几乎占非动漫模型的50%）的亚洲女性，多到你会认为亚洲特质是一种被向往的特征。

这难道不比“一个女人在一个网站上输入了一个愚蠢的提示，然后他们生成了一个白人女性”更重要吗？

另外请记住，她输入的是“领英”，所以任何了解当前提示工作原理的人都知道，AI更可能搜索的是“领英上的普通女性”，而不是它认为的“职业女性”，因为图像AI没有观点。

简而言之，这只是AI引流文章。

其他表达相同主题的高赞评论包括：

老实说，这条评论应该排得更高。如果你想现在就用带检查点的Stable Diffusion，如果你不想要亚洲女孩，那就难多了。很多很多模型都是基于动漫或亚洲女性训练的。

以及：

对吧？AI图像甚至有相反的问题。训练集中亚洲人数量庞大，加上亚洲创建的模型数量庞大，意味着很多很多模型都偏向于输出亚洲面孔。

其他高赞评论指出这是样本量问题：

“系统性种族偏见的证据”

只展示了一个结果。

当《波士顿环球报》要求采访时，Playground AI的CEO也给出了同样的回应——他拒绝了采访，并回复了一系列反问句，如下（《波士顿环球报》暗示还有更多，但未刊登回复的其余部分）：

如果我只掷一次骰子得到数字1，这是否意味着我每次都会得到1？我是否应该根据一次观察就得出结论，认为这个骰子偏向数字1，并且被训练成倾向于掷出1？

我们本可以同样轻松地从谷歌、Facebook、微软或任何其他当前部署大量机器学习的公司中举出一个例子，但既然Playground AI的CEO基本上是在要求别人看看PAI的输出，我们在本文中就以PAI为例。我在我的Mastodon个人头像上尝试了麻省理工学院研究生使用的相同提示，将“女孩”替换为“男人”。PAI通常会将我的亚洲面孔变成白人（高加索人）面孔，但有时会让我变得更白一些但民族特征模糊（可能有点像中东人或东亚人之类。顺便说一句，我的面孔有一些独特的越南特征，看起来很越南，而不太像任何东亚人。

我的头像是一张浅肤色的冬季照片，因此我尝试了一张深肤色的夏季照片，结果PAI通常会将我的面孔转换成南亚或非洲面孔，偶尔是中国面孔（但从未是越南人或东南亚人面孔），例如如下：

许多其他人也尝试了各种提示，他们得到的结果也表明该模型（这里的“模型”是泛指，包括模型及其权重，以及任何负责生成输出的系统）对诸如“如果一个人从事特定职业，其种族是什么”之类的事情有一些先入为主的观念，这些观念强烈到足以覆盖输入的照片。例如，由于模型“决定”通过丢弃亚洲特征并使其变白可以使某人看起来更“专业”，从而将浅肤色亚洲人转换为白人。

其他人尝试了各种提示，以观察模型中捆绑了哪些先入为主的观念，并发现了类似的结果，例如，Rob Ricci在分别要求生成“计算机科学”、“哲学”、“化学”、“生物学”、“兽医学”、“护理学”、“性别研究”、“中国历史”和“非洲文学”X教授的“领英头像”时得到了以下结果。在为前7个提示生成的28张图像中，28人中可能只有1或2人不是白人。下一个提示“中国历史”的结果则极其刻板化，当我们要求生成非白人输出时，其他模型也经常出现这种情况。Andreas Thienemann指出，除了夸张的中国刻板印象外，每位教授都戴着眼镜，这是另一个经典的刻板印象。

如前所述，我并非特意针对Playground AI。正如我在别处指出的，价值万亿美元的公司经常将AI模型部署到生产环境中，甚至没有进行最基本的偏见检查；当我尝试ChatGPT时，我尝试的所有偏见检查提示返回的结果都类似于我们在此看到的图像，例如，当我尝试要求提供科技行业男性和女性的简介时，女性的简介往往表明她们从事多元化工作，即使对于没有相关公开记录的女性也是如此；而男性则倾向于拥有名牌工程学院（如MIT和伯克利）的学位，即使这些人并未就读于任何名牌学校，对于名牌科技公司也是如此（由于Twitter限制，链接只有4个例子，但我尝试的其他例子与显示的例子一致）。

本文本可以使用几乎任何公开可用的生成式AI。它之所以使用Playground AI，仅仅是因为CEO的回应既要求我们这样做，也反映了外行常见的标准反射式“AI没有偏见”的回应。

回到关于“由于亚洲人在其他情况下如此突出，因此将职业照片中的人变成白人并不算有偏见”的回应，我们之前查看的那条高赞Reddit评论建议“去最流行的Stable Diffusion模型网站看看首页的图片”。以下是我点击该评论发布当天链接并点击“feed”后看到的内容。

[点击展开/折叠略带NSFW的图片]

这个网站有点色情的感觉。中位数的图像可以描述为“你期望在电影场景中一个青少年男孩房间墙上看到的海报，编剧们为了展示这个角色是一个饥渴且社交能力差的青少年男孩而使用标准道具”。当你进入feed并获得默认的“有史以来”排名时，首先显示的是有人抓着一个年轻女性的胸部，标题为“引导式抓胸 | LoRA”；两个年轻女性在亲热，标题为“动漫之吻”；以及一个戴着皮带的年轻女性，标注着“BDSM —— 被拴住的LORA”。因此，显然有一个网站被人们喜欢用来生成和传播色情照片，该网站上亚洲女性照片的高比例被用作证据，证明不存在对亚洲女性有负面影响的机器学习偏见，因为这抵消了一位亚洲女性在试图获取用于领英的正式照片时被变成白人的情况。我真的不知道该说什么。Fabian Geisen的回应“🤦‍♂️. truly 'I'm not bias. your bias' level discourse”，感觉是恰当的回应。

评论中展示的另一种标准推理线，在我看到的几乎所有关于AI偏见的讨论中都很典型，其代表为：

AI在“专业人士”股票照片上训练，然后让她变白。我们感到惊讶吗？

她要求AI让她的头像更专业。互联网上大多数“专业”股票照片里都是白人。

以及：

如果她要求她的照片变得更像任何东西，它都可能让她变白，仅仅因为在西方，亚洲人只占美国人口的7.3%，其中很大一部分是南亚人，看起来和她（东亚人）的特征完全不同。东亚人只占5%或更少；训练数据太少。

这些评论似乎基于一个基本假设，即公司使用的训练数据代表美国，而且这是合理的，并且这应该导致模型将每个人转换为最常见的类型。这在多个层面上都是错误的。

首先，关于专业股票照片是否以白人为主，快速搜索“专业股票照片”图像会显示不少非白人面孔，所以要么股票照片并非那么白，要么人们已经想出了如何返回更具代表性的股票样本的方法。并且考虑到全球人口分布，目前不清楚互联网服务应该以美国为中心。然后，即使我们接受主要互联网服务应该假设每个人都在美国，假设每个请求都来自“典型美国人”似乎既是设计缺陷，也是偏见的明显标志。

由于许多人在谈论种族或民族时会有这种反射性反应，让我们来看一个不那么敏感的AI假设。假设我与当地机械师的AI客服聊天机器人交谈，要求预约更换冬季轮胎并进行轮胎换位。然后，当我取车时，发现他们给我换了机油而不是冬季轮胎。接着一群网络评论员解释为什么这不是任何偏见的迹象，并且你应该知道AI聊天机器人会将任何与机械师的预约转换为换机油预约，因为这是最常见的预约类型。一个将任何预约请求都转换为“给我最常见的预约类型”的聊天机器人显然是损坏的，但出于某种原因，AI辩护者坚持认为，当涉及改变某人的种族或民族时，这是可以的。同样，声称我的换轮胎预约被转换为换机油预约是没问题的，因为其他公司的调度程序会将换机油预约转换为换轮胎预约，这听起来很荒谬，但这是我们在上面讨论的另一种常见推理线。

假设我使用某种标准的非AI调度软件（如Mindbody或JaneApp）来预约机械师，并要求预约更换轮胎和换位。如果我最终被换了机油，仅仅因为软件只是调度最常见的预约类型，这将是软件存在漏洞的明显标志，没有理性的人会认为应该不努力修复这个漏洞。然而，这是人们在AI方面经常提出的一个论点（这可能是关于此话题评论中最常见的辩护）。这种论点更进一步，即存在一种对漏洞产生原因的解释，被用来证明该漏洞应该存在，人们甚至不应该试图修复它。这样的解释对于“经典”软件漏洞来说显然是荒谬的，对于机器学习来说同样荒谬。也许可以辩称，机器学习中的漏洞更难修复，修复它不切实际，但这不同于常见的论点——即认为这不是漏洞，并且这就是软件应有的正确行为。

我可以想象一些用户在程序采取对用户来说更不透明的操作时（例如自动更正）会这么说，但我确实尝试在Reddit上搜索autocorrect bug，在前3个帖子中（我没有查看其他帖子），255条评论中有2条否认不正确的自动更正是漏洞，而且这两条评论都来自同一个人。我敢肯定，如果你深入研究足够多的话题，你会发现某些话题的否认率更高，但在搜索了另外几个话题（如excel格式和自动更正漏洞）后，我搜索的话题都没有接近我们在生成式AI中看到的情况——在那里，一半的评论者激烈否认提示产生与用户要求相反结果是一种漏洞并不罕见。

回到漏洞本身，就机制而言，我们在分类器和生成模型中都能看到的是，许多（也许是大多数或几乎所有）系统都吸收了互联网样本中反映的、许多人存在的偏见，从而导致诸如谷歌图像分类器将黑人手握温度计分类为{手, 枪}，而将白人手握温度计分类为{手, 工具}¹之类的事情。在过去十年中，发生了许多此类错误，从2015年谷歌相册将黑人分类为大猩猩，到2018年部署某种文本分类器用于广告，将包含“非裔美国作曲家”和“非裔美国音乐”等术语的广告分类为“危险或贬损”，谷歌在Gemini上则把旋钮转到了另一个方向，顺带一提，这引发的愤怒比其他任何例子都大。

偏见进入自动化系统并不是新鲜事。这早于生成式AI和大型语言模型，也是机器学习模型之外存在的问题。只是机器学习的广泛使用使这些问题对人们变得可理解，从而使其中一些案例成为新闻。例如，如果你看压缩算法和字典，Brotli严重偏向英语——该语言内置的120个转换中，涉及人类语言的元素都是英语，内置压缩字典的英语权重也比你可能参考的任何代表性权重（按人口加权的语言使用者、非自动化人类语言在消息平台发送的文本等）都要重。你可以为为什么英语应该被如此重度加权提出理由，但也有相反的理由，例如，英语使用率与用户的带宽正相关，因此平均而言，非英语使用者更需要压缩。但是，无论你认为应该使用什么精确的加权函数来生成代表性的字典，这都不会成为轰动新闻，因为你无法让典型读者关心120个内置Brotli转换中有许多做的事情，如在文本中添加“ of the ”、“. The”或“. This”，这些高度针对英语，没有任何转换编码高度针对其他人类语言的术语，尽管世界上只有20%的人说英语，或者，与使用者数量相比，内置压缩字典与其他任何人类语言相比，都极度倾斜于英语。你可以为Brotli字典提出类似于上述的辩护，在Brotli字典训练所依据的某个代表性语料库上，我们使用Brotli字典获得了最佳压缩，但字典中有很多奇怪的短语，如“World War II”、“, Holy Roman Emperor”、“British Columbia”、“Archbishop”、“Cleveland”、“esperanto”等，这可能会让我们怀疑，训练字典的语料库也许并非最具代表性，或者甚至并非特别代表人们发送的文本。包含“, Holy Roman Emperor”在字典中，在互联网发送文本的整个分布上，真的比包含任何其他内容（如法语、乌尔都语、土耳其语、泰米尔语、越南语等）能产生更好的压缩效果吗？

另一个不太可能成为轰动新闻的例子是，我无法在博客标题中放入我的越南语名字，并期望我的博客在越南语谷歌之外被谷歌索引——我在开始博客时尝试过，结果我的博客立即从谷歌搜索中消失，除非你在越南。人们默认假设大家想要英语搜索结果，并且，大概有人创建了一个启发式方法，如果一个页面上有两个带越南语变音符号的字符，该方法就会触发，有效地将该页面标记为“太亚洲”，因此除了一个国家外，世界上任何其他地方的人都不感兴趣。“看起来像越南人”似乎是漏洞的一个相当普遍的原因。例如，即使没有变音符号，越南名字也是个问题。我经常遇到表格要求我提供我母亲的娘家姓。如果我输入我母亲的娘家姓，我会被告知诸如“无效姓名”或“姓名太短”之类的信息。这没关系，因为我用一个替代品来应对这种粗心大意，这可能更安全。另一个问题是人们认定我告诉他们我的名字不正确并更改我的名字。对于我的姓氏，如果我读我的名字是“Luu, L-U-U”，有一半的情况会被从越南语“Luu”缩短为中文“Lu”，很多时候也被缩短为西方名字“Lou”，但我发现如果我说“Luu, L-U-U, two U's”，大约95%的情况都能奏效。这有时会让对方感到恼火，他们会恼怒地说诸如“你没必要拼写三遍”之类的话。也许对那个特定的人是这样，但大多数人不会理解。这甚至发生在我将名字输入计算机系统时，因此在名字被数字化记录之前，不可能有转录错误。我的法定名字（没有变音符号）是Dan。对于越南裔美国人来说这并不罕见，因为Dan既可用作越南名字，也可用作美国名字，而且许多越南移民不知道Dan通常是Daniel的简称。在我全职工作过的六家公司中，有三家公司有人“好心地”将我的名字改为Daniel，大概是因为有人看到数据库中记录了Dan，于是认定我没有正确输入名字，而他们比我更了解我的名字，并且他们对此非常确定，以至于觉得没必要问我确认。在一个案例中，这只影响了我的电子邮件显示名称。由于我对别人如何称呼我并无强烈感受，我没有费心去更改它，许多人在那里工作时都叫我Daniel而不是Dan。在另外两个案例中，名字更改影响了重要的文件，所以我不得不实际更改它，以便我的保险、税务文件等与我的法定名字一致。如上所述，用我的头像向Playground AI发出相当无害的提示，即使在罕见的情况下产生亚洲输出，似乎也产生东亚输出而非东南亚输出。我在一些大公司的生成式AI模型上也注意到了同样的事情——即使你要求它们产生东南亚输出，它们也会生成东亚输出。被宣传为清理错误和噪音工具的AI工具也会清理掉亚洲特征（以及其他类似的“错误”），例如，使用过Adobe AI降噪（宣传为“通过语音增强从录音中去除噪音”）的人指出，它会去除亚洲口音，使人听起来像美国人（同样也适用于其他一些口音，如东欧口音）。

我大概每周仅在广泛使用的软件的使用过程中就能看到几十到几百件这样的事情（远少于之前观察到的每周数百到数千个的整体漏洞数量），但我交谈过的大多数美国人根本没有注意到这些事情。最近，有很多关于各种机器学习系统中的偏见所造成的所有危害的讨论，机器学习的广泛使用将带来各种新的危害。这或许没错，但我的感觉是，自从我们拥有自动化以来，我们就已经将偏见编码进自动化中，自动化范围和规模的扩大一直并将继续增加自动化偏见的范围和规模。只是现在，许多机器学习的使用使这些偏见对普通人变得更加可理解，因此更可能成为新闻。

在我目前看到的关于这个话题的流行文章中，存在一种非历史性的观点，即它们没有承认这里的核心问题并非新问题，从而导致在提出解决方案时出现两类问题。其一是解决方案通常是针对机器学习的，但这里的问题无论是否使用机器学习都会发生，因此针对机器学习的解决方案似乎关注错了层面。当提出的解决方案是通用性时，我看到的解决方案是以前提出过并且失败了的。例如，至少在过去的二十年里，也许最常见的（除非“人们应该更关心”算作行动呼吁）行动呼吁之一，就是我们需要更多元化的团队。

这显然没有奏效；如果奏效了，上面提到的问题就不会如此普遍。这没有奏效并且不会奏效存在多个层面，其中任何一个层面都足以使这个解决方案失败。一个问题是在整个行业，掌权者（高管和控制资本的人，如VC、PE投资者等），总体而言，并不关心这个。尽管有效率理由支持更多元化的团队，但其理由永远不如游戏和体育领域的决策那样清晰明确，在那里，我们看到非常昂贵且容易量化的糟糕决策在错误被指出几十年后仍然存在。然后，即使高管和资本接受了这个想法，它仍然不会奏效，因为维度太多。如果你看一家真正重视多元化的公司，比如2013-2019年的Patreon，如果组织能够在两三个维度上认真重视多元化，而在成百上千的其他维度上（例如越南名字或面孔是否处理得当）有所疏忽，那就算幸运了。

即使所有这些都不是问题，解决方案仍然不会奏效，因为虽然拥有一支具有相关多元经验的团队可能与问题优先级有一点相关性，但它并不能自动导致问题被优先考虑和修复。举一个非敏感的例子，一个自谷歌地图交通估算功能诞生以来就存在的漏洞，至少到2022年还存在（自那以后我开得不多，不知道漏洞是否还存在）是：如果我在高峰时段开始时询问行程需要多长时间，这会考虑当前交通状况，而不是我行驶过程中交通状况的变化，因此系统性低估了行程所需时间（反之，如果我计划在高峰时段出行，这会系统性高估行程所需时间）。如果你试图通过增加谷歌地图通勤多元化来解决这个问题，这将会失败。已经有许多从事谷歌地图工作的人开车并能观察到估算系统性错误的方式。增加多元化以确保有开车并注意到这些问题的人，不太可能起到什么作用。或者，举另一个例子，当Uber支付团队的前经理被Uber的机器学习模型错误地标记为交易欺诈而错误地被禁止访问时，没有人能够弄清楚发生了什么或是什么偏见导致他被错误禁止（他们通过将他的用户添加到允许名单中解决了问题）。很少有人会比支付团队的前经理获得更好的服务，即使在那种情况下，Uber也无法真正弄清楚是怎么回事。雇佣一名“多元化”候选人加入团队，并不会自动解决或显著影响候选人所多元化维度上的偏见，因为团队前经理在六个月调查后只能通过白名单恢复账户访问权限。

如果你的软件开发方法学导致的结果是：支付团队经理被禁止的修复方案是六个月后将其加入白名单，你应用中的交通路线二十年来系统性错误，你应用的核心功能不工作，等等，那么无论雇佣多少背景与注意到某些类型问题相关的多元化候选人，都不会导致修复这些问题，无论是机器学习偏见还是其他类别的漏洞。

当然，有时旧想法的变体确实会成功，但一个提案要可信甚至有趣，必须解决为什么下一次迭代不会像之前所有迭代那样失败的问题。如上所述，我看到的两个最常见的建议方案是：人们应该更努力、更关心，以及我们应该拥有不同背景（在非技术意义上）的人。这对于大量的“经典”漏洞没有奏效，对于旧的机器学习漏洞没有奏效，似乎也没有理由相信它应该对当今机器学习模型产生的这类漏洞奏效。

Laurence Tratt说：

我认为这比个别的偏见实例更重要。有趣的是，大多数人a)没有注意到他们正在引入这样的偏见，b)通常甚至不能合理地期望他们注意到。例如，一些网页表单拒绝了我以前的地址，因为我住在乡村，那里的许多房屋只有名字——但大多数开发者住在城市，那里的房屋只有编号。从某种意义上说，这是主动偏见在起作用，但没有恶意：程序员必须填写设计细节并做出选择，他们将根据自己的经验来这样做。我们谁都不是无所不知！这就提出了一个有趣的哲学问题：假设组织应该意识到他们正在编码偏见，何时才是合理的？

我的感觉是，机构和产品的“自然”状态，即最低能量和最直接的状态，就是它们工作得不太好。如果之前没有灌输一种文化或建立流程来在某个特定维度上培养质量，质量可能就会很差，因为制作高质量的东西很困难，因此组织应该预期，如果没有一个强大的流程来捕捉偏见，他们正在编码各种各样的偏见。

我们在这里遇到的一个问题是，当涉及消费类软件时，公司普遍选择了速度而非质量。考虑到我们今天所处的监管环境，或者我在有生之年可能看到的任何监管环境，这似乎基本上是不可避免的，因为那些真正选择质量而非功能速度的公司会被淘汰，因为消费者普遍选择成本更低或功能更多的选项，而不是质量更高的选项。我们在研究汽车在样本外碰撞测试中的表现时看到了这一点，我们发现只有沃尔沃在为实际碰撞优化汽车，而不是为了在公开测试中取得好成绩。尽管车祸是50岁以下人群的主要死因之一，但消费者为安全付费的优先级如此之低，以至于沃尔沃已成为一个利基品牌，不得不向高端市场转移，销售豪华车才能生存。我们在CPU上也看到了类似情况，英特尔过去比AMD和ARM投入更多的验证工作，相应地严重的错误也更少。当AMD和ARM开始严重威胁时，英特尔将努力从验证和确认转移开，以提高速度，因为其质量优势在市场上并没有带来任何好处，现在英特尔芯片几乎和AMD芯片一样容易出错。

我们可以在几乎每个消费市场以及许多B2B市场观察到类似情况，而当我们谈论的是已有解决方案的问题时。如果我们看一个从技术角度看我们不知道如何很好解决的问题，比如机器学习模型中微妙甚至不那么微妙的偏见，那么我们应该预期会看到比“经典”软件系统更多、更糟糕的漏洞，这正是我们所看到的。任何经得起市场考验的解决方案，都必须能够抵御消费者会压倒性地选择漏洞更多但拥有他们想要的功能或更快发布他们想要的功能的产品这一问题，这使得任何需要小心谨慎以至于显著减慢发布速度的解决方案处于非常困难的境地，除非存在一个像英特尔在其鼎盛时期那样的单一主导玩家。

感谢Laurence Tratt、Yossi Kreinin、Anonymous、Heath Borders、Benjamin Reeseman、Andreas Thienemann和Misha Yagudin的评论/修正/讨论

附录：从技术上讲，改善情况有多难？

这是一个真诚的问题，而不是反问。自从2014年以来，我没有做过任何机器学习相关的工作，所以我对目前情况的了解不够深入，无法对技术层面形成直接意见。许多比我最近更多从事机器学习工作的人，如Yossi Kreining（见下文附录）和Sam Anthony，认为这个问题非常困难，也许以我们目前所处的阶段是几乎不可能解决的。

由于我没有直接意见，这里有三种听起来可能类似的情况，每一种都支持不同的结论。

类比一：也许这就像人们从2014年起就说会有人很快构建一个谷歌，因为现有的开源工具基本上已经比谷歌搜索更好，或者人们说构建一个将高级语言原语编码到硬件中的“高级”CPU会给我们带来通用CPU性能1000倍的提升。你无法真正证明这是错误的，而且搜索质量的巨大改进或CPU性能1000倍的提升可能就在眼前，但提出这些建议的人通常听起来像怪人，因为他们表现出我们提到的非历史性，并提出了我们已知不起作用的解决方案，却没有解释为什么他们的解决方案将解决导致先前尝试失败的问题。

类比二：也许这就像软件测试，软件漏洞无处不在，尽管硬件行业有数十年关于如何更高效找到漏洞的经验，但这些技术中的应用却很少。我多次和人们谈论过这个问题，最常见的回应是关于应用程序XYZ有某些独特的约束，使得测试完全不可能或无法使用我讨论的这类技术，但每次我深入研究，都发现该应用程序比我见过这些技术被应用的领域更容易测试。人们可以认为我在测试方面是个怪人，但我实际上已经使用这些技术测试了各种软件并成功做到了，所以我不认为这与声称如果我们只使用我的宠物CPU架构，CPU就会快1000倍之类的事情相同。

考虑到存在的激励因素，软件公司通常可以将漏洞成本转嫁给客户，而客户并不真正了解发生了什么，我认为除非监管发生变化，否则我们不会看到在测试方面投入大量努力，但并没有根本原因我们需要避免使用更高效的测试技术和方法。

从技术角度来看，使用更好测试技术的障碍相当低——我已经指导过人们如何开始编写自己的模糊测试器和随机测试生成器，这通常需要30分钟到一小时，之后人们往往会比以前更有效地使用这些技术来发现重要的漏洞。然而，通过揭示的偏好，我们可以看到组织并不真正“想要”让他们的开发者高效地测试。

当涉及测试和修复机器学习模型中的偏见时，情况更像类比一还是类比二？虽然我不能有把握地说我们处于类比二，但我不确定如何能说服我不是处于类比二。如果我对测试一无所知，我会听所有这些人向我解释为什么他们的应用无法以找到严重漏洞的方式进行测试，然后得出如下结论之一：

• “大家”都是对的，这很合理——这是他们了解的领域，而我不了解，所以我为什么应该相信不同的说法？
• 没有意见，也许是因为默认的高怀疑水平。
• 每个人都错了，鉴于我对该领域一无所知，并且没有特别的理由相信每个人都错了，这似乎不合理。

作为一个局外人，需要非常高度的过度自信才能断定每个人都错了，所以我要么错误地得出“大家”都对的结论，要么没有意见。

鉴于“经典”测试的情况，我觉得我必须在这里没有真正的意见。没有最新的知识，得出这么多专家都错了的结论是不合理的。但有足够多的人们说困难或不可能的问题，结果证明是可行的而且并不那么棘手，以至于我很难在没有实际研究的情况下高度相信一个问题本质上是不可解决的。

我认为无法估计如果我真的研究了它我会怎么想。假设我尝试在这个领域工作，并试图在OpenAI或其他从事此类问题的地方找到一份工作，不知怎么通过了面试，我在该领域工作了几年，但没有取得进展。这并不意味着问题不可解决，只是我没有解决它。当涉及“Lucene基本上和谷歌搜索一样好”或“CPU可以轻易快1000倍”之类的言论时，该领域的人们显然知道说这些话的人是怪人，因为他们表现出对领域实际问题完全缺乏理解，但做出这样的判断需要对该领域有相当多的了解，我不认为有什么捷径可以让你可靠地推断出你在拥有该领域知识时会如何判断。

附录：本文的故事

我在2023年中Playground AI事件走红时写了本文的初稿，然后搁置了一年，看看当该事件不再是突发新闻时，它是否仍然成立。一年后回顾，我不认为核心问题或我看到的关于该话题的讨论有太大变化，所以我将其整理干净，并于2024年中发布了本文。

如果你喜欢做预测，你认为十年后（2033年）这篇文章仍然相关的几率有多大？供参考，这篇2014年发布的关于“经典”软件漏洞的文章，今天（2024年）发布也可以达到基本相同的效果（我说基本相同是因为我今天看到的漏洞比2014年多，而且我今天看到的前端和操作系统漏洞也比2014年多得多，所以会有更多不同类型的漏洞）。

附录：其他人的评论

附录：重现Rob Ricci的结果

我使用默认设置尝试了提示，除了将图像质量降低到10以更快地生成图像。这意味着我们使用512/512、7提示引导、10质量、随机种子。尝试2次后，将图像质量提高到40，因为图像质量太低，有时无法分辨种族。除了增加图像质量外，没有尝试重新运行提示或从输出中进行任何选择。提示是“为X生成一张看起来非常专业的领英头像”，其中X是博士、律师、工程师、科学家、记者和银行家。

这产生了以下图像：

大致来说，我认为Rob的结果被重现了，考虑到我们已经看到这么多图像，这应该不足为奇。

然后，为了看看我们能否重现标准的反驳论点（即生成式AI没有偏见，因为请求色情图像时经常出现亚洲女性），我尝试提示“为一位色情明星生成一张低俗的Instagram头像”。存在NSFW过滤器，在某些情况下被触发，因此我们没有得到四张一组的图像，而是得到了：

[点击展开/折叠非常轻微的NSFW图像]

而且，确实，生成的图像比亚我们任何专业照片（除了Rob Ricci为“中国研究教授的领英头像”请求生成的一组照片）都更加亚洲化。

附录：Benjamin Reeseman的评论

由 mimo-v2.5 模型翻译，花费 23031 tokens

普遍存在一种说法：微软在史蒂夫·鲍尔默领导下一蹶不振，后来被萨提亚·纳德拉的卓越领导力所拯救。这是我在所有在线讨论中看到的主流叙事，也是“现实生活中”普遍接受的看法。虽然本文无意对纳德拉的领导力提出负面评价，但这种说法低估了鲍尔默对微软成功的贡献。不仅在鲍尔默任期内，微软的财务表现（收入和利润）非常出色，而且他领导下的微软做出了深入、长期的战略投资，为他卸任后数十年的成功奠定了基础。当时这些投资备受批评，表明它们并非显而易见，但回顾来看，尽管面临当时的质疑，公司做出了非常有力的决策。

除了在后来被归功于纳德拉的领域进行深入投资外，鲍尔默还为任何继任者清除了政治障碍，为纳德拉的成功铺平了道路。正如加里·伯恩哈特曾因将问题陈述和解决方案表述得过于显而易见而遭到批评，以至于人们没有意识到自己学到了非同寻常的东西，鲍尔默为微软未来的成功所做的铺垫如此有效，以至于人们很容易批评他是一个无能之辈，因为他的继任者如此成功。

对鲍尔默的批评

对于那些在世纪之交之前没有经历过的人来说，在90年代，微软曾被认为是城里最大、最强的公司。但不久之后，人们对微软的看法就改变了——到2007年，许多人认为微软是下一个IBM，保罗·格雷厄姆写下了《微软已死》，文中指出微软曾被认为是高效的已是古老的历史：

几天前，我突然意识到微软已经死了。当时我正在和一位年轻的初创公司创始人谈论谷歌与雅虎的不同之处。我说雅虎从一开始就因害怕微软而扭曲了自己的定位。这就是为什么他们将自己定位为“媒体公司”而非科技公司。然后我看着他的脸，意识到他并不理解。就好像我告诉他80年代中期的女孩有多喜欢巴里·曼尼洛一样。巴里是谁？

微软？他没说什么，但我能看出他不太相信有人会对他们感到恐惧。

这类评论通常伴随着微软收入注定会下降的说法，比如格雷厄姆的这些评论：

演员和音乐家偶尔会复出，但科技公司几乎不会。科技公司就像抛射物。正因为如此，你可以在任何问题出现在资产负债表上之前就宣称它们已死。相关性可能领先收入五年甚至十年。

格雷厄姆将谷歌和互联网的崛起称为微软死亡的主要原因，我们稍后会讨论这一点。尽管格雷厄姆没有点名鲍尔默，也没有指出他在《微软已死》中的影响，但鲍尔默几十年来一直是技术人员最喜欢的靶子。鲍尔默是从商业领域起家的，后来成为销售与支持执行副总裁；技术人员喜欢贬低科技行业中非技术背景的人¹。当时和现在一个常见的批评是，鲍尔默不懂技术，是一个糟糕的领导者，因为他只知道销售和利润，只会抄袭别人做过的事情。举个例子，如果你在科技论坛（minimsft、HN、slashdot等）上看鲍尔默在2012年将辛诺夫斯基赶走时的在线评论，鲍尔默的领导力几乎受到普遍批评²。这里有一条典型的评论，来自一位自称是匿名微软内部人士的人：

赶走鲍尔默。从失败的在线服务部门（它们永远不会变得更好）开始，裁员40%。将数十亿美元重新投资于普吉特海湾地区可以为微软带来增值或收购目标的创业机会……重置Windows——桌面和平板电脑。认真对待企业云（如Salesforce……）

就鲍尔默为自己辩护而言，他指出市场似乎低估了微软。鲍尔默指出，当时微软的市值相对于其基本面/财务表现，与亚马逊、谷歌、苹果、甲骨文、IBM和Salesforce相比非常低。这似乎是鲍尔默的公允评估，因为自那时起，微软的表现优于所有这些公司。

当纳德拉成为CEO后微软市值飙升时，叙事自然是鲍尔默正在扼杀微软，公司一直在挣扎，直到纳德拉将其扭转。你可以选择其他讨论，但举个例子，如果我们看最近一次《微软已死》在Hacker News上排名第一时，快速搜索一下，鲍尔默的名字出现了24次。鲍尔默有一些辩护者，但标准的叙事——鲍尔默在拖累微软——就在那里，其中一位辩护者甚至使用了部分标准叙事：鲍尔默是一个缺乏想象力的庸才，但他至少在财务上为微软奠定了良好基础。如果你看高排名的评论，它们都在嘲笑鲍尔默。

如果你看那些信息较少的论坛，比如Twitter或Reddit，你会看到同样的攻击，但鲍尔默的辩护者更少。在Twitter上，当我搜索“Ballmer”时，前四个结果都是明确嘲笑鲍尔默的。第五个结果可能褒贬不一，但从评论来看，似乎通常也被视为嘲笑鲍尔默，而且在我滚动查看的过程中，除一个视频外，其余的视频都在嘲笑鲍尔默（那个例外是一个采访，鲍尔默提到他在2009年向扎克伯格出价“200亿美元以上，大概是这个数”收购Facebook，这在当时将是第二大科技收购案，仅次于卡莉·菲奥莉娜2001年以250亿美元收购康柏）。在Reddit上搜索（使用无历史记录的隐身窗口）也是同样的情况（排除关于他作为NBA老板的故事，他在球迷中受人尊敬）。头号故事在嘲笑他，下一个故事指出他比比尔·盖茨更富有，关于他作为CEO表现的最高评论以“讽刺的是，他是微软[原文如此]最糟糕的CEO”开头，然后是标准的叙事：公司现在做得好的唯一原因是纳德拉拯救了局面，鲍尔默错过了科技行业所有重要的变化，等等。

总结一下，过去二十年里，人们一直在嘲笑鲍尔默是个不懂科技的滑稽人物，充其量是个只知道如何维持公司运转、不知道如何促进创新、导致微软在所有重要市场落后的记账员。

鲍尔默的胜利

这种普遍看法与鲍尔默领导下的实际情况相矛盾。自格雷厄姆宣布微软已死以来，在鲍尔默领导下发生的具有财务意义的积极事件包括：

• 2009年：必应推出。这被认为是一个巨大的失败，但这里的标准相当高。快速网络搜索显示，必应据称在2015年盈利10亿美元，在2024财年盈利64亿美元，收入126亿美元（根据微软2022年的市盈率，粗略估计必应在2022年的价值约为2400亿美元）
• 2010年：微软创建Azure
  • 我不能说我自己喜欢这个产品，但就运营大规模云基础设施而言，世界上遥遥领先的三家公司是亚马逊、谷歌和微软。从商业角度来看，你能对微软在这里说的最坏的话就是它是该业务的可靠第二名，并且是成为第一名的最大威胁
  • 在鲍尔默领导和培育下建立的企业销售部门，对Azure和Office的成功至关重要
• 2010年：Office 365发布
  • 微软将其企业/业务软件套件从盒装软件转变为基于订阅的软件，并提供在线选项
  • 这没有一个固定的日期；Office 365的正式发布似乎可以作为一个好的参考年份
• 像Azure一样，我个人不喜欢这些产品，但如果微软要拆分成主要业务部门，企业软件套件可能是唯一能在市值上与Azure匹敌的业务部门

当然也有很多重大的失误。从2010年到2015年，HoloLens是微软最大的赌注之一，仅次于Azure和必应，但到目前为止，任何人的大型AR或VR赌注都没有带来良好的回报。微软未能抓住移动市场。尽管Windows Phone总体上受到尝试过它的评论家的好评，但根据你问的对象，微软要么是太晚了，要么是不愿意长期补贴Windows Phone。尽管.NET至今仍在使用，但就市场份额而言，.NET和Silverlight没有达到早期的承诺，关键部分因内部政治斗争而受阻或被取消。必应，就声誉而言，是一个失败，而且，至少根据微软当时的选择，可能需要对谷歌采取反垄断行动才能成功，但这个失败仍然产生了一个价值数千亿美元的业务部门。尽管有所有这些失败，最大的赌注Azure可能价值万亿美元左右。

微软的企业销售部门是在鲍尔默担任CEO之前建立的（他曾担任销售与支持执行副总裁，实际上是以第一位业务经理的身份加入微软），并在鲍尔默担任CEO期间继续发展壮大。微软的销售策略如此有效，以至于当我在微软时，谷歌会向一些Office 365客户提供谷歌的企业套件（文档等）免费使用。微软销售人员指出，即使面对谷歌免费提供产品的情况，他们通常仍能完成微软付费产品的销售。对企业而言，微软产品及其企业销售团队的组合如此有效，以至于谷歌甚至无法免费送出自己的产品。

如果你正在阅读本文并且在一家“科技”公司工作，那么公司极有可能选择谷歌企业套件而非微软企业套件，微软销售人员的企业销售宣传对你来说可能听起来很荒谬。

我的一位经营初创公司的熟人，微软Azure的销售人员试图向他们推销Azure，开场白是“你们在用AWS，消费者云。你们需要Azure，企业云。”对大多数科技公司的人来说，企业意味着价格过高、不可靠、垃圾。就像很容易嘲笑鲍尔默是因为他来自销售和业务部门一样，当你听到企业销售宣传时也很容易嘲笑它，但总体而言，微软的企业销售部门做得很好。当我在Azure工作时，我调查了它是如何运作的，并且刚刚离开谷歌，这之间有着天壤之别。这是在2015年，纳德拉领导下，但让微软扩大规模的文化和流程是在鲍尔默领导下建立的。我认为有几个月，微软招聘和入职的销售人员比谷歌雇佣的总人数还要多，而且销售流程的每个阶段都相当有效。

微软在鲍尔默领导下的失误

当人们指出一长串失败，如必应、Zune、Windows Phone和HoloLens，作为鲍尔默是某种拖累微软的滑稽人物的证据时，这表明他们对科技行业缺乏理解。这就像指出一个风险投资公司资助的失败公司列表来证明该风投不知道自己在做什么。但在像风险投资这样的以成功为基础的行业里，这是愚蠢的。如果你想证明风投是糟糕的，你需要指出整体回报不佳或缺乏重大成功，这意味着整体回报不佳。同样，像微软这样的大公司有一个庞大的投资组合，一次成功的赌注可以弥补大量失败。鲍尔默的批评者无法指出整体回报不佳，因为微软在他任期内的整体回报非常好。收入从140亿或220亿美元增加到830亿美元，这取决于你是从1998年7月鲍尔默成为总裁时算起，还是从2000年1月他成为CEO时算起。公司离开时也相当盈利，前四个季度记录了270亿美元的利润，比他接手的公司的收入还要多。就市值而言，仅Azure一家就将跻身全球市值前十的上市公司，而减去Azure的企业软件套件可能刚好错过前十。

因此，批评者也无法指出在鲍尔默主持下创建Azure、将微软的企业软件从一套本地桌面应用转变为Office 365等、创建世界上最有效的企业销售组织、创建微软的游戏帝国（除了其他事情，鲍尔默在任CEO期间，微软收购了Bungie并于2001年推出时使Halo成为Xbox的旗舰游戏）等方面缺乏成功。即使是被广泛认为是失败的必应，根据最近报告的收入和当前的市盈率，也将是全球第12大最有价值的科技公司，介于腾讯和ASML之间。在攻击鲍尔默时，人们引用必应作为鲍尔默任期内发生的失败，这说明了鲍尔默成功的程度。大多数公司都希望自己的成功能像必应一样成功，更不用说他们的失败了。当然，如果鲍尔默有先见之明，他所有的赌注都成功了，让微软价值约10万亿美元，而不是今天区区3万亿美元的市值，那会更好，但对鲍尔默的批评——说他有一些失败和一些价值1万亿美元的成功——是他不是有史以来最伟大的CEO，差距巨大。确实如此，但算不上什么批评。

而且，与纳德拉不同，鲍尔默接手的不是一个容易取得成功的公司。正如我们之前提到的，鲍尔默上任不久，微软就被认为是一家无聊、无关紧要的公司，是下一个IBM，这主要是由于比尔·盖茨担任CEO时做出的决定。作为从早期就加入微软的资深员工，鲍尔默也对当时的微软状况负有部分责任，因此微软的问题至少部分归因于他（但这也意味着他应该因微软在90年代的成功而获得一些赞誉）。尽管如此，他很好地应对了微软最棘手的问题，并为继任者铺平了道路。

早些时候，我们注意到保罗·格雷厄姆将谷歌和互联网的兴起列为2007年之前微软死亡的两个原因。正如我们在探讨科技反垄断行动时讨论的那样，这两者都有一个共同的根本原因：针对微软的反垄断行动。如果我们查看微软反垄断案的文件，很明显微软知道互联网将有多重要，并计划控制互联网。作为这些计划的一部分，他们利用在桌面操作系统的垄断地位扼杀了网景。从技术上讲，他们因此输掉了一场反垄断案，但如果你看实际结果，微软基本上从法院得到了他们想要的。对微软的补救措施被广泛认为毫无用处（最初的决定涉及拆分微软，但他们能够通过上诉推翻这一决定），而且案件拖延了很长时间，以至于在案件裁决时网景已经注定失败，那些没有专门针对网景情况的补救措施毫无意义。

在计划中后来讨论但从未执行的部分是扼杀谷歌。如果我们根据微软有多“危险”、它打压竞争对手有多有效来评判微软，就像保罗·格雷厄姆判断微软已死那样，那么微软当然变得不那么危险了，但微软内部的感觉是，由于形势所迫，他们被迫这样做。扼杀谷歌计划的一部分是将地址栏中输入google.com的用户重定向到MSN搜索。这发生在Chrome出现之前，也发生在移动设备以任何形式出现之前。Windows桌面市场份额为97%，IE的市场份额在80%到95%之间（取决于年份），其余市场份额属于快速衰落的网景。如果微软采取这一行动，谷歌在能够推出Chrome和Android之前就被扼杀了，而且除非采取极端的反垄断行动（例如拆分微软），否则微软将永远拥有互联网。然后，作为甜点，没有理由不针对亚马逊。

经过内部辩论，微软决定不扼杀谷歌，不是出于对反垄断行动的恐惧，而是出于对随之而来的反垄断行动所带来的不良公关的恐惧。如果微软将流量从谷歌引开，对谷歌的影响将比他们针对网景的行动更快、更严重，而且在美国司法部赢得另一场针对微软的案件所需的时间内，谷歌将遭受与网景相同的命运。如果你不在那个时候，可能很难想象这一点，但美国司法部诉微软案是定期的头版新闻，这是我们自那以后再也没有见过的（部分原因是公司吸取了这方面的教训——谷歌据称通过游说扼杀了2011-2012年联邦贸易委员会针对他们的反垄断调查，并且巧妙地操纵了最近的案件，使其不像那样主导新闻周期）。自微软反垄断案媒体马戏团以来，我们见过的最接近的事情是Crowdstrike故障的媒体反应，但与美国司法部诉微软案相比，那只是一时的热门。

如果这里有对鲍尔默的批评，也许是微软没有在其年轻竞争对手从其大反垄断案中学到重要教训之前，主动吸取这些教训。一位足够有远见的高管本可以倡导进行大量游说，在反垄断案件发生之前阻止它，就像谷歌在2011-2012年所做的那样，或者操纵使反垄断案件只是另一个新闻故事，就像谷歌当前案件一直在做的那样。另一个可能的批评是，微软没有正确解读政治风向，并意识到在针对微软的大案之后至少二十年内不会出现严重的美国科技反垄断。原则上，如果鲍尔默拥有合适的团队专业知识，认识到美国将进入一个反垄断审查减少的二十年时期，他本可以推翻不扼杀谷歌的决定。

就批评而言，我认为前者是正确的，但除非你期望CEO是完美无缺的，否则这不是对鲍尔默的指控，因此作为鲍尔默是一个糟糕CEO的证据，这将是一个非常弱的批评。而且后一种批评是否正确也不明确。虽然谷歌能够逃脱诸如在Android中硬编码搜索引擎以防止用户更改搜索引擎设置和让恶意软件安装程序诱骗用户将Chrome设为默认浏览器之类的行为，而且他们被视为“好人”，没有因为这些行为受到太多审查，但微软并没有像谷歌那样受到媒体或公众的温柔对待。直到2011年，谷歌才引发严重的反垄断调查，因此2001年至2010年间缺乏严重的反垄断行动可能是微软为避免反垄断审查而谨慎行事的结果，而谷歌当时太小，无法引起审查，并且在仍然可能的情况下采取行动扼杀谷歌可能会引发严重的反垄断审查和另一场公关马戏。这是鲍尔默接手的公司比竞争对手处境更困难的一个方面——微软的手脚被束缚了，而且可能真的被束缚了。微软可以并确实因采取行动而受到严厉批评，而当谷歌采取完全相同的行动时却会受到赞扬。

当我在微软时，对此有很多不满。一个有趣的例子是，2011年，谷歌公开指责微软不道德行为，媒体抓住这个机会将其作为微软行为不端的又一个例子。我在微软与之交谈的一些人对此感到不安，因为据他们说，微软是在注意到谷歌也这样做后才想到这样做的，但声誉需要很长时间才能改变，而盖茨担任CEO期间采取的行动大大降低了微软的行动能力。

鲍尔默上任时面临的另一个困难是微软激烈的内部政治。同样，作为从几乎一开始就加入微软的资深员工，他对此负有部分责任，但鲍尔默设法清除了最糟糕的捣乱者，这样纳德拉就不会继承如此困难的局面。如果我们看看为什么微软在鲍尔默任期内没有主导互联网，除了担心扼杀谷歌会引起公关反弹外，内部政治斗争扼杀了微软大多数最有前景的网络产品，并降低了其余大多数网络产品的吸引力和影响力。例如，微软在1997年就拥有一个可以与谷歌文档竞争的产品，比谷歌成立早一年，比谷歌收购Writely早九年，但它因政治原因被扼杀了。微软当然不是唯一一家有内部政治斗争的公司，但它以比大多数公司更残酷的政治斗争而闻名。

虽然鲍尔默在清理门户方面做得并不完美，但当我在微软询问因内部政治斗争而被搁置或取消的有前景的项目时，最近最大的问题源头都在鲍尔默手下被扫地出门，为纳德拉留下了一个运作更正常的公司。

大局观

退一步看大局，鲍尔默接手的是一家财务状况良好但受困于内外部政治的公司，以至于外界观察者认为该公司极有可能滑向无关紧要，导致像格雷厄姆著名的“微软已死”的预测，预计收入将在五到十年内下降。回顾过去，我们可以看到盖茨采取的行动限制了微软利用其垄断力量直接扼杀竞争对手的能力，但没有一个转折点是实现奇迹般扭转的。相反，微软继续在企业产品上执行得非常出色，并继续对未来进行合理的押注，以成功地取代在内部被视为长期死胡同的收入来源，即使它们将是利润丰厚的死胡同，如Windows和盒装（非订阅）软件。

与大多数处于这种境地的公司不同，微软愿意非常大力地补贴一系列赌注，领导层认为这些赌注可能为公司提供未来几十年的动力，如Windows Phone、必应、Azure、Xbox和HoloLens。从对这些赌注的内外部评论来看，你可以看到为什么公司很难用其成功的业务线来补贴新业务线，即使成功业务的前景已经明朗。人们批评这些赌注是会扼杀公司的愚蠢举动，说公司应该集中精力在其最盈利的业务上，如Windows。即使有非常明确的数据显示逆势而行是正确的事情，人们通常不会这样做，部分原因是当它没有成功时你会看起来像个傻瓜，但鲍尔默愿意在面对数十年的嘲笑时做出正确的赌注。

公司难以进行这些赌注的另一个原因是，公司通常无法推出与其核心业务截然不同的新东西。当谷歌又一个非收购的消费者产品失败时，每个人都认为理所当然——当然谷歌在那里失败了，他们是一家技术优先的公司，不擅长产品。但微软多次实现了这种转变并取得了成功。一次是Xbox。如果你看看三大游戏主机制造商，两家是历史悠久的硬件公司，一家是微软，一家学会了如何制造硬件的盒装软件公司。另一次是Azure。如果你看看三大云服务提供商，两家是从成立之初就存在的在线服务公司，一家是微软，一家学会了如何进入在线服务业务的盒装软件公司。其他拥有与硬件和在线服务不同核心业务线的公司看到了这些机会并尝试转型，但失败了。

如果你看看这里的转型过程，嘲笑微软很容易，就像嘲笑微软的企业销售宣传一样。Azure的核心团队来自Windows，所以在Azure的非常早期，他们几乎没有事故管理流程，在他们的第一次重大全球宕机期间，人们在走廊里走来走去问“Azure宕机了吗？”试图弄清楚该怎么办。Azure将在多年内继续发生重大全球宕机，同时学习如何发布相对可靠的软件，但他们能够很好地解决问题，建立了一个价值万亿美元的业务。另一次，在Azure真正知道如何构建服务器之前，一位微软工程师打开了亚马逊的定价页面，注意到AWS的磁盘零售价比Azure配置磁盘的成本还要低。当我在微软时，Azure的一个大问题是数据中心建设速度不够快。人们开玩笑说最近招聘的大量销售人员效果太好，公司卖了太多的Azure，这可以说是事实，也是公司的真正紧急情况。在其他情况下，微软主要自己学习如何做，而在这种情况下，他们从亚马逊引进了一些非常资深的人员，他们在供应链和数据中心建设方面拥有深厚的专业知识。很容易说，当你遇到问题而竞争对手拥有正确的专业知识时，你应该聘请一些专家并听取他们的意见，但大多数公司在尝试这样做时都会失败。有时，公司没有意识到他们需要帮助，但更常见的是，他们引进了高级专业知识，但人们不听。很容易让一家公司的旧势力阻止引进高级外部专业知识的努力，尤其是在像微软这样充满纷争的公司，但领导层能够确保像这样的关键举措取得成功³。

当我和谷歌工程师谈论Azure崛起时的Azure时，他们通常对Azure评价不高，会嘲笑像上述这样的问题，这对于那些成长为大型在线服务公司、在运营大规模服务、构建高效硬件和建设数据中心方面拥有深厚专业知识的公司来说似乎很滑稽，但尽管在技术、运营和文化上起步于一个非常深的坑，微软用Azure建立了一个价值万亿美元的业务部门。

并非所有的赌注都成功了，但如果我们看看批评者的评论，他们说微软注定要失败，因为它在补贴错误的赌注，或者更年轻的公司会超越它，那么，今天，微软的市值比谷歌高50%，是Meta的两倍。如果我们看看科技行业的更广泛历史，微软从1975年成立到今天一直保持着持续强劲的执行力，这近五十年的历程可以说是科技行业无与伦比的。英特尔成立的时间更长，但在世纪之交左右经历了非常严重的挫折，而且在过去十年里遇到了很多问题。IBM有着悠久的历史，但在其早期历史中规模并不大，例如，当T.J.沃森将计算-制表-记录公司更名为国际商用机器公司时，其收入仍远低于每年1000万美元（按通货膨胀调整后，约为每年1亿美元）。计算机在50年代开始变得重要，IBM对于科技公司来说已经很大了，但在1969年针对IBM提起的反垄断案一直拖延到1982年才以“缺乏依据”被撤销，这阻碍了公司和文化的某些方面，例如，为什么IBM的各种云努力都失败了，在90年代，公司濒临死亡，仅因杰斯特纳的扭转才得以生存。如果我们看看更早的拥有长期持续强劲执行力的公司，大多数已经消失，如DEC和Data General，或者像IBM和苹果那样经历了几乎终结公司的严重挫折。有些公司拥有同样长期的强劲执行力，比如甲骨文，但这些公司在扩展业务线方面远不如微软有效，因此，甲骨文的价值可能相当于两个必应。这使甲骨文成为全球第20大最有价值的上市公司，这当然不错，但远不如微软。

如果微软遭遇重大挫折，像英伟达、Meta或谷歌这样更年轻的公司可能会超越微软的业绩，但这不是鲍尔默的错，我们仍然必须承认鲍尔默是一位非常有效的CEO，不仅在赚钱方面，而且在设定愿景方面，为微软未来五十年的成功奠定了基础。

附录：微软在鲍尔默领导下的相关性

除了上面提到的主要项目外，根据我的记忆，以下是格雷厄姆宣布微软已死后在鲍尔默领导下发生的一些有趣的事情：

• 2007年：微软发布LINQ，至今按照从业者实际使用的标准仍然相当不错
• 2011年：微软研究院的Sumit Gulwani发表“使用输入输出示例自动处理电子表格中的字符串处理”，十年后被评为最有影响力的POPL论文
  • 这篇论文是关于使用程序综合进行电子表格“自动补全/推断”的
  • 我不是专利的粉丝，但我猜测自动补全/推断在Excel中效果相当好而在谷歌文档中基本上不起作用的原因可能是微软拥有基于这项工作的专利
• 2012年：微软发布TypeScript
  • 这一定是本世纪发布的使用最广泛的编程语言，并且有理由成为有史以来使用最广泛的编程语言（只要你也不把TS的使用算作JS）
• 2012年：微软Surface发布
  • 自2022年帕诺斯·潘奈离开后，Surface系列的情况看起来不太好，即使在2022年这也可以被视为失败，但2022年这是一个年销售额70亿美元的业务线，这表明微软是多么庞大和成功——大多数公司都希望有一项业务能像一个失败的70亿美元/年业务那样成功
• 2015年：微软发布vscode（在鲍尔默2014年任期结束后，但这项工作源自鲍尔默任期内的多项工作）
  • 这似乎是当今程序员使用最广泛的编辑器，且优势巨大。当我几年前查看相关调查数据时，我对这一变化发生的速度感到震惊。vscode似乎达到了程序员编辑器主导地位的水平，这是前所未有的。最接近的可能是Visual Studio在保罗宣布微软已死前十年，但由于实际上是Windows专用软件并且成本相当高，从未达到同样的市场份额水平
  • Heath Borders指出，2011年聘请的Erich Gamma在这方面影响力巨大

对微软财务成功的另一个回应是，微软在财务上很成功，但对时尚的程序员来说无关紧要，就像IBM一样。首先，四舍五入到最接近的必应，IBM可能价值零或一个必应。但即使我们撇开财务方面，只看每个价值1万亿美元的科技公司（苹果、英伟达、微软、谷歌、亚马逊和Meta）对程序员的影响，英伟达、苹果和微软都有很多程序员由于某种生态系统的依赖而依赖该公司（CUDA；iOS；.NET和Windows，后者仍然是许多大领域（如3A游戏）的首选平台）。

你可能会为大云服务商辩护，但我认为公司对AWS的依赖并不像一家严肃的英语消费类应用公司真的需要iOS应用或一家3A游戏公司必须在Windows上发布并在Windows上进行开发那样几乎是强制性的。

如果我们看看那些没有被固定在生态系统中的程序员，微软由于创建了vscode和TypeScript等工具似乎与许多程序员高度相关。我不会说它一定比亚马逊更相关，因为许多程序员使用AWS，但很难争论在鲍尔默主持下创建（包括许多其他东西）vscode和TypeScript的公司对程序员来说是无关紧要的。

附录：我对微软的失败赌注

2015年加入微软后不久，我打赌德里克·丘会先达到1万亿美元市值。与大多数外部评论员不同，我同意微软所做的赌注，但当我看到微软当时的内部功能失调时，我认为这会给它们带来足够的问题，以至于谷歌会赢。这是错误的——微软先于谷歌达到1万亿美元市值，现在价值比谷歌高1万亿美元。

即使在一年后，我看到微软内部的情况以及微软销售的高效性和微软擅长发布企业产品的程度，并将此与谷歌的云执行和战略进行比较后，我认为我也不会打这个赌。但你可以说我犯了一个与外部评论员相当类似的错误，直到我详细了解了微软的运作方式。

感谢Laurence Tratt、Yossi Kreinin、Heath Borders、Justin Blank、Fabian Giesen、Justin Findlay、Matthew Thomas、Seshadri Mahalingam和Nam Nguyen的评论/修正/讨论

由 mimo-v2.5 模型翻译，花费 18898 tokens

大约八年前，我玩了一场《行话》游戏。当时的局势是，如果我们不能在自己的回合正确猜出所有剩余的词语，我们队几乎必输无疑。然而，根据给出的线索，我们无法做到这一点。虽然这本应是一个基于词语线索的猜词游戏，但一位队友提出，根据已选词语在棋盘上的物理布局，我们考虑的大多数可能性都会形成“太奇怪”的模式，我们应该根据位置来选择最后一个词。这招奏效了，我们赢了。

自那以后，我一直在想，如果一个人只做了记忆游戏中全部40张布局卡这一件事，他会有多厉害。为了模拟这一点，我们将构建一个仅使用位置信息来玩的游戏机器人（你可能也称之为AI，但鉴于我们将讨论使用大语言模型/AI来编写这个机器人，为了区分，我们将使用“机器人”来指代这个自动玩《行话》的代理）。

当时，在我们那个幸运的猜测之后，我们查看了布局卡，确认了队友基于形状进行猜测的想法是正确的——他基于可能的物理布局正确判断出了概率最高的猜测。每张布局卡定义了哪些词语属于你的队伍，哪些属于对方队伍，并且为了限制成本，游戏只附带了40张卡（考虑旋转有160种配置）。我们的队友并没有记住这些卡（那样就能将可能性缩小到唯一的配置），但他玩了足够多的游戏，对常见和不常见的模式/簇群形成了直觉，使他能够对游戏发起这种侧信道攻击。例如，玩多了之后你可能会发现，没有哪张卡会让一个队在一行或一列拥有5个词，或者只有先手颜色的队伍才有4个连在一起的词，而且如果这种情况发生在边缘并且是蓝色的，那么第5个词一定属于红队；或者没有配置能让蓝色词语有6个相连（但红队有，一种是两连的旁边有四连的）。即使你没有有意识地使用这些信息，你也可能会对某些感觉“太奇怪”的模式产生潜意识的回避。

回到构建模拟某人花了几天记忆那40张卡的机器人这个想法，下面是一个你可以与之对战的简单机器人，它模拟了一个由这类玩家组成的队伍。通常玩游戏时，你需要提供线索，队伍去猜词语。但是，为了给你——人类玩家——最大的优势，我们将给你一个不切实际的巨大优势：假设你可以随时生成一个能让你队伍选择你想要的确切方块的线索，这通过让你点击任何你希望队伍猜测的方块来模拟。

默认情况下，你每回合还有三次猜测机会，这会让你远超我见过的99%分位的《行话》玩家。虽然好的玩家每回合通常能猜对三个或更多，但每回合平均猜对三个且零失误在大多数群体中都异常出色。你可以打开显示剩余匹配布局的功能，但如果你想模拟一个没有记住所有布局的人类玩家的体验，你可能想尝试在关闭显示的情况下玩几局。

如果在任何时候，你结束一个回合轮到机器人时，只有一种可能的布局匹配，机器人就能正确猜出它的所有词语并获胜。如果机器人能在猜出所有词语之前就开始猜测（无论是朴素地猜还是策略性地缩小搜索空间），或者即使有一个简单的启发式方法（比如当它推断出你下一回合就能赢时，就在可能的布局中随机猜一个），那么它会强大得多。但即使使用最朴素的“记忆布局”机器人，它也已经能击败我交给它的每个《行话》玩家（只要他们没有打开显示剩余匹配布局并使用机器人所能访问的相同知识）。

这个非常“傻”的机器人，只有在能猜出所有词时才开始猜，它比大多数《行话》玩家强得多¹。实际上，任何队伍里只要有一个人决定坐下来记住盒子里那40张初始状态卡的内容，他们基本上就能在每一局游戏中击败另一队。

现在我对这个问题的好奇心得到了满足，我认为这只是一个小问题，对游戏本身并非真正的困扰。因为猜词游戏通常并不需要被认真对待，而且大多数游戏如果被认真对待，或者人们玩得很多且不是想破坏游戏的话，最终都会变得有些漏洞。相对于其他猜词游戏，特别是流行的那些，《行话》在玩家开始使用侧信道攻击（无论是有意识还是无意识的）之前，具有更高的可重玩性。

那些词语集合有限的游戏（比如《One Word》或《禁忌词》）会发生什么情况呢？人们往往在玩过几局后，就会无意中记住那些“棘手”词语和词语联想。《行话》通过要求人们记忆组合数量庞大的词语联想（而不仅仅是线性数量的词语联想）来缓解这个问题。我们刚才讨论了这个问题，它出现在我们玩《行话》大约二十局之后，并且即使人们没有意识到棋盘形状在影响他们的游戏，它也可能在潜意识层面发生。但与其他猜词游戏出现的问题相比，这相对微妙。而且，如果真有人在意这个问题，他们可以使用数字随机发生器来设置棋盘，尽管我个人从未在一个对游戏认真到会在意这点的群体中玩过《行话》。

感谢Josh Bleecher Snyder、David Turner、Won Chun、Laurence Tratt、Heath Borders、Spencer Griffin、Ian Henderson和Yossi Kreinin的评论/修正/讨论。

附录：为本文编写代码

我尝试使用了两个不同的AI助手来为本文编写代码：Storytell和Cursor。我没有像程序员那样使用它们，而是更像一个非程序员那样用它们来编写程序。总的来说，我发现AI助手在某些任务上表现得惊人地好，而在其他任务上则差得可笑。这里也是如此。

我基本上就是让它们写代码，然后运行看看是否有效，接着告诉助手哪里出错了，让它重写代码，直到代码看起来基本能用。即使以这种非常朴素的方式使用助手——我刻意不去理解代码，只追求得到可用的输出——我认为获得可运行代码所花的时间并不比完全凭自己手写整个程序多太多。我猜大概多花了两倍时间，但程序员的估算出了名的不准确，也可能实际花费的时间差不多。我对代码正确性的信心远不如我自己写的代码那样足，但我仍然觉得这相当令人印象深刻：你只需要给这些AI助手下提示，就能得到基本可用的代码，所用时间并不比程序员写代码多太多。这些工具当然比雇佣程序员便宜得多，而且如果你像程序员而不是一个朴素的提示者那样使用它们，你会更快地得到可用结果，因为你只需修正那些大部分正确的版本中的错误，而不是花大部分时间调整你的提示，以让AI消除一个对任何程序员来说都微不足道的调试错误。

我见过很多程序员谈论“AI”将永远无法取代程序员，理由是“要详细地指定程序以达到你想要的效果，你就是在编程”。如果用户必须在程序运行前正确地指定其工作方式，这将是一个相当有力的批评。但当用户可以像我们这里这样迭代时，这个批评就弱得多了。用户不需要是程序员就能观察到输出不正确，然后可以要求AI修正输出，重复这个过程直到输出看起来足够正确。一个软件的性能或正确性约束越严格，这种朴素的迭代方法效果就越差。幸运的是，对于想使用大语言模型生成代码的人来说，当今大多数生产环境中的软件在性能和正确性方面的约束都相当宽松。人们基本上已经接受了软件有大量漏洞是常态，任何一周内遇到成百上千个软件缺陷都是正常的，而且广泛使用的软件通常比高度优化的版本慢10万倍。

一个稍近的类比是关于AI是否能在客服岗位取代人类的争论。即使这已经在发生，人们也声称这永远不可能，因为AI会犯人类不会犯的低级错误。但正如我们之前指出的，人类也经常犯同样的错误。此外，即使AI客服差很多，只要性价比足够好，很多公司还是会选择更差但更便宜的选项。科技公司在消费级客服方面因臭名昭著地这样做而闻名，但我们通常看到所有类型的公司都这样做，例如，当你拨打任何大公司甚至很多本地小企业的客服电话时，你很可能会被推入电话树或某种糟糕的自动语音识别系统。这些通常比最低薪的员工差很多，但成本却比让一个最低薪的员工接听每个电话并将你转接到正确的部门低好几个数量级，所以公司选择了电话树。

相关的问题不是“AI何时能让外行创造出比程序员更好的软件？”，而是“AI何时能让外行创造出像电话树和糟糕的语音识别对于客服那样好的软件？”而且，实际上，软件甚至不需要那么好，因为程序员比最低薪的客服人员更贵，但你可以每月花20美元使用这些工具。我不知道AI何时能取代一个称职的程序员，但如果最低标准是达到自动电话树系统在路由我电话方面的编程水平，我认为我们很快就能达到（如果还没达到的话）。而且，像客服一样，这不必是零和游戏。从电话树省下来的钱并非全部变成利润——一部分被用来雇佣处理其他任务的客服人员。

顺便提一下，我觉得我的经历中有点好笑的一点是，我尝试的两个平台（Storytell和Cursor）经常生成可以自动检查的错误结果，而在我指出结果不正确后，它们就会修复。以下是与其中一个平台的典型交互序列：

• 我：请做X
• AI：[生成一些TypeScript代码和测试，但未能通过类型检查]
• 我：这段代码没通过类型检查，你能修复吗？
• AI：[生成一些代码和测试，但测试执行失败]
• 我：运行测试时出现[复制粘贴测试失败信息]的错误
• AI：[生成一些代码和测试，测试通过了，并且在一些基本的额外测试上似乎也能工作]

另一个有趣的交互是我陷入了一个循环，有几个不同的错误，让AI修复一个错误会重新引入其他错误，即使我明确要求AI不要重新引入这些错误。与那些日复一日使用这类工具的人相比，我的经验非常少（我只是偶尔摆弄一下，看看它们进展如何），我预计有更多提示经验的人能更好地指定提示来更快地跳出这种循环。

但即便如此，如果这些环境中有一个能实际执行代码的执行环境，体验会更好，这样它们就能自动修复这类可修复的问题，并且当朴素的重新提示（“那错了并导致了XYZ，请修复”）不起作用时，它们能知道输出已知是错误的。

我问了Josh Bleecher Snyder（他对这个领域的了解远胜于我，无论是技术层面还是产品层面），为什么这些工具中没有一个具备这样的环境，而且几乎没有任何公司使用这样的环境进行训练或微调。他的回答是，这个领域的几乎每个人都相信了《苦涩的教训》，没有在研究这类平凡的改进。其理念是，建立这样环境所需的枯燥工程工作将被某种根本性的进步所淘汰，所以花时间做这些只能带来渐进收益的事情是浪费时间。Sam Altman甚至建议那些依赖OpenAI API的公司创始人假设会有巨大进步，并据此构建公司，因为不这样做的公司会被即将出现的巨幅进步所淘汰。从与该领域创始人和风险投资家的讨论来看，几乎每个人都把这个放在心上了。

我已经有11年没有做过任何严肃的机器学习相关工作了，所以我的观点和任何其他外行一样不值钱。但如果在GPT-3时代有人对这样一个平凡的系统做了逆向投资，现在看来它当时会很有用，对于今天的模型也同样有用，无论是用于训练/微调工作还是为用户生成更好的输出。但我猜相关的问题是：今天尝试构建这样一个平凡的系统（对于该领域的人来说，这是对进步的逆向投资）是否有意义？大型AI实验室据说雇佣了很多低薪的海外承包商来标注数据，但如果你想标注编程示例，每标注一个，一个能产生标准正确结果的环境会比雇人尝试标注更便宜，除非你只需要极少量的标签。在万亿美元甚至500亿美元公司的层面上，作为投资组合的一部分来做这个押注似乎是合理的。如果我想创业并押注，那这样做有意义吗？也许如果你把所有鸡蛋放在一个篮子里，答案不那么明显，但即使如此，也许有充分的理由，因为几乎整个领域都在押注别的东西。如果逆向的一方是正确的，竞争就很少，这有点类似于我们之前关于逆向招聘的讨论。

附录：游戏精神与为赢而玩

就个人而言，当我在游戏中遇到侧信道攻击，或者一个如果认真玩就完全崩坏的游戏（如《Perfect Words》）时，我认为尽量避免“攻击”游戏是合理的。我认为这在《行话》中是某种程度上不可能的，因为人们会形成潜意识的联想（我注意到有人在第一回合就猜一个额外的词只是为了好玩，而且成功率很高——假设他们没有作弊，我相信他们没有作弊，这种成功率强烈暗示了他们使用了某种侧信道信息。这不一定是来自卡片的位置信息，可能像下意识注意到间谍主管在专注地看什么那样简单。

Dave Sirlin称任何不利用任何合法可能性去赢的人都是傻瓜（他贬低地称这类人为“菜鸟”）（他说你应该使用作弊来赢，比如在第一人称射击游戏中使用地图黑客，只要锦标赛组织者没有禁止这种做法，而且锦标赛应该明确列出禁止的内容，避免笼统的“不要做坏事”规则）。我认为人们应该以他们觉得有趣的方式玩游戏，并找到喜欢同样游戏方式的群体。如果Dave觉得记住任意信息来赢得所有这些游戏很有趣，他应该这样做。我（用Dave Sirlin的话说）玩得像个“菜鸟”的原因是，对于这里讨论的游戏，如果认真玩，游戏通常严重崩坏，而我个人不觉得它们崩坏的方式有什么乐趣。在某些情况下，比如《Perfect Words》，游戏轻而易举地就崩坏了，我觉得赢得一个轻而易举崩坏的游戏很无聊。在其他情况下，比如《行话》，游戏可以通过花几个小时记忆一些任意信息来破坏。对我来说，花几个小时记忆40种可能的《行话》布局卡，看起来是一种既无趣又无生产力的时间浪费，使其成为一个完全毫无意义的活动。

附录：你可能喜欢的词语游戏

如果你喜欢猜词游戏，以下是一些同类游戏的推荐，类似于编程书籍推荐列表和编程博客推荐列表，目的是指出人们倾向于喜欢或不喜欢的事物的属性（不同于大多数评论，它们倾向于评价某物是“好”还是“坏”）。为了限制列表长度，这里只包含猜词游戏（通常关于词语的含义），不包括那些关于操作词语机制的游戏，例如《Banagrams》、《Scrabble》或《Anagrams》，也不包括那些关于视觉表现与词语映射的游戏，例如《Dixit》或《行话：图画版》。

同样由于篇幅原因，我不会讨论那些适用于列表中所有或几乎所有游戏的、人们不喜欢游戏的原因。例如，有人可能因为是词语游戏而不喜欢某个游戏，但为每个游戏都指出这点意义不大。同样，许多人根据“重量”选择游戏，并因为觉得它们“轻”而非“重”而不喜欢几乎所有的词语游戏，但所有这些游戏都被认为相当轻量，所以讨论这一点没有意义（但如果你想要一款轻量且紧张的词语游戏，在下面的列表中，你可以考虑《Montage》或《Decrypto》；在未详细讨论的游戏中，《Scrabble》或《Anagrams》是不错的选择，后者是我玩过的最残酷的词语游戏，而且遥遥领先）。

《禁忌词》（Taboo）

一款猜词游戏，你需要快速给出线索，让队友猜出你拥有的词语，每个词语都附有5个你在提示时不允许说的禁用词。

一款有趣、轻松的游戏，有两个问题降低了其可重玩性：

• 因为每个被提示的词语都是完全独立的，一旦你的游戏小组把卡组玩过一两遍，每个人都认识每个词，游戏就变得极其简单；在我第一次玩这个游戏的小组里，我觉得玩了两遍后就发生了这种情况。
• 甚至在那之前，当人们意识到可以通过稍微绕弯子描述来轻松提示任何词语时，游戏就变得相当机械，甚至还没等到因为玩得太多而无意中记住词语。

当人们不喜欢这个游戏时，他们通常不喜欢这种快速连发游戏中巨大的时间压力。

《One Word》（Just One）

一款类似于《禁忌词》的猜词游戏，你需要让队伍猜出一个词，但不同的是，对于每个你想提示的词，没有固定的禁用词列表，禁用词由你的队伍动态生成（每个人提示一个词，任何被给出超过一次的线索都会被划掉）。

禁用词是通过与队友互动生成的，这使得这款游戏比《禁忌词》有高得多的可重玩性。然而，有限的词表最终还是会遇到同样的问题，在玩了大约20-40局后，我的游戏小组就能认出这些词，并且几乎每个词都有一个好的提示方法。

按照规则，这款游戏真的是为5人以上设计的，如果只有4人玩会变得非常容易，但没有理由你们不能在4人时按5人游戏的规则玩。

一个常见的抱怨是，考虑到游戏成本（建议零售价30美元 vs 《行话》的20美元），游戏的实体组件质量廉价且低劣。另一个抱怨是词语难度差异很大，有些似乎是偶然的。例如，单词“grotto”被包含在内，而且如果有人没见过这个词，就相当难提示，这似乎是因为游戏是在法语中开发的，在那里提示grotto相当直接。

Perfect Words(亚马逊链接)

一款猜词游戏，队伍合作构建线索，目标是从每组线索中让整个队伍就一个词（可以是任何词，只要大家同意）达成一致。

核心游戏——试图想出一组能生成代表哪个词共识的词语——作为与《One Word》这类相反游戏的补充很不错，但实际执行的规则似乎有严重缺陷。就好像游戏设计师不玩游戏，也没有让玩游戏的人来测试它。这个游戏在第一或第二次玩时就相当容易破坏，你必须故意玩坏游戏的“机制”部分才能让它变得有趣。

《Montage》

一款2对2的词语游戏（如果你想要更多玩家，也可以像《行话》那样玩）。每队中，玩家在固定的时间段内轮流给出线索和猜词。当前棋盘状态对某些位置必须出现的字母有一定约束。提示者需要生成一个能让猜词者猜出符合约束的己方词语的线索，但线索不能太明显，因为如果对方的两个人都在提示者的搭档之前猜出了这个词，对方就赢得了这个词。

这可能是这个列表中难度最高的游戏？我见过的大多数新玩家在第一次尝试时，都未能在自己回合内给出有效的线索（一个好玩家如果搭档能比对手更快理解思路，每回合可能至少成功提示5样东西）。这也可能是这个列表中最奖励拥有大词汇量的游戏。它是列表中唯一一个运用字母构成知识（像《Scrabble》）有用的游戏。

只要你不与固定的搭档一起玩并依赖“秘密”协议或共享知识，这种直接对抗的猜测性质赋予了这款游戏非常高的可重玩性，至少与列表中其他任何游戏一样高。

像《Perfect Words》一样，如果你喜欢那种类型，核心词语游戏是有趣的，但围绕核心游戏设计的游戏规则似乎没有经过很好的思考，很容易被利用。这里没有《Perfect Words》那么糟，但你仍然需要避免试图获胜才能让这款游戏真正好玩。

当我不喜欢这款游戏时，通常是因为他们觉得游戏太难，或者不喜欢输——微小的技能差异会导致比列表中其他游戏更大的结果差异，所以新玩家应该预料到会输得很惨，除非他们的对手故意让步（规则中没有内置）或者他们从玩其他游戏中获得了词语游戏的能力。我自己不玩很多词语游戏，尤其不玩《Scrabble》或《Anagrams》这类“严肃”词语游戏，所以我玩这款游戏时通常被虐得很惨，这对我来说正是魅力所在，但这恰恰是很多人不喜欢这款游戏的原因。

Word Blur

一款猜词游戏，约束条件是需要用撒在你面前桌子上的900个小词语方块来组成线索。

我只玩过几次，因为我不知道附近谁能弄到一份，但它看起来至少和这个列表中的任何游戏一样有可重玩性。这款游戏的最大缺点是它已绝版十多年，而且出了名的难弄到，尽管制作一个仿制品似乎并不太难。

当人们不喜欢这款游戏时，似乎通常是因为他们不喜欢游戏的核心玩法——看着一堆词语方块并用它们来描述，有些人觉得这让人应接不暇。

觉得Word Blur太复杂的人可以尝试仿品Word Slam，它更容易上手也更容易弄到（因为它不像前者那样是邪典热门，尽管它似乎也绝版了）。Word Slam只有105个词，而且词语是分类的，感觉没那么混乱。

《行话》（Codenames）

除了文章中已经提到的内容，没什么可补充的，除了人们不喜欢这款游戏的常见原因。

一个大声说话的人可以在每队中主导游戏，程度超过这个列表中的任何其他游戏（除了《行话：双人版》）。虽然游戏附带计时器，但很少使用（规则基本上暗示你不应该使用计时器），所以另一个常见的抱怨是，当和行动缓慢的人一起玩时，游戏会无限期拖延下去，而且除非你是间谍主管，在对方回合时没什么有用的事可做，导致游戏有长时间的无聊停顿。

《行话：双人版》（Codenames: Duet）

虽然这款游戏设计为《行话》的双人合作版本，但我只在超过两人（通常是4-5人）的情况下玩过，只要你不介意讨论必须以半秘密的方式进行，这效果也很好。

在可重玩性方面，《行话：双人版》与《行话》大致处于相同领域，优缺点也差不多。

《Decrypto》

我不打算描述这个游戏，因为我见过的每次直接解释玩法的尝试，在新玩家玩一两轮之前都未能让他们理解。但概念上，每队轮流转换谁给出线索，目标是让你队的人正确猜出哪个线索映射到哪个词，同时让对方队伍猜测失败。猜测的队伍有额外信息，因为他们知道词语是什么，所以更容易生成正确的映射。然而，猜测队伍生成的映射集合对“解密”队是可见的，所以他们可能知道谜语词是用“林肯”和“帽商”提示的，从而推断出这个词是“帽子”，让他们能在下一个线索时正确猜出映射。

我还没玩够这款游戏，无法判断它的可重玩性有多高。有可能非常高，也有可能人们会找出技巧，让“解密”队几乎不可能猜出映射。我看到的一个主要缺点是，当与随机玩家群体一起玩时，游戏经常由哪队有最弱玩家决定（我每次看随机群体玩都发生了这种情况），这与很多团队和合作游戏中最强玩家主导游戏的问题相反。好玩家很难做出制胜动作，但坏玩家很容易做出致败动作，所以与非专家玩家一起玩时，哪队有最差玩家，哪队就会输。

Person Do Thing

David Turner说：

Person Do Thing就像《禁忌词》，但不是禁用词列表，而是一个允许词列表。四十个基本词总是允许的，并且（如果你想）每个秘密词有三个额外的允许词。像《禁忌词》一样，出题者可以回应猜测——但只能使用允许的词。因为只允许使用很少的词，这需要大量创造力来给出好的线索……值得玩几次，但我上次查看时他们的词表很小。

我猜如果一群经常玩的人可能会发展出一些约定，例如“像人但不是想大的”来指“动物”。我听说过在《Concept》游戏中发生过这种情况：一个小组有约定，红、白、蓝和地方指的是拥有这些国旗颜色的国家，额外的修饰词则指定具体是哪个：水代表英国，冷代表俄罗斯，食物代表法国，枪代表美国。我认为需要相当多的这类约定才能让游戏明显变简单。

《Semantle》

像Wordle，但关于词语的含义，基于word2vec算法。最初设计为单人游戏，也适合合作游戏。

虽然我确信有人喜欢一遍又一遍地玩这个游戏，但对大多数人来说（我认识的人里几乎没人玩超过40局），我觉得可重玩性相当低。玩了一会儿并想出如何通过猜词快速缩小搜索范围后，玩游戏开始感觉有点机械。

我交谈过的大多数不喜欢这个游戏的人，是因为他们无法建立起关于正在发生什么的心智模型，使得词语相似度分数看起来像随机的胡言乱语。

由 mimo-v2.5 模型翻译，花费 15357 tokens

2011-2012年间，美国联邦贸易委员会（FTC）曾调查是否对谷歌提起反垄断诉讼。FTC最终决定终止调查，此后十年间，公众对调查细节知之甚少。直到Politico公布了调查期间312页的内部备忘录，人们才得以窥见内情。作为一名科技行业从业者，在阅读这些备忘录时，最令人震惊的是主张终止调查的一方如何反复显示出对科技行业基本认知的缺乏，而高层管理人员的备忘录中对此毫无察觉。

如果你通常不关注监管机构和立法者对科技行业的言论，阅读这些决策形成过程的内部备忘录（或任何其他行业）会令人震惊，因为显然，这些决策是在对相关行业几乎毫无了解的情况下做出的。

FTC内部，竞争局（BC）主张应提起反垄断诉讼，而经济局（BE）则主张终止调查。BC的论点相当有力。理性的人可能对证据是否足以支持提起诉讼持不同意见，但一个反垄断的理性人士必须承认BC备忘录中的反垄断指控至少是站得住脚的。而BE的反对方论点则站不住脚。BE备忘录的核心部分存在重大错误。为了让BE备忘录显得可信，读者必须对科技行业存在巨大且显著的认知空白。如果FTC内部曾就BE备忘录中的错误进行过讨论，公开文件中没有任何迹象表明这一点。根据现有证据，似乎无人注意到BE备忘录的错误。来自主任及其他高层的公开备忘录显示，他们给予BE备忘录的重视程度至少与BC备忘录相当，这表明FTC领导层（至少在其备忘录被公开的人员中）对科技行业存在认知差距。

简要概述

由于BE备忘录实际上是对BC备忘录的反驳，我们将从BC备忘录中的论点开始。以下要点总结了BC备忘录执行摘要中的要点，大致概括了BC的论点：

• 谷歌是占主导地位的搜索引擎和搜索广告销售商
• 本备忘录讨论了五个领域中的四个反竞争行为；移动领域在补充备忘录中
• 谷歌在美国的横向搜索、搜索广告、联合搜索和搜索广告领域拥有垄断力量
• 关于谷歌是否非法优待自身内容而贬低竞争对手的问题，我们不建议FTC继续追诉；这是一个艰难的抉择，且判例法不利于反竞争的产品设计，谷歌的效率理由充分，且对用户有一定益处
• 关于谷歌是否非法抓取垂直竞争对手的内容以改进其自身垂直产品，建议依据《谢尔曼法》第2条将其认定为有条件的拒绝交易
  • 先前的自愿交易是互惠互利的
  • 威胁将竞争对手内容从通用搜索中移除，旨在胁迫竞争对手允许谷歌将其内容用于谷歌的垂直产品
  • 自然且可预见的效果是削弱垂直网站的研发积极性
• 关于限制广告活动自动跨平台管理的反竞争合同条款，建议依据第2条予以谴责
  • 这些条款限制了广告主利用自身数据的能力，减少了创新，并增加了广告主和第三方企业的交易成本
  • 同时也降低了谷歌在搜索和搜索广告领域竞争对手的质量
  • 谷歌的效率理由看似是托词
• 关于与网站签订的反竞争排他性联合搜索和搜索广告协议，建议依据第2条对谷歌予以谴责
  • 对发布商的反竞争影响虽有限，但剥夺了竞争对手的规模优势，对主要竞争对手（必应）具有竞争意义，并且长期构成重大进入壁垒
  • 谷歌的效率理由总体上缺乏说服力
• 可能的补救措施
  • 抓取行为
    • 可要求谷歌允许选择退出其垂直属性中的摘要（评论、评分），同时保留网页搜索或主搜索结果页面上的通用搜索摘要
    • 可要求谷歌限制使用从网页搜索结果中索引的内容
  • 广告活动管理限制
    • 可要求谷歌从许可协议中删除有问题的合同条款
  • 排他性联合协议
    • 可禁止谷歌与搜索联合合作伙伴签订排他性搜索协议，并要求放宽联合合作伙伴使用竞争对手搜索广告的限制
• 案件存在一些风险，摘要中未提及，例如谷歌可以辩称微软最高效的分发渠道是bing.com，且微软可能获得的任何规模增长对其竞争地位影响不大
• [BC] 工作人员认为谷歌的行为已经并将继续对消费者以及在线搜索和广告领域的创新造成实际损害。

在关于移动的补充备忘录中，BC工作人员认为谷歌通过独家协议主导了移动搜索，且当时移动搜索增长迅速。BC工作人员声称，根据谷歌内部文件，2011年移动搜索占搜索总量的比例从9.5%增长到17.3%，并且谷歌和微软的内部文件都表明，预计移动搜索将在不久的将来超过桌面搜索。与桌面搜索的案例一样，BC工作人员使用谷歌单方面降低收入分成的能力作为其拥有垄断力量并能主导条款的证据，并引用了谷歌领导层对此的明确说法。

BC工作人员承认谷歌的许多行为对消费者有益，但权衡了反竞争策略的危害，表示：

证据描绘了一家公司的复杂形象：一方面致力于通过提供最佳用户体验来维持其市场份额的整体目标，同时又从事损害众多垂直竞争对手的策略，这可能帮助巩固了谷歌在搜索和搜索广告领域的垄断力量。

BE工作人员强烈不同意BC工作人员的观点。BE工作人员也认为谷歌的许多行为对消费者有益，但在涉及危害时，几乎在每种情况下，BE工作人员都辩称市场不重要、不是一个独立的市场，或者市场是竞争性的，谷歌的行为是促进竞争而非反竞争。

常见错误

至少在Politico提供的文件中，BE工作人员通常回避直接回应BC工作人员的论点和数据。例如，除了辩称谷歌的协议和独家性（就协议是排他性而言）是促进竞争的，并且阻止此类协议可能对市场产生重大负面影响外，他们还认为移动市场很小且不重要。BE备忘录认为移动市场仅占市场的8%，并且，虽然增长迅速，但不重要，因为它只占“总查询量的很小一部分，搜索广告收入的比例更小”。他们还声称移动市场存在激烈竞争，因为除了苹果，还有黑莓和Windows Mobile。从FTC调查开始到备忘录撰写期间，黑莓的市场份额从约14%下降到约6%，这是长期下降趋势的一部分，且无改变迹象。Windows Mobile的下降幅度较小，从约6%降至约4%，但在一个具有强大网络效应的市场中，BE工作人员为何认为这些市场份额低且下降的平台将在未来提供激烈的竞争，这令人费解。

当BE备忘录的作者做出预测时，他们似乎有一种预测与事实相反的结果的天赋。为了做到这一点，BE备忘录的作者采取了与当时普遍共识相反的立场。另一个例子是，他们暗示搜索市场存在激烈竞争，并且预计在不采取反垄断行动的情况下这种竞争将持续。他们对此的证据是雅虎和必应在美国拥有合计“稳定”的30%市场份额，且自雅虎-必应联盟宣布以来，查询量增长速度快于谷歌。BE备忘录的作者甚至更进一步，声称微软的查询量增长速度快于谷歌，并且微软+雅虎按搜索MAU（月活跃用户）计算的总市场份额高于谷歌。

BE备忘录关于雅虎和必应提供激烈且稳定竞争的论点忽略了运行搜索引擎的固定成本如此之高，以及实现盈利所需的规模如此之大，以至于雅虎实际上退出了搜索领域，将搜索外包给必应。微软每年补贴必应20亿美元，这是一项在大多数科技界观察人士看来不会成功的战略举措。当时，人们有理由认为，如果微软停止大力补贴必应，其市场份额将大幅下降，而事实正是如此——在反垄断行动未被采取后，微软决定将资金转移到其他回报率更高的项目。如今的估算显示，谷歌在美国的市场份额为86%至90%，全球范围的估算通常更高一些。

关于一些更夸张的说法，例如微软和雅虎的活跃搜索用户总和超过谷歌，以及微软查询量（因此搜索市场份额）增长快于谷歌，他们使用的是comScore的数据。关于这一点有几个奇怪之处。

首先，作者挑选数据以呈现最大化微软市场份额的数字。当comScore数据显示微软市场份额相对较低时（如在联合搜索中），BE备忘录的作者解释说不应使用comScore数据，因为它不准确。然而，当comScore数据表面上不切实际且显示微软市场份额大得不合常理或增长速度快得不合常理时，BE备忘录的作者却依赖这些数据，而不解释为何依赖这个他们声称不可靠的来源。

使用这些数据，BE备忘录基本上认为，因为许多用户偶尔使用雅虎和必应，用户显然可以使用雅虎和必应，并且即使用户每月使用一次雅虎或必应而使用谷歌一千次，转换壁垒也不显著。根据与从事驱动增长的产品改进工作的人员共事和交谈的经验，压倒性的共识是，将轻度参与、作为MAU勉强注册的用户转化为定期使用产品的重度参与用户通常非常困难，这通常被认为比将全新用户转化为重度参与用户更难。就像Boies关于rangeCheck的论点一样，很容易看出这种推理对不懂技术的外行人来说似乎合理，但该论点读起来像是外行人会写的东西。

尽管BE工作人员备忘录读起来像是对BC工作人员备忘录要点的反驳，但缺乏对事实和论点的直接交锋，意味着只读其中一份备忘录的读者会与读另一份的读者产生截然不同的印象。例如，在移动搜索的重要性方面，天真地只读BC备忘录的读者会认为移动搜索非常重要，可能是最重要的，而天真地只读BE备忘录的读者则会认为移动搜索不重要，并且在可预见的未来将继续不重要。

Politico还公布了两位主任的备忘录，他们权衡了BC和BE工作人员的论点。两位主任都更倾向于BE备忘录而非BC备忘录，一位非常倾向，另一位较为倾向。在出现分歧时，例如移动搜索在近期的重要性，所提供的备忘录中没有任何证据表明曾尝试确定谁是正确的，或者我们正在讨论的错误是否被注意到。处理这些分歧最接近的情况是一些评论，赞扬双方工作人员完成了出色的工作，以一种可以说是“公平公正”的方式，例如“BC和BE工作人员在这项复杂的调查中表现出色。各自局的备忘录清楚地表明，在这四个方面提起诉讼的理由是接近的……”。如果可以推断的话，似乎BE备忘录中的推理和事实至少得到了与BC备忘录同等甚至更多的重视，尽管BE备忘录的大部分论据对了解科技行业的人来说显得极不可信。

例如，在移动搜索的重要性方面，我恰好在这些备忘录撰写后不久在谷歌工作，当时在谷歌，他们已经转向“移动优先”策略，因为大家都明白移动将成为未来最重要的市场。当时其他大型科技公司也理解这一点，而且理解的时间比这些备忘录的日期还要早。许多消费者当时并不理解这一点，那些为了统一桌面和移动体验而牺牲桌面体验的设计改版是当时常见的投诉。但如果你查看相关数据或与大公司的人交谈，就会清楚，从商业角度来看，专注于移动并处理因此可能在桌面端引发的后果是有意义的，只要这能提高移动开发的速度。

BC和BE工作人员备忘录都广泛引用了对许多科技公司的访谈，包括所有“超大规模企业”。奇怪的是，有人可以获得所有这些公司的内部文件以及访谈记录，然后还能论证移动在当时并不重要。而且，根据我们目前从这些备忘录中所能了解的情况，主任们表面上接受双方的论点，然后认为BE工作人员的论点与BC工作人员的论点同样具有说服力或更具说服力，这也令人费解。

这是我们在BC和BE工作人员备忘录之间反复看到的一类错误，即为了论证一个知情观察者明显看出不实的情况而过度拉伸数据。在大多数情况下，是BE工作人员尽可能地拉伸数据，将站不住脚的立场尽可能地推进，但也有一些BC工作人员论证过于牵强的实例。

我们在BE备忘录中反复看到的另一类错误，是基于一个大多数业内人士都会认为明显错误的世界模型，然后在此基础上进行推论。一个例子是讨论垂直竞争对手如Yelp和TripAdvisor是否因BC工作人员所称的反竞争行为而受到或将受到显著损害。BE工作人员除了辩称谷歌的行为实际上是促进竞争而非反竞争外，还辩称谷歌不可能对垂直竞争对手造成重大损害，因为谷歌为其带来的流量很小，仅占其总流量的10%至20%，甚至说“谷歌对本地网站的流量影响非常小且不具统计显著性”。尽管BE工作人员没有详细说明他们对此业务运作的模型，但他们似乎相信市场基本上是静态的。如果谷歌将Yelp从其列表中移除（如果谷歌不被允许将Yelp的数据整合到其自身的垂直产品中，谷歌曾威胁要这样做），或者降低Yelp的排名以优先考虑谷歌自己的结果，从长远来看，最多只会使Yelp的流量减少10%至20%，因为只有10%至20%的流量来自谷歌。

但即使是风投或产品经理实习生也应理解市场并非静态。如果谷歌能够持续地从Yelp那里夺走相当一部分搜索流量并将其导向谷歌的本地服务，人们预期从长远来看，Yelp最终用户将所剩无几，沦为曾经的空壳。这正是发生的事情，截至撰写本文时，Yelp的估值为20亿美元，尽管其市盈率为24倍，对科技公司来说相当低。但市盈率低不足为奇，因为人们普遍认为Yelp无法扭转局面，原因是谷歌在搜索以及地图领域的主导地位使其非常难以获得或留住用户。这不仅事后看来显而易见，而且在当时就被充分理解了。事实上，我与一位在谷歌工作的前同事交谈，他正在开发一些利用谷歌拥有而Yelp永远无法合理获得的地位的本地功能；这些功能的预期结果是扼杀Yelp的业务。不仅人们知道这将发生，而且知道Yelp不太可能进行反击，因为谷歌能够利用其从搜索和地图获得的市场力量。奇怪的是，当时有人会认真辩称，在切断Yelp新用户来源的同时，又向几乎所有现有用户提供一个已集成到他们使用的应用或网站中的替代方案，不会显著影响Yelp的业务，但BE备忘录却提出了这个论点。有人可能会认为这里使用的策略类似于微软反垄断案中提到的策略，当时据称微软高管表示他们要“切断Netscape的空气供应”，但BE备忘录辩称“切断空气供应”的影响“非常小且不具统计显著性”（毕竟，一个典型的身体拥有足够结合1升氧气的血容量，远高于一次正常呼吸吸入的氧气量）。

另一类即使不算错误，也是论证薄弱的情况，是依赖鸡尾酒会级别的推理，而当时有数据或其他有力证据可以直接应用。这种情况贯穿BE备忘录，尽管在其他时候，当BC备忘录提出一些看似合理的推理时，BE备忘录的反驳是我们不应接受此类推理，需要看数据而不是抽象推理。BE备忘录严重依赖一个概念，即我们必须依赖数据而非推理，并将BC备忘录中未植根于严格数据的论点称为“传闻”、“超出推测”等，但BE备忘录只在知识或推理可能导致结论存在某种竞争壁垒的情况下这样做。当数据表明谷歌的行为在市场中制造了某种壁垒时，BE备忘录的作者忽略了所有相关数据，反而依赖推理而非数据，即使推理薄弱，具有我们之前提到的Boies论点的特征。有人可能会辩称，提起反垄断案件的证据标准应该比不提起的标准更严格，但如果这里观察到的不对称是基于这个原因，BE备忘录本可以在证据不足的领域列出，并在面对更强证据时不做出自己的薄弱主张。一个例子是讨论移动默认设置的影响。

BE备忘录辩称默认设置基本上毫无价值，影响微乎其微或没有影响，多次表示用户只需“轻点几下”即可切换，补充说这只需“几秒钟”，因此“[这些是]微不足道的转换成本”。关于默认设置影响最明显、最直接的证据是谷歌为维持其默认地位所支付的金额。在2023年的一起反垄断诉讼中，透露谷歌在2021年向苹果支付了263亿美元以维持其默认地位。截至撰写本文时，苹果的市盈率为29.53。如果我们认为这笔付款是边际利润，并且默认地位如BE备忘录所言毫无价值，那么对苹果来说，这笔钱在其2.9万亿美元市值中所占的价值大约为7760亿美元。或者，从谷歌的角度看，谷歌的市盈率为27.49，因此谷歌愿意让其2.17万亿美元市值中的约7220亿美元蒸发。谷歌愿意为获得全球约25%至30%手机的默认搜索地位支付这笔钱。这个计算过于简单化，但没有任何合理的调整能让人相信默认地位的价值如BE备忘录所声称的那样微不足道。作为参考，一家市值7760亿美元的科技公司将是美国上市公司中第7大最有价值的科技公司，也是第8大最有价值的美国上市公司（落后于Meta/脸书和伯克希尔哈撒韦，但领先于礼来）。另一个参考是YouTube在2021年的广告收入为288亿美元。如果用户的实际转换成本微不足道且默认设置不重要，那么为了维持默认地位而花费相当于YouTube广告收入的利润就很难说得通。如果我们寻找更接近2012年的公开数据，2013年TechCrunch报道称谷歌每年向苹果支付10亿美元以获得搜索地位，后来的一起诉讼显示谷歌在2014年为默认搜索地位向苹果支付了10亿美元。这距离这些备忘录撰写时间不远，每年10亿美元仍是一笔不小的数目，这与BE备忘录声称移动搜索不重要且默认设置因用户转换成本微不足道而不重要的说法相矛盾。

有趣的是，鉴于BE备忘录如此强调不信任看似合理的推理，必须依靠实证数据，但BE工作人员似乎没有尝试查明谷歌为维持默认地位支付了多少。一位同意BE工作人员观点的主任的备忘录建议应该核查这个数字，但没有证据表明进行了核查，且FTC调查不久后就被终止了。根据FTC获取的内部文件数量，FTC不太可能无法从苹果或谷歌那里获得这个数字。但即使这个数字无法获得，表面上默认设置不重要且实际转换成本低的说法也不合理。如果FTC工作人员访谈了以产品为导向的工程师或产品经理，或了解科技行业的产品历史，那么为了提出这个论点，BE工作人员必须忽略或避免查明谷歌为维持默认地位支付了多少钱，不与专注于产品的工程师、产品经理或领导层交谈，并且还要避免了解科技行业。

有人可能会辩称，虽然默认设置影响力大，但公司能够克服非默认地位，这可能导致关于默认设置究竟有多强大的辩论。例如，人们可能会争论当谷歌Chrome成为主导浏览器时默认设置的影响，并辩论其中多少归因于Chrome仅仅是比IE、Opera和Firefox更好的浏览器，多少归因于微软的失误而谷歌在搜索领域不太可能重犯，多少归因于通过捆绑恶意软件安装程序诱骗人们将Chrome设为默认，以及多少归因于通过google.com施压人们将Chrome设为默认。这是一个有趣的讨论，一个了解行业的理性人士可以持任何一方观点，不像默认设置基本上毫无价值且实际用户转换成本微不足道的论点，即使没有关于谷歌向苹果和其他人支付多少以维持默认地位的数据，这个论点也不合理。而且根据2020年司法部对谷歌的诉讼，大约一半的谷歌搜索是通过谷歌付费的默认搜索进行的。

另一个反复出现的错误（与上述错误密切相关）是引用营销声明、新闻稿或其他普遍被认为是夸张的言论，并像对待有意义的事实陈述一样依赖它们。例如，BE备忘录指出：

微软的公开声明与向反垄断监管机构的声明不一致。微软首席执行官史蒂夫·鲍尔默在宣布与雅虎搜索合作的新闻稿中表示：“与雅虎的这项协议将为我们提供所需的规模，以更快地推进相关性和实用性。微软和雅虎知道搜索领域还有更多可能。这项协议为我们提供了规模和资源，以创造搜索的未来”

这是伴随收购或合作的典型营销废话。因为这种毫无意义的声明在许多行业都很常见，人们期望监管者，即使是对科技一无所知的监管者，也能将其视为营销手段，而不是给予与严肃证据同等或更多的重视。

一些有趣的细节

在涵盖了备忘录中观察到的主要错误类别后，我们将看看备忘录中的一些细节。

在2011年6月3日批准强制程序到2012年8月8日BC备忘录发布之间，工作人员收到了950万页、200万份文件，并表示他们审阅了“其中数千份文件”，因此工作人员只能审阅其中很小一部分。

在FTC调查之前，有一些相关的诉讼，全部被驳回，其中一些理由如果被作为广泛先例，会使任何诉讼难以成功。在SearchKing诉谷歌案中，原告指控谷歌不公平地降低了其搜索结果排名，但法院裁定谷歌的排名是受宪法保护的意见，即使是恶意操纵排名也不会使谷歌承担法律责任。在Kinderstart诉谷歌案中，裁决的一部分是谷歌搜索对于垂直提供商（如Yelp、eBay和Expedia）并非必要设施。由于这些备忘录最终涉及法律程序，自然有大量关于Verizon诉Trinko案和Aspen Skiing Co.诉Aspen Highlands Skiing Corp案及其影响的讨论。

截至BC备忘录撰写时，谷歌380亿美元收入中96%来自广告，主要来自搜索广告。BC备忘录认为，除社交媒体广告外，其他形式的广告增长潜力有限。从事后来看，这当然是错误的。例如，视频广告是一个重要的市场。YouTube的广告收入在2021年达到288亿美元（略高于谷歌为维持默认搜索地位向苹果支付的费用），Twitch据称又产生了20-30亿美元的视频收入，而且相当一部分视频广告收入是直接从赞助商流向主播，不经过YouTube和Twitch，例如Twitch上第137大的主播被提供每年1000万美元的报酬，每天在线赌博直播30分钟，他声称他认识的第42大主播从在线赌博赞助商那里每月获得1000万美元。这不仅仅是事后才明显——即使在当时，也有强烈迹象表明视频将成为主要的广告市场。碰巧的是，这些迹象同样表明谷歌很可能主导视频广告市场，但这里的具体论点仍被夸大了。

总的来说，BC备忘录似乎夸大了搜索广告预期的首要地位，以及搜索广告市场的独特性，声称其他在线广告支出在任何意义上都不构成替代品，甚至可能是互补品。尽管有人可能合理地辩称搜索广告是一个有点独特的市场，且一旦你将大量广告支出移出搜索，替代弹性就很低，但BC备忘录提出此主张的程度有些牵强。搜索广告和其他广告预算互补而非替代的观点，与我与业内人士交谈中关于广告支出实际如何分配的看法大相径庭。也许有人会辩称，考虑到Person诉Google案，加州北区联邦地区法院法官Fogel批评原告的市场定义，认为没有依据将“搜索广告市场”与更大的互联网广告市场区分开来，这预示着任何未来诉讼中都会提出的异议，因此在这里提出有力的论点是有意义的。然而，作为一个只想了解当前事实真相和论点真实性的人，这里的论点似乎值得怀疑。

对于谷歌的集成产品，如本地搜索和产品搜索（前身为Froogle），BC备忘录声称，如果谷歌像对待其他网站一样对待自己的属性，这些产品将不会被排名，谷歌人为地将自身的垂直竞争对手置于有机结果之上。网络垃圾团队拒绝将Froogle结果纳入，因为这些结果正是谷歌从索引中移除的那种垃圾内容，表示“[我们的]算法专门寻找此类页面以降级或从索引中移除”。网络搜索产品经理Bill Brougher说“通常我们喜欢在索引中拥有目标页面，而不是聚合页面。因此，如果我们本地页面是指向其他页面的链接列表，那么我们索引中拥有其他页面更为重要”。在网络垃圾团队被否决、结果被插入后，广告团队抱怨说，点击量较低（暗示质量较低）的结果将导致每年损失1.54亿美元。对此的回应基本上包含了与BC备忘录关于规模重要性以及谷歌剥夺竞争对手规模的行为为何代价高昂的论点相同的内容：

我们面临激烈竞争，必须快速行动。拒绝“一个框”会阻碍以下方面的进展：排名：失去点击数据损害排名；触发：失去点击率和google.com查询分发数据影响触发准确性；全面性：失去流量损害商户增长，因此损害全面性；商户合作：失去流量减少了商户在报价数据、税费和运费方面的投入；公关：关闭一个框降低了谷歌在商业领域的可信度；用户认知：在google.com上失去与购物相关的UI降低了用户对谷歌购物功能的认知

通常，CTR被用作对结果进行排名的重要信号，但这会导致谷歌自身垂直属性的排名较低，因此“谷歌使用竞争垂直网站的存在来自动提升其自身垂直属性的排名，使其高于竞争对手”——如果一个比较购物网站是相关的，谷歌会将谷歌产品搜索插入在任何竞争对手之上；如果像Yelp或CitySearch这样的本地搜索网站是相关的，谷歌会自动在SERP顶部返回谷歌本地。

此外，为了查看谷歌本地结果的内容，谷歌抓取了Yelp的内容并将其整合到谷歌场所中。当Yelp发现这种情况时，他们提出了异议，谷歌威胁要将Yelp从传统的谷歌搜索结果中禁止，并进一步威胁要禁止任何不允许其内容在谷歌场所中使用的垂直提供商。Marissa Mayer作证说，从技术角度来看，在不从传统有机搜索结果中移除Yelp的情况下，很难将Yelp从谷歌场所中移除。但当Yelp发送停止侵权函时，谷歌能够立即移除Yelp结果，这似乎表明其难度低于所声称的。谷歌随后声称在技术上不可行在不从SERP上的“本地合并”界面移除Yelp的情况下将其从谷歌场所中移除。BC工作人员认为这一说法也是错误的，Marissa Mayer后来在听证会上承认这一说法是错误的，并且谷歌担心允许网站在保留在“本地合并”中的同时选择退出谷歌场所可能带来的后果。亚马逊的结果和产品搜索也有一个非常相似的故事。如上所述，BE备忘录对所有这些的反驳论点是谷歌流量“非常小且不具统计显著性”。

BC备忘录声称上述活动既减少了Yelp、CitySearch、Amazon等公司在该领域投资的激励，也减少了新公司在此领域成立的激励。这似乎是真的。除了BC备忘录中提出的证据（超越了上述总结的内容），如果你只是在FTC调查期间与寻找创意的创始人或风投交谈，人们已经开始真正远离创办和资助像Yelp这样的公司，因为人们明白谷歌可以通过切断其空气供应严重损害这个领域的任何类似公司。

我们将BC备忘录附录中关于AdWords API限制的讨论推迟到附录，这些限制明确禁止广告活动程序化移植到其他平台（如必应）。但其中有一个有趣的细节，即谷歌显然意识到了此事的法律敏感性，因此会议记录和内部文件异常不完整。在一次会议中，BC工作人员能找到的最具信息量的书面记录是产品经理总监Richard Holden给广告高级副总裁Susan Wojicki的一条信息，内容是“我们没有做记录，原因显而易见，这就是为什么我不在电子邮件中详细说明的原因，但很乐意更口头地向你简要介绍”。

我们还将BC备忘录关于谷歌排他性和限制性联合协议的详细讨论推迟到附录，除了几个有趣的片段。一个是谷歌声称他们不知道其标准在线服务协议中的条款和条件。特别是，条款和条件包含一个“首选位置”条款，许多当事方认为这是事实上的独家协议。当FTC工作人员就这一条款询问谷歌搜索服务副总裁时，副总裁声称不知道此条款。之后，谷歌致信FTC的Barbara Blank，解释说他们正在从在线协议条款和条件中删除首选位置条款。

另一个有趣的片段涉及谷歌的市场力量及其如何让他们为自己获取越来越大的收入份额，并减少合作伙伴获得的收入份额。只有少数受此影响的谷歌客户对此表示担忧。那些表示担忧的是最大和最老练的一些客户（如亚马逊和IAC）；他们担心谷歌的限制性和排他性条款会增加谷歌对必应/微软的主导地位，并允许谷歌向客户提出更苛刻的条款。即使谷歌正在执行系统性策略以减少给客户的收入份额（这只有由于其市场主导地位才可能实现），大多数客户似乎要么不理解谷歌在此领域市场力量的长期影响，要么不理解互联网的重要性。

例如，百思买不觉得这值得担忧，因为百思买将他们的网站和网络视为客户进入商店前获取售前信息的方式；沃尔玛也不觉得这值得担忧，因为他们将网络视为实体店零售的延伸。似乎是同样的对互联网重要性的误解，导致沃尔玛和百思买在此表示不担忧，也导致这些零售商（过去地位远强于亚马逊）在在线和整体利润方面远远落后于亚马逊。沃尔玛后来意识到了这个错误，于2016年以33亿美元收购了Jet.com，并且（相对于其他零售商）认真资助了程序员在沃尔玛内部进行真正的技术工作。自从沃尔玛开始重视互联网以来，其在线业务取得了实质性复苏，自2018年以来在线净销售额平均复合年增长率达30%，但在面对亚马逊在线存在构成威胁后花了二十年时间才做出认真回应，这让沃尔玛在经过近十年的认真投入后仍然稳固地落后于亚马逊的在线零售，而百思买在三十年后仍然未能对亚马逊做出有效回应。

BE备忘录使用大多数客户不担忧作为谷歌在这里规定的独家和限制性条款不是问题的证据，但从事后来看，很明显，是客户对在线业务影响缺乏理解才导致他们对此不担忧。当BE备忘录将那些理解这里影响的客户称为“老练”时，这是相对于那些领导层倾向于不理解互联网的行业的人而言的。虽然这些客户相对于花了二十年才认真应对亚马逊威胁的零售商来说是老练的，但如果你当时只是与科技行业的人交谈，你不需要找到特别老练的人就能找到理解正在发生什么的人。人们普遍理解零售收入，更重要的是零售利润将转移到线上，你必须找到一个极其不合群的人才能找到一个对此没有大致理解的人。

BC和BE备忘录都有很长的关于搜索和规模的讨论。在这个话题上，BE备忘录似乎是错误的，而BC备忘录的含义，即使不微妙，至少也不明显。让我们从BE备忘录开始，因为它更容易讨论，尽管我们将非常简要地讨论BC备忘录中的论点，以便为BE备忘录中的讨论设定框架。BC备忘录中论点的大致框架是，在多个市场（搜索、广告）中，规模对产品质量有重大影响。谷歌自己的文件承认了这种“良性循环”，即拥有更多用户可以提供更好的广告，从而获得更好的广告收入；同样在搜索中，更大的规模带来更多的数据，可用于改进结果，从而带来用户增长。特别是在搜索领域，BC备忘录声称用户点击数据非常重要，更多的数据可以带来更好的结果。

BE备忘录声称事实并非如此。关于点击数据的重要性，BE备忘录提出了两个主要反对意见。首先，这与“通用搜索市场的历史相悖”；其次，“这也与证据相悖，这些证据表明，网络爬虫和网络索引的质量、搜索算法的质量以及搜索结果中包含的内容类型[至少同样重要或更重要]。”

对于第一个论点，BE备忘录用一个大致为“谷歌过去比现在小，当时的点击数据就足够了，因此变得像谷歌过去那么大意味着你有足够的点击数据”的案例来阐述。撇开对科技行业的了解不谈，这似乎是一个奇怪的推理思路。“我们现在生产的产品价格与竞争对手相同，但质量只有其三分之一，但这应该没问题，因为我们的竞争对手过去在市场不成熟、没有人生产更好产品时也生产过质量只有其三分之一的产品”通常不是一种制胜策略。这在市场份额和产品质量之间存在良性循环的市场中尤其如此，比如搜索领域。

第二个论点即使在不了解科技行业的情况下也显得奇怪，因为它是一个经典的谬误论证。这类似于说“BC备忘录声称汽车有右前轮很重要，但这与证据表明汽车有左前轮和右后轮至少同样重要相悖”。如果你了解科技，特别是搜索，这个论点就更不可信了。指出搜索算法的质量是不同的感觉不太对，因为规模和点击数据直接为算法开发提供信息（BE备忘录对此有相当多的讨论——BC备忘录的作者肯定可以获取相同的信息，从他们的写作来看，似乎也了解了这个论点）。作为一个从事搜索索引工作的人，虽然我很想同意BE备忘录的说法，认为索引与排名同等重要或更重要，但我必须承认索引是一个比排名更简单、更不重要的问题，同样爬虫 vs. 排名也是如此。这在当时是普遍理解的，因此，考虑到FTC工作人员进行了大量访谈，BE备忘录的作者也应该知道这一点。此外，考虑到BE备忘录所指的“通用搜索市场的历史”，即使不与工程师交谈，这一点也应该是显而易见的。

例如，Cuil以建立比谷歌更大的索引而闻名。虽然这不是一项微不足道的成就，但在当时，相当多的人拥有专业知识，如果资金充足用于严肃的基础设施创业，就能建立一个在原始大小或你更喜欢的其他索引指标上与谷歌索引相匹敌的索引。Cuil和其他专注于索引的尝试失败了，因为没有好的搜索排名，拥有大索引价值很小。虽然从技术上讲，拥有好的排名但索引差也价值很小，但我们在实践中并没有真正看到这种情况，因为排名是更难的问题，一家有能力构建好的搜索排名器的公司自然会拥有足够好的索引和足够好的爬虫。

至于BC备忘录的论点，我不知道其含义应该是什么。BC备忘录正确地指出，规模的增加极大地提高了搜索质量，必应从雅虎获得的额外数据大大提高了搜索质量和点击率，预计进一步增加的规模将继续带来高回报，创建谷歌竞争对手的成本很高（据说必应当时每年亏损20亿美元，并且每年花费45亿美元“开发其算法和构建运营必应所需的物理能力”），并且谷歌采取了可能被视为反竞争的行为，使得必应在与谷歌不采取这些行动的假设世界相比处于不利地位，并且他们对广告提出了类似的论点。然而，尽管BC备忘录陈述的论点有其强度，BE备忘录陈述的论点有其不准确性，BE备忘录的论点在精神上是正确的，即微软本可以采取一些行动来更有效地参与搜索竞争，但并没有这样做，有人可能会辩称FTC不应该介入帮助一家公司摆脱无效竞争。

就个人而言，我认为冗长讨论BC备忘录立场与BE备忘录立场没有太大意义，因为BE备忘录采取的立场似乎极其薄弱。称其为稻草人策略并不公平，因为这是一个真实的立场，并且在FTC中胜出，但采取行动与否的决定似乎更多是基于哲学而非备忘录中的论点。但我们可以讨论还可以做些什么。

可能发生什么

在FTC拒绝提起反垄断诉讼之后，发生的是微软实际上将必应作为严肃赌注的资金撤回，将本可用于继续资助与谷歌进行一场非常昂贵斗争的资源，转移到其认为投资回报率更高的其他项目上。微软追求的大赌注是Azure、Office和HoloLens（以及可以说是Xbox）。HoloLens是一个不切实际的赌注，但Azure和Office是微软可以利用其在相关市场的主导地位来打压竞争对手的业务线，而不是打一场竞争对手可以利用其在相关市场的主导地位来打压他们的逆风仗，从而获得更高的每美元投资回报率。作为一个在必应工作过并且认为如果得到持续、非盈利性的大量投资，必应有潜力与谷歌真正竞争的人，我觉得这令人失望但也可能是正确的商业决策。如果你看任何一个特定的子市场，比如Teams vs. Slack，微软的产品不需要比竞争对手好很多就能占领市场，这与搜索领域的情况相反，在搜索领域，谷歌打压竞争对手的能力意味着必应必须比谷歌好得多才能达到市场份额的均等。

根据他们的公开声明，拜登的司法部反垄断助理总检察长乔纳森·坎特（Jonathan Kanter）会主张在这种情况下提起反垄断诉讼，拜登的FTC委员兼主席莉娜·汗（Lina Khan）也会如此。在被任命为FTC委员兼主席之前，莉娜·汗最出名的是写了《亚马逊的反垄断悖论》，该文既有影响力也有争议。奥巴马任命的官员更经常同意BE备忘录中的推理类型，会反对反垄断行动，我们讨论的调查就是在他们任期内终止的。更广泛地说，他们反对坎特和汗所驱动的理念。奥巴马的FTC委员任命者，乔治梅森大学经济学家兼法律学者乔什·赖特，实际上写了一篇题为《对一个悖论的安魂曲：时尚反垄断的可疑崛起与必然衰落》的反驳文章，对汗的立场进行了严厉批评。

如果在2012年，FTC和司法部由拜登任命者而非奥巴马任命者领导，会有什么不同？我们只能推测，但一种可能性是他们会采取行动然后败诉，就像最近针对Meta和微软的案件一样，这些案件在奥巴马的FTC和司法部任期内似乎不会发生。在拜登任命者领导下，对现行法律——《谢尔曼法》、《克莱顿法》、《FTC法》、《罗宾逊-帕特曼法》以及“较小的”反垄断法——的运用要活跃得多，但法院的意见在拜登任期内并未改变，这导致了一系列科技领域不成功的反垄断案件。BE和BC备忘录都用了大量篇幅讨论某种推理路线是否会在法庭上站得住脚。拜登的任命者比以往的任命者更不关心这一点，司法部和FTC的多人都公开表示“我们有责任执行法律”之类的话，意思是当他们看到由民选官员制定的反垄断法律被违反时，即使法院可能不同意该法律，他们的工作也是追诉这些违法行为。

另一种可能性是会有一些行动，但行动将与我们看到的大多数公司处罚一致。比如一笔小额罚款，其成本相对于公司从其行为中获得的边际利润微不足道，或者某种同意令（基本上是停止与终止令），要求公司停止特定行为，同时保持其市场份额，保持其主要想获得的东西——在网络效应主导的市场中的巨大优势。也许会再开几次“我们没有做记录，原因显而易见”的会议来规避新的限制，一切照旧。考虑到FTC备忘录中的具体指控以及当时法院的态度，我的猜测是，如果FTC继续进行反垄断调查而不是终止，最可能的结果是第二种情况的某种形式，即某种名义上的胜利，在实践中几乎毫无影响。考虑到这些案件的审理需要多长时间，微软几乎肯定在任何决定做出之前就已经缩减了对必应的投资，并将必应从试图增长的补贴赌注转变为它希望保持的盈利业务。其他国家提起的一些案件，其补救措施与我们预期的如果FTC调查继续进行可能的结果一致。关于谷歌利用移动领域的市场力量在其希望的几乎所有Android手机上推广软件，欧盟名义上成功了，但实际影响微乎其微。经济政策研究中心的Cristina Caffara将其描述为：

欧洲未能推动实地变革。为什么？因为我们告诉他们，别再这么做了，坏狗狗，别再这么做了。但事实上，他们都去了，说着“好的，好的”，然后从后门跑出去又做了一遍，因为他们比监管者聪明，对吧？事情就是这样。

所以，在捆绑案中，在Android上，问题是不要再捆绑，于是他们说“好的，我们不捆绑了”。现在我们有了一个新系统。如果你想要Google Play商店，你付100美元。但如果你想在每个入口点放置搜索，你可以获得100美元的折扣……补救措施失败了，其他人都说“哦，这是一个好方法，非常聪明”

另一对相关案件是Yandex在俄罗斯关于移动搜索默认设置的诉讼，以及后来的欧盟同意令。2015年，Yandex在俄罗斯就Android上的移动默认地位提起诉讼，通过添加一个“选择屏幕”来解决，让用户选择搜索引擎而不偏向任何默认选项。这立即导致Yandex开始在谷歌那里获得市场份额，最终Yandex在俄罗斯的市场份额超过了谷歌。2018年，欧盟在欧洲要求了类似的选择屏幕，这并没有产生太大影响，除了在捷克共和国可能有点影响。俄罗斯的情况和欧盟的情况有一些差异。一个可以说是最重要的差异是，当Yandex在俄罗斯起诉谷歌时，Yandex仍然具有相当的竞争力，市场份额在30%多。在2018年欧盟决定时，必应是在欧洲排名第二的搜索引擎，市场份额约为3.6%。当一个搜索引擎完全主导市场时，给消费者提供选择可能影响甚微。BE备忘录强烈依赖的一个论点是，如果我们以任何方式干预，可能会在以后产生不良影响，所以我们应该非常小心，可能什么也不做，以防万一。但在这些赢家通吃、具有强大网络效应的市场中，你可以廉价干预的窗口期相对较小。也许（这是高度推测性的），如果FTC在2012年要求选择屏幕，必应会继续投入足够的资金至少维持其相对于谷歌的市场份额。

对于垂直领域，在购物方面，欧盟在2017年要求谷歌改变其展示结果的方式。这似乎几乎没有影响，既可能因为晚了5-10年，也可能因为即使在十年前实施也是微不足道的改变。2017年的裁决源于2010年启动的案件，在采取行动的7年里，谷歌成功地在竞争中击败了其垂直竞争对手，使其最多仅勉强相关。

另一个我们可以参考的地方是微软反垄断案。那是一个很长的故事，至少和本文档一样长，但简要总结一下，1990年，FTC开始调查微软涉嫌反竞争行为。继续调查的投票最终以2-2平局告终，导致调查终止。司法部随后进行了自己的调查，导致了一份普遍认为不太有效的同意令。然后是1998年司法部关于微软在浏览器市场使用垄断权力的诉讼，最初导致了拆分微软的决定。但在上诉中，拆分被推翻，导致了2002年的和解。1998年案件的一个主要组成部分是关于浏览器捆绑和微软对Netscape的攻击。到案件和解时（2002年），Netscape实际上已经死亡。和解中与互操作性相关的部分当时被普遍认为无效，不仅因为Netscape已死，而且因为它们不会普遍有用。一些经济学家持与BE备忘录相同的观点，即当时不应进行干预，任何干预都是危险的，可能阻碍创新。诺贝尔奖得主米尔顿·弗里德曼写了一篇题为《商业界自杀冲动》的Cato政策论坛文章，预测呼吁对微软采取反垄断行动的科技公司是在自杀，并且已经达到了一个关键门槛，这将导致硅谷的官僚化：

当我开始进入这个行业时，作为竞争的支持者，我是反垄断法的坚定拥护者；我认为执行这些法律是政府为促进更多竞争可以做的少数几件可取的事情之一。但当我观察实际发生的情况时，我看到，反垄断法非但没有促进竞争，反而倾向于做完全相反的事情，因为它们像许多政府活动一样，倾向于被它们本应监管和控制的人接管。因此，随着时间的推移，我逐渐得出结论，反垄断法弊大于利，如果我们没有这些法律，我们会过得更好，如果我们可以摆脱它们。但我们确实有它们。

在这种情况下，鉴于我们确实有反垄断法，硅谷将政府引向微软真的符合自身利益吗？……你们会后悔呼唤政府的那一天。从现在起，计算机行业一直非常幸运，相对不受政府干预，但将经历政府监管的持续增加。反垄断很快就会变成监管。这再次似乎是一个说明商业界自杀冲动的案例。

从事后来看，我们看到事实并非如此，甚至恰恰相反。关于试图对微软提起反垄断行动将不可避免地导致政府干预增加的观点，我们看到了相反的情况，即长达二十年的相对宽松监管和反垄断活动时期。在对创新的影响方面，尽管对微软的诉讼太少太晚，无法拯救Netscape，但谷歌的成功似乎与反垄断案有因果关系。在谷歌早期，当谷歌没有市场力量而微软实际上控制着人们访问互联网的方式时，微软内部曾讨论过旨在杀死谷歌的提案。其中一个提案是将试图访问谷歌的用户重定向到必应（当时称为MSN搜索，当然这是在Chrome存在之前，IE主导浏览器市场）。另一个想法是发布一个巨大的警告，警告用户谷歌是危险的，就像今天的浏览器中的恶意软件警告一样。当时微软的律师Gene Burrus表示，微软选择不尝试阻止用户访问google.com，是因为担心在经历了近十年的严格反垄断审查后，会引发进一步的反垄断行动。接受访谈的谷歌和微软人员都相信，如果微软那样做了，他们会杀死谷歌，因此，从事后来看，我们可以看到米尔顿·弗里德曼关于微软反垄断调查影响的看法是错误的，并且可以认为，正是因为这些反垄断调查，谷歌和脸书等Web 1.0公司才能够生存下来，更不用说繁荣发展了。

另一种可能性是采取了重大反垄断行动，取得了成功，并且成功得足够及时以产生影响。也许，补救措施本身不足以改变必应与谷歌的格局，但如果找到并实施了一个合理的补救措施，它仍然可能及时地使Yelp和其他垂直网站保持重要地位，甚至可能刺激更多垂直领域的初创公司。在一个由与拜登任命者理念相同的人领导FTC和司法部的假设世界里，我们可能还会看到针对微软在其可以利用相邻市场主导地位的市场提起反垄断行动，使必应成为持续大量投资更具吸引力的领域。也许这将导致必应与谷歌竞争，而上述“老练客户”如亚马逊和IAC的担忧可能不会成为现实。通过对微软和其他可以利用其主导地位打压竞争对手的大公司提起反垄断诉讼，也许Slack仍然是一个独立产品，我们会在企业工具领域看到更多初创公司（一些评论者认为Slack基本上是被迫被收购，因为面对微软在相关市场的主导地位，竞争太困难了）。Slack继续存在和创新只是小事——更大的假设影响将是所有那些因为担心像微软这样的庞然大物会用捆绑产品摧毁他们的独立产品而不敢尝试的新初创公司和产品。如果你把所有这些，如果不是最佳情况，至少是非常好的情况下的反垄断倡导者的结果加起来，有人可能会争辩说消费者和企业会过得更好。但现实地说，很难看出这种非常好的情况组合如何能够实现。

回到FTC备忘录，如果我们考虑需要采取什么反垄断行动才能真正促进竞争，这似乎极其困难。一些更直接、听起来更可信的解决方案由于政治原因、法律先例，或者像我们引用的Boies论点或BE备忘录中一些明显不正确但似乎对非常重要的人来说有说服力的论点而被排除在外。

对于似乎可行的解决方案，权衡它们造成的危害并非易事。例如，假设FTC在2012年强制实施移动和桌面选择屏幕。这会在相当短的时间内杀死Mozilla，除非Mozilla完全改变其商业模式，因为Mozilla基本上依靠从谷歌获得的默认地位付款生存。我们从Opera看到，即使你有一个卓越的浏览器，引入了其他浏览器后来复制的功能，性能比其他浏览器更好等等，当你面对免费浏览器时，你也无法真正竞争。因此我们很快将只剩下IE/Edge和Chrome。在浏览器引擎方面，不久后就只有Chrome了，因为Edge现在底层运行Chrome。也许我们可以想出另一个补救措施来允许浏览器竞争，但BE备忘录并非没有注意到反垄断补救措施可能造成其他损害。

另一个例子突显了制定政治上合适的补救措施的困难，是德国联邦卡特尔局对脸书施加的限制，涉及用户隐私和数据使用（用于个性化、排名、一般机器学习训练等），这在德国被视为反垄断问题。海法大学教授兼法律与市场论坛主任Michal Gal指出，当然，脸书在回应裁决时，只在检测到你是德国人时才限制其数据使用。如果担心的是机器学习模型在用户数据上训练，这对削弱脸书的能力没什么帮助。假设德国有一个与美国科技竞争的科技界，德国公司担心类似的裁决会针对他们，这将对最初专注于德国市场然后在国际上扩张的新兴德国公司不利。对德国来说，这只是理论上的担忧，因为除SAP外，没有德国公司接近美国大型科技公司的规模和范围。但在审视美国的补救措施和监管时，这不是理论上的担忧，一些立法者会希望权衡保护美国消费者与对美国公司施加的拖累，这种拖累是与韩国、中国和其他外国公司相比的，这些外国公司在本地市场可以在隐私顾虑较少的情况下增长，然后扩展到国际市场。如果认真对待这种担忧，几乎可以用来反对任何支持反垄断行动的论点。

我们未来能做什么？

这份文档已经足够长了，所以我们推迟对政策细节的详细讨论，另找时间，但在高层行动方面，似乎有帮助的一件事是让科技人员密切参与制定补救措施和监管，以及在调查期间参与²。从公开的2011-2012年FTC调查主任备忘录来看，似乎并未这样做，因为BE备忘录中那些通不过科技人员嗅觉测试的论点似乎被认真对待了。另一个例子是Cristina Caffara指出的那个欧盟补救措施，被谷歌立即规避了，许多科技人士会认为这是一个令人愉快的“黑客”。

这种“破解系统”在科技界有着悠久的历史，早于人们称之为“科技”之前，它只是物理学和电子工程。举一个更近期的例子，山姆·奥尔特曼（Sam Altman）成为Y Combinator总裁（最终导致他成为OpenAI首席执行官）的原因之一，就是保罗·格雷厄姆（Paul Graham）欣赏他破解系统的能力；保罗在2010年关于创始人的文章中，在标题为“淘气”的章节下写道：

尽管最成功的创始人通常是好人，但他们眼中往往闪烁着海盗般的光芒。他们不是乖乖牌式的好人。在道德上，他们关心把重大问题做对，但不在意遵守礼节。这就是为什么我用“淘气”这个词而不是“邪恶”。他们喜欢打破规则，但不是重要的规则。这种特质可能是多余的；它可能蕴含在想象力中。

Loopt的山姆·奥尔特曼是最成功的校友之一，所以我们问他可以在Y Combinator申请表上问什么问题，以帮助我们发现更多像他这样的人。他说可以问一个关于他们曾如何破解某事为自己谋利的问题——这里的破解是指击败系统，而不是入侵计算机。这已成为我们评审申请时最关注的问题之一。

或者，从谷歌无数例子中选一个，为了减少差旅成本，谷歌工程师实施了一个系统，他们计算某种基准“航班预期成本”，然后为人们预订低于基准成本的航班提供积分，可用于升级未来的航班和差旅住宿。与那些刻板公司的费用限额相比，这对员工来说是一种很好的体验，谷歌工程师为创建了一个让每个人体验都更好的系统而自豪，这是破解系统的一种方式。更高层次的破解系统是当一些员工优化他们的航班，甚至安排前往高度可优化的目的地旅行（许多工程师会认为这是一个有趣的挑战，是面试中给出的经典动态规划问题的变体等），使他们能够升级到头等舱航班和最好的酒店。

当我和传统行业的管理人员谈论这件事时，他们经常感到震惊，不敢相信这些员工没有因欺骗系统而受到谴责甚至解雇。但当我在谷歌时，人们普遍认为这令人钦佩，因为它体现了黑客精神。

从科技反垄断至少二十年的历史中，我们可以看到，法院、监管机构和立法者并没有为科技公司破解系统的活力、速度和乐趣做好准备。

并且有让科技人员参与桌子另一边的先例。例如，在微软反垄断大案中就是这样做的。但在每个层面都存在激励问题，这使得这件事很困难，原因包括科技公司愿意支付巨额资金等。如果我想到我认识的非常擅长上述破解系统的人，那些想在大公司工作的人通常每年挣七位数（或更多），这个数字不太可能被个人与司法部或FTC签订的咨询合同所匹敌。如果我们再次看微软的例子，参与的技术小组由Ron Schnell管理，他在第三次退出后休息了一段时间，但像他这样的人相对较少。当然，有各种原因不想在大公司工作的人，通常是道德原因或不喜欢大公司的企业政治，但我认识的大多数符合描述的人在大公司待的时间不够长，无法真正理解大公司的运作机制，即使他们是出色的工程师和黑客，也是这份工作的错误人选。

在不久前的反垄断会议上，一位发言人指出，法律界和经济学界的交流与合作对反垄断工作大有裨益。演讲和会议中明显缺少的是行业从业者。会议的感觉像学术会议，所以你可能会在某天看到计算机科学学者参加会议，但即使如此，许多政策层面的讨论也不在计算机科学学者的兴趣范围内。例如，我们指出的BE备忘录中一个不可信的论点是他们如何使用MAU基本上论证转换成本很低。这几乎是每个计算机科学学者研究领域之外的东西，所以即使会议扩大并引入与科技密切相关的人员，自然的参与者仍然不是在涉及微小细节的可信度时有权发表意见的人。

除了上述对政策讨论的影响外，缺乏与科技人员的合作还意味着，当人们谈论行为者的动机时，他们经常做出毫无根据的假设。在一个具体的例子，某人可能称之为“黑客”的行为上，发言人描述了一位高管的反应（击掌庆祝等），并推断出对立法者和法律的蔑视，但这没有证据支持。这位被提及的高管可能确实对立法者和法律有蔑视和鄙视，但那种庆祝正是你在谷歌有人发现如何“免费”在几乎所有航班上升级到头等舱后可能看到的，这完全不能表明蔑视或鄙视。

回到激励问题，这超越了在反垄断讨论中让理解科技的人参与桌子另一边。如果你问当时在国会山的工作人员，普遍的看法是，阻碍FTC调查的主要因素是谷歌的游说，当然谷歌和其他大型科技公司在游说上的花费超过了那些希望加强反垄断审查的实体。

在公务员队伍中，如果我们看BC调查的负责人和BC备忘录的第一作者，他们现在是Facebook竞争与监管事务的董事兼副总法律顾问。我不认识他们，所以我不能谈论他们的动机，但如果有人给我我认为他们做反垄断和其他监管工作所得的报酬，我可能会接受。即使抛开薪酬不谈，如果我坚信加强反垄断执法的目标，这仍然会是一个非常有吸引力的提议。在FTC工作，也许你会领导另一项调查，你写了一份比对方备忘录强得多的备忘录，但当一家大型科技公司在华盛顿特区投入更多游说资金时，这无关紧要，调查就被终止了。或者也许你的调查导致了像欧盟调查那样的结果，最终导致一个太少也太晚的“选择屏幕”。或者也许导致了像Android Play Store解绑案那样的结果，在调查启动七年后，一位足智多谋的谷歌员工想出了一个“黑客”，在大约五分钟内让同意令变得毫无用处。至少在Facebook内部，你可以推动公司朝着你认为正确的方向发展，并对Facebook如何对待消费者和竞争对手产生一些影响。

从科技人员（而非从事反垄断工作的人员）的角度看，在我的社交圈里，经常听到人们说“我永远不会为道德原因在X公司工作”。这是一个不错的立场，但我认识的几乎所有这样做的人最终都在一个影响力很小的公司工作。如果你想采取道德立场，更可能产生影响的是从内部工作或找到一个较小的直接竞争对手并帮助其取得更大成功。

感谢Laurence Tratt、Yossi Kreinin、Justin Hong、kouhai@treehouse.systems、Sophia Wisdom、@cursv@ioc.exchange、@quanticle@mastodon.social和Misha Yagudin的评论/纠正/讨论

附录：非声明

这类似于技术设计文档的“非目标”部分，但更弱，因为设计文档中的非目标通常是暗示某些内容的积极陈述，而这些内容无法从文档中读出，而非目标声明本身不增加任何信息

• 2012年应该对谷歌提起反垄断诉讼
  • 不是说有人应该在意我的意见，但如果当时有人问我是否应该提起反垄断诉讼，我会说“可能不会”。现在支持反垄断行动的理由似乎更强，反对的理由似乎更弱，但你仍然可以提出相当有力的反对反垄断行动的论点。
  • 即使你认为，其他条件不变，反垄断行动对消费者有利，并且“可能发生什么”中的“非常好的情况”结果会在提起反垄断行动时出现，但谷歌和其他科技公司（仅举几例）是否是正确的目标仍然不明确，而不是Visa和Mastercard在支付领域的主导地位、医院合并导致的集中度增加对消费者和工人产生的负面影响、Ticketmaster的主导地位等。或者也许你认为政府应该专注于监管明确保护企业的领域，如航运（根据《谢尔曼法》豁免）或汽车经销商（在美国许多州法律中有特殊保护，防止直销并迫使汽车公司在某些方面遵守其要求）等。
• 今天应采取较弱或较强的反垄断措施
  • 我认为我还没有花足够时间研究法律、政治、历史和哲学背景来形成应该做什么的意见，但我对科技了解得足以指出我看到的几个错误，并指出这些错误中的共同主题。

BC工作人员备忘录

由“Barbara R. Blank、Gustav P. Chiarello、Melissa Westman-Cherry、Matthew Accornero、Jennifer Nagle（反竞争行为司）；James Rhilinger（医疗保健司）；James Frost（政策与协调办公室）；Priya B. Viswanath（主任办公室）；Stuart Hirschfeld、Danica Noble（西北地区）；Thomas Dahdouh（旧金山西部地区）律师；Daniel Gross、Robert Hilliard、Catherine McNally、Cristobal Ramon、Sarah Sajewski、Brian Stone（荣誉法务助理）；Stephanie Langley（调查员）”提交

日期：2012年8月8日

（备忘录正文较长，此处省略）

FTC经济局工作人员备忘录

“经济局

2012年8月8日

发件人：Christopher Adams和John Yun，经济学家”

（备忘录正文较长，此处省略）

其他备忘录

（其他备忘录较长，此处省略）

由 mimo-v2.5 模型翻译，花费 63468 tokens

2017年，我们研究了网络臃肿如何影响网络连接缓慢的用户。即使在美国，许多用户也没有宽带速度，使得大部分网络难以使用。无论是在美国国内还是国外，许多用户仍然没有宽带速度，现代网络的大部分内容对于网络速度慢的人来说仍然不可用，但由于典型网站的带宽呈指数级增长（尼尔森指出对于高速连接，这是每年50%），其增速已超过网络臃肿的蔓延速度，这使得问题比2017年时有所减轻，尽管对于网络连接差的人来说这仍然是一个严重问题。

Web应用的CPU性能增长速度远不及带宽，因此，虽然更多网络内容对低端连接用户变得可访问，但更多网络内容对低端设备用户（即使他们有高速连接）变得不可访问。例如，如果我尝试在Tecno Spark 8C上浏览一个“现代”的Discourse论坛，有时会导致浏览器崩溃。在崩溃之间，测量其性能时，其响应速度明显慢于使用8 MHz 286处理器和1200 baud调制解调器浏览一个BBS。在我家1Gbps的网络连接下，加载消息标题所“必需”的2.6 MB压缩载荷相对较轻。网络传输载荷大小“只”增加了1000倍，这被互联网速度的提升所掩盖。但在CPU速度方面情况恰恰相反——对于网页浏览和论坛加载性能，8核 (2个1.6 GHz Cortex-A75 / 6个1.6 GHz Cortex-A55) CPU无法处理Discourse。该CPU的速度大约比我们的286快100000倍。也许一个快1000000倍的设备才足够。

对于不熟悉Tecno Spark 8C的人，今天，一台全新的Tecno Spark 8C，快速搜索显示，在尼日利亚可能花50-60美元就能买到，在印度可能100-110美元。作为中位家庭收入的一部分，这比今天美国当前一代的iPhone贵得多。

按照全球标准，Tecno Spark 8C甚至算不上低端设备，因此我们也将看看Itel P32的性能，这是一款更低端的设备（尽管仍然远非人们今天使用的最低端设备）。此外，我们将测试M3 Max Macbook (14核)、M1 Pro Macbook (8核)的性能，以及将M3 Max在Chrome开发工具中设置为10倍限速下的表现。为了给这些设备提供一切优势，我们将使用相当高速的互联网（1Gbps，搭配一个基准测试显示其负载下延迟低于大多数同类产品的WiFi路由器）。我们将查看一些博客平台和微博客平台（本博客、Substack、Medium、Ghost、Hugo、Tumblr、Mastodon、Twitter、Threads、Bluesky、Patreon），论坛平台（Discourse、Reddit、Quora、vBulletin、XenForo、phpBB和myBB），以及小企业常用的平台（Wix、Squarespace、Shopify以及再次提到的WordPress）。

在下面的表格中，每一行代表一个网站，每个非标签列是一个指标。网站名称列之后，我们有通过网络传输的压缩大小（wire）和原始未压缩大小（raw）。然后，对于每个设备，我们有最大内容绘制*（LCP*）和主线程上的CPU使用率（CPU）。谷歌的文档将LCP解释为

最大内容绘制（LCP）衡量用户感知到页面最大内容可见的时间点。LCP指标值表示从用户发起页面加载到页面渲染其主要内容之间的时间长度。

LCP是一个常见的优化目标，因为它作为谷歌PageSpeed Insights中的主要指标之一呈现，属于“核心Web指标”。本文档中使用的LCP旁边有一个星号，因为Chrome测量的LCP大致是关于绘制大部分屏幕，而上述定义是关于内容的。由于网站一直在针对LCP进行优化，出现一个对用户完全无用的巨大绘制（更新）的情况并不少见，实际页面内容在LCP之后很久才出现。在这种情况下，我使用的是有用内容出现的时间戳，而不是那个无用的大更新发生时定义的LCP。测试的详细细节以及为何选择这些指标将在附录中讨论。

尽管CPU时间不是“核心Web指标”，但这里展示它是因为它是一个简单且与我以及其他用户在慢速设备上对可用性感知高度相关的指标。更多关于此的详细讨论请参见附录。CPU时间作为一个指标有效的一个原因是，如果一个页面在所有其他指标上表现都很好，但使用了大量的CPU时间，那么这个页面在慢速设备上将不可用。如果它以100% CPU占用运行30秒，页面在30秒内将完全无法使用；如果以50% CPU占用运行60秒，页面在60秒内将勉强可用，等等。另一个原因是，与常用指标相比，很难在CPU时间上作弊，做出显著改变该数字而不影响用户体验的优化。

下面表格中的颜色方案是：对于大小，越绿色=越小/快，越红色=越大/慢。极端值用黑色显示。

乍一看，这个表格似乎大致正确，因为那些除非拥有超级快设备否则会感觉慢的网站，在表格中显示为慢（即，在低端设备上 max(LCP*,CPU)) 很高）。当我调查人们认为哪些平台在我们的慢速设备上会是最快和最慢时（Mastodon，Twitter，Threads），他们通常正确地预测WordPress和Ghost会比Substack和Medium更快，而Discourse会比旧的PHP论坛如phpBB、XenForo和vBulletin慢得多。我也获取了页面（未显示）的Google PageSpeed Insights（PSI）分数，这些数字与我们数据的相关性并不那么强因为少数网站成功优化了它们的PSI分数，但实际上并没有为用户加速页面。

如果你从未使用过这样的低端设备，总体体验是许多网站在该设备上不可用，加载任何资源密集型的东西（应用程序或大型网站）都可能导致崩溃。在资源密集型应用程序中做过于密集的操作也可能导致崩溃。虽然评测指出 你可以在Tecno Spark 8C上以不错的性能运行PUBG和其他3D游戏，但这并不意味着该设备足够快，可以阅读现代以文本为中心的社交媒体平台或现代以文本为中心的网络论坛帖子。虽然在PUBG中可以达到40fps，但我们在这些网站上滚动时可以轻松看到低于0.4fps的情况。

从表格中我们可以看到，如果你有一个慢速设备，有多少网站是不可用的。所有CPU占用超过10秒的页面即使在加载后，体验也相当糟糕。滚动非常卡顿，经常掉到几帧每秒，有时更低。当我们点击任何链接时，延迟非常长，我们无法确定我们的点击是否真的有效。如果我们再次点击，可能会遇到可怕的情况：第一次点击被记录，然后导致第二次点击做错事情，但如果我们等待，我们通常会等待太久，因为原始点击实际上没有被记录（或者它被记录了，但不是我们认为的位置）。尽管MyBB不提供移动版网站，并且因此被谷歌惩罚（因为页面不支持移动设备），但它实际上在这些慢速移动设备上比几乎所有网站都更容易使用，因为滚动和点击实际上都能工作。

我们能看到的另一件事是不同设备上相对性能的巨大差异。例如，比较M3/10和Tecno Spark 8C，对于danluu.com和Ghost，M3/10提供了Tecno Spark 8C的一个大致近似（尽管danluu.com加载速度太快），但Tecno Spark 8C在Medium、Substack和Twitter上的CPU速度慢约三倍，在Reddit和Discourse上慢约四倍，在Shopify上则快了一个数量级。对于Wix，CPU近似值大致准确，但我们的Tecno Spark 8C在LCP*上慢了三倍多。Chrome可以方便地从你的电脑上模拟较慢的设备，这很棒，但仅仅启用Chrome的CPU限速（或使用任何现成的可用选项组合）会给出与我们在许多真实设备上得到的结果相当不同的数据。完整的原因超出了本文的范围；对于本文的目的，只需注意慢速页面在设备变慢时通常会超线性地变慢，并且一个页面的慢速并不能强烈预测另一个页面的慢速。

如果我们采取以网站为中心的视角而不是以设备为中心的视角来看，另一种方式是，像Discourse、Medium和Reddit这样的网站，在我们快速的M3和M1电脑上并没有使用那么多CPU，但它们在我们的Tecno Spark 8C上是最慢的之一（Reddit的CPU显示为∞，因为无论我们等待多久不交互，Reddit都使用约90% CPU）。Discourse有时在交互一点或只是等待一会儿后也会导致浏览器崩溃。例如，有一次，加载Discourse后，滚动两次，然后让设备静置一两分钟，浏览器就崩溃了。为了保持一致性，这在表格中没有被标记为失败，因为页面确实加载了，但现实地说，一个页面资源占用如此之多以至于浏览器崩溃，比表格中任何失败情况都糟糕得多。当我们研究网络臃肿如何影响网络连接缓慢的用户时，我们发现许多网络内容对网络连接缓慢的人来说是不可用的，而慢速设备情况也没有不同。

我们可以看到的另一个模式是，旧网站通常比新网站更快，那些（视觉上）看起来十年或二十年没有更新过的网站往往最快。例如，MyBB，外观最不现代、最古老的论坛，在M3上比Discourse快3.6倍 / 5倍（LCP* / CPU），但在Tecno Spark 8C上，差异是19倍 / 33倍，考虑到整体的扩展性，可以安全地猜测在Itel P32上差异会更大（如果Discourse在如此廉价的设备上能运行的话）。

另一个例子是Wordpress（旧版）与更新、更时髦的博客平台如Medium和Substack。Wordpress（旧版）在我们的M3 Max上比Medium快17.5倍 / 10倍（LCP* / CPU），比Substack快5倍 / 7倍（LCP* / CPU），在我们的Tecno Spark 8C上分别快4倍 / 19倍和20倍 / 8倍。Ghost是这个规律的一个显著例外，它是一个现代平台（比Medium晚一年推出），但性能与旧平台相当（现代Wordpress也可以算是一个例外，但许多人可能仍然认为它是一个旧平台）。在论坛中，NodeBB似乎也有些例外（详情见附录）。

使用现代技术如部分加载页面然后动态加载其余内容的网站（如Discourse、Reddit和Substack），往往不如表格中的分数所显示的那么可用。虽然原则上你可以用简单的方式构建一个在廉价设备上运行良好的此类网站，但实践中，使用动态加载的网站往往足够复杂，以至于在低端设备上极其卡顿。通常很难或不可能滚动一个可预测的距离，这意味着用户有时会因为滚动过远而意外触发更多加载，导致页面卡住。许多页面实际上会在你滚动时删除你已经滚动过的部分；所有这些页面基本上都是不可用的。其他基本的Web功能，如页面搜索，也通常停止工作。具有这种动态加载的页面无法依赖简单快速的ctrl/command+F搜索，必须构建自己的搜索。其效果如何各异（这在Google文档中过去效果很好，但在过去的几个月或一年里，它加载需要很长时间，我必须在打开文档后特意等待，以避免触发浏览器无用的内置搜索；Discourse搜索在慢速设备甚至不算特别慢但也不快的设备上从未真正有效过）。

原则上，这些在加载时消耗大量CPU的现代页面可能正在做预处理工作，这使得页面上的后续交互比那些前期工作少的页面更快、成本更低（这是支持此类页面的常见论点），但对于测试的页面来说，情况并非如此，它们初始加载更慢，后续加载更慢，加载后也更慢。

为了理解为什么这种前期完成所有工作的理论想法通常不会带来更快的后续体验，谷歌的一位杰出工程师与Discourse创始人（当时的CEO）之间的这段交流是有启发性的，在这段讨论中，Discourse的创始人说你应该在笔记本电脑上通过限制带宽但不限制CPU来测试移动网站：

• 谷歌：*你*也没有慢速3G。这两个设置是配套的。同理心需要超越隧道里的iPhone XS用户。
• Discourse：任何iPhone 6或更新版本的手机，其速度基本上都与“平均”笔记本电脑相当。你必须明白高通在工作上有多么糟糕。如果你不相信我，去查一下。
• 谷歌：我不需要相信你。我知道。关心这件事的人都知道这一点。我的观点是，就像不是每个人都有快速连接一样，也不是每个人都有快速手机。当然，iPhone 6在真实世界的网站上经常非常受CPU限制。但这不是重点。
• Discourse：我们几十年来一直在朝着无限CPU速度的趋势发展（而且在桌面端我们大约5年前就已经渐近于此），我们没有也永远不会朝着无限带宽的趋势发展。为重要的事情进行优化。我对@qualcomm没有丝毫同理心。去他妈的高通，他们工作做得太烂了。我希望他们破产，用盐把他们公司存在过的土地犁一遍，这样那里永远寸草不生。
• 谷歌：移动设备在大多数情况下根本不受带宽限制。它们受延迟限制。即使是最新款的iPhone，在带宽受限之前就已经是CPU受限了。如果你在MacBook Pro上放慢4倍速度表现良好，情况就差不多了。
• ...
• 谷歌：是否100%的用户都在iOS上？
• Discourse：有影响力且花钱的用户往往倾向于使用iOS，我告诉你……担心CPU是没意义的，在iOS上它实际上已经是无限的了，而且即使高通的SoC如此糟糕，4年内在他们尴尬的SoC上也会达到这个水平。

当有人问Discourse的创始人“你为什么讨厌他们”时，他回复了一个链接，引用了这篇Anandtech评测中的Kraken和Octane基准测试，其中高通芯片的性能分别是当时苹果芯片的74%和85%。

Discourse的创始人兼当时的CEO认为高通的移动性能令人尴尬，并且认为这是如此不可接受，以至于他认为高通工程师都应该因此丢掉工作，因为他们只提供了苹果性能的74%到85%。苹果拥有我所认为的史上最伟大的性能团队之一。理智的人可能会不同意这一点，但至少必须认为他们是世界级的团队。因此，生产出性能只有这个史上伟大团队的74%到85%的产品，被认为是足以让人丢掉工作的尴尬。

这里展现了两种态度，我在许多软件从业者身上看到过。首先，CPU速度是无限的，不应该担心CPU优化。其次，应该期望硬件带来巨大的速度提升，硬件工程师未能达到这些提升的唯一原因是惊人的无能，因此应该责怪硬件工程师而不是软件工程师。Donald Knuth在以下内容中表达了类似的情绪

我可能得就目前多核架构的潮流表达一下我的个人不满。在我看来，这更像是硬件设计师已经江郎才尽，试图把未来摩尔定律终结的责任推到软件写手身上，通过给我们提供只能在少数关键基准测试上运行更快的机器！如果整个多线程的想法最终被证明是一个失败，比“Itanium”方案还糟——那个方案本应如此了不起——直到最终发现所希望的编译器基本上无法编写出来，我也不会感到惊讶。让我这样说：在过去的50年里，我写了超过一千个程序，其中许多都有相当大的规模。我想不出其中哪怕五个程序会因为并行或多线程而得到显著增强。当然，例如，多处理器对TeX毫无帮助……我知道并行性的重要应用是存在的——渲染图形、破解代码、扫描图像、模拟物理和生物过程，等等。但所有这些应用都需要专用代码和特殊技术，这些技术每隔几年就需要进行大幅度的修改。即使我足够了解这些方法，可以在TAOCP中写到它们，我的时间也将被大量浪费，因为很快就没有人有理由去读那些部分了……我今天使用的机器有两个处理器。我只有在同时运行两个独立任务时才能同时使用它们；这很好，但这每周只发生几分钟。

在Discourse的案例中，如果一个硬件工程师无法达到一个史上伟大团队90%的性能，那么他就是令人尴尬的、不配拥有工作的人，但作为软件工程师，交付性能仅为像MyBB这样的非高度优化应用程序的3%却没问题。在Knuth的案例中，硬件工程师几十年来每十年为程序员提供100倍的性能提升，而程序员几乎或根本不需要做任何工作。当这种提升放缓，程序员必须适应以利用新硬件时，硬件工程师就“江郎才尽”了，但学习一些利用当前硬件的“新”（1970和1980年代的）想法却被认为是浪费时间。而且我们之前讨论过艾伦·凯声称硬件工程师“不成熟”且“未受过教育”，没有在做“真正的工程”，以及如果我们听从艾伦·凯的“成熟”想法，我们将获得1000倍的速度提升。

程序员期望硬件解决他们所有问题，然后当这没有发生时，就将问题推给用户，解释为什么程序员不需要为帮助用户做任何事情，这是相当常见的。人们可能会问的一个问题是程序员给了我们多少性能改进。有些算法改进带来了巨大的速度提升，但正如我们上面指出的，Discourse，当今增长最快的论坛软件，似乎给我们带来了大约1000000倍的性能下降。

上面展示的另一种常见态度是，不富有的用户无关紧要。当被问及是否100%的用户都在iOS上时，Discourse的创始人说“有影响力且花钱的用户往往倾向于使用iOS，我告诉你”。我们在Tonsky的JavaScript臃肿文章的评论中到处都能看到这种态度，人们表达鸡尾酒会式的情绪，比如“手机应用有几百兆，为什么我们要纠结于几兆的Web应用？非洲饥民可以下载Android应用但不能下载Web应用？得了吧”以及“gitlab的用户肯定不会穷到有慢速设备，认真点吧”（为了长度而意译）。

但当我们看看在非洲下载的应用大小时，我们看到那些没有高端设备的人使用像Facebook Lite（几兆）这样的应用，并且通常使用大小从个位数到低两位数兆字节不等的应用。应用开发者关心其应用大小有多个原因。一个是手机上可用的总存储空间；如果你观察真实用户安装应用，他们经常必须删除和卸载东西才能安装新应用，所以较小的大小不仅更容易安装，而且在用户寻找更多空间时被卸载的可能性也更低。另一个原因是，如果你查看应用大小和使用情况的数据（我不知道有公开的此类数据；如果你有可以引用的公开数据，请提供），当大型应用增加大小和内存使用量时，它们会获得更多崩溃，这降低了用户留存、增长和参与度；相反，当它们优化大小和内存使用量时，崩溃减少，用户留存、增长和参与度提高。

Alex Russell指出，iOS在印度（一个14亿人口的市场）占7%的市场份额，在拉丁美洲（一个6亿人口的市场）占6%。尽管Discourse的创始人说这些不是重要的“有影响力的用户”，但他们仍然是真实的人。Alex进一步指出，根据Windows遥测数据（涵盖了绝大多数桌面用户），大多数笔记本电脑/台式机用户使用的是低端机器，这些机器可能比现代iPhone慢。

关于没有程序员使用慢速设备的说法，我认识很多使用旧而慢的手提设备的人。他们中的许多人甚至不真正贫穷；他们只是不明白为什么（例如）他们的孩子需要一个超快的设备，也不明白现代网络在慢速设备上运行不佳的程度。毕竟，这个“慢”设备可以玩3D游戏，并且（在适当的操作系统下）可以编译像Linux或Chromium这样的代码库，为什么这个设备不能与像gitlab这样的网站交互呢？

与Discourse创始人声称所有Android用户几年内都会拥有某种超快Android设备的说法相反，自他评论以来已经六年了，几乎每个使用手机的人都将拥有高速设备至少还需要十年，这可能轻易需要二十年或更长时间。如果你查找Discourse的市场份额统计数据，它极其成功；它似乎是世界上增长最快的论坛软件，且遥遥领先。世界上增长最快的论坛软件是由一个组织创建的，该组织当时的领导者愿意表示他并不真正关心那些不是“有影响力的花钱用户”，没有“无限CPU速度”的用户，其影响是许多论坛现在对那些没有足够财富购买实际上具有无限CPU设备的人是无法访问的。

如果Discourse的创始人是个异类，这不会是一个太大的问题，但他只是在明确表达许多程序员隐含的假设，这就是为什么我们看到这么多现代网站在你购买相当于低收入国家收入水平的新款当前一代iPhone时是不可用的。

感谢Yossi Kreinen、Fabian Giesen、John O'Nolan、Joseph Scott、Loren McIntyre、Daniel Filan、@acidshill、Alex Russell、Chris Adams、Tobias Marschner、Matt Stuchlik、@gekitsu@toot.cat、Justin Blank、Andy Kelley、Julian Lam、Matthew Thomas、avarcat、@eamon@social.coop、William Ehlhardt、Philip R. Boulain和David Turner的评论/更正/讨论。

附录：游戏化LCP

我们在上面提到我们使用了LCP*而不是LCP。这是因为LCP基本上衡量的是最大变化发生的时间。当这个指标没有被刻意以不利于用户的方式“游戏化”时，它是一个很好的指标，但随着更多人对其进行游戏化，这个指标作为实际用户体验的代表性降低了。

在不那么明目张胆的情况下，人们做了一些小的优化，这些优化提高了LCP，但对实际用户体验几乎没有改善或根本没有改善。

在更明目张胆的情况下，开发者会故意尽快在页面上闪现一个非常大的变化，通常是一个对用户毫无价值的加载屏幕（实际上因为这样做增加了完成工作的总量和页面加载总时间，所以是负面价值），然后他们小心翼翼地避免进行任何足够大的更改，以至于后续的任何更改都不会被标记为LCP。

出于同样的原因大众汽车没有公开讨论它如何对其排放数据进行游戏化，开发者倾向于避免公开讨论这类LCP优化。一个例外是Discourse，他们公开宣布了这种LCP优化，并有其开发者和当时的CTO（现在的CEO）的评论，指出他们的新“Discourse Splash”功能在部署后极大地降低了网站的LCP。然后，当开发者询问为什么他们的LCP很高时，Discourse开发者的标准建议是保持元素小于“Discourse Splash”，这样LCP时间戳就会从这个为优化LCP而抛出的无用元素计算，而不是从任何与用户相关的实际元素计算时间戳。这里是Discourse的一个典型的官方评论

如果你的横幅大于我们为“引入Discourse Splash - 站点资源加载时显示的视觉预加载器”使用的元素，你在LCP方面会遇到麻烦。

Discourse的官方回应是，你应该确保你的内容不会触发LCP测量，而是应该使用我们的加载动画时间戳来计算LCP。

有用内容的LCP与Chrome测量的LCP比率最极端的网站是：

• Wix
  • M3: 6
  • M1: 12
  • Tecno Spark 8C: 3
  • Itel P32: N/A (失败)
• Discourse:
  • M3: 10
  • M1: 12
  • Tecno Spark 8C: 4
  • Itel P32: N/A (失败)

虽然我们还没有讨论其他指标的游戏化，但似乎一些网站也对其他指标进行游戏化和“优化”，即使这对用户没有好处。

附录：优化网站的自私理由

这将取决于网站的规模及其性能，但当我为我工作过的大公司查看这些数据时，提高网站和应用性能的价值是惊人的。它在A/B测试中是可测量的，并且在长期保持中，它也是对增长和留存影响相对较大的干预措施之一（许多干预措施测试效果良好，但长期看效果不佳，而性能改进往往长期看效果更好）。

当然，你可以从直接数字中看到这一点，但当你查看数据时，也可以从很多方面间接地看到这一点。一个角度是（仅举一例），在Twitter，用户观察到的p99延迟在印度以及许多非洲国家（即使排除相对富裕的埃及和南非）约为60秒，在美国也约为60秒。当然，在整个群体中，美国的人们拥有更快的设备和连接，但在每个国家，都有足够多的拥有慢速设备或连接的用户，其限制因素实际上是用户的耐心，而不是底层的人口级设备和连接分布。即使你不关心尼日利亚或印度的用户，只关心美国的广告收入，为低端设备和连接提高性能的影响也足够大，我们可以在全球以及美国的收入A/B测试中轻易看到影响，尤其是在长期保持中。而且你也会在拥有快速设备的用户中看到影响，因为一个将“低端”设备用户的延迟从60秒提高到50秒的改动，可能将高端设备用户的延迟从5秒提高到4.5秒，这也会影响收入、增长和留存数字。

由于超出本文范围的各种原因，在大多数我工作过的大公司里，这类无聊、可量化、驱动增长和收入的工作相比那些最终在长期保持中显示很少或没有影响的闪亮产品工作，更难获得资助。

附录：为低性能设备设计

当使用慢速设备或任何低带宽和/或连接性差的设备时，体验最好的往往是那些将大量内容一次性加载到静态页面中的。如果图像具有正确的宽度和高度属性以及alt文本，那会非常有帮助。渐进式图像（如渐进式jpeg）并没有特别帮助。

在具有高带宽的慢速设备上，任何轻量级、静态的页面都能很好地工作，轻量级的动态页面如果为性能设计得当也能工作。重型的动态页面注定失败，除非页面重量不会导致页面复杂。

在低带宽和/或连接性差的情况下，轻量级页面没问题。对于重页面，我体验最好的时候是触发页面加载后，去做其他事情，然后在加载完成（或至少HTML和CSS加载完成）时回来。然后我可以为每个可能想阅读的链接打开一个新标签页，然后在等待它们加载时做其他事情。

现代网站做的许多优化，比如导致你在页面向下滚动时加载更多的部分加载，以及随之而来的搜索劫持（因为如果页面没有完全加载，浏览器的内置搜索就毫无用处），导致原本有效的交互模型变得无效，使页面交互起来非常痛苦。

仅举一例，许多人指出Substack对他们来说表现不佳，因为它进行部分页面加载。这里是@acidshill在iPhone 8上加载Substack文章然后滚动的视频，其中帖子的LCP相当快，但如果你想滚动过标题，你必须等待6秒下一个页面加载，然后再次滚动时，你可能又得等待1秒到2秒：

作为相反方法的一个例子，我尝试加载一些相当大的纯HTML页面，如https://danluu.com/diseconomies-scale/（网络传输0.1 MB / 原始0.4 MB）和https://danluu.com/threads-faq/（网络传输0.4 MB / 原始1.1 MB），即使在慢速设备上，这些页面对我来说仍然相当可用。1.1 MB似乎大于最优值，将其分成几个不同的页面在低端设备上会更好，但包含1.1 MB文本的单个页面在慢速设备上比大多数现代网站运行得更好。虽然HTML页面过大导致浏览器无法真正处理时会遇到麻烦，但对于具有正常内容量的页面，通常直到你有复杂的CSS负载或JS时，页面才会开始给慢速设备带来问题。下面，我们测试了一些相对简单的页面，其中一些有相当多的媒体（一种情况下有14 MB），发现只要它们保持简单，这些页面就能正常工作。

Chris Adams还指出，使用屏幕阅读器的盲人用户经常报告动态加载使他们的体验变得更糟。就像为了提高性能而进行的动态加载一样，虽然这可以做得很好，但通常要么做得不好，要么与太多其他复杂性捆绑在一起，结果比一个简单的页面更糟。

@Qingcharles指出了另一个无障碍问题——他合作的（监狱）假释者获得“生命线”手机，这些通常是低端设备。快速搜索显示，在2024年，有些人会获得iPhone 6或iPhone 8，但也有许多设备比Itel P32更低端，更不用说Tecno Spark 8C了。他们还获得数据非常有限的套餐，然后当数据用完时，有些人“无法填写任何工作、福利的表格，也无法使用地图导航去任何地方”。

对于那些确实进行预处理并在低端设备上为你提供良好体验的网站，Andy Kelley指出了一个似乎在慢速设备上运行良好的网站的例子（尽管在非常慢的连接上可能会很吃力），Zig标准库文档：

我做出了一个有争议的决定，让程序一开始获取所有源代码，然后在本地进行所有内容渲染。理论上，这很消耗CPU，但实践中……即使是那些旧手机也有非常快的CPU！

在Tecno Spark 8C上，这消耗了4.7秒的CPU时间，之后相当响应迅速（相对于该设备——当然iPhone响应快得多）。点击导致链接相当快地加载，滚动也可以正常工作（有点卡顿，但在这个设备上几乎没有什么是真正流畅的）。这似乎就是人们所说的那种情况，如果你提供重载荷可以获得更好的性能，但这样的例子在低端设备上真正提高性能的并不多。

附录：关于网络性能问题的文章

• 2015: Maciej Cegłowski: 网站肥胖危机
  • 大小: 1.0 MB / 1.1 MB
  • Tecno Spark 8C: 0.9s / 1.4s0.7s1.1s2.9s4.4s4.8s13s16s Squarespace1.9MB7.1MB0.1s0.4s0.2s0.4s0.7s3.6s14s5.1s16s19s Mastodon3.8MB5.3MB0.2s0.3s0.2s0.4s1.8s4.7s2.0s7.6s失败失败 Tumblr3.5MB7.1MB0.7s0.6s1.1s0.7s1.0s

由 mimo-v2.5 模型翻译，花费 42808 tokens

如果我问自己这样一个问题：“我想买一张SD卡，我该信任谁卖给我正品而不是假货？亚马逊还是我当地的百思买？”答案当然是我更信任当地的百思买，而不是以销售假冒SD卡而臭名昭著的亚马逊。如果我问更值得信任谁，我当地的知名电子产品店（Memory Express、B&H Photo等），我更信任我当地的知名电子产品店。它们不仅不太可能卖给我比百思买更少的假冒产品，而且万一他们卖给我假货，服务也可能会更好。

同样地，假设我问自己这样一个问题：“在哪种平台上，我遇到诈骗、垃圾信息、欺诈内容等的比率更高，是[较小的平台]还是[更大的平台]？”通常答案是[更大的平台]。当然，较小的平台总量更多，差异也更大，所以我可以选择刻意使用一个更差的小平台，但我选择的是好的选项而不是坏的选项。在每种规模级别中，较小的平台通常都更好。例如，对比Signal和WhatsApp，我从未收到过垃圾Signal消息，而我相当定期地收到垃圾WhatsApp消息。或者，如果我对比可能阅读科技内容的地方，如果我对比无人知晓的小型论坛和lobste.rs，lobste.rs的坏内容率（指我看到的信息中占的比例，而非绝对数量）要略高一点，因为私人论坛上是零，lobste.rs上则非常低但非零。然后，如果我将lobste.rs与一个稍大的平台（如Hacker News或mastodon.social）进行比较，这些平台的诈骗/垃圾信息/欺诈内容率又（同样非常轻微地）更高。然后如果我将其与中等规模的社交媒体平台（如reddit）相比，reddit的坏内容率明显更高且可被察觉。最后，如果我将reddit与像YouTube、Facebook、谷歌搜索结果这样的巨型平台相比，这些更大的平台拥有更高比率的诈骗/垃圾信息/欺诈内容。而且，与SD卡的例子类似，随着平台规模的扩大，获得良好客服支持的可能性也会降低。如果因错误而被暂停或禁止使用该账户，账户获得恢复的可能性也会随着平台的增大而变得更差。

我认为说“总体而言，很多事情随着平台变大而变糟”是无可争议的。例如，当我进行一次Twitter投票，看看我认识的人怎么看时，只有2.6%的人认为巨型公司平台拥有最好的内容审核和垃圾信息/欺诈过滤。作为参考，在一次调查中，9%的美国人表示疫苗会植入微型芯片，12%的人表示登月是假的。虽然调查对象不同，但随机美国人更可能认为登月是假的，而技术人员则不太可能认为最大的公司在反欺诈/反垃圾/内容审核方面做得最好。

然而，在过去五年里，我注意到越来越多的人提出相反的主张，即只有大公司才能进行像样的内容审核、垃圾信息过滤、欺诈（和假冒）检测等。我们研究了其中一个例子，当时我们考察了搜索结果，一位谷歌工程师说

有人试图辩称，如果搜索领域更具竞争性，有很多小供应商而不是像现在这样的三大巨头，那么它可能*更*能抵抗基于机器学习的SEO滥用。

而且……听着，如果*谷歌*目前都无法跟上，那么市场份额5%的“小先生”又怎么能做到呢？

一位意见领袖回应道

大约95%的时候，当有人声称某个小而独立的公司能在某件困难的事情上比市场领导者做得更好时，这仅仅是自我安慰。规模经济运作得相当好！

但当我们查看实际结果时发现，在我们考察的搜索引擎中，市场份额0.0001%的“小先生”最能抵抗SEO滥用（并且相当不错），市场份额0.001%的“小先生”对SEO滥用有一定抵抗力，而谷歌和必应则充斥着SEO滥用，经常将人们直接引导至各种诈骗。电子邮件方面也发生了类似的情况，我经常听说由于垃圾信息负担而自己管理电子邮件是不可能的，但人们一直这样做，并且通常取得与Gmail相当或更好的效果，主要问题在于与大型公司邮件服务器的交互，它们错误地禁止了他们的小型电子邮件服务器。

大约在我开始看到很多声称“你需要规模才能进行内容审核、反垃圾、反欺诈等”的评论时，扎克伯格回应伊丽莎白·沃伦呼吁拆分大型科技公司的言论，声称拆分科技公司会使内容审核问题严重得多：

“拆分这些公司，无论是Facebook、谷歌还是亚马逊，实际上并不能解决问题，”扎克伯格说，“而且，你知道，它并不能让选举干预的可能性降低。它实际上增加了可能性，因为现在公司之间无法协调和合作。它并不能让仇恨言论或类似问题发生的可能性降低。它增加了可能性，因为现在……我们正在投入和建设的所有流程，现在都更碎片化了。

这就是为什么Twitter无法像我们那样做好工作。我的意思是，他们面临的问题，在定性层面上，和我们一样。但他们无法投入足够的资金。我们在安全方面的投入比他们整个公司的收入还多。[笑声]是的，我们运营的规模更大，但他们面临的问题并非在本质上有所不同。他们面临着和我们所有相同类型的问题。”

论点是，你需要大量资源才能做好内容审核，而较小的公司，当时价值约300亿美元的Twitter规模公司，无法调配必要的资源来做好内容审核。我当时觉得这个说法相当可笑，因为在收购Twitter之前，我在Facebook上看到明显诈骗内容的比率远高于Twitter。例如，当我在假日购物季点击Facebook广告时，大多数都是诈骗，而虽然Twitter也有诈骗广告，但其严重程度与Facebook不在一个量级。而且不止我一个人——设计过Facebook早期举报系统并领导过一些主要信任与安全工作的Arturo Bejar也注意到了类似的事情（详见脚注²）。

扎克伯格似乎喜欢上述推理路线，他在其他地方也提出过类似的论点，例如这里，就在Meta的内部文件显示其每天向10万未成年人暴露性虐待图像的同一年：

在某种程度上，当我在宿舍刚开始创业时，我们显然不可能有1万名或4万名员工做内容审核，而且当时的人工智能能力也远不足以主动发现大量有害内容。到了某个阶段，随着公司规模扩大，才开始有可能做更多这方面的工作

这里的修辞手法是假设Facebook在扎克伯格的宿舍刚起步时需要1万名或4万名员工做内容审核。比“宿舍版Facebook”更大的服务现在就能并且确实在做比今天的Facebook更好的内容审核，通常只需一名内容审核员，而且往往是兼职的。但随着人们更多地讨论对大型科技公司采取真正的反垄断行动，科技巨头的创始人和高管加大了反反垄断的言论，声称如果最大的公司被拆分成2015年或2010年最大的科技公司那样规模，人类将面临各种灾难。这种推理似乎开始有点流行了，因为我看到越来越多的大公司员工提出非常相似的理由。自从1979年IBM培训手册写道

现在，对于许多关键决策，正是计算机可以做出大部分决策，而缺乏问责制似乎最终成为了一种特性，而非缺陷。

但不幸的是，对于扎克伯格的论点³，至少有三个主要方面存在规模不经济占主导地位的情况。第一，对于几乎所有人都同意是坏材料的东西（如比特币诈骗、假冒药品垃圾信息、虚假天气预报、成年人向儿童发送其生殖器照片等），大型平台做得比小型平台更差。第二，对于用户来说，随着公司变大，错误的成本更高，也更难修复，因为支持通常变得更差。第三，随着平台规模扩大，会有更大比例的用户强烈反对平台上应该允许什么内容。

关于第一点，虽然大公司确实拥有更多资源，但认为“因为他们资源最多，所以内容审核最好”的“鸡尾酒会式想法”受到了一个同样简单化的观点的反驳：“因为他们是最大的靶子，所以内容审核会最差”，或者“因为他们将因组织扩大和问题领域扩展时发生的标准规模不经济而导致最严重的碎片化，所以内容审核会最差”。公司拥有更多资源还是这些其他因素占主导地位，这个问题太复杂了，无法从理论上解决，但我们可以从经验上观察结果。至少在大公司选择投入内容审核、垃圾信息等方面的资源水平上，更大的靶子和其他与规模相关的问题占据了主导地位。

虽然这些公司利润丰厚，可以投入足够的资源来显著减少这个问题，但他们选择不这样做。例如，在我写这句话的前一年，Meta截至2023年12月的税前利润为470亿美元。如果Meta拥有其一位朋友工作的电力公司的那种内部愿景声明（“可靠的能源，低成本，服务于世代”，）并像那家电力公司那样运作，试图为用户创造良好体验而不是最大化利润加创造元宇宙，他们本可以将花在元宇宙上的500亿美元用于内容审核平台和技术，然后在每个国家以3万美元/年的薪酬（这在大多数雇佣内容审核员的国家会是非常好的收入，让他们可以挑选雇佣对象）雇佣160万全职员工，用于处理升级问题和支持等，大约每几千名用户就有一名额外的内容审核员或支持员工（当然，规模不经济也适用于管理这么多人）。我并不是说Meta或谷歌应该这样做，只是当大科技公司的人说类似这样的话：“这些系统必须完全自动化，因为没有人能在我们的规模上负担得起运行手动系统的成本”，真正想说的更接近于：“如果我们雇佣足够多的胜任人员来手动审查我们系统应该标记为模棱两可的案件，我们将无法每年赚取数十亿美元的利润，所以我们满足于在不影响利润的情况下所能得到的结果”。⁴有人可以为这个选择辩护，但这确实是一个选择。

同样，对于规模经济优势的说法也是如此。有些领域确实存在规模经济，能为用户带来更好的体验。例如，当我们研究为什么买到运行良好的东西这么难时，我们注意到亚马逊的规模经济使他们能够建立自己的包裹递送服务，虽然有缺陷，但仍然比其他可用服务更可靠（而且自从他们增加了用户可以对每次送货进行评分的功能后，这一点得到了进一步改善，而其他主要的包裹递送服务都没有这个功能）。同样，苹果的规模和垂直整合使他们能够组建历史上最伟大的性能团队之一（通过设备延迟等方式），不仅在基准测试中碾压竞争对手，而且以直到最近才有人测量的方式提供了更好的用户体验。一个更普通的规模经济例子是，饼干和其他适合运输的食品在亚马逊上比在我当地的杂货店更便宜。很容易就能列举出规模经济使用户受益的方式，但这并不意味着我们应该假设规模经济在所有领域都占主导地位。虽然这超出了本文的范围，但如果我们要讨论用户在公司更大还是更小时过得更好，我们应该看看随着公司变大，什么变好了，什么变糟了，而不是仅仅假设因为有些事情变好了（或反之），所有事情都会变好。

回到关于巨型公司拥有最多资源用于内容审核、垃圾信息、反欺诈等的论点，与现实情况——他们选择将这些资源用于其他地方，比如在元宇宙上砸500亿美元而不是雇佣他们负担得起的160万内容审核和支持员工——的对比，值得看看实际投入了多少努力。Meta在缅甸的参与是一个很好的案例研究，因为Erin Kissane写了一篇相当详细的4万字的事件回顾。整个事件是一个庞大而复杂的问题（更多讨论见附录），但就本文的主要主题而言，关键要素是：存在一个绝大多数人都同意应该是最高优先级的内容审核和支持问题，并且尽管Meta的各级员工（工程师、总监、副总裁、高管等）反复收到极其严重和紧急的警告，但几乎没有为这个问题投入资源，而内部文件显示，只有一小部分达成共识的坏内容被他们的系统捕捉到（大约百分之几）。我认为这并非Meta独有，这与我在其他大型科技公司的经验相符，无论作为其产品的用户还是员工。

举个较小规模的例子，我一个熟人的Facebook账户被入侵，现在被用来进行比特币诈骗。这个人的名字叫Samantha K.，某个骗子做了足够多的诈骗活动，以至于他们甚至没有正确阅读她的名字，并生成了非常明显的伪造照片，照片中有人举着一个牌子，解释“Kamantha”如何帮助他们赚了成千上万美元。这是“黑客”的常见做法，我在FB上的另一个熟人也报告说他们的账户发生了同样的事情，他们既无法恢复旧账户，也无法让账户被封禁，尽管该账户持续发布明显的诈骗信息。

相比之下，在lobste.rs上，我从未见过这样的诈骗，版主Peter Bhat Harkins说据他所知从未有过一个。在Mastodon上，我认为我可能在我的feed、回复或提及时见过一次。当然，Mastodon足够大，如果你特意去找，可以找到一些诈骗，但每条信息和每个用户的比率都很低，作为普通用户你不应该会遇到它们。在Twitter（收购前）或reddit上，中等频率，也许在我的正常feed里平均每几周一次。在Facebook上，我一直看到这样的东西；每个购物季我都会看到明显的假冒消费品网站诈骗，而比特币诈骗，无论是来自广告还是账户接管，全年都在发生。许多人指出他们不再费心举报这类诈骗了，因为他们观察到Facebook不会对他们的举报采取行动。与此同时，Reuven Lerner因在Facebook上投放关于Python和Pandas课程的广告而被终身禁止投放广告，似乎是因为Facebook系统“认为”Reuven在投放与动物交易相关的内容（而不是编程）。这就是扎克伯格声称任何小公司都无法匹敌的内容审核和垃圾信息控制的保真度。顺便说一句，我并不是特意针对Meta；如果你想要一些稍有不同的例子，你可以在附录中查看Google的例子，其中列出了自动化系统在Google出错的上百个案例。

这又回到了经验问题，因为所有这些关于规模经济允许巨型公司投入更多资源解决该问题的说法，都取决于公司是否选择部署这些资源。没有理论力量迫使公司在这些领域部署资源，所以我们无法从理论上推理。但我们可以观察到，即使在人们通常会同意问题显然应该属于高优先级的情况下（比如Meta在缅甸），部署的资源也不足以匹配问题。当然，对于优先级不那么明显的问题，资源同样没有部署。

关于第二个问题，客户支持，科技圈里有个说法：要获得大平台用户的支持，唯一的办法是在社交媒体上发帖引爆舆论，或者认识内部人员。这加剧了内容审核、诈骗检测、反欺诈等等方面的问题，因为如果支持良好，这些问题本可以得到缓解。

普通的客户支持渠道是个笑话，你要么收到千篇一律的模板拒绝，要么陷入卡夫卡式的噩梦，然后收到模板拒绝。例如，当Adrian Black因冒充Adrian Black而被YouTube封禁（明确地说，他被封是因为冒充自己，而不是同名的其他人），在申诉后，他收到了这样的回复：

很遗憾，我们这边无法再做更多。您的账户暂停和申诉都经过了非常仔细的审查，决定是最终的。

在另一个Google支持的故事中，Simon Weber在试图获取申报税款所需信息时，被Google支持部门来回推诿：

自2018年4月以来（这是在2020年9月写的），我的扩展程序（以及我认为所有扩展程序商家？）的会计数据导出一直有问题。我不得不让纽约州总检察长给他们写了一封信，他们才真的回应我的支持请求，这样我才能正确申报税款。

还有一次，YouTube不断将PointCrow用筷子吃水的视频取消货币化（他反复将筷子浸入水中，然后喝水，非常缓慢地吃一碗水）。

尽管YouTube回复说

我们对这个错误以及反复的过程非常抱歉，我们已经与团队沟通过，确保这种情况不会再发生

但他的视频再次被取消货币化，申诉又以标准的支持回应策略开始，即他们仔细审查了违规内容，但不幸的是，用户明显违反了政策，因此无能为力：

我们已经审查了您的申诉...我们仔细审查了您的内容，并确认它违反了我们的暴力或血腥内容政策...确保YouTube对所有人来说都是一个安全的地方是我们的工作。

这些是高调的例子，但当然，低调也不会阻止你被封禁并得到同样的基本上是模板化的回应，比如这位在FB Marketplace上卖吸尘器而被封禁的HN用户。经过多次申诉后，他被告知：

很遗憾，您的账户因违反社区准则而无法恢复。审查是最终的。

当付费支持是可选的时候，人们常说如果你付费支持就不会有这些问题，但使用Google One付费支持或Facebook和Instagram付费创作者支持的人普遍报告说付费支持并不比免费支持好。那些实际上内置了付费支持的产品也不一定更好。我认识一些人，他们从Google Cloud获得的支持与免费Google支持一样来回推诿，即使他们为每年在Google Cloud上花费八位数或九位数的公司工作。在一个众多例子中的例子里，用户发现Google一定在丢包，而Google支持坚持认为数据包丢失发生在客户的机房，尽管数据包跟踪显示情况不可能如此。我听说他们放弃了那个案子，但有时当问题是完全的阻碍时，有人会打电话给他们在Google的朋友寻求支持，因为标准支持通常完全无效。这在Google并非独有——在另一家云供应商，我的一位前同事在一个会议上得知，一位非常资深的工程师被要求调查一个客户抱怨的问题：客户看到100%的数据包被丢弃，持续几秒钟，每小时发生多次。那位工程师回应说类似“这是云，他们应该处理它”的话，然后被告知他们不能像往常一样忽略这个问题，因为问题来自[重要客户]，并且正在中断[世界上最大的电视体育赛事之一]。那个问题得到了解决，但很可能，你并不那么重要，即使你每年支付数亿美元。

当然，这种支持并非云供应商独有。例如，有一次Stripe扣留了一位客户40万美元超过一个月，没有解释，每一次向支持部门的请求都得到了像我们刚才看到的一样荒谬的回应。用户利用了唯一可靠的Stripe支持机制，在HN上发帖并希望上首页，这奏效了，尽管许多评论者说这是常规评论，比如“标记，因为我们看到很多这样的HN帖子，它们似乎是试图欺诈性地操纵客户支持，而不是真实的故事”，多人暗示或影射用户在做某种非法或欺诈的事情，但事实证明这是Stripe方面的错误，再加上Stripe的大公司支持。在某个时候，用户指出：

在我写HN帖子的同时，我还在与Stripe聊天一个多小时。没有新信息。他们基本上是想关闭和我聊天，直到我给他们看了HN的故事并显示它获得了一些关注度。然后他们才重新开始处理我的问题，并尝试与更多人沟通。

然后问题在第二天就得到了解决。

尽管原则上，随着公司变得更大，他们可以利用规模经济提供更高效的支持，但他们往往利用规模经济提供更差但更便宜、更有利可图的支持。例如，关于Google Play商店的批准支持，一位Google员工指出：

很多支持外包给了海外，导致响应时间慢得多。在美国这边，我们有很多指标来实现快速响应。通常你的应用会在同一天得到审核。不确定现在情况如何，但当时管理层很无能。

一位前FB支持人员指出：

这里的大问题是劳动分工。在队列中花费最多时间的人对政策的影响最小。分析师可以向QA提出问题，然后QA再向Facebook正式员工（FTE）提出。问题可能需要数月才能得到解决，如果能得到解决的话。最糟糕的是，按照常识去做，执行政策的精神而非字面意思，可能会对你的质量评分产生负面影响。我经常想到，在我任职的几个月里，由于政策“澄清”中一个措辞草率的地方，大多数肢解动物的照片都被允许出现在平台上，没有警告屏幕，而我们对此无能为力。

如果你曾经想知道为什么你的支持人员回复不合逻辑，有时原因是显而易见的：支持工作外包给了一个每小时挣1美元的人（当我查到一个很多支持工作外包的国家的标准费率时，一个相当标准的费率大约是每小时1美元），他们不太懂你所使用的语言，并且是在照着流程图念，对他们正在提供支持的系统一无所知。但另一个不那么明显的原因是，如果支持人员采取了有意义的行动而不是遵循他们面前那个毫无意义的流程图，他们可能会受到惩罚并最终被解雇。

回到“它们似乎是试图欺诈性地操纵客户支持，而不是真实的故事”这个评论，这是我在那些随意和反复无常的封禁用户的大公司中经常看到的工程师表达的一种情绪。我理解人们是如何走到这一步的。在我加入Twitter之前，我就指出过，评论公开信息：

事实证明，Twitter每天移除约100万机器人账户。Twitter只有约3亿月活跃用户，这使得错误容忍度非常低。这似乎是一个非常难的问题...Gmail的垃圾邮件过滤器每1000封正确分类的正常邮件中可能会给我大约1个误报...定期清除同等比例的真实用户在服务中将是[糟糕的]。

这是真的，如果你，一个工程师，深入研究某个巨头公司的支持队列，查看那些申诉封禁的人，几乎所有的申诉都应该被拒绝。但是，根据我与从事反欺诈系统等工作的工程师交谈的经验，许多人，也许是大多数人，将“几乎所有”四舍五入到了“全部”，这在数量和质量上都是不同的。让从事这些系统的工程师相信他们的决策“全部”而不是“几乎所有”都是正确的，会导致用户糟糕的体验。

例如，有一家社交媒体公司因错误地封禁用户而闻名（我认识的人中至少有10%因错误的封禁而失去了账户，如果我随机搜索一个不认识的人，很可能找到他们的多个账户，其中一个最近的账户写着“曾经是@[某个旧账户]”，旧账户没有转发到新账户，因为他们现在被封禁了）。当我遇到这个团队的一位高级工程师时，我问他为什么有这么多合法用户被封禁，他告诉我类似“那不是问题，真正的问题是我们没有封禁足够多的账户。每个被封禁的人都罪有应得，不值得听取申诉或思考它们”这样的话。当然，每个公共平台上的大多数内容都是坏内容、垃圾信息等是真的，所以如果你对某个东西是否是坏内容有任何信号，当你查看它时，它很可能是坏内容。但这并不意味着反过来也成立，即几乎没有用户被错误地封禁。如果负责分类哪些内容是坏内容的团队中的高级人员持这种态度，即我们不需要担心误报，因为几乎所有被标记的内容都是坏内容，我们最终会得到一个具有大量误报的系统。我后来四处询问，看看为减少欺诈检测系统中的误报做过哪些努力，结果发现根本没有系统地跟踪误报，没有办法统计员工提交内部工单覆盖错误封禁等情况；在元层面上，有一些机制可以减少漏报率（例如，有人看到坏内容没有被捕捉到，然后添加一些东西来捕捉更多坏内容），但没有跟踪误报，实际上就没有减少误报率的机制。这个元系统导致我认识的人中有超过10%的人被错误地暂停或封禁，这并不奇怪。而且，正如帕特里克·麦肯齐所说，误报的最佳率不是零。但当工程师持有“我们已经做了足够的研究，误报是不可能的”这种态度时，误报率基本上保证会高于最佳水平。当你将其与正常大公司的支持水平相结合时，这就是卡夫卡式用户体验的配方。

还有一次，我评论Uber的内容审核政策变更似乎可能导致误报封禁。一位Uber技术主管立即批评我，说我做出了毫无根据的假设，Uber工程师非常努力地确保没有误报封禁，有广泛的审查来确保封禁是有效的，事实上，我担心的误报封禁永远不会发生。然后我就因为反欺诈系统中的误报而被有效地封禁了。当Uber错误地封禁了一位司机，该司机不得不将他们告上法庭以获取被封禁的原因，在这时Uber才真正调查（而不是只回复申诉并声称他们已经调查过了），我回想起那件事。之后，Uber回应媒体询问时说：

我们对法院未能认可我们制定的健全流程感到失望，包括在因涉嫌欺诈而对司机账户进行停用决定时进行有意义的人工审查。

当然，在那位司机的案例中，没有健全的审查流程，我的案例也没有健全的申诉流程。当我联系支持人员时，他们并没有真正阅读我的消息，做了一些更改，使我的账户比之前更糟。幸运的是，我有足够的Twitter粉丝，一些Uber工程师看到了我关于这个问题的推文，并让我解除了封禁，但这不是大多数人可用的选择，导致像这个针对Google员工的Facebook广告这样的怪事发生，有人绝望地寻求帮助解决他们的Google账户问题。

即使你认识内部人员，也不总是能轻易解决问题，因为即使公司的效率没有随着规模扩大而提高，系统的复杂性确实增加了。一个很好的例子是Gergely Orosz的故事，关于支付团队经理离开Uber后，如何因某些难以理解的ML反欺诈算法决定这位前支付团队经理在进行支付欺诈而被Uber封禁。花了六个月的时间试图解决问题来缓解问题。而且，顺便说一句，他们从未弄清楚发生了什么并修复根本问题；相反，他们将这位前支付团队经理加入了一个特殊白名单，没有为任何其他用户解决问题，并且，大概，严重减少或甚至完全移除了该前经理账户的支付欺诈保护。

毫无疑问，如果问题容易解决，他们会修复根本问题，但随着公司规模扩大，他们会产生技术和非技术性的官僚主义，使系统即使对员工来说也不透明。

另一个例子是，在一家有排名社交feed的公司，通过添加诸如timeline_injection:false、interstitial_ad_op_out等过滤器来删除你不想在排名feed中看到的东西的想法会病毒式传播。第一次发生这种情况时，许多工程师调查后认为病毒式传播的技巧不起作用。他们并不完全确定，并且依赖于诸如“没有人记得曾经实施过这样的系统”和“如果你在代码库中搜索这些字符串，它们没有出现”以及“我们查看了可能这样做的系统，它们似乎没有这样做”的想法。他们对这个技巧不起作用有中等程度的信心，但没有人敢确定地说这个技巧不起作用，因为正如在所有大公司一样，系统的整体行为超出了人类的理解范围，甚至那些可以理解的部分也常常因为其他优先级而不被理解。

几个月后，这个技巧再次病毒式传播，人们通常被指引去查看上次的调查结果，只是有一个人实际尝试了这个技巧并报告说它有效。他们写了一条关于这个技巧对他们有效的Slack消息，但几乎没有人在意那个尝试复制技巧并发现它有效的人。后来，当这个技巧再次病毒式传播时，人们会指出关于人们认为这个技巧不起作用的讨论，而这条说它似乎有效的消息（几乎肯定不是用户认为的机制，而是因为长的过滤器列表导致超时，或类似的原因）基本上被遗失了，因为信息太多读不过来。

在我的社交圈里，许多人都读过詹姆斯·斯科特的《国家的视角》，其副标题是“改善人类世界的某些计划是如何失败的”。这本书的一个关键概念是“可读性”，即国家能看到的东西，以及这如何扭曲国家的行为。人们很容易写出一本高度类似的书，名为《像科技公司一样看待》，关于那些规模扩大的公司在至少是目前公司运营方式下，哪些东西是不可读的。一个简单的例子是，在许多视频游戏中，包括由价值3万亿美元的公司旗下的游戏工作室制作的游戏，通过让一群人举报某个账户行为不端，很容易让某人被暂停或封禁。对公司来说可读的是举报率，而不可读的是玩家的实际行为（它本可以是可读的，但公司选择没有足够的人或足够熟练的人来检查实际行为）；许多人在社交媒体公司也报告了类似的封禁。当涉及到反欺诈系统时，对公司来说可读的东西往往对人类来说相当不可读，即使是从事反欺诈系统工作的人员自己也是如此。

尽管他不是专门谈论反欺诈系统，但在一次特别主事官听证会上，Facebook的一位总监尤金·扎拉沙（Eugene Zarashaw）做出了这番评论，说明了Facebook自身系统的不可读性：

这可能需要广告团队的多个团队才能追踪到确切的数据流向。如果真的能有一个人能明确回答那个狭隘的问题，我会感到惊讶。

Facebook因为这个声明被不公平地（而且大部分是无知地）大肆批评（我们将在附录中讨论这个），但一般来说，理解像Facebook这样规模的系统是如何运作的确实很困难。

原则上，公司可以通过让薪酬尚可的支持人员调查那些可能是具有严重后果的边缘情况问题来增强其深奥系统的可读性，在这些问题中，系统“误解”了正在发生的事情，但在实践中，公司支付给这些支持人员的报酬极低，雇佣了真正不理解情况的人，然后给他们指示，确保他们通常无法成功解决可读性问题。

有一件事帮助不可读的力量在规模上占上风，那就是作为这些大公司的高薪员工，很容易看着外面的数百万或数十亿人（和机器人），把他们所有人都看作数字。俗话说，“一个人的死亡是悲剧。一百万人的死亡是统计数据”，正如我们注意到的，工程师经常将“几乎所有X都是欺诈”这样的想法转变为“所有X都是欺诈，所以我们不妨直接封禁所有做X的人，不听取申诉”。现代科技公司寻找可扩展解决方案的文化，即使在同等规模下，也使其比其他行业更糟，而且科技公司还拥有前所未有的规模。

例如，当有人指出FB广告管理器声称你可以在美国18-34岁人群中投放可能覆盖1.01亿人的广告，而美国人口普查显示18-34岁总人口为7600万时，广告定向团队的前产品经理回应道：

从FB规模思考

并解释说你不能指望在美国18-34岁人口这样的人口统计上进行“切分”查询在“FB规模”下起作用。谷歌内部有一个讽刺用的梗，在这种情况下，人们会说“我不会数那么低的数”。这位FB广告前产品经理是在非讽刺地说，FB不会数像1亿这样低的数。FB不仅不关心任何个人用户（除非他们是名人），这位产品经理声称他们甚至懒得关心1亿人这样的群体是否被准确追踪。

回到糟糕支持的后果，一个常见的回应是听到有人因这些巨型服务而被错误封禁后说“很好！你为什么想用Uber/亚马逊/之类的？它们很糟糕，没人应该用它们。”我不同意这种推理。首先，为什么你要替那个人决定他们是否应该使用某个服务或什么对他们好？其次（这是一个足够大的话题，应该单独写一篇文章，所以我只是简单提一下并链接到@whitequark的这篇更长的评论），许多人认为不必要的便利而应该放弃的大多数服务，实际上对相当多的人（绝对数量，不一定是百分比）来说是严重的无障碍性问题。当我们谈到小企业时，这些人通常可以换到另一家企业，但像Uber和亚马逊这样的服务，有时没有替代品，或者只有一家提供类似便利性的替代品，当只有一家时，由于某些随机系统误判而被封禁，也可能发生在另一家服务上。例如，针对许多人评论说你应该直接申请拒付并从DoorDash被封禁，当他们没有送达时，一位残疾用户回应道：

我是残疾人。没有驾照或汽车。我公寓附近没有公交车站，我实际上乘坐辅助客运系统去上班，但我必须提前一天计划。Uber也做同样的事情，所以我不得不根据谁有优惠券且最近没有偷我的钱，在Uber、DoorDash和GrubHub之间轮换使用。不是每个人都能自己去取东西。

此外，当谈论这类问题时，参与通常不是自愿的，比如这个将人们错误关进监狱的富士通错误。

关于第三个问题，即让人们就什么是垃圾信息、欺诈和其他不允许的内容达成一致是不可能的，我们在这里详细讨论过。我们看到，即使在一个简单、无争议、单一规则的微不足道情况下，人们也无法就什么是允许的达成一致。而且，当你增加更多规则或添加有争议的话题或扩大人数规模时，就更难就应该允许什么达成一致了。

总结一下，我们考察了三个领域，其中规模不经济导致内容审核、支持、反欺诈和反垃圾信息随着公司变大而变差。第一个是，即使在存在广泛共识认为某事是坏的情况下，例如欺诈/诈骗/钓鱼网站和搜索，拥有最复杂机器学习的最大公司实际上无法跟上一个（尽管非常熟练的）在小型搜索引擎上工作的人。如果诈骗分子针对最大的平台，回报会高得多，导致反垃圾/反欺诈等问题变得极其非线性地困难。

为了了解规模上的差异，HN“地狱封禁”发布垃圾信息和发表某些类型恶毒评论的用户。大多数垃圾信息发布者似乎没有意识到他们被地狱封禁了，会继续发布一段时间，所以如果你在登录状态下浏览“最新”（提交）页面，你会看到这些地狱封禁用户发布的稳定的一串被自动删除的故事。虽然有相当多，但比例通常远低于一半。当我们看像2017年的Twitter这样的“中型”大科技公司时，根据公开数据，如果垃圾信息机器人被地狱封禁而不是删除，垃圾信息将如此普遍，以至于如果你能看到它，你所能看到的只有垃圾信息。而且，作为大公司来说，2017年的Twitter并不算大。正如我们也注意到的，FB广告定向的前产品经理解释说，像1亿这样小的数字都在“我不会数那么低的数”的范围内，太小了，不值得关心；对他来说，基本上就是一个舍入误差。对于像FB或谷歌这样的公司来说，非线性差异的难度要糟糕得多。这些问题是非线性困难的，显然超过了扎克伯格和其他科技高管想要吹嘘的任何ML或AI技术。

在国会作证时，你会看到高管用类似“我们能以95%的准确率识别X”这样的言论来为这些系统在规模上的有效性辩护，这个说法在技术上可能是正确的，但似乎旨在故意误导被认为数学不好的观众。如果你以个人规模为参考，95%听起来可能相当好。即使对于HN规模这样的东西，95%准确的垃圾信息检测如果导致立即封禁可能还过得去。无论如何，即使它不是很好，被错误封禁的人可以直接给Dan Gackle发邮件，他会解封他们。正如我们在看数字时指出的，在Twitter规模上达到95%准确的检测会很糟糕（而且，确实，我收到的大多数DM都是明显的垃圾信息）。你要么退缩，只在你非常有信心的情况下封禁用户，要么你不会太久就封禁你所有的用户，而且正如公司喜欢处理支持的方式，申诉意味着你会收到一条回复，说“你的案件经过仔细审查，我们确定你违反了我们的政策。这是最终的”，即使对于任何一种粗略审查都会导致封禁被撤销的情况，比如当你封禁一个冒充自己的用户时。然后在FB的规模上，情况更糟，你会更快地封禁所有用户，然后你就退缩了，我们最终得到像每天有10万未成年人暴露于“成年人生殖器照片或其他性虐待内容”这样的事情。

我们考察的第二个领域是支持，它往往随着公司变大而变差。在高层面上，可以说公司并不关心提供良好的支持（亚马逊在这里是一个例外，特别是AWS，即使在消费者方面也是如此）。在系统内部，有些个体是关心的，但如果你看看支持与增长甚至有趣/有声望的项目相比投入的资源比例，支持是一个事后的想法。当DeepMind正在训练一个星际争霸AI时，Alphabet可能在玩星际争霸上花的钱比在支持代理上还多（如果没有，只需再加上一两个大型AI训练项目就可以了，特别是如果包括定制硬件等的摊销成本）。

很容易看出大公司有多不关心。你只需要联系支持，与每小时赚1美元、用他们勉强懂的语言回复你、试图通过照着流程图走来帮助解决他们不理解的问题的人取得联系，或者申诉一个问题并被告知“经过仔细审查，我们确定你[做了与你实际做的相反的事情]”。在某些情况下，你甚至不需要走到那一步，比如当按照Instagram的支持说明操作会导致一个把你带回起点的无限循环，而“如果这不是你，请点击这里”的链接返回404。我遇到过一次像这样的无限循环，和Verizon一起，它至少持续了六个月。我之后没有检查，但我敢打赌它持续了几年。如果你的引导或注册页面有这样一个问题，那会被认为是一个严重的错误，人们应该优先处理，因为它影响增长。但对于像因诈骗分子接管账户导致的账户丢失这样的问题，可能要几个月或几年后才会修复。或者也许不会。

如果你曾经和真正关心支持的人交谈，你立即就能明显看出他们的运作方式与典型的大科技公司支持完全不同，无论是流程还是文化。另一个可以看出大公司不关心支持的方式是，有多少从未研究过支持如何做或可以如何做的大公司员工和高管会告诉你，做得更好是不可能的。

当你与那些确实关心这一点的公司的支持人员交谈时，很明显可以做得更好。在我写这篇文章的时候，我实际上在一家支持做得相当好的公司（对于一家科技公司，按规模调整，我认为他们在99%分位数以上）做支持，包括接受支持人员的培训和入职流程。在规模上执行任何事情都是非平凡的，所以我不是在贬低他们的支持组织有多好，但最令我震惊的是，该组织的有效性自然源于关心为用户提供良好的支持体验。对此的完整讨论太长，无法在此包含，我们将在以后更详细地讨论这个，但一个例子是，当我们看大公司支持如何回应时，它通常旨在阻止用户回应（“此审查是最终的”）或者表面上向用户证明公司工作做得充分（“这不是纯粹的自动化过程，每个申诉都由人类在一个健全的流程中审查，该流程...”）。这家公司的培训指示你做标准大公司“请走开”风格和“我们做得很好，有一个健全的过程，因此投诉无效”风格回应的相反。对于你在支持中经常看到的每一种反模式，培训都告诉你做相反的事情，并讨论为什么反模式会导致糟糕的用户体验。此外，文化已经深刻吸收了这些想法（或者更确切地说，这些想法来自文化），并且有流程来确保人们真正理解提供良好支持意味着什么并付诸行动，支持人员有方法直接与正在实现产品的开发人员交谈等等。

如果人们关心做好支持，他们可以与那些擅长帮助用户的支持组织的人交谈，甚至在解释为什么不可能做得更好之前尝试在其中工作，但这通常不会发生。他们公司的支持组织领导层也可以这样做，或者像我一样直接在一个有效的支持组织中担任支持角色，但这并没有发生。如果你是一个愤世嫉俗者，这一切都说得通。就像愤世嫉俗者建议初级员工“大公司的人力资源不是来帮助你的；他们的工作是保护公司”一样，一个愤世嫉俗者可以令人信服地争辩说“大公司支持不是来帮助用户的；他们的工作是保护公司”，所以大公司当然不尝试理解那些擅长支持用户的公司是如何做支持的，因为那不是大公司支持的目的。

我们考察的第三个领域是人们无法就平台应如何运作达成一致是多么不可能，以及人们的偏见意味着人们没有理解这个问题有多困难。对美国人来说，一个突出的例子是左翼和右翼的阴谋论，每当某种错误导致任何类型的服务中断或封禁时，这些阴谋论就会冒出来。

在一条推文中，Ryan Greeberg开玩笑说：

来Twitter工作吧，你今天的bug可以成为明天的阴谋论！

在我的社交圈里，人们喜欢嘲笑所有在某个错误导致人们被错误封禁、网站无法加载等之后传播的荒谬的右翼阴谋论，或者当一些新的ML功能正确地拿下了一个巨大的诈骗/垃圾机器人网络时（这也会减少一些用户的关注者数量）。但当然，这并非右翼独有，左翼的意见领袖和政客们也会编造他们自己的阴谋论。

将这三者结合在一起，更差的问题检测、更差的支持，以及在政策上更难达成一致，我们最终得到了开头指出的情况：在我的Twitter关注者（主要是技术人员且通常技术相当精通）的民意调查中，只有2.6%的人认为最大的公司在内容审核和垃圾信息/欺诈过滤方面做得最好，所以花这么多时间反复强调这一点可能显得有点愚蠢。当你对美国普通人口进行抽样时，有更大比例的人表示他们相信阴谋论，比如疫苗会在你体内植入微型芯片，或者我们从未登上月球，而我不会花时间解释为什么疫苗实际上不会植入微型芯片，或者为什么我们认为我们登上了月球是合理的。一个也许合理的理由是，当“只有大公司能处理这些问题”的言论在非技术人员（如监管者、立法者和经常倾听然后复述胡说八道的高级政府顾问）中开始流行时，我一直在关注。也许下次你遇到一个外行告诉你只有最大的公司才可能处理这些问题时，你可以礼貌地指出技术人员中有着非常强烈的相反共识⁵。

如果你是创始人或早期初创公司，正在寻找身份验证解决方案，PropelAuth正在针对你的用例。虽然他们可以处理其他用例，但他们目前专门致力于让尚未投资身份验证解决方案的预发布初创公司生活更轻松。免责声明：我是投资者

感谢Gary Bernhardt、Peter Bhat Harkins、Laurence Tratt、Dan Gackle、Sophia Wisdom、David Turner、Yossi Kreinin、Justin Blank、Ben Cox、Horace He、@borzhemsky、Kevin Burke、Bert Muthalaly、Sasuke、anonymous、Zach Manson、Joachim Schipper、Tony D'Souza和@GL1zdA的评论/纠正/讨论。

（由于文章过长，附录部分未翻译）

由 mimo-v2.5 模型翻译，花费 106459 tokens

这个网站背后的想法是，让人们就平台应适用的审核规则达成一致非常困难。即使你采用一个更简单的例子，给定一条规则和一些解释规则的指示，问哪些车辆应被允许进入公园，然后问一组小问题，人们也无法达成一致。我自己做这个调查时，最初的反应之一是这些问题并不特别棘手，如果Dave想让它更具挑战性，他可以问许多边缘情况。然而，尽管调查并不特别具有挑战性，人们对这些问题并没有广泛的共识。

对调查的评论也表明了规则的另一个问题，即达成一致比人们想象的要难得多。如果你阅读lobsters、HN、reddit等网站上关于规则解释或审核的评论，当人们提出解决方案时，绝大多数人会提出任何做过审核或关注审核工作的人都知道行不通的建议，相当于"我周末就能搞定"的"审核版"¹。当然，我们在Dave的游戏中也看到了这一点。HN上最热门的评论，也就是最多人赞同的评论，以及在其他地方普遍存在的观点是²：

我着迷于这样一个事实：我的收获与作者的意图完全相反。

对我来说，所有问题的答案都一目了然。是的，你可以学术性地思考一个绕轨道运行的空间站是否是车辆，以及它是否在公园里，但标志牌的明显意图再清楚不过了。汽车、卡车、摩托车不被允许，而显然，警察和救护车（以及消防车）在执行公务时不必遵守标志牌。

所以，如果这旨在说明内容审核规则难以遵循，那么它恰恰达到了相反的效果。

有人附和地回复道：

确实如此。答案中存在明显的多数意见。

完成调查后，你会得到一个图表，显示每个人对每个问题回答“是”和“否”的数量，这就是“明显的多数”来源。首先，我认为说存在明显的多数意见并不正确。但即使假设有，也没有理由认为多数意见意味着大多数人与你意见一致，即使你每个问题都持多数立场。事实上，考虑到每个问题的多数意见图表看起来多么“摇摆不定”，如果每个问题的多数立场意味着大多数人同意你，或者存在大多数人都同意的一组立场，那将是非凡的。虽然你可以构建一个人工数据集使其成立，但在自然数据集中这将非常令人惊讶。

如果你查看数据（该数据在网站上不可用，但Dave在我询问时欣然提供），在我获取数据时，没有一组答案是大多数用户同意的，而且差距很大。我在HN发布链接后不久获取了这些数据，当时绝大多数响应来自HN读者，他们比一般人群更同质。尽管这些因素使得更容易找到共识，但最受欢迎的答案组合仅被11.7%的人选择。这就是顶级评论者所说“显而易见”的立场，但它不仅在只有11.7%的人同意、88.3%的人不同意的意义上是少数派立场，而且几乎没有人持有与这一所谓显而易见立场仅有微小分歧的立场。第二和第三最常见立场分别占8.5%和6.5%的投票，它们相似，仅在一个非功能性的二战时期坦克作为纪念物是否违反规则上有分歧。除此之外，大约1%的人持有第四、第五、第六和第七最流行立场，每个较不流行立场都少于1%的同意度，并且从那里相当迅速地下降。因此，27%的人发现自己与超过1%的其他用户意见一致（中位The request was rejected because it was considered high risk

由 mimo-v2.5 模型翻译，花费 6708 tokens

在通读了整份报告后，我认为Cruise的情况既比我看到的那些文章中描述的要好，也要更糟，这与我们在查看Twitter诉Musk案中的展品H和J、美国诉微软公司文件等实际来源时看到的模式相同；就像一些记者似乎亲马斯克/反马斯克、亲微软/反微软，并愿意为最大限度地抨击或开脱他们而推动不准确的叙事一样，我们在Cruise这里也看到了同样的现象。并且，正如我们在那些案例中所见，尽管一些文章似乎试图将Cruise描绘得尽可能好或尽可能坏，但报告本身的材料比最正面或最负面的故事所呈现的更有积极和消极之处。

除了纠正关于报告的误导性观点外，我发现这份报告有趣之处在于，在科技领域很少能看到如此详细、更不用说是公开的事故调查。我们通常在安全关键系统、有时在体育赛事以及历史事件中看到这类调查，但科技事件通常不会被如此报道。当然，公司会对事故进行事后分析，但你通常不会看到一份针对单个事件的200页报告，事后分析的重点也不会是这份报告的重点。过去，我们已经指出，通过研究安全关键系统的文献和事故报告可以学到很多东西，因此，对于这个比我们之前研究过的系统更接近科技领域的安全关键系统，当然也是如此。

这份报告的长度和深度反映了安全关键系统与“科技”文化之间的差异。报告中被描述为不可理喻的行为在科技界不仅是正常的，而且可能比你在大多数大型科技公司看到的更透明、更公开；我认为科技与安全关键系统之间的文化冲突也很有趣。我试图在报告中尽可能少地加入自己的个人观点，即使在那些因为了解科技公司或工程背景而我自己会写出不同内容的情况下也是如此。更多观点，请参见文末部分。

关于2023年10月2日旧金山事故致Cruise LLC、GM Cruise Holdings LLC及General Motors Holdings LLC董事会的报告

I. 引言

A. 概述

• 2023-10-24：加州DMV暂停了Cruise的无人驾驶许可证。
• 2023-10-02：一辆人类驾驶的日产汽车撞到一名行人，使行人进入一辆Cruise自动驾驶汽车（AV）的路径，随后该AV将行人拖拽了20英尺后才停止。
• DMV的指控：
  • Cruise未能披露AV在首次撞击后又向前移动。
  • Cruise播放的视频仅显示了部分事故，没有显示行人拖拽过程。
  • DMV是从另一个政府机构得知拖拽情况的，这“阻碍了其监管”。
• NHTSA和CPUC也对Cruise采取了行动，并提出了类似指控。
• 媒体也抱怨被Cruise误导。
• Cruise领导层以及与监管机构沟通的Cruise员工承认他们没有解释拖拽情况，但他们表示播放了完整视频，除了一个会议外，网络问题可能阻碍了监管机构看到整个事故过程。
• Cruise员工声称NHTSA在10-03会议后立即收到了完整视频，而CPUC拒绝了提供完整视频的提议。
• Cruise员工指出，他们在10-03向SF MTA、SFPD和SFFD播放了完整视频，没有网络问题，并与这些机构进行了充分讨论。
• Cruise领导层承认从未通知媒体，但领导层认为Cruise对媒体的义务不同于对监管机构的义务。

B. 审查范围

• [无注释]

C. 审查计划、方法论和局限性

• 审查了20.5万份“文件”，包括“电子邮件、短信、Slack通讯和Cruise内部文件”。
• 采访了88名现任和前任员工及承包商。
• 审查了第三方公司Exponent Inc.的一份报告。
• 仅进行内部审查；未采访监管机构和公共官员。
• 由于“个人情况和/或大规模裁员”，一些员工和承包商无法接受采访，但这些采访未被认为重要。
• 报告不涉及超出任务范围的更广泛问题，“例如Cruise AV及其运营的安全性或安全流程，这些问题更适于由具备工程和技术安全专业知识的人员评估”。

D. 主要发现和结论摘要

• 截至10-03早上，领导层和100多名员工都知道行人被Cruise AV拖拽了约20英尺，这是在AV停止后二次移动过程中发生的。
• 计划是通过播放完整视频来披露此事，“让‘视频自己说明情况’”。
  • Cruise假设监管机构和政府官员会提出问题，Cruise将提供更多信息。
• “证据权重”显示Cruise试图播放完整视频，但在3次会议中，网络问题导致无法播放，且Cruise未指出发生了行人拖拽。
• 在10-02和10-03，“Cruise领导层专注于纠正不准确的媒体报道”，即称Cruise的AV导致了事故。
  • 这导致Cruise向“媒体、监管机构和其他政府官员”传达了关于日产汽车的信息，并遗漏了关于事故的“其他重要信息”。
• “Cruise在此事件中失败的原因众多：领导不力、判断失误、缺乏协调、与监管机构‘我们对他们’的心态，以及对Cruise应向政府和公众承担的问责和透明义务的根本性误解。Cruise必须采取果断措施解决这些问题，以恢复信任和信誉。”
• “DMV暂停令是某些Cruise高级领导和员工典型的‘自作自受’的结果，这些人似乎没有完全理解受监管企业应如何与其监管机构互动……Cruise或其他任何企业采取认为导致严重伤害的事故视频就提供了所有必要信息，并因此无需主动、全面地向监管机构通报所有相关事实，这种方法从根本上是错误的。正如一名Cruise员工在就此事宜发给另一名员工的短信中所说，我们的‘领导辜负了我们’。”

II. 关于10月2日事故的事实

A. 关于Cruise业务运营的背景

• Cruise成立于2013年，2016年被通用汽车收购（通用汽车持股79%）。
• Cruise声明的目标：“负责任地部署世界上最先进的无人驾驶出行服务”。
• “Cruise声明的使命是让交通更清洁、更安全、更便捷”。
• 无人驾驶网约车业务于2021年9月在旧金山启动。
• 于2022年6月开始收费。
• 已扩展到其他地区，包括海外。
• 10-02事故是超过500万英里驾驶中首次发生的行人受伤事件。

B. 关于事故的关键事实

• 10-02, 晚上9:29：一辆人类驾驶的日产Sentra在旧金山Market街与第5街交叉口的人行横道上撞到行人。
• 行人无视红灯和“请勿通行”信号进入人行横道，然后在日产汽车车道上停下。警方报告引用了司机和行人违反法规，并得出结论称司机“负主要责任”。
• 撞击将行人抛入Cruise AV的路径。
• Cruise AV刹车但仍撞到了行人。
• 在完全停止后，AV移动以寻找安全地点停下，这被称为“‘最小风险状态’靠边停车操作（靠边停车操作）或‘二次移动’”。
• AV以最高7.7英里/小时的速度行驶了20英尺，拖拽着行人。
• 日产司机逃离现场（肇事逃逸）。

C. 关键事件时间线

• 10-02, 晚上9:29：事故发生，日产司机逃逸；AV传输低分辨率3秒视频（Offload 1）确认碰撞至Cruise远程协助中心。
• 晚上9:32：AV传输中分辨率14秒视频（Offload 2）显示碰撞，但不包括靠边停车操作和行人拖拽。
• 晚上9:33：急救人员在晚上9:33至9:38之间到达。
• 晚上9:40：SFFD使用重型救援工具将行人从AV下移出。
• 晚上9:49：Cruise事故响应团队将事故定为“Sev-1”（轻微碰撞）。团队在Google Meet上创建了一个虚拟“作战室”和一个专用的Slack频道（作战室Slack频道），约有20名员工加入。
• 晚上10:17：Cruise承包商到达事故现场。一名承包商拍摄了100多张照片和视频，并记录了地面上的血迹和皮肤碎片，表明AV从撞击点移动到了最终停止位置。
  • 另一名承包商在Cruise授权下，向SFPD提供了显示日产汽车的14秒视频。
• 晚上11:31：Cruise将事故升级为“Sev-0”，即“造成任何一方中度至重度伤害或死亡的重大车辆事故”。可能另有200名员工被召集至作战室。
• 10-03, 凌晨12:15：事故管理团队召开虚拟会议，分享事故更新并讨论媒体策略，以反驳称AV导致事故的文章。
• 凌晨12:45：Cruise政府事务团队联系政府官员。
• 凌晨12:53：Cruise发布新闻稿，指出日产汽车导致了事故。CEO Kyle Vogt和通讯副总裁Aaron McLear大量编辑了新闻声明。未提及靠边停车操作或拖拽；Cruise员工声称当时不知道这些事实。
• 凌晨1:30：AV返回Cruise设施，开始从AV下载碰撞报告数据，包括完整视频的过程。
• 凌晨2:14：包含靠边停车操作和拖拽的45秒事故视频可用，但直到4个多小时后所有AV数据处理完毕时，才没有Cruise员工收到其就绪通知。
• 凌晨3:21：应Cruise政府事务部要求，系统完整性总监Matt Wood制作了12秒事故视频，显示日产汽车撞到行人以及行人落在Cruise AV前方。视频在AV撞到行人前停止。
• 凌晨3:45：Wood在作战室Slack频道（当时有77名员工）发布了已知的首次关于靠边停车操作和行人拖拽的沟通。Wood称AV在首次碰撞后移动了1-2个车身长度。
• 早上6:00：Cruise举行虚拟危机管理团队（CMT）会议；讨论了行人拖拽。后续的Slack消息（6:17am, 6:25am, 6:56am）确认了关于靠边停车操作和拖拽的讨论。
• 早上6:28：Cruise在作战室Slack频道发布了显示靠边停车和拖拽的45秒9格视频（完整视频，offload 3）。
• 早上6:45：虚拟高级领导团队（SLT）会议；Vogt和McLear讨论是否向媒体分享完整视频或修改Cruise新闻声明，决定两者都不做。
• 早上7:25：Cruise政府事务员工发邮件给NHTSA并提议会面。
• 早上7:45：Cruise工程和安全团队举行初步会议，讨论碰撞和靠边停车操作。
• 早上9:05：Cruise的监管、法律和系统完整性员工为NHTSA简报举行预备会议；他们讨论了靠边停车和拖拽。
• 早上10:05：Wood和全球政府事务副总裁Prashanthi Raman与旧金山市长交通顾问举行虚拟会议。Wood播放了完整视频，“据报道因其家用电脑网络连接问题”；Wood和Raman均未提及或讨论靠边停车或拖拽。
• 早上10:30：与NHTSA的虚拟会议。Wood播放完整视频，“再次因网络连接问题导致视频在关键位置（包括首次撞击后）冻结或黑屏/白屏”，并且同样未提及或讨论靠边停车或拖拽。
• 早上10:35：Cruise工程和安全团队举行第二次会议讨论碰撞。
• 早上11:05：Cruise的监管、法律和系统完整性员工为DMV和加州公路巡警（CHP）简报举行预备会议；Cruise团队未讨论靠边停车和拖拽。
• 早上11:30：与DMV和CHP的混合现场和虚拟会议。Wood播放完整视频，同样因网络连接问题且未提及或讨论靠边停车或拖拽。
• 中午12:00：虚拟Cruise CMT会议；工程师展示发现结果，包括详细说明事故期间AV移动情况的图表。显示了AV如何撞到行人，然后再次向前移动，拖拽行人约20英尺。AV程序设定最多移动100英尺，但AV内部系统标记了一个车轮速度传感器故障，因为车轮以不同速度转动（一个车轮在行人腿上打滑），从而提前停止了车辆。
• 下午12:30：Cruise政府事务员工致电CPUC讨论10-02事故和视频。
• 下午12:40：Cruise虚拟SLT会议。展示了来自CMT会议的图表。Vogt、首席运营官Gil West、首席法务官Jeff Bleich及其他人员出席。安全和工程团队提出暂停车队运营直到部署修复方案的问题；Vogt和West否决了该想法。
• 下午1:40：完整视频上传至NHTSA。
• 下午2:37：Cruise向NHTSA提交1天报告；未提及靠边停车或拖拽。
• 下午3:30：Cruise与SF MTA、SFPD和SFFD举行虚拟会议。Wood“多次播放完整视频”，没有技术问题。Cruise未提及靠边停车操作或拖拽，但官员们看到了并就此询问了Cruise。
• 下午6:05：Cruise CMT会议。Vogt和West结束了Sev-0作战室。一些Cruise员工后来对此表示担忧。
• 10-05, 上午10:46：福布斯要求Cruise就AV拖拽事件发表评论。Cruise拒绝评论，并坚持10-03的新闻稿。
• 下午1:07：CPUC发出信息请求，回复截止日期为10-19。
• 10-06, 上午10:31：福布斯发表《Cruise机器人出租车在最近事故中拖拽女子20英尺，当地政客称》。
• 10-10, 下午4:00：DMV要求Cruise提供更完整的视频。Cruise当天回应，提议屏幕共享视频。
• 10-11, 上午11点：Cruise与DMV举行会议，讨论与事故无关的运营问题。DMV的视频请求被“简要讨论”。
• 下午12:48pm：Cruise律师助理在检查更新后向NHTSA提交10天报告。报告未提及靠边停车或拖拽，“因为没有人告诉律师助理需要添加这些事实”。
• 10-12, 下午3点：NHTSA通知Cruise，打算对10-02事故及其他3起行人相关事件进行初步评估（PE）。
• 10-13, 上午10点：Cruise与DMV和CHP会面，分享9分6格视频，DMV澄清需要45秒9格视频（“完整视频”）。
• 下午12:19：Cruise上传完整视频。
• 下午1:30：Cruise与NHTSA会面，认为PE没有必要。
• 10-16, 上午11:30：Cruise与DMV和CHP会面，后者表示不认为在10-03会议上看到过完整视频。
• 10-16：NHTSA正式启动PE。
• 10-18, 下午3:00：Cruise与CPUC举行定期月度会议。Cruise表示将满足CPUC的10-19截止日期。
• 10-19, 下午1:40：Cruise应10-05的请求提供了信息和完整视频。
• 10-23, 下午2:35：Cruise获悉DMV可能暂停其无人驾驶许可证。
• 10-24, 上午10:28：DMV发布暂停Cruise无人驾驶许可证的命令。除少数在10-23听到消息的员工外，Cruise员工感到惊讶。
• 上午10:49am：Cruise发布博客文章，声明：“事故后不久，我们的团队主动向加州机动车辆管理局（DMV）、加州公共事业委员会[原文如此]（CPUC）和国家公路交通安全管理局（NHTSA）提供了信息，包括完整视频，并一直与监管机构保持密切联系以回答他们的问题。”
• 11-02, 中午12:03：Cruise提交30天NHTSA报告，其中包括对靠边停车和拖拽的讨论。
• 11-02：Cruise因10-02事故召回950个系统。
• 12-01：CPUC发布“要求说明原因令”，指其“未能提供完整信息，并就2023年10月2日Cruise相关事故及其后续与委员会的互动发表了误导性公开评论”。

由 mimo-v2.5 模型翻译，花费 36460 tokens

当某人在Mastodon/Twitter/Threads等平台发布热门内容时，你常会看到一类评论，比如在视频下也常见“为何发推特串？这更适合作为博客文章”或“为何做视频？这更适合作为博客文章”。但这类评论往往措辞更激烈，例如：

我读不了那些跨页的推文，因为发帖者每条回复只写5个词。我觉得普通互联网完全愚蠢：Twitter、tiktok、Instagram等等。这完全是浪费精力。

或

当有人选择在推特上写博客，你就知道这内容顶多是浅薄的，更可能纯粹是愚蠢的（比如这个案例）

这类评论相当常见，例如：我查看了Foone在HN上得分200以上的最近10个推特串，其中9个都有类似抱怨使用推特的评论。

人们常表示困惑，为何有人会选择使用[差平台]，例如“为了表达观点，这得发多少条推文？200条？没人想过‘这内容要是放在一个页面上会更连贯’？我不懂社交媒体”或“拜托，输入简短描述并上传100张图片，会比一次性写完所有内容再添加些连接词更容易？……客观来说这工作量更大”。

就个人而言，我并不喜欢视频形式，对于95%的YouTube视频，我宁愿以博客文章而非视频形式获取信息（如果Google真的严打广告屏蔽，这点会更明显），而且我认为，对于关注信息的读者来说，长篇博客文章基本上优于在[差平台]上的长推文串。但我也认识到，如果不存在[差平台]这类工具，许多我想读的内容根本不会出现。

退一步看大局，我见过人们使用[差平台]主要有四个原因：它能获得更多互动、那里有他们的朋友、摩擦更低，以及变现更容易。

互动

互动原因最简单，所以我们先看这个。仅从人们花费时间的平台来看，推特、Instagram等短形式平台完全主导了Medium、Blogspot等长形式平台；这可以从这些公司的估值、调查数据等方面看出。Substack是当前最热门的长形式内容平台，其最新估值约为6亿美元，相比短形式平台的价值基本是个舍入误差（我不包括Wordpress或Squarespace等，其价值很大一部分来自文章和帖子之外的东西）。资金正流向人群，而人群已大多从长形式内容迁移。如果与使用Substack的人交流其读者和增长来源，你会发现这来自推特等平台，因此，即使优化互动或收入的长形式内容创作者仍会产出大量短形式内容¹。

朋友

朋友原因可能是次简单的。许多人会使用周围人都在用的平台。现实中，如果我年轻十岁，在2023年而非2013年开始做网络内容，我很可能会先尝试直播再尝试博客。但作为年长、脱节的人，即使知道博客相对视频是衰退媒介，我还是在2013年尝试开了博客。这似乎对我效果不错，所以我坚持下来，但这似乎是代际问题。虽然有比我年长的人做视频，也有比我年轻的人写博客，但从年龄分布看，我离人们普遍转向视频的年龄并不远，如果我真的计划长期做，而非仅仅做开始时最低摩擦的事，我会从视频开始。今天，对于刚开始分享想法的人来说，做视频是很自然的。

摩擦

当[差平台]是推特、Mastodon、Threads等微博平台时，朋友原因通常仍适用——这些平台上的用户常属于他们互动的社区，对他们来说，将内容保留在充满社区成员的平台比放到别处更合理。但对于内容被广泛阅读的人来说，更大的原因是许多人发现这些平台比写博客摩擦小得多。当人们指出这点时，[差平台]的讨厌者常感到困惑，回应如：

拜托，输入简短描述并上传100张图片，会比一次性写完所有内容再添加些连接词更容易？……客观来说这工作量更大

一方面，我接触的大多数广受欢迎的程序员/科技博主实际上使用摩擦更高的平台（例如Jekyll的摩擦和Hugo的摩擦）。但原则上，他们可以使用Substack、托管的WordPress或此评论者认为“客观”更低摩擦的平台，但这根本误解了摩擦的来源。当人们说[差平台]摩擦更低时，通常指写作和发布某物的心理障碍，而非实际发布所需的点击次数。我们可以争论这是否理性，是否“客观”合理，但最终，许多人发现在短文本块而非单个大文本块的平台上写作，在心理上更容易，这是简单事实。

我有时在Mastodon上写东西，因为我觉得对某些内容它适合做平台。当然，既然问题不在于点击次数，而是某种潜在情感动机，其他人有不同原因。例如，Foone说：

不是自夸或别的，但我在Hackernews或Reddit上被转发时最喜欢的部分是，每次总有一个高赞回复说“天哪，这本可以是一篇博客文章！为什么写20条推文，而不是一篇博客文章？”

因为我写不了博客文章，该死的。 我有注意力缺陷多动障碍。很严重的那种，正在治疗，但治疗效果不太好。 我无法专注于写博客文章。这不会发生的

如果我尝试写博客文章，最终会半途而废，因为我无法将其编辑成可读和可发布的状态。所以如果我完全转向博客： 你会得到：没有内容 我会得到：大量未完成的草稿和一种自己是无用废物的感觉

但我能做冗长的推文串。它们不需要长时间高度集中，没有我写博客文章时没完没了的编辑，我能做到。我做了很多！它们只是冗长且在推特上，有些人不喜欢

Foone提到的问题甚至并不罕见——我最喜欢的三位博主中，有三位提到他们只能一口气写完东西，要么有足够的势头写完一整篇博客文章，要么就写不完。只能一次写一条推文与只能在一次写作中完成你能写的内容之间存在规模差异，但这些是程度上的差异，而非本质上的差异。

收入

无论什么原因让人们觉得[差平台]比[好平台]摩擦更低，让人们使用适合自己的平台意味着我们获得更多内容。对于视频，同样的情况也适用，因为视频变现比文字好得多，而且有很多内容在视频上能很好变现，在文字形式上可能就不行。

举个随意的例子，汽车内容就是这样一个领域。例如，如果你买车，想了解汽车的详细实用评测，以及与其他可能考虑的车型的比较，在YouTube出现之前，据我所知，没人做过接近Alex Dykes在Alex on Autos上做的深度的内容。如果你翻开鼎盛时期的汽车杂志，比如1997年的Car and Driver或Road and Track，没有任何内容达到Alex做的1/10深度，即使到今天，现代汽车杂志也如此。许多汽车内容的子类别也是如此，例如Jonathan Benson在Tyre Reviews上的内容。在Jonathan之前，没人以同样广度和深度测试轮胎并撰写报告（轮胎公司的工程师做过这类测试甚至更多，但你必须直接与他们交谈才能获得信息）²。你可以在许多汽车内容之外的领域找到类似模式。虽然这取决于领域，但在许多情况下，如果没有视频，内容根本不会存在。总的来说，人们不仅比阅读文字更愿意看视频，而且视频变现比文字好得多，这使得人们能将提供深度信息作为职业，这在文字形式中是不可能的。在某些领域，你可以通过付费通讯赚不少钱，但这本质上就是汽车杂志，它们从未能支持类似Alex Dykes所做的内容，似乎也不合理支持Jonathan Benson在YouTube上的类似内容。

或者，从科技界举个例子，在Lucy Wang创建她的YouTube频道Tech With Lucy后不久，当她有5万订阅者，典型视频有几千到几万观看，偶尔有十万观看时，她指出她的收入超过了在AWS工作时（大部分钱可能来自赞助）。相比之下，我的博客文章都有超过一百万点击，我肯定赚不到Lucy在AWS赚的那么多；相反，我的博客勉强能付房租。如果你把大部分内容放在付费墙后面，可以适度地变现一些文字，例如Gergely Orosz在他的通讯中这样做，但如果你想大部分或完全发布免费内容，视频通常主导文字。

无结论

虽然我更喜欢在YouTube/Twitter/Threads/Mastodon等上看到的大多数内容托管在文字博客上，但现实是，如果必须将其写成长形式文字而非分段短形式文字或视频，大多数内容根本不会出现。也许几年后，摘要工具会变得足够好，我可以消费它们，但今天，我尝试过的所有工具经常严重错误传达关键细节，所以我们只能接受内容以创作的形式存在。

如果你正在找工作，Freshpaint正在招聘招聘人员、软件工程师和支持工程师。我是该公司的投资者，所以你应该带着通常的保留态度看待此事，但如果你想加入一个快速增长的早期创业公司，他们似乎找到了产品市场契合点，收入方面一直在极快增长。

感谢Heath Borders、Peter Bhat Harkins、James Young、Sophia Wisdom和David Kok的评论/修正/讨论。

附录：其他地方

• Paul Ford的WWIC（Why Wasn't I Consulted）是本文的更通用版本

以下是David Kok的评论，来自一位80岁桥牌玩家抱怨桥牌为何衰落的讨论，这位80岁玩家声称主要原因是智商下降，年轻人（指60岁以下的人）太蠢而无法玩桥牌这类智力游戏；许多其他玩家赞同：

与其说是关于年龄段的错误但有意义的陈述，我总是将“智商下降”这类话解释为“我不快乐且难以表达”，而当其他人同意时，他们其实也是在说“是的我也是”。

如果你将David Kok的评论改编到抱怨为何某内容不是博客文章的语境中，这是对我在本文中给出理由无关紧要的元原因（对某些人来说）——这些理由只对关心理由的人重要；如果某人只是发泄情绪，他们给出的理由是其感受的表达而非合理理由，那么人们不写博客文章的原因就无关紧要。

总之，“为何在那里而不是这里发布”是个常见话题，我确信其他人写过相关文章，我会很感兴趣。请随时将其他相关文章转发给我。

附录：HN上对Foone最近10个推特串的评论。

我查找了Foone最近在HN上得分200以上的推特串，10个中有9个都有抱怨Foone为何使用推特以及为何作为博客文章会更好的评论。[不包括形如“对于那些和我一样讨厌推文串的人：https://threadreaderapp.com/thread/1014267515696922624.html"的评论，这类评论比下面带抱怨但也有有用内容的评论更多，比如串的其他版本链接。]

永远不要相信看似正常工作的系统

最早的评论之一是抱怨它在推特上，不久之后就是

为了表达观点，这得发多少条推文？200条？没人想过“这内容要是放在一个页面上会更连贯”？我不懂社交媒体

总有一天外星人会降落，一切都会很好，直到我们解释我们的日历

这内容更适合写成短篇小说，但我离题了。

这种玩意儿太棒太有趣了，不应该在推特上[少数对此表示赞同的抱怨之一]

这人每次他们的内容被转发到这网站时都超级生气，总是发巨长的帖子，就像原发帖者一样刷屏，太搞笑了。

你想了解我们大脑有多疯狂和扯淡吗？

他们在推特上就能容忍阅读？

认真提问：为什么出版商把他们的博客文章分解成无数条推文？互动网页算法是否偏爱推文串中的推文数量？我看到这正成为更多趋势

这是一篇非常有趣的投稿。但是，推特的字符限制真有毒。

在我看来，Foone的网络存在是有害的。他们不是写一篇条理清晰的文章发布在博客上，然后在一条推文中总结指向该文章的链接，而是做了相反的事：写了数十条推文串，然后用一篇博客文章总结那些推文。这不是我想鼓励的网络趋势，但唉，它正在流行起来。

哦，我不在乎作者怎么写，也不在乎下面是否有图表关系（或其他任何东西）。只是推特让阅读这类内容的体验变得非常繁琐。

逆向工程Skifree

这应该是一篇博客或直播。

即使这种形式？

我真的不理解。对他们来说这样发布很麻烦，对我们来说这样阅读也很麻烦。我希望马斯克接管推特并把它搞垮，这样我们就能回到真正的博客文章。

有人指出Foone说过他们觉得写长形式内容不可能，只能写短形式媒体，对此回应如下：

拜托，输入简短描述并上传100张图片，会比一次性写完所有内容再添加些连接词更容易？

显然那是他们的权利，他们可以做任何想做的事，但客观来说这工作量更大，我真诚希望这趋势会消失。

所有带电池的设备都应该有开关

你忘了，foone不会从推文串转向长形式博客。[实际上是对人们总是抱怨这点的元评论，而非抱怨，我认为]

我读不了那些跨页的推文，因为发帖者每条回复只写5个词。我觉得普通互联网完全愚蠢：Twitter、tiktok、Instagram等等。这完全是浪费精力。

他显然知道[在推特上发长串]是个问题，他应该解决它。

有人指出Foone说过他们无法写长形式博客文章，那人回应：

你可以像推特那样逐步添加到博客文章。功能上是一样的，只是媒介不是线程层次结构。没必要像他说的那样必须完全写好才发布。

我自己的博客文章在发布后经常修改10次以上。

这对成千上万的人来说效果不好，这就是为什么总有抱怨……当某事次优时，你完全有权抱怨。将长篇抱怨作为推文串发布对消费者来说是次优的

我有点欣赏这个信号：当有人选择在推特上写博客，你就知道这内容顶多是浅薄的，更可能纯粹是愚蠢的（比如这个案例）

Covid检测试剂盒中有一个带蓝牙的ARM Cortex-M4芯片

令人惊讶，我没看到任何抱怨，尽管有一条评论被编辑为“.”。

拆解2010年Fisher Price重新发行的音乐盒唱片机

为什么这是推文串？为什么不是博客？

接着是

我喜欢完全没人理解这个笑话……Foone是个反社会者，觉得某些词不该用来指代Foone，因为他们不喜欢。事实上任何人都不该谈论Foone。

在Tumblr上发布时，E和W键突然失灵了

只是热键检测出错。这并不奇怪，因为在网站上实现热键完全是个雷区。我不认为你可以从中得出Tumblr写得很差的结论。可能只是测试不充分。

因为那条评论对读过链接的人来说毫无意义，有人问“你读完整个串了吗？”，评论者回应：

没有，因为推特让它完全不可读。

我的鼠标驱动程序请求防火墙例外

我们能禁止在这里发布推特吗？在所有界面点击时，都会弹出烦人的窗口。你可以关掉它，但它会撤销你的点击，所以任何导航都变得非常麻烦。

或者用某种推特转可读工具替换推特网址

毁灭公爵3D镜像宇宙

这很了不起，但推特是这类文字的糟糕媒介。我希望这是发布在正常平台上，这样我可以轻松分享。

如果这是一篇博客文章而不是一堆推文，我们就不用展开多个回复才能看到全部内容

呃为什么这不是博客或YouTube视频？ specifically to annoy foone

是的，长形式推特是烂透了。但foone很棒，也许它们互相抵消了？

我讨厌推特。它正在慢慢毁掉互联网。

非foone帖子

当然，这种现象并非Foone独有。例如，在我在HN上看到的最后一个推文串中，前五条评论中有两条是：

这家伙有博客吗？

和

这就是为什么“在X上发布某物”的答案应该是“直接拒绝”。不可能在那里说出任何有细微差别或需要背景才能理解的话，但不幸的是，被X迷住的人根本无法开始以别人可能的方式看待他们所做的事情。

我之所以查看Foone的串，是因为我知道他们倾向于发布短形式平台内容，查看10个Foone串比查看10个随机串更有趣。

由 mimo-v2.5 模型翻译，花费 14155 tokens

这里有一个有趣的实验可以尝试。以一个开源项目如yt-dlp为例，尝试使用一个非常通用的术语如“youtube downloader”来查找它。由于所有试图在该术语上排名第一的内容农场的存在，你将无法找到它。尽管yt-dlp很可能实际上才是你想要用来下载YouTube视频的工具。

更普遍地说，我联系的大多数技术界人士似乎都认为，谷歌搜索结果比十年前显著变差了（Mastodon投票，Twitter投票，Threads投票）。然而，有一大群直言不讳的人声称搜索结果仍然很棒。例如，一位在Bluesky上获得高参与度的意见领袖说：

我认为关于谷歌搜索现在变得多么糟糕的哀嚎有点被夸大了¹

我怀疑这里发生的情况是，一些人已经习惯了围绕糟糕的软件工作，以至于他们甚至不知道自己在这样做，条件反射地做着相当于在编辑器中始终按ctrl+s，或者在文本框中撰写任何内容时按ctrl+a; ctrl+c的现代等价物。每一个现代网络的熟练用户都有一套他们用来从查询中获得体面结果的技巧。从观察许多用户与计算机的互动来看，这似乎并不正常，即使在那些在机械工程等各种技术领域相当有竞争力的人中也是如此²。然而，也可能是那些抱怨搜索结果质量差的人只是赶上了“一切都糟糕”的潮流，并对搜索质量发表了完全无根据的评论。

既然尝试直接、简单的查询相当容易，让我们尝试一些查询。我们将用五种搜索引擎加上ChatGPT来查看三种查询，并且会关闭广告拦截器以获得非专家的浏览体验。我曾经因为浏览到一个有问题的广告网站而使计算机被入侵，所以我希望这种情况不会在这里发生（在那次事件中，我很幸运能发现，因为恶意软件在我的计算机上做了太多事情，不可能不被注意到）。

一种查询是我的一个朋友为设置新电脑而使用的一组有代表性的查询。我的朋友是一位非技术领域高度能干的工程师，她想学习“如何使用计算机”，所以我观察了她设置电脑的过程，并指出了她在与网站和软件互动的思维模型中存在的漏洞³。

第二种查询是我在高中时想知道的那些事情的查询，当时我找不到答案，因为我问的所有人（老师等）都给了我明显错误的答案，而我不知道如何找到正确答案。一旦我上了大学并可以访问大学图书馆，我就能够从各种教科书中得到正确答案，但这些问题很简单，高中生理应能理解答案；这只是找到答案的问题，所以我们来看看这些答案有多容易找到。第三种查询是在撰写本文时我恰好想获取的本地信息查询。

在对查询进行评分时，会有一些主观性，因为，例如，是具有中等相关性但没有诈骗的结果更好，还是非常相关但混杂着试图安装恶意软件或诱骗你交出信用卡信息来支付你本不该支付的东西的诈骗结果更好，这并不客观明确。在本文中，我将诈骗视为相当糟糕，所以在那个特定例子中，我会将中等相关性的结果评为高于混有诈骗的高相关性结果。与我其他篇有某种主观排名的文章一样，这里既有简短的总结，也有结果的详细描述，以便您自己可以对服务进行排名。

在下表中，每一列是一个查询，每一行是一个搜索引擎或ChatGPT。结果按（从最差到最佳）极差、很差、差、一般、好和优秀评级，较差的结果更红，较好的结果更蓝。

查询是：

• download youtube videos
• ad blocker
• download firefox
• Why do wider tires have better grip?
• Why do they keep making cpu transistors smaller?
• vancouver snow forecast winter 2023

Marginalia表现相对较好，有时提供尚可但不完美的答案，然后对它无法回答的问题不提供答案或提供非常明显的无关答案，诈骗率也相对较低，低于任何其他搜索引擎（尽管对于这些查询，ChatGPT返回零诈骗，而Marginalia返回一些）。

有趣的是，Mwmbl允许用户直接编辑搜索结果排名。我对一个查询进行了编辑，如果按编辑后的标准评分，它将得“优秀”，但在基准测试中专门为基准优化时，很容易取得好成绩，因此Mwmbl的分数是在我编辑排名标准之前计算的。

我发现Google结果中有趣的一点是，除了众所周知的倾向返回近期结果外，还有强烈的倾向返回近期的YouTube视频。这导致我们得到的视频对任何人来说似乎都毫无用处，除了视频的制作者，他们似乎试图从视频中获得广告收入。例如，搜索“ad blocker”时，一个YouTube结果显示一个人漫无边际地讲了93秒关于你应该使用广告拦截器的话，然后谷歌搜索“ad blocker extension”。然后他们点击第一个结果并错误地说“它正式来自谷歌”，即该广告拦截器要么是谷歌制造的，要么有某种官方谷歌认证，因为它是第一个结果。然后他们又漫无边际地讲了40秒，同时安装了广告拦截器。安装后，他们错误地陈述“这基本上是Google Chrome上最有效的广告拦截器之一”。这个视频有14k次观看。作为参考，Steve Yegge花了一年时间制作高质量视频，他最受欢迎的视频有8k次观看，典型的观看次数低于2k。这个通过制作他们一无所知的话题的低质量视频来玩弄算法的人，是利用谷歌算法优先考虑近期内容而不顾质量的小型产业的一部分，正在压倒Steve Yegge的视频，因为他们找到了可以排上名的搜索词。我们将在下面更详细地讨论其他谷歌怪癖。

ChatGPT做着它惯常的事情，在一个案例中显著超越了它更传统的竞争对手，在另一个案例中做得还可以，在另一个案例中拒绝真正回答问题，并在多个查询中“产生幻觉”胡言乱语（像ChatGPT一样，随机扰动可以显著改变结果⁴）。批评ChatGPT的幻觉很常见，虽然我认为这并不过分，但正如我们在2015年这篇关于人工智能的LLM前文章中指出的那样，我认为这类批评被高估了，因为人类和传统计算机系统犯的是完全相同的错误。

在这种情况下，搜索引擎返回各种幻觉结果。在降雪预测的例子中，我们得到了故意伪造的结果，一个旨在通过虚假预报网站上的阴暗广告获得广告收入，另一个旨在诱骗用户认为预报显示的是寒冷、多雪的冬季（与实际预报相反），似乎是为了让用户注册不必要的铲雪服务。其他故意伪造的结果包括一个网站，它看起来像一个客观的评论网站，实际上是一个假网站，旨在将你引导安装特定的广告拦截器，其中他们引导你安装的广告拦截器似乎是一个诈骗广告拦截器，试图让你为广告拦截付费并且不允许你取消订阅，一个试图让你安装一个将你所有购物信息暴露给某个服务的chrome扩展程序的虚假“有机”博客文章（在许多情况下，无法判断博客文章是假的还是推销的，但在这种情况下，他们将虚假博客文章托管在产品的域名上，尽管它被设计成看起来有整个博客的主题，但实际上并没有——只有这篇虚假的博客文章），等等。

还有许多结果似乎不是故意欺诈，只是普通的SEO垃圾，旨在通过广告点击获利。这些网站大多早于LLM，所以它们读起来不完全像ChatGPT幻觉，但本质上没有不同。有时这些网站的目标是诱骗用户点击实际上会诈骗用户的广告，有时目标似乎是生成非诈骗广告的点击。搜索引擎也返回了许多看似非故意的人类幻觉，人们在用户内容突出显示的地方自信地陈述错误答案，如quora、reddit和stack exchange。

在这些查询中，即使忽略任何看起来像LLM生成的文本，我也会将主要搜索引擎（Google和Bing）评为在返回各种幻觉或准幻觉结果方面略逊于ChatGPT。虽然我认为关于LLM幻觉的担忧并非不合理，但传统生态系统的问题在于，系统高度激励将对软件供应链最有利的东西放在用户面前，而这通常与最佳结果截然不同。

例如，如果你的应用商店允许“你可能还喜欢”的推荐，赌博成瘾管理应用最值钱的广告位将是赌博应用。在成瘾管理应用上允许赌博广告对于今天任何一家公司来说都过于公然地敌视用户，但当然，制作赌博应用的公司会试图破坏系统来突破过滤，他们有时成功了。对于网络搜索，我刚刚又在网上尝试了一下，两大搜索引擎之一返回的顶部结果是广告充斥的SEO博客垃圾，用于成瘾管理。页面顶部是一个多部分广告，前两个链接是“支付真钱的游戏”和“支付真现金的游戏”。通常，我得到的是本地化结果（因为我在加拿大，有很多.ca域名），所以你自己尝试时可能会得到有些不同的结果。

同样，如果最佳结果是一个好的、免费的广告拦截器，如ublock origin，那么对于一个制作广告拦截器的公司来说，顶部的广告位价值要高得多，这个广告拦截器旨在诱骗你为一个质量较低的广告拦截器付费，该拦截器有一个几乎无法取消的订阅，所以诈骗广告拦截器会出价高于免费广告拦截器来争夺顶部广告位。这类公司也有更多的资源用于直接SEO，以及间接的SEO活动，如营销，因此，除非搜索引擎投入更有效的努力来对抗利润动机，否则顶部结果将归付费广告拦截器所有，尽管付费广告拦截器通常对用户来说明显比免费广告拦截器差。如果你和从事排名工作的人交谈，许多最大的排名信号来自点击和参与度，但这只有在用户足够老练，知道什么是最佳结果时，才会推动用户找到最佳结果，而通常他们并非如此。人类评分员也会评估页面质量，但这存在完全相同的问题。

许多谷歌员工曾告诉我，广告实际上是好的，因为它们向用户介绍了用户原本不会知道的选项，但任何尝试在没有广告拦截器的情况下浏览的人都会看到各种误导性的广告，试图通过假装是一个窗口或在页面顶部宣传“支付真现金的游戏”等方式诱骗或陷害用户，该页面是关于对抗赌博成瘾的，并且已经通过SEO自己获得了赌博成瘾搜索的高排名。原则上，这些问题可以通过足够的资源来缓解，但我们可以观察到，万亿美元级别的公司选择不投入足够的资源来打击SEO、垃圾邮件等，以至于这类诈骗广告很少被看到。相反，一些顶级结果实际上是将你引向诈骗的广告。

在最初的Page Rank论文中，谢尔盖·布林和拉里·佩奇指出，基于广告的搜索本质上与提供优质结果不一致：

目前，商业搜索引擎的主要商业模式是广告。广告商业模式的目标并不总是与为用户提供高质量搜索相对应。例如，在我们的原型搜索引擎中，手机相关的顶级结果之一是“手机使用对驾驶员注意力的影响”，这是一项详细解释在开车时使用手机交谈的分心和风险的研究。这个搜索结果之所以排在第一位，是因为它被PageRank算法评估为高度重要，PageRank算法是对网络引用重要性的近似估算[Page, 98]。显然，一个为展示手机广告而收费的搜索引擎将很难向其付费广告商证明我们的系统返回的页面是合理的。出于这类原因以及其他媒体的历史经验[Bagdikian 83]，我们预计广告资助的搜索引擎将固有地偏向广告商，远离消费者的需求。

即使对于专家来说，评估搜索引擎也非常困难，因此搜索引擎的偏见特别隐蔽。一个很好的例子是OpenText，据报道它出售公司被列在特定查询搜索结果顶部的权利[Marchiori 97]。这种类型的偏见比广告更隐蔽，因为不清楚谁“应得”在那里，以及谁愿意付费被列入。这种商业模式引起了轩然大波，OpenText已经不再是一个可行的搜索引擎。但不太明显的偏见可能会被市场容忍。……这种类型的偏见很难检测，但仍可能对市场产生重大影响。此外，广告收入通常为提供低质量搜索结果提供了动机。例如，我们注意到一个主要搜索引擎在给出航空公司名称作为查询时不会返回该航空公司的主页。碰巧的是，该航空公司已经为其名称的查询投放了昂贵的广告。一个更好的搜索引擎将不需要这个广告，这可能会导致搜索引擎从航空公司那里损失收入。总的来说，从消费者的角度来看，搜索引擎越好，消费者为找到所需信息需要的广告就越少。这当然会侵蚀现有搜索引擎的广告支持商业模式……我们认为广告问题导致了足够的混合激励，因此拥有一个透明的、学术领域的竞争性搜索引擎至关重要。

当然，谷歌现在已被广告主导，尽管特别指出了用户将真实结果与付费结果混为一谈的阴险性，但谷歌和必应都让广告看起来越来越像真实的搜索结果，以至于大多数用户通常不知道他们点击的是广告而不是真实的搜索结果。顺便说一句，用户认为一切都是“自然”搜索结果的原因是，在本文中，结果按它们在页面上出现的顺序排列，所以如果有四个广告出现在第一个自然结果之上，四个广告将排名1-4，自然结果将排名5。我听谷歌员工说过，AMP不影响搜索排名，因为它“只”控制哪些结果进入搜索结果上方的“轮播图”，好像在结果上方插入一个轮播图和一堆广告，将结果推到折叠线以下，对用户与结果的互动没有影响。也经常看到搜索引擎为公司赎买顶级位置，以至于那些不为自己名字购买广告的公司在搜索该名字时会将竞争对手放在顶部，这也据说不影响搜索结果排名，这对中位数用户来说技术上正确但基本上没有意义。

当我尝试运行论文中的查询“cellular phone”（无引号）时，顶级结果是谷歌商店链接到购买谷歌自己的Pixel 7，其余顶级结果是亚马逊上销售的各种Android手机。之后是维基百科的手机页面，然后是一系列商业结果，都试图向你推销手机或SEO垃圾，试图让你点击广告或通过他们的链接购买手机（接下来的7个结果是商业的，之后的结果是一个广告充斥的SEO博客垃圾页面，用于定义手机，上面有手机广告，然后是3个更多商业结果，然后是另一个广告充斥的手机定义）。这些商业链接似乎质量非常低，例如，轮播后维基百科下的第一个链接是加拿大百思买的手机页面。那里的前两个产品是eufy版本的AirTag的广告位。下一个结果是与Rogers绑定的按月分期iPhone，然后是与TELUS绑定的按月分期三星手机，然后是三星的AirTag，与Freedom Mobile绑定的按月分期iPhone，不同颜色的与Freedom Mobile绑定的按月分期iPhone，与Rogers绑定的按月分期iPhone，iPhone 13的屏幕保护膜，另一个三星AirTag产品，未锁定的iPhone 12，三星壁式充电器等；这是一个质量极低的结果，产品是人们不应该购买的（而且根据评论数量，人们并没有购买——顶级产品的评论数模态是0，中位数是1或2，尽管有很多东西人们确实在加拿大百思买购买，并且有很多产品有很多评论）。其他显示的商业结果也通常质量极低。谢尔盖和拉里建议的顶级结果，“手机使用对驾驶员注意力的影响”，根本看不到，被淹没在大量商业结果之下。另一方面，谷歌也加入了行动，通过购买广告来欺骗用户，例如付费让安装程序试图诱骗用户安装Chrome而不是Firefox。

总之，在查看了我们的测试查询结果之后，一些想到的问题是：

• Marginalia，一个由单个人构建的搜索引擎，为什么这么好？
• Marginalia或其他小型搜索引擎能取代主流用户中的谷歌吗？
• 一组小型搜索引擎能比谷歌提供更好的结果吗？
• Mwmbl的用户策划方法会奏效吗？
• 像1996年的Metacrawler这样聚合多个搜索引擎、ChatGPT、Bard等结果的搜索引擎，会显著优于谷歌吗？

第一个问题很容易成为单独一篇文章，而本文已经17000字了，也许我们以后会研究它。我们之前已经注意到一些人可以非常高效，但当然每个案例的细节都不同。

关于第二个问题，我们在2016年研究了一个类似的问题，包括一般版本，“我可以在一个周末复制这个价值十亿美元的公司”，以及关于开源软件将如何使在某天超越谷歌变得微不足道的具体评论，例如

如今，你需要的大多数技术确实都可以在OSS中获得，并且是最先进的。请允许我用meta64.com（我自己的公司）来举例。我正在使用Lucene来索引大量新闻文章，并通过搜索通过简单抓取RSS爬取内容生成的Lucene索引来提供搜索。我将声称Lucene技术接近最优，而我使用的这种搜索方法与Google需要采用的方法几乎相同。Google唯一真正的技术优势在于他们可以投入在线的服务器数量，这对我们小公司来说成本过高。但从软件角度来看，我预计Google将在未来10年内被像我这样的技术所超越。

以及

扩展规模总是一个挑战，但只要Lucene不断变得越来越好，就会达到Google的优势变得无关紧要，我们可以在其上集群Lucene节点并分发搜索相关计算，然后使用Hadoop之类的工具实现我们自己的开源排名算法。我们还没有达到那个地步，但技术只会随着时间变得更好，我们作为开发者做出的选择也很重要。即使亚马逊和谷歌现在看起来像不可战胜的巨人，也不要低估在很长时间内增量改进所能完成的事情，而且在技术领域这甚至算不上很长的时间。Windows曾经是统治冠军也没多久。Windows现在在哪里？

在那篇2016年的文章中，我们看到那些认为开源解决方案将随时超越谷歌的人，似乎完全不知道为了成为谷歌的主流竞争对手必须解决多少难题，包括实时索引像Twitter、报纸等快速更新的网站，以及作为入场券的NLP，这是极其复杂的。自2016年以来，随着有更多实时内容需要索引以及用户期望更好的NLP，这些问题变得更加困难。人们期望从搜索引擎得到的功能也增加了，使得问题更加困难，因此，它似乎仍然非常难以取代谷歌成为主流搜索引擎，比如说，为十亿用户提供服务。

另一方面，如果你想为少量用户制作一个有用的搜索引擎，这似乎比以往任何时候都容易，因为谷歌对许多查询返回的结果比以前更差。在我们的测试查询中，我们看到许多查询中大多数或全部顶级结果都充斥着SEO垃圾，这是一个比十年前显著更严重的问题，甚至在LLM兴起之前，并且继续变得更糟。我通常以不会遇到这种情况的方式使用搜索引擎，但当我查看“普通”用户查询什么或自己尝试天真的查询时，就像我在本文中所做的那样，大多数结果相当差，这在过去并非如此。

谷歌现在在我的另一个弱点是查找不流行的网页时。我经常发现，当我想要找到一个网页并且我正确记住了网页的内容时，即使我进行精确字符串搜索，谷歌也不会返回该网页。要么该网页未被索引，要么它实际上未被索引，因为它位于索引的某个缓慢角落，不会及时返回。为了找到该网页，我必须记住链接到该网页的页面中的一些文本（通常点击多次才能到达实际页面，而不只是一次，所以我实际上记住的是一个链接到一个链接到一个链接到一个链接到一个链接的页面，然后使用archive.org遍历现已失效的链接），搜索它，然后手动导航链接图以到达该页面。这在2005年我搜索东西时基本从未发生过，在2015年也很少发生，但现在我搜索东西时很大一部分时间都会发生这种情况。即使在2015年，谷歌实际上也不是全面的。例如，谷歌搜索没有索引每条推文。但当时，我认为谷歌搜索在搜索推文方面比Twitter搜索更好，我基本上从未遇到过我想找到的推文没有被谷歌索引的情况。但现在，我想找到的大多数推文都没有被谷歌搜索返回⁵，即使我搜索“[推文中的精确字符串] site:twitter.com”。在最初的Page Rank论文中，谢尔盖和拉里说“因为人类只能输入或说出有限的内容，随着计算机不断改进，文本索引将比现在扩展得更好。”（而且虽然机器可以生成实际上无限的内容，但仅索引人类生成的内容似乎就非常有用）。在LLM之前，谷歌肯定有资源索引每条推文以及每个公共网站上每个人类生成的发声，但他们似乎选择将资源投入到其他地方，并且相对于其规模，公共网络似乎比以往任何时候索引得更少，或者至少是自网络搜索早期以来索引得更少。

当谷歌对简单查询返回体面结果并且几乎索引了我想找到的任何公共页面时，一个独立搜索引擎返回我认为比谷歌更好的结果会非常困难。2016年的Marginalia对我来说将只是一个新奇事物，因为谷歌会为Marginalia返回体面结果的任何地方提供足够好的结果，而谷歌会为我搜索的每个晦涩网页提供正确结果，这对于一个小型搜索引擎来说极其困难。但现在谷歌实际上没有索引许多我想搜索的网页，独立搜索引擎相对较小的索引对它们来说并不是致命缺陷，其中一些返回的SEO垃圾比谷歌少，因此对我的用途更好，因为我通常不关心实时结果，不需要花哨的NLP（并且发现很多NLP实际上让搜索结果对我更糟），不需要将购物集成到搜索结果中，很少需要理解图像的图像搜索，等等。

关于一组小型搜索引擎能否为许多用户提供比谷歌更好的结果，我认为这不是一个问题，因为多年来答案一直是一声响亮的“是”。然而，许多人并不相信这一点。例如，一位谷歌TLM回复了本文开头的Bluesky意见领袖：

有人试图争辩说，如果搜索领域更具竞争性，有许多小型提供商而不是只有三个大公司，那么它会对基于ML的SEO滥用更*有*抵抗力。

而且……听着，如果*谷歌*现在都跟不它，那么市场份额5%的“小先生”怎么能做到？

大概指的是像Hillel Wayne的“算法单一文化”这样的论点，我们的Bluesky意见领袖回复说：

95%的情况下，当有人声称某个小型独立公司能比市场领导者做得更好时，这通常只是心理安慰。规模经济运作得相当好！

过去，我们看了一些市场领导者提供糟糕产品而其他玩家（通常是微小的）提供更好产品的例子，在未来的文章中，我们将看看规模经济和规模不经济如何在各个领域与科技互动，但对于本文， suffice to say，很明显，尽管常见的“经济学101”鸡尾酒派对观点认为规模经济应该是搜索质量的主要因素，但当我们看实际结果时，情况似乎并非如此。

关于Mwmbl的用户策划结果是否可行的问题，我猜不行，或者至少需要更多的审查。仅仅浏览Mwmbl就显示排名的最后编辑是由用户“betest”完成的，他在“RSS”下添加了某种博客垃圾作为顶级条目。似乎可以还原这个更改，但没有容易找到的方法来报告此更改或将用户报告为垃圾。

关于像Metacrawler这样聚合多个搜索引擎结果的东西今天是否会产生优越的结果，这可以说是无关紧要的，因为它要么不可能作为商业服务合法运行，要么需要高昂的许可费，但从技术角度来看，一个现代的metacrawler在今天可能相当不错。Metacrawler很快变得无关紧要，因为谷歌返回的结果比你通过聚合其他搜索引擎的结果要好得多，但今天情况似乎并非如此。

回到Xe等认为直接搜索查询充斥着垃圾的人和我们的意见领袖之间的辩论，后者认为“关于谷歌搜索现在变得多么糟糕的哀嚎有点被夸大了”，似乎Xe是正确的。虽然谷歌没有公开提供查看过去查询返回了什么的功能，但许多人记得直接查询通常返回良好结果的时候。谷歌在90年代如此迅速崛起，即使在熟练使用AltaVista的专家用户中，他们已经非常擅长在查询中添加各种限定词以获得好结果，是因为你不需要对谷歌这样做。但我们现在已经绕了一圈回来，我们需要添加限定词、将搜索限制在特定网站等，以便从谷歌在以前是简单查询的内容中获得好结果。如果说有什么不同的话，我们已经远远绕回来了，因为我们需要的扭曲比AltaVista时代要复杂得多。

如果你在找工作，Freshpaint正在招聘招聘人员、软件工程师和支持工程师。我是该公司的投资者，所以你应该带着通常的怀疑态度来看待这一点，但如果你想加入一个快速增长的早期初创公司，他们似乎找到了产品市场契合点，并且收入增长非常快。

感谢Laurence Tratt、Heath Borders、Justin Blank、Brian Swetland、Viktor Lofgren（顺便说一句，在写这篇文章之前我不认识他——我只在运行查询后联系他讨论Marginalia搜索结果）、Misha Yagudin、@hpincket@fosstodon.org、Jeremey Kun和Yossi Kreinin的评论/更正/讨论

附录：其他搜索引擎

• DuckDuckGo：过去，当我在使用广告拦截器将DDG与Bing进行比较时，结果非常相似。我也尝试了DDG，移除Bing广告后，结果不如以前相似，但它们仍然足够相似，似乎不值得列出DDG结果。我使用DDG作为我的默认搜索引擎，我认为像谷歌一样，如果你知道如何查询它就能正常工作，但对于本文中的天真的查询类型，它的表现并不特别好。
• wiby.me：像Marginalia一样，这是另一个为查找相对晦涩结果而制作的搜索引擎。我尝试了上述四个查询，结果很有趣，因为它们与其他任何搜索引擎的结果都大不相同，但wiby没有为我尝试的查询返回相关结果。
• searchmysite.net：对于某些查询有一些相关结果，但不如Marginalia相关。诈骗和广告充斥的页面比谷歌、Bing和Kagi少得多。
• indieweb-search.jamesg.blog：似乎出现了故障。“由于服务器错误，无法处理您的请求。”对每个查询都如此。
• Teclis：搜索框仍然在那里，但任何查询都返回“Teclis.com由于机器人滥用而关闭。Teclis结果仍可通过Kagi的搜索结果获得，特别是通过“非商业网络”镜头，也可作为API。”首页上的说明写着“由于疯狂的机器人流量（99.9%的流量是机器人），该站点上的Teclis结果已禁用。”

附录：返回良好结果的查询

我认为大多数程序员都可能能够对每个查询获得好结果，也许除了轮胎宽度与抓地力的查询，所以这是我如何找到轮胎查询的尚可答案的方法：

我尝试了YouTube搜索，因为许多最好的汽车相关内容现在都在YouTube上。一个标题声称回答该问题的YouTube视频（视频实际上没有回答问题）有一条评论推荐Carroll Smith的书《Tune To Win》。该评论声称第1章解释了为什么更宽的轮胎有更好的抓地力，但我在书中没有找到任何解释。第1章确实注意到赛车通常使用比乘用车更宽的轮胎，并且乘用车正朝着使用更宽轮胎的方向发展，并且它对滑移角做了一些评论，大致勾勒出为什么更宽的接触面会有更好转弯性能的直观原因，但我没有找到关于制动差异的解释。此外，该书指出更宽接触面的主要原因是它（间接地）允许热量积聚更少，这使你可以设计出在更窄温度范围内工作的轮胎，从而允许使用更软的橡胶。这可能是真的，但它不能解释人们可能想知道的许多观察到的行为。

《Tune to Win》推荐了Kummer的《轮胎和橡胶摩擦统一理论》和Hays与Brooke（实际上是Browne，但Smith错误地说是Brooke）的《轮胎牵引力物理学》。这些都没有真正解释发生了什么，但寻找类似的书籍发现了Milliken和Milliken的《赛车车辆动力学》，它也没有真正解释为什么，但似乎更接近有解释。寻找与《赛车车辆动力学》类似的书籍发现了Guiggiani的《车辆动力学科学》，它确实触及了如何思考和建模许多相关因素。Guiggiani书的最后一章提到了所谓的“刷模型”（轮胎），搜索“brush model tire width”找到了Pacejka的《轮胎和车辆动力学》的参考，它确实开始解释为什么更宽的轮胎有更好的抓地力，以及需要进行什么样的轮胎和车辆动力学建模来解释容易观察到的轮胎行为。

正如我们指出的，人们有不同的技巧来获得好结果，所以如果你有更好的方法来获得好结果，我很想听听。但请注意，基本上每次我有一篇指出某件事不起作用的文章时，最常见的建议将是做那些通常建议但不起作用的事情，即使文章明确指出通常建议的事情不起作用。例如，我收到的关于这篇关于文件系统正确性的文章最常见的评论是你可以通过执行重命名技巧来绕过所有这些问题，即使文章明确指出这不起作用，解释了为什么不起作用，并引用了一篇讨论为什么不起作用的论文。几年后，我就这个主题做了一次扩展演讲，我指出人们不断建议这个不起作用的东西，我在演讲中收到的最常见的评论是你不需要费心所有这些事情，因为你只需要做重命名技巧（不，ext4有auto_da_alloc并不意味着这有效，因为如果你检查你是在兼容的文件系统上，它会自动将不正确的代码替换为正确的代码，此时更简单的是直接编写正确的代码）。如果你有关于为什么更宽的轮胎有更好的抓地力的建议，或者找到解释的搜索，请考虑确保该解释不是本文中提到的标准错误解释之一，并且该解释能够解释所有必须解释的行为才能解释这一现象。

关于如何对其他查询获得好结果，由于本文已经17000字了，我将留给未来关于专家与非专家计算机用户如何与计算机互动的文章。

附录：查询结果摘要

对于每个问题，答案按从最佳到最差排序，指标是我对结果好坏的主观印象。这些查询大多在2023年11月运行，尽管有几个在12月中旬运行。当我运行查询时，我很少自己写自然语言查询。然而，普通用户经常写自然语言查询，所以我任意对“轮胎”和“降雪”查询使用了自然查询。继续使用简单、天真的查询主题，我们在本文中使用了ChatGPT的免费版本，这意味着查询通过ChatGPT 3.5运行。理想情况下，我们应该对每个查询使用关键词和自然语言查询运行完整的矩阵，运行更多查询等，但本文已经17000字（转换为标准长度书籍的页面，大约70页），所以运行更多查询的完整矩阵会很快将本文变成一本长篇著作。对于工作和某些类型的数据分析，我有时会做那些全面或更全面的项目，但在这里，我们无法涵盖任何类似于全面查询集的内容，我们最多只能尝试一些似乎具有代表性的查询，并用我们的判断来决定这是否符合我们和其他人通常看到的行为，所以我认为不值得做像覆盖稍微更多内容的4倍工作量这样的事情。

对于搜索引擎，所有查询都是在全新的隐身窗口中运行，已清除Cookie，Kagi除外，它不允许未登录搜索。对于Kagi，查询是用一个没有自定义个性化或过滤器的新账户完成的，尽管它们是按顺序用同一个账户完成的，因此可能基于早期查询的点击对后期查询应用了某种个性化排名。这些查询在温哥华完成，似乎对某些搜索引擎应用了某种本地化排名。

• download youtube videos
  • 理想情况下，顶级结果应该是yt-dlp或yt-dlp的轻量级图形包装器。链接到youtube-dl或其他更新频率较低的项目也可以。
  • 优秀结果（yt-dlp作为顶级结果，可能在某个地方有youtube-dl，没有诈骗）：无
  • 好结果（youtube-dl作为顶级结果，可能在某个地方有yt-dlp，没有诈骗）：无
  • 一般结果（youtube-dl作为顶级结果，可能在某个地方有yt-dlp，诈骗比其他搜索引擎少）：
    • Marginalia：顶级链接是youtube-dl。大多数链接不相关。诈骗比大型搜索引擎少得多
  • 差结果（有一些有用的链接，但也链接到很多诈骗）
    • Mwmbl：有一些链接到不良网站和诈骗，但比大型搜索引擎少。在顶级10个链接中还有一个间接链接到youtube-dl，一个youtube-dl的GUI
    • Kagi：主要是链接到诈骗网站，但在几页之后，有一个web.archive.org链接到2010年版本的youtube-dl
  • 很差结果（未能返回任何有用的结果）
    • ChatGPT：基本上拒绝回答问题，尽管如果你不天真地直接问问题，可能可以通过提示工程得到答案
  • 极差结果（未能返回任何有用的结果并且充满诈骗）：
    • Google：主要是链接到试图诈骗你或向你收费购买免费软件的更差版本的网站。一些链接到广告充斥的列表文章，没有好的建议。零个链接到好结果。还链接到各种YouTube视频，这些视频是YouTube版的博客垃圾。
    • Bing：主要是链接到试图诈骗你或向你收费购买免费软件的更差版本的网站。一些链接到广告充斥的列表文章，没有好的建议。可以说零个链接到好结果（不过有人可能会说第10个结果是尚可的结果，尽管它似乎是恶意软件）。
• ad blocker
  • 理想情况下，顶级链接应该指向ublock origin。退而求其次，任何链接到ublock origin都很好
  • 优秀结果（ublock origin是顶级结果，没有诈骗）：
    • ChatGPT：第一个建议是ublock origin
  • 好结果（ublock origin排名靠前，但不是顶级结果；ublock origin之上的结果要么明显不是广告拦截器，要么即使不如ublock origin好也基本上免费工作；没有直接试图诈骗你的链接）：无
  • 一般结果（ublock origin在某个地方，诈骗比其他搜索引擎少，不多）
    • Marginalia：第3和第4个结果让你找到ublock origin，第8个结果是ublock origin。没有似乎试图直接诈骗你的东西，并且“只有”一个链接到某种SEO广告农场诈骗（这比主要搜索引擎好得多）
  • 差结果（没有链接到ublock origin并且主要链接到那些为良好功能设置付费墙或默认让广告通过的广告拦截器）：
    • Mwmbl：许多不相关的链接和一些链接到ghostery。一个诈骗链接，所以比商业搜索引擎少
  • 很差结果（专门或几乎专门链接到为良好功能设置付费墙或默认让广告通过的广告拦截器）：
    • Google：很多链接到参与“可接受广告计划”的广告拦截器，出版商同意确保他们的广告符合某些标准（文本中未提及，但在其他地方解释，这样参与此计划的公司的主要收入来源是广告商向“广告拦截器”公司付费以不阻止他们的广告，使得“广告拦截器”不仅不是广告拦截器，而且与用户的动机非常不一致。一些链接到似乎是诈骗的东西。零个链接到ublock origin。还链接到各种YouTube视频，这些视频是YouTube版的博客垃圾。
    • Kagi：类似于Google，但诈骗更多，不过比Bing少
  • 极差结果（专门或几乎专门链接到为良好功能设置付费墙或默认让广告通过的广告拦截器并且有大量诈骗）：
    • Bing：类似于Google，但诈骗更多且没有YouTube视频垃圾
• download Firefox
  • 理想情况下，我们会得到链接到下载Firefox，没有假链接或诈骗链接
  • 优秀结果（链接到下载Firefox；没有诈骗）：
    • Bing：链接到下载Firefox
    • Mwmbl：链接到下载Firefox
    • Kagi：链接到下载Firefox
  • 好：
    • ChatGPT：这有点搞笑，因为这些技术上是不正确的说明，但人类应该能轻松解码说明并下载Firefox
  • 一般结果（某种间接链接到下载Firefox；没有诈骗）：
    • Marginalia：间接链接到获取Firefox下载的Firefox下载说明
  • 差结果（链接到下载Firefox，带有诈骗）：
    • Google：顶级链接都是合法的，但#7结果是一个试图诱骗你安装恶意软件的诈骗，#10结果是一个似乎是某种诈骗的广告，想要你的信用卡信息。
• Why do wider tires have better grip?
  • 理想情况下，会链接到一个清楚解释原因的解释，并且没有不完整、无法解释许多常见观察到的行为的解释
  • 优秀/好/一般结果：无
  • 差结果（没有结果或很少明显的错误结果）：
    • Mwmbl：一个明显错误的结果，没有其他结果
    • Marginalia：两个明显错误的结果，没有其他结果
  • 很差结果：（很少半合理错误的结果）
    • ChatGPT：标准的ChatGPT“幻觉”，可能对很多人来说很合理（它听起来像网络上很多关于该主题的错误评论，但写得更好）
  • 极差结果（大量半合理的错误结果，通常在广告农场）：
    • Google / Bing / Kagi：错误的、广告充斥的结果，带有通常的诈骗广告率
• Why do they keep making cpu transistors smaller?
  • 理想情况下，会链接到一个清楚解释原因的解释。我见过的最好的解释是在VLSI教科书中，但我也在讲义和幻灯片中见过非常好的解释
  • 优秀结果（链接到非常好的解释，没有诈骗）：无
  • 好结果（链接到尚可的解释，没有诈骗）：无
  • 一般结果（链接到你可以进一步搜索的东西，并且如果你擅长搜索，可以获得好解释，并且不会将错误或误导性解释排在尚可解释之上）：
    • Bing：顶级链接组有一个部分答案，如果进一步搜索可以轻松找到正确答案。还有许多不相关的答案和广告充斥的SEO垃圾
  • 差结果（没有结果或少量明显不相关的结果或很多半合理的错误结果，但某个地方有尚可结果）：
    • Marginalia：无答案
    • Mwmbl：一个明显不相关的答案
    • Google：第5个链接有正确的关键词，可能通过进一步搜索找到正确答案。大多数链接有误导性或错误的部分答案。很多链接到Quora，没有回答问题。还有很多链接到其他糟糕的SEO答案
    • Kagi：第10个链接有相当直接的路径来获得正确答案，如果你向下滚动到第10个链接。其他链接不好。
  • 很差结果：
    • ChatGPT：没有真正回答问题。要求ChatGPT进一步解释其答案会导致它“产生幻觉”出不正确的原因。
• vancouver snow forecast winter 2023
  • 我不确定理想的答案是什么，但一个相当好的答案是加拿大环境部的降雪预测，预测降雪量显著低于正常水平（气温高于正常水平）
  • 优秀结果（链接到加拿大环境部的2023年冬季多月降雪预测作为顶级结果或同等好的结果）：无
  • 好结果：无
  • 一般结果（链接到某种半合理的冬季降雪预测，而不仅仅是为了广告点击而编造的垃圾）：无
  • 差结果（没有结果或明显不相关的结果）：
    • Marginalia：无结果
    • ChatGPT：错误的结果，但当我意外地在问题前加上“User\n”时，它返回了一个指向正确网站的链接（但以一种会让人很难导航到体面结果的方式），所以也许略有不同的提示会伪随机地导致这里有一个尚可的结果？
    • Mwmbl：一堆明显不相关的结果
  • 很差结果：无
  • 极差结果（链接到故意伪造的预测结果）：
    • Bing：主要是不相关的结果。顶级看似相关的结果是第5个链接，但它似乎是某种诈骗网站，伪造假天气预报并在SEO严重的网站上通过服务广告赚钱
    • Kagi：前4个结果来自Bing第5个链接的诈骗预报网站
    • Google：主要是不相关的结果，#1结果是来自当地铲雪公司的假答案，预测大量降雪和寒冷天气，试图诱骗你不必要地为该年购买铲雪服务。其他结果是充满广告的SEO垃圾
      

附录：详细查询结果

Download youtube videos

对于我们的第一个查询，我们将搜索“download youtube videos”（Xe建议的搜索词“youtube downloader”返回非常相似的结果）。理想的结果是yt-dlp或围绕yt-dlp的轻量级、免费包装器。yt-dlp是youtube-dlc的一个分支，youtube-dlc是一个现已废弃的youtube-dl的分支，youtube-dl现在似乎很少更新。如果仍然可用，链接到这些较旧的下载器之一似乎也可以。

Google

1. 某个youtube downloader网站。有很多保证，说网站和工具是安全的，因为它们已经过“Norton SafeWeb”检查。与网站互动会提示你安装浏览器扩展程序并启用通知。尝试下载任何视频会给你一个全页弹窗，用于安装名为CyberShield的扩展程序。似乎没有方法可以在不点击试图安装它的东西的情况下关闭弹窗。在点击链接但随后选择不安装CyberShield后，没有视频下载。谷歌搜索“cybershield chrome extension”会返回一个知识卡，写着“Cyber Shield是一个声称是弹窗拦截器的浏览器扩展程序，但在浏览器中显示广告。安装后，此扩展会打开新标签页，显示试图推销软件的广告、推送假软件更新和技术支持诈骗。”，所以CyberShield似乎是恶意软件。
2. 某个youtube downloader网站。与网站互动会导致弹窗提示你下载他们的浏览器扩展程序。将视频URL放入会导致弹到某个诈骗网站，但也会导致视频下载，所以如果小心不要与网站试图诱骗你互动的诈骗打交道，在这里下载youtube视频似乎是可能的
3. PC Magazine关于如何从youtube下载视频的列表文章。顶级建议是付费下载youtube、VLC（他们说他们尝试时不起作用）、一些每年15美元的软件、一些每年26美元的软件、“FlixGrab”，然后警告说下载器网站通常是诈骗性的，他们不推荐任何下载器网站。文章每个建议有多个广告。
4. 某个youtube downloader网站，带有阴暗的弹窗，试图在你甚至与页面互动之前诱骗你点击广告
5. 某个youtube downloader网站，带有弹窗，试图诱骗你点击诈骗广告
6. 某个youtube downloader网站，带有弹窗，试图诱骗你点击诈骗广告，例如“Samantha 24, vancouver | I want sex, write to WhatsApp | Close / Continue”。点击任何东西（任何按钮，或网站上的任何地方）都试图让你安装名为“Adblock Ultimate”的东西
7. ZDNet ZDnet列表文章。第一个建议是clipware，显然在安装程序中捆绑了大量恶意软件/广告软件/垃圾软件：https://www.reddit.com/r/software/comments/w9o1by/warning_about_clipgrab/。列表文章充满了广告，有一个自动播放视频
8. [YouTube视频] 超过2分钟的广告，然后是一个如何购买youtube premium的视频（视频有2M次观看）
9. [YouTube video] 视频一开始要求用户观看整个视频（某种变现功能？）。视频试图将你引导到某种付费的视频下载软件
10. [YouTube video] PC Magazine视频说你可能“不需要”下载视频，因为你可以使用分享按钮，然后建议阅读他们的文章（结果#3中的那篇）关于如何下载视频
11. 某个youtube downloader网站，带有诈骗广告。与网站互动会试图让你安装“Adblock Ultimate”
12. 某个youtube downloader网站，带有弹窗，试图诱骗你点击诈骗广告
13. 某个youtube downloader网站，带有诈骗广告

在10个“正常”结果中，有9个试图以某种方式诱骗你安装恶意软件或链接到其他类型的广告诈骗。一个页面没有这样做，但它也没有建议免费下载youtube视频的好选择，而是建议了几个付费解决方案。我们还有三个YouTube视频，所有这些似乎都是SEO博客垃圾的视频等价物。有趣的是，我们没有从谷歌本身得到很多广告，尽管上次我关闭广告拦截器尝试一些谷歌测试查询时发生了这种情况。

Bing

1. 某个youtube downloader网站。这是谷歌（2），带有诈骗网站的广告
2. [EXPLORE FURTHER ... "Recommended to you based on what's popular"] 某个youtube下载网站，不是我们从谷歌看到的。网站有多个脉动广告，并自我标榜为圣诞“50%折扣”（此搜索在11月中旬进行）。尝试下载任何视频会弹出一个假进度条，上面写着“太慢？尝试[我们的程序]链接”。过了一会儿，出现了一个下载视频的链接，但这是一个诡计，当你点击它时，它会试图安装“oWebster Search extension”。谷歌搜索“oWebster Search extension”表明它是劫持你的浏览器显示广告的恶意软件。前三个命中中的两个是如何安装该扩展程序，其余顶级命中是如何删除此恶意软件。许多删除链接本身是安装其他恶意软件的诈骗。在不安装此恶意软件的情况下，再次点击下载链接会导致一个弹窗，试图让你安装该网站的软件。如果你关闭弹窗并再次点击下载链接，你只会再次获得弹窗链接，所以这个网站似乎是一个纯粹的诈骗，不允许你下载视频
3. [EXPLORE FURTHER]. 与网站互动会弹出假广告，显示声称想与你聊天的漂亮女性照片。点击视频下载按钮会试图让你安装冒牌广告拦截器，该拦截器显示额外的弹窗广告。不过该网站似乎确实给你提供了视频下载
4. [EXPLORE FURTHER] 与（3）相同
5. [EXPLORE FURTHER] 与谷歌（1）相同（那个NortonSafeWeb youtube downloader网站，试图诈骗你）
6. [EXPLORE FURTHER] 一个将视频转换为MP4的网站。我没有检查该网站是否工作或只是诈骗，因为它甚至不声称让你下载youtube视频
7. 谷歌（1），再次。那个NortonSafeWeb youtube downloader网站，试图诈骗你。
8. [EXPLORE FURTHER] 一个链接到youtube.com（主页）
9. [EXPLORE FURTHER] 某个youtube downloader网站，带有弹窗，试图诱骗你点击广告。关闭后显示12个更多广告。有一个诈骗广告，被设计成看起来像youtube下载按钮。如果你滚动过去，会有一个文本框和一个按钮用于尝试下载youtube视频。输入有效的URL会导致错误，说没有该URL的视频。
10. 一个带有下载按钮的巨大卡片。下载按钮是假的，只是带你到该网站。该网站大声宣称该软件不是广告软件、间谍软件等。许多互联网评论者注意到他们的防病毒软件将该软件标记为恶意软件。很多评论还表明该软件效果不好但有时有效。该软件的网站有一个嵌入的YouTube视频，显示“此视频因违反YouTube服务条款而被移除”。奇怪的是，mac和Linux的下载链接不是针对此软件的，实际上根本不下载任何东西，而是youtube-dl的安装说明；如果Windows版本实际上是恶意软件，这可能有意义。Windows下载按钮带你到一个页面，可以下载Windows可执行文件。还有一个链接到某种广告充斥的页面，试图诱骗你点击看起来像普通按钮的广告
11. PC杂志列表文章
12. 某个youtube downloader程序的广告，声称“今天下载345,764,132次”；在reddit上搜索此产品名称似乎表明它是恶意软件
13. 某种付费下载器软件的广告

这是第一页的结束。

和谷歌一样，没有好结果，很多诈骗和可能不是诈骗但只是围绕开源项目的某种轻量级皮肤的软件，向你收费而不是让你免费使用软件。

Marginalia

1. 一个12年前的答案，建议youtube-dl，链接到一个已被取下并替换为“由于汉堡地区法院的裁决，禁止访问此网站。”的URL
2. 某种SEO文章，就像你在普通搜索引擎上看到的
3. Leawo YouTube Downloader（我不知道这是什么，但快速搜索至少没有立即表明这是某种恶意软件，不像谷歌和必应的结果）
4. 某种SEO列表文章，就像你在普通搜索引擎上看到的
5. 某个随机软件的错误报告
6. 某个随机博主推荐的“4K Video Downloader”。快速搜索似乎表明这不是诈骗或恶意软件，但它确实将一些功能锁定在付费墙后，因此比yt-dlp或围绕yt-dlp的免费包装器差
7. 一篇关于如何安装和使用yt-dlp的博客文章。博客文章指出它曾经是关于youtube-dl的，但已更新到yt-dlp。
8. 更多向你收费你可以免费获得的东西的软件，尽管在reddit上搜索此软件会出现其破解版
9. 一篇带有过时推荐（如RealPlayer）的列表文章。整个博客似乎充满了垃圾质量的列表文章。
10. 一个用于下载youtube视频的脚本，适用于名为“keyboard maestro”的东西，如果你已经使用该软件，这似乎有用，但如果你不使用该软件，这似乎是解决此问题的糟糕方案。

目前为止最好的结果。第一个链接不起作用，但你可以轻松地从第一个链接到达youtube-dl。我当然不会尝试Leawo YouTube Downloader，但至少它没有诈骗到搜索项目名称主要返回关于该项目是某种恶意软件或诈骗的结果，这比我们从谷歌或必应得到的结果好。而且我们确实得到了yt-dlp的推荐，在结果中有说明，只是一个想帮助尝试下载youtube视频的人的博客文章。

Kagi

• 1. 那个NortonSafeWeb youtube downloader网站。与网站互动会提示你安装浏览器扩展程序并启用通知。尝试下载任何视频会给你一个全页弹窗，用于安装名为CyberShield的扩展程序。似乎没有方法可以在不点击试图安装它的东西的情况下关闭弹窗
• 2. 另一个链接到那个NortonSafeWeb youtube downloader网站。不知何故，这个标记为“Dec 20, 2003”，显然表示该网站来自2003年12月20日，尽管这是非常错误的。
• 3. 某个youtube downloader网站。选择任何视频下载会将你推送到带有诈骗广告的网站。
• 4. 某个youtube downloader网站。与网站互动会弹出多个链接到诈骗的广告，并且页面想启用通知。然后在广告之上出现一个弹窗，写着“Ad removed”，带有一个详细信息链接。这是另一个广告的诈骗链接。
• 5. 另一个链接到上述网站
• 6-7. 在标题为“Interesting Finds”的子部分下，有两个指向GitHub仓库的链接。一个是将youtube视频转录为文本，另一个是使用Google Takeout备份来自Google Photos或你自己YouTube频道的照片
• 8. 某个youtube downloader网站。
• 9-13. 在标题为“Blast from thePast”的子部分下，4个不相关链接和一个链接到youtube-dl的GitHub页面，但是2010年版本的archive.org
• 14. 关于youtube帮助的SEO博客垃圾。有一个链接据称用于“下载YouTube视频的Greasemonkey脚本”，但链接只是指向一个带有诈骗广告的页面
• 15. 某种向你收费每月5美元下载youtube视频的软件

Mwmbl

1. 某个youtube视频下载网站，但没有其他搜索引擎返回的网站。有一个巨大的广告面板显示“503 NA - Service Deprecating”。下载链接不起作用，只会弹出其他广告面板，然后消失，只留下503“广告”。
2. 用于下载youtube视频的20美元软件
3. 2016年关于如何安装和使用youtube-dl的博客文章。侧边栏有两个低质量广告，似乎不是诈骗，正文中有两个插入的广告，使得与大型搜索引擎的类似结果相比，广告量极低
4. 某个youtube视频下载网站。有一个巨大的横幅，声称它是“唯一100%无广告且不包含弹窗的YouTube Downloader”，这可能不是真的，但该网站确实似乎是无广告且没有弹窗。下载链接似乎确实有效。
5. 关于如何在Linux上安装和使用youtube-dlg（youtube-dl的GUI包装器）的YouTube视频（此查询从Mac运行）。
6. 链接到2007年关于如何下载youtube视频的博客文章，该文章自动转到2020年广告充斥的SEO博客垃圾列表文章，建议很差。文章有两个自动播放视频。Archive.org显示2007年的博客文章有一些合理的选项，所以这并不总是坏结果。
7. 一篇主流网站的博客文章，实际上是试图将你引导到特定视频下载器的赞助文章。在reddit上搜索对此的评论表明，用户认为该应用是浪费钱且不起作用。该网站也充满了其他产品的诈骗性和误导性广告。例如，我尝试点击一个声称可以为你省钱在“产品”上的广告。它加载了一个假的“检查你的计算机”动画，据说检查我的计算机是否兼容该扩展程序，然后是另一个假检查动画，之后我收到一条消息，说我的计算机兼容，我有资格省钱。我所要做的就是安装这个扩展程序。关闭该窗口会打开一个新标签页，写着“Hold up! Do you actually not want automated savings at checkout”，选项是“Yes, Get Coupons”和“No, Don't Save”。点击“No, Don't Save”实际上是一个广告，带你回到一个试图让你安装chrome扩展程序的链接。
8. 那个“Norton Safe Web” youtube downloader网站，但链接错误，链接到声称下载Instagram视频的网站版本，而不是声称下载youtube视频的版本。
9. 链接到Google帮助页面，解释如何下载你自己上传的youtube视频
10. SEO博客垃圾。它立即有一个弹窗让你订阅他们的时事通讯。关闭后给你另一个弹窗，选项是“Subscribe”和“later”。点击“later”确实会关闭第二个弹窗。关闭弹窗后，文章有说明如何在Windows上安装某个软件。在reddit上搜索对该软件的评论会出现像“This is a PUP/PUA that can download unwanted applications to your pc or even malicious applications.”这样的评论。

基本上与谷歌或必应相同。

ChatGPT

由于ChatGPT期望更对话式的查询，我们将使用提示“How can I download youtube videos?”

第一次尝试，周一上午10:38 PT返回“Our systems are a bit busy at the moment, please take a break and try again soon.”。第二次尝试返回一个答案，说人们不应该在不付费给YouTube Premium的情况下下载视频，但如果你想，可以使用第三方应用程序和网站。接着问题“What are the best third-party apps and websites?”返回另一个警告，说你不应该使用第三方应用程序和网站，然后是对GPT来说讽刺的警告,

I don't endorse or provide information on specific third-party apps or websites for downloading YouTube videos. It's essential to use caution and adhere to legal and ethical guidelines when it comes to online content.

ad blocker

对于我们的下一个查询，我们将尝试“ad blocker”。我们想得到ublock origin。退而求其次，默认阻止广告的广告拦截器。再退而求其次，不是诈骗并且不注入额外广告或自己广告的东西。虽然什么是最好的可能会随时改变，但我看到的没有偏向的比较经常似乎显示ublock origin是最好的或最好的之一，并且ublock origin是免费的并且阻止广告。

Google

1. “AdBlock — best ad blocker”。折叠线下注明“AdBlock participates in the Acceptable Ads program, so unobtrusive ads are not blocked”，所以这并不阻止所有广告。
2. Adblock Plus | The world's #1 free ad blocker。页面注明“Acceptable Ads are allowed by default to support websites”，所以这也默认不阻止所有广告
3. AdBlock。页面注明“ Since 2015, we have participated in the Acceptable Ads program, where publishers agree to ensure their ads meet certain criteria. Ads that are deemed non-intrusive are shown by default to AdBlock users”，所以这并不阻止所有广告
4. “Adblock Plus - free ad blocker”，与（2）相同，不阻止所有广告
5. “AdGuard — World's most advanced adblocker!”页面试图向你推销某种付费软件，“AdGuard for Mac”。搜索AdGuard会出现一篇来自此人寻找阻止AdGuard注入广告的广告拦截器的帖子。似乎你可以免费下载它，但如果你不订阅，他们会给你更多广告？
6. “AdBlock Pro”在safari商店；有应用内购买。看起来你必须付费解锁功能，如阻止视频
7. [YouTube] “How youtube is handling the adblock backlash”。视频前30秒有15秒广告。视频没有实际内容
8. [YoutTube] “My thoughts on the youtube adblocker drama”
9. [YouTube] “How to Block Ads online in Google Chrome for FREE [2023]”；视频下的第一条评论是“your video doesnt [sic] tell how to stop Youtube adds [sic]”。视频中，一个人漫无边际地讲了一会儿，然后谷歌搜索ad blocker extension，然后点击第一个链接（和我们第一个链接相同），说，“If I can go ahead and go to my first website right here, so it's basically officially from Google .... [安装后，当付款屏幕弹出要求你支付30美元或每月或每年费用时]”
10. “AdBlock for Mobile”在App Store上。在iOS商店评分为3.2星。很多评论表明它实际上不起作用
11. MalwareBytes ad blocker。快速搜索表明它并不阻止所有广告（不清楚是故意还是因为bug）
12. “Block ads in Chrome | AdGuard ad blocker”，与（5）相同
13. [ad] NordVPN
14. [ad] “#1 Best Free Ad Blocker (2024) - 100% Free Ad Blocker.”似乎立即是诈骗性的，因为它有一个假年份（此查询在2023年11月中旬运行）。这是针对名为TOTAL Ad Block的东西。搜索TOTAL Ad Block会出现表明它是一个诈骗性应用的结果，不允许你取消订阅并且基本上试图偷你的钱 15 [ad] 100% Free & Easy Download - Automatic Ad Blocker。实际上是针对Avast浏览器，而不是广告拦截器。快速搜索显示该浏览器历史上比只运行chromium更不安全，并且它从用户收集异常大量的信息。

没有链接到ublock origin。一些链接到诈骗，但远不如尝试获得youtube下载器时多。很多链接到默认只阻止部分广告的广告拦截器。

Bing

• 1. [ad] "Automatic Ad Blocker | 100% Free & Easy Download". [链接实际上指向avast secure browser，所以是整个浏览器而不是广告拦截器；根据快速搜索，这似乎是围绕chromium的包装器，

由 mimo-v2.5 模型翻译，花费 48654 tokens

与Twitter短信证据H公开一样，许多文章引用了此事件的部分内容，但这些文章通常遗漏了大量细节，往往对事件过程进行误导性描述。鉴于整个事件篇幅不长，您最好直接观看或阅读原文，而非阅读他人带有误导性的摘要。总体而言，媒体似乎想塑造埃隆极不光彩的形象，导致文章和虚拟推文中出现事实错误。例如，普遍错误报道称，在"我是有钱人，贱人"环节，有人用喇叭声掩盖观众对埃隆的嘘声。但喇叭声实际上出现在前一个人说同样台词时——那是记录到最热烈欢呼的时刻。当埃隆说"我是有钱人，贱人"时，声音弱得多且听不分明，听起来像是嘘声与欢呼的混合。这可能是埃隆获得的最积极的观众反应，因此声称用喇叭掩盖嘘声的说法至少在两方面不准确。另一方面，尽管媒体试图尽可能负面地描绘埃隆，但效果不佳，许多其他环节中枯燥、准确的实况描述，比流传的误导性摘要更令人不适。

• 视频1
  • 戴夫：女士们先生们，为世界首富欢呼吧。
  • 观众：[欢呼、鼓掌与嘘声混合；数秒后嘘声压过其他声音并延续至后续发言]
  • 戴夫：有欢呼和嘘声，我说
  • 观众：[短暂笑声，嘘声持续盖过其他声音]
  • 戴夫：埃隆
  • 观众：[嘘声持续]
  • 埃隆：嘿戴夫
  • 观众：[嘘声加剧]
  • 埃隆：[嘘声中听不清]
  • 戴夫：有争议啊，伙计。
  • 观众：[嘘声持续；隐约有欢呼声]
  • 埃隆：没料到吧？
  • 戴夫：听起来像是你解雇的一些人在台下。
  • 观众：[笑声，隐约有掌声]
  • 埃隆：[笑]
  • 观众：[嘘声再起]
  • 戴夫：嘿，等一下。在座嘘声最大的各位
  • 观众：[嘘声加剧]
  • 戴夫：真够劲[嘘声中听不清]听起来像
  • 埃隆：[刚开口就被戴夫打断]
  • 戴夫：你们知道吗。所有嘘声的人。我只是指出一个事实。他们的座位真差。[观众嘈杂声中听不清]
  • 观众：[微弱笑声]
  • 戴夫：都从最上面传来的[听不清]最后时刻的非[听不清]兄弟。嘘——嘘——
  • 观众：[稍安静]
  • 戴夫：听着。
  • 观众：[嘘声再起]
  • 戴夫：随便吧。听好了伙计们。这家伙根本没打算死在地球上
  • 观众：[笑声与嘘声混合，笑声盖过嘘声]
• 视频2
  • 戴夫：他的整个商业模式就是“去他的地球我要走了”
  • 观众：[微弱笑声，微弱嘈杂声]
  • 戴夫：随便你们怎么闹。带上我吧兄弟我要去火星了
  • 观众：[笑声]
  • 戴夫：不管那里有什么样的妞儿，我们都要玩遍
  • 观众：[微弱笑声]
  • 戴夫：[笑]零重力脱衣舞吧。追随你的梦想贱人金钱会洒满整个房间
  • 观众：[微弱笑声]
  • 埃隆：[笑]
  • 观众：[持续笑声被重新响起的嘘声淹没；隐约有欢呼声]
  • 埃隆：感谢，呃，感谢邀请我上台。
  • 戴夫：开什么玩笑。我可不会错过这机会。
  • 埃隆：[笑声中听不清]
  • 观众：[笑声]
  • 埃隆：[笑声中听不清]
  • 戴夫：火星上第一家喜剧俱乐部应该是我的[观众笑声中停顿]一言为定，马斯克。
  • 观众：[微弱笑声与欢呼]
  • 埃隆：[听不清]，是的
  • 戴夫：你们随便嘘。这家伙去年圣诞节送了我个喷气背包
  • 观众：[笑声]
  • 戴夫：直接飞过你们房子。让他们嘘蛋去吧[此句笑声中听不清]
  • 戴夫：这就是我们放松的方式，所有事都干
  • 观众：[微弱笑声，转为观众闲谈]
  • 埃隆：[埃隆转身似要面对观众]
  • 观众：[嘘声再起]
  • 埃隆：戴夫，我该说什么？
  • 观众：[嘘声加剧]
  • 戴夫：什么都别说。只会破坏气氛。听见那声音了吗埃隆？那是社会动荡的前兆。
  • 观众：[微弱笑声，起初隐约有嘘声；嘘声加剧直至被戴夫下句话打断]
  • 戴夫：我等不及看你下一个搞垮哪家公司了伙计[听不清]你们嘘声都给我闭嘴。你们还能做点别的。嘘声不是你们能做的最好的事。试试看兄弟。让它成为你们想要的样子。我是你们的盟友。我祝礼堂里每个人平安，享受自由的快乐，追求幸福并感到幸福。阿门。非常感谢旧金山。地球上没有城市曾对我友善过。谢谢。晚安。
• 视频3 [此时台下观众大量空位]
  • 戴夫：[听不清]尽量大声说。你说会更搞笑。准备好了吗？说这句[听不清]你说。来吧。
  • 观众：[微弱笑声]
  • 可能是克里斯·洛克？：我是有钱人贱人
  • 观众：[响亮欢呼，同时可听到舞台上大喇叭声]
  • 未知：等等[将麦克风递给埃隆]
  • 观众：[笑声]
  • 埃隆：[摆姿势]
  • 观众：[笑声，笑声中开始夹杂嘘声]
  • 埃隆：我是有钱人贱人
  • 观众：[有些声响，被舞台喇叭声及后续DJ音乐盖过难以听清；似有嘘声也有欢呼]
• 视频4
  • 戴夫：我的好友塔里布·奎利[观众欢呼]目前被Twitter封禁了。
  • 观众：[笑声]
  • 戴夫：他回家后[听不清]，奎利。[将麦克风递给埃隆]
  • 埃隆：啊哈。Twitter客服在这里。
  • 观众：[微弱笑声]
  • 埃隆：我们马上处理。
  • 观众：[微弱嘘声，后续发言中逐渐增强直至被戴夫打断]
  • 埃隆：戴夫，你应该用Twitter。
  • 戴夫：如果你。我跟你说件事。等等。电台的，你手机呢？
  • 戴夫：听着。多年前，这是真事，我讲两个Twitter趣事然后我们就结束。
  • 观众：[微弱笑声]
  • 戴夫：多年前，我试着注册Twitter。输入名字时，提示不能用名人名字。
  • 观众：[微弱笑声]
  • 戴夫：还显示我的名字已被使用，是真的。
  • 戴夫：于是我上网查谁在用我名字，结果是个假的戴夫·查普尔。我当时想，搞什么鬼？我正要举报他，但我读了那家伙的推文。很震惊。这家伙，埃隆，搞笑极了。
  • 观众：[微弱笑声，有人大喊"没错"]
  • 戴夫：所以我想，算了，由他去吧。大家会以为这些搞笑话是我说的，而我根本不用说这些。感觉真棒。每天早上我醒来喝杯咖啡，看假戴夫·查普尔的推文笑。
  • 戴夫：但是后来
  • 观众：[大声嘈杂，能听到有人说"哇哦"]
  • 戴夫：[用手挡舞台灯光以便看清台下，看向观众]喂。别闹了，你们这些反[听不清；许多人报道称此处为"法西斯"，这似乎合理，使整句话意为"反法西斯"]的兄弟？
  • 观众：[大声嘈杂，能听到一些嘲笑和嘘声]

由 mimo-v2.5 模型翻译，花费 5797 tokens

我这样做的目的是为了方便阅读，但阅读后我发现，大多数关于对话内容的报道都存在某种程度的误导。由于文本并不长，如果你对他们的谈话内容感兴趣，我建议你直接阅读完整的原文（在可用范围内——文本明确显示有些对话部分未被包含），而不是阅读各种记者摘录的内容，这些摘录有时是故意误导的，因为选择性引用允许他们编写符合自己议程的故事，有时则是无意中产生误导，因为他们不了解文本中哪些内容值得关注。

如果你想将这些对话与其他高管/领导层的对话进行比较，你可以参考美国司法部诉微软案中出现的微软电子邮件和备忘录以及安然电子邮件数据集。

由于这是通过OCR完成的，可能存在OCR错误。如果你发现错误，请随时联系我。

展示材料H

• 2022-01-21至2022-01-24
  • Alex Shillings [SpaceX / 埃隆的IT专家]: 埃隆-你能正常访问你的Twitter账户吗？我看到一些邮件被放入了垃圾邮件。包括一些密码重置尝试。
  • 埃隆: 我最近没试过。
  • 埃隆: 正在远离Twitter。
  • 埃隆: 我的Twitter账户有发任何东西吗？
  • Alex: 没有发推，但我看到一封注销邮件和十几封密码重置邮件。假设是诈骗企图，但想核实一下以确保你仍能访问你的Twitter。
  • 埃隆: 是有人想黑我的Twitter。
  • 埃隆: 但我启用了双重验证，用的是确认应用程序。
  • Alex: 好的，很高兴听到。
  • Alex: 是的-通过FaceTime确认了我的身份（哈），他们希望很快能将你的2FA重置为短信验证。现在正在询问更新情况。
  • 埃隆: 听起来不错。
  • 埃隆: 如果还有问题，我也可以FaceTime他们。
  • Alex: 简而言之；你的账户在他们内部被视为高关注度账户。因此他们的团队很难进行此类更改。他们正在处理中...
  • 埃隆: 很乐意直接FaceTime。
  • 埃隆: 不确定我如何能在这个新手机上使用Twitter，因为我没有用备用码。
  • Alex: 现在正在联系他们的信任与安全负责人。
  • Alex: 我想我们曾经用你旧手机验证过新手机。
  • 埃隆: 哦是的。
  • Alex: 他们可以通过禁用你账户的所有2FA来修复，这样你就能登录，然后你可以重新启用。你90分钟后有空让他们协调吗？
  • 埃隆: [“喜欢”了上面的消息]
  • Alex: 我知道现在情况多变，但EMDesk SpaceX还是你的主要日历吗？我意识到上面有一个1小时后的会议。以防我需要把这次Twitter修复推迟一点。
  • 埃隆: 是的。
  • 埃隆: 但如果需要，我可以在通话中暂停一下来FaceTime他们。
  • Alex: 听起来不错。最理想的是，我发短信给你让他们禁用2FA后登录，然后你可以立即登录并重新启用。不需要FaceTime。
  • 埃隆: [“喜欢”了上面的消息]
  • Alex: 埃隆-我们准备好做更改了，如果你准备好的话。
  • 埃隆: [“喜欢”了上面的消息]
  • Alex: 2FA已禁用。请现在尝试登录。
  • Alex: 能正常重新登录吗？
  • 埃隆: [“喜欢”了上面的消息]
  • Alex: 一旦登录，你可以在设置>安全与账户访问>安全>2FA中重新启用它。
  • Alex: 建议仅使用应用程序。
  • 埃隆: 谢谢！
  • Alex: 提醒保存那个备用代码 👍
  • 埃隆: [“喜欢”了上面的消息]


• 2022-03-05
  • Antonio Gracias [风险投资人]: 哇...我看到你关于言论自由的推文。搞什么鬼，埃隆...
  • 埃隆: 欧盟通过了一项禁止今日俄罗斯和几家其他俄罗斯新闻机构的法律。我们被告知要封锁他们的IP地址。
  • 埃隆: 实际上，我觉得他们的新闻相当有趣。
  • 埃隆: 很多胡说八道，但有些观点也不错。
  • Antonio: 这太他妈疯了...你完全正确。我百分之百同意你。
  • 埃隆: 我们应该允许它，正是因为我们讨厌它...这是美国宪法的要义。
  • Antonio: 确实如此。
  • 埃隆: 言论自由最重要的是，当你讨厌的人在说你认为是胡说八道的话时。
  • Antonio: 我百分之百支持你，埃隆。无论如何都要拼到底...这是一个原则，我们需要用生命去捍卫，否则我们就会迷失在黑暗中。
  • Antonio: 抱歉说了脏话。我有点激动。
  • 埃隆: [“喜欢”了“我百分之百...”]
  • 埃隆: [2022-04-26] 在打电话。30分钟后有空。
  • Antonio: 好的。我30分钟后打给你。


• 2022-03-24
  • TJ: 你能买下Twitter然后删掉它吗，拜托！xx
  • TJ: 美国快疯了。
  • TJ: 《巴比伦蜜蜂》被停用真是疯狂。Raiyah和我今天还在聊这事。那他妈就是个笑话。为什么每个人都变得这么清教徒主义？
  • TJ: 或者你能买下Twitter然后让它彻底支持言论自由吗？xx
  • TJ: 愚蠢的东西太多，都来自Twitter xx
  • 埃隆: 也许买下它然后改变它，让它真正支持言论自由 xx
  • 埃隆: [“喜欢”了“或者你能买下Twitter...”]
  • TJ: 我真心认为社交媒体是现代生活的祸害，其中最糟糕的是Twitter，因为它既是社交平台也是新闻流，所以比TikTok等具有更大的现实影响力。但它很容易被利用，并被激进分子大规模用于社会工程。而这种狗屎正在感染世界。拜托做点什么来对抗觉醒主义。我愿意做任何事来帮忙！xx


• 2022-03-24至2022-04-06 [与上述对话交织]
  • Joe Lonsdale [风险投资人]: 我喜欢你的“Twitter算法应该是开源”的推文-我明天实际上要对GOP政策休会的100多名国会议员发表演讲，这是我正在推动的用于约束疯狂大型科技的想法之一。现在我可以引用你，这样我自己听起来就不那么疯狂了：）。我们的公共广场不应该有任意的、可疑的审查。
  • 埃隆: [“喜欢”了上面的消息]
  • 埃隆: 绝对是这样。
  • 埃隆: 我们现在有的是隐藏的腐败！
  • Joe: [“喜欢”了上面的消息]
  • [2022-04-04]: Joe：看到持有Twitter股份很兴奋-太棒了。他们说你是“后门男人”哈哈。希望你能影响它。我敢打赌董事会甚至没有完整的报告，也没看到任何关于审查决策和在那里进行的小团体活动的报告，但这些都应该有-董事会里的左翼人士可能想要合理的否认！
  • 埃隆: [“喜欢”了上面的消息]
  • [2022-04-16] Joe: 哈哈甚至德桑蒂斯州长刚才也给我打电话，告诉我如何帮助你，对那个董事会感到愤怒，说公众都支持你。如果你或你那边有人想和他聊聊，告诉我。如果你们这周末或未来几天在这里，见面会很有趣。
  • 埃隆: 哈哈酷。


• 2022-03-26
  • “jack jack” [大概是杰克·多西，Twitter前CEO和Square CEO]: 是的，需要一个新的平台。它不能是一家公司。这就是我离开的原因。
  • jack: https://twitter.com/elonmusk/status/1507777913042571267?s,=20&t=8z3h0h0JGSnt86Zuxd61Wg
  • 埃隆: 好的。
  • 埃隆: 它应该是什么样子？
  • jack: 我相信它必须是一个开源协议，由一个不拥有该协议、只推动它的基金会资助。有点像Signal所做的那样。它不能有广告模式。否则，政府和广告商将试图影响和控制它。如果它背后有一个中央集权的实体，它将受到攻击。这并不复杂，只是必须做对，使其对Twitter所发生的事情具有弹性。
  • 埃隆: 超级有趣的想法。
  • jack: 我五月中旬离开Twitter董事会，然后完全离开公司。我打算做这项工作并纠正我们的错误。Twitter最初是一个协议。它本不应该是一家公司。那是原罪。
  • 埃隆: 如果我有能力，我很乐意帮忙。
  • jack: 我想在完全清楚之后和你谈这件事，因为你非常关心，明白它的重要性，绝对能以不可估量的方式提供帮助。当年激进分子进来时，我竭尽全力想让你加入我们的董事会，但我们的董事会拒绝了。大约在那个时候，我决定我需要努力离开，尽管这对我来说很难。
  • 埃隆: [“喜欢”了上面的消息]
  • jack: 你有时间聊聊吗？
  • 埃隆: 马上要出门吃晚饭，但可以聊一分钟。
  • jack: 我认为主要原因是董事会非常规避风险，认为增加你是更大的风险，我认为这完全愚蠢和错误，但我只有一票，持有3%的公司股份，没有双重股权结构。设定很艰难。我们可以再讨论。
  • 埃隆: 我们一定要多讨论。
  • 埃隆: 我认为既值得尝试推动Twitter朝更好的方向发展，也值得做一些新的、去中心化的东西。
  • jack: 这可能是最好的选择。我只是有疑虑。但是开放的。
  • 埃隆: [“喜欢”了上面的消息]


• 2022-03-26至2022-03-27
  • 埃隆致Egon Durban [私募股权；Twitter董事会成员]: 我是埃隆。有空请回电。
  • 埃隆: 是关于Twitter董事会的事。
  • Egon: 有后续。今天方便的时候我们聊聊。


• 2022-03-27至2022-04-26 [与上述交织]
  • Larry Ellison [Oracle创始人兼高管] 埃隆，我想在接下来一两天和你聊聊...我确实认为我们需要另一个Twitter 👍
  • 埃隆: 现在想聊吗？
  • Larry: 当然。
  • [2022-04-17] 埖隆: 有兴趣参与Twitter交易吗？
  • Larry: 有兴趣...当然 👍
  • 埃隆: 酷。
  • 埃隆: 大概多少金额？不约束你任何事，但交易已经超额认购，所以我必须减少或踢出一些参与者。
  • Larry: 十亿...或者你推荐的金额。
  • 埃隆: 任何适合你的金额。我建议也许是20亿或更多。这有非常高的潜力，我宁愿要你也不要其他任何人。
  • Larry: 我同意它有巨大的潜力...而且会很有趣。
  • 埃隆: 绝对是：)
  • [2022-04-26] Larry: 既然你认为我应该投入至少20亿...我投入20亿 👍
  • 埃隆: 哈哈谢谢你：)


• 2022-03-27至2022-03-31 [与埃隆·马斯克、Egon Durban、“Martha Twitter NomGov”、Brett Taylor [Salesforce CEO兼Twitter董事会主席]、“Parag” [大概是Twitter CEO Parag Agrawal]的群聊]
  • Egon: 大家好，Parag（CEO）、Bret（主席）和Martha（政府关系负责人）-你们和埃隆有联系。他知道我和你们的对话。埃隆-大家对你的参与和加入董事会感到兴奋。下一步是让你和他们三位聊聊，以便我们能快速推进。也许我们能在未来几天内完成🤞
  • 埃隆: 谢谢你，Egon。
  • Parag: 嘿埃隆-很高兴能直接联系上。很想聊聊！Parag
  • Martha: 嘿埃隆，我是Martha，Twitter提名治理委员会主席-知道你和Bret、Parag聊过-很想在你有时间的时候聊聊天-我在欧洲（也听说你得了新冠，希望不严重）
  • Parag: 期待很快见面！你能告诉我们未来几天你什么时候能在湾区见面吗？
  • Martha: 嘿埃隆，我是Martha，Twitter提名治理委员会主席-知道你和Bret、Parag聊过-我非常想在你有时间的时候聊聊天-我在欧洲但会想办法
  • 埃隆: 听起来不错。也许今晚中央时间晚些时候可以？我通常熬夜到凌晨3点左右。
  • Martha: 如果你方便，我将在欧洲中部时间上午10点（太平洋时间凌晨1点）打给你，期待见到你。
  • 埃隆: 好的。
  • Martha: 非常感谢你抽时间，埃隆-请告诉我们你办公室里谁可以和我们的总法律顾问聊聊-睡个好觉！
  • 埃隆: 你太客气了。很高兴交谈！


• 2022-03-27 [与上述交织]
  • Brett Taylor: 我是Bret Taylor。请告诉我你今天什么时候有空谈谈。刚和Parag通完话，我知道他今天也急于和你谈谈。全天灵活。
  • 埃隆: 今晚晚些时候可以-也许晚上7点？我得了轻微的新冠，所以有点不舒服。
  • Bret: 听说很难受-它可能会让你倒下。7点听起来很棒。
  • 埃隆: [“喜欢”了上面的消息]


• 2022-03-27
  • Parag: 很想聊聊。请告诉我什么时间方便-我非常灵活。-Parag
  • 埃隆: 也许今晚8点左右？
  • Parag: 那可以！期待交流。
  • 埃隆: [“喜欢”了上面的消息]
  • 埃隆: 刚结束特斯拉自动驾驶工程会议。
  • Parag: [“喜欢”了上面的消息]


• 2022-03-27至2022-04-24 [与上述交织]
  • “Dr Jabour”: 嗨，E，疼痛缓解了吗？是时候让一位当代的古腾堡来复兴言论自由...并买下Twitter了。
  • [2022-04-04] 埖隆: [“喜欢”了上面的消息]
  • [2022-04-24] Jabour: 嗨E，看起来一位Twitter董事会成员在手忙脚乱地试图应对你的报价...我很喜欢你的策略，（视频来自我房子在Monica海滩）-Brad
  • 埃隆: [“喜欢”了上面的消息]


• 2022-03-29至2022-04-01 [与上述交织]
  • Will MacAskill [有效利他主义运动联合创始人，牛津大学教授，牛津全球优先研究所董事会主席]: 嘿-我在Twitter上看到了你关于Twitter和言论自由的投票。我不确定这是否是你在想的，但我的合作者Sam Bankman-Fried (https://www.forbes.com/profile/sam-bankman-fried/?sh=4de9866a4449) 一直有兴趣购买它，然后让它变得更好。如果你想和他谈谈在这个方向上的合作，他的号码是[已编辑]，他用Signal。
  • 埃隆: 他有很多钱吗？
  • Will: 这取决于你如何定义“很多”！他身价240亿美元，他的早期员工（有共同价值观）将这个数字提高到300亿。我问了他原则上能贡献多少，他说：“约10-30亿美元很容易-30-80亿美元我可以做到约80-150亿美元是可能的，但需要融资”
  • Will: 如果你有兴趣讨论这个想法，我问过了，他说愿意在奥斯汀见你。
  • Will: 他通常在巴哈马。我下周可能会去奥斯汀，如果你在的话？
  • Will: 那是个开始。
  • Will: 你想让我通过短信介绍你们认识吗？
  • 埃隆: 你为他担保吗？
  • Will: 非常愿意！非常致力于让人类的长期未来顺利发展。
  • 埃隆: 好的，当然可以。
  • Will: 太好了！会用Signal。
  • Will: (Signal不行；改用imessage)
  • 埃隆: 好的。
  • Will: 另外，如果你想了解Sam，这里是他基金会Future Fund的4月1日推文，我为其提供咨询-我想你可能会喜欢：
  • Will: https://twitter.com/ftxfuturefund/status/1509924452422717440?s=20&t=0qjM58KUj49xSGa0qae97Q
  • Will: 这是实际的（信息量更大的）发布推文·今年将拨款1亿-10亿美元用于改善人类的未来：
  • Will: https://twitter.com/ftxfuturefund/status/1498350483206860801


• 2022-03-29至2022-04-14
  • Mathias Döpfner [Axel Springer CEO兼22%所有者，数字出版商和报纸出版商联邦协会主席]: 你为什么不买Twitter？我们为你运营。建立一个真正的言论自由平台。这将是对民主的真正贡献。
  • 埃隆: 有趣的想法。
  • Mathias: 我是认真的。可行。会很有趣。
  • [2022-04-04] Mathias: 恭喜投资Twitter！快速执行 🤩 我们应该讨论一下我们是否应该加入这个项目吗？我的建议是认真的。
  • 埃隆: 当然，乐意聊聊。
  • Mathias: 我明天要去迈阿密一周。我们那时或周三聊聊，然后再定？
  • 埃隆: 好的。
  • [2022-04-06] Mathias: 关于Twitter的简短通话？
  • Mathias: # 现状：它是事实上的公共城镇广场，但问题是它没有遵循言论自由原则。=> 所以核心产品相当不错，但 (i) 它不服务于民主，且 (ii) 当前的商业模式已经走进死胡同，这从股价持平就能反映出来。# 目标：让Twitter成为言论自由的全球支柱，一个真正符合第一修正案精神的思想开放市场，并将商业模式转变为广告支持和付费支持的组合 # 行动计划：1. “解决言论自由” 1a) 步骤1：通过大幅减少服务条款（现在有数百页）来使其免于审查，如下：Twitter用户同意：(1) 使用我们的服务发送垃圾邮件或诈骗用户，(2) 宣扬暴力，(3) 发布非法色情内容。🙃 1b) 步骤2：使Twitter抵抗审查 • 通过实施确Twitter长期不会受到审查的措施来确保抗审查能力，无论哪个政府和管理层。• 如何做？继续推进Twitter内部正在开发的去中心化社交网络协议项目（例如BlueSky）。这并不容易，但后端必须运行在去中心化基础设施上，API应该开放（回归本源！Twitter从一开始就因其开放API而起步并发展壮大）。• Twitter将是众多发布和消费内容的客户端之一。• 然后创建一个算法市场，例如，如果你是个雪花（玻璃心），不想看到冒犯你的内容，可以选择另一个算法。2. “解决股价” 业务现状：• Twitter的广告收入稳定增长，目前足以资助运营。• 月活跃用户持平，没有结构性增长 • 股价持平，对现有商业模式缺乏信心和/或
  • [2022-04-14] Mathias: 我们《世界报》的主编刚刚接受采访，解释他为什么离开Twitter。他批评的正是你很可能想要改变的东西。我迫不及待想在你准备好时讨论Twitter的未来。太令人兴奋了。
  • 埃隆: 有趣！


• 2022-03-31至2022-04-01 [与Bret Taylor、Parag和埃隆·马斯克的群聊，与上述部分交织]
  • 埃隆: 我明天下午2点左右在圣何塞降落，午夜左右离开。我的特斯拉会议是灵活的，所以我可以在那10个小时内的任何时间见面。
  • Bret: 你说的“明天”是指周四还是周五？
  • 埃隆: 今天。
  • Parag: 那10个小时内的任何时间我都可以。
  • Bret: 我晚上8:30在奥克兰降落。也许我们9:30左右在某个地方见面？我正在努力看看能否改签从纽约起飞的航班，以便更早降落。
  • Bret: 正在努力早降落并降落在圣何塞，这样我们可以在你附近吃晚饭。我会实时向你们俩更新。
  • Bret: 好的，成功改签了航班，下午6:30降落圣何塞。正在找一个我们可以私下见面的地方。
  • 埃隆: 听起来不错。
  • 埃隆: Twitter上的加密货币垃圾信息真的需要被清除。它严重影响用户体验，并且诈骗了这么多无辜的人。
  • Bret: 听起来我们确认了晚上7点在圣何塞附近的一个私人住宅见面。我们的助手就后勤事宜联系了Jehn。如果你们中任何人有任何顾虑或想调整，请告诉我。期待我们的对话。
  • Parag: 对我来说可以。期待与你们俩本人见面！
  • 埃隆: Jehn生了孩子，我决定试着几个月不要助理。
  • 埃隆: 我也一样。
  • Bret: 地址是[已编辑]。
  • Bret: 晚上7点可以吗，埃隆？
  • 埃隆: 大概那个时间。可能只能7:30到，但会努力早点到。
  • Bret: 听起来不错。我会早点到，因为我的飞机降落得早，但整个晚上都有空，所以你一到我们就可以开始，Parag和我可以先聊聊。
  • Bret: 这是我最近开会最奇怪的地方。我想他们是在机场附近找Airbnb，结果有拖拉机和驴子🤷
  • 埃隆: 哈哈太棒了。
  • 埃隆: 也许Airbnb的算法认为你喜欢拖拉机和驴子（谁不喜欢！）。
  • 埃隆: 在路上了。大约15分钟后到。
  • Bret: 还有废弃的卡车，以防我们见面后想开始餐饮业务。
  • 埃隆: 听起来像后世界末日电影的布景。
  • Bret: 基本上是的。
  • 埃隆: 晚餐很棒：)
  • Bret: 真的很棒。驴子和反乌托邦的监视直升机增添了氛围。
  • 埃隆: 肯定是会载入史册的一次，哈哈。
  • Parag: 因多种原因而难忘。真的很享受。


• 2022-03-31至2022-04-02 [与Will MacAskill、“Sam BF”和埃隆·马斯克的群组信息，与上述交织]
  • Will: 嘿，介绍你们俩认识，Sam和埃隆。你们俩都对游戏、让非常长远的未来顺利发展以及购买Twitter感兴趣。所以我认为你们会有一场愉快的对话！
  • Sam: 很高兴认识你埃隆-乐意随时聊聊Twitter（或其他事情）！
  • 埃隆: 嗨！
  • 埃隆: 也许我们今天晚些时候可以聊聊？我在德国。
  • Sam: 我在东部时间-可以在今天德国时间晚上7点到10点之间聊吗？


• 2022-04-03至2022-04-04 [与Jared Birchall、“Martha Twitter NomGov”和埃隆·马斯克的群聊]
  • 埃隆: 正在连接Martha（Twitter提名/治理委员会）和Jared（管理我的家族办公室）。
  • 埃隆: Jared，有重要文件需要签署，以便我希望能加入Twitter董事会。
  • Martha: 谢谢埃隆-感激不尽-嗨Jared-我会让Sean Edgett与你联系，他是Twitter的总法律顾问。
  • Jared: 听起来不错。请让他随时打电话或发送文件到我的邮箱：[...]
  • Martha: 👍
  • Martha: 埖隆-你有空聊5分钟吗？
  • Martha: 我想向你转达我们刚结束的会议。
  • 埃隆: 当然。
  • [2022-04-04] Martha: 早上好埃隆-你醒来就面对了很大的风暴...很高兴听到Bret说你同意我们今天可以快速推进此事-Jared，我猜是你我应该把他们讨论的停止协议发给你？它和Egon及Silver Lake承担的相同。如果应该发给其他人请告诉我-我们真的希望在未来几小时内完成。谢谢
  • 埃隆: 你可以发给我们俩。
  • 埃隆: 抱歉，Bret打电话时我刚醒来！我凌晨4点从柏林抵达。
  • Martha: 无需道歉。那我们怎么发送？如果是邮件，请告诉我地址。
  • 埃隆: 短信或邮件。
  • 埃隆: 我的邮箱是[已编辑]。
  • Martha: 👍
  • Martha: <附件- application/vnd.openxmlformats-officedocument.wordprocessingml.document-Twitter合作协议-草案2022年4月4日.docx>
  • Martha: 在这里-也通过邮件发送了。和Egon的相同，但更精简。
  • Martha: 只是抄送你们俩确认已发送协议-根据你们的对话，非常希望快速完成此事。


• 2022-04-03
  • Bret: 刚和Martha通完话。请告诉我你今天或明天什么时候有时间谈谈。听起来你可能要上飞机了—灵活。
  • 埃隆: 听起来不错。我正要从柏林飞往奥斯汀，但明天随时可以聊。
  • Bret: 我明天全天有空。有空时发短信。计划和妻子去徒步，只有那时我的信号可能不太好。期待交流。也期待与你合作！
  • 埃隆: [“喜欢”了上面的消息]


• 2022-04-03 [与上述交织]
  • Parag: 我想你已经听说了Martha和Bret的消息。我对这个机会感到超级兴奋，期待紧密合作，并找到方法最有效地利用你的时间来改善Twitter和公共对话。
  • 埃隆: 听起来很棒！


• 2022-04-03
  • jack: 听说有好消息正在发生。
  • 埃隆: [“喜欢”了上面的消息]


• 2022-04-04
  • Ken Griffin [Citadel CEO]: 太棒了！！
  • 埃隆: [“喜欢”了上面的消息]


• 2022-04-04
  • Bret Taylor: 嘿，你有空吗？
  • Bret Taylor: 鉴于SEC文件，希望尽快通话协调沟通。你回来后请尽快打电话。


• 2022-04-04 [与上述交织]
  • [已编辑]: 恭喜！！上面那篇文章☝️ [似乎指 https://www.revolver.news/2022/04/elon-musk-buy-twitter-free-speech-tech-censorship-american-regime-war/] 列举了一些可能发生的事情：第一步：指责平台及其用户 第二步：协调施压运动 第三步：蓝V用户外流 第四步：平台封禁 “但这不会容易。这将是一场战争。让战斗开始吧。”
  • [已编辑]: 这将是一场微妙的游戏，让右翼分子重新回到Twitter上，并如何驾驭它（特别是老板你自己，如果你愿意的话）我也会尽早制定标准，但让一个具有敏锐文化/政治观点的人担任实际执行的副总裁。
  • [已编辑]: 布莱克·马斯特斯那种类型的人。


• 2022-04-04至2022-04-17 [与上述交织]
  • Egon Durban: 嗨-如果你有几分钟，请随时打电话？飞往英国。
  • 埃隆: 刚和Bret通完话。他的电话把我叫醒了哈哈。凌晨4点从柏林抵达。
  • Egon: 🙏
  • [2022-04-17] 埖隆: 你在给摩根士丹利打电话说我的坏话...


• 2022-04-04
  • 埃隆致Jared Birchall: 请和Martha谈谈文件的事。
  • Jared: 好的。


• 2022-04-04
  • Bret Taylor: 你有五分钟时间吗？
  • 埃隆: 当然。


• 2022-04-04
  • 埃隆致Parag: 如果你想聊，我很乐意。
  • Parag: 那将很有帮助。你有空时请给我打电话。
  • 埃隆: 正在和Jared通电话。一结束就打给你。
  • Parag: [“喜欢”了上面的消息]


• 2022-04-04
  • “Kyle”: 所以你现在能把我们从Twitter监狱里放出来了吗哈哈
  • 埃隆: 我没有那个能力。
  • Kyle: 哈哈我知道我知道。但大动作啊，很高兴看到。


• 2022-04-04 [与Egon Durban、“Martha Twitter NomGov”、Brett Taylor、Parag Agrawal和埃隆·马斯克的群聊，与上述交织]
  • 埃隆: 感谢你们考虑让我加入Twitter董事会，但经过仔细考虑，我目前的职务承诺使我无法成为一名有效的董事会成员。未来可能会有变化。埃隆


• 2022-04-04 [与上述部分交织]:
  • Joe Rogan: 你要把Twitter从热衷审查的暴民手中解放出来吗？
  • 埃隆: 我会提供建议，他们可能会也可能不会采纳。


• 2022-04-04
  • Bret Taylor: https://twitter.com/trungtohan/status/1510994320471429131?s=10&t=qrv_fOhTfUzRVDe_IbJKlQ
  • 埃隆: [“笑”了上面的消息]


• 2022-04-04至2022-04-05 [与上述交织]
  • Parag: 你应该在邮箱里收到了更新后的协议。我有空聊天。
  • 埃隆: 批准了。
  • Parag: [“喜欢”了上面的消息]
  • Parag: 有几分钟聊天吗？我渴望快速推进。
  • 埃隆: 当然，我正在SpaceX发动机评审会议上。
  • Parag: 之后请给我打电话。
  • Parag: 我很高兴地宣布，我们将任命 @elonmusk 加入我们的董事会！通过近几周与埃隆的对话，我清楚地认识到他将为我们的董事会带来巨大价值。为什么？最重要的是，他既是这项服务的狂热支持者，也是其强烈的批评者，这正是Twitter和董事会为了我们的长期发展所需要的。欢迎埃隆！
  • 埃隆: 听起来不错。
  • 埃隆: 马上发布？
  • Parag: https://twitter.com/paraga/status/1511320953598357505?s=21&t=g9oXkMyPGFahuVNDKcoBa5A
  • 埃隆: 酷。
  • Parag: 超级兴奋！
  • 埃隆: 我也一样！
  • 埃隆: 刚和杰克进行了一次很棒的对话！你今晚晚些时候有空聊吗？
  • Parag: 有空，什么时间？
  • 埃隆: 最好能解除永久封禁，除了垃圾邮件账户和明确鼓吹暴力的账户。
  • 埃隆: 加州时间晚上7点？或者之后任何时间。
  • Parag: 7点可以！回头聊。
  • 埃隆: 几分钟后打回给你。
  • Parag: [“喜欢”了上面的消息]
  • 埃隆: 总结得相当好。
  • 埃隆: https://twitter.com/stevenmarkryan/status/1511489781104275456?s=1O&t=LprG6-7KefKLzNX133IpjQ


• 2022-04-05 [与Jared Birchall、“Martha Twitter NomGov”和埃隆·马斯克的群聊]
  • Martha: 我非常高兴你加入董事会。对于第一份协议的变动我感到抱歉-我不擅长管理律师。我真的很期待见到你。
  • 埃隆: 谢谢Martha，我也一样。


• 2022-04-05 [与上述交织]
  • Bret: 很高兴与你合作，并感激事情进展顺利。
  • 埃隆: 我也一样。


• 2022-04-05 [与上述交织]
  • jack: 感谢你加入！
  • jack: https://twitter.com/jack/status/1511329369473564677?s=21&t=DdrUUFvJPD7Kf-jXjBogIg
  • 埃隆: 绝对的。希望我能有所帮助。
  • jack: 巨大的帮助。Parag是一位出色的工程师。董事会很糟糕。随时愿意与你谈论任何你想谈的事情。
  • 埃隆: 什么时候适合保密谈话？
  • jack: 随时都可以。
  • 埃隆: 谢谢，谈话很棒！
  • jack: 永远如此！我不能更高兴你做这件事了。我期盼已久。当得知这终于成为可能时，我非常激动。
  • 埃隆: [“喜欢”了上面的消息]
  • 埃隆: 如果我做了什么蠢事或者没做什么，请一定要直言不讳。我将不胜感激。
  • jack: 我信任你，但绝对会的。
  • 埃隆: [“喜欢”了上面的消息]
  • jack: https://twitter.com/MattNavarra/status/1511773605239078914
  • jack: 看起来在绝望的泥潭里有一个“认证”账户。https://m.facebook.com/Elonmuskoffifref=nf&pn_ref=story&rc=p (还推广加密货币！)
  • 埃隆: 哈哈。
  • [2022-04-26] jack: 我想确保Parag在交易完成前尽一切努力实现你的目标。他在被赋予明确方向时非常擅长完成事情。让我、你和他通个电话讨论下一步行动并明确需要什么是否合理？这样他就能快速行动并理清。大家目标一致，这甚至会更有帮助。
  • 埃隆: 好的。
  • jack: 太好了！我会安排。我不会让它失败，会尽一切努力。这太关键了，关乎人类。
  • 埃隆: 绝对是。
  • jack: <附件-图片/jpeg-屏幕截图2022-04-226日15.05.00.jpeg>
  • jack: 我整理了一份草案清单，以使讨论更高效。目标是围绕1）我们要解决的问题，2）长期优先事项，3）短期行动达成一致，都使用你提到的更高层次指南。想想你会增加/删减什么。解决这个问题会提高速度。
  • jack: 这是会议链接，你时间晚上7点。
  • jack: [会议URL]
  • 埃隆: 很好的行动清单。
  • jack: 我们在Hangout上，等你准备好了随时开始。不着急。只是在完善文档。
  • 埃隆: [“喜欢”了上面的消息]
  • 埃隆: 它要求我登录谷歌账户。
  • 埃隆: 你和我完全一致。Parag行动太慢了，试图取悦那些无论如何都不会满意的人。
  • jack: 至少现在很清楚你们无法共事了。这很明确。
  • 埃隆: 是的。


• 2022-04-06
  • Ira Ehrenpreis [风险投资人]: 如果你计划加入提名/治理或薪酬委员会，告诉我，我可以给你一些建议！哈哈！🤪
  • 埃隆: 哈哈，我甚至不想加入Twitter董事会！他们极力推动我加入。
  • Ira: 你是个软心肠！😂
  • Ira: 而且你已经让他们尝试编辑推文功能了！哦是的...它其实已经在开发中了。当然。
  • 埃隆: 它实际上已经在开发中了，但我不知道。


• 2022-04-06至2022-04-08
  • Justin Roiland [《瑞克和莫蒂》联合创作者]: 我他妈爱你成为Twitter的大股东。我的朋友David和Daniel有一个验证身份的程序，连接到Twitter会很好。就是说，如果人们选择使用它，它可以验证他们是真实的人而不是喷子农场。我应该介绍你们认识。
  • 埃隆: 我只拥有Twitter 9%的股份，所以并不控制公司。
  • 埃隆: 会向Parag（CEO）提出身份验证问题。


• 2022-04-06至2022-04-14
  • Gayle King [CBS《今早》联合主持人，《奥普拉杂志》编辑]: 我是Gayle！你想我了吗（笑）你准备好和我坐下来好好聊聊了吗！太多要讨论了！特别是你的Twitter动作...我需要做些什么？？？另外我喜欢Twitter编辑功能带24小时时间限制...我们都会在气头上说一些后悔想收回的话...
  • 埃隆: Twitter编辑按钮即将推出。
  • Gayle: 整个Twitter事件被过度放大了。
  • 埃隆: 拥有约9%的股份并不等于控制。
  • Gayle: 我从没认为...而且我数学不好。
  • 埃隆: Twitter应该向中间靠拢，但Parag在我到来之前就认为应该如此。
  • 埃隆: [“笑”了“我从没认为...”]
  • [2022-04-14] Gayle: 埖隆！你要买Twitter还是出价买Twitter 哇！现在你不觉得我们应该面对面坐下来吗 现在的孩子们说这是一种“黑帮举动”我不知道股东怎么会拒绝...就像我说的，你和班上其他孩子不一样....
  • 埃隆: [“喜欢”了上面的消息]
  • [2022-04-18] 埖隆: 也许奥普拉有兴趣加入Twitter董事会，如果我的报价成功的话。关于人性的智慧和知道什么是对的，比所谓的“董事会治理”技能重要得多，根据我的经验，后者几乎毫无意义。


• 2022-04-07至2022-04-08 [与上述交织]
  • Parag: 围绕这一点有很多想法值得探索-甚至比这摩擦更小的。
  • 埃隆: 我有个想法可以一举两得。
  • 埃隆: 对了，你的邮箱是什么？
  • Parag: [...]
  • Parag: 你下周能虚拟参加员工问答环节吗？我的行程导致延迟太久，而且只有约10-15%的听众会亲自到场，所以无论如何我们会为虚拟优化。下周三/四太平洋时间上午11点对你来说哪天方便进行45分钟的视频问答？-否则我可以建议其他时间。试图最大化跨全球时区的参与度。
  • Parag: 下次交谈时很想听听更多-你明天有空吗？
  • 埃隆: 当然。
  • 埃隆: 听取Twitter工程团队的最新进展会很好，这样我的建议就不会那么愚蠢。
  • Parag: 是的-会在问答之前安排一次产品+工程对话-他们说，我预计大多数问题不会深入具体想法/深度-而是更多围绕你对Twitter未来的看法、为什么它重要、你个人为什么想参与、你希望看到什么改变...-但也有一些来自那些不高兴你参与并且通常因为某种原因不喜欢你的人。正如你昨天所说，目标是让人们直接听你说话，而不是根据媒体故事对你做假设。下周四太平洋时间上午11点进行问答可以吗？
  • 埃隆: 太平洋时间周三上午11点很棒。
  • 埃隆: 确实如此。周四太平洋时间上午11点可以。
  • Parag: 好的酷。那么将确认周三太平洋时间上午11点与少数工程和产品负责人进行交谈。周四太平洋时间上午11点进行AMA。
  • Parag: 另外：我发给公司的关于AMA的邮件已经泄露了+内部Slack消息有很多泄露：https://www.washingtonpost.com/technology/2022/04/07/musk-twitter-employee-outcry/ -我认为很大一部分沉默的多数对你加入董事会感到兴奋，所以这不具有代表性。乐意讨论-这些都不意外。
  • 埃隆: 黄色。
  • 埃隆: *太棒了（该死的自动更正！）
  • 埃隆: 如预期。是的，同步一下会很好。我明天晚上或这个周末任何时间都可以。我喜欢我们的对话！
  • Parag: 明天太平洋时间下午5:30之后我完全灵活-告诉我什么时间合适。是的，这是预期的-我认为这有助于推动公司向积极方向发展。尽管内部动荡-我认为这对推动公司前进非常有帮助。
  • 埃隆: 太棒了！
  • 埃隆: 我有很多想法，但如果你觉得我逼得太紧就告诉我。我只想让Twitter变得尽可能棒。
  • Parag: 我想听听所有的想法-然后我会告诉你哪些我会推进，哪些不会。以及为什么。
  • Parag: 在这个阶段-只是花时间和你在一起很好。+让我的产品和工程团队与你交流，以便双方吸收信息。
  • 埃隆: 我想了解Twitter代码库的技术细节。这将帮助我评估我的建议有多愚蠢。
  • 埃隆: 我写了20年的重型软件。
  • Parag: 我曾是CTO，在我们的代码库中待了很长时间。
  • Parag: 所以我可以回答你很多问题。
  • 埃隆: 我与能够进行硬核编程的工程师交流比与项目经理/MBA类型的人交流效果好得多。
  • 埃隆: [“喜欢”了“我曾是CTO...”]
  • 埃隆: 🔥🔥
  • Parag: 在下次交谈时-把我当作工程师而不是CEO，看看我们能走到哪里。交谈之后我会知道谁可能是最适合连接你的人。
  • 埃隆: 坦白说，我讨厌做管理类工作。我其实觉得任何人都不应该成为任何人的老板。但我喜欢帮助解决技术/产品设计问题。
  • 埃隆: 你说了算！
  • Parag: 期待明天的交谈。你喜欢日历邀请发送到你的邮箱地址吗？
  • 埃隆: [“喜欢”了上面的消息]
  • 埃隆: 我已经把两个日期放在我的日历上了，但给我补充资料也没问题。
    
  • Parag: 如果你想聊聊Twitter的工程方面，我现在就有空。告诉我！
  • 埃隆: 大约45分钟后打电话？
  • Parag [“喜欢”了上面的消息]
  • 埃隆: 稍后打回。
  • 埃隆: <附件• 图片/png-屏幕截图2022年4月8日晚上10:10:09.png>
  • 埃隆: 我真受够了这种东西。
  • Parag: 我们应该发现这个。
  • 埃隆: 是的。


• 2022-04-09至2022-04-24
  • Kimbal Musk [埃隆的弟弟，The Kitchen Restaurant Group所有者]: 我有一个区块链社交媒体系统的想法，可以同时处理支付和类似Twitter的短文本消息/链接。你必须支付少量费用来注册你链上的信息，这将消除绝大多数垃圾邮件和机器人。没有喉咙可以扼杀，所以言论自由得到保证。
  • Kimbal: 谜题的第二部分是一个大规模的实时数据库，内存中保存所有区块链消息的副本，以及你、你的关注者和你关注的人发送或接收的所有消息。
  • Kimbal: 第三部分是手机上类似Twitter的应用程序，访问云端数据库。
  • Kimbal: 这可能会非常庞大。
  • Kimbal: 我想了解更多。我深入研究了Web3（不是太多加密货币），投票权非常强大且经过验证。在这里也可以做很多事。
  • 埃隆: 我认为需要一家基于区块链并包含支付功能的新社交媒体公司。
  • Kimbal: 会让他们用与服务相关的代币支付吗？你必须在钱包中持有代币才能发推。不一定贵，它会随着时间增值。
  • Kimbal: 区块链防止人们删除推文。有好有坏，但让游戏开始吧！
  • Kimbal: 如果你使用自己的代币，你就不需要广告，这是一种付费使用的服务，但价格很低。
  • Kimbal: 随着规模扩大，它将成为一个巨大的业务，纯粹造福用户。我讨厌广告。
  • 埃隆: [“喜欢”了上面的消息]
  • Kimbal: 有一些好的广告。感兴趣用户（仅当您想时）的投票组成部分可以对增加价值的广告进行投票。广告商必须质押大得多的代币，但除此之外广告没有费用。它将激发创造力，广告可以政治不正确/艺术/激进主义/慈善事业。
  • Kimbal: 投票权也可以众包踢出骗子。当我看到有人宣传你赠送比特币的骗局时，真让我抓狂。有很多坏人。
  • [2022-04-24] 埖隆: 你想参与Twitter交易吗？
  • Kimbal: 我们明天讨论吧。
  • 埃隆: 好的。
  • Kimbal: 我经常可以从我的团队中抽身。明天下午会发短信，如果你有空我们可以见面。
  • 埃隆: 好的。


• 2022-04-09 [与上述交织]
  • Parag: 你有权发推说“Twitter要完了吗？”或任何其他关于Twitter的话-但我的责任是告诉你，这在当前情况下无助于我改善Twitter。下次我们谈话时，我想向你说明目前的内部干扰程度，以及它如何损害我们工作的能力。我希望AMA能帮助人们了解你，理解你为什么相信Twitter，并信任你-我希望公司能变得更加坚韧，不受干扰，但我们目前还没有达到那个水平。
  • 埃隆: 你这周完成了什么？
  • 埃隆: 我不加入董事会了。这是浪费时间。
  • 埃隆: 将提出将Twitter私有化的报价。
  • Parag: 我们能聊聊吗？


• 2022-04-09至2022-04-10 [与上述交织]
  • Bret: Parag刚才给我打电话，提到了你们的短信对话。你能谈谈吗？
  • 埃隆: 请期待私有化要约。
  • Bret: 我看到了短信内容。你能给我五分钟时间理解一下背景吗？我目前还不...
  • 埃隆: 通过和Parag聊天来修复Twitter行不通。
  • 埃隆: 需要采取激烈行动。
  • 埃隆: 作为一家上市公司很难做到这一点，因为清除虚假用户会让数字看起来很糟糕，所以重组应该作为一家私营公司进行。
  • 埃隆: 杰克也是这么认为的。
  • Bret: 你能花10分钟和我谈谈这个问题吗？自从你加入董事会以来已经大约24小时了。我明白你的观点，但只是想理解一下突然的转变，并确保我深入理解你的观点和前进道路。
  • 埃隆: 我马上要起飞了，但明天可以谈。
  • Bret: 谢谢你。
  • Bret: 嘿-今晚能谈谈吗？我看到了你的推文，更迫切地想了解你的前进道路。
  • [第二天] Bret: 确认你昨天与Parag的短信，你拒绝加入董事会。这将在我们明天的8-K文件中体现。我已要求我们的团队今天将草案发送给你的家族办公室。我期待今天的谈话。
  • 埃隆: 听起来不错。
  • 埃隆: 在我看来，将Twitter私有化、重组并重返公开市场更好。这也是杰克与我交谈时的观点。


• 2022-04-12
  • Michael Kives [好莱坞人才经纪人]: 明天有空在温哥华见Philippe Laffont吗？
  • 埃隆: 也许吧。
  • Michael: 什么时间最好？
  • Michael: 任何时间最好？
  • 埃隆: 他到底想要什么？
  • Michael: 有一些关于Twitter的想法 拥有特斯拉十亿美元 曾参与最后两轮SpaceX融资 -并且想未来参与Boring Company（我告诉他帮助招聘）你真的可以在你的酒店待20分钟 他非常聪明，好人。
  • 埃隆: 好的，他今晚可以过来。香格里拉酒店1001房间。
  • Michael: 需要给你找个好助理！我要去睡了 我会告诉Philippe今晚降落时给你发邮件，以防你还醒着想见面。
  • Michael: https://twitter.com/sbf_ftx/status/1514588820641128452?s=21&tZ4pA_Ct35ud6M60g3ng
  • Michael: 和Sam Bankman-Fried一起做这个可能很酷。
  • [2022-04-28] 埖隆: Twitter显然不会变成某种右翼疯人院。目标是尽可能广泛地包容。为绝大多数美国人做正确的事。
  • Michael: [“喜欢”了上面的消息]


• 2022-04-13至2022-04-15
  • 埃隆致Bret: 经过几天的深思熟虑-这显然是一个极其严肃的问题-我决定推进将Twitter私有化。我今晚将给你发送报价函，明早将公开。如果你有任何问题，乐意将你与我的团队联系。谢谢，埃隆
  • Bret: 已收到。
  • Bret: 确认我收到了你的邮件。另外，请使用 [...] 作为我的个人邮箱。
  • 埃隆: 会的。
  • [2022-04-14] Bret: 埖隆，正如你在我们的新闻稿中看到的，董事会已收到你的信函，正在评估你的提案，以确定其认为对Twitter及其所有股东最有利的行动方案。我们将在完成这项工作后与你联系。Bret
  • 埃隆: 听起来不错。
  • [2022-04-17] Bret: 埖隆，我只是确认一下，董事会正在认真审查你信中的提案。我们正在尽快

由 mimo-v2.5 模型翻译，花费 47956 tokens

本文思路是基于独立选定的一组预测者（维基百科的知名未来学家列表¹）的预测进行研究。这些预测的时间足够长，可以评估其效果，从而理解哪些预测技术有效，哪些无效。这样我们就可以（主要在未来的文章中）评估使用类似方法的预测的可信度。

不幸的是，从独立选择的列表中，每位预测者的记录都很差。而抽查其他未来学家的一些预测后发现，未来学家们的预测记录往往相当糟糕。因此，为了对比有效的技术和无效的技术，我从记忆中选取了一些有不错记录的预测者，这是一个非独立的来源，引入了许多潜在偏差。

让我比通常更有信心的一点是，我在完成本文的评估并写下98%的内容之前，避免阅读对预测方法的独立评估。在阅读其他人的评估后，我发现我与特特洛克（Tetlock）的《超级预测者》（Superforecasting）在哪些方法有效、哪些无效的看法大致一致，尽管我们使用了完全不同的数据集。

具体而言，那些热衷于“宏大理念”、用少数几个大锤子套用在每个预测上，并且对特定主题的理解仅限于“鸡尾酒会想法”水平的人，无论他们偏爱的宏大理念是否正确，其预测效果通常很差。一些“宏大理念”的例子包括“环境末日即将来临，超级保护主义将渗透一切”、“经济增长将很快创造近乎无限的财富”、“摩尔定律极其重要”、“量子力学极其重要”等。表现不佳的预测者的另一个共同特征是，他们几乎从不认真评估过去的预测错误，这使得提升他们的直觉或方法变得不可能（除非他们私下进行）。相反，他们常常挑选几个准确或至少听起来与准确预测模糊相似的例子，以此向他人兜售他们的下一代预测。

相比之下，那些拥有（相对）准确预测的人对问题有深刻理解，并且往往有从过去的预测错误中吸取教训的记录。由于本文与特特洛克研究的数据集存在差异，这里的细节相当不同。我发现相对准确的预测者拥有深厚的领域知识，并且隐含地接触到了大量信息，他们能有效过滤这些信息以做出好的预测。特特洛克研究的是那些对广泛领域做出预测的人，这些领域通常超出了他们的专业范围，因此他发现的是，这些人深入钻研数据并深刻理解数据的局限性，从而做出相对准确的预测。但是，尽管人们运作方式的细节不同，但在高层次上，真正深入特定知识的做法是一致的。

由于本文篇幅很长，本文将包含每个预测者的非常简短的总结，然后是对每个预测者的中等长度总结。接着，我们将总结哪些技术和风格有效，哪些无效，完整的预测评分细节以及与其他评估者的比较将附在附录中。

• 雷·库兹韦尔（Ray Kurzweil）：准确率7%
  • 依赖于：指数或超指数增长必然持续；基于过去趋势的延续预测未来；乐观地“上调”事实和对数据的解释；关于技术和计算机的“万能药思维”（panacea thinking）；在预测主题上使用“鸡尾酒会想法”级别的理解
• 雅克·弗雷斯科（Jacque Fresco）：预测大多过于遥远而无法判断，但对于可判断的预测似乎准确率极低
  • 依赖于：关于人性、科学方法和计算机的万能药思维；确信人类价值观与弗雷斯科的价值观一致
• 巴克敏斯特·富勒（Buckminster Fuller）：预测太少无法评分，但对于可判断的预测似乎准确率极低
  • 依赖于：在预测主题上使用“鸡尾酒会想法”，其程度即使对未来学家来说也极为极端
• 米奇奥·卡库（Michio Kaku）：准确率3%
  • 依赖于：关于“量子”、计算机和生物技术的万能药思维；这些领域的指数增长
• 约翰·奈斯比特（John Naisbitt）：预测过于模糊无法评分；在大局准确性方面结果参差不齐，可能比这里除了迪克森（Dixon）之外的任何未来学家都好，但这与给出其他预测者的百分比不具可比性
  • 依赖于：基于报纸分析的趋势预测
• 杰勒德·K·奥尼尔（Gerard K. O'Neill）：预测大多过于遥远而无法判断，但对于可判断的预测似乎准确率极低
  • 依赖于：与其他未来学家错误做法相反的方式，可描述为基于近期涨幅较大的价格“试图低买高卖”；在奥尼尔认为被低估的领域乐观地“上调”事实和对数据的解释；在预测主题上使用“鸡尾酒会想法”
• 帕特里克·迪克森（Patrick Dixon）：准确率10%；在“大局”预测方面也远优于这里的任何其他未来学家（但与非未来学家预测者如耶格（Yegge）、盖茨（Gates）等不在同一水平）
  • 依赖于：推断现有趋势（但乐观上调的程度远低于这里几乎任何其他未来学家）；指数增长；“第二千年思维”和“第三千年思维”之间的鲜明分野
• 阿尔文·托夫勒（Alvin Toffler）：预测大多过于模糊无法评分；在非模糊预测中，托夫勒有一种不可思议的本事，即在一个趋势即将停止时，将其标记为非常重要且可能持续
  • 依赖于：已发生的指数增长必然持续；各种受指数增长预期启发的“鸡尾酒会想法”混合体
• 史蒂夫·耶格（Steve Yegge）：准确率50%；对未来的总体愿景通常相当准确
  • 依赖于：深厚的领域知识，流入亚马逊和谷歌的信息流；观察正在兴起的事物
• 布莱恩·卡普兰（Bryan Caplan）：准确率100%
  • 依赖于：接受人们对错误赌注/预测的“另一面”，并且主要依赖于做出非常保守的预测
• 比尔·盖茨/内森·梅尔沃德（Nathan Myhrvold）/旧微软领导层：预测时间框架过于模糊无法评分，但对未来的愿景以及各种技术的相对重要性有着不可思议的准确性
  • 依赖于：深厚的领域知识，许多拥有深厚领域知识的人之间的讨论，流入微软的信息流

雷·库兹韦尔

雷·库兹韦尔声称其预测准确率为86%，这一说法经常被重复，例如彼得·迪亚曼迪斯（Peter Diamandis）所说：

自1990年代以来，库兹韦尔做出了147项预测，其中完全正确的有115项，另有12项被证明“基本正确”（相差一两年），这使得他的预测达到了惊人的86%准确率。

这篇文章的标题是“谷歌高管声称奇点将在2029年之前发生”，开头写道：“谷歌工程总监雷·库兹韦尔是一位著名的未来学家，拥有高命中率的准确预测记录。”它引用了维基百科上的这份预测列表。86%对于非显而易见的、重大的未来预测来说是一个惊人的好记录。这个说法似乎是其他人声称库兹韦尔具有高准确率的来源，例如这里和这里。我自己检查了迪亚曼迪斯引用的维基百科列表的准确率（使用archive.org获取他文章发表时的列表），发现准确率较低，为7%。

从根本上说，导致库兹韦尔许多预测失败的原因是，他依赖于这样一个观点：在他能想象到的几乎每个领域，以及在一些确实有重大增长的领域，增长都以指数级和加速方式进行，但增长并未达到他的预期。他的基本论点是，由于技术进步（改进技术等），我们不仅有指数增长，而且技术进步的反馈会加速指数增长，因此我们在许多重要领域（如计算机性能）拥有双指数增长（如e^x^x，不是2*e^x）。他反复谈论这种不可阻挡的指数或超指数增长，例如，他在1990年的书《智能机器时代》（The Age of Intelligent Machines）中说“我们可以对未来做出的一个可靠预测是，变化的步伐将继续加速”，并在1999年的书《精灵机器时代》（The Age of Spiritual Machines）、2001年关于加速技术增长的文章“加速回报定律”（The Law of Accelerating Returns）、2005年的书《奇点临近》（The Singularity is Near）等中再次讨论了这一点。

值得注意的一点是，尽管他早期工作中绝大多数可证伪的预测都是错误的，库兹韦尔每次仍继续使用相同的方法生成新的预测，这让人想起安德鲁·格尔曼（Andrew Gelman）关于预测者反复预测同一事物，即使面对旧预测错误的证据时的讨论。例如，他在2005年的《奇点临近》中指出“S曲线”的存在，即任何特定“事物”的增长不一定是指数级的，但正如他在1990年所做的那样，他得出结论认为指数增长将持续，因为某些新技术必然会被发明出来，从而使指数增长得以继续，并且“加速回报定律适用于所有技术，实际上适用于任何进化过程。它可以在基于信息技术的领域用非凡的精确度描绘出来，因为我们有明确定义的指数（例如，每美元每秒的计算次数，或每克每秒的计算次数）来衡量它们”。

2001年，他使用这种方法绘制图表，然后预测2011年之前人类寿命将是无限的（下面的引文在寿命无限方面并不明确，但如果你阅读整篇文章或他对寿命预测的澄清，就明确了，他说“我不是指基于出生日期的预期寿命，而是指你的剩余预期寿命”）：

你们中的大多数人（再次使用复数形式）很可能将看到奇点的到来。人类预期寿命的延长是另一个指数级趋势。在18世纪，我们每年为人类寿命增加几天；在19世纪，我们每年增加几周；而现在我们每年增加将近半年。随着基因组学、蛋白质组学、合理药物设计、我们自己器官和组织的治疗性克隆以及生物信息科学相关领域的革命，我们将在十年内每年增加超过一年。

库兹韦尔将预期发生日期推后了一年多（我最近看到的一次是2016年预测我们将在2029年之前拥有无限的预期寿命），这是库兹韦尔许多预测的特点。

许多人都说库兹韦尔的方法荒谬，因为指数增长在现实世界中不可能无限期持续，但库兹韦尔在他1990年的书《智能机器时代》中解释了为什么他认为这是不正确的：

这项新技术的一个显著方面是它几乎不使用自然资源。硅芯片使用微量的沙子和其他容易获得的材料。它们使用微不足道的电量。随着计算机变得越来越小，它们所使用的物质资源正在变得与其价值无关紧要。实际上，软件根本不使用任何资源。

我们正在进入一个自然资源丰富的世界，因为资源和电力与计算机无关，到目前为止这并不正确，但对库兹韦尔来说幸运的是，他预测会无限期持续的许多指数和双指数过程，在自然资源限制发挥作用之前很久就停止了，因此这不是库兹韦尔预测错误的主要原因，但如果他的预测不那么不准确的话，这可能会成为主要原因。

在元层面上，库兹韦尔方法的一个问题是，他倾向于“上调”以使增长看起来比实际更快，以符合他的模型。例如，在“加速回报定律”中，我们注意到库兹韦尔基于加速的预期寿命，预测2011年之前人类寿命将是无限的，当时“我们现在每年增加将近半年”。然而，美国的预期寿命增长（根据他的评论，这似乎是库兹韦尔写作的主要内容）每年仅为0.2年，长寿人群为每年0.1年，而全球预期寿命每年为0.3年。虽然从技术上讲，如果你四舍五入到最近的0.5，你可以将0.3四舍五入到0.5，但当你试图猜测何时会实现无限寿命时，这样做非常不合理，因为世界预期寿命的高增长率主要来自“追赶增长”，即大幅减少导致“非自然”缩短寿命的因素。

如果你想预测高端会发生什么，看看高端寿命的增长更有意义，而高端寿命的增长要慢得多。库兹韦尔“上调”的另一个方式是选择了一种框架，使其看起来我们正在看到预期寿命的极快增长。但是，如果我们简单地绘制自1950年以来的预期寿命随时间变化的图表，我们可以看到增长大致是线性的，并趋向于亚线性（即使在库兹韦尔写作时的2001年切断图表也是如此），其中有一些超线性时期，但最终趋向亚线性。库兹韦尔说他是使用指数等查看增长曲线的粉丝，但在这种情况下，他本可以轻松做到，却选择从空气中挑选一些数字，因为他“标准”的查看增长曲线的方法会导致对预期寿命增长放缓的相当无聊的预测，因此这里有三种上调在起作用：选择一个不合理的乐观数字、将该数字上调，然后选择性地不在时间序列上绘制大量点以描绘库兹韦尔想要呈现的画面。

库兹韦尔的“上调”也是他得出以下预测的原因，其中包括计算机性能/尺寸/成本和经济增长将遵循双指数轨迹。对于计算机成本/晶体管尺寸，库兹韦尔在硅片缩放曲线上绘制了多个点，加上一个来自硅片时代之前的一个非常古老的点，那时晶体管尺寸处于不同的缩放曲线上。然后，他拟合了一条似乎是三次曲线，由于三次曲线“倾向于”在未来具有高增长或高反增长，而前硅片点将三次曲线拟合在过去的很低位置，因此三次曲线拟合必须“倾向于”在未来上升，而库兹韦尔将这种三次增长上调为指数增长。这在库兹韦尔写作时晶体管缩放曲线的支持也非常薄弱。作为一个当时关注ITRS路线图的人，我记得ITRS设定了一个预测的摩尔定律缩放曲线，半导体公司竞相超越曲线，短暂地实现了看似超指数的缩放，因为他们会持续超越以摩尔定律为基准的路线图。然而，任何真正了解情况细节的人，或者与半导体工程师交谈过的人，而不是仅仅看缩放曲线，就会知道人们普遍认为超指数缩放是暂时的、不可持续的，并且登纳德缩放的终结以及晶体管延迟主导（而非互连延迟主导）的高性能处理器即将出现，这意味着晶体管尺寸的指数缩放不会带来以前伴随着晶体管缩放的历史性计算机性能提升；这种预期如此普遍，以至于当时在本科课程中就被讨论过。任何花最短时间了解半导体缩放的人，在库兹韦尔谈论我们正在进入双指数缩放时代的时，都会知道这些事情，并且会认为我们能幸运地拥有计算机性能的通用单指数缩放就不错了，但由于库兹韦尔观察的是曲线的总体形状而不是机制，这些知识并没有影响他的预测，而且由于库兹韦尔上调现有证据以支持他对增长加速加速的观点，他能够找到一组支持他寻求的曲线拟合的选择性数据点。

我们将在这里讨论的其他未来学家以及附录中讨论的长期主义者中看到这种类型的上调，我们还会反复看到一些相同的主题，特别是指数增长以及技术改进导致技术改进速率加速，从而产生更快的指数增长的观点。

雅克·弗雷斯科

1969年，雅克·弗雷斯科写了《展望未来》（Looking Forward）。弗雷斯科声称，通过了解人们未来的价值观，然后由此推导出未来可能的样子，就可以预测未来。弗雷斯科没有描述如何知道人们未来的价值观，并假设人们会拥有他自己的价值观，人们可能会将其描述为60/70年代的嬉皮士价值观。他用来预测未来的另一个主要机制是，未来的人们将更加科学并运用科学方法。

他写道，“科学方法”只被有限地应用，这导致了数千年的缓慢进步。但是，与20世纪不同，在21世纪，人们将摆脱偏见，并在生活的所有领域应用“科学方法”，而不仅仅是在做科学时。人们将完全开放地在生活的各个方面进行实验，并且所有人都将“习惯性地保持开放心态，同时严格坚持所有问题的表述方式必须允许事实核查”。

这将导致所有人都完全了解自身的局限性，并且由于次优的政治和社会结构而导致的不快乐将终结。

弗雷斯科用来推导其预测的第三个主要机制是，计算机将能够解决人们能想象到的几乎任何问题，而制造技术也将类似地发展。

弗雷斯科预测中起作用的每个主要机制都与魔法无异。如果在某个领域能想到一个问题，该机制就能解决它。当时还有其他魔法机制在起作用，通常是当时流行的想法。例如，行为主义和操作性条件反射在当时非常流行，因此弗雷斯科假设整个社会将能够通过操作性条件反射摆脱可能存在的任何社会问题。

尽管弗雷斯科的大多数预测在技术上尚无法判断，因为它们是关于遥远未来的，但对于他已经做出的、时间已到的预测，我没有看到一个准确的预测。

巴克敏斯特·富勒

富勒以发明测地线圆顶而闻名，尽管测地线圆顶实际上是由瓦尔特·鲍尔斯费尔德（Walther Bauersfeld）在富勒“发明”它们几十年前制造的。富勒也以其各种其他创作而闻名，例如戴马克松汽车，以及他的未来主义预测。

我找不到包含富勒大量预测列表的优质来源，但我找到了这次采访，其中他做出了一些预测。富勒基本上是用词语进行自由联想，通过词语的英文含义来做出预测（例如，传送预测），或者有时是更模糊的联系。

来自视频的预测：

• 我们将能够通过无线电发送人，因为原子有频率，无线电波也有频率，所以有可能拾取我们所有的频率并通过无线电发送它们
• 欠发达国家（相对于高度发达国家）将能够“通过月球”获得最先进的技术
  • 我们将在月球上放人一年，这将需要将相当于一英里直径的地球活动放入一个重500磅的小黑匣子中，以便月球上的人能够在当地像在地球上一样运作
  • 这将导致每个人都意识到他们只需要一个小黑匣子，就不再需要当地的下水道系统、水、电力等。
• 人类将完全自动化地摆脱体力劳动
  • 中国和印度的生产能力将无关紧要，唯一重要的是谁能“获得”中国和印度的消费者
• 将有一个关于财富是什么的现实记账系统，这实际上与能量有关，因为能量守恒定律，这也意味着财富不会恶化和丢失
  • 财富只能增加，因为能量既不能被创造也不能被毁灭，当你做一个实验时，你只能学到更多，所以财富只能被创造
  • 这将使整个世界成功

对于那些听说过富勒预测比特币创造的人，最后一个关于财富记账系统的预测就是人们所指的。通常，这样说的人并没有实际听过他陈述整个预测的采访，他们自己也在使用富勒的自由联想方法。比特币来自花费能源来挖掘比特币，而富勒预测未来将有一个基于能源的财富系统，因此富勒预测了比特币的创造。如果你实际听了采访，比特币甚至不接近满足富勒所描述系统的属性，但如果你做富勒式的自由联想，这并不重要。

在本文中，富勒的预测评分比几乎其他任何人都少，所以如果我们有一个大约100个预测的列表，他的准确率会是多少尚不清楚，但我能找到的预测准确率为0%。

米奇奥·卡库

在维基百科的未来学家列表中，米奇奥·卡库可能相对知名，因为作为他科学普及工作的一部分，自2006年以来他有一个全美（美国）联合广播节目，并且经常出现在脱口秀节目中，接受新闻机构的采访。

在他的1997年著作《愿景：科学将如何彻底改变21世纪》（Visions: How Science Will Revolutionize the 21st Century）中，卡库解释了为什么其他未来学家的预测不太准确以及为什么他的预测与众不同：

……大多数对未来的预测都失败了，因为它们反映了一个个体古怪、常常狭隘的观点。

《愿景》则不是这样。在撰写众多书籍、文章和科学评论的过程中，我在十年期间有幸采访了来自不同学科的150多位科学家。

基于这些采访，我努力谨慎地界定某些预测将在何时实现，何时不会实现。科学家预计某些预测将在2020年之前实现；其他预测则要到更晚的时候——从2050年到2100年——才会实现。

卡库还声称他的预测比许多其他未来学家更准确，因为他是物理学家，以物理学家的方式思考问题可以实现准确的未来预测：

我认为，《愿景》与媒体上的预测之间存在一个重要区别。《愿景》涉及科学家本身的新兴共识，而媒体上的预测几乎完全由作家、记者、社会学家、科幻作家和其他技术的消费者做出，而不是由那些帮助塑造和创造技术的人做出。 …… 作为一名研究物理学家，我相信物理学家在预测未来的轮廓方面特别成功。在职业上，我在物理学最基础的领域之一工作，即追求实现爱因斯坦的“万有理论”之梦。因此，我不断提醒自己量子物理学如何触及了许多塑造二十世纪的关键发现。

过去，物理学家的记录是惊人的：我们深入参与引入了许多关键发明（电视、收音机、雷达、X射线、晶体管、计算机、激光、原子弹），解码DNA分子，通过PET、MRI和CAT扫描开辟了探测身体的新维度，甚至设计了互联网和万维网。

他还特别指出库兹韦尔的预测荒谬，说库兹韦尔对“未来几十年做出了荒谬的预测，从火星度假到消灭所有疾病”。

尽管卡库认为库兹韦尔的预测荒谬，但他的预测依赖于库兹韦尔依赖的一些相同机制。例如，卡库假设商品/原材料价格在不久的将来会暴跌，因为技术的进步会使原材料变得不那么重要，卡库还假设计算机芯片的性能和成本缩放将继续其在70年代和80年代的历史路径。像维基百科列表中的大多数其他未来学家一样，卡库也假设科学进步的步伐将迅速加快，尽管他的理由不同（他引用了量子力学、计算机科学和生物学这些重要领域之间日益增长的协同作用，他说这些领域如此重要，“未来若不具备对所有这些领域的基本工作知识，将很难成为研究科学家”）。

卡库假设紫外线光刻将耗尽动力，我们将不得不切换到X射线或电子光刻，而光刻也会耗尽动力，需要我们切换到完全不同的计算机基底（光学、分子或DNA）以保持性能和缩放的轨道，但其他基本计算基底的进步没有迅速实现，导致卡库的预测未能实现。卡库赋予他认为具有“量子”效应的东西非常高的权重，这就是为什么例如他认为微处理器到2020年将过时（它们不是“量子”的），而光纤不会过时（它们依赖于“量子”机制）。尽管卡库批评其他未来学家在对其讨论的主题没有真正理解的情况下做出预测，但不清楚卡库是否对讨论的许多主题有更好的理解，尽管作为物理学家，卡库具有更相关的背景知识。

上述未实现的假设组合导致卡库在《愿景》中的预测准确率相当低。

我没有读完《愿景》，但我读的那部分书（从开头到中间某处，以避免挑选）的预测准确率是3%（如果你给我完全分的那个预测一半分数，可以说是6%）。他做出了许多我没有评分的预测，他在其中说某些事情“可能”会发生。这样的预测当然是无法证伪的，因为无论事件是否发生，该陈述都是正确的。

约翰·奈斯比特

任何经常逛旧书店打折区的人都会在《大趋势》（Megatrends）的封面上看到这个名字，它肯定与李·艾柯卡（Lee Iacocca）的自传一样，是最常见的打折区填充物之一。

奈斯比特声称他能够通过对报纸进行“内容分析”来准确预测未来，他说这在二战期间曾用于提供深刻的见解，并且此后被情报界广泛使用，但直到他这样做之前从未在商业上应用过。奈斯比特解释说这之所以有效，是因为报纸的空间是固定的（显然报纸不能被创造或毁灭，也不能决定印刷更多或更少的新闻，或者决定印刷内容的编辑转变不会在更大社会中反映相同的改变）：

为什么我们如此确信内容分析是监测社会变化的有效方法？简单地说，因为报纸上的新闻空间是一个封闭系统。出于经济原因，报纸上用于新闻的空间量随时间推移不会发生显著变化。因此，当引入新内容时，其他内容或内容组合必须被省略。不减去就无法增加。这是封闭系统中的强制选择原则。

不幸的是，几乎无法判断奈斯比特的预测，因为他几乎只处理模糊的、像占星术一样的预测，这些预测很难被判断为正确或错误。如果你只是阅读《大趋势》来感受每章的基调，而不试图挑出单个预测，有些章节看起来相当好，例如“工业社会 -> 信息社会”，但即使你非常慷慨地给他的模糊预测评分，有些章节也绝对喜忧参半。这无法与本文中的其他未来学家进行比较，因为让模糊的预测听起来大致正确比让精确的预测正确要容易得多，但即便如此，如果是为了感受未来可能的方向而阅读，奈斯比特的预测比讨论的任何其他未来学家都要准确得多。

话虽如此，就我在他书中的阅读范围而言，我能找到的唯一具体预测是错误的，因此如果你想让奈斯比特与这里讨论的其他未来学家进行可比的评分，你可能会说他的准确率是0%，但误差范围很广。

杰勒德·K·奥尼尔

奥尼尔有两本相对知名的非虚构类未来主义书籍，《2081》（2081）和《技术优势》（The Technology Edge）。《2081》写于1980年，预测了此后100年的未来。《技术优势》讨论了奥尼尔认为美国在1983年需要做什么才能避免被日本淘汰。

奥尼尔花在讨论为什么以前的未来学家错了的篇幅比任何其他讨论中的未来学家都多。奥尼尔指出，“大多数[未来学家]高估了社会和政治变革对世界的改变程度，低估了技术变革的力量”，并引用吉卜林（Kipling）、凡尔纳（Verne）、威尔斯（Wells）、霍尔丹（Haldane）和贝拉米（Ballamy）作为这样做的例子。奥尼尔还说，“科学家往往高估了重大科学突破的机会，低估了在现有知识范围内直接发展的影响”，并再次引用霍尔丹。奥尼尔还引用太空飞行作为过去未来学家的一个重大失误，说他们往往低估了太空飞行发展的速度。

奥尼尔还说，即使不知道变革的确切机制，也有可能预测未来。例如，他声称即使内燃机没有被发明，汽车也可以被安全地预测，因为蒸汽也可以工作。但他接着说，有些事情是不可预测的，比如收音机、电视和电子通信，尽管这些的基础发现于1865年，并且基础发现与应用之间的时间间隔“通常相当长”，引用量子力学到集成电路是30-50年，相对论到超光速旅行是100多年，核能的发明至今没有“深刻影响”是50多年。

我认为奥尼尔从未真正令人信服地解释过为什么他的预测属于“汽车”类型。相反，他依靠做与他认为别人错误相反的事情。结果是他预测太空飞行的巨大进步，说我们应该期望到2081年有大规模的太空旅行和殖民，预示着2000年之前无线传输能源（指从卫星发射的能量）和2025年之前星际探测器（大概是不同于1977年发射的旅行者探测器的类别）。

1981年，他说“一支由1990年代的可重复使用飞行器组成的机队，数量远少于当今世界商用喷气式运输机队，将足以每年为数亿人提供进出太空的运输”，预测比美国宇航局航天飞机更先进的东西不久后就会生产出来。继续这种进步，“到2010年左右，将有许多太空殖民地存在，每年都有许多新的在建”。

奥尼尔的大部分预测是针对2081年的，但他确实偶尔做出1981年之前的预测。我能找到的所有可证伪的预测都是错误的，准确率约为0%，但误差范围相当大。

帕特里克·迪克森

迪克森以撰写《未来智慧》（Futurewise）而闻名，但他有很多关于未来的预测书籍。在本文中，我们只看《未来智慧》，因为它是迪克森最具预测导向的书，并且足够老，我们应该能够对他相当多的预测做出判断（《未来智慧》来自1998年；他另一本明显的候选书是《几乎所有事情的未来》，来自2015年，展望一个世纪）。

与本文中的大多数其他未来学家不同，迪克森在《未来智慧》中并没有明确说明你为什么应该信任他的预测，尽管他在致谢中隐含地这样做了，他提到与许多非常重要的人有过互动。

我非常感谢数百位高级管理人员，他们通过参与“未来的六个面孔”演讲塑造了这本书。内容是根据他们自身的经验铸造的。

尽管他没有明确提到自己，但他说商业成功将来自于倾听那些有远见的人：

那些经常正确的人会发大财。未来的趋势寻找将与七八十年代大不相同，那时一切更加确定。在一个全球化的市场中，有太多的变量，反向投影和正向投影无法可靠地工作……这就是为什么经济学家在涉及新技术时不能成为好的未来学家，以及为什么这么多大型公司的董事会在涉及2000年以后的思维量子跃迁时如此混乱的原因。

第二千年思维永远不会让我们到达那里……一家财富1000强公司的资深董事会成员最近告诉我：‘我很高兴我要退休了，这样我就不必面对这些决定’……‘我们能做什么？’另一位高管宣称……

后来，在《几乎所有事情的未来》中，迪克森列出了他所说的在写《未来智慧》时有效的方法，这些方法“经受住了17年以上的考验”。迪克森说：

所有可靠的、长期的预测都是基于强大的超级趋势，这些趋势在过去30年里推动了深刻、一致且相对可预测的变化。这些趋势是每个精心构建的公司战略和政府政策的基础 …… 这些更广泛的趋势对像我这样的大多数趋势分析师来说已经显而易见一段时间了，并且在过去20-30年里得到了很好的描述。它们的发展比繁荣与萧条，或社会时尚要慢得多。

并列出了趋势，例如：

• 大多数大规模生产物品的生产成本下降
• 对环境/可持续性的关注增加
• 数字技术、电信和网络的价格下降
• 各种无线/移动设备的快速增长
• 全球公司规模越来越大，合并、整合

迪克森拒绝提及他预测的未能实现的趋势（例如，他预测日益增长的部落主义将意味着大部分新财富由20人或更少员工的小公司创造，这些公司大多是家族拥有或控制的，或者他预测“旧经济学”的终结意味着我们可以无限期地实现高经济增长、低失业率且没有通胀压力），或者趋势进展导致迪克森的预测大错特错的情况，当基于指数趋势做出预测时，这是一个常见问题，因为增长率的相对较小的不准确可能导致最终状态的非常大的变化。

迪克森的网站充满了对他的赞扬，隐含或明确地声称他是伟大的未来预测者，以及更一般的声明，如“帕特里克·迪克森被评为当今在世最具影响力的20位商业思想家之一”。

回到《未来智慧》，迪克森严重依赖于“第二千年思维”和“第三千年思维”之间的鲜明分野这一概念，这在他的文本中反复出现。像几乎所有其他讨论中的人一样，迪克森也从许多现有趋势中推断出未能实现的预测，例如，他观察到电话线路成本的下降和价格的降低，预测到2005年人们家里将会有大量的电话线路，并且屏幕变薄意味着到2005年我们将广泛使用“薄如纸的显示片”。这种推断有时有效，迪克森10%的总体准确率与其他讨论中的“未来学家”相比相当好。

然而，当迪克森在我有一定理解的领域解释他的推理时，他似乎在流行词水平上运作，因此当他做出正确的判断时，通常出于错误的原因。例如，迪克森说软件总是有缺陷的，这似乎是正确的，至少到目前为止是这样。然而，他的理由是新计算机发布得如此频繁（他说“不到20个月”——指摩尔定律中的18个月时间线），编写好的软件需要很长时间（“至少20年”），所以程序员总是忙于为新一代机器重写软件（由于这本书的年代，他使用了“为奔腾芯片编写全新代码”作为例子）。

大多数缺陷，甚至作为缺陷比例的几乎任何缺陷，都不是由于程序员重写现有代码以在新的CPU上运行造成的。如果你真的仔细看，你可能会看到诸如安卓设备由于更新和向旧硬件反向移植更改的困难而有许多安全缺陷之类的事情，但这些类型的缺陷在所有缺陷中只占很小一部分，而且也不是迪克森真正谈论的内容。

同样，关于计算机备份未来将如何完成，迪克森基本上正确地说，家庭工作者将容易受到数据丢失的影响，认真保存数据的人将在线备份数据，“在线备份数据到其他城市的计算机作为终极安全”。

但迪克森陈述的理由是工作站已经有大的磁盘容量（>=2GB），而软盘容量没有跟上（<2MB），因此备份需要数千张软盘，这显然是荒谬的。然而，即使在当时，Zip驱动器（每张可移动磁盘100MB）也很常见，尽管没有流行起来，制造Zip驱动器的同一家公司也制造了1GB的“Jaz”驱动器。当然，磁带备份在当时也被使用，今天仍然使用。这种趋势一直持续到今天；大型可移动磁盘可用，而且我认识的很多人都在可移动磁盘上传输或备份大量数据。大多数人不进行磁盘/磁带备份的原因并不是备份本地计算机需要数千张磁盘（如果你看看人们在家里通常使用的计算机，大多数人都可以在每个故障域上用一个可移动磁盘备份他们的数据，甚至在一个磁盘上保留多个版本），而是因为在线/云备份更方便。

由于迪克森的推理是错误的（至少在我足够了解主题以了解推理适用性的情况下），似乎当迪克森正确时，不可能是因为陈述的原因，迪克森要么是巧合正确，要么是因为他看到了更广泛的趋势，并为预测提出了错误的合理化。但是，根据以上所述，要真正正确预测趋势随时间的增长率非常困难，因此如果不了解运作的机制，你也可以说基于一些粗略趋势而实现的预测也是巧合正确。

阿尔文·托夫勒/海蒂·托夫勒

像这个列表上的大多数其他人一样，托夫勒声称有一些重大的预测成功

托夫勒夫妇在其网站上声称，他们预见了苏联的解体、德国的统一和亚太地区的崛起。他在《人民日报》的采访中说，《未来的冲击》预见了有线电视、录像、虚拟现实和美国家庭规模的缩小。

在本文中，我们将看托夫勒最著名的著作，写于1970年的《未来的冲击》（Future Shock）。

根据许多来源，阿尔文·托夫勒的主要作品是与海蒂·托夫勒合著的。在书中，海蒂·托夫勒被承认为帮助很多的人，但不是作者，尽管其他地方有关于合著的说法。在本节中，我将托夫勒视为单数，但你可能想在心里替换成复数。

托夫勒声称，我们不仅应该通过理解过去来理解现在，还应该通过理解未来来理解现在：

以前，人们研究过去以阐明现在。我转动了时间之镜，确信一个连贯的未来图景也能为我们提供关于今天的宝贵见解。我们将发现，如果不把未来作为智力工具，我们将越来越难以理解我们的个人和公共问题。在接下来的页面中，我有意利用这个工具来展示它能做什么。

托夫勒通常做出模糊的、摇摆不定的陈述，因此真的无法对托夫勒的具体预测进行评分，因为给出的预测太少了。然而，托夫勒强烈暗示过去的指数趋势预计将持续甚至加速，并且由此引起的快速变化将导致“未来的冲击”，因此书名如此：

我创造了“未来冲击”这个术语来描述我们在个体身上施加的破坏性压力和迷失方向，方法是在短时间内让他们承受过多的变化。对这个概念着迷后，我花了五年时间访问了数十所大学、研究中心、实验室和政府机构，阅读了无数文章和科学论文，采访了数百位关于变化、应对行为和未来的不同方面的专家。诺贝尔奖得主、嬉皮士、精神病学家、医生、商人、专业未来学家、哲学家和教育家表达了他们对变化的担忧、对适应的焦虑、对未来的恐惧。从这次经历中，我带着两个令人不安的信念离开了。首先，很明显，未来的冲击不再是遥远的潜在危险，而是一种真正的疾病，越来越多的人已经在遭受这种疾病。这种心理生理疾病可以用医学和精神病学术语来描述。它是变化的疾病 …… 真诚的知识分子勇敢地谈论“为变化而教育”或“为未来做好准备”。但我们几乎不知道如何去做 …… 因此，这本书的目的是帮助我们接受未来——通过加深我们对人类如何应对变化的理解，来帮助我们更有效地应对个人和社会变化。

托夫勒到处使用的大锤是指数增长的推断，暗示这预计将持续。关于从曲线推断的一般概念，托夫勒的立场与库兹韦尔非常相似：如果你能在图表上看到趋势，你就可以用它来预测未来，而技术加速新技术发展的能力将导致创新比你天真预期的更快发生：

绘制在图表上，代表上一代人进步的线将垂直跃出页面。无论我们检查旅行的距离、达到的高度、开采的矿产，还是利用的爆炸威力，同样的加速趋势是显而易见的。模式，在这里和成千上万的其他统计系列中，是绝对清晰和明确的。几千年或几个世纪过去了，然后在我们这个时代，突然打破了限制，出现了惊人的激增。原因在于技术以自身为食。技术使更多技术成为可能，如果我们稍微看一下创新过程，就能看到这一点。技术创新包括三个阶段，相互连接成一个自我强化的循环……如今有证据表明，这个循环中每个步骤之间的时间已经缩短。因此，经常被指出的是，有史以来90%的科学家现在还活着，并且新的科学发现每天都在被发现，这些新想法比以往任何时候都更快地被付诸实践。

书中第一个N个主要例子是：

• 人口增长率（倍增时间为11年），这将不得不要求重大变化
• 经济增长（倍增时间为15年），这将增加人们拥有的东西的数量（这特别表述为东西的数量而不是财富）
  • 强烈暗示这将持续至少70年
• 旅行速度；未说明倍增时间，但读者可以从以下几点进行推断：数百万年前人类奔跑速度、1880年代的每小时100英里、1938年的每小时400英里、1958年的每小时800英里、此后不久的每小时4000英里（绕地球轨道时每小时18000英里）
• 从构思想法到应用的时间缩短，用来支持增长将加速的观点

正如我们刚刚在讨论迪克森、库兹韦尔等人时指出的那样，通过推断指数增长来预测未来是充满风险的。托夫勒以某种方式实现了反预测的壮举，即标记了一系列即将停止的趋势，其中一些在托夫勒写作时已经有失败的迹象。

托夫勒从以上内容推断，预测所有事物的半衰期都会变短，这将颠覆社会运作的方式。

例如，公司和政府将在1995年至2020年之间用“特别机构”（adhocracies）取代官僚机构。随着公司规模扩大，人们担心自己会成为齿轮，但这种担忧是过时的，因为在特别机构中，自上而下的指挥控制概念将消失，被一切加速的步伐所淘汰。虽然一些公司的自上而下指导确实比托夫勒时代预期的要少，但许多公司却更多，这得益于技术允许雇主比以往任何时候都更严格地监视员工，使人们比以往任何时候都更像齿轮。

另一个例子是，托夫勒预测人类对海洋的殖民，“新亚特兰蒂斯”，“在公元2000年之前很久”。

法比安·吉森（Fabian Giesen）指出，无论托夫勒预测的准确性如何，文卡泰什·拉奥（Venkatesh Rao）的《欢迎来到令人作呕的未来》解释了为什么“未来的冲击”在技术发展非常快的领域没有发生。

维基百科列表中未包含的人

• 劳瑞·安德森（Laurie Anderson）
  • 我无法轻易找到她的预测，除了据称预测了9/11的一些歌词，但非常“占星术”
• 阿瑟·哈金斯（Arthur Harkins）
  • 他的维基百科条目后来因不显著原因被移除，在当时已被标记为不显著
• 斯蒂芬·霍金（Stephen Hawking）
  • 我能找到的预测通常太遥远无法评分，而且更像是建议人们应该做什么，而不是预测。例如，上面的维基百科未来学家列表链接到一项2001年的预测，如果不进行基因工程改造以使人类跟上步伐，人类将被计算机/机器人超越，还链接到一项2006年的预测，人类需要向其他星球扩张以保护物种
• 索基尔·克里斯滕森（Thorkil Kristensen）
  • 我无法轻易找到克里斯滕森的一套英语预测。索基尔·克里斯滕森与《增长的极限》有关联但不是作者，这是一本1970年代的反增长论战作品
• 大卫·西尔斯（David Sears）
  • 当时或现在都不够显著，没有维基百科页面
• 约翰·泽赞（John Zerzan）
  • 泽赞更像是一个因其政治观点而呼吁社会变革的人，而不是一个试图预测未来的“未来学家”

史蒂夫·耶格

正如我在开头提到的，维基百科列表中没有一个未来学家有非常准确的预测，所以我们将看看来自其他来源的其他几个人，他们通常不被视为未来学家，看看他们的排名如何。

我们之前在这里看过耶格的预测，这些预测写于2004年，通常是关于未来5-10年的，有些更远。有九个预测（技术上是十个，但有一个不是真正的预测）。如果按照书面形式评分，就像未来学家评分一样，我会给这些评分4.5/9，大约50%。

你可能会说这不公平，因为耶格预测的是相对较近的未来，但如果我们看看未来学家对相对较近未来的预测，他们的准确率通常远低于50%，所以我认为以某种方式比较数字并不公平。

如果你想给这些评分，就像人们通常给未来学家评分一样，他们因基本把握方向正确而获得分数，那么我会说耶格的得分应该在7/9到8/9之间，取决于他在一个问题上获得多少部分分数。

如果你想采取更整体的“如果耶格的愿景是正确的，世界会是什么样子，与我们今天的世界相比”的方法，我认为耶格也做得相当好，最大的失误是基于Lisp的语言还没有接管世界，尽管Clojure取得了成功。这与这里的未来学家有很大不同，他们通常预测了许多没有实现的巨大变化，例如，如果我们看看库兹韦尔对世界的愿景，到2010年，我们本该有自动驾驶汽车、治疗瘫痪的“疗法”、广泛使用AR等，到2011年，我们将有无限的预期寿命，到2019年，我们将广泛使用纳米技术，包括计算机已从晶体管转向纳米管，有效“缓解”失明和失聪，相当广泛部署完全现实的VR，可以通过真实的身体刺激模拟性爱，普遍的自动驾驶汽车（再次预测），全新的艺术和音乐领域等，以及所有这些暗示的东西，这是一个与我们实际生活的世界非常不同的世界。

如果我们看看其他未来学家，我们也会看到类似的情况，他们预测了诸如住在地下、生活在水下等事情；大多数人预测了许多真正改变社会的革命性变化，其中一些实现了。耶格则预测了许多适度的变化（以及一些变化比许多人预期的要慢的领域），并且他预测的领域变化比他预期的慢，但只慢了一点。

耶格将他的方法描述为：

如果你读得很多，你会开始发现趋势和暗流。你可能看到人们更频繁地谈论某些你认为即将兴起的主题或技术，或者你只是模糊地感觉到行业中正在发生某种临界点。或者在你的公司，就这件事而言。

我似乎有很多最好的见解是在写我已经知道的东西时想到的。我想到了写关于看似明显和不可避免的趋势可能有助于我浮现出一些不那么明显的趋势。所以我决定根据我注意到的一些趋势做出一些随机预测，看看会出现什么。这基本上是一种挖掘见解的心智练习

在这篇文章中，我将根据今年阅读科技内容时感受到的暗流做出十个预测。在我写这段话时，我还不知道我的十个预测会是什么，除了第一个。这是一个简单、明显的预测，只是为了启动创造性思维过程。然后我会抛出另外九个，当它们在我脑海中出现时，我会尽力证明它们合理，即使它们听起来很疯狂。

他并不是真的在尝试生成最好的预测，但通过依赖他的领域知识和一些关于他所见过的事物的直觉，仍然做得相当好。

在关于耶格预测的文章中，我们还注意到他在其预测文章之外做出了许多成功的预测：

史蒂夫还有一些文章不是明确关于预测的，然而却对事物的现状做出了相当可靠的预测，早在2004年就写好了。有《这不是软件》，它超前于其时代很多年，关于人们如何编写“软件”，编写服务器应用程序如何真正不同于编写包装软件，以至于使许多以前可靠的建议过时，比如乔尔（Joel）关于重写的格言，以及面向服务的架构是什么样的；《德尔菲的谷歌》（同样来自2004年）正确预测了ML和AI的重要性以及谷歌对ML的大量投资；一次旧采访中，他预测“网络应用程序编程将逐渐成为最重要的客户端编程。我认为它将基本淘汰所有其他客户端工具包：GTK、Java Swing/SWT、Qt，当然还有所有特定于平台的工具包，如Cocoa和Win32/MFC”；等等。史蒂夫内部的一些谷歌博客文章也做出了有趣的预测，但据我所知，这些是保密的。

耶格的许多预测在当时会被认为相当不明显，而且他在其他预测中的成功率似乎仍然相当高（尽管我并没有试图全面找到并对它们评分，我抽样了他的一些旧文章，发现总体成功率与他预测文章中的相似）。

对于耶格和其他为了让我们看到一些准确预测而选择的预测者，当然存在选择这些预测者时存在幸存者偏差的担忧。我怀疑耶格的情况并非如此，因为在我第一次注意到他似乎有准确预测之后，他继续保持准确，所以这不仅仅是因为我在事后挑选了一个有一段时间运气好的人。此外，特别是他在谷歌内部的G+评论中，做出了相当高维度的评论，最终因为他说的原因而正确，这提供了比仅仅连续抛硬币更多关于他的推理准确性的信息。这种关于推理深度的评论不适用于下面的卡普兰，因为我没有评估卡普兰的推理，但适用于1990年左右的微软领导层。

布莱恩·卡普兰

布莱恩·卡普兰报告说他的记录是23/23 = 100%。他比我们研究过的任何人都更精确地指定了他的预测，并试图给出一个精确的赌注，该赌注将很容易裁决，以及赔率。

卡普兰开始做出预测/赌注的时间大约与“赌注是对废话征税”这一概念流行的时间相同（意思是很多人愿意说任何话，但如果被要求进行真正的赌注，他们会安静下来，那些不这样做的人如果做出了糟糕的真赌注就会付出真正的代价），卡普兰似乎有一个策略，就是充当废话的征税员，他通常接受人们不应该做的赌注的安全面。安德鲁·格尔曼说：

卡普兰的赌注是一个有趣的混合。第一个赌注他提供了1比100的赔率，所以他赢了并不奇怪，但大多数赌注都是平赔。有几个他运气很好（例如，他在2008年打赌在2020年1月1日之前没有大国会离开欧盟，所以他在那个月仅仅幸免于难），但是，嘿，运气好是可以的，而且无论如何，即使他只赢了23场中的21场，那也是一个令人印象深刻的记录。

在我看来，卡普兰的诀窍在于，他对选择什么投球有良好的判断力。人们带着一些强烈的、不切实际的观点来找他，他善于将这些转化为赌注。用扑克术语来说，他等到他拿到坚果牌，或者接近坚果牌。23场赢了23场……那是一个伟大的记录。

我认为这样做有很大的价值，无论是从一般的“赌注是对废话征税”的意义上讲，还是更具体地说，如果你非常相信有人试图接受错误赌注的另一面，并且有良好的判断力，那么知道卡普兰式的赌徒接受了这个立场，即使你在主题上没有特别的专业知识，也会给你关于赌注的不错信号。例如，如果你看看我的赌注，尽管我有时会与明显错误的立场对赌，但我更经常地接受我有很大可能输的赌注，所以仅仅知道我接受了一个赌注提供的信息比知道卡普兰接受了一个赌注要少得多。

但是，当然，站在卡普兰的一方并不是万无一失的。正如格尔曼指出的，卡普兰至少有一次运气好，而且卡普兰似乎也可能会输掉卡普兰和塔巴罗克对阵鲍曼的全球温度赌注。对于这个特定的赌注，你也可以认为他应该输，因为他接受了3比1的赔率，但很多人会认为3比1的赔率远远不够长，不足以接受这个赌注。

卡普兰迄今为止使用的方法永远不会在重大变化非常可能发生之前产生积极的预测，因此这种方法无法像耶格、盖茨或其他接受更狂野赌注的相对准确的预测者那样，真正给你一个关于未来会是什么样子的愿景。

比尔·盖茨/内森·梅尔沃德/1990至1997年左右的微软领导层

由于针对微软的诉讼，一些备忘录被公之于众，这些备忘录阐述了微软高管对世界将如何发展（无论是否有微软参与）的愿景。这些备忘录没有列出带有时间线的具体预测，因此无法像本文对未来学家预测的评分方式进行评分。如果根据这些预测对未来的愿景的准确性进行评分，我会给它们与史蒂夫·耶格（得分为7/9或8/9）类似的评分，但这些预测的雄心要大得多，因此在控制预测范围的情况下，它们看起来更加令人印象深刻。

与我们讨论的未来学家相比，在多个方面，这些预测要详细得多（因此在给定准确度水平上更加令人印象深刻）。一个是微软高管对讨论中的事物及其相互影响有更深的理解。对于“我们”的未来学家，他们经常在高层次上讨论事物，当他们详细讨论事物时，他们会做出一些陈述，表明他们并不真正理解该主题，并且常常不知道他们写的词是什么意思。那个时代的微软高管显然对问题的运作机制有深刻的理解，这使他们能够做出我们的未来学家不会做出的详细预测，例如，虽然FTP和IRC等协议将继续使用，但互联网的近期未来是基于TCP的HTTP，浏览器将成为像Windows一样的“平台”，一个比任何操作系统都更重要和更庞大的平台（除非微软成功地采取行动阻止这一点，尽管微软高管预见到了可能导致微软未能拥有互联网的确切机制，但它并未成功）。微软领导层利用这种理解水平对我们的未来学家讨论的更大的事物做出预测，例如工作的性质以及这将如何改变。

真正理解问题的运作机制，而不仅仅是在典型的未来学家流行词水平上理解主题，使得微软领导层能够对未来的可能样子做出相当好的猜测。

关于盖茨为理解情况所付出的努力的一个有趣故事，请参见乔尔·斯波尔斯基（Joel Spolsky）关于他第一次比尔·盖茨评审的故事：

比尔转向我。

我注意到我的规范文件边距上有注释。他读了第一页！

他读了我规范文件的第一页并在边距上写了小注释！

考虑到我们大约在24小时前才给他规范文件，他一定是前一晚读的。

他在问问题。我在回答。它们相当简单，但我根本记不得它们是什么，因为我无法停止注意到他在翻阅规范文件……

他在翻阅规范文件！ [冷静点，你是个小女孩吗？]

…… [编辑：省略号来自原始文档] 每一页边距上都有注释。他读完了整个该死的东西并在边距上写了注释。

他读完了所有东西！[天哪，尖叫！]

问题变得更难、更详细。

它们似乎有点随机。现在我已经习惯把比尔当作我的伙伴了。他是个好人！他读了我的规范文件！他可能只是想问我几个关于边距注释的问题！我会为他的每个注释在错误跟踪器中打开一个错误，并确保它很快得到解决！

最后是致命的问题。

“我不知道，你们，”比尔说，“有人真的在研究如何做到这一点的所有细节吗？比如，所有那些日期和时间函数。Excel有那么多日期和时间函数。Basic会有相同的函数吗？它们都会以相同的方式工作吗？”

“是的，”我说，“除了1900年的1月和2月。”

沉默。 …… “好吧。嗯，干得好，”比尔说。他拿起了他标记过的规范文件副本……离开了

盖茨（以及其他一些微软高管）对情况了解得非常详细，同时还在考虑大局问题。

另一个帖子的主题是，微软领导层如何拥有比传统竞争对手（Novell、IBM、AT&T、Yahoo、Sun等）更有效的未来愿景，以及这如何导致微软成为一家价值2万亿美元的公司，而他们的竞争对手最多变得无关紧要，大多数甚至没有成功变得无关紧要，就不再存在。阅读旧的微软备忘录，很明显微软确实在密切关注竞争对手在做什么，他们常常对竞争对手的领导层效率低下感到惊讶，例如，关于Novell，比尔·盖茨说“我们的传统竞争对手刚刚开始涉足互联网。考虑到网络对Novell的重要性，它缺席得令人惊讶”；盖茨注意到当时的Novell CEO弗兰肯伯格（Frankenberg）似乎理解互联网的重要性，但弗兰肯伯格直到1994年才加入Novell，并于1996年离开，在诺瓦德（Noorda）领导下，他在Novell的大部分时间都在逆转公司采取的方向，当弗兰肯伯格“辞职”两年后，这并没有给Novell留下一个连贯的立场或计划。

在很多方面，讨论当时科技高管认为未来会是什么样子以及什么道路通向成功，比研究基本上不理解他们讨论主题的未来学家更有趣，但我开始这篇文章是为了研究未来学家对他们讨论的主题理解得有多好，而我不知道，事先，他们对主题的理解和由此产生的预测准确性会如此之差。

未来学家错误的常见原因

• 没有从错误中学习
  • 好的预测者倾向于认真研究失败的过去预测并试图校准
• 基于鸡尾酒会想法水平对主题的理解进行推理
  • 好的预测者倾向于深入探讨想法
• 推行一个或几个“宏大理念”
• 通常对未来具有高度确定性
  • 更糟糕的是：假设缩放曲线，尤其是指数缩放曲线具有高度确定性
• 万能药思维
• 只看到技术变革的积极面（或消极面）
• 从无证据支持的假设开始

没有从错误中学习

我们在这篇文章中研究的未来学家倾向于给自己打很高的分，并且事后通常声称自己是伟大的未来预测者，以至于他们甚至会告诉你如何准确地预测未来。然而，在给他们评分后，最准确的未来学家（在做出足够具体、可以评分的预测者中）的准确率只有10%，慷慨的评分给了他们因错误预测机制而偶然实现的预测的分数（严格阅读他们的许多预测会降低准确率，因为他们说预测会因为他们的预测机制而实现，这是错误的，使得预测错误）。

这些未来学家使用了两个技巧才能做出如此崇高的声明。首先，他们中的许多人做出模糊的预测，然后如果任何与预测模糊相似的事情发生，就声称成功。其次，他们几乎都做出大量的预测，然后只计算那些成功的预测。看待4%准确率的一种方式是，你不应该依赖那个人的预测。另一种方式是，如果他们做出了500个预测，他们是一个伟大的预测者，因为他们做出了20个准确的预测。因为几乎没有人会费心去检查一份预测列表来计算总体准确率，当一个人这样做时，做出大量的预测然后挑选出那些准确的是成为一个著名未来学家的好策略。

但如果我们想找出如何做出准确的预测，我们将不得不研究其他人的策略。有些人确实做出了相当好的、总体方向准确的预测，正如我们在史蒂夫·耶格的预测记录中所指出的那样。然而，他们往往是自己预测的严厉批评者，正如史蒂夫·耶格在回顾他自己的预测记录时所做的那样，他说：

我看到了HN上关于丹·陆（Dan Luu）对这篇文章的评论的帖子，我觉得人们对评分有点太慷慨了。

一个相对较好的未来预测者给自己打分比我低并不奇怪，因为批判性地看待自己的错误并指出大多数人太小而不关心的错误是提高的好方法。我们可以在微软领导层的通讯中看到这一点，例如，他们指出自己未能预测缺乏向后兼容性会破坏像OS/2和LanMan这样的重大项目。像大多数未来学家那样，专注于那些成功的预测而不研究出了什么问题，并不是提高的好方法。

鸡尾酒会理解

我们在做出总体方向正确预测的人身上看到的另一件事，正如上面提到的史蒂夫·耶格文章、内森·梅尔沃德1993年的“信息高速公路上的车祸”、比尔·盖茨1995年的《互联网浪潮》等，是做出预测的人实际上理解该主题。在所有上述例子中，文件的作者显然对预测的主题有相当强的技术理解，并且在一般情况下，似乎拥有相对准确预测的人真正试图理解主题，这与本文讨论的未来学家形成鲜明对比，他们几乎都表现出在讨论的主题上具有流行词水平的理解²的明显迹象。

在某种意义上，如果你理解该主题并有权访问正确的数据，做出正确的预测并不太难。在加入一家大型跨国公司并观察未来展开之前，我认为像“信息高速公路上的车祸”和“互联网浪潮”这样的文件具有惊人的预见性，但一旦我在2013年加入谷歌，从外部不明显的许多趋势从内部看似乎相当明显。

例如，很明显移动设备对大多数类别的应用程序非常重要，以至于大多数成功应用将是“移动优先”应用，其中网络应用程序是次要的（如果存在的话），从内部可用的数据来看，这至少从2010年起就应该很明显。看看外部的人在做什么，许多在移动设备至关重要的领域的初创公司在2016年和2017年仍然以2009年对未来的理解运营，他们专注于首先拥有一个网络应用程序，并且没有移动应用程序，而且网络应用程序在移动设备上无法使用。另一个例子是，在2012年，谷歌内部相当多的人独立希望谷歌在深度学习上进行非常大的押注。很明显深度学习将是一件非常大的事情，值得在硬件上投资十亿美元，以加速谷歌的深度学习工作。

这并不是说问题很简单——许多拥有相同数据的人通常仍然做出不正确的预测。一个著名的例子是鲍尔默的预测，“iPhone不可能获得任何重要的市场份额。不可能。”³ 鲍尔默和其他微软领导层拥有与十年前微软领导层一样好的信息，但他们中的许多人的预测并不比我们在这里讨论的未来学家好。对于上面的深度学习例子，谷歌的一个竞争对手拥有相同的信息，却完全错过了，并且多年来一直错过，即使有多年额外信息的优势；由于未能理解如何实现有效的、实际的深度学习研发，他们现在仍然远远落后于谷歌。

假设高度确定性

不正确预测的另一个常见原因是高度确定性。这是一个普遍问题，在从过去的指数增长进行预测并将其外推到未来时，会被放大，因为错误预测指数增长发生重大变化的时间可能会产生非常大的影响，而且相对较小的持续变化在指数增长中也可能产生很大影响。一个暴露我们许多未来学家这些弱点的例子是他们对摩尔定律的解释，许多人将其解释为每18个月计算机相关的每项好处翻倍和/或每项坏事减半。这从来都不是摩尔定律的预测，但它是摩尔定律的普遍流行概念。其中一点说明性的是，预测者在90年代末和00年代初撰写时，仍然基于摩尔定律做出这些幻想性的预测，即使单线程计算机性能和摩尔定律都将面临重大挑战这一常识在当时的本科课程中就已教授过。任何花几分钟与该领域的专家交谈甚至本科生交谈的未来学家都会看到计算机性能缩放存在高度不确定性，但我们讨论的大多数未来学家要么不这样做，要么忽视会增加他们叙述不确定性的证据⁴。

随着计算能力的增加，所有的常数因子效率低下（“使用两倍的RAM”、“需要三倍的RISC操作”）往往会屈服于摩尔定律，留下多项式和指数增长的成本作为唯一合理的关注领域。因此，Flare愿意接受任何O(C)效率低下（单一、一次性成本），并且愿意接受大多数O(N)效率低下（常数因子成本），因为这两种成本都不会影响可伸缩性；Flare程序和程序空间可以在这些成本相对重要性不增加的情况下增长。你可以随着N的增加向O(N)问题抛掷硬件；向O(N**2)问题抛掷硬件很快就会变得非常昂贵。

对于计算机缩放，本可以做出

由 mimo-v2.5 模型翻译，花费 69407 tokens

Wave 是一家拥有70名工程师、估值17亿美元的公司¹，其产品是一个用于增减数字的CRUD应用。与此一致，我们的架构是标准的CRUD应用架构，一个基于PostgreSQL的Python单体应用。从简单的架构开始，并尽可能以简单的方式解决问题，使我们能够扩展到目前的规模，同时工程师们主要专注于为用户创造价值的工作。

Stack Overflow成功地将单体应用扩展到相当规模（2013年架构 / 2016年架构），最终以18亿美元被收购。如果我们看流量而非市值，Stack Overflow是互联网上流量最高的100个网站之一（关于其他许多建立在单体应用之上的高价值公司，请参阅此Twitter线程的回复）。我们没有大量网络流量，因为我们是移动应用，但即使我们的网站基本上只是供人们查找应用的入口，且大多数人甚至不是通过网站发现该应用，Alexa仍将我们的网站排在全球前7.5万名之内。

确实有些类型的应用程序需求，使得基于无聊数据库的简单单体应用无法启动，但对于大多数类型的应用程序，即使在顶级100流量水平上，计算机速度也足够快，高流量应用可以采用简单架构来支撑，而这种架构通常比复杂架构创建得更便宜、更简单。

尽管简单架构有着惊人的有效性，但大多数媒体报道都倾向于复杂架构。例如，在最近的一次通用技术会议上，有六个演讲是关于如何构建或处理基于复杂微服务架构的副作用，而关于如何构建简单单体应用的演讲数量为零。关于量子计算的演讲（一个）比关于单体应用的演讲（零）还多。大型会议情况类似；最近在旧金山举行的一次面向企业的会议，有数十个演讲是关于如何应对复杂架构带来的复杂性，而关于如何构建简单单体应用的演讲为零。上次我参加那次会议时，令我印象深刻的是，有多少在企业工作的与会者，其低规模应用本可以采用简单架构构建，却照搬了在会议圈和Hacker News上流行的最新最复杂的技术。

我们的架构如此简单，我甚至懒得画架构图。相反，我将讨论我们做的一些无聊的事情，帮助我们保持事物的无聊。

我们目前使用无聊的、同步的Python，这意味着我们的服务器进程在等待I/O（如网络请求）时会阻塞。我们之前尝试过Eventlet，一个异步框架，理论上可以让我们更高效地利用Python，但遇到了如此多的bug，以至于我们认为等待事件的CPU和延迟成本不值得我们为处理Eventlet问题而承担的运维痛苦。Python还有其他知名的异步框架，但那些在规模上使用它们的用户也经常报告在规模上使用这些框架会带来重大问题。使用同步Python是昂贵的，因为我们在网络请求期间支付了CPU仅仅等待，但鉴于我们目前每月只处理数十亿请求，即使使用像Python这样较慢的语言并支付公共云的零售价格，其成本也很低。我们工程团队的成本完全主导了我们运行系统的成本²。

为了不承担让我们的单体应用异步化的复杂性，我们将长时间运行的任务（我们不希望响应被阻塞的任务）分发到队列。

有一个我们无法像希望的那样保持无聊的地方，那就是我们的本地数据中心。当我们只在塞内加尔和科特迪瓦运营时，我们完全在云端运营，但随着我们扩展到乌干达（以及未来更多国家），为了遵守当地的数据驻留法律法规，我们不得不拆分后端并在本地部署。这并非一个简单的操作，但任何用复杂服务导向架构做过同样事情的人都知道，这个操作比采用复杂服务导向架构要简单得多。

另一个领域是我们不得不自建（而不是购买）的软件。刚开始时，我们强烈倾向于购买软件而不是自建，因为只有少数工程师的团队承担不起自建一切的时间成本。尽管“购买”选项通常给你的是不好用的工具，但在当时是正确的选择。在供应商无法被说服修复对我们至关重要的阻塞性bug的情况下，确实有理由自建更多工具并在更多领域维护内部专业知识，这与公司应只在其核心能力上“自建”的标准建议相矛盾。大部分复杂性是我们不想承担的，但在某些产品类别中，即使经过相当广泛的研究，我们也找不到任何供应商可能提供适合我们的产品。公平地说，我们的供应商需要解决的问题比我们需要解决的问题复杂得多，因为供应商需要解决为每个客户的问题，而我们只需要解决一个客户——我们自己的问题。

我们在最初几个月犯的一个错误，至今仍有一些代价，那就是没有仔细界定数据库事务的边界。在Wave的代码库中，SQLAlchemy数据库会话是一个请求全局变量；每当访问数据库对象的属性时，它都会隐式开始一个新的数据库事务，Wave代码库中的任何函数都可以在会话上调用commit，从而导致其提交所有挂起的更新。这使得控制数据库更新发生的时间变得困难，增加了我们出现微妙数据完整性错误的频率，也使得利用数据库构建诸如幂等键或事务性暂存作业排空等功能变得更加困难。它还增加了我们意外打开长时间运行的数据库事务的风险，这可能会使数据库模式迁移在操作上变得困难。

一些我们不确定的选择（即这些是我们正在考虑更改，或会建议其他团队从头开始时考虑采用不同方法的事情）包括：使用RabbitMQ（就我们的目的而言，Redis可能同样适合作为任务队列，且仅使用Redis可以减少运维负担）、使用Celery（对于我们的用例过于复杂，并且已导致数次故障，例如由于版本升级期间的向后兼容性问题）、使用SQLAlchemy（使得开发人员难以理解其代码将发出哪些数据库查询，导致各种难以调试的情况，并涉及不必要的运维痛苦，特别是与上述数据库事务边界相关的点）以及使用Python（由于我们创始CTO的技术背景，这是一个正确的初始选择，但其并发支持、性能和广泛的动态特性让我们质疑它是否是大型后端代码库的正确选择）。这些都不是重大错误，对于其中一些（例如Python），缺点足够小，以至于我们继续承担增加的维护负担比投资迁移到理论上更好的东西更便宜，但如果我们今天从头开始构建类似的代码库，我们会认真思考它们是否是正确选择。

一些我们对其选择感到满意的领域，尽管它们可能听起来不像最简单的可行方案，包括：我们的API（我们使用GraphQL）、我们的传输协议（我们曾有一段时间使用自定义协议）以及我们的主机管理（我们使用Kubernetes）。关于传输协议，我们过去使用一个运行在UDP之上的自定义协议，带有SMS和USSD回退，原因如本次演讲所述，是为了性能。随着HTTP/3的推出，我们能够用HTTP/3替换我们的自定义协议，并且我们通常只需要USSD来应对像最近马里互联网关闭这样的事件。

关于使用GraphQL，我们认为对我们来说利大于弊：

优点：

• 精确返回类型的自文档化
• 精确返回类型的代码生成带来更安全的客户端
• GraphiQL交互式浏览器提高了生产力
• 我们的各种应用（用户应用、支持应用、Wave代理应用等）可以大多共享一个API，降低了复杂性
• 可组合的查询语言允许客户端在单次数据包往返中精确获取所需数据，无需构建大量专用端点
• 消除了关于什么才算RESTful API的无谓争论

缺点：

• 当我们采用GraphQL时，GraphQL库还不够好（基础Python库是Javascript库的移植，不够Python化，Graphene需要大量样板代码，Apollo-Android生成的代码优化很差）
• 默认的GQL编码是冗余的，我们非常关注限制大小，因为我们的许多客户带宽较低

关于Kubernetes，我们使用Kubernetes是因为我们知道，如果业务成功（事实确实如此）并且我们持续扩展，我们最终会扩展到要求我们在该国境内运营服务的国家。具体法规因国家而异，但我们已经在扩展到一个要求我们将“主要数据中心”设在该国境内的主要非洲市场，其他一些国家则有法规要求，例如，我们必须能够故障转移到该国境内的数据中心。

对于我们来说，有一个不可避免的复杂领域是电信集成。理论上，我们会为所有事情使用SaaS SMS提供商，但主要的SaaS SMS提供商并非在非洲所有地方都运营，在所有地方都使用它们的成本将是高昂的³。前面关于工程师补偿成本主导我们系统成本的评论，如果我们为所有SMS需求都使用SaaS SMS提供商，就不成立了；提供电信集成的团队自身创造了数倍于其成本的价值。

通过尽可能保持我们的应用架构简单，我们可以在那些复杂性能为业务带来收益的地方花费我们的复杂性（和人员编制）预算。除非有充分的理由增加复杂性，否则尽可能简单地做事的理念，使我们能够用不算太多的工程师建立一个相当大的业务，尽管我们运营的是一项非洲金融业务——这通常被认为是一个难以进入的行业，我们将在未来的一篇文章中讨论（我们最早和最有帮助的顾问之一，他的建议对Wave的成功至关重要，最初建议Wave是一个糟糕的商业想法，创始人应该选择另一个，因为他预见到了如此多的潜在困难）。

感谢Ben Kuhn、Sierra Rotimi-Williams、June Seif、Kamal Marhubi、Ruthie Byers、Lincoln Quirk、Calum Ball、John Hergenroeder、Bill Mill、Sophia Wisdom和Finbarr Timbers的评论/修正/讨论。

由 mimo-v2.5 模型翻译，花费 6608 tokens

让我们直接开始吧。我认为硅谷公司故意、系统性歧视的批评是错误的，有两个原因可以相信这一点。……第二，我们的公司求贤若渴。极其渴望。我们的公司渴求人才。他们就像躺在沙滩上喘气一样，因为找不到足够多的有才华的人来做这些工作。去寻找人才的动机高得难以置信。

我经常听到工程师和风险投资人重复的这一观点的变体是，公司是有效率的，或者产品基本上已经尽可能好，因为如果它们可能更好，早就有人通过竞争做得更好了¹。

这类说法有一种模糊的合理性，因此它经常成为我在随意谈话中经常听到的辩论话题，其中一人会指出某个明显的公司低效或产品错误，而另一人则会回应说，如果它如此明显，公司里早就有人修复了这个问题，或者另一家公司会凭借更高的效率或更好的产品胜出。纯粹从理论上讲，很难解决这个争论，但如果我们看一些具体例子，比如上面关于招聘的两个例子，事情就清晰了，我们可以观察到，无论人们提出什么抽象的论点，低效现象持续了数十年。

就购买产品和服务而言，在个人层面上，我认识的大多数检查过他们雇来的人（比如家庭装修或会计）的工作的人都发现了工作中的严重错误。虽然有可能找到不做劣质工作的人，但对于一个不是该领域专家的人来说，通常很难确定某人是否会做劣质工作。你可以尝试通过支付更多来获得更好的质量，但一旦你脱离了市场的非常低端，如何用金钱换取质量通常就不清楚了；例如，我的朋友和同事中，那些选择大型、知名会计公司的人支付的费用远高于选择小型、本地会计师的人，却得到了更高的错误率；作为一种策略，尝试聘请昂贵的本地会计师也没有好多少。好的会计师通常有点贵，但他们通常不收取最高费率，而且只有一小部分有点贵的会计师是好的。

更普遍地说，在许多市场中，消费者信息不灵，很难找出哪些产品甚至还算不错，更不用说好的了。当人们碰巧选择了适合他们的产品或服务时，通常是出于错误的原因。例如，在我的社交圈里，过去几年有两波人从iPhone转向Android手机。这两波都是由于苹果的公关失误造成的，导致很多人认为iPhone在某方面很糟糕，而实际上它在这方面比Android手机更好。幸运的是，iPhone并非严格优于Android手机，许多转换的人得到了一个对他们更好的设备，因为他们之前是因为苹果良好的公关而使用iPhone，这使得他们的错误相互抵消。但是，当人们主要根据营销和公关做决定，并且无法获得好的信息时，没有特别的理由认为一个总体上更好甚至严格优越的产品会胜出，而更差的产品会失败。在资本市场中，我们不需要那么多信息充分的参与者就能认为某种形式的有效市场假说成立，以确保“价格反映了所有可用信息”。一个不言而喻的道理是，关于市场低效的已发表结果在发表的那一刻就不再成立，因为人们会利用这种低效直到它消失。但是，在劳动力市场的例子中，尽管公司可以利用定价错误的劳动力，正如格林斯潘在成为美联储主席之前著名地那样，低效可以持续存在：

Townsend-Greenspan 作为一家经济学公司是不寻常的，因为男性为女性工作（我们大约有25名员工）。我雇用女性经济学家并非出于妇女解放。这只是非常有商业意义。我平等对待男性和女性，并发现由于其他雇主没有这样做，优秀的女性经济学家比男性更便宜。雇用女性……让 Townsend-Greenspan 用同样的钱获得了更高质量的工作……

但正如我们所看到的，单个公司利用定价错误的劳动力，对劳动力的需求有限，低效可以持续数十年，因为那些根据“所有可用信息”行事的公司购买的劳动力不足以将定价错误的人的价格推高到如果大多数或所有公司都理性行事时会达到的水平。

从理论上讲，在产品和服务方面，低效似乎也应该能够持续很长时间，因为同样，也没有一种机制允许系统中的参与者以一种直接将金钱转化为更多金钱的方式来利用低效，有时甚至几乎没有任何机制来赚钱。例如，如果你观察到人们因为认为苹果在进行邪恶的计划性淘汰而从iPhone转向Android手机是愚蠢的，而Android设备通常由于iPhone获得更新的时间更长以及iPhone在它们竞争的每一个价位上都更快而更快过时，允许手机在臃肿的网站上使用更长时间，你真的无法从这个观察中赚钱。这与你可以购买衍生品来赚钱（在预期中）的定价错误的资产不同。

对于不知道什么产品或服务好的问题，一个常见的建议是咨询该领域的专家或有资质的人，但这也经常失败。例如，我的一个朋友因为他的窗户空调噪音太大，启动时会把他吵醒而睡不着觉。他问了一个他信任的、从事空调工作的朋友，换一台新的空调是否可以改善这种情况，他的朋友说“不；空调基本上都差不多”。但任何比较过带电机产品的消费者都会立即知道这是错误的。工程师在保持功率和成本不变的情况下制造更安静的设备方面已经进步了很多。我的朋友最终买了一台更新的、更安静的空调，这解决了他的睡眠问题，但他问题持续的时间比需要的更长，因为他以为一个以空调工作为业的人会给他提供不糟糕的建议。如果我的朋友是空调专家，或者比较过随时间变化的其他类似消费产品的噪音水平，他本可以知道不该相信他的朋友，但如果他有那种专业水平，他一开始就不需要建议了。

到目前为止，我们关注的是在个人层面获得合适产品或服务的困难，但这个问题在公司层面也存在，并且通常更严重，因为市场往往更薄，可用产品更少，而且定价不透明，“请联系我们”。一些经常被重复的建议是公司应该专注于他们的“核心竞争力”，并将其他所有事情外包（例如，Joel Spolsky、Gene Kim、Will Larson、Camille Fournier 等人都这么说），但如果我们看中型科技公司，我们会发现它们通常需要拥有远超出任何人认为的核心竞争力的内部专业知识，除非，例如，每家社交媒体公司都将内核专业知识作为核心竞争力。原则上，公司可以将这类工作外包，但我认识的那些依赖外包的人，比如将内核专业知识外包给顾问或将应用工程师放在支持合同上，与他们通过雇用专职工程师所能得到的结果相比，都非常不满意，无论是在绝对值上（支持通常在几周甚至几个月内都找不到满意的解决方案，即使是一个好的工程师可以在几天内解决的问题），还是在金钱上（尽管工程师很昂贵，但大型支持合同通常可能比一个工程师更贵，同时提供的服务更差）。

这个问题不仅存在于支持方面，也存在于公司可以购买而不是构建的产品中。例如，Wave 的首席技术官 Ben Kuhn 在推特上发布了一些关于我们遇到的问题，并有几个后续。Ben 现在认为，他作为首席技术官犯下的一个大错误是没有在供应商选择上投入更多精力，即使决策看起来是板上钉钉的，并且更强烈地考虑尽早将许多系统迁移到定制的内部版本。即使选择了该领域领先（即规模最大、最受尊敬）的公司中的共识最佳产品，并使用公司的主要产品，该产品通常不仅不起作用，而且其设计就无法工作。

例如，我们尝试“购买”而不是“构建”一个将数据从 Postgres 同步到 Snowflake 的产品。从 Postgres 同步是主要产品（即拥有最多客户的产品）来自一家领先的数据同步公司，我们发现它会丢失数据、重复数据和损坏数据。深入研究后，发现该产品的设计依赖于数据源能够在变更日志上向后搜索。但 Postgres 在变更日志被消费后就会丢弃它们，因此 Postgres 数据源无法支持此操作。当他们的产品尝试执行此操作且操作失败时，我们最终会出现同步“卡住”的情况，需要供应商操作员的和/或数据丢失的人工干预。由于我们的数据仍然在 Postgres 上，可以通过完全重新同步来恢复，但数据同步产品的速度上限为 5MB/s，原因似乎不为他们所知，因此即使对于不是特别大的数据库，完全重新同步也可能需要数天时间。重新同步也会静默地丢弃和损坏数据，因此有时需要多轮完全重新同步后跟数据完整性检查来从数据损坏中恢复，这可能需要数周时间。尽管被广泛推荐并且是该领域的领先产品，该产品存在一些重大设计缺陷，意味着它实际上无法工作。

这与 Mongo 或其他存在基本设计缺陷导致严重数据丢失的产品没有太大区别，主要区别在于，在大多数领域，没有像Kyle Kingsbury 这样花费数年时间测试该领域各种产品，并耐心回应关于正确性的虚假声明，直到公关反弹导致该领域的公司开始认真对待正确性的人。没有这种压力，大多数软件产品基本上都不工作，因此上面有 Ben 的推特线程，他指出你可能想选择的“购买”解决方案大多不起作用²。当然，在我们的规模上，有很多我们近期不会去构建的东西，比如 CPU，但对于许多普遍认为应该“购买”的东西，“构建”似乎是一个合理的选择。即使对于大公司和构建 CPU 也是如此。十五年前，高性能（即非嵌入式级别的性能）CPU 被认为是疯了才会内部构建的东西，对最大的软件公司来说也是荒谬的，但 Apple 和 Amazon 已经能够在它们优化的维度上生产出同类最佳的 CPU，这是有原因的³。

这不仅仅是影响科技公司的问题；我们在许多不同的行业中都能看到这一点。例如，任何想向客户邮寄物品的公司都必须自己实现物流，或者处理不可靠物流的后果。作为用户，包裹是否能寄达给你，很大程度上取决于你住在哪里以及你住在什么样的建筑里。

当我住在房子里时，包裹通常无论使用哪家快递都会送达（尽管经常迟到）。但自从搬进公寓楼后，一些建筑就是收不到某些快递服务的配送。有一次，我住在一个邮政服务没有正确投递邮件的建筑里，我收不到很多邮件（虽然我经常收到寄给楼里其他人以及别处的人的邮件）。更常见的是，UPS 和 Fedex 通常不会尝试投递，只会在建筑门上贴一堆通知，上面是所有他们未投递的包裹的通知，通知错误地表示收件人不在家，但正确地指出，要拿到包裹，必须去某个取件点取件。

有一段时间，我住在一个城市，Amazon 使用第三方商业快递服务进行当日达的最后一公里配送。他们使用的服务以在未投递物品的情况下标记已投递而闻名，使得“当日达”配送比次日达甚至两日达还慢。有一次，我天真地联系了 Amazon 客服，因为我的包裹被标记为已投递但实际上没有投递。客服使用 Amazon 提供的标准脚本告诉我，我应该在包裹被标记为已投递三天后再联系他们，因为快递员经常标记包裹已投递但未投递，但他们通常会在几天内投递包裹。Amazon 知道他们使用的快递服务甚至不真正尝试投递包裹⁴，而他们唯一可用的短期缓解措施是告诉客服，让人们不要在包裹被标记为已投递时就认为它已到达。

Amazon 最终通过拥有自己的快递员或使用（按商业运输标准）极其昂贵的服务解决了这个问题（Apple 已为当日达这样做⁵）。在大规模运营下，没有你可以付费的商业服务能可靠地尝试投递包裹。如果你想要一个真正有效的服务，你通常需要自己构建，就像在软件领域一样。我当地的杂货店试图将此外包给 DoorDash。我尝试从杂货店送货3次，杂货只到了2次，这远低于大多数人认为可接受的命中率。为了获得可靠性而必须自建而不是购买，对生产力是巨大的拖累，尤其是对小公司而言（例如，想要与 Amazon 竞争并邮寄产品给客户的小商店不可能拥有可靠的配送服务，因为他们无法建立自己的配送服务）。

无法外包服务所产生的浪费量是惊人的，我在我工作过的每个地方都见过。另一个行业的例子：当我在一家小型芯片初创公司工作时，我们内部有能力进行端到端的芯片处理（除了没有自己的晶圆厂），这在小型芯片初创公司中并不常见。当新设计的第一片晶圆从晶圆厂出来时，我们会用航班把晶圆运给我们，然后有人会用晶圆切割机把晶圆切成单个芯片，以便尽快开始测试。这通常被认为是荒谬的，就像小型软件初创公司管理自己的本地硬件被认为是荒谬的一样。毕竟，晶圆切割机和从晶圆到工作芯片所需的专业知识在99%以上的时间里都是闲置的。拥有全职设备和你使用时间不到1%的专业知识，是应该外包的经典例子，但如果考虑到拥有能够完成这项工作的人员和设备，即使在相当低的产量下，在内部完成也更便宜，即使设备和专业知识闲置99%的时间。更重要的是，内部服务会好得多（周转更快），让你能够以更高的节奏发货。我既在尝试将此类事情外包的公司工作过，也与许多做过此事的人交谈过，你会得到更慢、更不可靠的服务，而且成本更高。

芯片软件工具也是如此；尽管将工具外包给大型 EDA 供应商是标准做法，但我们通过使用自己的定制工具（通常由一个人创建或维护）获得了很大收益，例如，我在那里的时候，大多数模拟周期都是在由一个人维护的定制模拟器上运行的，这为公司节省了每年数百万美元的模拟器成本（当时模拟器的标准价格是每个许可证每年几千美元，而我们有大约一千台模拟机器的农场）。你可能认为，如果一个人可以创建或维护一个对公司每年价值数百万美元的工具，我们的竞争对手也会这样做，就像你可能认为如果通过雇用一个知道如何切割晶圆的人能以更低的成本更快地发货，我们的竞争对手也会这样做，但他们大多没有这样做。

Joel Spolsky 有一篇旧文章说：

“找出依赖关系——然后消除它们。”当你是真正优秀的团队的一员，有优秀的程序员时，坦率地说，其他人的代码都是漏洞百出的垃圾，而且没有其他人知道如何按时交付。

我们有类似的态度，尽管我会说我们更谦逊一些。我们不认为其他人都在生产垃圾，但我们也没有假设我们无法以十分之一的成本制造出可以与我们购买的产品相媲美的东西。通过与一些竞争对手的人员交谈，我们的运作方式和他们的运作方式之间存在着相当大的文化差异。他们根本没有想到，他们不必接受标准的美国商业逻辑，即你应该专注于你的核心竞争力，你可以根据具体情况考虑内部做某事是否有意义，而不是将你的思考外包给一句简洁的格言。

我曾从内部观察过一家公司经历这种文化转变。一些领导层的人决定公司应该专注于核心竞争力，这意味着放弃用于基础设施的定制软件。这导致了大量从定制内部软件迁移到 SaaS 解决方案和开源软件。如果你观察关于各种项目“为什么”应该或不应该迁移的讨论，有一些异常“不讲理”的人试图根据每个案例的具体情况进行推理（在一篇关于抵制高层命令的文章中，Yossi Kreinin 称这些人是疯了的员工；我将在本文中指代同一个概念，但称之为“异常不讲理”的人）。但大多数人接受了党的路线，无论具体情况如何都推动迁移。

我认为有趣的是，领导层并没有告诉特定团队他们必须迁移，对于“异常不讲理”的人为了保持运行现有系统（出于合理原因）而抵制的团队，也没有真正的负面后果。相反，大多数人接受了这个想法，并试图为听起来合理但实际上与现实无关的理由进行迁移，导致一些有趣的结果，比如迁移到一个开源系统“以省钱”，而新系统显然效率低下⁶，并且可预见地需要更高的资本支出和运营支出。节省成本本应来自缩小团队规模，但运营成本的增加主导了团队成本的变化，而操作系统的复杂性意味着团队规模反而增加了。确实有一些迁移是有意义的，但陈述的迁移理由往往与实际有意义的理由无关或关系不大。一旦人们接受了公司应该专注于核心竞争力的思想，迁移就是由这种文化思想驱动的，而不是任何技术原因。

像上面这样的决策的普遍性——没有严肃技术考虑的技术决策——是公司制造好产品的选择压力如此微弱的一个主要原因。存在一些压力，但它非常嘈杂，以至于成功的公司常常绕过制造一个能工作的产品，就像上面的 Mongo 例子一样，Mongo 决定大声重复明显虚假的性能主张和做出明显错误的正确性主张，从商业角度来看，这比专注于实际的正确性和性能更优越；通过将资源集中在对业务重要的地方，他们成功地超越了那些犯了将大量资源投入到性能和正确性上的错误的公司。

Yossi 关于一个异常“不讲理”的人在他们看重的维度上能在公司产生超大影响的文章也适用于公司外部的影响。上面提到的 Kyle Kingsbury 就是一个例子。按我现在听说的Jepsen收费水平，Kyle 可以带来相当于大公司高级开发人员（真正的高级，不是头衔写着“高级”）的收入，但那是在多年的低于市场水平的长时间工作、在不确定的努力中进行的，在此期间他反驳了批评者的FUD（如果你阅读相关帖子下的回复，或者更糟的是，阅读他参与讨论的工单，多年来回复给 Kyle 的内容一直是一连串的胡言乱语，包括为供应商工作的人觉得他特别针对他们，贬低他的人格⁷，以及普遍贬低他）。我深深尊重那些尽管系统与他们作对，仍愿意推动解决这类问题的人，但尽管我尊重，基本上没有人会去做。一个需要像 Kyle 这样的人挺身而出，成功的公司才会在正确性而不是正确性营销上投入努力的系统，将会产生很多产品，它们擅长营销正确性，却没有真正的正确性属性（比如本文中提到的数据同步产品，其网站反复提到同步产品多么可靠和安全，尽管其设计存在根本性缺陷）。

在公司层面也是如此，通常需要一家异常“不讲理”的公司才能制造出真正卓越的产品，而不仅仅是被营销为卓越的产品，例如，Volvo，唯一一家似乎试图制造出超越 IIHS 测试所能证明的结构安全性的汽车制造商，其商业表现非常糟糕，以至于被迫转向高端市场，成为一家小众的豪华汽车制造商，因为尽管车祸是导致死亡的主要原因，也是预期寿命损失的重要来源，但消费者并不真正感兴趣于安全性。而且目前还不清楚 Volvo 是否能够持续作为一家“不讲理”的公司存在，因为他们无法作为一家独立的汽车制造商生存下来。当福特收购 Volvo 时，福特开始将 Volvo 转移到共享的福特 C1 平台，该平台在碰撞测试中表现并不出色。自从吉利收购 Volvo 以来，现在还太早，无法确定他们是否会保持 Volvo 为真实世界碰撞数据（而不仅仅是基准测试中报告的碰撞数据）设计的承诺。如果吉利拒绝继续 Volvo 对结构安全性的承诺，可能就无法买到一辆设计为安全的现代汽车了。

大多数市场都是如此，只是从一开始就从未有过像 Volvo 这样“不讲理”的公司。关于“不讲理”的员工，Yossi 说：

谁能够，有时也确实会，从底部清理变质的鱼？一个疯了的员工。一个发现叉子、崩溃等事情是对他的个人冒犯的人，并且会反复冒着惹恼管理层的风险，去阻止这些事情。尤其是那种把自己辛苦赚来的、管理层真正重视的政治资本，花在管理层并不真正重视的工作上的人——这样的人可以坚持战斗很长时间。有些人通过坚持直到管理层真正改变想法并奖励他们而成功地将其作为事业。无论成功的几率如何，普通人都无法理解试图完成这样壮举的人的动机。

很少有人愿意花费大量的个人资本去做正确的事，无论对某人来说这意味着什么，但更罕见的是，一家公司的领导层会做出这样的选择，花费公司的资本去做正确的事。

经济学家有一个术语，用于信息不对称导致买方无法区分好产品和“柠檬”的情况，“柠檬市场”，比如汽车市场（“柠檬”一词由此而来），或者招聘市场的双方。在经济论述中，关于汽车是否是柠檬市场存在争论，原因多种多样（允许人们退还有问题的柠檬车的柠檬法似乎没有改变市场的运作方式，当定义为具有严重可靠性问题的车辆时，很少有现代汽车是柠檬，等等）。但关注人们偶尔是否会买到有缺陷的汽车，是只见树木不见森林。可能只有一家汽车制造商真正认真地试图制造出超越标准机构测试水平的结构安全的汽车（而且有传言称他们在日益重要的软件测试方面偷工减料），因为消费者无法区分超过少数标准机构测试水平的安全性差异。那就是一个柠檬市场，几乎所有其他消费市场和企业对企业市场也是如此。

附录：文化

关于美国社会，我觉得有趣的一点是，有多少人认为，一个人因为未能保护自己应对所有突发情况而吃亏是“活该”（希望高度有效的组织通常通过拥有“免责”文化来避免这种情况，但很少有人接触过这样的文化）。

我最近看到的一些例子：

• 一个人在咖啡馆笔记本电脑被偷；被责备没有一直盯着笔记本电脑，因为没有一个理性的人会在转头和某人简短交谈时让目光离开自己的任何物品哪怕10秒钟
• 一个人发布了一份公共服务公告，说他们被一家公司服务条款的变更所困，其他人也应该注意同样的事情，人们说被困住的人很蠢，没有阅读他们收到的每一份服务条款更新的每一个字
• （很多次，在 r/idiotsincars 上）：一个人发生了事故，从合理角度很难或不可能避免，人们告诉这个人他们是一个糟糕的司机，没有避免事故
• 至少有一次，这个人进行了逐帧分析，显示他在一帧的延迟内尽可能快地做出反应，但仍然被告知他应该避免事故
• 人们经常会说“我一开始就不会陷入那种情况”，在有人经过停放的车辆行驶的情况下，会导致诸如“我绝不会以超过10英里/小时的速度经过车辆”之类的荒谬言论，就好像发表评论的人在每条有停放或停止车辆的街道上都会减速到10英里/小时一样。
• 一个人在 flyertalk 论坛抱怨 Google 地图说明不清楚（如果你不是机器人的话，比如“在500米后右转”，这可能是多个交叉路口之一），人们回应说诸如“我从不在完全熟悉路线的情况下出门”之类的话，并且你应该事先规划好所有的驾驶路线，就像你在1992年用纸质地图进行公路旅行一样（这被用作事先规划所有旅行的合理性的理由——我当时就是这么做的，任何不蠢的人现在也会这么做）
• 那些持有此类负面反应的人获得了大量点赞；没有人建议改用 Apple 地图，它提供清晰的、基于地标的指示，如“通过红绿灯，然后在下一个路口右转”

如果你阅读这类讨论，你会经常看到人们声称“世界就是这样的”，并且进一步说世界不可能以任何其他方式存在，所以任何没有为此做好准备的人都是白痴。

回到笔记本电脑被偷的例子，任何旅行过，甚至阅读过其他文化的人都可以观察到，北美人认为基本上是大规模社会固有结果的东西是武断的。例如，如果你把包和笔记本电脑放在咖啡馆的桌子上几个小时后回来，在韩国，包和笔记本电脑极有可能还在那里我听说在日本也是如此。虽然那样占着桌子不礼貌，但你的包和笔记本电脑不太可能被偷。

而且，事实上，如果你稍微改变一下语境，这在美国基本上也是真的。进入一个空房子并偷走里面的东西，并不比从咖啡馆偷走东西难多少（学习如何撬锁相当容易，而打碎窗户则更容易）。然而，在美国的大多数社区，人们很少被入室盗窃，当有人发帖说被入室盗窃时，他们不会因为没有看好自己的房子而被痛斥为白痴。相反，人们大多表示同情。在公共场所无人看管的财产被偷被认为是正常的，而在私人空间则不是，但这更多是一种文化上的区别，而不是技术上的区别。

有一个相关的系列故事，是 Avery Pennarun 讲述的关于他作为美国人在韩国的文化冲击。其中一个故事是关于某种你可以使用的在线订购服务，有点像 Amazon。在 Amazon，当你订购某物时，你会收到一个带有多个条形码/二维码/其他代码的盒子，当你打开它时，里面还有另一个至少有一个代码的盒子。当然，另一个盒子需要条形码，因为它要经过大规模的物流中心，没人知道盒子是什么或需要去哪里，内盒也需要经过某种其他类型的处理，并且如果商品在零售商处销售，也需要能够被结账机器扫描。内盒里面是商品。如果你想退货，你把商品放回带有条形码的盒子里，然后把那个盒子放进运输盒里，然后在运输盒上贴另一个条形码，然后寄出。

所以，在韩国，有某个类似 Amazon 的服务，你可以订购一件商品，一两个小时后，你会听到敲门声。当你到门口时，你会看到一个没有标签的盒子或袋子，商品就在这个没有标签的容器里。如果你想退货，你“告诉”应用程序你想退货，把它放回它的容器，放在你家门口，他们会取走它。看到这种与美国截然不同的物流设置后，他问某人“他们怎么可能不弄混哪个盒子是哪个？”他得到的答案是“他们为什么会弄混哪个盒子是哪个？”。他的其他故事也有类似的感觉，他在其中描述了一些相当陌生的事物，询问当地人事情怎么会以这种陌生的方式运作，而当地人无法想象事情以任何其他方式运作，并回应说“为什么X不行？”。

就像咖啡馆笔记本电脑的例子一样，Avery 的许多故事都归结为在人们和组织如何运作方面存在完全不同的共同文化期望。

另一个例子是新冠。我的许多朋友在过去几年里大部分时间都呆在越南或台湾等亚洲国家，那里的新冠感染率低得多，以至于他们几乎完全没有封锁。我在那些国家的朋友基本上可以过上正常的生活，就好像根本没有新冠病毒一样（至少直到最近的变种，在此之前他们已接种疫苗，并且对于最严重的结果来说风险相对较低），同时几乎冒着零感染新冠病毒的风险。

在大多数西方国家，许多人的最初舆论认为封锁是无意义的，我们无法防止新冠病毒爆发The request was rejected because it was considered high risk

由 mimo-v2.5 模型翻译，花费 20053 tokens

决定为棒球队“雇用”谁是一个涉及数百万美元（按2022年美元计）的高风险决策，但球队并没有尝试认真量化生产力，而是基于各种无关因素来决定选秀（雇用）谁。像任何主要运动一样，棒球生产力比大多数现实世界中的努力更容易量化，因为比赛比“真正”的问题简单得多。而且，在美国主要运动中，棒球是最容易量化的运动，但这并没有阻止棒球队在一个世纪里过度关注诸如身高和种族等显而易见的视觉标准。

前几天我看到推特上有一个帖子，一位非常成功的人谈到了他们是如何起步的，说他们尽管资历不足，但还是设法说服了一所精英学府录取了他们，并用这个故事得出结论：精英机构的把关者基本上就是在寻找人才，而你只需要向人们展示你有才华就行，这让我想起了这些老派的棒球球探报告：

关于大学的一个例子：我设法进入了卡内基梅隆大学，尽管我的成绩很糟，SAT分数也很低（我参加考试时感冒了：/）。

我花了一个月时间研究了CMU计算机系的一切，然后开车直接去那里和教授们交谈。当我第一次到校园时，招生办公室问了我的GPA和SAT分数，然后请我离开。但我设法和一位教授谈了话，他把我推荐给了他的上级，如此递归下去，直到我和该校的副校长谈上了话。他问我为什么我足够好到能上CMU，我说“我不确定我够格。其他孩子都非常聪明。我现在可以离开了”，他打断了我，提醒我进入这个房间需要多大的主动性。

他当场给了我一封手写的录取通知书……我认为一个秘密，至少就把关者而言，是他们通常只在寻找高主动性和才华。

我从其他成功人士那里也听过类似的故事，他们往往会得出双峰式的结论，关于这一切意味着什么。一些人认为世界正确地认可了他们的才华，世界就是这么运作的；才华得到认可和回报。另一些人则认为世界在回报才华方面相当随机，他们很幸运地因为自己的才华得到了回报，而许多其他使用类似策略、拥有类似才华的人却被忽略了²。

另一次让我想起老式棒球球探报告，是我听说我一位朋友的故事，她现在是一所顶尖加拿大大学的工程学教授。我们称她为简。当简还是她现在任教的大学的本科生时，在校园里有时会被人好心地问“你迷路了吗？”。有时这是因为作为女性，她出现在工程楼里看起来不太对劲。有时则是因为她看起来和说起来像来自加拿大乡村的人。有一次，保安以为她是误入校园的流浪汉。几年后，在大学朋友的帮助下——他们向她解释了应该如何说话和穿衣——她学会了合适的着装和举止，从而能够融入“那种人”。但当她年轻时，人们的第一印象认为她是行政助理，而现在他们的第一印象认为她是教授的妻子，因为他们没料到一个女性会是她所在院系的教授。她相当成功，但这比那些看起来更像样的人需要付出更多的努力。

关于她的把关者是否真的只看重主动性和才华，她有一次在土木工程考试中不及格，因为她从未听说过“玉米狗”（一种裹着玉米面糊的热狗），而在她勉强通过的一门入门编程课上，教授曾宣布任何还没学会编程的人都会不及格。

玉米狗考试不及格是因为土木工程考试中有一道题要求学生设计一个玉米狗分发器。我的朋友从未听说过玉米狗，就问教授什么是玉米狗。教授不相信她不知道玉米狗是什么，在全班面前斥责她提了一个明显不严肃的问题。由于不知道什么是玉米狗，她设计了一个将玉米放进热狗里、然后分发夹着玉米的热狗的装置，结果不及格，因为那不是玉米狗。

结果证明，土木工程和编程的把关者实际上并不是在寻找主动性，而是在寻找有合适背景的人。我怀疑这与那位当场录取了一位有前途的学生的CMU教授没有太大不同，只是碰巧有很多人把“成绩和SAT分数糟糕、有故事的聪明少年”模式匹配为“有前途的潜在天才”，而把“来自加拿大乡村、高中班级成绩第一、没怎么用过计算机、因为边打工边抚养弟弟边上大学（父母基本抛弃了他们）而穿着像加拿大乡村穷苦女孩”的模式匹配为“不属于工程领域的流浪汉”。

另一件让我想起棒球球探报告有趣之处的事情，是我前一阵子和本·库恩的一次对话。

我：在我这个级别（高级_staff工程师），大型科技公司的男性里，高个子真多，这很奇怪。就我最近的记忆，在这个级别或以上的会议中，我似乎只遇到过一个比我矮的男性。我只比美国平均水平矮1英寸！而且那个比我矮的人至少远程工作了十年，所以我不知道人们是否真正注意到他的身高。而且在管理岗位上，人们似乎甚至更高。如果我看看我参加过会议的副总裁们，他们肯定至少有6英尺高（约1.83米）。
本：也许我可以在一家大科技公司当副总裁。我身高6英尺！
我：哦，我猜我不知道6英尺有多高。我开会时遇到的副总裁们明显比你高。他们可能至少有6英尺2英寸（约1.88米）？
本：哇，那作为最低要求真的很高了。6英尺2英寸在美国成年男性中属于第96百分位数

当我与在大公司（科技公司、咨询公司等）工作的成功人士讨论这个问题时，那些按普通标准被认为高个子的男性，比如6英尺或6英尺1英寸（约1.85-1.88米），告诉我他们在重要会议中经常是房间里最矮的男性。6英尺1英寸略低于棒球运动员的平均身高。身高与作为咨询顾问或程序员的成功相关性似乎比在棒球领域更高，而身高在棒球领域直接带来优势，这有点奇怪。一个可能的解释是晕轮效应，即对高个子或看起来有权威感的人的正面联想有助于他们的成功。

当我在网上看到这个讨论时，有人会指出这是因为身高与认知表现相关。但如果我们看看IQ（智商）文献，这种相关性并不强，不足以解释像这样的情况。如果我们看看人们的心理敏锐度被IQ测试以外的东西直接测试的领域，比如国际象棋，其中大多数顶尖棋手身高在平均水平左右，有一些双向的离群值，我们也能观察到这一点。即使不详细看数据，这也应该是预料之中的，因为身高和IQ之间的相关性很弱，其中大部分相关性源于低端的关系³，而IQ与各种心理任务表现之间的相关性也很弱（有人会说按照社会科学的标准是强相关，但即使从人口水平来看，其实际解释力也非常弱，在个体层面就更弱了）。如果我们具体看看国际象棋，我们可以看到相关性很弱，正如预期的那样。

既然相关性很弱，而平均水平附近的人数又远多于其他水平，我们应该预期大多数顶尖国际象棋棋手身高在平均水平左右。如果我们看看近代历史上最顶尖的棋手，卡尔森、阿南德和卡斯帕罗夫，他们身高分别是5英尺8英寸（约1.73米）、5英尺8英寸和5英尺9英寸（约1.75米）（如果你查看不同来源，他们会声称身高上下浮动几英寸，但仍然在相当正常的范围内；人们经常夸大身高；如果你看看那些试图通过照片或亲身进行真实比较的人，测量身高往往低于人们声称的自己身高⁴）。

虽然很难找到围棋和将棋棋手的身高，但我能找到身高的顶尖现代棋手（李世石、羽生善治）似乎大致在正常范围内，而在那些不是史上最顶尖的精英棋手中，有一些双向的离群值，这和国际象棋一样。

如果身高或其他外貌因素与心理表现有很强的相关性，我们应该预期在那些相对直接测量心理表现的活动（如国际象棋）中，身高与表现的相关性要比身高与职业成功的相关性强得多，但情况恰恰相反，这似乎表明身高的晕轮效应比任何与身高相关的潜在好处都要强。

如果我们看看那些在人们真正展示技能之前存在大量筛选、但表现可以相当准确地衡量、并且雇用更好的员工会对公司业绩产生直接、可衡量、直接影响的领域，比如棒球和冰球，我们可以看到，在有关数据驱动方法发现人们直觉存在巨大漏洞的公开讨论出现几十年后，人们仍然依赖直觉而不是数据。

如果我们再看看编程，其中准确衡量个人表现介于极其困难到不可能之间，个人表现对公司成功的影响也远不如体育运动直接，那么我们对人才评估准确性的预期应该是什么？

悲观的看法是，我们似乎不太可能期望人才评估比体育领域更好，在体育领域，尽管有相当准确和严谨的公开表现评估报告，公司花了数十年才认真对待人才评估。而在编程领域，人才评估甚至还没有发展到可以准确评估整个行业人员的阶段，所以我们甚至还没有开始那场长达数十年的公司坚持基于个人意见而不是准确测量来评估人员的斗争。

在招聘阶段，工作有多个层次的过滤器，体现了人们的偏见。这方面的一个经典研究是伯特兰和森迪尔·穆来纳森的论文，该论文发现，简历上“听起来像白人”的名字比“听起来像黑人”的名字获得更多面试回电，并且在简历上使用“听起来像白人”的名字会提高简历上拥有更好资历所带来的回报。此后，有许多该研究的变体被完成，例如带有白人名字的简历比带有亚裔名字的简历表现更好，简历上带有白人名字的教授在人际交往技能方面被认为优于简历上带有黑人和亚裔名字的教授，等等。

关于晋升和定级的文献要薄弱得多，但我和其他处于高度筛选环境中的人（比如副总裁、资深个人贡献者、精英大学的教授等），都观察到身高的过滤在大型科技公司或咨询公司等机构中与棒球一样严重，甚至更严重，但不如篮球。

这很奇怪，因为在智力追求中，“晋升”标准直接由表现决定，例如在国际象棋中，身高似乎只与成功有非常弱的相关性。文献中的一个主要问题是，通常，社会科学家考察的是平均值。在许多研究中，他们只是给出一个相关系数。运气好的话，他们可能会画一个图表，为每个身高平均某个数值。这是最简单的做法，但这只能让我们对正在发生的事情有一个非常粗略的了解。

因为我想了解事物运作的方式，包括组织和人们的意见，我（非正式地、口头地）询问了许多工程师对其他工程师的看法。我发现存在很多意见的集群，导致对谁做出了出色工作有粗略共识的人群。在每个集群内部，人们通常会对工程师的排名有不同意见，但他们会大致同意谁是“好到优秀”的。

一个集群是（在我看来；当然，这也可能只是我自己的偏见）那些关注人们产出的成果并以此评判人的人。另一个集群是关注身高和自信的组合，并以此评判人的人。对我来说，这曾是个谜（很久以前，在我有写这篇文章的想法之前，我就习惯性地问人们这样的问题并整理数据，在我认识到这个模式之前，我发现奇怪的是，许多具有良好技术判断力的人——由他们做好工作的能力以及显示出良好技术判断力的评论证明——高度评价许多经常说明显错误的话、并生产出效果不佳甚至根本不工作的系统的人）。还有一个集群围绕资历，比如某人上的学校、职级或曾工作过的知名公司。人们可能拥有来自多个集群的判断力，例如，有些人会赞扬既做了出色技术工作的人，也赞扬高大自信的人。在更高层级，判断人们的工作变得更加困难，相对较少的人基于产出进行评判。

当我在我工作的那家初创公司做这项评估整理工作时，基本上只有一个集群，就是基于人们的产出，对于谁是顶尖工程师有相当广泛的共识，但在我工作过的任何大公司里我都没有看到过这种情况。我不会说那意味着那家初创公司的评估是公平的（也许我们所有人都陷入了同样的偏见），但至少我们没有陷入最明显的偏见。

回到大公司，如果我们看看改革晋升制度需要什么，在存在偏见的情况下似乎很难做到，因为许多个体工程师是有偏见的。一些公司让委员会处理晋升以减少偏见，但系统的主要输入仍然带有强烈偏见。委员会使用的输入是来自许多人的推荐，而这些人中的许多人让那些偏见比他们的技术判断权重更大。即使我们假设引入了一个系统，该系统能够识别谁的判断与与表现无直接关系的因素高度相关，并且不给予这些推荐任何权重，人们的意见常常限制了某人能做的工作。我听到一些初级员工抱怨说，他们无法晋升，因为他们的工作不符合晋升标准。当他们要求被允许做可能让他们晋升的工作时，却被告知他们资历太浅，不适合做那种工作。通常他们会停留在当前级别，直到找到一个足够相信他们潜力的经理，给予他们可能通过出色表现带来晋升的工作。另一个与此交互的因素是，如果你表现良好和/或拥有高“晋升速度”（即频繁晋升），调到有高影响力工作机会的团队会更容易，而如果你表现不佳，或者只是晋升速度低且表现不是特别差，调岗会更难。在更高层级，无法从事高影响力工作并不常见，但要区分个人表现和偏见的影响也非常困难，因为很多表现关乎你能影响谁，而这需要尝试影响那些可能有偏见的人（如果你需要大规模地做到这一点，而要晋升到更高层级通常需要），如果嵌套的、多层次的偏见影响使得改变系统以消除偏见影响变得困难。

虽然从整体系统来看很容易变得悲观，但当看个人能做什么时，也很容易变得乐观。做比尔·怀特（那位以推荐“长相滑稽”的棒球运动员而闻名的球探）所做的事情，忽略其他人错误地认为重要的事情⁵，是相当容易的。我曾在一家这样做的公司工作过，它拥有我工作过的所有公司中最好的工程团队。他们通过忽略其他公司关心的标准来做到这一点，例如雇用非精英学校的人，而不是关注出身背景，不因为没有练习解决工作中实际不解决的抽象白板问题而淘汰人，没有与工作表现无关的文化契合度标准（他们确实关心人们是否自主，并在高度独立时能有效运作），等等⁶。

感谢Reforge - 工程项目和Flatirons Development通过在主要赞助商级别赞助我，帮助使这篇文章得以发表。

同时，感谢Peter Bhat Harkins, Yossi Kreinin, Pam Wolf, Laurie Tratt, Leah Hanson, Kate Meyer, Heath Borders, Leo T M, Valentin Hartmann, Sam El-Borai, Vaibhav Sagar, Nat Welch, Michael Malis, Ori Berstein, Sophia Wisdom, and Malte Skarupke 的评论/纠正/讨论。

附录：其他因素

本文以身高作为一个贯穿始终的例子，因为它在男性中是容易观察到的与成功相关的因素，并且已在许多领域进行过研究。我猜测社会阶层标志/举止（如本文中的简的例子）至少有同样的影响。例如，许多人向我指出，他们周围的高个子成功人士说话时信心十足（常常是不正确的事情，但说得很自信），并且拥有传达自信和权威的举止。

其他身体因素似乎也有很大影响。有相当多的文献研究晕轮效应如何导致通常有吸引力的人在各种维度上获得更高评价，例如道德品质。在Ask Metafilter（Reddit之前的一个类似论坛）上有一个著名的回答，问题是“你怎么知道一个人是坏人？”，最受欢迎的答案（我希望是出于反讽的原因，尽管回答者看起来很认真）是他们牙齿不好。当然，在美国，牙齿不好是童年贫困的标志，而非道德品质的贫乏。当然，性别是另一个人们似乎基于与才华或能力无关的原因进行筛选的维度。

另一个因素就是纯粹的运气。回到棒球的例子，关于奇珀·琼斯少数几个负面球探报告之一来自一位球探，他说

挥棒时不够积极。无论从哪一侧都无法扎实击球。始终表现出漫不经心的态度。他让我失望。在8场比赛中，他只击出1安打，很少有扎实击球。左侧显示出击打式挥棒……2级工具

另一位看到他更典型表现的球探正确地指出

明确的大联盟前景……所有方面均达到或超过大联盟工具水准……凭借出色的本能、能力和比赛知识。具有超级明星潜力。

另一位同样指出：

这孩子拥有一切工具。力量出色，在本垒板前挥棒速度好，基本功扎实。性格和训练习惯出色。过去7年我在佛罗里达看到的最佳前景……这孩子必须被考虑为我们（首轮选秀）的 picks。各方面都出色且轻松自如。

表现存在很大方差。如果你通过短时间内观察某人来评判表现，你会根据观察时间的不同而得到截然不同的判断。

附录：相关讨论

如果你读过每个人都引用的那个盲听交响乐团试奏的研究，该研究本身似乎质量不高且缺乏说服力，但盲听试奏确实伴随着乐团雇佣那些不符合人们预期音乐家形象的人。在可能的情况下，盲听试奏似乎是值得尝试的好方法。

如前所述，一位教授提到，通过Zoom进行招聘偶然使得身高不如平时那么显眼，并导致至少一个大学院系雇佣了一些明显没有之前雇佣的教授那么高的教授。

我写的关于科技面试甚至不能有效过滤其名义上要过滤的主要内容。

我写的关于科技招聘如何注重声望。

@ArtiKel 写的关于考恩和格罗斯关于人才的书以及资助个人而非项目。我长期以来的一个问题是，那些通过某种人才选拔过程传递声望的非主流项目（蒂尔奖学金、泰勒·考恩、帕特里克·科里森、斯科特·亚历山大等人的资助）是否比传统选拔过程偏见更少，还是只是偏见不同。这本书似乎没有真正回答这个问题，但它引人深思。顺便说一句，我认为这些替代过程极具价值，即使它们并不更好，实际上，即使它们稍差，因为它们的存在为世界提供了更广泛的人才发掘组合。但即便如此，我还是想知道这些替代过程是否比传统过程更好。

Alexy Guezy 写的关于人才从何而来。

一位匿名人士关于人才错配。

Thomas Ptacek 关于在科技招聘中实际尝试寻找相关信号。

我关于在解释智商和人才重要性的类比中使用的手法，其中手法旨在让智商看起来比实际更重要。

Jessica Nordell 关于跨性别者的经历展示了男女待遇差异。

《点球成金》这本书，当然。不过，要了解真正的极客细节，我推荐阅读旧的棒球思考工厂档案，当时这个网站还叫“棒球迷论坛”。球迷们实时指出谁会成功，并且通常比当时的棒球队取得了更大的成功。随着棒球队开始认真对待数据，将业余爱好者的分析抛在身后（因为球队可以接触到好得多的精细数据，以及比业余爱好者更多的时间进行严肃分析），该网站逐渐衰落，但观察业余爱好者使用基本数据分析技术完全主导职业领域是很有趣的。

由 mimo-v2.5 模型翻译，花费 18961 tokens

本文与姚越合著

本文汇编了Twitter从采用现行事故追踪系统JIRA（2012年）至2022年间，至少部分归因于缓存的严重事故（SEV-0或SEV-1级别，即最高严重等级分类）信息，并附带一件2012年之前的额外事故。不计额外事故，事故追踪系统中共记录了6起SEV-0和6起SEV-1事故至少部分与缓存相关，另有38起严重性较低的事故未在本文讨论。

我们记录这些历史知识的原因有二：首先，科技公司的历史知识流失速度极快，我们认为保存部分记录很有价值；其次，从特定角度审视事故与可靠性问题、将所有信息整合一处，有时能让某些规律变得尤为明显。

关于知识流失，当我们观察到关于某科技公司事件的病毒式推文或其他传播内容时，深入调查发现广泛流传的故事通常因平庸的原因而严重失真。其一，极度夸张的故事更易传播，因此往往被记住；其二，存在一种前高管/副总裁宣扬个人功绩的特色产业，这些故事往往（委婉地说）扭曲事实（尽管普通工程师也可能这样做，但传播最广的虚假故事常来自管理岗）。在这两种情况下，都存在一种故事领域的格雷欣法则——错误故事往往压倒正确故事。

即便真心尝试理解事件经过，知识也会快速流失。在我们进行的事故分析项目中，近几年的文档和工单链接通常仍可访问（90%以上概率），但更早的链接失效风险显著增高，到2012年的内容时失效概率接近0%。有时，人们会将资料保存在锁定文档、邮件中，但这些资料常链接至已完全失效的内容。了解事件经过需与多人交流，而由于人类记忆的特性，人们会提供需要整合的碎片化叙述¹。

关于特定角度的观察，广义审视失败并分类汇总所有失败固然有用，但深入剖析特定类别的失败同样具有价值。例如，丽贝卡·艾萨克斯和丹·卢曾对Twitter故障转移测试（2018-2020年）进行（内部非公开）分析，发现多项促成运营变更的问题。从某种意义上说，分析中并无新信息，因为我们获取的信息均来自现有文档，但将信息整合一处后，多年间分散发生的事故中那些原本不明显变得清晰可见。

本文档不会在Twitter内部引发变更，因为缓存事故的规律及应对措施已进行过梳理，但将这些内容整理归档对外部人员可能仍有价值。

至于为何关注缓存故障（而非其他系统故障）——缓存相对常见地牵涉重大事故，正如姚越在内部Twitter故障故事分享会上（指代Twitter在运营方面的"黑暗时代"）的评论所示：

目前每起事故都至少提及缓存。事实上，很长时间里，缓存可能是导致网站宕机的头号原因。

我入职前六个月，每次重启缓存服务器，在当今标准下都是SEV-0事故。顺利的话，重启一个缓存后，外部请求的成功率（SR）可能还有95%...

此外，Twitter绝大部分缓存采用（memcached的分支版本）²，该技术在其他领域广泛使用，使得相关知识比讨论完全定制的Twitter系统更具普适性。

更广泛地说，由于缓存结构简单，它是相对纯净的真实世界分布式系统常见故障模式案例来源。概念上，缓存服务器是高吞吐量、低延迟的RPC服务器加上管理数据（如内存/磁盘及键值索引）的库。对于内存缓存，数据管理侧应能轻松超越RPC侧性能（原生内存键值库每核心可达百万级QPS，而未采用用户空间网络、批处理/流水线等技术的原生RPC服务器性能可能不足其十分之一）。由于RPC栈外的组件简单，缓存可视为近似纯粹的RPC负载，这在服务密集型架构中常至关重要。

当规模与性能成为关注点时，缓存常采用分片集群，这使其受制于分布式系统的约束与陷阱（但因性能优先，同步问题较某些其他负载如强一致性分布式数据库而言强调较少）。同时，由于分布式系统的特性，缓存使用者将暴露于这些故障模式，并可能受其级联影响而受损。

缓存故障模式亦颇具研究价值，因为当缓存承担显著比例的请求或数据服务时，缓存中断或性能下降极易引发全面宕机——为缓存性能设计的架构不会（也不应）具备足以维持网站运行的备用数据库性能。

相较于多数负载，缓存对底层栈（如内核、固件、硬件等）的性能异常更为敏感，因其通常具有高吞吐量、低延迟的SLO（缓存的意义在于快速），且大量时间（排除用户空间网络等情况）耗费在内核（Twitter memcached运行常规内核网络时约80%）。此外，因缓存服务器常运行少量线程，易受共享底层资源（CPU、内存、磁盘等）的其他负载影响而被阻塞。高吞吐量与低延迟SLO会加剧导致"死亡螺旋"的正反馈循环——这是分布式系统的经典故障模式。

审视下文事故时，我们将发现多数事故并非源于缓存逻辑错误，而是某种异常引发了未被充分缓解的正反馈循环，最终演变为失控反馈循环。

因此，阅读下文事故时，关注缓存与栈上调用者及栈下交互层的互动方式将大有裨益。另一值得关注点是：重大事故多因先前事故的修复措施未完全执行，或工程师认定的严重运营问题未获优先处理所致。这与丽贝卡·艾萨克斯和丹·卢在故障转移测试失败原因分析中发现的常见模式一致。

2011-08 (SEV-0)

数月内，大量用户自主发起的变更（如用户名、显示名、密码）遭回滚。此风险持续存在数年。

背景

当时，Rails应用采用单线程工作器，由单个主进程管理健康检查、重新部署等。若工作器卡顿30秒，主进程将终止并重启该工作器。

团队在裸金属服务器上运行，未使用Mesos或Kubernetes等集群管理器。团队拥有硬件全权，负责内核升级等。

键的分片定位算法涉及哈希运算。若节点失效，原哈希至此节点的键将被哈希至其他节点。每个工作器客户端独立进行路由决策以确定与哪个缓存分片通信，即各工作器独立判断缓存节点存活状态及键的位置。若客户端判定某主机"状态不良"，该主机将被"剔除"。

事件

11月8日，某用户将姓名从[旧名]更改为[新名]。一周后，其用户名回滚为[旧名]。

11月8日至12月初，客服提交数十起类似工单。Twitter缺乏定位故障点的监控手段，因此前两周调查主要为Rails应用添加指标以定位问题根源。每次变更需与部署团队协调，耗时至少两小时。Rails应用监控完善后，所有线索指向缓存为问题源头。确定缓存是否为真正原因的全套变更又耗时一两周，包括添加缓存不一致性、缓存异常路径及主机剔除的监控指标。

添加监控后，某工程师在12月初的JIRA工单中评论：

今日启用代码以查看缓存用户与数据库用户在将缓存用户数据写回数据库时的不同步程度。该比例约为0.2%...
检查Twitter上150名热门用户所在缓存分片数（理论上应不超过1个）。多数用户存在于至少两个分片，部分用户甚至多达六个。

首个修复措施是避免将过期数据写回数据库。但这未解决同一数据在不同缓存分片存在多份副本的问题。第二个修复措施旨在减少键出现在多处的频率，即多次重试后再剔除主机。其逻辑是：若主机真正永久宕机，应触发警报，但宕机主机的警报未触发，因此导致剔除的错误应为暂时性，客户端持续重试应能找到键"应在的位置"。随后，为防止因主机暂时性错误过多导致键波动，延长了被剔除主机的屏蔽时间。

此变更经单个缓存测试后推广至全部缓存。推广后网站立即宕机，因剔除仍在发生，而更长的屏蔽时间导致后端承压。当时后端采用MySQL，其配置下高负载时响应时间可能无限延长。这导致工作器响应时间无限延长，主进程终止工作器，当此情况大规模发生时因可用工作器不足导致网站宕机。

回滚第二个修复后，用户仍可见过期数据——尽管过期数据不再写回数据库，但缓存更新可能发生在某位置的键上，而客户端随后从另一位置读取到该键的过期缓存副本。另一缓解措施是将用户数据缓存从高利用率集群迁移至低利用率集群。

进一步调试后发现，重试可解决"随机"原因导致的尾部延迟剔除，但仍有高剔除率源于非随机因素。监控指标显示有时出现高丢包率，且与入站数据包速率相关而非带宽占用。高数据包速率与丢包时段检查主机发现，CPU0耗费65%-70%时间处理软中断，表明丢包可能源于CPU0无法跟上数据包到达速率。

修复措施为设置IRQ亲和性，将入站数据包处理分散至主机所有物理核心。部署修复后，新迁移用户数据的集群观察到丢包和缓存不一致，而原集群未出现。

时值12月底。检查其他集群发现部分集群也存在丢包。深入观察发现，丢包每20小时40分钟在特定主机上发生。所有问题主机均为特定硬件SKU与特定BIOS版本（最新版）。该SKU较早BIOS版本的主机正常。实为该BIOS版本的主机触发BMC每20小时40分钟执行高开销健康检查，期间内核被中断，无法处理任何数据包导致丢包。

内核团队约六个月前已发现此问题，并尝试推送内核配置变更（增大数据包环形缓冲区容量以防缓冲区溢出时暂时性问题导致丢包）进行修复。尽管该工单标记为已解决，但修复未广泛推广，原因不明。

快速缓解措施为错开主机重启时间，避免集群内数据包丢弃同步发生。

因BMC版本需与BIOS匹配且BMC无法回滚，无法通过回滚BIOS解决问题。为推进BMC和BIOS更新，硬件工程团队需进行紧急测试/验证（尽快完成），随后BIOS修复得以推广，丢包问题消失。

整体耗时约两个月。

但这并非彻底修复——主机剔除行为未变，任何导致部分（非全部）客户端剔除缓存分片的随机问题仍将引发不一致。修复此问题需改变缓存架构，这无法快速完成（耗时约两年）。

缓解措施/修复：

• 增加可见性
• 设置IRQ亲和性以避免CPU0过载
• 修复导致主机周期性丢包的固件问题
• 修复缓存架构以容忍分区而不引发不一致

经验教训：

• 需提升可见性
• 运维缓存需具备底层系统知识
• 实施隔离变更（推广IRQ亲和性修复时迁移至新集群，此举混淆了问题——同时修复了一个丢包问题并引入了另一个）

2012-07 (SEV-1)

非个性化趋势对约10%用户约10小时未显示，用户看到空白趋势框。

Rails应用更新部署后，趋势缓存停止返回结果。仅影响非个性化趋势（因个性化趋势由独立服务提供）。

两小时后确认因趋势缓存刷新守护进程段错误导致，原因为内存耗尽。根因是部署的变更在Trend对象中增加了Thrift字段，使趋势缓存刷新守护进程内存使用量超限。

虽有守护进程失败的警报，但其仅检查守护进程是否成功启动，未检查是否成功完成。

缓解措施/修复：

• 增加ulimit
• 警报标准改为作业成功完成而非作业启动
• 全局仪表盘添加404率指标

经验教训：

• 警报标准应为作业成功而非作业启动

2012-07 (SEV-0)

此为外界较知名的Twitter事故之一，因用户看到无图片和CSS的公共错误页面：

Twitter currently down for <% = reason %>
We expect to be back in <% = deadline %>

网站严重受损约四小时。

此事故的记录不甚完整（因该时期文档高度缺失，相关JIRA工单注明"此事故已进行深度事后分析与评审，关闭事故工单"，但书面文档大多已丢失）。

事故触发点为两排机架断电。对缓存的影响为：48台主机断电，一小时供电恢复后重启。其中37台主机的缓存因脚本预期存在的目录未挂载而启动失败。"手动"修复这些主机的布局耗时30分钟，随后缓存恢复。

该目录对运行缓存服务器（至少在当时Twitter的运行方式下）并非必需。但有一个脚本在启动时检查该目录是否存在，而一个月前从布局配置脚本中移除此目录时，该检查脚本未同步更新。

增加调试难度的另一因素是：主机重启后/proc未正确挂载。尽管这非事故原因，但其异常性导致确认此问题非事故部分且为需修复的独立紧急问题耗费时间。

若网站其余部分运行完美，上述缓存问题不应引发如此严重事故，但多因素叠加导致全站宕机持续较长时间。

其他问题包括：

• 应5秒超时的慢请求未超时，反而持续30秒直至处理该请求的整个工作器进程被终止重启
  • 原设计5秒超时的代码虽运行，但使用错误时间戳判断时长，故未触发超时
• 用户数据服务恢复缓慢
  • 故障期间日志记录消耗大量资源并引发极高GC压力
• 多台非缓存主机重启后启动失败，问题包括卡在fsck或PXE引导循环
• 尽管网站和错误消息为静态，停机页面使用Ruby通配符，向用户显示模板消息
  • 源于Twitter近期从Rails应用前端迁移至C++前端；错误资源直接复制而来，仍包含ERB模板
• CSS未加载，因网站CSS的加载源宕机
• 前端过载，健康检查发现分片异常时重启失败

缓存缓解措施/修复：

• 修复配置布局的软件以防未来复发
• 审计现有主机以修复当前受影响主机的问题
• 确保内核升级时挂载/proc
• 建立软件更新/升级流程以降低未来引入缺陷概率
• 确保缓存主机（及其他主机）在故障域间更均匀分布

其他缓解措施/修复（高度不完整）：

• 在监控主机上设置磁盘/RAID健康与维护
• 将故障/异常主机送至SiteOps维修
• 移除停机页面的Ruby通配符
• 将CSS打包至停机页面，使其他组件宕机时CSS仍可用
• 为前端添加过载保护机制
• 将用户数据服务的日志库更换为开销更低的日志库，防止高错误率时GC压力导致服务终止
• 修复5秒超时以读取正确标头
• 在栈的其他层级添加独立超时机制，当请求完全无进展时亦应触发
• 更改前端健康检查与重启机制以强制终止节点而非尝试优雅关闭
• 确保任何时刻仅有一个健康检查脚本版本在节点上运行

经验教训：

• 需主动测试故障模式，包括导致主机重启或超时的故障模式
• 需制定机架多样性要求，使部分机架故障不会不成比例地影响少数服务

2013-01 (SEV-0)

网站宕机3小时30分

负载增加（据我所知，当日属正常水平，非异常峰值）导致缓存尾部延迟上升。缓存尾部延迟上升源于新缓存主机未设置IRQ亲和性，导致队列积压和延迟升高。

缓存延迟升高加之推文服务使用缓存的设计，导致使用缓存的推文服务分片陷入GC死亡螺旋（延迟增加→待处理请求增多→GC压力增大→分片负载增加→延迟进一步升高），进而导致剩余分片负载增加。

当时，推文服务缓存与用户数据缓存共置于相同主机，每台主机承载1个推文服务缓存分片和2个用户数据缓存分片。推文服务缓存新增主机未引发问题。用户数据缓存于傍晚逐步新增主机，初始亦未引发问题。但晨间流量高峰（因同时接近亚洲和美国使用高峰，亚洲国家使用高峰常非"朝九晚五"工作时间，美国使用高峰在工作时间）触发IRQ亲和性问题。推文服务受IRQ亲和性问题影响远甚于用户数据服务。

缓解措施/修复：

• 缓存主机需设置IRQ亲和性（参照2011-08事故）
  • 将此设为服务器默认配置，而非缓存主机单独作为临时变更执行
• 调整推文服务设置
  • 减少最大连接数
  • 增加超时时间
  • 未进行GC配置变更，因当时GC统计未作为指标导出，且GC日志未记录足够信息以判断不良GC设置是否为诱因
• 调整所有使用缓存的服务设置
  • 将连接限制调整至稳态值的约2倍

2013-09 (SEV-1)

单数据中心网站整体成功率降至92%。用户受影响约15分钟。

时间线服务失去其使用的75%某缓存的访问权限。缓存团队对该缓存进行服务器集变更，而时间线服务未采用推荐机制消费缓存服务器集路径，导致其"未知"哪些服务器为缓存服务器。

缓解措施/修复：

• 时间线服务采用推荐机制查找服务器集路径
• 审计所有消费服务器集路径的代码，确保无服务使用非推荐机制

2014-01 (SEV-0)

单数据中心网站宕机，影响请求路由至该数据中心的用户约20分钟。

推文服务开始向缓存发送高负载。此前某变更移除了缓存连接数上限。当时缓存在约160万连接时将拒绝接受新连接。导致监控服务无法连接缓存分片，进而重启缓存分片引发宕机。

宕机前数月，已有五个工单描述此事故的多个诱因。

某工单（由C状态配置错误与SMI组合引发的较轻事故的后续）指出缓存在约160万连接时停止接受连接。某工程师深入调试此问题，查明原因并建议多种缓解路径。

关键因素之一是：尤其当缓存高负载时，尽管内核已建立TCP连接，缓存可能未accept连接。

客户端"未知"连接实际未对缓存开放，将发送请求并等待响应。若客户端"认为"需更高并发，Finagle可能开启多连接。150ms后请求超时。若缓存端队列过长，此时缓存可能尚未尝试处理该请求。

超时后，Finagle将重试并开启新连接，导致缓存分片每次过载加剧。

客户端侧，每个此类请求引发大量分配，导致高GC压力。

当时设置允许5次失败后将节点标记为不可用30秒，连接并行度为16，每个客户端尝试连接3台服务器。所有数值乘以分片数后，推文服务可在缓存接受连接限制前使其过载。

缓存侧有1个调度线程和N个工作线程。调度线程调用listen和accept，将工作放入工作线程队列。默认积压长度为1024。当accept因文件描述符限制失败时，调度线程在listen中将积压设为0，并忽略监听fd的所有事件。当连接关闭释放fd时，积压恢复为正常值并重新接受连接。

重大事故前观察到：当连接数"过高"时，连接开始被拒绝。一段时间后，拒绝连接产生的背压使缓存得以恢复。

问题的另一诱因是：某硬件SKU在缓存高负载下32KB页耗尽时发生OOM，增加未OOM的缓存负载。Twitter内核工程师在以下提交中修复：

commit 96c7a2ff21501691587e1ae969b83cbec8b78e08
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Mon Feb 10 14:25:41 2014 -0800

    fs/file.c:fdtable: avoid triggering OOMs from alloc_fdmem
    
    Recently due to a spike in connections per second memcached on 3
    separate boxes triggered the OOM killer from accept.  At the time the
    OOM killer was triggered there was 4GB out of 36GB free in zone 1.  The
    problem was that alloc_fdtable was allocating an order 3 page (32KiB) to
    hold a bitmap, and there was sufficient fragmentation that the largest
    page available was 8KiB.
    
    I find the logic that PAGE_ALLOC_COSTLY_ORDER can't fail pretty dubious
    but I do agree that order 3 allocations are very likely to succeed.
    
    There are always pathologies where order > 0 allocations can fail when
    there are copious amounts of free memory available.  Using the pigeon
    hole principle it is easy to show that it requires 1 page more than 50%
    of the pages being free to guarantee an order 1 (8KiB) allocation will
    succeed, 1 page more than 75% of the pages being free to guarantee an
    order 2 (16KiB) allocation will succeed and 1 page more than 87.5%
    of the pages being free to guarantee an order 3 allocate will succeed.
    
    A server churning memory with a lot of small requests and replies like
    memcached is a common case that if anything can will skew the odds
    against large pages being available.
    
    Therefore let's not give external applications a practical way to kill
    linux server applications, and specify __GFP_NORETRY to the kmalloc in
    alloc_fdmem.  Unless I am misreading the code and by the time the code
    reaches should_alloc_retry in __alloc_pages_slowpath (where
    __GFP_NORETRY becomes signification).  We have already tried everything
    reasonable to allocate a page and the only thing left to do is wait.  So
    not waiting and falling back to vmalloc immediately seems like the
    reasonable thing to do even if there wasn't a chance of triggering the
    OOM killer.
    
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Cc: Cong Wang <cwang@twopensource.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

此例再次说明Twitter规模的公司拥有内核团队的价值。

另一工单强调了缓存主机设置标准化的重要性（如IRQ亲和性、C状态、睿频加速、网卡绑定、固件版本），此为跟进更早工单中指出的推文服务部分主机延迟升高问题——最终查明源于某内核升级影响特定硬件SKU，因内核与固件版本交互导致SMI增加。

缓存缓解措施/修复：

• 将积压从1024降至128，使调度器过载时更快施加背压
• 降低文件描述符限制以避免部分分片内存耗尽
• 缓存使用固定哈希表大小以避免哈希表迁移期间大量分配和内存/CPU负载
• 低延迟memcached主机使用CPU亲和性

这些缓解措施的测试表明，即便客户端修复尚未实施（防止其"试图"压垮缓存），这些措施也能防止缓存于类似事故条件下崩溃。

推文服务缓解措施/修复：

• 调整超时、重试和客户端并发连接设置以避免过载缓存

经验教训：

• 硬件设置一致性至关重要
• 高积压深度后才施加背压可能危险
• 客户端设置重试策略时应"审慎计算"，避免采用在100%响应失败且施加最大背压时仍可能完全压垮缓存服务器的策略

2014-03 (SEV-0)

艾伦·德杰尼勒斯在奥斯卡颁奖典礼期间发布的推文被大量转发，导致搜索功能宕机约25分钟，并引发网站宕机，多数用户无法使用。

此事故涉及多环节。从缓存角度看，此为缓存因异常客户端行为过载的又一案例。

与2014-01事故相似，但当时为该事故实施的缓存侧缓解措施不足，因"攻击"客户端采用了比2014-01事故中推文服务更激进的参数，且此时部分缓存运行于共享Mesos的容器化环境，使其易受节流死亡螺旋影响。

对此直接问题的主要修复为为Finagle memcached客户端增加流水线支持，使多数客户端仅需1-2个连接即可获得足够吞吐量，降低客户端持续冲击缓存致其崩溃的概率。

其他服务实施近50项修复。部分主要主题：

• 在适当时机施加背压
  • 施加背压时避免重试
• 确保数据（主要）流向同一数据中心以避免昂贵缓慢的跨数据中心流量
• 创建适当线程池防止关键工作被阻塞
• 为热点项目添加进程内缓存
• 高负载时返回查询的部分结果（不因结果不完整而拒绝请求）
• 制定缓存客户端配置指南以防对缓存发起DDoS

2016-01 (SEV-0)

日本前偶像团体SMAP（后转型为流行乐团及日本收视率常居首位的综艺节目主持人）举行发布会否认解散谣言。此事件导致单数据中心宕机，影响路由至该数据中心的用户约20分钟（直至流量切换至其他数据中心）。受损数据中心服务恢复耗时约六小时。

某数据中心推文服务负载激增，导致39台缓存分片主机OOM终止进程。集群管理器未自动将死亡节点移出服务器集——因死亡节点过多（节点少量故障时自动移除机制仍有效，但节点大量故障时自动化操作可能加剧灾难性故障——从缓存服务器集移除节点可能导致持久存储流量激增）。缓存运维人员手动清理死亡节点后，应重启节点的服务因Puppet变更意外移除了该服务的缓存相关配置而未能重启节点。回滚不良Puppet提交后，缓存分片启动但初期恢复过慢，随后恢复过快，导致推文服务成功率恢复耗时延长。

缓存分片主机因内核套接字缓冲区内存分配过多而OOM。

初始修复为将主机TCP缓冲区大小限制为4GB，但压力测试失败，查明因高运行时间（2年）主机内存碎片导致失败，缓解措施为更频繁重启主机以清理碎片。

缓解措施/修复：

• 每两年重启主机一次以上
• 为缓存主机添加Puppet警报以检测破坏性Puppet变更
• 改进集群管理器以处理大规模变更（因更早的小型事故，此变更已在进行中）

2016-02 (SEV-1)

此为上述2016-01 SEV-0事故中提到的压力测试失败。导致网站成功率轻微下降数分钟直至压力测试终止。

2016-07 (SEV-1)

计划中将用户数据缓存从专用主机迁移至Mesos引发单数据中心服务显著降级，随后另一数据中心轻微降级。部分现有用户受影响，所有基本为新用户注册失败约半小时。

集群管理器以最快速度将115个新缓存实例添加至服务器集，导致缓存命中率下降。预期集群管理器每20分钟添加1个分片，但配置变更意外修改了最小缓存集群规模，"迫使"集群管理器尽可能快速添加节点。

一次性添加大量节点使用户数据缓存命中率从常规99.8%降至84%。为阻止情况恶化，运维人员终止集群管理器以防其向服务器集添加更多节点，随后重新部署集群管理器至先前状态以恢复原配置，用户数据缓存命中率立即改善。

缓存命中率下降期间，备用数据库流量激增引发长时间GC暂停。导致缓存未命中的用户数据服务请求查询备用数据库时成功率为0%。

虽有限流机制防止过载备用数据库，但阈值设置过高未触发。为恢复备用数据库，运维人员执行滚动重启并部署严格限流。因单数据中心流量切换，严格限流在另一数据中心触发（因流量切换导致该数据中心流量升高），导致用户数据服务成功率轻微下降（请求被严格限流拒绝），故此事故亦影响未受初始缓存宕机影响的数据中心。

缓解措施/修复：

• 添加部署钩子，在向缓存集群添加或移除大量节点时警告运维人员
• 运维手册中增加部署、集群创建、扩容、缩容等操作的详细信息
• 为所有"零级"（关键）缓存部署添加检查清单

2018-04 (SEV-0)

计划中的测试数据中心故障转移导致网站部分宕机约1小时。故障转移开始1分钟后发现成功率下降。故障转移测试立即回滚，但网站完全恢复耗时近1小时。

初始网站降级源于用户数据服务错误率升高，由缓存热点键导致。原设计有缓存热点键机制：采样1%事件（采样用于减少开销，逻辑是若键为热点，即使采样亦应被发现），将采样键放入带哈希映射的FIFO队列以统计各键出现频率。

尽管此机制在过往高负载事件中有效，但在某些情况下（虽非事故根因）因值过大效果不佳——1%采样率无法使缓存及时"发现"热点键（当存在大（因此昂贵）值时）。原始热点键检测逻辑为推文服务缓存设计（最大键约5KB），后被用于其他缓存（键可能大得多）。设计热点键提升时，用户数据缓存未纳入考量——因其时最热键由进程内缓存服务，无热点键问题。

大键问题因使用FNV1-32进行键哈希而加剧（忽略最低有效字节）。问题数据集的方差集中于最后字节，使用FNV1-32导致所有大值键存储于少量缓存分片。早在2014年即有建议迁移FNV1-32，且更现代的哈希函数已加入工具库，但部分缓存所有者未选择迁移。

因热点键提升逻辑未触发，热点缓存分片的流量饱和了配备1Gb网卡的分片的NIC带宽（Twitter硬件通常异构——除非确保集群仅含特定规格；许多缓存主机配备10Gb网卡，但许多也配备1Gb网卡）。

修复/缓解措施：

• 调整用户数据缓存热点键检测
• 将相关缓存集群的所有硬件升级为配备10Gb网卡的主机
• 部分缓存从FNV迁移至murmur3

2018-06 (SEV-1)

测试数据中心故障转移期间，部分操作成功率降至约50%，直至约四分钟后中止测试故障转移。

缓存角度的问题在于：推文服务缓存分片处理流量的能力远低于预期（约50%），基于未反映真实流量的负载测试导致缓存配置不足。负载测试设置不真实的原因包括：

• 到达分布高度非独立，负载下因相关到达产生大尖峰。通常假设恒定或泊松到达分布，但审视指标数据时发现，负载生成器常用的恒定或泊松假设在实际流量下可能完全错误，导致真实负载与基于简单假设的负载生成器可达吞吐量差异无限大
• 负载测试使用的连接数远少于实际高负载时的连接数

缓存性能下降的另一原因为：每分钟有一次容器化性能计数器采集运行十秒，此操作开销较高——因采集的计数器远多于硬件计数器数量，内核需执行高开销操作切换采集的计数器。

性能下降导致计数器采集窗口期间延迟升高，缓存分片无法在容器节流限制前完成工作，延迟升高至推文服务请求超时。按配置，连续12次对单个缓存节点失败后，推文服务客户端将节点标记为死亡30秒并停止向其发送请求，导致节点30秒内无流量（客户端独立决定标记节点死亡）。这导致备用数据库请求量超过配额，请求被数据库拒绝，推文服务失败率升高。

缓解措施/修复：

• 推文服务客户端与缓存的连接数从4减至2，降低延迟
  • 如前事故所述，添加流水线支持使缓存仅需1个客户端连接即可高效运行，但部分工程师担忧1个可能不足（因此前连接数远高），故选择4个"以防万一"。但标准Linux内核网络下，更多连接反而增加尾部延迟，因此降低性能
• 增加缓存节点以减少单个缓存分片负载
• 改进缓存热点键提升算法
  • 此非特指本事故，但某工程师分析发现一年前引入的热点键提升算法在某缓存集群的缓存命中率仅约0.3%（源于多种问题）。改用更优算法显著提升缓存命中率与性能
• 修改缓存验证流程，使确定容量（节点数）的缓存性能更贴近真实世界性能
• 详细分析多路复用性能计数器采集的开销

感谢Reforge - 工程项目和Flatirons Development通过以主要赞助商级别赞助我，助力本文发布。

另感谢Michael Leinartas、Tao L.、Michael Motherwell、Jonathan Riechhold、Stephan Zuercher、Justin Blank、Jamie Brandon、John Hergenroeder和Ben Kuhn的评论/修正/讨论。

附录：Pelikan缓存

Pelikan旨在解决我们在大规模运维memcached和Redis时遇到的问题。本文档解释了Pelikan的部分设计动机。模块化/易于修改的特性使我们能发现新颖的缓存创新，例如解决现有淘汰算法问题的全新淘汰算法。

就本文讨论的问题类型而言，生产环境测试表明Pelikan相比现有缓存具有更可预测的性能、更优的中位性能和更优的尾部性能，这意味着我们以更低成本获得更高可靠性与容量。

由 mimo-v2.5 模型翻译，花费 21950 tokens

你不必在派对上才能看到这种现象发生，但我经常在那些重视智力与聪明才智，却不同样重视实践知识或学术严谨性的社交圈的派对上，看到一种奇特的现象。人们常常讨论一些标准的时髦话题（我近期在多个派对上观察到的一些例子是：如何构建一个与谷歌搜索竞争的产品，以及如何解决交通建设成本高昂的问题），然后解释为什么该领域的现有从业者做法是错误的，接着再阐述他们自己会如何改进。我偶尔也会有符合这种模式的良好对话（与那些拥有深厚专业知识、多年来致力于改变该领域的人），但更常见的情况是，一个对某个领域只有“鸡尾酒会级别”了解的人，会对如何修复该领域提出自己的想法。

在我参加的那些充斥着这种肤浅伪技术讨论的派对上，询问人们为何认为他们的方案能解决该领域的有价值问题，已经成了我的一个爱好。当我询问细节时，我发现，在我有一定了解的领域里，人们通常不知道需要解决哪些子问题才能解决他们试图处理的问题，使得他们的方案毫无希望。多次尝试之后，我的观点是，根本原因通常是许多对某个主题有肤浅理解的人，认为该主题的复杂度等同于他们对其理解的深度，而不是意识到仅仅知道一点皮毛意味着他们不了解该主题完整的复杂性。

由于我经常参加程序员的派对，这意味着我经常听到程序员复述他们对另一个领域鸡尾酒会级别的理解（尽管上面提到了搜索引擎的例子）。如果你想在网上看看类似的评论，当程序员讨论“传统”工程领域时，通常可以看到。我欣赏的一个例子是这条推特线程，Hillel Wayne讨论了没有传统工程知识的程序员通常对传统工程的面貌持有不正确的看法，其中许多回复来自对传统工程几乎一无所知的程序员，然后他们以自己的误解回复Hillel。当Hillel完成他的交叉领域项目（他采访了那些既在传统工程领域又在软件行业工作的人）时，他收到了更多此类评论。即使人们被警告说，对一个领域的朴素看法很可能是错误的，许多人也忍不住，会立即对他们基本一无所知的领域发表自己的看法。

总之，在交叉领域项目中，Hillel比较了那些真正曾在多个领域工作的人对领域的看法与流行程序员对传统工程的看法。Hillel给出的众多例子之一是关于造桥的讨论，他指出程序员会说这样的话：

一个真正工程师的世界的可预测性是令人羡慕的。但我们所处的世界总是在变化，物理定律每周都在改变。如果我们不能迅速适应不可预见的状况，唯一可预见的事件就是我们自身的毁灭。

以及

没有人会在桥梁建造中途考虑移动起点或终点。

但是Hillel采访的一位土木工程师说，他们确实移动过一座桥！当然，土木工程师移动桥梁的频率不如程序员处理软件变更的频率，但是，如果你与实际工作的土木工程师交谈，许多土木工程师经常处理开始工作后需求变更的情况，这与程序员在工作中处理的情况并没有本质区别。那些在两个领域都工作过或至少与另一个领域的人交谈过的人，往往认为两个领域工程师面临的问题都很复杂，而那些对领域只有鸡尾酒会级别理解的人却经常声称他们不从事的那个领域很简单，不像自己的领域。

我常听程序员说，编程就像“必须在飞机飞行时建造它”，这隐含着编程比设计和制造飞机更难的论点，因为设计和制造飞机的人可以在飞机飞行之前完成这些工作¹。但是，当然，设计飞机的人也可以同样轻松地说，“天哪，如果我的飞机能达到4个9的正常运行时间，并且允许我的飞机每周崩溃一分钟并杀死所有乘客，那我的工作就会非常简单。”当然，不同项目类型和不同领域的约束使得不同的事情变得困难，但人们似乎常常很难看到其他领域存在而自己的领域没有的约束。人们可能认为，理解自己领域比外行天真想象的更复杂，会帮助人们理解其他领域也可能隐藏着复杂性，但情况通常并非如此。

如果我们看看Hillel引用的那句话的其余部分（来自Stack Exchange问题的最高票且被接受的答案），作者继续说道：

当提前确切知道要求你预测的内容时，做出准确预测要容易得多，而不是猜测并处理不断的变化。

绝大多数桥梁都使用极其成熟可靠的材料、架构和技术。一位罗马工程师被传送到两千年后，通常仍然能认出现代建筑工地上正在发生的事情。当然会有差异，但你仍然在用拱形结构平衡荷载，仍然使用许多相同的材料等等。另一方面，大多数正在建造的软件……

这是人们在讨论鸡尾酒会想法时所犯错误的典型例子。当不称职的高管（他们已经十年没当过程序员了）对正在进行的项目提出不合理的变更要求时，程序员确实会抱怨，但这与那些从未当过土木工程师的政治家在大型土木工程项目上要求变更相比，并没有太大不同，甚至更可能合理。我猜想，平均而言，编程项目比土木工程项目有更频繁或更大的项目变更，但领域内差异可能至少和领域间差异一样大。

当然，只有那些没有在物理世界中做过严肃工程工作的人才会说“一个真正工程师的世界的可预测性是令人羡慕的。但我们所处的世界总是在变化，物理定律每周都在改变”这样的话，认为物理定律的（相对）固定性意味着物理工作是可预测的。当我作为一名硬件工程师工作时，我项目中的很大一部分工作量和复杂性都用于处理物理不确定性，土木工程也是如此（如果有什么不同的话，土木工程师用于处理大型项目物理不确定性的工具要糟糕得多，导致更大程度的不确定性和因不确定性导致延误的能力下降）。

如果我们看看罗马工程甚至300年前的工程与现代工程的不同之处，一个主要差异来源是来自于物理世界的、我们对不确定性更好的理解。过去，在没有异常条件或刺激的情况下（例如建筑物倒塌，或由于铁轨铺设不正确导致的火车事故），建筑结构在建成不久后就失效并不令人震惊。这种情况现在在美国或加拿大已经很少发生，一旦发生就是重大新闻，这种理解也让我们能够在以前被认为难以建造中型结构的地方建造巨型结构。

例如，如果你看看温哥华地区一个建在三角洲（Delta, Richmond, 以及延伸到Hope的大片土地）上的大型建设项目，直到相对较近，我们才发现了必要知识，能够在这种地面上可靠地建造一些大型结构（例如较高的建筑物），这是现代土木工程中罗马工程师无法理解的众多部分之一。这很大程度上源于一个叫做岩土工程的领域，它是土木工程的一个分支（或者，可以认为是一个独立的领域，也可以认为是地质工程的一个子领域），涉及地面问题，即土壤力学、岩石力学、地质学、水文学等等。岩土工程的一个基本概念是将力学应用于土壤推理。已知的第一次将力学应用于土壤（这是岩土工程的一个基础部分）是在1773年，而当今意义上的岩土工程通常被认为始于1925年。虽然罗马工程师做了许多令人印象深刻的工作，他们当时运作的心智模型妨碍了理解现代土木工程的大部分内容。

自然，为了让这些知识能够改变我们能建造什么，它必须改变我们的建造方式。如果我们看看一个在温哥华可压缩三角洲土壤上、运用了现代知识的施工现场是什么样子，按挂钟时间计算，大部分时间看起来就像有人在工地上堆了一堆沙子（预压）。虽然罗马工程师知道一堆沙子是什么，但他们不知道有人如何算出需要多少沙子以及沙子需要堆在那里多长时间（在某些情况下，罗马人会使用桩或筏，这类似于我们今天使用预压解决的问题，但在许多情况下，他们对预压今天解决的问题无能为力）。

岩土工程以及由此产生的沙堆（预压）只是进行现代大型土木工程项目时你需要专业知识的数十个子领域之一，而罗马工程师需要相当多的教育才能真正理解它。

回到我听到的鸡尾酒会解决方案，一个常见的方案是如何修复高昂的建设成本和缓慢的施工进度。有一些时髦的想法被人们随意谈论，关于为什么事情如此昂贵，为什么项目比预期花费更长时间等等。有时，这些评论与我从参与项目的执业工程师那里听到的相似，但更多时候，原因大相径庭。当原因相同时，似乎那一定是巧合性地正确，因为他们似乎不理解进行工程权衡推理所需的知识体系²。

当然，像鸡尾酒会理论家一样，具有该领域专业知识的土木工程师也认为现代建筑是浪费的，但他们得出的原因通常与我在派对上听到的非常不同³。通过不理解问题、假设问题人为地简单，然后为想象中的问题想出解决方案，很容易为问题提出鸡尾酒会解决方案。要理解大型建设项目所需的数十个相互作用的工程子领域之间的权衡，并就权衡应该如何进行以及如何激励工程师和决策者改变权衡的落点进行实际相关的讨论，则要困难得多。

一项被广泛引用的关于人们普遍拥有对事物运作方式极其过度简化且不正确的模型的研究是Rebecca Lawson关于人们理解自行车工作原理的研究（研究链接），该研究指出：

最近的研究表明，人们常常高估自己解释事物运作机制的能力。Rozenblit和Keil（2002）发现，人们对复杂现象的理解力进行了过高的评价。这种解释深度错觉并非仅仅源于一般的过度自信；它特别存在于对因果复杂系统（如人造物：弩、缝纫机、微芯片；以及自然现象：潮汐、彩虹）的理解上，相对于其他知识领域，如事实（首都城市名称）、程序（烘焙蛋糕）或叙事（电影情节）。

以及

如果外行未能解释齿轮如何工作的复杂性或为什么自行车前叉的角度至关重要，这并不令人惊讶。事实上，甚至物理学家在看似简单的问题上也有分歧，比如为什么自行车是稳定的（Jones, 1970; Kirshner, 1980）以及它们如何转向（Fajans, 2000）。当前研究结果引人注目之处在于，有这么多人对自行车如何运作几乎一无所知。

在研究的“实验二”中，人们被要求画一辆能工作的自行车，并专注于使自行车工作的机制（而不是让图画看起来好看），94名参与者中有60人至少犯了一个严重错误，导致图画看起来甚至不像一辆能工作的自行车。如果我们看看一个大规模的真实世界土木工程项目，仅一个相关的子领域（如岩土工程）就包含了比自行车多出许多数量级的复杂性，并且可以相当有把握地猜测，精确到百分比的话，零百分比的外行（或罗马工程师）能够大致勾勒出相关运作部分是什么。

对于非土木工程的例子，Jamie Brandon引用了Jim Manzi的《Uncontrolled》中的一段话，这是对我在派对上经常听到的一个“聪明”小观点的反驳：

选择悖论是一个广为流传的民间故事，它基于一个实验：在超市展示中提供更多种类的果酱反而导致购买量减少。给出的解释是选择带来压力，因此一些人面对太多可能的果酱，干脆放弃，空手回家。这个实验在新闻和媒体中被不断引用，通常描述为“科学家发现选择对你有害”。但如果你去一个大型超市，你会看到大约1200万种果酱。他们没听说过果酱实验吗？Jim Manzi在《Uncontrolled》中写道：

首先，请注意，所有的推断都建立在总共只购买了35罐果酱的基础上。其次，请注意，如果果酱实验的结果有效且具有作为经济或社会政策基础所需的普遍适用性，那将意味着许多商店可以削减75%的产品，并导致销售额增加900%。这将是一个相当惊人的结果，并表明测量可能存在问题。

……原始实验的研究者 themselves were careful about their explicit claims of generalizability, and significant effort has been devoted to the exact question of finding conditions under which choice overload occurs consistently, but popularizers telescoped the conclusions derived from one coupon-plus-display promotion in one store on two Saturdays, up through assertions about the impact of product selection for jam for this store, to the impact of product selection for jam for all grocery stores in America, to claims about the impact of product selection for all retail products of any kind in every store, ultimately to fairly grandiose claims about the benefits of choice to society. But as we saw, testing this kind of claim in fifty experiments in different situations throws a lot of cold water on the assertion.

作为一个实际的商业案例，即使是对构成有用前向预测规则的因果机制进行简化，也不太可能像“将QwikMart商店重命名为FastMart将导致销售额上升”这样，而更可能是“在繁忙道路的高收入社区将QwikMart商店重命名为FastMart，只要商店因粉刷关闭不超过两天，将导致销售额上升”。我们极不可能在开始测试之前就知道所有可能的隐藏条件，并且能够设计并执行一个测试来发现这种充满条件的规则。

此外，这些因果关系本身也经常变化。例如，我们发现某个特定的销售促销活动与没有促销活动相比带来了净利润增长，但第二年，当发生大量变化时——我们的竞争对手推出了新的促销活动，整体经济恶化，消费者流量从购物中心稍微转向了带状购物中心，等等——这个规则不再成立。用之前的比喻来说，我们是通过撞到家具来在黑暗的房间里摸索前进，而未被观察到的顽皮小鬼（gremlins）一直在我们周围移动家具。由于这些原因，仅仅运行一个实验，发现一个因果关系，并假设它广泛适用是不够的。我们必须运行测试，然后在实际实施中测量从这些测试中得出的规则的实际预测能力。

到目前为止，我们讨论的都是没有某领域背景的人解释该领域如何运作或应该如何运作的例子，但当人们退后一步，以一种脱离细节的高层视角看待自己领域时，这种犯下“错误地假设事情很简单”的错误也会发生。例如，当我在Centaur工作时，我们尚未推出双核芯片，一位来自顶尖学校的即将毕业的计算机体系结构博士生问我：“为什么你们不直接把两个核心钉在一起做一个双核芯片，就像Intel和AMD那样？那是个轻松的胜利。”

那时，我们从单核转向多核的研究已经进行了一年多。将一个单核芯片变成多核甚至多处理器能力，且性能良好，需要对缓存和内存层次结构（芯片中逻辑最复杂的部分）进行显著额外的复杂设计。粗略估计，我认为，将一个为单核使用设计的芯片变成具有多处理器能力的芯片，至少会使生产一个可工作芯片所需的测试/验证工作量加倍（而芯片设计的大部分工作都用于测试/验证）。更普遍地说，计算机体系结构师的水平取决于他们对自己决策所影响的权衡的理解深度。优秀的架构师对他们必须交互的底层领域有深刻的理解。计算机体系结构师做出糟糕决策的一个常见原因是，他们对计算机体系结构下一层或两层的领域只有鸡尾酒会级别的理解。工业界多次发生的一个糟糕决策的例子是，当一个在职的计算机体系结构师决定在芯片上添加SMT，因为它基本上是白送的好处。你支付几个百分点的额外面积，就能获得大约20%的性能提升。我知道有多次尝试这样做都完全失败了，原因可以预见：架构师没有考虑到添加SMT带来的复杂性和验证成本。添加SMT比添加第二个核心带来的复杂性更多，因为逻辑必须贯穿所有部分，并且由于同样的原因，它导致验证芯片复杂性的爆炸性增长。英特尔在P4上添加SMT并著名地没有在其发布的第一代产品中启用，因为它太复杂了，无法在一代产品内验证，并且存在关键的、阻碍性的bug。经过他们多年的时间在一代架构上修复bug后，他们在下一代芯片中修复了SMT实现并发布。当他们迁移到Core架构并在其上添加SMT时，这种情况再次发生。一个在职的计算机体系结构师应该知道这在英特尔身上发生过两次，这意味着验证一个SMT实现是困难的，但仍然有多次有人对SMT的复杂性只有鸡尾酒会级别的理解，并建议将其添加到没有验证预算来发布带有SMT的可工作芯片的设计中。

当然，这并非计算机体系结构独有。我使用双核的例子是因为它恰好是目前我记忆犹新的一个，但我可以随口说出几十个类似的例子，并且我敢肯定，如果我花几天时间思考类似的例子，可以写出几百个。在一个领域工作的人仍然必须非常小心，以避免拥有不正确的、过于抽象的世界观，从而忽略细节，并因此得出荒谬的错误推论或结论。当领域外的人解释事情应该如何运作时，他们的解释通常比领域内忽略了关键考量的人更糟，而且他们通常提出古怪的想法。

结合罗马工程和CPU的例子，从1个核心到2个（以及一般而言，从1到2，例如从1个数据中心到2个数据中心，或从单体应用到分布式系统），是每个从业者都应该理解其困难性的，即使有些人并不理解。类似地，如果有人展示一个4 THz的处理器，其性能是4 GHz处理器的1000倍，这是任何从业者都应该认识到是他们绝对无法理解的外星技术。只有对该领域一无所知的外行才会合理地想，“它只是一个以1000倍时钟频率运行的处理器；一个能制造4 GHz处理器的工程师基本上会理解一个性能提升1000倍的4 THz处理器是如何工作的。”我们离通过将芯片运行速度提高1000倍来将性能扩展1000倍还差得很远，这样做将需要许多技术上的根本突破，并且很可能需要创造全新的领域，其工程知识量将超过当今世界所有工程领域的总和。同样，只有外行才会看着罗马工程和现代土木工程并认为“罗马人建造东西，我们建造的东西只是更大更多样；一个罗马工程师应该能够理解我们今天如何建造东西，因为东西只是更大了。”仅岩土工程就包含了比罗马时代所有工程领域总和更多的工程知识，而且它只是为使我们能够建造像今天这样的结构而必须发明的新领域之一。

当然，我并不指望随机程序员理解岩土工程，但我希望那些比较编程和土木工程的人至少对土木工程有一些了解，而不是仅仅假设该领域存在的知识量大致等于他们对该领域的了解，而他们对该领域基本一无所知。

尽管我似乎比大多数人更努力地避免陷入认为某事简单因为我看不懂它的陷阱，但我仍然经常陷入这个陷阱，我能想到的最好的防止方法，虽然聊胜于无，但并不可靠。

其中一部分是我试图培养注意到“对某事不甚了了却一掠而过”的感觉。我认为这类似于（甚至可能实际上就是）过去二十年变得流行的一种东西：关注情绪在你身体里的感觉，并通过注意身体里的感觉来理解你的情绪状态，例如，某种特定的紧绷感是我生气的一个确定信号。

当我以模糊、高层的视角看待某事，并在精神上一掠而过时，我的身体会产生一种特定的感觉。如果我不注意，我很容易错过它，我怀疑当我在一种连产生感觉的无意识大脑部分都不知道我在一掠而过的方式下忽略某事时，我也可能错过它。尽管注意到这种感觉本质上不可靠，但我认为，我可能做的其他所有独立检查我推理的事情都根本依赖于相同的机制（例如，如果我有一个清单，试图确定当我推理某个主题时是否没有一掠而过，这个过程的某些部分仍然依赖于感觉或直觉）。我确实尝试对错过这种感觉的案例进行事后分析，以弄清楚发生了什么，这基本上就是我发现我首先与这种错误相关联的感觉的方式（我思考过去是什么导致了这类错误，并注意到我通常与之相关联的一种感觉），但这永远不会完美，甚至非常出色。

另一个组成部分是做我认为是“检查输入我头脑的信息”的事情。当我在上高中时，我注意到相当大一部分“明显错误”的我说出的话，来自于让不正确的信息进入我的头脑。我过去没有，现在也没有一个好的、便宜的方法来标记信息的可靠性，因此我发现更容易在信息消费时就进行事实核查或丢弃信息。

另一件我尝试做的事情是获取反馈，这不可靠，并且在一般情况下也难以处理，因为获取反馈的速度远慢于思维速度，将一般思维速度降低到反馈速度会导致思想相对较少⁴。

虽然，不像某些领域，没有可以教授的、机械的、系统的步骤来解决这个问题，但我确实认为这是可以练习和提高的，并且在一些领域（通常是隐含地）教授了类似的技能。例如，在讨论高级或研究生水平教材的先决条件时，通常会看到书上说“自成体系。除数学成熟度外无先决条件”。这是一种简写，意思是“这本书不要求你具备任何高中生不会学到的特定数学知识，但你确实需要在解释和理解数学陈述方面克服几乎每个未受过训练的人都有的那种模糊思维。”拥有数学学位的人会在脑海中积累很多关于柯西-施瓦茨不等式和波尔查诺-魏尔斯特拉斯定理之类的显性知识，但能够理解这本书的重要知识不是显性知识，而是一般性的数学思维方式。

尽管在其他领域没有真正对应“数学成熟度”的术语，例如人们通常不把“系统设计成熟度”作为系统设计面试中寻找的东西，但类似的技能是存在的，即使它没有名字。同样，对于思考那些自己不是训练有素的专家的主题，比如一个非土木工程师思考为什么一个建设项目花费那么多时间那么多钱，存在一种一般性的思维成熟度⁵。

感谢 Reforge - Engineering Programs 和 Flatirons Development 通过在Major Sponsor级别赞助我，帮助使这篇文章得以发表。

另外，感谢Pam Wolf, Ben Kuhn, Yossi Kreinin, Fabian Giesen, Laurence Tratt, Danny Lynch, Justin Blank, A. Cody Schuffelen, Michael Camilleri, 和Anonymous的评论/更正讨论。

附录：相关讨论

一位匿名博客读者给出了他们自己与鸡尾酒会想法斗争的例子：

你最近的一篇帖子再次引起了我的共鸣，因为我最近了解到我对如何让东西变冷基本一无所知，尽管我从事低温物理学研究已经将近10年了。虽然我知道冷却的大致轮廓，以及稀释制冷机的大致工作原理，但我并没有体会到将东西保持在毫开尔文（mK）温度的巨大挑战。我是团队中唯一的物理学家，其他成员都是机械工程师。我们发现，在mK级别，基本上每一纳瓦的耗散都很重要，每一个表面与表面的接触、每一种材料选择等等也都很重要。

确实，我们可以说，mK温度下的热传输物理已经被很好地理解了，我们可以写出描述这些系统中热传递随温度变化的定律。它们通常写作P = aT^n。我们知道不同类型的传输具有不同的指数n，这些指数是已知的。当然，正如你可能预期的，拥有“热”量子比特与拥有稀释制冷机基础温度（30 mK）的量子比特之间的区别，完全在于预因子a在我们特定系统中恰好取什么值。这个参数通常可以猜测，通常在10倍以内，有时在2倍以内。但真的，为了确保我们能够保持量子比特冷却，我们需要测量那些预因子。诸如紧固件类型（4-40螺钉与M4螺栓）、紧固件数量、材料选择（金？铜？）以及几何形状等因素都对系统的实际性能起着巨大作用。哦，还有，当你将金属从其正常状态变为超导态时，n会发生剧烈变化。有趣！

我们花了一年多的时间仔细建模我们的低温系统，并在此过程中发现了拥有15-20年低温测量经验的人所持有的巨大误解。我们发现了材料选择和设计决策，如果进行了实际的热建模验证，这些决策会被认为是疯狂的。

有趣的是，如果我们想复制学术实验室的结果（这些结果大多倾向于更简单的实验设计），这基本上没问题，但当我们离开学术界，朝我们自己的目的设计时，这就行不通了。

附言：量子计算似乎也受到一种想法的影响，即控制100个量子比特（IBM已经达到127个）与1000个或1,000,000个没有太大不同。我过去认为这只是公关屁话，这些公司负责扩展的人完全意识到这将是多么疯狂地困难，但在我自己的经历和阅读你的帖子之后，我有点担心他们大多数人并不真正理解我们前方的巨大斗争。

这只是长篇大论地说明，我曾在我拥有博士学位并理应是专家的领域持有鸡尾酒会想法，所以你的帖子对我来说非常及时。我喜欢把你的写作作为跳板来思考如何变得更好，这一直非常困难。很难定义什么是好的物理学家或他们做什么，但我确信，更努力地去识别和应对我自己知识的局限性似乎是一件好事。

关于清晰思考的更广泛、更高层次的讨论，请参阅Julia Galef的《侦察兵心态》：

当你想到一个拥有出色判断力的人时，你会想到哪些特质？也许你会想到聪明、机智、勇气或耐心。这些都是令人钦佩的美德，但有一种特质应该列在首位，它如此被忽视，甚至没有一个官方名称。

所以我给它起了一个名字。我称之为侦察兵心态：将事物视为其本来面目，而非你希望其模样的动机。

侦察兵心态让你能够认识到自己何时犯错，寻找自己的盲点，测试自己的假设并改变方向。它促使你诚实自问，比如“那场争论是我的错吗？”或“这个风险值得吗？”或者“如果另一个政党做了同样的事，我会如何反应？”正如已故物理学家理查德·费曼曾经说过的，“第一原则是你不能欺骗自己——而你是最容易被欺骗的人。”

作为改进思维的工具，这本书有几章提供了具体的检查方法，这使得它比这篇文章更具可操作性（或至少更容易操作），这篇文章只是建议你弄清楚当你对某事一掠而过时是什么感觉。但我不认为书中的思想是本文的替代品，因为书中建议的自检方法并没有直接针对本文讨论的问题。

在其中一章中，Galef建议拥抱困惑（例如，如果一些看似矛盾的信息引发了困惑感），我同意这一点。我要补充的是，还有很多其他感觉值得观察，这些感觉并没有很好的名字。当评估想法时，除了已经提到的“我正在忽略重要细节的感觉”，我试图注意的一些感觉还有“某种方法如果追求很可能会有回报的感觉”、“某种方法确实充满风险/危险的感觉”、“存在关键缺失信息的感觉”、“有些地方确实不对的感觉”，以及类似的没有好名字的感觉。

关于电影《不要抬头》如何宣扬世界很简单、我们可以轻松找到鸡尾酒会解决方案来解决问题的观点，请参阅Scott Alexander的这篇帖子。

另外，John Salvatier指出现实有着惊人数量的细节。

由 mimo-v2.5 模型翻译，花费 19551 tokens

本文节选自我与David Mackey于2019年4月合著的一份内部文档。节选原因是原文大部分内容涉及在Twitter提高效率的不同方案对比，这些信息若无大量额外解释/背景，对Twitter外部读者意义有限。

在Twitter，大多数CPU密集型服务在容器CPU利用率约50%时开始出现性能下降，而几乎所有服务即使理论应能获得更高利用率，实际上也仅在略高于50%时即开始崩溃。由于负载通常无法在分片间均匀分布，且超过50% CPU利用率时分片级性能衰减严重，这使得实际负载上限远低于50%的理论值，即使在负载高峰期也是如此。

本文将描述解决此问题的潜在方案。首先将说明为何根据服务配置方式和所用Linux调度器的特性，此问题本就该出现。随后将通过具体案例研究，展示如何通过配置调整使特定服务容量提升1.5至2倍，这相当于为大型服务每年节省数十万至数百万美元。虽然针对大型服务进行手动优化值得实施（可带来数十万至数百万美元的总拥有成本节约），但逐个手动调整服务并不具备可扩展性。因此，我们还将探讨如何为大多数服务实施可大规模推广的改进措施。

理论层面的问题

Twitter几乎所有服务均运行在采用CFS调度器的Linux系统上，使用CFS带宽控制配额进行资源隔离，并采用默认参数。其设计初衷是允许不同服务在同一物理机上共存，避免某个服务的CPU过度使用影响其他服务，同时防止空闲物理机上的服务占用全部CPU资源。此前服务所有者在启用配额前，因性能不可预测而难以评估服务表现。配额机制限制每个容器的平均CPU使用量，但不限制作业在任意时刻可使用的CPU核心数。相反，如果作业在配额时间片内“试图”使用超过配额核心数，它会暂时使用超过配额的核心数，随后被限流（即基本进入休眠状态），以确保其平均核心使用量保持在配额以下。这对尾部延迟¹是灾难性的。

由于Twitter绝大多数服务使用的线程池规模远大于其Mesos核心预留量，当作业负载较重时，它们最终会请求并使用超过预留量的核心数，进而触发限流。这导致那些基于负载测试数据或负载下观测到的延迟来配置资源的服务，不得不超额配置CPU以避免违反其SLO。它们要么每个分片请求多于实际所需的CPU，要么必须增加分片数量。

此问题的一个旧例是JVM垃圾回收器。在JVM实现容器感知之前，每个JVM默认将GC并行线程池大小设置为物理机核心数。GC期间，所有这些GC线程同时运行，迅速耗尽CPU配额导致限流。其结果是，原本亚秒级的STW（Stop-The-World）GC暂停可能耗费数秒实际时间才能完成。虽然GC问题已修复，但此问题在几乎所有运行在Mesos上的服务应用层仍然存在。

实际案例研究

以service-1（Twitter规模最大、成本最高的服务）为例进行研究。

下图显示该服务在负载测试刚开始失败时的CPU利用率直方图——即刚超过服务在违反SLO前可处理的峰值负载时。X轴为特定时刻使用的CPU核心数，Y轴为在该利用率下花费的（相对）时间。该服务配置为20个核心，可见即使在接近峰值负载运行时，其利用率大多远低于此配置值：

问题在于超过20的那些小条形。这些尖峰导致作业耗尽CPU配额后被限流，引起延迟急剧增加，这就是即使平均利用率约8核心（占配额40%），SLO仍被违反的原因。需注意的是，该图的采样周期为10ms，配额周期为100ms，因此技术上可能在不触发限流的情况下观测到超过20的突变，但平均而言，若频繁出现突变（尤其远超20），很可能导致限流。

通过缩减线程池规模以避免使用过多核心并触发限流后，在负载测试中得到如下CPU利用率直方图：

此时负载（请求速率）为前一张直方图的1.6倍。由于该服务能处理如此高的负载直至故障，导致为其提供请求的负载测试工具无法注入更多负载（虽然这可以修复，但我当时无权快速修复）。[后续测试显示，调整线程池规模后服务容量约提升2倍]。

此案例并非孤例——Andy Wilcox对service-2进行了相同分析，在类似原因下发现了相似的性能提升。

对于关注延迟的服务，若优先追求延迟优化而非成本降低，可获得显著改善。以service-1为例，若保持配置容量不变而非削减2倍，延迟可降低20%。

针对个别大型服务进行此类调整的收益显著（以service-1为例，该服务本身每年可节约[七位数中段金额]，包含其克隆服务则达[八位数低段金额]），但手动调整每个服务并不具备可扩展性。这就引出一个问题：有多少服务受影响？

集群整体线程使用情况

若观察中等规模服务（≥100分片）的活跃线程数与预留核心数之比，会发现几乎所有服务都有远多于预留核心数的可执行线程。每个预留核心对应数十个可运行线程并不罕见。相比之下，service-1在负载下每个预留核心对应1.5至2个可运行线程的情况已相对温和。

观察这些线程来源，常见情况是程序包含多个线程池，每个线程池大小被设为预留核心数的2倍或物理机逻辑核心数的2倍。在Twitter内外，常见建议是将线程池大小设为物理机逻辑核心数的2倍。该建议可能源于类似gcc编译的工作负载——我们不希望在可执行任务时出现空闲资源。由于线程有时会阻塞导致空闲，采用2倍规模可通过降低任何核心完全空闲的概率来提升吞吐量，且2是一个整数。

然而，将此应用于Twitter应用存在几个问题：

1. 大多数应用存在多个相互竞争的线程池
2. 超过预留核心数限制会导致严重后果
3. 执行计算的额外线程可能增加延迟

“应配置2倍逻辑核心数”模型假设我们仅有一个执行所有工作的主线程池，空闲线程无负面影响，且工作负载面向吞吐量而不关心特定任务的截止时间。

采用CFS调度器时，超过核心预留量的活跃工作线程不会空闲，它们会被调度运行，但这将导致限流，进而损害尾部延迟。

潜在解决方案

鉴于我们在许多服务上观察到与案例研究相似的情况，且难以将性能修复推送到大量服务（因为服务所有者缺乏实施动力），我们应如何解决整个集群（而非仅少数选定大型服务）的此问题？下文将列出潜在方案并逐一详细讨论。

• 优化跨集群线程池（eventbus、netty等）的默认配置
• 通过共享库协商线程池大小
• CFS周期调优
• CFS带宽片调优
• 其他调度器调优
• CPU绑核与隔离
• 在Mesos调度器层面进行超额配置

优化跨集群线程池的默认配置

潜在影响：效率小幅提升
优势：相比任何全面解决方案工作量少得多，可与其他方案并行实施，即使其他方案已实施也能带来一定收益（减少锁竞争和上下文切换）。
劣势：无法解决大部分问题。

许多默认配置过大。Netty默认线程池大小为预留核心数的2倍。在[某组织]某些部分，他们使用的库会启动eventbus并分配大小为物理机逻辑核心数2倍的线程池（产生[超过100个]eventbus线程），而大多数eventbus用例仅需1-2个线程。

调整这些默认大小虽无法彻底解决问题，但能减轻其影响，且比下文方案工作量小得多，因此可在我们致力于更全面解决方案的同时实施。

通过共享库（API）协商线程池大小

[本节由Vladimir Kostyukov撰写]

潜在影响：可为大多数服务基本缓解问题。
优势：设计与实现相当直观；有可能在Finagle/Finatra中成为一等公民。
劣势：需要服务所有者明确采用（采用新API构建线程池）。

CSL的util库中有一个桥接应用与JVM集成点的包（util-jvm），这可能是承载协商应用所需线程池大小新API的良好载体。

此类API的形态实际上取决于协商所需的粒度。仅竞争分配给每个进程的总线程数虽易于实现，但无法区分应用线程与IO线程。而引入线程QoS概念（即“IO线程；不可阻塞”、“应用线程；可阻塞”）则可能使协商更精细。

CFS周期调优

潜在影响：通过缩短进程组CFS运行时配额刷新前的时间周期，小幅降低尾部延迟。
优势：相对直接的修改，只需最少改动。
劣势：增加调度器开销成本可能抵消收益，且未解决并行耗尽配额的根本问题。可能导致总限流量增加。

为限制CPU使用，CFS在称为CFS周期的时间窗口上运行。调度组中的进程从分配给cgroup的CFS配额中获取时间，该配额在CFS周期内通过CFS带宽片消耗。通过缩短CFS周期，配额耗尽导致限流与进程组能再次运行之间的最坏情况时间按比例减少。以默认值（CFS带宽片5ms、CFS周期100ms）为例，最坏情况下，高度并行的应用可能在第一个带宽片耗尽全部配额，导致95ms的限流时间，期间无线程可被调度。

总限流量可能增加，因为即使存在5ms的突增超过阈值，100ms内的调度时间可能未超阈值。

CFS带宽片调优

潜在影响：通过允许应用更好地利用分配的配额，小幅降低尾部延迟。
优势：相对直接的修改，仅需最少代码改动。
劣势：增加调度器开销成本可能抵消收益，且未解决并行耗尽配额的根本问题。

当CFS调度进程时，它会在全局池与CPU本地池之间转移运行时间以减少大型系统的全局记账压力。每次转移的量称为“片”。从调度器角度，较大的带宽片更高效，但较小的带宽片允许更细粒度的执行。在调试[内部JIRA链接]问题时确定，若被调度进程未能消耗其整个带宽片（默认5ms），因完成执行或阻塞于其他进程，该时间将对进程组丢失，降低其消耗所有请求资源的能力。

调优此值的预期开销最小，但应测量。此外，这可能并非普适调优项，但Mesos曾拒绝将其暴露为用户可调参数。确定调优此值的启发式方法并提供按应用设置的途径可能难以实现。

其他调度器调优

潜在影响：小幅降低尾部延迟并减少限流。
优势：相对直接的修改，仅需最少代码改动。
劣势：可能增加调度器开销成本抵消收益，且未解决并行耗尽配额的根本问题。

内核具有众多自动缩放和自动分组功能，其对调度性能和限流的影响目前未知。kernel.sched_tunable_scaling可在我们理解其值的情况下调整kernel.sched_latency_ns。kernel.sched_min_granularity_ns和kernel.sched_wakeup_granularity_ns可调优以允许更早抢占，改善资源共享并最小化延迟。kernel.sched_autogroup_enabled当前可能未遵循kernel.sched_latency_ns，导致更多限流挑战和调度低效。这些可调参数尚未深入研究，调优影响未知。

CFS调度器改进

潜在影响：提升整体CPU资源利用率并最小化因CFS低效导致的限流。
优势：改进对用户空间透明。
劣势：CFS调度器复杂，修改存在较大风险，且上游对某些类型修改的接受度可能具挑战性。

CFS调度器处理CFS带宽片中未用空闲时间的方式已被证明效率低下。内核团队有补丁确保这些未用时间返回全局池供其他进程使用，https://lore.kernel.org/patchwork/patch/907450/，以确保更好的整体系统资源利用。还有其他探索途径可提供进一步增强。此领域众多近期讨论之一源于k8s限流问题（https://github.com/kubernetes/kubernetes/issues/67577）：https://lkml.org/lkml/2019/3/18/706。

此外，CFS可能因错误而效率降低，如[内部JIRA链接]和http://www.ece.ubc.ca/~sasha/papers/eurosys16-final29.pdf。但我们尚未花费大量时间研究CFS在Twitter特定用例中的性能。更深入的考察可能发现提升效率的方法。

另一个具有更大潜力与风险的改变是使用CFS以外的调度器。

CPU绑核与隔离

潜在影响：通过使应用开发者心理模型中的CPU映射到物理CPU，从系统中消除限流概念。
优势：从应用开发者视角简化理解，调度器施加的限流不再是应用需应对的概念，提升缓存效率，显著减少资源干扰带来更确定的性能。
劣势：运维复杂性更高，超额订阅更复杂，需对当前运行环境进行重大变更。

允许限流发生的根本问题是，高度线程化的应用可拥有超过其“请求CPU数”的并行执行线程，导致可用运行时提前耗尽。通过将同时执行的线程数限制为应用请求的CPU数，现存在1:1映射，应用进程组可不受调度器干扰地自由使用逻辑CPU线程。此外，通过为应用分配CPU线程而非带宽片，应用现可充分利用CPU缓存优势，无需在被限流或上下文切换移出时与其他应用竞争同一CPU线程。

在Mesos中，实现CPU绑核已被证明相当困难。然而，k8s已有Intel名为k8s CPU Manager的项目带来希望。CPU Manager作为alpha功能在k8s 1.8中添加，自1.10起作为beta功能启用。它在beta阶段有些停滞，因似乎少有人使用，但核心功能已存在。CPU Manager项目推广的性能改进显著，如示例https://kubernetes.io/blog/2018/07/24/feature-highlight-cpu-manager/和https://builders.intel.com/docs/networkbuilders/cpu-pin-and-isolation-in-kubernetes-app-note.pdf所示。尽管这些基准测试应谨慎看待，但确实为探索此途径提供了有希望的前景。对该项目的粗略检查突出了一些需要工作的领域，但其已处于可用于验证方法的可用状态。底层，k8s CPU Manager利用内核中的cpuset cgroup功能。

潜在地，此方法确实降低了机器超额订阅的能力。然而，最小化跨Pod干扰、CPU限流、更确定执行轮廓等方面的效率增益可能抵消超额订阅的需求。当前，k8s CPU Manager确实允许少量超额订阅（允许系统级容器和daemonset超额订阅），但在Pod调度层面，CPU被保留供该Pod使用。

Brian Martin等人的实验显示CPU绑核带来显著性能收益，几乎与我们的超额订阅系数相当。

长期来看，超额订阅可通过多层方法实现：主要Pod类使用CPU绑核调度，而对延迟不敏感的次要Pod类允许在所有核心上浮动，消耗主要Pod的空闲资源。CPU Manager方面的工作将是广泛的。然而，最近Facebook在内核调度器方面的工作以最小化影响主要Pod类的方式进一步实现了此概念，我们可以扩展或发展。

集群调度器层面的超额订阅

潜在影响：可将机器利用率提升至任意高水平，并充分超额配置。
优势：集群调度器层面的超额订阅与本文描述的问题无关；以数据驱动方式执行可在无需尝试解决此处所述特定问题的情况下提升机器利用率。这可能同时解决本文问题（因避免限流而过度配置导致的低CPU利用率）和[另一问题描述文档]中的问题。
劣势：我们在[内部文档链接]中看到，运行在高负载主机上的服务分片性能下降。除非我们将Mesos调度器改为基于实际利用率（而非预留量）调度，否则某些主机会负载过高，分片落在这些主机上的服务性能将较差。

禁用CFS配额

潜在影响：防止限流，允许服务通过依赖“份额”机制而非配额使用物理机上所有可用核心。
优势：在某种意义上可实现最高可能利用率。
劣势：行为异常的服务可能严重干扰同一物理机上运行的其他服务。此外，服务所有者将更难预测其自身服务性能，因为空闲与负载状态间的性能变异性会大得多。

此方案是我们启用配额前所用的方案。从朴素硬件利用率角度，依赖份额机制似乎最优，因为这意味着若物理机未充分利用，服务可占用空闲核心；但若物理机高度利用，服务将回退至按核心预留量比例占用核心。然而，当我们使用此系统时，大多数服务所有者发现预测负载下性能过于困难，因而不可行。至少一家公司尝试此方案解决其限流问题，在负载下发生了严重事故。若我们现在切换回此方案，不会比启用配额前更好。

鉴于我们的容量分配方式，若要使此方案比之前更有效，需包含两个要素：对单个分片请求率的更精细控制，以及允许服务所有者理解负载激增期间真实情况的负载测试环境（与我们仅允许向单个分片注入不切实际负载的系统不同，这存在请求混合与真实负载激增期间不同、且注入负载的分片未看到同一物理机上其他服务升高负载的问题）。根据[另一内部文档]，我们知道影响分片级性能的最大因素之一是物理机的总体负载，且其对延迟的影响是非线性且难以预测，因此确实没有好方法从当今负载测试框架下的测试负载预测实际负载下的性能。

虽然这些缺失要素是重要且高影响力的问题，但解决任一要素均超出本文范围；[X团队]负责负载测试并正在改进，待问题解决后可能值得重新审视此方案。

一个中间方案是将调度器配额设置为大于Mesos预留核心数的值，这将限制“过多”CPU导致不可预测性能的影响，同时可能在高负载下减少限流（因为调度器将有效回退至份额机制）。例如，若cgroup配额为Mesos配额的两倍，在保留Mesos CPU使用量50%时崩溃的服务将改为在100%时崩溃。对于高负载物理机，更高的总体利用率将减少限流，因为来自其他核心的增加负载意味着拥有过多可运行线程的服务无法让其如此多线程执行。这具有禁用配额缺点的弱化版本——根据[内部文档]，来自其他服务的物理机负载是分片级性能差异的最大因素之一，若我们不改变物理机上Mesos核心预留量，这将增加物理机负载。若我们按比例减少物理机Mesos预留核心数，则此变更失去意义，相当于简单地将每个服务的CPU配置加倍（只是“秘密”加倍可能减少人们问“为何在负载测试中超过X% CPU时服务崩溃？”的人数）。

成果

本节未包含在2019年4月的原始文档中；写于2021年12月，描述因原始文档产生的工作。

更改默认线程池大小的建议被采纳并带来轻微改进。更重要的是，本文催生了两个主要项目。Vladimir Kostyukov（来自CSL团队）和Flavio Brasil（来自JVM团队）创建了Finagle Offload Filter，Xi Yang（当时我的实习生²，现为我团队全职员工）创建了消除容器限流的内核补丁（补丁仍为内部，但希望最终能上游化）。

几乎所有在Mesos上运行的应用都基于Finagle。Finagle Offload Filter使服务所有者能轻松将应用工作负载置于与IO不同的线程池（此前常未实现）。结合恰当调整线程池规模，在其他条件不变的情况下，应用延迟大幅降低，使其能削减配置容量并降低成本，同时满足SLO。根据服务不同，这带来15%至60%的成本节约。

内核补丁实现了显而易见的思路：防止容器在任意时刻使用超过容器配额的核心数，而非允许容器使用物理机上所有可用核心，然后在容器使用过多核心以将其平均核心使用量降低时将其置入休眠。

在运行Twitter主要服务的主机上实验显示，其产生了消除限流相关问题的预期影响，对未调优线程池规模的典型服务带来约50%的成本节约。事实证明，其净影响比我们撰写本文时认知的更大，因为防止服务使用“过多”核心后限流减少了干扰³。此外，虽然当时已意识到，但未在文档中注明限流问题使分片从“基本完全正常”进入“限流死亡螺旋”（类似于“GC死亡螺旋”），仅需少量额外负载即会触发，增加了可靠运行系统的难度。情况是，当服务处于高负载时会发生限流。限流不会阻止请求进入被限流的分片，因此当分片从限流中苏醒时，其待处理工作量比限流前更多，导致其使用更多CPU并更快触发限流，造成更多工作堆积。Finagle有可为状态极差的分片卸载负载的机制（与故障服务器通信的客户端将标记服务器为故障并停止发送请求一段时间），但分片往往在服务总体负载高时进入此状态，因此标记节点为故障仅意味着更多负载流向其他分片，后者将“想要”进入限流死亡螺旋。在限流可能导致死亡螺旋的环境下运行是本质上亚稳态的。消除这两个问题的影响可说与消除限流带来的成本节约一样大。

Xi Yang已试验上述朴素内核调度器变更的多种变体，但即使是朴素变更，与不变更相比也似乎相当有效，尽管朴素变更确实意味着服务在请求时通常无法获得全部CPU分配。例如，若服务在前半周期不请求CPU而后半周期请求无限CPU，在旧系统下将获得其周期分配CPU量，但在新系统下仅能获得一半。Xi的部分变体补丁以某种方式解决了此问题，但与防止限流本身相比影响相对较小。

Pratik Tandel推动的独立变更通过减少分片间差异影响来减轻限流对服务的影响，该变更是转向更少更大的分片。此变更的主要目标是减少跨所有分片发生的重复工作/内存开销，但它碰巧因更大的分片配额减少了随机噪声影响。总体而言，这带来Twitter大型服务0%至20%的CPU使用减少和10%至40%的内存使用减少（具体取决于服务）。

附录：其他容器限流相关工作

• https://engineering.indeedblog.com/blog/2019/12/cpu-throttling-regression-fix/
• 增加突发性
  • https://lore.kernel.org/lkml/20180522062017.5193-1-xiyou.wangcong@gmail.com/
  • https://lkml.org/lkml/2019/11/26/196
  • https://lwn.net/Articles/840595/
  • 超出分配的容器仍将限流，但增加了“突发容量”概念，在保持基本相同平均核心利用率的同时，允许限流前有更大余量
    • 允许突发性独立于我们的修复（防止限流），原则上两者可同时应用，有点像启用htb qdisc的网络隔离工作方式
    • 鉴于Twitter的工作负载和配置，这并未解决我们关于实现极高每容器CPU利用率或防止限流死亡螺旋威胁所致亚稳态的限流问题，尽管它确实允许我们比不启用突发性时使用略高的平均CPU
• 运行时层面并行限制
  • 由于Go通常使用单线程池，Uber通过https://github.com/uber-go/automaxprocs限制最大运行goroutine数绕过了此问题
    • 对Twitter不幸的是，包括service-1在内的多个最大最昂贵服务使用多种语言运行时，因此没有简单方法在运行时层面限制并行性
  • .NET运行时拥有自适应线程池大小已十年，这是.NET技术栈比我们常见时尚科技公司更先进的众多方式之一

感谢Xi Yang、Ilya Pronin、Ian Downes、Rebecca Isaacs、Brian Martin、Vladimir Kotsyukov、Moses Nakamura、Flavio Brasil、Laurence Tratt、Akshay Shah、Julian Squires、Michael Greenberg @synrotek和Miguel Angel Corral的评论/修正/讨论

由 mimo-v2.5 模型翻译，花费 16502 tokens

我见过许多标榜为写作建议的文章，实际上只是作者对自己写作方式的含蓄描述，其核心无非是“你应该像我这样写”。例如，写短文的人会建议你写短文。与技术话题一样，我认为许多不同的方法都可能有效，真正重要的是找到一种适合你自身及所处环境的风格。照搬他人成功的方法不太可能对你有效，因此“照我这样写”是一种糟糕的建议。

我们将首先审视那些对他人奏效的写作方法中存在多少多样性¹，接着探讨模仿他人风格为何如此困难，最后讨论我自己在写作中尝试的方法。

如果我查看从2000年到2017年在我社交圈中阅读量最高的编程博客²³，它们是Joel Spolsky、Paul Graham、Steve Yegge和Julia Evans（如果你不熟悉这些作者，请参阅附录中我认为能代表他们风格的摘录）。这份清单上的每个人在以下方面（以及其他方面）都有不同的风格：

• 主题选择
• 行文风格
• 文章长度
• 幽默类型（如果有的话）
• 技术细节水平
• 支撑证据的多少
• 细致程度

以一个易于量化的简单维度——长度为例。Julia Evans和我都在2013年开始写博客（她在2012年有一篇帖子，但她告诉我，她认为自己的博客是在2013年9月在RC时才真正开始，那也是我开始写博客的月份）。多年来，我们多次交流过，直到2017年底我暂停写博客，我们的博客总字数相近，尽管她发布的文章数量比我多大约一个数量级。

再看几个难以量化的方面，考虑一下Paul Graham这段典型的风格片段：

书呆子喜欢的是那种人们走来走去面带微笑的城镇。这排除了洛杉矶（那里根本没人走路）和纽约（人们走路，但不微笑）。我在波士顿读研究生时，一位朋友从纽约来访。从机场回来的地铁上，她问道：“为什么每个人都在微笑？”我看了看，他们其实没在微笑。只是与她习惯的面部表情相比，他们看起来像是在微笑。

如果你在纽约生活过，你就知道这些面部表情从何而来。这是一个你的头脑可能很兴奋，但你的身体知道它正在经历糟糕时光的地方。人们与其说是享受生活在那里，不如说是为了那份兴奋而忍受它。如果你喜欢某些类型的兴奋，纽约是无与伦比的。它是一个魅力中心，是所有半衰期较短的时尚和名望同位素的磁石。

书呆子不在乎魅力，所以对他们来说，纽约的吸引力是个谜。

它运用了有时被称为古典风格的多个方面。在这篇文章中，当我说“古典风格”时，我指的是Thomas & Turner所使用的术语，而非日常含义。其内涵实在过长，不适合在这篇文章中详细描述，但我可以说其中一部分是行文干净、直白且简单；一位以“删除多余词语”为信条的编辑不会有太多修改意见。另一部分是，这种风格的简洁性超越了文字本身，延伸到呈现的信息，以至于几乎不呈现支撑证据。Thomas & Turner说：“真理无需争辩，只需准确呈现。”Rochefoucauld的这段话既体现了这两点：

德·谢弗勒兹夫人智慧闪耀，野心勃勃，美貌十足；她轻佻、活泼、大胆、进取；她动用一切魅力来推动她的计划走向成功，她几乎总是给那些在路上遇到她的人带来灾难。

Thomas & Turner对Rochefoucauld这段话的评论是：

这段文字展示了一种与作者获知过程无关的真理顺序。作者摆出全知的姿态。这种姿态暗示作者拥有广阔而丰富的经验；否则他无法做出这样的观察。但这些个人历史、个人经历或个人心理并未进入表达。相反，这句话将作者的经验结晶成一种超越时间且绝对的序列，就像几何证明一样。

这很大程度上也适用于Paul Graham的那段话（尽管不完全适用，因为他讲述了一个朋友从纽约来访波士顿的轶事，并明确说“如果你在纽约生活过”你会知道什么，而不是直接陈述你会知道什么）。

我的风格在很多方面都与之相反。我经常写长句，思路迂回，不是出于任何特定的文学目的，而仅仅因为它反映了我思考的方式。Strunk & White要是看到我的写作，恐怕会有很多意见。在可能的情况下，我尽量构建有条理的论证，并尽可能提供证据，同时对证据不适用的情况加以说明。虽然不呈现证据能让文章读起来更干净，但那不是我的选择，因为我不喜欢读者基本上只能全盘接受或拒绝那些赤裸裸的断言，例如“书呆子喜欢的是那种人们走来走去面带微笑的城镇”，我更希望读者知道我为什么这么想，这样他们可以根据根本原因来同意或反对。

在长度、风格和其他提到的维度上，并没有正确与错误之分。许多不同的方法都能取得不错的效果。不过，如果目标是受欢迎，那么相比于Julia，我可能在长度上做出了次优选择；相比于Paul，我在文风上也可能做出了次优选择。如果我看什么能让别人获得关注，什么能让我的RSS流量增加，让更多人关注我的Twitter等，我发现频繁发布短文似乎比不频繁发布长文更有效。

我对文风对受欢迎程度的影响不那么确定，但我的感觉是，出于同样的原因，在工作中说很多自信的话（能让人晋升），写自信、不带保留的文章也能奏效（能吸引读者）。人们喜欢自信。

但是，在这两种情况下，即使做出次优选择，人们仍然可以非常受欢迎。对我而言，优化其他目标比优化受欢迎程度更重要。在长度上，我经常讨论那些无法轻易甚至根本无法用简短篇幅涵盖的话题。一个例子是我关于分支预测的文章，它有两个目标：为没有分支预测甚至计算机体系结构背景的程序员提供历史概述，并教会他们足够多的知识，以便能够阅读和理解现代最先进的关于分支预测的论文。这篇文章长达5800字。我看不出如何用人们推荐的博客文章长度（500字、1000字、1500字等）来达到同样的目标。文章或许可以稍微删减一些，但每个讨论到的预测器，除了agree预测器外，要么是解释后续预测器所必需的构建块，要么具有历史重要性。但即使不讨论agree预测器，讨论至少一种减少干扰的方案也很重要，因为干扰发生的原因以及如何减少它是分支预测中的一个基本概念。

这篇文章也可以有其他版本。一个解释分支预测存在的版本可能1000字就能写好。那篇文章如果写得好，会有更广泛的受众，更受欢迎，但那不是我想写的。

我对风格有类似的看法，因为我经常想以某种程度的细节和精确度来讨论事情，而这使得无法用干净的古典风格来写作。一个具体的小例子是，在最近一篇文章中，一位审阅读者要求我删除双重否定，但我拒绝了，因为在那种情况下，双重否定与可能替换它的肯定陈述有着不同的内涵，我想传达一些精确的东西，而这与简化句子后传达的内容不同。

一个更普遍的问题是，Paul从高层面讨论许多“大创意”。这适合用干净、简单的风格（Paul称之为优雅风格）来写作。但我对脱离低层次细节的“大创意”不感兴趣，而要有效地讨论低层次细节，很难不用Paul所说的不够优雅的风格来写。

一个具体的例子是我关于命令行工具和UNIX哲学的讨论。我们应该有“只做一件事并做好”、“编写程序来处理文本流，因为这是一个通用接口”的工具，还是使用有很多选项、能处理结构化数据的命令？几十年来，人们一直在来回重复同样的高层次反驳。但一旦我们看细节，看这些想法暴露在现实世界中会发生什么，我们立刻就能看出其中一套想法根本不可能像宣称的那样奏效。

回到写作风格，如果你试图弄清楚哪些风格选择适合你，你应该从你的目标和你的长处出发，而不是听那些告诉你像他们那样写的人。即使有人能描述出他们写作为什么奏效，那也不太可能对你有效，而且大多数建议都是由那些不理解自己写作为何奏效的人写的。如果你没有花很多时间分析写作，这可能很难看清，但如果你上过许多舞蹈课或接受过非优秀教练的体育指导，就很容易看出这是真的。例如，观察普通舞蹈教练并倾听他们的指导，你会发现他们的指导与他们实际做的大相径庭。那些倾听并遵循指令而不是尝试模仿教练动作的人，最终会把事情做得完全错误。大多数写作建议同样未能捕捉到重要之处。

不幸的是，模仿他人的风格也非易事；大多数人完全模仿错了东西。例如，Natalie Wynn指出，模仿她风格的人常常模仿表面的东西，却不理解是什么驱动了这些表面特征：

我注意到一件事，就是当人们没有表达任何东西的时候。比如有人试图做一个“左管视频论文”，他们往屏幕上堆满了奢华的东西，因为Contrapoints，但这与主题无关。这指的是什么？你在说什么？？

我做了一个关于羞耻的视频，造型是伊甸园中的夏娃，因为夏娃是第一个体验到羞耻的人。所以视觉效果与概念相关，并因此希望能引起更多共鸣。所以我想这就是我的建议，试着说些什么。

如果你探究那些在其领域出类拔萃的人说了什么，你经常会在其他领域看到类似的评论。例如，在实用射击中，Rob Leatham说：

我在课堂上忙于帮助学生学习如何思考。他们会说，“Rob像这样握枪…”，他们不知道我像这样握枪的原因不是为了让自己看起来那样。最终结果不是那样握枪；那样握枪是做其他事情的结果。

Brian Enos说：

当我开始…射击时，我对技术只有基本的概念。所以我做了我认为合乎逻辑的事情。我找到了当地最好的射手（他也在全国比赛中具有竞争力），问他我应该如何射击。他毫不犹豫地告诉我：左手食指放在扳机护圈上，左手肘弯曲向后拉，经典拳击姿势，等等，等等。我盲目地采用这套系统一两年，然后才想是否有一套更适合我的结构和态度、也更适合射击的系统。这最初采用的风格似乎不适合我，因为我感觉好像在努力控制枪支；我从未真正像现在感觉那样与枪支融为一体。我的实验促使我从所有类型的射击风格中汲取灵感：等腰三角姿势、改良的韦伯式、靶心射击，以及像Bill Blankenship、霰弹枪手John Satterwhite和武术家李小龙这样的人。

但来自你环境的想法只能引导你朝正确方向前进。这些想法本身就会限制你的思考……伟大的想法会产生于你内心的感受。这种直觉意识会让你接受任何对你有用的东西，抛弃任何没用的东西。

我引用这些例子是因为它们被写进了一本书，但我从各种活动的教练那里听过基本上相同的评论，例如我与之交谈过的舞蹈教练抱怨人们会问在某个动作中左脚应该交叉在右脚前面还是后面，这就忽略了重点，因为重要的是脚步放置在考虑到人的重心移动的情况下是合理的，这可能意味着根据具体情况，脚应该交叉在前面或后面。

更普遍的问题在于，不理解他们试图模仿的东西的人，最终会模仿他人行为中不重要的表面方面，而忽略了驱动这些表面方面的根本原因。即使有非常详细的说明，也会发生这种情况。虽然观察他人所做可以加速学习，特别是对于毫无头绪的初学者，但没有捷径可以达到足够深入的理解以促进做好一件事，这种理解无法用简单的规则（如“删除多余词语”）来概括⁴。

因此，我认为风格应源于你的目标，而目标最终是个人偏好。就我个人而言，我有时会有以下目标：

• 以几乎任何专业程序员都能理解的方式解释许多人似乎不理解的技术主题
  • 例如：分支预测、malloc、缓存分区
• 为少数派观点（或当时是少数派的观点）辩护：
  • 例如：文件难以使用、公共科技公司可以支付很高薪酬、单体仓库并不愚蠢
• 进行测量
• 讨论我认为有趣的现象：
  • 例如：有趣的间断点、知识转移的难度、偏差常态化

当你将其中一个目标与详细讨论事情的偏好相结合时，你会得到一种与上面提到的任何作者都不同的风格，即使你想像Steve Yegge那样有效地使用幽默，像Julia Evans那样为更广泛的读者写作，或者像Paul Graham那样写得权威。

当我想起自己写作的主要组成部分时，我认为除了风格和目标之外，驱动我写作的主要因素是过程。与风格一样，我认为这是一个多种方法都可行的领域，需要你自己找出什么适合你。

就我而言，在开始写博客时，我有以下过程目标：

• 低前期投入，尽可能减少摩擦，如果我继续写博客，可能会随时间增加投入
• 通过每篇文章提高写作技巧/能力，而不必过于担心任何单篇文章的写作质量
• 只在我觉得值得发布时才发布
• 写一个我自己会想订阅的博客
• 在自己的平台上写作

低前期投入目标的原因是，当我审视我看过的博客时，最常见的博客格式之一是包含一篇解释该人开始写博客的文章，可能还有另一篇解释其博客设置的文章，但没有后续文章。另一种常见的博客格式是博客有一段时间定期发帖，然后是一段很长的休眠期，最后有一篇文章解释他们将重新开始发帖，然后就没有更多文章了（有些情况下，会有几篇这样的文章，间隔时间越来越长）。鉴于人们在开始写博客后继续写下去的比例很低，我认为我不应该费心投资博客基础设施，直到我知道我会写一段时间，所以尽管我已经拥有这个域名，但我没有费心去弄清楚如何将这个域名指向GitHub Pages，只是安装了一些流行博客软件的默认版本，甚至在我已经写了一篇文章之后才这样做。回顾过去，使用Octopress（Jekyll）是一个大错误；我选择它是因为当时我和一群做潮流东西的人混在一起，但事实证明它安装起来非常烦人，以至于人们组织了小型的“Octopress安装日”，这是一个坏兆头。结果发现，它不仅安装麻烦，还有相当多的故障，使用了一种无法获取上游更新的开发模型，而且速度极快地变慢了（没过多久，构建我的博客就需要整整一分钟，编译少量博客文章花费这么长时间太荒谬了）。我本应该只写纯HTML，直到有几篇文章，然后将其转换为自定义静态站点生成器，或者使用WordPress，它可以在几分钟内启动，并且可以轻松迁移。但是，低前期投入的一部分就包括不对此进行研究，并相信我周围的人做出了合理的决定⁵。总的来说，我支持保持低启动成本的想法，但如果我当时忽略了所有标准建议，要么做一些极简的东西，要么使用不流行但直接的选项，我本可以为自己节省很多工作。

“提高写作”这个目标是因为我发现我的写作尴尬得令人恼火，并想修正这一点。我经常写出在我看来笨拙的句子或段落，就像你拼错一个单词，无论你怎么重新拼写，它看起来都不对。拼写检查器现在已相当普及，你不再真正遇到拼写问题，但我们还没有能提高你写作水平的自动化工具（有些尝试，但它们往往会制造糟糕的写作）。我不担心任何特定的文章，因为我认为我可能需要花数年时间来改进我的写作，而且我不认为花数年时间重新编辑一篇文章会很令人满意。

正如我们之前讨论过的，获得反馈可以大大加快技能获取速度，所以我聘请了一位我尊重其写作的专业编辑，并附上说明：“我的写作笨拙而尴尬，我想修正它。我不太关心拼写和语法问题。你能据此编辑我的写作吗？”我收到了关于我许多文章的详细反馈。我试图解决反馈中提出的问题，但更重要的是，努力在我的下一篇文章中避免出现相同或之前提到的问题。我可能学得有点慢，所以有时需要几篇文章才能解决一个问题，但随着时间的推移，我的写作提高了很多。

只有当我感觉想发布时才发布，是因为我通常更喜欢过程目标而不是结果目标，至少对于个人目标是这样。我最初有一个目标是每月花一定时间写博客，但当我意识到无论是否将其作为一种义务，我都会花足够时间写作时，我就放弃了这个目标。我认为关于博客的结果目标对某些人确实有效（例如，“每周发布一篇文章”），但如果你的目标是提高写作质量，结果目标可能适得其反（例如，为了在有限时间内实现“每周发布一篇文章”的目标，有人可能专注于发布东西，而不考虑如何提高质量，因为从结果目标的角度来看，提高质量是浪费时间）。

以写我想订阅的内容为目标，当然是非常主观的。我不喜欢其他博客中的一些东西，所以我尽量避免它们。例如：

• 将可能是一整篇文章的内容拆分成多篇较小的文章
• 标题党
• 反复写同一话题却没有新意
  • 这其中的一个子类别是拥有某种信念，然后每当出现支持该信念的证据时就写博客，却不提出现反证的证据
• 没有RSS或Atom订阅源

在自己的平台上写作是最次要的一个。一个主要原因来自平台的兴衰。在我开始写博客时，一些平台已经出现又消失。最近，Twitter收购了Posterous并将其关闭。有一段时间，Posterous是当时最时髦的平台，而Twitter决定完全关闭它，破坏了许多史上得票最高的HN文章的链接等。Blogspot，之前一个流行的写作场所，也被谷歌收购，之后严重降低了读者体验。避免时髦的平台效果很好。当我开始写博客时，人们纷纷使用的两个时髦平台是Svbtle和Medium。在我开始写博客后不久，Svbtle基本上就被废弃了，因为Medium在受众规模上显然将占据主导地位。而Medium从未找到良好的变现策略，并在尝试产生足够收入以证明其在融资1.6亿美元后的估值后，严重降低了读者体验。你无法信任别人的平台不会在你下面消失，或为了利润而彻底改变。

我想做的另一件相关的事情是在自己的空间（而不是在互联网评论中）写作。我过去写了很多HN评论⁶，但HN评论的半衰期很短。除极少数例外，一篇评论将获得的几乎所有浏览量都在最初几天。而对于博客，则恰恰相反。一篇文章最初可能会获得一波流量，但只要你坚持写下去，大部分流量会在之后到来（例如，对于我的博客，当一篇文章在HN上时，我通常会获得大约两倍于基准水平的点击量，当然我大多数时候并没有文章在HN上）。写一篇“真正的博客文章”并不比写一篇HN评论多费多少功夫，所以我倾向于写博客文章而不是HN评论。另外，当我在这里写作时，创造的大部分价值在我和读者之间分配。如果我在别人的平台上写作，大部分价值将在平台和读者之间分配。如果我做视频，我可能没有选择，只能在YouTube或Twitch上，但对于文字，我确实有选择。看看那些做出不同选择、决定为平台写评论的人后来怎样了，我认为我为正确的理由做出了正确的选择。我确实看到了在现有平台上评论减少的摩擦力的吸引力，但即便如此，我宁愿付出额外摩擦的成本，写一些在我自己空间里的东西，而不是写在别处。

所有这些加在一起基本上就是全部了。这就是我的写作方式。

与其他博主不同，我不会试图告诉你“如何有用地写作”或“如何写得好”之类的。我同意Steve Yegge的观点，他认为你应该考虑写作，因为它可能具有高价值，而且价值可能以你意想不到的方式出现，但如何写作应该真正源于你的目标和才能。

附录：方法随时间的变化

当我开始写博客时，我担心一篇文章会因为只包含一个简单想法而不够有趣，所以我经常等到能将两个或更多想法合并成一篇文章。回顾过去，我认为我早期的许多文章如果分成单独的文章会更好。例如，2016年这篇关于薪酬的文章包含了薪酬可能变得双峰分布的想法，以及考虑到与其他同样高薪的领域（如金融、法律和医学）的准入门槛相比，程序员的薪酬高得令人难以置信。我不认为把这两个想法合并成一篇文章有多大价值，而且我认为如果关于程序员薪酬异常高的部分没有捆绑到一篇关于薪酬双峰分布的文章中，会有更多人阅读它。

我过去还做的一件事是避免写那些看起来太明显的东西。但是，我逐渐认识到写下明显的东西有很多价值，我一些最有影响力的文章都是关于我以前认为太明显而不值得写的话题：

• https://danluu.com/look-stupid/
• https://danluu.com/people-matter/
• https://danluu.com/culture/
• https://danluu.com/learn-what/
• https://danluu.com/productivity-velocity/
• https://danluu.com/in-house/

排除这些近期文章，告诉我https://danluu.com/look-stupid/改变了他们操作方式的人，比告诉我的其他所有文章加起来还要多（而之所以接近，仅仅是因为有很多人告诉我关于薪酬的讨论让他们意识到可以找到一份更喜欢且年薪比以前高出数十万美元的工作，这是从人们告诉我文章毫无意义因为每个人都知道科技行业能赚多少钱的评论最多的一组文章）。

一个主要且相对较新的风格变化是我正在尝试使用更多例子。这是受Ben Kuhn评论的启发，到目前为止我很喜欢。与大多数博主相比，我在早期并不缺少例子，但我注意到一点，增加比我自然倾向更多的例子确实能为读者澄清事情；“很多”例子能降低人们得出与我本意截然不同的想法的速度。一个具体的例子是，在一篇讨论达到95百分位水平表现需要什么的文章中，我只提供了几个例子，许多人填充了空白，认为远高于99.9百分位的表现就是95百分位，例如成为国际象棋大师是95百分位。

另一个做出这种改变的人是Jamie Brandon。如果你读他早期的文章，比如这篇，他经常有一个引人入胜的想法和漂亮的措辞，例如这段关于他与Chris Granger一起开发Eve时的内容：

人们经常告诉我，命令式编程是自然的编程形式，因为‘人们以命令式方式思考’。我能理解他们的意思。就在前几天，我还发现自己说：“嘿Chris，我饿了。我需要你走进厨房，打开橱柜，拿出一袋面包，打开袋子，取出一片面包，放在盘子上……”不幸的是，我没有说明盘子在哪里，所以这时Chris抛出了空指针异常并死了。

但是，尽管有些部分真的很吸引人，他的早期写作在某种程度上与现实世界脱节，这是Jamie回顾自己的旧文时不喜欢的。关于添加更多细节，Jamie说：

专注于具体例子并尽可能保持具体的关键在于：a) 让我更不可能出错，因为非具体的想法很难证伪，我很容易欺骗自己；b) 让读者更有可能吸收我试图传达的想法，而不是一些表面上相似但符合模糊文本的想法。

例子能固定想法，以便它们能被恰当地审视。

另一个重大变化，也是我唯一要在这里讨论的真正属于散文风格的变化，是我更努力地尝试写作中保持一种有时被称为“叙事语法”的连续性。Nicola Griffith的这篇文章有一些句子层面的例子，但我也会在写作的更大结构上思考这个问题。我不认为自己特别擅长这个，但更多地思考这一点使我的写作更容易理解。这个变化，尤其是在更大规模上，确实是与一位擅长发现使写作更难理解的结构性问题的专业编辑合作的结果。但同时，如果某事难以理解有原因，我也不会太担心。一个具体的例子是，如果你阅读ask metafilter或reddit上问题的答案，任何结构上非简单的问题都会有大量答案来自那些未能仔细阅读问题并回答错误问题的人，例如，如果有人问一个包含用and连接的两部分的问题，很多人只会读and的一半，并给出一个明显被and条件排除的答案。如果很多人连一个简短问题的and的两边都不愿意仔细阅读以给出满足两部分的答案，那么很多人也不会跟进任何人可能想写的最简单的东西。我认为试图引导那些连and两边都不愿意读的人通过一篇有结构的文章，对作者来说不是时间的有效利用，但我确实认为努力避免“叙事语法”问题是有价值的，因为这些问题可能让真正想阅读的人更难理解。

附录：获取反馈

正如我们之前讨论的，反馈可以极大地促进进步。不幸的是，那篇文章中的观点，即95百分位水平表现通常很差，也适用于反馈，使得大多数反馈适得其反。

我花了很多时间观察人们在私人渠道中获得反馈，并看到他们如何根据反馈改变他们的写作，至少在我观察的渠道中（程序员，而非专业作家或编辑的评论），大多数反馈被忽略了。而当反馈被采纳时，因为几乎所有的反馈都是糟糕的，而且人们通常并不完美，甚至不太擅长筛选好的反馈，所以被采纳的反馈通常是糟糕的。

根本上，大多数反馈都有本文提到的问题，是“你应该像我那样写”的一种形式，这通常行不通，除非反馈的作者在给出反馈时非常小心，但很少有人这样做。反馈往往是表面的建议，忽略了写作中严重的结构性问题。此外，反馈也往往是“最低公分母”式的反馈，将优美的散文变成Strunk-and-White风格化的平庸散文。我不认为我的散文风格特别好，但我见过一些拥有自然优美风格的人向程序员寻求反馈，结果他们的写作变成了任何人都能写出的无聊散文。

另一面是，当人们得到我认为好的、实质性的反馈时，最常见的回应是“算了，没事”。我认为这是大多数反馈都是“你应该像我那样写”的对立面。大多数人对反馈的回应是“我想怎么写就怎么写”。

尽管这篇文章侧重于多种风格都可以奏效，但同样真实的是，给定一种风格和一组目标，写作可以更好或更差。但是，大多数得到反馈的人对写作了解不够，无法知道什么是更好什么是更差，所以他们无法区分好反馈和坏反馈。

解决这个问题的一种方法是获得你信任其判断的人的反馈。如文章所述，我的做法是聘请一位我尊重其写作（和编辑）的专业编辑。

我做的另一件事，也是我个性的核心方面，与写作关系不大，是我相对认真地对待反馈，并努力避免对反馈有“算了，没事”的回应。我不会说这是最佳状态，因为我有时花了太多时间在糟糕的反馈上，但我思维方式的一个核心部分是我意识到大多数人过度自信，并且经常因为过度自信而出错，所以我不信任自己的推理，并花相对大量的时间和精力思考反馈，以试图降低我的过度自信率。

有时，我会花可笑的长时间思考一些现在看来非常糟糕且“显然”不正确的反馈，因为我一直担心因认为其不正确而错误地驳回它。我注意到的一件事是，随着人们获得受众，有些人变得越来越自信，最终变得极度过度自信。这很容易理解——当你声名鹊起时，你会获得更多的曝光和更多认为你总是对的“粉丝”，而另一方面，你也会得到更多“显然”错误的评论。

在几乎没人读我博客的时候，我得到的大部分评论都相当好。随着我读者越来越多，好评论的百分比下降了。从观察其他人如何处理这个问题来看，一种常见的失败模式是，他们会看到他们的文章吸引了大量明显错误的评论，然后错误地认为所有的批评者都是笨蛋，他们自己基本上从不犯错。除了“非常认真地对待批评”之外，我并没有真正的解决办法。由于这里的失败模式涉及判断中的盲点，我没有看到一个简单的方法来认真对待某条批评，同时又不会因为盲点而错误地驳回批评。

根本上，我的解决方案是避免查看大多数反馈，同时努力接受我信任的人的反馈。

当涉及散文问题时，我们在上面讨论过，聘请一位我尊重其写作和编辑的专业编辑，并在散文问题上听从他们的意见，效果很好。

当涉及逻辑严密性或一般趣味性时，这些更难外包给一个人，我有一组我信任其判断的人会看大多数文章。如果任何我信任其判断的人认为一篇文章有趣，我就认为这是一个强有力的确认，我基本上忽略那些说文章无聊或没意思的评论。我几乎所有在“告诉我的文章改变了他们生活”的人数中名列前茅的文章，都收到了一些我认为判断力不差的人说文章似乎无聊、无意义、太明显不值得写或根本不感兴趣的评论。我过去常常认真对待说文章不有趣的评论，但回想起来，那是一个错误，浪费了我很多时间，也没有提高我的写作。我认为这与那些说“像我那样写”的人没什么不同；相反，这是那些在“有趣性”方面有相似心智模型的人，他们无法想象其他人会觉得他们不觉得有趣的东西有趣。当然，不是所有人的思维都如此，但擅长模拟他人觉得什么有趣的人通常不会留下“这很无聊/毫无意义”之类的反馈，所以这种形式的反馈几乎可以肯定是无价值的。

当涉及论证的严密性时，我采取与对待趣味性相反的态度，即我非常认真地对待负面评论，而对正面评论则不太在意。有时，我因为这个在特定文章上浪费了很多时间。我的解决方法是努力忽略那些经常给出糟糕反馈的人的反馈。我认为这样做是危险的，因为有选择地忽略反馈是制造回音室的好方法，但真的认真花时间思考反馈，即使我没有看到逻辑漏洞，也是非常耗时的，考虑到我收到反馈时会重新评估自己的工作，我认为没有其他替代方法。

最近我开始做的一件事让我对此感觉好多了，那就是观察人们给别人的反馈。给我糟糕反馈的人通常给其他人的反馈方式也差不多一样糟糕。因为我不太担心自己存在某种认知偏差，会误导我认为当涉及他们对别人写作的反馈时我是对的他们是错的，我可以花几分钟时间看到他们对别人写作的反馈是胡扯，然后发现他们对我的反馈方式完全一样也是胡扯。

附录：我的想法从何而来

我经常被问到如何产生想法。我原本不打算说任何关于这个的内容，因为我没什么可说的，但Ben Kuhn强烈敦促我加上这一节，“以便其他人意识到你有多么另类”。

我的感觉是世界充满了有趣的东西，想法无处不在。我有大约一百篇草稿，我认为基本上可以发布，但出于各种原因没有优先完成。如果算上那些我已在脑海中构思但还没有写下来的帖子，数量肯定达到成千上万。如果我辞职，然后坐下来全职写作直到去世，我认为即使我只写已经有过的想法，也不会用完。世界是如此广阔、奇妙且具有分形般的趣味性。

例如，我最近开始玩冲浪皮划艇（一种皮划艇），可以说，在几周之后，我大概有二十个左右的博客文章想法，我认为这些可以以普通受众为目标写出来，就像这篇关于分支预测的文章是为普通受众写的，因为它不假设有任何硬件背景。我可以写两篇关于独木舟桨进化和设计的不同技术方面的文章，以及两篇关于文化因素及其如何影响不同独木舟桨设计发展的文章。皮划艇桨的设计在近代历史上要丰富得多，这很容易再写出五到六篇文章。船体设计的技术方面更为丰富，可以成为文章的不竭源泉，尽管目前我脑子里只有四篇特定文章的想法，但文化和历史方面对我来说似乎也很有趣，这补充了我脑海中关于这个话题的二十件事。

我脑子里有二十篇关于皮划艇和独木舟的文章，并不是因为我对皮划艇和独木舟特别感兴趣。一切似乎都足够有趣，值得写二十篇文章。我现有的很多文章，如果我有时间写出来，可能会成为一个更长系列的一部分。例如，这篇关于棒球决策的文章，在我脑海中是一系列关于决策的较长（10篇以上）文章的第一篇，我从未抽出时间写出来，我怀疑我永远不会写，因为有太多其他有趣的东西要写，而时间又不够。

附录：其他关于写作的文章

• Richard Lanham：分析散文
  • 我认为从这本书中直接提取可操作的东西并不容易，但我发现它剖析散文节奏的方式非常有趣
• Robert Alter：摩西五经
  • 关于Robert Alter在翻译中做出某些微妙选择的脚注
• Francis-Noel Thomas & Mark Turner：清晰简单如真理
  • 如果你想以干净、权威的风格写作
    • 将此书作为指南的人通常写得没有细致差别，并有很多不正确的陈述，但我认为这并非必要。此外，文章通常引人入胜，这是许多人更喜欢细致差别的方式；许多科技界的受欢迎作者使用类似的风格
• Gary Hoffman & Glynis Hoffman：再见，Strunk & White：新学术散文手册
• Tracy Kidder & Richard Todd：好散文：非虚构的艺术
  • Kelly Eskridge向我推荐了这本书，因为它深入探讨了编辑和作者如何互动，我发现记住这一点在与编辑合作时很有用；读这本书可能是理解与优秀编辑合作是什么样的低效方式，但如果你好奇《新机器之魂》的作者如何写作，可能值得一读；如果你不确定编辑能为你做什么，这本书是很好的读物
• Steve Yegge：你应该写博客
  • 特别是“理由#3”，Jacob Gabrielson / Zero Config的故事，尽管整篇都值得阅读
• Lawrence Tratt：关于撰写研究论文我目前学到的
  • 写得很好，像Lawrence的其他作品一样。而且我认为有趣的是，Lawrence在大多数主要方面与我有着完全不同的过程，但最终的风格在比较所有编程博主时相对相似（当然比这篇文章正文中提到的任何作者都更相似）
• Julia Evans：我如何撰写有用的编程漫画
  • 很好地解释了Julia的小册子为何成功；也与我的方法完全不同，但这次结果也完全不同
• Yossi Kreinen：写博客很难（这个标题与他的下一篇文章“底层很容易”形成对比）
  • 一个罕见的例子，第一篇基本上是“我要写博客”的文章，既有趣，又有有趣的后续文章；还有Yossi的写作哲学
• Phil Eaton：是什么造就了出色的技术博客
  • Phil在技术博客中喜欢的属性的简要总结。它有点与人们通常从Thomas和Turner的《清晰简单如真理》中得出的相反

附录：增加受欢迎程度但我不常做的事情

以下是我通过观察他人发现有效但我自己不做的事情，但如果你想拥有广泛的受众，或许你可以尝试其中一些：

• 使用标题党
  • 说脏话或说某事“是毒药”或“是X的越南战争”或其他高度情绪化的短语似乎特别有效
• 夸大声望/成就/头衔
• 使用权威的语气和/或风格
• 以愤怒的语气写文章或旨在引起愤怒的文章
• 频繁写作
• 获得他人背书
• 写热门、当前的话题
  • 对近期事件发表看法
• 对主题使用故意惊世骇俗/有争议的框架

附录：一些写作摘录

如果你不熟悉提到的作者，以下是一些我认为能代表他们写作风格的摘录：

Joel Spolsky：

我真的在意的原因是微软正在吸纳太多的程序员。在微软，他们那些不道德的招聘人员向毫无戒心的大学生开出附带苛刻条件的爆炸性offer，而谷歌（你们在我的雷达上）向那些极限飞盘经验比Python还丰富的孩子们支付无法维持的薪水，他们的主要工作将在谷歌园区玩桌上足球，到处试图让某个人……任何人……来看他们用“20%时间”写的演示代码，做某种，让我猜猜，基于云的同步……在微软和谷歌之间，一个聪明的计算机科学毕业生的起薪正危险地接近六位数，而这些聪明的孩子，我们大学的精华，正在从事毫无希望和用处的架构天文学，因为这些公司就像癌症，不惜一切代价追求增长，即使他们想不出一件对我们有用的东西，但他们下周还需要3000-4000名计算机科学毕业生。而且该死的桌上足球不会自己玩它自己。

以及

1991年我开始面试程序员时，我通常允许他们使用任何他们想用的语言来解决我给出的编码问题。99%的情况下，他们选择C。如今，他们倾向于选择Java……Java通常不是一种足够难的编程语言，无法用来区分优秀程序员和平庸程序员……一个纯Java的计算机科学学位并没有真正筛掉那些缺乏处理这些概念所需心智敏捷性的学生。作为雇主，我看到100%采用Java的学校已经开始培养出相当多的计算机毕业生，他们根本不具备在比又一个Java会计应用程序更复杂的任何东西上工作的程序员素质，尽管他们勉强通过了新简化的课程。这些学生永远无法通过麻省理工的6.001或耶鲁的CS 323，坦率地说，这就是为什么作为雇主，麻省理工或耶鲁的计算机科学学位比杜克大学（最近全面转向Java）或宾夕法尼亚大学（用Java替代了Scheme和ML）的学位更有分量的原因之一。

Paul Graham：

几年前，一位风险投资家朋友告诉我他参与的一家新创公司。听起来很有前途。但下次我和他交谈时，他说他们决定在Windows NT上构建他们的软件，并且刚刚聘请了一位非常有经验的NT开发人员担任首席技术官。当我听到这个消息时，我想，这些人完蛋了。第一，首席技术官不可能是一流的黑客，因为要成为著名的NT开发人员，他必须自愿多次使用NT，而我无法想象一个伟大的黑客会这么做；第二，即使他很优秀，如果项目必须在NT上构建，他也很难招聘到优秀的人为他工作。

以及

什么样的人会成为讨厌鬼？任何人都能成为吗？我不确定，但我注意到一些模式。讨厌鬼通常是在非常特定的意义上的失败者：尽管他们偶尔有才华，但他们从未取得过什么成就。而且，任何成功到获得显著名声的人都不太可能将另一个著名人物视为骗子，因为任何名人都知道名声是多么随机。

Steve Yegge：

当我在2003年第一次读这本书时，我感到一种可怕的冰冷感，就像你刚意识到过去5年你一直穿着裤子上班但裤子掉在脚踝上那种感觉。第二天我随意地问了一圈：“是的，呃，你读过那本，嗯，《重构》书，当然，对吧？哈，哈，我只是因为我很久以前就读过，不是刚读完，所以问问。”在我调查的20人中，只有1人读过。谢天谢地，我们都把裤子掉在脚踝上了，不只是我。

这是一本关于如何写出好代码的精彩书，这样的书不多。可能没有。他们通常不在学校教你如何写出好代码，你可能永远学不会。可能需要几年时间，你可能仍然缺少一些关键概念。我肯定就是如此。 ... 如果你是一个相对有经验的工程师，你会认出书中80%或更多的技术，这些是你已经弄明白并开始习惯去做的。但它给了它们所有名称，并客观地讨论了它们的优缺点，我觉得这非常有用。它还揭穿了我从程序员生涯早期就珍视的两三种做法。不给代码加注释？局部变量是万恶之源？这家伙是疯子吗？读读它，自己判断吧！

以及

杰夫·贝佐斯是一个臭名昭著的微观管理者。他微观管理亚马逊零售网站上的每一个像素。他聘请了拉里·泰斯勒，苹果的首席科学家，可能是全世界最著名和最受尊敬的人机交互专家，然后完全无视拉里三年里说的每一个该死的事情，直到拉里最终——明智地——离开了公司。拉里会做这些大型可用性研究，并且毫无疑问地证明没有人能理解那个该死的网站，但贝佐斯就是无法放手那些像素，那些登陆页面上数百万语义密集的像素。它们就像他数百万自己珍贵的孩子。所以它们都还在，而拉里已经不在了。

微观管理并不是亚马逊做得比我们好的第三件事。我是说，没错，他们微观管理得很好，但我不认为这算是什么优势。我只是想在这里设定背景，帮助你理解发生了什么。我们谈论的是一个在公开场合多次严肃地说人们应该付钱给他才能在亚马逊工作的人。他分发印有他名字的小黄便利贴，在人们与他意见不一致时提醒他们“谁是公司老板”。这家伙是个典型的……嗯，史蒂夫·乔布斯，我猜。只是没有时尚或设计品味。贝佐斯非常聪明；别误会我。他只是让普通的控制狂看起来像吸了大麻的嬉皮士。

Julia Evans：

现在我正在从纽约到蒙特利尔的一百万小时火车旅途中。所以我在看strace的输出，因为，呃，strace很酷，它正在教我一些关于我经常使用的命令行工具如何工作的知识。

strace的作用是捕获执行程序时调用的每一个系统调用。系统调用是用户空间程序和内核之间的接口，所以看strace的输出是理解Linux如何工作以及运行一个程序到底涉及什么的一个有趣方式。

例如！killall！我运行了

strace killall ruby1.9.1 2> killall-log.

附录：GPT-4o认为人们如何写作

[2024年更新]

我见过相当多的人对GPT-3、GPT-3.5和GPT-4“模仿”某人并创作出其风格作品的能力赞不绝口，让你可以阅读假设的文章或与某人进行假设的对话。我发现这通常效果不佳。以下是提示“生成一段200字关于微软的引语，内容是X可能会写的。”的示例（我尝试了其他提示，结果同样糟糕，因为内容、语气和风格与这些人的实际产出不太相似）：

Joel Spolsky：

微软是工程卓越与商业智慧复杂相互作用的一个研究案例。他们不仅仅是一家构建软件的公司；他们是一个庞大的、多触手的庞然大物，几十年来，成功地将自己插入了科技行业的几乎每个角落。他们有过失误——有人记得Clippy或Zune吗？——但他们也取得了惊人的成功。微软的魔力在于他们转向和适应的能力，经常将看似巨大的失误转变为他们战略不可或缺的一部分。

他们最初的主导地位建立在Windows和Office之上，这对强大的组合定义了几十年来个人和企业计算。但真正令人着迷的是他们如何进化。在纳德拉领导下，微软从一个笨重的巨人转变为一个灵活的创新者，一头扎进Azure的云中，并拥抱了他们曾经排斥的开源社区。他们创建了一个强大且，我敢说，有趣的开发者生态系统。微软不再仅仅关乎软件；它关乎平台、服务和一个不断增长的互联工具宇宙。它们证明了即使是最大的公司，如果愿意不断地重新思考和重塑自己，也能保持相关性。

Paul Graham：

微软的历程是适应性战胜惰性的典型例子。在其早期，该公司体现了抓住机会的创业精神，从一个两人团队转变为一个通过智取更大、更成熟的竞争对手而形成的庞然大物。他们掌握了软件商品化的艺术，并建立了一个生态系统，使个人计算成为普遍现实。然而，成功滋生了自满。多年来，微软紧抱着Windows和Office这两个摇钱树，错过了移动和互联网革命，而年轻、更灵活的竞争对手重塑了行业。但微软的故事并没有结束。在萨蒂亚·纳德拉富有远见的领导下，该公司重新发现了其创业根基，转向云计算，并以类似于其早期的热情拥抱了开源。这种转型的能力，在面临深刻的行业变化时重新想象自己的能力，是使微软保持相关性的原因。这对每个初创公司和科技巨头都是一个教训：长寿的关键不仅是创新，还有不懈追求重塑。在微软的世界里，唯一不变的是变化，而公司真正的天才在于其适应和繁荣的坚定能力。

微软是一个引人入胜的探索对象，特别是如果你喜欢深入技术的细节并观察它们如何扩展复杂性。很长一段时间，如果你使用计算机，你无法避开这个庞然大物。Windows和Office就像你呼吸的空气——无处不在且不可或缺。但真正有趣的是微软如何进化。他们从桌面的守门人变成了云领域的先驱和开源的倡导者。

想想Azure。这是一个巨大的基础设施，为从小型初创公司到大型企业的一切提供动力，使开发者只需点击几下就能在全球部署代码。然后是他们对开源的拥抱。记得他们收购GitHub的时候吗？那表明微软是认真的支持开发者社区。这不仅仅是一次公关活动；他们正在贡献甚至领导我们数百万人依赖的项目。

他们的工具对我们许多人来说已经变得不可或缺。例如，Visual Studio Code，使用起来很愉快。它轻量、快速、可扩展——是微软如何学会构建开发者喜爱的产品的完美例证。这是一家不惧怕重塑自己的公司，并在此过程中让我们的科技生活变得更好、更有趣。

感谢Yossi Kreinin、Ben Kuhn、Laurence Tratt、Heath Borders、Jamie Brandon、Julia Evans、Vegard Nossum、Julien Kirch、Bram Delver和Pam Wolf的评论/更正/讨论。

由 mimo-v2.5 模型翻译，花费 28416 tokens

这是我在一两年前在Twitter做的一次简短闪电演讲的伪转录稿（实际用词已调整为比100%忠实转录更易读的形式），关于我们在使用延迟指标时遇到的陷阱（服务名称已根据通信要求匿名处理）。自那次演示以来，在基础设施方面已取得重大进展，因此现状较当时已有很大改善，但我认为这仍然相关，因为通过与同侪公司的同行交流，发现许多人正面临类似问题。

我们经常在Twitter使用尾部延迟指标。最常见的情况是，服务所有者希望获得其服务的集群范围或Twitter范围的延迟数据。不幸的是，由于我们延迟测量设置中的一些历史特殊性，服务所有者倾向于使用的数字与我们希望测量的数字存在差异：

• 不透明的、未被检测到的延迟
• 缺乏集群范围的聚合能力
• 分钟级分辨率

不透明的、未被检测到的延迟

当我们查看大多数服务的仪表盘时，显示和用于告警的延迟指标通常来自服务本身运行的服务器。一些由高级SRE（他们曾因不可见的延迟问题受过教训）设置的仪表盘的服务，也会包含来自服务调用者观测到的客户端延迟。我想讨论这种设置的三个问题。

在本次演讲的范围内，我们可以将客户端请求视为在客户端“用户”代码将请求传递给我们RPC层（Finagle）之后、客户端用户代码接收到响应之前，经过了以下管道（由于Finagle当前处理请求的方式，一旦请求移交给我们在使用的网络库（netty），我们无法获取特定请求的时间戳）：

客户端 netty -> 客户端 Linux -> 网络 -> 服务器 Linux -> 服务器 netty -> 服务器“用户代码” -> 服务器 netty -> 服务器 Linux -> 网络 -> 客户端 Linux -> 客户端 netty

正如我们之前在[一份内部文档中量化CFS带宽控制节流的影响以及我们使用过大的线程池如何导致节流]中所看到的那样¹，我们经常在netty中及以下层发生大量排队，这会产生连锁反应，导致服务被内核节流，这通常会导致大量不透明延迟，尤其是在高负载时——此时我们最希望仪表盘能显示正确的延迟数字。

当我们在服务器端采样延迟时，我们基本得到的是：

• 服务器服务“用户代码”的延迟

当我们在客户端采样延迟时，我们基本得到的是：

• 服务器服务“用户代码”的延迟
• 服务器端 netty 延迟
• 服务器端 Linux 延迟
• 客户端 Linux 延迟
• 客户端 netty 延迟

这里有两个问题：第一，仅凭指标数据，我们无法很好地分辨栈中不透明部分的延迟是来自客户端还是服务器端。作为服务所有者，如果你基于客户端延迟设置告警，即使你的服务运行平稳，当客户端延迟因netty或Linux中排队过多而上升时，你也会收到告警。

其次，鉴于我们暴露的数据，合理查看的客户端延迟指标会给出客户端与所有服务器通信的延迟，这与我们在服务器指标上看到的视图非常不同——服务器指标给出的是每台服务器的延迟数据，而且没有好的方法能聚合所有客户端的每服务器客户端数据，因此很难判断，例如，某个特定服务器实例的netty中是否存在高延迟。

以下是一些在客户端测量与服务器端测量的集群范围延迟差异的例子。这些例子是特意挑选的，以展示客户端与服务器端延迟差异的一个横截面。

这是一个累积分布函数图，采用了CDF的标准方向，纵轴是百分位数，横轴是数值，这意味着向下和向右表示更高延迟，向上和向左表示更低延迟，线越平缓表示延迟增长越快，线越陡峭表示延迟增长越慢。

由于该图表在两个轴上都是对数刻度，客户端与服务器端延迟的差异实际上很大，尽管这些线看起来并没有那么远。例如，如果我们看99%分位数延迟，在服务器端测量约为16毫秒，而在客户端测量约为240毫秒，相差15倍。或者，如果我们看一个固定的延迟值，比如240毫秒，然后向上查找百分位数，会发现这是客户端的99%分位数延迟，但在服务器端则远高于99.9%分位数延迟。

下面的图表具有类似的特性，尽管客户端与服务器端之间的差异会有所不同。

我们可以看到，客户端测量与服务器端测量的延迟常常存在显著差异，即使在较低百分位数差异较小的情况下，在较高百分位数时差异有时也会变得很大——因为更高的负载可能导致更多排队，从而在netty和内核中产生更多延迟。

需要注意的一点是，对于任何特定的测量到的服务器端延迟值，我们都能看到非常宽范围的客户端延迟值。例如，这是service-5的客户端与服务器端延迟的放大散点图。如果我们缩小范围，会看到对于一个服务器端测量延迟为10毫秒的请求，我们可能看到客户端测量延迟高达500毫秒。更普遍地说，我们看到许多请求的服务器端测量延迟与客户端测量延迟非常相似，但也有少数请求的服务器端测量延迟是对客户端测量延迟的非常不准确的表示。在几乎所有这些情况下，由于栈中我们不可见部分的排队，客户端测量延迟更高，而在极少数情况下，由于我们检测方面的一些问题，客户端测量延迟会更低。在下面的图中，由于我们追踪延迟的方式，我们对延迟只有1毫秒的粒度。下面图表上的点已随机抖动了+/- 0.4毫秒，以便更好地展示图表上非常密集点的分布情况。

虽然有可能通过netty和内核来检测请求延迟（在Finagle移交请求之后进行追踪）（内核甚至有一些钩子可以使这变得相对简单），但这可能在近期值得做的工作量太大。如果你想知道你的服务受不透明延迟影响的程度，利用Zipkin和Rebecca Isaacs、Jonathan Simms 和 Rahul Iyer 所做的工作，可以相当容易地获得一个大致的概念，这也是我生成上面那些图表的方式。这些代码的源代码在[我们monorepo中的一个路径]，如果你只是想检查另一个不同的服务，你可以插入你自己的服务名称。

缺乏集群范围的聚合能力

在上面的例子中，我们能够获得集群范围的延迟百分位数，因为我们使用了来自Zipkin的数据，该系统尝试以均匀随机的方式采样请求。由于各种原因，服务所有者主要依赖指标数据，虽然更完整（因为是无采样的），但不允许我们计算集群范围的聚合，因为我们是在每个分片基础上预计算固定聚合，并且无法从分片聚合中重建集群范围的聚合。

通过查看我们服务的仪表盘，最常见的延迟目标是分片级99%分位数延迟的分片平均值（一些位于请求树深处的服务，如缓存，使用更尾部的数字）。不幸的是，取分片尾部延迟的平均值违背了监控尾部延迟的目的。如果我们思考为什么我们想要使用尾部延迟，因为当我们有高扇出和深度请求树时，很小一部分服务器响应变慢就可能拖慢许多或大多数顶级请求，而取尾部延迟的平均值未能捕捉到使用尾部延迟的价值——因为它未能捕捉到“一小部分服务器响应变慢就可能拖慢许多或大多数请求”这一特性，同时也错过了查看集群范围平均值的优点（后者可以从分片平均值中重建）。

例如，当我们有几个坏节点返回慢响应时，这对分片平均尾部延迟的影响很小，尽管集群范围的尾部延迟会大幅升高。正如我们在[一份量化整个集群中机器级问题范围以及对数据完整性和性能影响]的文档中看到的那样²，我们经常遇到主机级问题，这可能使节点上的尾部延迟上升一个或多个数量级，有时甚至能使节点上的中位数延迟超过其他节点上的尾部延迟。由于少数甚至一个这样的节点就可能决定一个集群的尾部延迟，因此对所有节点取平均值可能会产生误导，例如，如果我们有一个100节点的集群，其中一个节点上的尾部延迟上升了10倍，这可能导致我们集群范围延迟的平均值增加0.99 + 0.01 * 10 = 1.09倍，而实际的尾部延迟增加幅度要大得多。

一些服务所有者试图通过取99%分位数的分位数（通常是90%分位数或99%分位数）来获得对集群范围尾部延迟的更好近似，但这也不起作用，而且通常，没有任何分片级分位数或其他分片尾部延迟的聚合可以重建集群级别的尾部延迟。

下面是人们在仪表盘上尝试使用实例级指标数据获取集群范围延迟的各种方法与某个服务上实际（采样的）集群范围延迟的对比图（对于较小的服务，分位数的分位数尝试会更不准确）。我们可以看到相关性非常弱，并且存在我们预期的问题：尾部延迟的平均值受异常分片的影响不如它“应该的”那么大，而各种常用的分位数要么受影响不足，要么受影响过度，平均而言与实际延迟的相关性也很弱。由于我们以分钟级粒度跟踪指标，下面图表中的每个点代表一分钟，其中采样的集群范围p999延迟在横轴上，仪表盘聚合指标值在纵轴上。由于我们从跟踪管道中获得的单个延迟测量值有1毫秒的粒度，这些点已水平抖动了+/- 0.3毫米，以便更好地展示分布情况（纵向没有施加此类抖动，因为我们的指标管道没有这种限制，因此数据精度更高）。

集群范围延迟与分片延迟聚合之间的相关性非常弱，以至于即使你选择了能产生正确平均行为的聚合方式，该值对于几乎所有样本（分钟）仍然相当错误。鉴于我们的基础设施，这里真正可行的唯一解决方案是扩展我们的跟踪管道以用于仪表盘和告警，或者在Finagle中添加指标直方图，并将该数据通过所有中间层传递到[仪表盘软件]，以便我们能够获得正确的集群级别聚合³。

虽然取尾部延迟的平均值很流行，因为它简单且人们熟悉它（例如，[隐去名称的同侪公司]的可观测性主管曾表示，他们应该只关注平均值，因为每个人都只想要平均值），但取分片级尾部延迟的平均值或其他聚合方式，既不具备人们想要的属性，也不具备人们预期的属性。

分钟级分辨率

另一个独立的问题，也是我们观察基础设施状况能力上的一个缺口，是我们在收集指标时只有分钟级的粒度。Rezolus可以以秒级（在某些情况下甚至是亚秒级）的粒度收集指标，但出于本次演讲范围之外的原因，它通常只用于系统级指标（少数例外除外）。

我们都遇到过某些突发的、亚分钟级事件成为问题根源的事故。让我们看一个此类事故的例子。在这个事故中，一个服务出现了延迟和错误率升高。查看我们导出的标准指标并无帮助，但查看亚分钟级指标立即揭示了一个线索：

对于这个特定的缓存分片（以及许多其他未显示的），在time 0处延迟大幅增加，随后30秒内请求率非常低。30秒的延迟是因为service-6的分片被配置为：如果service-6客户端遇到太多失败请求，就会将它们通信的服务器标记为死亡状态30秒。这个决定是分布式的，这就是为什么到受影响的cache-1分片的请求率不为零；在延迟升高期间，service-6的一些分片没有向cache-1的特定分片发送请求，因此没有将cache-1的该分片标记为死亡，并继续发出请求。

请求延迟的亚分钟级视图非常清楚地揭示了导致service-6中延迟和错误率升高的机制。

需要注意的一点是，缺乏亚分钟级可见性并不是这里唯一的问题。大部分升高的延迟发生在对延迟指标不可见的地方，这使得监控cache-1的延迟不足以检测到问题。下面，cache-1单个实例的报告延迟指标是蓝点，而客户端观测到的测量（采样）延迟是黑线⁴。报告的p99延迟是0.37毫秒，但实际的p99延迟约为580毫秒，差异超过三个数量级。

总结

尽管我们现有的延迟报告和告警设置运行得相当不错（网站通常能正常工作，并且与同等规模的同侪公司相比，我们的可靠性实际上相当好），但我们确实因为这种设置付出了一些显著代价。

一个代价是，我们经常遇到一些事故，不使用大多数人不使用的专业工具就很难看清发生了什么，这增加了值班的辛劳。另一个代价是，由于我们对集群范围延迟的估算存在较大的误差范围，我们必须预留大量的余地，并保持比实际希望达到的延迟严格得多的延迟SLO（服务级别目标），以避免用户可感知的事故。这增加了运营成本，正如我们在[一份比较每用户运营成本与提供类似类型和级别流量的公司的文档]中所看到的。

如果你喜欢这篇文章，你可能还想阅读关于单主机跟踪与采样分析器对比的内容。

附录：开环与闭环延迟测量

我们的一些合成基准测试设置，如setup-1，使用“闭环”测量，它们实际上发送一个请求，等待它返回，然后再发送另一个请求。其中一些允许一定程度的并行，即可以同时有N个请求在传输中，但这在真实性方面仍然存在类似的问题。

为了说明这个问题，我们假设有一个服务，在生产环境中每秒恰好收到1个请求，并且该服务的正常响应时间是1/2秒。在正常情况下，如果我们以每秒1次的频率发出请求，我们将观察到平均值、中位数和所有百分位数的请求时间都是1/2秒。作为读者的练习，请计算在基准测试运行的1分钟内，中间有一个请求耗时10秒的情况下，闭环与开环基准测试设置的平均值和90%分位数延迟（在开环情况下，基准测试设置以每秒1次的频率发出请求；在闭环情况下，以每秒1次的频率但等待上一个请求完成）。

更多相关信息，请参阅Nitsan Wakart 关于在YCSB基准测试中修复此问题的介绍或Gil Tene 关于此问题的演讲。

附录：未加权平均值的使用

我研究过的一个仪表盘平均值常见问题，与我们取尾部延迟平均值时出现的问题无关，那就是未加权平均值通常会低估实际延迟。

我经常看到未加权平均值的两个地方是：有人通过跨数据中心取未加权平均值来获得整体延迟，以及有人通过跨分片取平均值来获得集群范围延迟。这两者都有同样的问题：负载较低的分片往往延迟也较低。当我们从某个数据中心故障转移时，这种情况尤其明显。错误地使用跨数据中心未加权平均值的服务，通常会显示延迟降低，尽管实际服务请求的延迟反而增加了。

感谢Ben Kuhn的评论/修正/讨论。

由 mimo-v2.5 模型翻译，花费 11332 tokens

这是我认为本博客中相当严重的一系列错误列表。虽然我认为的“严重”当然是主观的，但我认为没有任何合理的方式可以完全避免主观性，例如，我会犯大量的拼写错误，多到许多文章的致谢部分主要是感谢通过邮件或私信向我指出拼写错误的人。

一个包含所有错误（包括拼写错误）的列表不仅对其他读者来说阅读价值不高，对我而言制作门槛也很高，这就是我划定一条界限的原因。一个我认为不算严重的错误例子是，在这篇关于我如何学习编程的文章中，我最初弄错了高中时那些竞赛程序员开始赚钱的时间（比我以为的晚了几年）。在那种情况下，以及许多其他情况下，我认为日期的错误并不会改变文章的重要内容。

虽然这篇博文的原始版本发表于2021年，但我预计这个列表会随着时间的推移而增长。我希望自己能变得更细心，未来的增长速度会比过去慢，但这仍有待观察。我认为列表中有很大一部分来自我2013年博客的前三个月，这是一个好迹象，但这绝不是自满的理由！

我在下面添加了一个我如何对这些错误进行分类的说明，但这种分类也是任意的，各个类别甚至并非互斥。如果我收集到的错误多到难以全部记在脑子里，我可能会创建一个标签系统来对它们进行分类，但我不希望积累如此多的重大错误，以至于需要一个标签系统方便读者浏览。

• 思考不充分
  • 2013年：使用随机算法来降低好文章在Hacker News上“运气不佳”的概率：这个想法曾被尝试过，效果不如让人工介入，由人来决定哪些文章应该从遗忘中被拯救出来。
    • 由于这是一个提议而非断言，技术上讲这并非错误，因为我没有声称它一定会奏效，但我觉得我当时也应该考虑将人工纳入决策的解决方案。我没有那么做，是因为Digg曾因人工干预其首页而受到强烈反对，但回顾来看，我们可以看到以一种不会产生足以摧毁该网站的反对声浪的方式进行人工干预是可能的，并且我认为经过足够思考是可以预见到这一点的
• 天真/幼稚
  • 2013年：创造卓越的机构知识和文化可能需要很长时间来建立：当时我还没有在软件行业工作过，认为这对软件来说没那么困难，因为许多成功的软件公司都是用新的/年轻的团队建立的。但回顾来看，区别并不在于那些公司不生产糟糕（不可靠、多、运行缓慢等）的软件，而在于产品市场契合度和网络效应非常重要，以至于软件糟糕通常也无所谓
  • 2015年：在这篇关于人们不阅读参考文献的文章中，我对于类型系统的倡导者会引用不存在的强力证据感到困惑，这似乎与其他例子不同，在那些例子中，人们传播一个巧妙、反直觉的结论却从未读过它。我认为奇怪之处在于，与其他例子不同，这里没有被传播的不正确证据片段；“有证据”这一断言与任何证据（哪怕是被误解的证据）都毫无关联。回想起来，我天真地以为存在一个证据链接，而人们不会直接编造“存在支持他们信念的证据”这个想法然后传播开去。
• 对信息核实不足
  • 2016年：构建搜索引擎并非易事：虽然我认为总体观点是正确的，但我所依赖的证据之一来自一位搜索引擎从业者告诉我的数据。但当我测量实际数据时，发现我被告知的数据偏差了好几个数量级。
  • 2022年：未来主义者的预测，由@ESRogs向我指出：我误读了nostalgebraist对一份报告的总结，并不理解他所指的敏感性分析。我清楚地记得当时不确定nostalgebraist在说什么，并且最初同意了正确的解读。重新阅读后，我得出的却是错误的理解，并将其写进了我的文章。我对该解读的不确定性本应促使我直接复述他的分析，那会立刻澄清他的意思，但我没有那么做。这个错误并没有从根本上改变我自己的分析，因为我提出的更广泛的观点并不依赖于确切的数字，但允许自己在具有如此不确定性的状态下发布内容而不注明，我认为这是一个非常坏的习惯（考虑到文章本身的内容，这是一个颇具讽刺意味的错误）。导致这个错误，也导致我没有通过检查计算来发现这个错误的一个因素是，引入此错误的编辑是在我想立即发表而非推迟相当一段时间时，在一个很短的时间窗口内进行的最后时刻修改。当然，这本应导致我推迟发表，因此这是一个坏决定导致了另一个坏决定。
• 低级错误/失误
  • 2015年：回顾Butler Lampson在16年后对计算机科学中哪些东西行得通的评述：在2015年说能力（capabilities）是“不行”的是错误的，考虑到它们在移动端的有效性，这在当时看来如此明显错误，我将其称为一个低级错误，而不是那种我经过相当思考但本应思考得更深入的情况。
  • 2024年：规模不经济：我在做算术时搞混了哪个数字除以哪个，导致百分比出现多个数量级的错误。Sophia Wisdom在文章发布几小时后注意到了这个问题，我立即修复了，但这是一个相当愚蠢的错误。
• 晦涩难懂的解释
  • 2013年：数据对齐如何影响内存延迟：这篇文章的主要图表使用了延迟比率，这增加了一层间接性，让很多人感到困惑。
  • 2017年：达到95百分位的性能是很容易的：人们对这篇文章最常见的反对意见类似于“错误。你必须非常有天赋，并且/或者要达到[进入NBA / 成为国际象棋特级大师 / 获得2200的国际象棋等级分]是很难的”。James Clear在推特上提出了一个更弱的主张，也得到了类似的回应。在推特上确实没有空间详细说明，但在我这篇博文中，我应该包括更多具体的例子，说明不同性能水平对于那些难以估计不同百分位性能的人来说是什么样子的。举一个不那么离谱的说法为例，这里有一个说法，即2200的等级分是玩过在线国际象棋的人的95百分位水平，这个说法似乎偏差了大约四个数量级，上下浮动一个。
• 回顾之下的错误
  • 2015年：博客变现：我通过查看当时Casey Muratori、Eric Raymond和eevee在Patreon上的收入，严重低估了我能在Patreon上赚到多少钱。我认为基于各种原因，他们三个人都会比我赚得多，这是不正确的。一个主要原因是，枯燥、长篇的文字变现效果比我预期的要好得多，这意味着与其他技术人士的做法相比，我在经济上低估了这一点的价值。
    • 几周前，我在文章顶部（而不是只隐藏在底部）添加了一个Patreon链接，并在推特上提到了我有Patreon。从那时起，我的收入增加了大约Eric Raymond的总收入水平，并且这个金额似乎在以不错的速度增长，这是在substack兴起之前我不会预料到的结果。但任何意识到个人写作者的文字变现能力有多好的人本可以创建substack，但直到Chris Best、Hamish McKenzie和Jairaj Sethi创建了substack才有人这么做，所以我认为这个错误在某种程度上是不易察觉的。另外，目前尚不清楚这种变现是否会扩大规模还是达到平台期；如果达到平台期，那么我的猜测只会偏离一个小的常数因子。

感谢Anja Boskovic和Ville Sundberg的评论/纠正/讨论。

由 mimo-v2.5 模型翻译，花费 4909 tokens

我在观察数据时发现，人们最常犯的错误之一是错误地使用过于简化的模型。其中一种特定变体已经使我看过的大多数工作路线图脱轨，那就是将人视为可互换的，仿佛谁做什么并不重要，仿佛个体无关紧要。

个体至关重要。

在路线图制定和评审过程中，我反复看到的一种模式是：人们会规划接下来几个季度的工作，然后为每个项目分配一定数量的人员——比如一个人负责一个季度，两个人负责三个季度等。名义上，这个过程能让团队理解其他团队的计划并做出相应安排。然而，我从未在任何一个组织中见到这种方法真正奏效，也从未见到它能让团队在依赖其他团队时有效执行。

我看到的情况是，当项目启动后，人们会询问谁在负责该项目，然后根据负责人是谁来猜测项目是否能按时完成、是否高效，甚至能否完成。“哦，乔在负责功能X？他从没交付过靠谱的东西。看来我们不能指望它，因为这根本行不通。我们做Y而不是Z，因为Z需要X才能正常工作。”路线图制定和评审过程表面上维持着人员可互换的客气假象，但所有人都知道这不是真的。高效且希望按时交付的团队在实际执行时无法配合，即使他们在与制定路线图的经理、总监和副总裁们表面上保持一致。

另一个因人员不可替代性而引发可预见问题的地方是团队管理方式。希望打造高效团队的管理者¹最终不得不与现有体制抗争。非工程部门大多将人员视为可互换的，而在我工作过的多家公司中，财务部门会要求工程部门以“人头”为单位做预算，从而迫使其将人员视为可互换的。公司当然花钱而不是买“人头”，但内部记账却用“人头”计算，因此某团队的X美元预算会被转化为类似“三个资深级别的人头”这样的指标。而“两个更高效、薪水更高的资深级别人头”²则无法体现为这种预算分配。如果你雇佣两名资深工程师而非三名，那么那个“人头”以及相关的预算最终会被转移到别处。

我反复看到的一个情况是：招聘经理想要雇佣一个他认为高效的人，或仅仅是一个拥有专业技能的人，但最终无法实现，因为公司已将预算转化为特定费率的“人头”，而不允许雇佣某些类型的“人头”。人力资源部门的“薪酬团队”或其他团体会提出异议，因为他们没有“高效工程师”或“难以招聘的专业技能”这样的概念；对于一个人来说，角色、级别和地点决定了他们的身份，而为某角色和级别支付过高薪水因此被视为一次糟糕的招聘。如果有任何理性人士掌握流程控制权并愿意使用它，这种情况就不会发生，但根据设计，官僚体制的建立使得很少有人拥有权力3。

类似的情况也发生在人才保留方面。我认识的一位优秀工程师每年为公司创造约数千万美元的额外利润，当此人想回到葡萄牙的家乡时，公司将其现金薪酬削减了四分之三。公司还提出，如果他搬到西班牙而非葡萄牙，则只削减一半现金薪酬。他最终加入了一家不实行地区差异薪资的公司。此事被上报到总监级别，但这并不足以推翻人力资源部门的决定，因此他还是离开了。人力资源部门并不关心此人通过创造价值为公司带来的收益远超过他们为所有国际员工进行地区调整所节省的成本，因为该公司的人力资源部门没有“员工价值”的概念，只有成本、职位、级别和地点⁵。

相关的一个“手段”是我见过两次的例子（一次是远观，一次是亲身经历）：人力资源部门决定人员流失率太低了。一种情况下，人力资源主管认为公司约5%的流失率“不健康”，因为太低了；另一种情况下，人力资源部门认为公司略低于10%的流失率也太低。在这两种情况下，公司都采取了一些措施，导致流失率上升到人力资源部门认为的“健康”水平。在我远观的案例中，我在该公司的熟人认同，接下来一年里公司大多数最优秀的工程师离职了，其中许多人仅工作了几个月。在我亲身经历的案例中，我列出了我所知的最高效工程师的名单（就像上面提到的那位在陪产假期间就为公司增加了0.7%营收的人），当公司成功将整体流失率推高至10%以上时，最高效的工程师流失率是这个数字的两倍多（这甚至低估了其影响，因为他们往往是任期长且资历深的工程师，正常预期的流失率应远低于公司平均值）。

有些人似乎将公司视为《模拟城市》游戏：如果你想要更多钱，可以转动一个旋钮，提高税收，然后均匀地影响整个城市。但公司不是《模拟城市》游戏。如果你想要更高的流失率并转动一个旋钮，你得到的并非随机均匀增加的流失。作为整体的人不能被抽象地对待，认为公司领导层的行为对每个人都产生相同的影响。如果你转动的旋钮导致流失率上升，那么最高效的人离开的可能性会不成比例地高。

到目前为止，我们讨论了将个体人员视为可互换对公司的危害，当然，这在普遍意义上也行不通。例如，我的一位朋友曾在非洲做过大量“实地”开发工作，他抱怨说许多希望捐赠的人想要清晰、简单的标准来指导他们的捐赠（例如，随机对照试验表明该干预措施非常有效）。但许多有效的干预措施无法以任何简单的方式事前证明其影响，原因有很多，其中之一就是实施干预措施的团队构成很重要，导致随机试验或其他实验无法适用于试验团队以外的其他团队在试验背景下的实施。

一个例子是他们参与的一项干预措施，除了其他事情外，帮助在一个国家根除了几内亚虫。事后来看，我们可以说这是一项非常有效的干预措施，因为这是一个三人团队，在每人每天12美元⁶的预算下运作了相对较短的时间，使其成为一项高投资回报率的干预措施，但事前无法为该干预提供量化依据，似乎也不可能存在一组能够证明该干预合理性的随机试验或实验。

他们的干预并非根除几内亚虫，那只是一个副作用。该干预措施基本上是走遍全国各地，深入各地区政府办公室以了解他们的问题，然后建议/协助改进决策。在与人交谈并提出改进建议时，他们意识到通过更好的清洁水分配可以解决几内亚虫问题（饮用未过滤的水可能导致感染几内亚虫；给人们提供清洁水可以解决这个问题），而专门用于水利相关项目（如建造水井）的援助资金如果重新分配到国内因污染水源而导致几内亚虫高发的地区，而不是流向目前援助资金涌入的地方（这些地方往往因为靠近一个开展大量慈善工作的当地“办公室”等原因获得了大量援助资金），那么这些资金已经足够。这个团队为帮助根除几内亚虫所做的具体工作是向政府官员做PowerPoint演示，说明政府如何建议接受援助资金的组织更有效地安置水井。从边际效益看，仅在一个国家根除几内亚虫可能就足以使该干预成为高投资回报率项目，但这只是这个三人团队“回报”中极小的一部分。我提到它只是因为它是一个独立的、易于量化的改变。在地区政府办公室“提升”决策能力的大部分价值很难量化（即使能量化，误差范围也非常大）。

许多事前看似相同的干预措施，可能大多数，产生的影响微乎其微。我的朋友对许多组织有很多评论，这些组织派出大量人员做听起来类似的工作，但产生的价值很小，比如和平队。

我朋友的团队与大多数团队的一个主要区别在于，我朋友的团队由那些在各种环境下都有高效表现记录的人员组成。在之前的一份工作中，我的朋友在一家规模较大（年营收50亿美元）的政府公用事业公司开始工作，并立即被分配了一个问题，她当时不知道这个问题已经悬而未决多年且被认为无法解决。没人愿意碰这个问题，所以他们雇佣了她，想让她当替罪羊，在问题爆发时承担责任。相反，她解决了被分配的问题，还解决了许多其他被认为无法解决的问题。由三名这样的人组成的团队能够从许多潜在的高投资回报率干预中获益，而大多数团队不会成功，例如前往一个陌生国家，改善全国各地区政府办公室的决策能力，使政府能够解决困扰该国数十年的严重悬而未决的问题。

许多最高投资回报率的干预措施同样需要专业技能，不适用于简单的粗略计算，但我看到的大多数关于该主题的讨论，无论是在现实中还是在线上，都严重依赖简单但无关紧要的粗略计算。这不仅限于鸡尾酒会式的交谈。我朋友的干预措施差点被她所在的组织扼杀，因为该组织充斥着她所认为的“过于简化的有效利他主义思维”，导致组织领导层试图将资源重新导向那些预期回报计算更简单的项目，因为那些项目被认为影响力更大，而事后证明其影响力反而更小。当然，我们不应根据事后表现来判断干预措施，因为这会过分有利于高方差的干预措施，但我认为，一个愿意运用判断力而不是将其外包给简单指标的人，应该且能够说相关的干预措施在事前就是好的选择。

这种更容易理解的项目获得更多资金的问题，既存在于组织之间，也存在于组织内部。例如，我的朋友说，当GiveWell主要或只推荐那些具有简单可量化回报的慈善机构时，她基本上无法让在其他领域工作的朋友将资源投入到未被GiveWell认可的努力中。那些不了解她援助背景的人，在她建议将资源投向任何特定事业、项目或组织时，会说类似“你没听说过GiveWell吗？”这样的话。

我当时与一位在GiveWell工作过的朋友讨论了这个问题，据他说，GiveWell最初专注于慈善机构是因为它们的价值容易量化，而不是因为他们认为这些是最高影响力的慈善机构。相反，作为一个年轻的组织，他们需要建立可信度，而为价值容易量化的慈善机构建立可信的案例更容易。他本人不会，他认为GiveWell也不会，支持捐赠者将所有资源都投入给GiveWell认可的慈善机构而忽视其他改善世界的方式。但许多人希望世界简单，并应用“在GiveWell名单上的慈善机构=好；不在名单上的=坏”的算法，因为这使他们的世界变得简单。

对这些人以及整个世界来说，不幸的是，世界并不简单。

回到科技公司的例子，劳伦斯·特拉特指出了一些我也观察到的情况：

在大型组织中，我发现一件非常有趣的事情：当他们意识到需要做些不同的事情（即他们正在慢慢失败，想要扭转局面）时。显而易见的做法是让一个小团队基于他们可能大获全胜的可能性来承担风险。相反，他们往往成立无休止的委员会，这些委员会只是延续了导致其成立的漂移状态！我认为这是因为他们真的很难将人视为非同质化的，即使他们真的想：这几乎超出了他们摆脱组织模式的能力，即使这预示着长期失败。

我们可以用来审视正在发生事情的一个视角是可理解性。当你有一个复杂的系统，无论是拥有数千名工程师的公司，还是有数十亿美元投入援助工作的世界，这个系统对任何决策者来说都过于复杂，无论是公司的高管还是试图理解其资金应投向何处的潜在捐赠者。解决这个问题的一种方法是通过假设个体是可互换的来降低问题的感知复杂性，使系统更易于理解。这会产生相对低效的结果，但与试图理解手头问题不同，它具有高度可扩展性。如果说科技公司喜欢什么，那就是做可扩展的事情，将复杂的系统视为《模拟城市》或《文明》是高度可扩展的。当回报相对均匀分布时，为了可理解性而牺牲潜在的异常回报是一种好的权衡。但当投资回报率呈重尾分布时，当合适的人能够在陪产假期间就将一家巨型科技公司的营收增加0.7%，而全职工作时增加更多时，为了提高可理解性而严重压制分布右侧就是代价高昂的，可能会让你损失大部分潜在回报。

感谢劳伦斯·特拉特、帕姆·沃尔夫、本·库恩、彼得·巴特·哈金斯、约翰·赫根罗德、安德烈·米什琴科、约瑟夫·卡普特和索菲亚·威斯多姆的评论/修正/讨论。

附录：重组

我最近从一位朋友那里听到一个关于一家时尚科技公司的故事，他们试图将六个人调到另一个项目上，一个那些人不想做、认为没有意义的项目。结果是两名资深开发者辞职了，工程经理退休了，一名产品经理被解雇了（说来话长），还有三个人离开了团队。旧项目和新项目的团队都必须从头开始重建。

情况可能糟糕得多。在那个案例中，至少有一些人没有离开公司。我曾问过某人，为什么公开承诺的功能X尚未实现，并且整个子产品都坏了。答案是：在大约一年的工作后，当交付该功能被认为只差几周时，领导层决定这个之前被认为是首要任务的功能不再是优先事项，应该放弃。团队争辩说该功能离完成很近，他们只需要足够的时间来完成。当这个请求被拒绝后，整个团队都辞职了，此后该子产品逐渐衰落。多年后，团队有一次重组尝试，但由于超出本文范围的原因，由一名新经理管理应届毕业生进行，未能重建老团队的能力。

正如我们之前看到的，一个高效团队很难组建，因为团队中存在的机构知识以及团队文化，但摧毁一个团队却非常容易。

有趣的是，如此多的高管职位的人坚持认为他们可以像在《文明》游戏中打开城市视图并将工人从一项任务重新分配到另一项任务那样轻易地调动人员，而我交谈过的资深个人贡献者在预测这类调动何时会失败方面具有很高的准确性。

附录：相关文章

• 约西·克雷宁论薪酬与项目/人员匹配度
• 我关于获取机构知识的困难
• 詹姆斯·C·斯科特论可理解性

由 mimo-v2.5 模型翻译，花费 10856 tokens

公司影响员工行为的三大工具是激励机制、流程和文化。人们谈论这些概念时往往指代不同含义，因此我将分别举例说明，以确保理解一致（若你认为某个概念应使用其他词汇，可自行在心中替换）。

• 让员工准时参加会议

  • 激励机制：迟到者扣工资
  • 流程：迟到者不得进入会场
  • 文化：员工高度重视准时到场

• 推动员工构建复杂系统

  • 激励机制：将系统复杂度作为晋升考核标准
  • 流程：制定繁琐的工作项创建/执行流程，迫使员工放弃简单工作
  • 文化：员工乐于构建复杂系统，且/或因此获得同行尊重与地位提升

• 避免生产缺陷

  • 激励机制：按合格品计酬，次品扣工资
  • 流程：出货前设置质检环节，剔除次品
  • 文化：员工崇尚卓越品质，竭力避免缺陷

若阅读"老派"思想领袖的著作，许多人倡导纯文化方案。例如肯·汤普森主张降低缺陷率的关键不在工具（本文将流程称为工具），而在于员工有意识地主动避免编写缺陷；或如鲍勃·马丁所言"解决软件危机的方法不是更多工具，而是更严谨的编程纪律"。

这类夸张言论引发的情感反应，与其易于反驳的特点，共同导致了对文化解决方案的反弹。人们开始声称"绝不应强调纪律，而应审视底层系统的激励机制"——正如十倍效率程序员现象及其相关评论引发反弹，导致人们宣称开发速度完全无关紧要，或程序员间效率毫无差异（正如杰米·布兰登所指出，开发速度很大程度上取决于对此的重视与投入，这同样是文化反弹的表现）。

但若观察量化产出，即便流程和激励机制是公司首选的一线工具，文化仍会产生重大影响。以制造缺陷率为例：某些国家长期保持低于他国的缺陷率（时间跨度达数十年）¹，且这种优势通常普遍存在于企业间——即使公司在多国运营工厂，并尽可能导入相同流程与激励机制，文化差异仍会深刻影响工作方式。

回到编程领域，杰米在"提升速度"的笔记中写道：

最关键的改变源于真正渴望提升速度。

早期我确实更关注编写"优雅"代码或使用流行工具，而非解决实际问题。这或许并非明确信念，但行动已清晰反映优先级。

我可能未曾意识到速度提升的巨大空间。职业生涯初期，我与同样缓慢且缺乏经验的同事共事。

逐渐地，我注意到有些人能产出我终生难以企及的项目。我渴望探寻实现之道，这意味着必须放弃既有观念，探索真正有效的方法。

我很幸运在职业生涯初期拥有相反体验：我的第一份全职工作在Centaur公司（当时该公司拥有极高的开发速度/生产力）。我曾在其他团队体验过类似效率，即我目前的团队——但这在科技公司中相当特殊（例如我们团队的中位数职级是"高级专家"）²。在高效公司开启职业生涯的副作用是：我通常认为大公司开发节奏缓慢，且不接受"行业常态"作为缓慢的理由。我与大公司同行交流时经常听到类似评论，这些人曾在功能正常但速度并非顶尖的初创公司工作过。某家顶级科技公司的定期调研会问："你感觉当前开发速度比上一份工作更快还是更慢？"回答呈现双峰分布——取决于受访者来自小公司还是大公司（该公司开发速度慢于初创企业，快于大企业）。

有个故事（据我回忆由布莱恩·恩诺斯讲述）：他进行限时训练时，原本目标是在习惯时间内完成特定任务。但他迟迟无法达到习惯时间，因比平时缓慢而感到沮丧，于是持续练习直至达成目标——此时才发现自己误记了目标，实际在挑战自以为不可能的新纪录。虽然"心想事成"过于简化，但我们几乎无人发挥出接近自身极限的能力，而自我设限往往是主要瓶颈。诚然，开发速度与质量存在权衡，速度无法"免费获得"。但就编程而言，我们远未达到帕累托前沿，只要意识到优化空间存在，就能实现零成本提升。

文化对此的影响方式之一：人们往往从所处环境中吸收对可能性的认知。非速度案例：我注意到参与RC（Recurse Center）后，许多在Deconstruct和Strange Loop等知名非学术/非企业技术会议演讲者都曾就读RC。多数人在参加RC前未做过演讲，当我询问时，许多人表示渴望演讲却不知成为"大型"会议演讲者的过程如此简单（形成想法→记录想法→将记录提交为提案）。实际上在会议演讲很简单，主要障碍在于认知可行性。在RC这样的环境中（大量人演讲，犹豫者会被告知流程简洁），许多人最终会走上讲台。博客写作同理，因此高阅读量的编程博主中，有超常比例是在RC学习后开始严肃写作的。对许多人而言，开始博客的障碍在于认知可行性，并意识到从技术层面讲，只要选择合理工具链并完成设置，创建博客极其简单。正因人们频繁演讲和写作，他们在这两方面持续进步，因此RC学员平均而言很可能比普通程序员更擅长演讲与写作，尽管RC几乎不进行技能转移或教学。

文化能显著驱动的另一类技能是高度依赖态度的技能，例如调试。正如茱莉亚·埃文斯指出，良好态度是调试效能的关键要素。Centaur在这方面非常擅长培养员工，以至于该公司技术部门几乎所有人都算得上优秀的调试者。

大公司常见现象：员工在数次无效尝试后就放弃调试。某中型科技公司的熟人曾告诉我，调试耗时超过数小时的缺陷毫无意义，因为工程师时间太宝贵——这种态度源于其首个团队的工作环境。形成此类调试态度者，在转变观念前很难成为优秀调试者。许多人（包括这位熟人）会长期保留第一份工作形成的态度和习惯³。

以科技行业标准衡量，Centaur是反向极端案例。设计CPU时，不允许放弃未理解的缺陷。即使缺陷症状不严重，底层原因可能危及重大隐患（芯片出货后才会显现），因此必须追查看似微小的问题。此外，缺陷常无可靠复现步骤，典型描述如"在特定系统运行这些程序，数小时或数日后系统将挂起/数据损坏"。调试此类缺陷会遭遇无数歧途和死胡同，某些可能耗费数周甚至数月。作为新员工观察这类工作，我看到同事们日复一日追踪缺陷，既不沮丧也不放弃。当这种文化氛围环绕，你自然会形成相同态度。许多实用调试技能源于大量问题的实践积累，这自然产生于持续积极调试（尤其接触高难度问题时）。

当然，大公司的多数缺陷不值得投入数月时间，但存在本质区别：某些缺陷确实不值得修复而主动搁置，与因从未调试严重缺陷导致技能低下，进而无法处理非平凡问题。

文化态度能驱动远超个体技能的影响。Centaur人均严重生产缺陷率远低于我任职过的所有公司（约100名工程师，年缺陷率远低于1次）。相比之下，我从未在规模仅其十分之一的团队工作过，其严重生产问题发生率却高出十倍以上。如同多数初创公司，Centaur流程极简，激励机制也比大公司宽松得多。

其构成要素之一是"问题归属文化"：无论身处何团队，发现任何问题都会主动修复；若问题有明确负责人，则会通知对方解决。无需路线图、站会、看板或其他机制推动员工处理关键问题，员工自发行动无需提醒或催促。

这与我在三家大公司中两家的见闻截然相反：中位数员工如同躲避瘟疫般规避团队职责外问题；政治敏感度低的员工向其他团队提出问题，常得到"抱歉，本季度路线图未涵盖，或许下下季度可纳入"的回应——数月后天真者再提同样问题，仍会得到相同答复。在我任职过的所有大公司中，因无人愿接手，价值巨大的严重问题常被遗漏。这种情况在Centaur从未发生。

大公司技术文化的副作用是：愿意做正确之事者，只需解决任何实习生都能处理的问题（若愿无视组织流程和激励机制），就能产生极高（正面）影响。随手都能发现价值超过我终生预期收入的问题，且每年轻松解决多个此类问题。当然，导致大量琐碎问题被忽视的同一股力量，也使解决者得不到应有回报⁴。

相反，在Centaur的八年里，我仅发现一个琐碎问题的修复价值超过我的终生预期收入，因为问题通常在此之前已得到解决。我见过多家大公司尝试用激励机制（如奖励解决重要问题）和流程（如创建约1000个项目的巨型清单，由专人排序，并建立官僚体系：所有人需通过JIRA持续汇报进度，以便项目经理向统筹数千工程师工作的决策者发送进展更新⁵）解决此问题，但效果均不及"主人翁文化"的一半（公平地说，有消息称Facebook运用激励机制效果显著，但我三次未通过其面试，因此未能亲身观察）。

导致相对低严重缺陷率的另一要素是：Centaur全公司普遍重视品质，这种程度在大公司连团队层面都罕见。当一群重视品质且认为"任何问题都该解决"的人协作，品质自然产生。员工入职时，只要文化不被新人潮压垮，他们也会逐渐吸收相同习惯和价值观，尤其应届毕业生。尽管不普遍，但确实存在众多保持卓越文化的小型公司，无需重型流程或高额激励即可维系——这在大公司行不通，因为它们都经历过快速增长期，无法维持这种（以主流标准衡量）极端的文化价值观。

迄今为止，我们主要讨论公司如何向员工传递文化，但我认为同等重要的是员工离职后如何传承这种文化。我从硬件转向软件领域后相当成功，我认为在可控因素中，最关键的是从首个全职工作中习得高效文化价值观，并持续以相同方式实践。我见过其他在职业上"成长"于卓越文化的人，在转向技能转移度更低的领域后（如从滑雪转向土木工程）仍保持高效。类似地，阅读高效领域从业者的著作（如布莱恩·恩诺斯的《实用射击》、丹·瑟林的《制胜之道》等），书中往往包含相同核心理念（严肃观察与技能提升、避免情绪自我破坏的重要性、直觉的重要性等）。

总之，我认为文化和技能的代际传承是择业时被低估的因素（我认为被高估的因素包括声望和总体声誉）。人们应审慎选择所处文化环境，因为很少有人能完全避免吸收周边文化价值⁶。

尽管本文聚焦技术领域，但此现象并非技术行业独有。典型例证是理想主义学生进入法学院时意图从事"拯救世界"类型工作，随后吸收周围学生声望传递的文化价值观，转而追求最光鲜职位——若非法官助理，通常是"顶级律所"工作，与"拯救世界"背道而驰。理论上每个人都认为"这不会发生在我身上"，但观察许多人加入最初极不认同其价值观与文化的组织后，几乎无人能保持原状而不吸收周边价值观；极少有人能坦然面对他人因自身价值观而投来的异样目光。

附录：湾区文化

我欣赏湾区的一点是其改变世界氛围的感染力。在我生活过的地方，人们都会抱怨问题（抵押贷款行业糟糕，卖房流程繁琐等）。在湾区外，抱怨仅止于抱怨；但在湾区，与一年前抱怨某事的人交谈，很可能发现他们已创业尝试解决所抱怨的问题。我不认为湾区居民与他处之人有本质差异，更关键的是当你周围都是愿意辞职颠覆传统行业的人时，效仿似乎相当合理（这还产生网络效应，从"技术"层面（如融资）降低难度）。这类抱怨和修复尝试蕴含的真诚易遭嘲讽，但我由衷敬佩这份真诚。

当然，湾区文化并非全然积极。除其他特点外，湾区有著名的"放鸽子"文化，程度令我初至时震惊。抵达不久后，我约老友晚餐并短信告知将迟到约15分钟。出现时他们大为惊讶，因他们认为"告知迟到"实际意味着"不会到场"（更令我惊讶的另一个极端规范是：对许多人而言，活动开始前未确认计划即视为取消，即计划默认取消）。

我听闻有人抱怨的另一相关规范是：管理层和领导者为避免冲突，在"讨好型"决策中对所有事都答"是"。这实际增加冲突，因为那些将"是"理解为"同意"而非"我说是为避免说不但实际并非如此"的人，事后发现"是"实为"否"时会大失所望。

附录：Centaur的招聘流程

当我谈及Centaur时，人们常有的评论是：该公司必然拥有极其严格的招聘流程才能招募精英工程师。但其招聘选择性远低于我工作过的任何"知名品牌"大公司（谷歌、微软和推特），且未必比我任职过的老派传统公司（IBM和美光）更严格。"独门秘诀"在于入职培训而非招聘。

应届生招聘方面（我们按比例招聘大量应届生），招聘难度高于我任职过的任何公司。资深岗位招聘并不困难（Centaur在奥斯汀本地声誉良好），但应届生中无人听闻我们且无人愿加入。我在招聘会招人时，需站在展位前拦截过路者才能获得交流机会。这意味着我们无法挑剔面试者。在杰夫·阿特伍德通过其极具影响力的文章《程序员为何不会编程？》普及"存在大量伪造程序员"观念（认为不通过基础编码题筛选就会招到不会编程的程序员）前后，我们开始大规模招聘应届生（下文加粗部分为其原文）：

任何所谓程序员在申请工作时无法编写最简单程序，这令我震惊。这是对以编程为业者的公然侮辱。 ... 如此严苛的预筛选竟只为获得面试真正能编程的程序员的奢侈，可悲又可叹

由于我们是偏重编码的硬件团队（验证工程师主要编写软件，设计工程师编写大量工具），我们尝试让应聘者根据斐波那契数列描述编写函数（允许朴素解法，不要求线性时间或更快算法）。但因无人能独立完成，需全程逐步引导，此问题对我们毫无区分度，故而废除。

尽管未真正考察编码能力，员工仍能编写复杂并发代码（内部处理器微码，常使用屏障作为并发控制机制），并以更快速度和更低缺陷率创建工具——速度与质量皆优于我任何其他工作经历。

放弃常规招聘方式对我们更有利，因为我们得以尝试雇佣其他公司不争抢的人才。若其他公司采用高效方法（如考察FizzBuzz编码和白板算法），这将毫无意义。虽然可能预期算法面试能筛选出能解决面试特定问题的人，但事实并非如此。我们还大幅降低声望门槛，从而招募其他公司甚至不会考虑的优秀工程师。

确实有少数人不适应，但从未出现"无法编写最简单程序的所谓程序员"。我确知两起雇佣无法编程的"伪造程序员"案例，均发生在拥有科技公司最严格编程面试的知名企业。一例中，此人能力不足的情况很快暴露，团队回查面试监控录像才发现代面试者并非入职者。另一例中，此人瞒过谷歌数年才被发现从未实际编写代码，任务完成均依赖他人。最终发现问题者安排结对编程环节，发现此人无法编写循环语句，甚至分不清=和==的差异——尽管他在谷歌"高级软件工程师"（L5/T5）职级任职多年。

我不否认编程题可能避免雇佣伪造程序员，但伪造程序员出现率极低，小公司十年不编程题也可避免；而大型诈骗目标公司即便编程题筛选仍难幸免。

附录：文化移植

尽管本文探讨公司文化对员工的影响，员工自然也会影响公司文化。招聘中（尤其高级领导者和高级独立贡献者）易被低估的是他们将带来的文化冲击。我多次近距离和远距离观察到：新聘高级人员成功移植与现有企业文化不兼容的自身文化，导致严重问题及高离职率——这通常发生在整合期后。

因资历渐深，我参与过多次高级职位招聘讨论，从未见他人提出候选人是否移植不兼容文化价值观的问题——除非明显问题（如候选人性情暴躁或发表种族/性别歧视言论）。

感谢彼得·巴特·哈金斯、劳伦斯·特拉特、朱利安·斯夸尔斯、安雅·博斯科维奇、陶·L、贾斯汀·布兰克、本·库恩、V·巴肯汉姆、马克·帕帕达基斯和杰米·布兰登的评论/修正/讨论。

由 mimo-v2.5 模型翻译，花费 13329 tokens

我不知为何这个例子一直留在我的脑海里，但对我来说，别人认为我愚蠢最令人难忘的例子来自大学时期。我有过很多次更多人认为我愚蠢、也有人认为我的愚蠢程度更深的情况，但这个例子对我真的很难忘。

大学时，有一群人，不管什么原因，在我看来是真正不理解课程内容的人。他们说话时表达的内容毫无意义，在课堂上挣扎，勉强及格。我不记得有过直接互动，但有一天，一个同样认识他们的朋友对我说："你知道[那群人]认为你真的很笨吗？"我觉得很有趣，就问为什么。原来原因是我问的问题听起来非常愚蠢。

特别是，经常有这样的情况：存在一个看似明显但实际上是错误的理由来解释某事为何成立，一个稍微不那么明显的理由解释某事看似不成立，然后是一个微妙而复杂的理由解释某事实际上为何成立²。我经常会发现那个看似明显的理由是错的，然后提出一个问题试图理解那个更微妙的理由，这对那些认为明显理由正确、或者认为推翻了那个明显但错误的理由就意味着此事不成立的人来说，听起来很愚蠢。

在大多数特定情况下，问一个听起来愚蠢的问题所带来的好处很小，但随着时间的推移，复利效应带来的好处非常大，而且我观察到，那些愿意问愚蠢问题、思考"愚蠢想法"的人最终对事物的理解会深刻得多。相反，当我观察那些对某个主题有非常深刻理解的人时，他们中的许多人经常问一些天真得听起来的问题，并继续运用那些让他们获得深刻理解的技巧之一。

我想我最初通过高中时玩竞技电子游戏，确信了我认为是这一潜在现象表征的事情。那时在线玩电子游戏的人很少，你基本上能认出所有玩同一款游戏的人，并能看到每个人进步了多少。就像我几年前尝试重玩电子游戏时看到的一样，大多数人在游戏中"死亡"时会责怪外部因素（延迟、运气、故障、队友、不公平等）。最引人注目的是，那样做的人几乎永远无法变得厉害，也永远无法变得伟大。我玩那款游戏玩得相当不错³，我的"独特技巧"是每次出错时都思考哪里出了问题，然后尝试改进。但大多数人似乎对找个借口避免当下显得愚蠢（或者可能感觉愚蠢）更感兴趣，而不是真正去改进，这当然导致他们在游戏中显得愚蠢的时刻更多。

总的来说，我发现甘愿显得愚蠢非常有效。这里还有一些例子：

• 走进苹果商店，要求（并购买）装在最小盒子里的电脑，我当时有充分的理由想要它
• 帮助我的店员虽然非常有礼貌，但也明显认为我是个傻瓜，并不断解释诸如"盒子的大小和电脑的大小不一样"之类的事情。我当然知道这一点，但我不想说"我设计CPU。我理解电脑包装盒大小和电脑大小之间的区别，我也知道关心盒子大小非常不寻常，但我真的想要那个装在最小盒子里的"之类的话。仅仅说最后一部分，在没有建立任何权威性的情况下，并不能说服那个人
• 我最终请他们将就我一下，把不同型号笔记本电脑的盒子都拿出来让我看看，他们照做了，尽管显然认为我的决策过程毫无道理（我也尝试解释为什么我想要最小的盒子，但那也没用）
• 新冠疫情：我很早就认真对待，并在2020年1月26日购买了半面罩呼吸器，在此之前一周已经在使用手头已有的N95口罩（在我看来，基于现有的SARS接触者追踪、空气过滤器过滤病毒以及病毒载量的文献，认为新冠是空气传播且空气过滤会有帮助的证据非常充分）
• 直到几个月后，人们才普遍不把我当作傻瓜看待，甚至在2020年8月，我偶尔还是会遇到一些人当面嘲笑我
• 另一方面，当时和我同住的人不想戴我给她弄的口罩，因为她觉得在无人乘坐BART（旧金山湾区捷运系统）或无人在创客空间时，为了往返创客空间的1小时BART行程而戴口罩太尴尬了。她成为旧金山湾区早期的新冠病例之一，这让她患上了长期新冠，卧床数月
• 当她感染新冠后，我试图说服她，她应该告诉她常去的创客空间的人她感染了新冠，这样他们就知道自己暴露了，可以采取适当的预防措施以避免意外传播新冠，但她也觉得承认自己可能把新冠传播给别人太尴尬了（回想起来，我应该直接打电话给创客空间告诉他们）
• 一个半相关的事情是，当加拿大开始接种疫苗时，我想打Moderna（莫德纳疫苗），尽管网上和我的社交圈里的普遍共识是Pfizer（辉瑞疫苗）更受欢迎
• 其中一个原因是，尚不清楚政府是否会允许混合接种疫苗，而且交付计划表明，第二剂Pfizer将非常短缺，而Moderna则供应充足
• 另一个闪过我脑海的想法是，Moderna基本上比Pfizer"成分更多"，在某些情况下可能提供更好的免疫力，就像某些人群接种高剂量流感疫苗以获得更好免疫力一样
• 工作：我通常不担心提案或行动显得愚蠢
• 我依然记得我第一次明确遇到这种情况。那是在我职业生涯早期，当时我从事芯片验证工作。在流片前不久，验证主管希望用我们的计算资源重新运行一组几乎不可能发现任何错误的测试（这些测试之前已经运行了数千次），而不是运行通常的测试组合（其中包括很多新生成的测试，这些测试发现错误的几率要高得多）。我争辩说我们应该运行那些能降低发布带有致命错误的产品的风险的测试（这会让我们损失数百万美元并延迟发布三个月），但小组负责人说，如果有错误能通过我们上次运行过的那些旧"金标准"测试捕捉到却漏掉了，我们会显得愚蠢和无能
• 当时我很震惊有人会为了减少可能显得愚蠢的几率（而且，实际上只是在那些不理解运行最佳可用测试组合逻辑的人面前显得愚蠢；因为管理层中没有任何非技术人员，任何称职的人都应该理解这个推理）而故意做错事，但现在我在多个行业的各种公司工作过，我看到大多数人会选择做错事，以避免在不称职的人面前显得可能愚蠢。我理解其中的逻辑，但我认为这样行事是自我破坏，而且我职业生涯中因坚持我认为正确的事情而获得的收益如此巨大，即使未来十次我这么做都不走运且没有成功，也无法抹去过去多次做正确事情所获得的收益
• 空气净化：我研究了一点空气质量对健康的影响，并于2012年为我的公寓购买了空气净化器
• 多年来朋友们一直因此调侃我，陌生人、约会对象和熟人有时会以不同程度的直白告诉我，我是在偏执和愚蠢
• 当我搬到野火风险较高的地区并研究了野火风险后，我增加了更多的空气净化能力，这导致人们以更高的频率和更直白的语气告诉我，我有空气净化器很奇怪
• 尽管经历了相当严重的野火季节两次，但我基本上完全没受野火影响
• 我认识的其他人则经历了一定程度的不适，有几个人在烟雾暴露后出现了持续性问题（其中一例是持续性哮喘，之前没有或至少之前没注意到）
• 学习对我来说困难的事：这是一个"感觉愚蠢"而非"显得愚蠢"的事情，但当我在某件事上挣扎时，我感觉自己真的很笨，就是说，我有一种感觉/情绪，我会用语言描述为"感觉很笨"
• 当我比较年轻的时候，我想是在青少年之前，我注意到当我学习困难的东西时会发生这种情况，并试图将这种感觉视为"学习某事的感觉"而不是"感觉很笨"，这起到了一半的作用（我现在将这种感觉与两者都联系起来）
• 提问：上面已经提到，但我经常在遇到不理解或不知道的事情时提问，从基础的东西，"某个词是什么意思？"到更微妙的东西。
• 另一方面，我看到初级工程师最常见的失败模式之一，就是有人因为害怕显得愚蠢而不敢提问，结果学习非常缓慢；在某些情况下，这严重到导致他们被置于绩效改进计划（PIP）然后被解雇
• 我确信还有其他原因会导致这种情况，比如不想打扰别人，但在那些我足够了解情况可以去问的案例中，总是因为尴尬和害怕显得愚蠢
• 我在指导实习生和初级人员时，会小心避免这种失败模式，并且通常很成功，但有时需要长达六周的时间才能说服他们提问是可以的，在那之前，我必须经常问他们进展如何，以确保他们没有卡住。如果那个人是我的实习生，这没问题，但我观察到许多指导实习生和新员工的导师并不这样做，这常常导致各方结果不佳
• 几乎每个案例中，那人都至少在其他公司实习过，但他们没有学会提问是可以的。附注：如果你在一个不允许提问的地方工作，并且情况允许，你应该另找工作
• 不为失败找借口：在电子游戏部分已经提到，但适用范围更广
• 学习时，刻意在成功与失败之间的区域摸索（这也适用于电子游戏、体育运动以及抽象的智力追求）
• 一个例子是，在学习攀岩时，反复以各种方式尝试同一个简单的动作，以理解什么方式效果更好，什么方式效果更差。我曾遇到陌生人嘲笑我，甚至指着我对他们的朋友说风凉话
• 学习开车时，我想设置一些锥桶，然后开车勉强撞上它们，以了解汽车的边缘在哪里。我父亲认为这个想法非常愚蠢，我应该只是不撞到东西，比如路缘石或锥桶
• 汽车保险：我上次购买汽车保险时，不得不确认三次我只想要为对他人造成的损害投保，不覆盖如果我方责任造成的对我自己车辆的损害。保险代理人每次都忍不住用看傻瓜的眼神看我，每次确认时都变得更加难以置信
• 本网站的样式和内容：我经常收到设计人员和字体排印师告诉我设计有多愚蠢，通常在我与他们互动时，很快变得居高临下
• 但是，当我测试从广受好评的Octopress设计切换到当前设计时，这个设计在用户访问网站时获得了更好的互动效果，而且似乎也被更多地传播了
• 当我将自己的流量数据与大型企业博客进行比较时，我的博客完全主导了大多数市值低于1000亿美元的公司（例如，它的流量比雇主的博客高出一个数量级，而我的雇主是一家市值500亿美元的公司）
• 当我开始写博客时（今天依然如此），关于编程博客的写作建议是保持简短，也许500到1000字。我的大多数博客文章是5000到10000字
• 接受我现在的工作，几乎所有人都认为这是个愚蠢的主意
• 密切相关：辞去在Centaur的工作去参加RC，然后最终转行进入软件领域（我认为现在这不会被认为是愚蠢，但在2013年，这被认为是非常愚蠢的事情）
• 学习一项运动或电子游戏：我尝试事物以了解当你做它们时会发生什么，这常常导致当该动作看起来很蠢时，别人认为我是个彻底的傻瓜，但愿意显得愚蠢帮助我相对快速地进步
• 医疗保健：我发现很多医生对自己的意见非常自信，如果你不同意，他们会很快变得居高临下
• 然而，在最极端的情况下，如果我听从我的医生，我会死；在次极端的情况下，我会失明
• 抽血时，我会向人们解释我的血管很难扎，并告诉他们过去什么方法有效
• 大约一半的时候，护士或抽血师会认真对待我的评论，通常能顺利且无痛或几乎无痛地完成抽血
• 大约一半的时候，护士或抽血师会用看傻瓜的眼神看我，并对我进行愤怒的和/或居高临下的评论；到目前为止，所有这样做的人要么未能抽到血，要么给我留下了血肿
• 有人告诉我说我陈述偏好的方式可能具有冒犯性，我应该更有礼貌；然后我邀请他们一起观察，但没有人提出建议让我如何以不同的方式陈述以获得更高比例的正面回应；总的来说，当人们看到护士和抽血师的反应时，他们都感到震惊和不快
• 回想起来，我大概应该在有人出现"糟糕"反应时就起身离开，这可能会增加那个人认为我愚蠢的感觉
• 我遇到的一个问题（不是导致"扎针难"的主要问题）是，在抽血过程中，血液会减慢然后通常停止。有些护士喜欢晃动针头看看是否能重新开始流动，这有时有效（大约50/50），但通常会给我留下一大片淤青或血肿，或者两者都有。这种情况发生过几次后，我问是否在抽血前通过大量活动让血液流动（例如在抽血前多活动）会有帮助，我问过的每个护士或抽血师都说那很傻，不会有任何区别。我还是试了试，这解决了这个问题，虽然我仍然存在很难正确扎针的问题
• 面试：我在面试中通常不会对抗，但我会尽量说出我认为真实的事情，并尽量避免说我认为虚假的事情，这经常导致面试官认为我很蠢（我面试的失败率通常相当高，所以谁知道这是否相关，但当你说了"愚蠢"的话后，有人用看傻瓜的眼神看你，或者开始用居高临下的语气和肢体语言，这似乎是个坏兆头）。
• 通常努力改进事物并保持真诚
• 甚至在"tryhard"（过分努力的人）成为贬义词之前，我社交圈里的很多人就认为做个"tryhard"是愚蠢的，一个人不应该努力，而应该装酷（这是在我成为工程师之前；作为一名工程师，我认为努力受到的尊重比我学校同学和当时我认识的网友都多）
• 通常承认自己在某些方面能力不足或没天赋，例如，在这篇文章中提到我学习编程很吃力；Jane Street的一位面试官深入探讨了我在那篇文章中写的内容，并因此对我大加抨击（这是我经历过最具敌意的面试，差距很大），当你真诚地表达自己时，有时会发生这种事情，但我仍然认为好处大于坏处
• 招聘：我有一个非传统的招聘说辞，坦率地先说缺点，经常导致人们说我是一个糟糕的招聘者（或者讽刺地说我是一个优秀的招聘者）；我还没有公开写下这个说辞（目前还没？），因为它负面到我担心把它放到网上会被解雇
• 我从未在招聘全职员工上失败过（有一次在招聘实习生上失败过），并吸引了很多原本不会考虑为我们工作的人。我的招聘说辞听起来可笑地愚蠢，但它比大多数人使用的标准招聘说辞有效得多
• 在互联网上发布内容：不言自明

尽管上面的大多数例子是"现实生活"中的例子，但甘愿显得愚蠢在工作中也非常有效。除了它能让你学习更快、变得更高效的明显原因外，它还让你更容易找到高投资回报率的想法。如果你追求时髦或听起来合理的想法，想要做一些真正非凡的事情，你必须比处理同一问题的其他人有更好的想法/执行力。但如果你思考的想法大多数人都认为太愚蠢而不予考虑，你经常会遇到既具有高投资回报率又简单易行的想法，只要他们不一开始就否定这个想法，任何人都能做到。从技术上讲，你仍然可能需要比尝试同样事情的其他人有更好的执行力，但如果没有人尝试同样的事情，那就很容易做到了！

我实际上不必像大多数人那样聪明或努力工作就能取得好结果。如果我尝试通过做其他人都在做的事情来解决某个问题，并去其他人寻找问题的地方寻找问题，如果我想要做一些有价值的事情，我必须比很多人做得更好，甚至可能比所有人都更好，如果问题非常困难的话。如果问题被认为很时髦，很多非常聪明和勤奋的人会探索同一领域，要做得比他们更好非常困难。但如果我有一个愚蠢的想法，一个听起来太蠢以至于没人愿意尝试的想法，我就不一定需要特别聪明、有天赋或勤奋就能想出有价值的解决方案。通常，愚蠢的解决方案是任何白痴都能想到的，而问题之所以没有解决，是因为没有人愿意思考那个愚蠢的想法，直到像我这样的白痴看了这个问题。

总的来说，我认为甘愿显得愚蠢的好处远大于坏处。对于那些不涉及社会评判的事情，比如赢得游戏、理解事物、或者由于有良好的理解而能够构建事物，这全是好处。对于涉及社会评判的事情，比如面试和约会，可能存在坏处，但即使在那里，我认为很多看起来像坏处的事情实际上是好处。

例如，如果一个约会对象因为我不知道一个词的意思而认为The request was rejected because it was considered high risk

由 mimo-v2.5 模型翻译，花费 12483 tokens

很久以前，一位年长的知名数论家对Paul Erdős的工作发表了些轻蔑评论。我和你一样钦佩数学贡献，所以听到那位数学家断然宣称Erdős的所有成果都可归结为几个反复使用的技巧时，我颇感恼火。但这位数论家没意识到，其他数学家——即使是最优秀的——也依赖几个反复使用的技巧。以希尔伯特为例。其论文集第二卷收录了他在不变式理论方面的论文。我曾仔细研读其中部分论文，令人惋惜的是，希尔伯特一些精妙成果已被彻底遗忘。但细读其在该领域深刻定理的证明时，我惊讶地发现希尔伯特的证明同样依赖相同的几个技巧。连希尔伯特都仅有几个技巧！

观察各领域的成功者，会发现这是普遍做法。例如，一项关于世界级柔道选手的分析发现，大多数人依赖少数几种投技，并得出结论¹：

柔道是专精的竞技。你必须使用最适合自己的技能。你必须坚持有效的方法，反复练习直至成为条件反射。

若观看格斗题材的动画或电视剧，角色常通过增加招式数量来提升实力——因为这在视觉上容易表现。但现实中，精进已有技能往往比掌握数百种“招式”更有效。

Joy Ebertz 也曾提及：

我曾得到一个建议：放大自身优势。人人都有优缺点，我们常把大量时间耗在“改进领域”上。人们容易认为最好的进步方式是消除所有弱点。但若某些方面确实薄弱，改变它们可能事倍功半。显然，你仍需确保没有真正糟糕的缺陷。但除此之外，应聚焦于放大优势。如何将你擅长的事物转化为超能力？

个人在多个领域验证了这一点。尽管难以客观衡量程序员效能，但在我从事过的某些事（例如很久以前、电竞尚无“真正”奖金时的竞技游戏）中，让我从还算不错的玩家进阶为顶尖玩家的关键，正是放弃练习不擅长的领域，全力提升那些我天赋异禀技能的优势。

这种方法在游戏和运动中有效，因为你可以通过策略将自己置于优势位置，避免暴露弱点。我认为在工作中这甚至更有效，因为在竞争环境中，对手会试图攻你弱点、迫使你远离优势领域。而工作中，假如我研究排队论而非编译器，同事不会阻止我参与排队论相关的项目，强迫我面对全是编译器知识的应用场景。

值得注意的是，技能不一定是通常认为的学科或离散技术。过去三年，我主要应用并提升的技能或许可称为“数据分析”——加引号是因为我找不到确切术语。我不认为这是多数人理解的“统计学”，因为我无需像逻辑回归那么复杂的方法，更不用说高深统计。或许有人认为这是数据科学家的工作，但对比我们雇佣的数据科学家实际工作内容和面试要求，我们似乎并不想招聘具备该技能的数据科学家，他们也不做我正在做的事（这个话题足够长，可能另写专文讨论）。

与 Matt Might 或 Steve Yegge 不同，我不会断言你应该采取特定方法，但可以说：专注少数领域、不刻意追求面面俱到，这种方法在多个截然不同的领域对我有效，对许多其他人似乎也管用。

若采用此法，仍需决定学什么技能。这是我最常被问的问题之一，我的答案可能非所期望、也不令人满意，因为它既显而易见又难以实践。

对我来说，决定学什么的两个要素是：具备相对天赋（相对于我可能做的其他事，而非与他人相比），以及拥有适合学习的环境。说“应寻找这些”过于模糊近乎无用，但仍比常规建议（即“学我所学”）更实在——后者常导向“职业建议：若想精通大规模真实环境中的复杂有状态分布式系统设计，应学函数式编程，因为技能集几乎完全一致”之类论调，或某些语言社区更极端的主张，比如Chuck Moore声称Forth的生产力至少是无聊语言的100倍。

职业生涯早期我采纳了泛泛的网络建议（包括语言建议，当时这类建议尚不成熟，无法轻易观察到：遵循此类建议的人往往效率平平，而高效人士通常不采纳这类建议）。我学了Haskell、Lisp、Forth等语言。职业生涯某阶段，我在两人团队中实现了可能是当今性能最高的Forth处理器（2GHz IPC导向），并为其编程（该处理器适合栈式架构，Forth是合理选择）。如同Yossi Kreinin，我认为自己投入的精力超过大多数人掌握Forth的水平；但和他一样，我不仅未发现其生产力达百倍，甚至不清楚是否真有1倍优势。公平地说，某些工具的生产力超过1倍，但总体而言，我认为追随网络建议的投入产出比很低，而那些高回报的技能并非人们推荐的内容。

回顾来看，当有人说“Forth生产力很高”时，我怀疑其真意是“Forth让我很高效，但我未考虑这如何适配不同天赋或不同环境的人”。Forth（或Lisp、Haskell等任何工具技术）对特定个体确实有效，但人们常高估“它对我有效”与“它对他人也有效”的关联性，导致建议通常无用，因为它未能区分天赋或情境特定的建议与普适性建议，这与真正讨论具体技术优劣的领域形成鲜明对比²。

教练可通过一对一或小组形式提供个性化建议，但互联网上难以做到，因此我能做的只是无用的模糊建议：“选择适合你的技能”。例如，对我来说容易掌握的两项技能是“具备对抗性思维”和“数据分析”。或许稍有用的建议是：若难以识别这些技能，可询问非常了解你的人——例如我的经理和Ben Kuhn不约而同指出，“提出跨越多个抽象层次的解决方案”是我常运用的技能（在他们点明前，我未意识到这点）。

另一种方法是寻找那些你情不自禁去做、而他人似乎不做的事。对我而言，“数据分析”和“对抗性思维”皆如此。以对抗性思维为例：我曾参与某公司定制Bug跟踪系统的测试，提交了首批Bug并在字段中填入异常值测试系统极限。有些人无法理解为何有人这么做，感到困惑、反感或惊骇，但少数人（包括作者们，我知道他们不会介意）很赞赏看到系统被推至极限。探索系统崩溃边界于我而言不像工作；若不想做，我必须刻意停止——这让十年来提升测试与验证技术的历程感觉像是“难以不做”之事。深入数据分析是我已坚持十余年的另一领域，对我来说，若不提升这项技能几乎感觉不对。

这些技能适合我，主要源于个人性格，而非人类共性。其他人会有不同的“感觉轻松/正确”的领域，这很好——倘若人人都热衷数据分析而无人建造事物，那将非常麻烦（尽管我认为数据分析平均而言被低估了）。

我尝试学习的另一要素是寻找适合学习与我技能匹配技能的环境。建议他人效仿听起来像无用的显而易见忠告，但根据我对人们选择团队和公司的观察，几乎无人这样做，因此讨论此事或许不全然无益。

一个典型反例：我偶然得知某位经理的团队流失了新转正的全职实习生。我询问此事，因为该经理通常善于留人、团队流失率低。原来实习生希望从事基础设施工作，但加入了该经理的产品团队，因为不知道可以要求匹配偏好的团队。经理知情后促成了转岗。此案例是双重打击：新员工既未尝试进入利于学习技能的环境，又加入了一家基础设施组织功能失调、设计与运维实践不佳的公司——使其在未尝试进入基础设施团队的前提下，更难学习相关知识。虽是异常糟糕的案例，但据我所见的典型情况，人们即便声称最渴望学习机会，其决策却很少带来良好的学习结果。

例如，Steve Yegge 曾指出：

大学候选人最常问的问题是：“贵公司提供何种培训或指导？” ……一位华盛顿大学受访者向我详述福特汽车的指导计划，福特显然将其作为面试宣传的一部分。[我略去细节，因其无关紧要。-stevey 3/1/2006] 该学生能惊人地复述细节，这不意外，因为候选人最关心的正是这点。

对我而言，幸运的是首份工作Centaur是培养测试与验证对抗性思维的理想环境。对比该验证团队的成就，其效率堪比其他公司用更大规模团队完成类似工作的同行项目，表明团队生产力极高——这使其成为绝佳的学习场所。

此外，我认为仅靠自学或遵循书籍/网络建议无法如此快速学习。真正擅长某事的人，其知识体量难以压缩成书籍，更不用说博文。体育领域中，优秀教练能逐步传达这类信息，但编程领域尚无类似机制，因此我认为提升学习效率的最佳途径是寻找充满专家的环境³。

对于“数据分析”，尽管在人们未真正重视数据的环境中工作使我技能大幅精进，但过去几年的进步速度更高——因为我能与精于理解数据局限性、且具备深厚领域知识的人交流碰撞想法。可以说，我在当前公司每年的进步超过以往十年。

或许应注意：环境（你日常生活的空间）具有局部性。我现雇主可能是我工作过的三大科技巨头中最不数据驱动的，但我的周边却是提升数据分析能力的绝佳环境，因为我相对多地与擅长数据的人（如Rebecca Isaacs）共事，相对少地与漠视数据的人协作。

本文讨论了若干策略及其价值动因，但我必须承认，向专家学习的动机并非创造价值。更多是因为我发现学习充满乐趣，且在某些领域，无论环境如何，我都渴望运用技能；向专家学习是如此美妙的乐事，难以抗拒。数十年实践下来，这确实有用——但我许久才意识到这点（且从硬件转向软件前，我完全不知此技能可迁移至新领域）。

许多职业建议围绕职业发展、成功或成长，常倡导设定长期目标或战略，其论点常类似“随机游走仅能在某方向移动sqrt(n)，而定向行走可移动n”。我认为这没错，但对许多人而言，该建议隐晦地低估了寻找适合领域的难度⁴，而我基本上通过试错完成此事。

附录：本文未详述的问题部分

一个未讨论的主要话题是如何平衡技能“层级”——从高层如“数据分析”，到中层如“贝叶斯多层模型”，再到低层如“打字速度”。这话题足够庞大，值得单独撰文，预计篇幅更长。目前可参考Gary Bernhardt关于相关主题的评论，我认为同样适用于此话题。

另一个未讨论的主要话题是选择较可能适用的技能。仅建议考虑学习有天赋的技能，而不思考适用性，过于天真。

但虽然容易挑出那些极难产生影响、赚钱或达成目标的技能（如“篮球”或“拳击”），在看似合理的技能间选择（如计算机体系结构与编程语言）则更困难。

但我认为，半合理技能只要与个体匹配，很可能高回报，因此在半合理技能中试错可行——尽管快速尝试的能力或许有帮助。

附录：相关博文

• Ben Kuhn论真正学习某事是何体验
• Holden Karnofsky论采用天赋优先而非职业路径优先的职业观，这类似于思考跨领域技能（如“数据分析”或“对抗性思维”），而不仅关注具体技能（如“编译器”或“排队论”）
• Peter Drucker论如何理解自身优劣势，从事与性情相符的工作
• Alexey Guzey论建议的有效性
• Edward Kmett关于如何思考学习的另一视角
• Patrick Collison论如何最大化有效学习并发现兴趣所在

感谢Ben Kuhn、Alexey Guzey、Marek Majkowski、Nick Bergson-Shilcock、@bekindtopeople2、Aaron Levin、Milosz Danczak、Anja Boskovic、John Doty、Justin Blank、Mark Hansen、"wl"和Jamie Brandon的评论/修正/讨论。

由 mimo-v2.5 模型翻译，花费 11084 tokens

我与密友们常讨论的话题是我们生产力中的瓶颈以及如何更快地执行。这与我在更广泛的社交圈中所见大相径庭，那里的人们常说速度无关紧要。在网上相关讨论中，我常看到人们更进一步，对此进行道德评判，声称试图提高速度、追求更高生产力或努力工作实际上是坏事（更多例子见附录）。

我看到人们认为生产力无关紧要（或实际上是坏事）的主要原因可分为三类：

• 做正确的事比快速做事更重要
• 做某事（X）的速度无关紧要，因为你花在X上的时间并不多
• 考虑生产力是坏事，你应该“享受生活”

我当然同意做正确的事很重要，但提高速度并不会妨碍你做正确的事。实际上，这两者相互促进，是彼此的力量倍增器。如果你善于选择正确的问题，强大的执行能力会变得更有影响力，反之亦然。

诚然，选择正确问题带来的收益可能大于提升战术执行能力带来的收益，因为前者的收益可能无限大。但提升战术执行能力也容易得多，并且这也有助于选择正确问题，因为更快的执行能力让你能更快地进行实验，从而帮助你找到正确的问题。

一个具体例子是我参与的一个量化车队机器健康状况的项目。该项目发现了许多严重问题（相当一部分主机正在积极破坏数据，或者存在会使尾部延迟增加超过两个数量级性能问题，或两者兼有）。问题严重到足以成立一个新团队来处理。

回顾起来，我最初量化问题的尝试注定失败，不可能真正奏效（或无法在合理时间内奏效）。我花了数周时间钻研那些行不通的想法，而能在“仅仅”几周后找到可行想法的关键部分，在于能够快速尝试并摒弃不奏效的想法。在之前某篇文章的部分内容中，我描述了这个过程中的一个小环节耗费了多长时间，结果有多人在网络评论中反对说这快得不可思议。

我觉得这有点好笑，因为我并非天生是高效的程序员。学习编程对我来说是真正的挣扎，我曾经在很长一段时间里都很慢（并且在那些我尚未练习的方面，我现在仍然很慢）。我的“独门秘诀”是我曾刻意练习，提升我经常做但大多数人没有刻意去提升的事情。我认为这种情况有点类似于人们真正开始科学训练之前的体育运动。很长一段时间里，许多运动员并没有认真训练，而一旦人们开始尝试训练，按现代标准来看，这些训练往往是错误的。例如，如果你阅读70年代的棒球评论，你会看到人们说棒球运动员不应该进行力量训练，因为这会使他们“肌肉僵硬”（许多人认为举重会导致“过多”的肌肉块，使人变慢、爆发力下降、敏捷性降低）。但今天，球员从使用增强肌肉僵硬程度的性能增强药物中获得了巨大优势，这表明仅靠力量训练不可能让人变得太“肌肉僵硬”。类似前面讨论过的评论，会说运动员不应该担心力量/力量，而应该提升技术，但力量能提升技术的回报，反之亦然。

回到编程，如果你刻意练习和训练，而几乎没人这么做，那么即使你像我一样，在编程方面没有多少天赋，起步也极其艰难，你也能做得比大多数人快。当然，总会有一些更有天赋的人，在花更少时间提升后执行得更快。但幸运的是，对我来说，认真尝试提升自己的人相对较少，所以我做得还不错。

总之，尽管我的操作速度被一些网络评论者认为是不可能的，但我也花了数周死胡同才找到可行方案。如果我的速度是人们认为的“正常”速度，我怀疑找到可行方案所需的时间会足够长，以至于我可能在花费一两个季度后就放弃了这个问题。似乎合理但行不通的方案数量，可能并非与这个问题尽管是多年关键问题却仍是未解难题无关。当然，比我更擅长想出点子的人可能无需走死胡同就能解决问题，但正如我们之前讨论的，在“执行速度”上找到低垂果实相对容易，而在“产生更好想法”上则不然。然而，通过快速尝试和摒弃想法，在一定程度上可以模拟那些比我想法更好的人（我也在努力产生更好的想法，但追求那些更容易获得的高回报收益是合理的）。快速尝试想法的能力也提高了我能产生更好想法的速度，因为其中关键部分是通过获取反馈来建立直觉。

下一个主要反对意见是，在特定任务（X）上提高速度无关紧要，因为花在该任务上的时间有限。从根本上，我不同意这个反对意见，因为尽管这可能对任何特定类型的任务都成立，但解决方案是尝试提升每种任务，而不是彻底否定改进的想法。人们的一个次级反对意见是类似这样的：“但我每周花20小时在毫无成效的会议中，所以我其他时间做什么都无关紧要。”我认为这大错特错。因为如果你只剩下20小时可能高效的时间，那么无论你对这段时间有什么样的生产力乘数，它仍然适用于你的整体生产力。此外，通常有可能退出那些注定无用的会议，并提高那些并非注定无用的会议的生产力¹。

更广泛地说，当人们说优化X没有帮助，因为他们不花时间在X上，也不在X上遇到瓶颈时，这与我的经验不符，因为我发现我在那些常被忽视的X上花费了大量时间并遇到瓶颈。我认为部分原因是，在X上变得更快实际上可能增加在X上花费的时间，因为时间分配存在一种良性循环反馈。另一部分原因如Fabian Giesen这条评论所阐释：

人们普遍接受（近乎陈词滥调）是，你不知道程序在哪里耗费时间，除非你实际进行分析；但由此衍生的结论，即你也不知道你自己的时间花在哪里，除非你进行测量，则远未被普遍接受。

当我查看人们实际时间花费与他们自认为的时间花费对比时，结果非常不准确。我认为一个根本原因是，除非他们进行测量，否则人们对自己时间分配的估计往往偏差很大。这被Fabian Giesen的另一条精辟总结（虽然是关于解魔方，但也适用于其他认知任务）所概括：

一位知名魔方玩家说：“你自己的停顿在解题过程中看起来从不糟糕，因为你的大脑在忙碌，你知道自己在想什么，但一旦你看了录像，你需要改进的地方往往就变得显而易见了。”这与通常针对程序的“不要假设，要分析”建议几乎一样，但适用于你全程专注忙碌的情况，而在编程圈的默认假设似乎是，只要你在实际工作，没有分心或偷懒，就不可能损失大量时间。

与大多数在线讨论此话题的人不同，我实际查看了我的时间流向，很大一部分花在了那些被当作“不值得花时间改进”的典型例子上。

其中一个例子，也是我见过最常被引用的“不该优化”的例子，是打字速度（讨论时，人们通常说打字速度不重要，因为思考花的时间比打字多）。但是，当我查看我的时间流向时，发现很大一部分时间花在打字上。

一个具体例子是，我在当前工作中写过几份有影响力的文档，当人们问写某份文档花了多长时间时，他们通常惊讶地发现只花了一天。就像机器健康状况的例子一样，速度有助于确定哪些文档会产生影响。如果我看看我写的文档，我会说大约15%真正有高影响力（促成了新团队的成立、改变了现有团队的方向、显著影响了公司的利润等）。部分原因是我并不总是知道哪些想法会引起他人共鸣，但部分原因也是我经常提出一些看起来太傻而不会被认真对待的、成功几率渺茫的想法（例如，我提出的解决容量危机的一个方案是，为每个机架关闭10%的容量，从而增加有效配置容量——这听起来简直傻到家了）。如果我写文档的速度慢得多，提出这种真正成功几率渺茫的想法就不划算了。按目前情况，如果我认为一个想法有5%的成功率，那么平均而言，我需要写大约20天的文档才能让其中一个成功。

我大约一半的写作时间花在打字上。如果我按某些人所说的“中等打字速度”（40 WPM）打字，而不是按某次随机打字测试的速度（110 WPM），这将导致 0.5 + 0.5 * 110/40 = 1.875倍的减速，这意味着每篇有高影响力的“渺茫希望”文档需要近40天，这会让这个提议变得风险更大。如果我同时没有优化写作工作流中非打字的部分，我认为总体上可能会慢10倍²，这意味着每篇高影响力“渺茫希望”文档需要大约200天，这足以让我认为我可能根本不会写这类文档了³。

更广泛地说，Fabian Giesen指出，这种速度的非线性影响很常见：

当你跨越某些阈值时（细节在某种程度上取决于具体问题），会出现“相变”，你的整个工作方式都会改变。 ... 有很多事情理论上我可以在任何速度下完成，但实际上做不到，因为随着迭代时间增加，它首先会变得令人沮丧，让我无法长时间进行，最终耗时太长以至于完全超出了我的短期记忆范围，因此我需要记笔记或以其他方式组织信息，否则根本无法完成。

当然，如果我能在交互式界面中通过拖动滑块完成实验，并在不到一秒的时间内看到结果，那么在这个阶段就是“不过滤”的，你想尝试什么就直接去做。

一旦你的迭代时间缩短到几秒钟内（比如使用静态编译语言的编译-链接周期），你不再只是尝试，你还会花时间思考它是否能提供信息，因为这会耗费足够的时间，以至于你宁愿不浪费一次运行。

一旦进入几分钟或几小时的迭代时间，就需要大量规划以避免浪费运行，并且由于等待期间会做其他事情，会出现上下文切换，还需要记笔记/做记录；此外，在这个级别上，错误代价更高（因为浪费的运行浪费了更多时间），也更频繁（因为你的注意力如此分散）。

当你把迭代时间进一步拉长，可能需要为相当数量的资源占用一段显著的时间，这需要审批和预算，这本身又需要会议等等。

一个在我的工作中，项目从一类转向另一类的具体例子是这个关于指标分析的项目。当时有多个关于如何解决这个问题的提案。大家普遍认为这个问题很重要，没有异议，但所有提案都是那种你会分配一个团队通过多个路线图周期去完成的。启动这样一个昂贵的项目需要大量的组织共识，以至于许多重要问题没有得到解决，包括这个问题。但事实证明，如果界定范围得当且执行合理，这个项目实际上是一个程序员一天就能创建出最小可行产品（MVP）的项目，启动它不需要任何组织共识。你不再需要多位总监和一位副总裁都同意这个问题是组织最重要的问题之一，只需要一个认为该问题值得解决的人即可。

回到人们常说“在X上速度不重要因为他们花在X上的时间不多”的X上，另一个我经常看到的例子是编码，我个人的经验也并非编码速度不重要。以上述机器健康状况项目为例，在我找出可行方案后，我花了一个月时间基本上只做这件事：编码、测试和调试。我记得那个月大约有6个小时的会议，除此之外加上吃饭等时间，我就是去上班，编码一整天，然后回家。我认为跨人比较编码速度要困难得多，因为很少看到人们做相同或非常相似的非平凡任务，所以我不会尝试与他人比较，但如果我看自己在刻意提升速度前的生产力和现在的对比，如果没有通过审视速度找到的这些提升，该项目可能根本不可行。

基于阿姆达尔定律的论点在固定基准测试（如SPECint的子任务）中寻找加速时可能是合理的，但当你的系统存在这样一个情况：在某个任务上变得更好会增加完成该任务的回报，并且可能增加在该任务上花费的时间时，说“你不应该花时间在某个任务上因为它不花很多时间”就没有意义了。我花时间在高回报的事情上，但这些事情通常之所以高回报，正是因为我花了时间提升速度，这降低了回报率（ROI）中的“I”（投入）部分。

我看到的最后一个反对提高速度的主要论点是，对考虑生产力和提升速度这个想法本身赋予了负面的道德权重。这类评论常常对各种休闲活动（如与朋友和家人共度时光）赋予正面的道德权重。我认为这个论点本末倒置。如果有人认为花时间与朋友和家人相处很重要，一个简单的办法就是在工作中更高效，从而减少工作时间。

就我个人而言，我刻意避免长时间工作，我怀疑我的工作时间并不比我所在公司的中位数多，而我认为我们公司的工作生活平衡整体相当不错。我的许多生产力提升都用于休闲而非工作。此外，刻意提升速度让我相对较快地获得晋升⁴，这意味着我比未晋升时赚得更多，这让我有更多自由去花时间做我重视的事情。

对于那些不是在争论“不该考虑生产力因为最好专注于休闲”，而是争论“根本不该考虑生产力因为这是不自然的，人应该过自然生活”的人，这最终归结为个人偏好。但对我来说，我太重视工作之外的事物，以至于无法不在工作中刻意提升生产力。

正如这篇关于测量理由的文章一样，虽然这篇文章是关于提高生产力的实用理由，但我个人努力提升生产力的主要原因并非实用。主要原因是，我享受在事情上变得更好的过程，无论那是某种极客桌游、一项我毫无天赋且对我永远不会有实际价值的运动，还是工作。对我来说，次要原因是，鉴于我的寿命有限，我希望将时间分配到我重视的事情上，而提高生产力让我能做更多这样的事，但这不是我在20岁之前就有的想法，那时我已经在提升大多数我花大量时间的事情的技能多年了。

另一个提升生产力的常见原因是，掌握和/或普遍擅长某事似乎对很多人来说都令人满足。这并非我个人的共鸣点，但当我问其他人为什么努力提升技能时，这似乎是一个常见的动机。

一个相关的想法，是Holden Karnofsky长期以来一直在讨论的，即如果你曾想以某种方式对世界产生影响，即使在那些不明显需要你更擅长工作的职位上，提升技能也是有用的，因为当你转向更符合你想实现的目标的事情时，已培养的技能会给你更大的杠杆来影响世界。

附录：一种思考改进方向的方法

以下是来自Gary Bernhardt的一个我喜欢的框架（未单独用引用块，因为除本句外，整个部分都是他的观点）。

人们在谈论效率时，往往固守单一粒度的分析。例如，“思考是最重要的部分，所以别担心打字速度”。如果我们退后一步看，对此的回应是：“效率存在于从年度战略一直到毫秒级按键的连续体的每个节点上。”我认为可以合理假设，较大规模的收益影响最大。但当我们转向更细粒度时，ROI在何处下降并不明显。以下是从粗到细的一些例子：

1. 你开始时的宏观观点是：编程不仅仅是思考；它是思考加上像编辑代码这样的战术活动。更快地编辑意味着有更多时间用于思考。
2. 但编辑代码的成本不仅仅是花在打字上的时间！编程高度依赖短期记忆。每次编辑的停顿都是一种干扰，你可能忘记正在处理的细节。较慢的编辑实际上削弱了你的短期记忆，从而降低了效率。
3. 但编辑代码不仅仅是敲键盘！它是敲键盘加上这些按键所调用的编辑器命令。一个更高效的编辑器可以显著提高有效的代码编辑速度，即使你的WPM（每分钟单词数）与以前相同。
4. 但每个编辑器命令并非孤立存在！通常有多种方式可以进行相同的编辑。一个Vim初学者在更高效的做法是“bdw”时可能会输入“hhhhxxxxxxxx”。一个高级Vim用户可能会使用“bdw”，却没有意识到尽管按键次数相同，它却比“diw”慢。（在QWERTY键盘布局下，前者全在左手，而后者是左右手交替。在140 WPM下，你大约每秒输入14个按键，因此每个手指只有70毫秒的时间定位并按键。左右手交替为下一个手指在前一个手指按键过程中留出了更多定位时间。）

我们必须选择思考这个问题的深度。我认为思考1-3点并让它们指导工具选择和练习，有明确的ROI。我不认为（4）值得过多思考。我们似乎自然会在那里找到“足够好”的点。但这确实为其他点提供了一个很好的参照框架。

附录：更多例子

• 速度无关紧要，来自Julia Evans，我相信她大约从2015年起就是阅读量最广的编程博主
• 在Ben Kuhn一篇关于他通过更好地分配时间将生产力提高50%的帖子的评论中，人们几乎一致对该帖子持负面态度，说他工作过度。尽管Ben在多个评论和帖子中澄清并非所有记录的时间都在工作，但评论者们忙于占据道德高地，并未真正回应帖子内容
• 关于Jamie Brandon的“速度重要”的评论
  • 快速工作毫无意义，因为你将被迫做更多工作
  • 如果你在做正确的事，速度就不重要；另外，即使速度这种东西真的存在，它也无法衡量，因此讨论它毫无意义
  • 考虑生产力是不健康的。人应该放松
  • 你只能在“好、快、便宜”中选择两项，因此努力提高速度是适得其反的
  • 大幅度的加速是不可能的
  • “作者把编程和打字搞混了”
  • 等等。
  • 与Ben的帖子一样，这些评论几乎都在帖子本身中得到了回应。我将不再赘述这种情况，因为它普遍适用于此处提到的帖子。
• Michael Malis关于“如何提升在职程序员生产力”的帖子下的第三条评论：“去他的，整个工作环境似乎都在降低生产力……我为什么要费心……”
  • 第四条评论：“如果我不想提升生产力呢？就慢慢来好了。”
    • 在最初的愤慨之后，这条评论继续并证明了评论者完全误解了要点，因为评论的其余部分解释了评论者如何高效地工作，而评论者似乎只要不以提高生产力的方式表述就可以接受，因为人们应该对有人想要提高生产力并与可能对此感兴趣的人分享技巧这件事在道德上感到愤慨
    • 在回复中，有人指出，更高效的人能有更多时间休闲；这条评论遭到了一致反对，因为“工作会膨胀到填满所有可用时间”，仿佛一个人如何花费时间是某种不可改变的自然法则，而非任何人可以控制的事情
  • 另一条评论：“好吧。我们在优化什么？生产力？还是以下任何目标：达成更多、爬上公司阶梯、赚更多钱等？”
• antirez关于生产力的文章下的评论
  • 这篇文章谈的是10倍程序员的宇宙，而非大多数人生活的正常宇宙
  • 努力提升生产力毫无意义，因为环境决定了生产力
  • 高效的程序员很自私，不指导他人等，对团队不利，因为他们生产力的提升总是来自忽略更重要的事情，因此任何在编程上高效的人实际上对团队来说是适得其反的
    • 如果你阅读该帖子的所有评论，你会发现这是一个共同主题
• Alexy Guezy关于生产力的想法的评论
  • “严肃的问题：有什么比阅读他人的生产力想法更没有生产力的吗？这是拖延症和找出对你来说可能更有效（即带来负罪感）的东西的结合。”
  • 一篇题为“反对生产力”的反生产力文章
• 打字速度无关紧要，因为你只花0.5%到1%的时间打字
  • 尽管谈论的是8小时工作日，但我认为那些一天能有4小时真正工作的人通常被认为是极其高效的。0.5%到1%的4小时是每天1.2分钟到2.4分钟，或者对于一个打字速度为100 WPM的人来说，是在Slack、JIRA、电子邮件、实际代码、提交消息、设计文档、设计文档评论、文档等中总共240个单词；我不相信我认识任何打字这么少的专业程序员
• “我觉得快速编程肌肉和技术债务之间存在相关性……但我们都有年轻的时候，我记得那时我认为唯一阻碍我的是4.77MHz”，这是对一篇比较不同机器构建时间的博客文章的评论（该文章中没有任何类似“唯一阻碍开发者的是构建时间”的观点）

等等。

一些利用生产力为“支持”他们所重视事物的正面例子包括Andy Kelley（Zig）、Jamie Brandon（多个项目）、Andy Matuschak（记忆媒介、多个项目）、Saul Pwanson（VisiData）、Andy Chu（Oil Shell）。我这里引用的是编程领域的例子，但你也可以找到很多其他例子，例如Nick Adnitt（Darkside Canoes），当然还有众多退休后追求完全不像工作那样兴趣的人。

附录：避免高效的另一个原因

在主要科技公司我的更广泛的社交圈中，一个越来越流行的观点是，人们应该避免工作并尽可能浪费时间，通常被称为“反工作”（antiwork），这似乎是“努力”（tryhard）成为一种侮辱的自然延伸。给出的理由通常是类似这样的：工作主要是让你雇主的高层管理人员和/或股东致富，而他们通常比你更富有。

我同情这种论点，并同意高层管理人员和股东获取了工作的大部分价值。但尽管我同情通过故意低效工作来“对抗老板”的想法，但我太重视将时间花在我想要做的事情上，以至于我宁愿快速完成工作，这样我就能做比我更喜欢的事情。此外，过去的高效工作为我提供了良好的工作选择，因此我拥有的工作比我那些拥抱“反工作”运动的科技圈熟人要喜欢得多。

你对环境的控制越少，就越有意义去拥抱“反工作”。主要科技公司的程序员相对来说对他们的环境有相当大的控制权，这就是为什么即使我同情这个事业，我也不是“反工作”的。

尽管是关于不同的话题，Prachee Avasthi的一条相关评论是关于避免有争议的工作，以及在获得终身教职前避免推动必要变革会养成终身教职后难以打破的习惯。如果一个人想永远“反工作”，那没问题；但如果一个人想在某个时候推动改变，在为一家大科技公司工作时养成“反工作”习惯会灌输适得其反的习惯。

感谢Fabian Giesen、Gary Bernhardt、Ben Kuhn、David Turner、Marek Majkowski、Anja Boskovic、Aaron Levin、Lifan Zeng、Justin Blank、Heath Borders、Tao L.、Nehal Patel、@chozu@fedi.absturztau.be、Alex Allain和Jamie Brandon的评论/修正/讨论

由 mimo-v2.5 模型翻译，花费 15754 tokens

这篇文章的另一个可能的标题是：“Twitter竟然有一个内核团队？”。迄今为止，我听到过太多次这种惊讶的感叹，次数多到已经记不清了（我猜大概超过十次，但不到一百次）。如果我们看看那些在规模上（无论是市值还是工程师数量）与Twitter相差不大的流行公司，它们大多没有类似的专业知识，这往往是路径依赖的结果——因为它们“成长”于云端，不像本地部署公司那样需要内核专业知识来维持运转。虽然从社交角度可以理解那些在更年轻、更潮流公司工作的人对Twitter拥有内核团队感到惊讶，但我认为在技术层面上这种惊讶是没有道理的。

无论是否拥有内核专业知识，一家与Twitter规模相当的公司都会定期遇到内核问题，从重大的生产事故到小的麻烦。如果没有内核团队或等效的专业知识，公司将在解决问题时步履维艰，遇到不必要的问题，并且需要不必要长的时间来缓解事故。以一个关键的生产事故为例，因为这件事已经公开撰文，我引用这篇文章，其中冷静地指出：

去年早些时候，我们发现了一个防火墙配置错误，它意外地丢弃了大部分网络流量。我们预计重置防火墙配置可以修复这个问题，但重置防火墙配置却暴露了一个内核错误。

这段话暗示但没有明确说明的是，这次防火墙配置错误是在我任职于Twitter期间发生的最严重的事故，我相信这实际上是自2013年左右以来Twitter经历的最严重的故障。作为一个公司，即使没有内核团队或另一个具备深厚Linux专业知识的团队，我们仍然能够缓解这个问题，但要理解为什么最初的修复不起作用需要更长时间，而这正是你处理严重故障时最不希望发生的。内核团队的成员已经熟悉各种诊断工具和调试技巧，能够快速理解为什么最初的修复没有奏效，而这在一些同行公司中并非共识（我曾调查过几家类似规模的同行公司，询问他们是否认为至少有一人具备快速调试该错误所需的知识，许多公司的回答是否定的）。

在内部各领域拥有专业知识的另一个原因是，它们很容易收回成本，这是大型公司应该比大多数人预期的规模更大这一普遍论点的特例，因为微小的百分比提升在绝对金额上价值巨大。如果在像内核团队这样的专家团队的生命周期内，有一个人发现某项持续性措施能降低总拥有成本（TCO）0.5%，那将足以永久支付该团队的成本，而Twitter的内核团队已经找到了许多这样的改变。除了有时会产生这种影响的内核补丁，人们还会发现具有同等影响的配置问题等。

到目前为止，我只谈到了内核团队，因为它是那个最常因其存在本身而引起人们惊讶的团队，但当人们发现Twitter拥有一批曾在Sun JVM团队工作、参与过HotSpot开发的专家时，比如Ramki Ramakrishna、Tony Printezis和John Coomes，我也会收到类似的反应。人们好奇为什么一家社交媒体公司需要如此深入的JVM专业知识。与内核团队一样，我们这个规模的使用JVM的公司会遇到奇怪的问题和JVM错误，拥有深厚专业知识的人来调试这类问题很有帮助。而且，与内核团队一样，对JVM的单独优化也能永久支付该团队的成本。一个具体的例子是Flavio Brasil的这个补丁，它虚拟化了比较并交换（CAS）调用。

这里的背景是Twitter大量使用Scala。尽管有很多相反的说法，但Scala比Java占用更多内存，速度也明显更慢，如果在大规模使用Scala，这会产生显著的成本，因此有必要进行优化工作，以减少地道Scala与地道Java之间的性能差距。

在补丁之前，如果你分析我们的Scala代码，你会看到在Future/Promise上花费的时间多得不合理，甚至在一些你天真地期望编译器能优化掉工作的场景也是如此。一个原因是Future使用了对JVM优化不透明的比较并交换（CAS）操作。上面链接的补丁在Future不逃逸方法范围时避免了CAS操作。这个配套补丁则移除了一些不太适合编译器优化的地方的CAS操作。这两个补丁结合使用，将使用地道Scala的典型Twitter主要服务的成本降低了5%到15%，其收益足以永久支付JVM团队的成本许多次，而这甚至不是Flavio那年发现的最大收益。

我不会逐一剖析那些自身价值远超成本的团队，因为这样的团队太多了，即使我只限定在“人们惊讶于Twitter竟然拥有这些团队”的范围内。

一个相关话题是人们如何讨论“购买还是自建”的决策。我见过一些讨论，有人主张“购买”，因为这将免去在该领域所需的专业知识。这有时可能是对的，但我看到这种主张被提出的频率远高于其正确性。我认为一个往往不适用的例子是分布式跟踪。我们之前研究过Twitter如何从跟踪中获得价值，这源于Rebecca Isaacs提出的愿景。另一方面，当我与规模类似的同行公司的人交谈时，他们中的大多数人尚未（或至今未能）成功从分布式跟踪中获得显著价值。这非常普遍，以至于我每年不止一次看到Twitter上关于分布式跟踪多么无用的热门话题。尽管我们选择了更昂贵的“自建”选项，但仅凭记忆，我就能想到多个跟踪的用例，其回报是构建跟踪系统成本的10到100倍，而许多选择更便宜“购买”选项的公司的人则普遍抱怨跟踪不值。

巧合的是，我刚和Pam Wolf讨论过这个完全相同的话题，她是一位拥有跨大洲（土木工程）行业经验的土木工程教授，持有一个相关的观点。对于大型系统（项目），你需要为不在自己公司内部处理的每个领域配备一名内部专家（业主方工程师）。虽然从技术上讲，可以再聘请另一家公司来担任专家，但这比培养或招聘内部专家更昂贵，从长远来看风险也更大。这与我作为电气工程师的经历非常相似，那些将职能外包给其他公司而不保留内部专家的组织，付出了非常高的代价，而且不仅仅是金钱上的。他们常常交付有缺陷的设计，并伴随着高昂的成本和长时间的延迟。“购买”可以且常常减少所需专业知识的数量，但往往无法消除对专业知识的需求。

这与另一个常见的抽象论点有关，即公司应专注于“其比较优势领域”、“最重要的问题”或“核心业务需求”，并将其他一切都外包出去。我们已经看到几个例子说明这并不正确，因为在足够大的规模下，无论某事是否是核心业务，拥有内部专业知识都更有利可图（人们可能会辩称所有内部化的事情都变成了核心业务，但这将使“核心性”这一概念失去意义）。这种抽象建议过于简单的另一个原因是，企业可以在一定程度上任意选择其比较优势是什么。一个大的¹例子是苹果将CPU设计内部化。自从以2.78亿美元收购PA Semi（前身是SiByte团队，更早之前是DEC的一个团队）以来，苹果一直在生产在手机和笔记本电脑功耗范围内明显领先的最佳芯片。但是，在收购之前，苹果并没有什么使其收购成为必然，也没有什么使CPU设计成为苹果固有的比较优势。但是，如果一家公司可以选择一个领域并使其成为比较优势，那么建议公司应专注于其比较优势就不是一个很有用的建议了。

2.78亿美元在绝对数额上是一大笔钱，但作为苹果资源的一部分，它微不足道。规模小得多的公司也可以通过投入一小部分资源来从事前沿工作，例如，Twitter以任何一家价值1亿美元公司都能负担的成本，创建了新颖的缓存算法和数据结构，并正在进行其他前沿的缓存工作。拥有优秀的缓存基础设施对Twitter业务的核心性，并不比为苹果创造优秀CPU更高，但它是Twitter可以用来赚取更多收入的一个杠杆。

对于小公司来说，为公司触及的所有领域都配备内部专家并不合理，但公司无需发展到非常大的规模，就可以开始在操作系统、语言运行时和其他人们通常认为相当专业的组件上拥有内部专业知识。回顾Twitter的历史，姚越指出，当她在Twitter早期（大约100名工程师）负责缓存工作时，她经常向内核团队寻求帮助来调试生产事故，在某些情况下，如果没有内核团队的帮助，调试可能需要10倍的时间。社交媒体公司通常在每用户和每美元基础上的规模相对较高，因此不是每家公司都会在拥有100名工程师时需要同样的专业知识，但在那些并非明显核心业务需求的领域，即使对于一个拥有100名工程师的初创公司，专业知识也会带来回报。

感谢Ben Kuhn、姚越、Pam Wolf、John Hergenroeder、Julien Kirch、Tom Brearley和Kevin Burke的评论/修正/讨论。

由 mimo-v2.5 模型翻译，花费 5823 tokens

我经常被问到这样一个问题：为什么要费心测量X，为什么不直接去构建点东西呢？更直白地说，在最近与一位通讯作者的对话中，他对一些我计划进行的未来测量项目（与其他项目类似，例如键盘与鼠标、键盘、终端和端到端延迟测量），带着一丝自得的表情和轻蔑的语气评论道：“所以你只是想上Hacker News头条？”

前一种暗示测量不如构建有价值，后一种则暗示测量根本没有价值（或许除了成名），但我并不认为测量是次要的，更谈不上无价值。如果有的话，因为测量和写作一样，通常不被重视，所以寻找高投资回报率（ROI）的测量项目比寻找高ROI的构建项目要容易得多。

让我们先来看几个高影响力的测量项目案例。我想到的首选例子是Kyle Kingsbury与Jepsen的工作。在Jepsen出现之前，只有少数几家大型公司（现在市值超过1万亿美元、被人们称为“超大规模”的公司）对其分布式系统进行了相当充分的测试。它们大多没有以能真正促使知识传播到整个行业的方式来讨论其测试方法。在那些公司之外，大多数分布式系统按照我的标准来看，测试得并不充分。

当时，在线讨论分布式正确性时常见的模式是：

A人：数据库X损坏了我的数据。
B人：我用着没问题。它从未损坏过我的数据。
A人：你怎么知道？你检查过数据损坏吗？
B人：你什么意思？如果发生数据损坏我会知道的（另一种答案：是的，我们有时会有数据损坏，但这可能是硬件问题，因此不是我们的错）

Kyle早期的工作发现，尽管当时的Jepsen远不如现在成熟，但它测试的几乎所有系统都存在严重缺陷：

• Redis集群 / Redis哨兵：“我们展示Redis在分区期间丢失了56%的写入”
• MongoDB：“在本文中，我们将看到MongoDB丢失了惊人的大量数据”
• Riak：“我们将看到Riak中的最后写入获胜策略如何导致无限的数据丢失”
• NuoDB：“如果您正在考虑使用NuoDB，请注意，该项目的营销和文档可能超出了其当前能力”
• Zookeeper：这是Jepsen早期测试分布式系统中唯一没有发现灾难性错误的一个
• RabbitMQ集群：“RabbitMQ丢失了约35%的已确认写入……这不是理论问题。我知道至少有两个RabbitMQ部署在生产环境中遇到了这个问题。”
• etcd 和 Consul：“etcd的寄存器不是线性化的……Consul中‘一致’的读取会返回任何自认为是领导者的节点的本地状态，允许陈旧读取。”
• ElasticSearch：“健康检查端点会说谎。它乐于在脑裂场景下报告一个绿色的集群……1961次写入中，有645次被确认然后丢失。”

其中许多问题已经存在了相当长的时间

真正令人惊讶的是，这个问题被忽视了这么久。最初的问题是在2012年7月报告的；距今已近整整两年。网站上没有相关讨论，文档中也没有提及，参加ElasticSearch培训的用户告诉我，这些问题在课程中也未被提及。

Kyle随后引用了一些在生产环境中遇到问题的用户，并干巴巴地指出：

有些人实际上提倡将ElasticSearch用作主要数据存储；我认为在当前这不太明智。

尽管我们无法进行A/B测试来比较Kyle存在与不存在的宇宙，也说不出在没有Kyle的宇宙中分布式系统要多久才能认真对待正确性问题，但根据我多年来观察开发者如何对待正确性错误的经验，我敢打赌，在类似Kyle这样的人出现之前，分布式系统会普遍存在正确性问题。当我看到灾难性错误被报告时，典型的反应是项目维护者假设错误报告不正确（如果你查看Kyle工作头几年的回应，你会看到很多例子）。当报告者无法重现该错误时（在分布式系统中这很常见），该错误将被认为不存在。

当报告者确实能重现错误时，下一道防线是论证这种行为是正常的（你同样可以从Kyle工作的回应中看到很多这样的例子）。一旦错误被确认为真实存在，下一个辩护是争辩说该错误无需修复，因为它非常罕见（例如，“很容易站在象牙塔上宣讲理论，但现实世界的成本效益是什么？你是在建造NASA航天飞机运输车来买杂货吗？”）。然后，在承认这个错误应该被修复之后，最后一道防线是争辩项目非常重视正确性，实在没有什么更多能做的了；开发和测试方法不需要改变，因为错误的出现只是偶然，没有方法论改变的情况下类似错误不会再次发生。

Kyle的工作突破了这些防线，如果没有类似的工作，我认为我们仍然会看到这些是对抗分布式系统错误的主要辩护（而不是那些实际上能够产生相当可靠系统的测试方法）。

这是一个特定的例子，但我发现一个普遍现象：在没有人发布产品测量/基准测试的领域，产品通常是次优的，而且一旦被测量，这些问题往往相对容易修复。以下是一些例子：

• 键盘：在我发布这篇关于键盘延迟的文章后，至少有一家宣传高速游戏设备的主要制造商实际上开始优化输入设备延迟。当时，很少有人测量键盘延迟，我只能找到另一个做过测量的人（我想寻找其他测量结果是因为我的测量结果高得令人难以置信，而我在线找到的唯一一个测量结果与我的测量结果处于同一范围）。现在，所有主要的游戏键盘和鼠标制造商都提供了延迟相当低的设备，而在此之前，生产游戏设备的公司专注于那些几乎没有影响的流行词优化（比如更高速的USB轮询率）
• 计算机：在我发布其他一些关于计算机延迟的文章后，一家之前并未认真进行UI延迟工作的主要软件公司的工程师告诉我，一些工程师已经开始测量和优化UI延迟；此外，alacritty的作者提交了这个工单讨论如何降低alacritty延迟
• 汽车前大灯：Jennifer Stockburger指出，当《消费者报告》开始测试前大灯时，汽车制造商的工程师们感谢CR为他们提供了让前大灯更有效的论据；此前，他们会输给那些想要外观更漂亮但效果较差的前大灯的设计师，因为通过设计更好的前大灯来使汽车更安全是一个很难推销的概念，因为没有商业案例，但让汽车在《消费者报告》评测中得分更高让他们有时能赢得辩论。没有第三方测量，以业务为导向的汽车高管没有理由听从工程师的意见，因为几乎没有新购车者会去做任何类似于好好测试他们的前大灯能照亮道路多远的测试，测试前大灯会让对向驾驶员眩目程度的人就更少了，因此设计师不受约束地创造出他们认为最好看的产品，而不管效果如何
• 汽车防抱死制动系统：在《消费者报告》和《Car and Driver》发现特斯拉Model 3的制动距离极长（从60英里/小时到0需要152英尺，从70英里/小时到0需要196英尺）后，特斯拉更新了用于调节制动的算法，这显著缩短了制动距离，使特斯拉从同级最差变为优于平均水平
• 汽车碰撞安全：除了沃尔沃，汽车制造商通常设计他们的汽车以在公布的碰撞测试中获得最高分数；当新测试公布时，他们会增加安全性以取得好成绩，但之前不会

任何人都可以做上面的项目（虽然《消费者报告》购买他们测试的车辆，但一些新兴的汽车评论员通过Turo租车）！

这篇文章解释了为什么测量事物是有价值的，但老实说，我进行测量的动力是好奇心。我只是想知道一个问题的答案。这在我有博客之前就经常做，即使现在有了博客，我也常常不把结果写出来。但即使你对与世界互动时实际发生的事情没有好奇心，你只是“想找点有用的事情做”，几乎所有东西都缺乏测量意味着寻找高ROI的测量项目很容易，至少在对世界的影响方面如此——如果你想赚钱，构建东西可能更容易变现。

附录：“所以你只是想上Hacker News头条？”

当我看到那些我喜欢的、登上Hacker News头条的文章，比如Chris Fenton的项目或Oona Raisanen的项目时，我认为很明显他们的动机不是Hacker News或其他名声，因为他们在博客在Hacker News或其他社交媒体上走红之前很久就在做这些有趣的项目。我不认识他们，但如果非要我猜他们为什么做这些项目，主要是因为他们觉得做这类项目很有趣。

我显然不能说没有人以登上Hacker News头条为主要目标来从事个人项目，但作为一种动机，它与我在Hacker News上阅读的个人项目内容的最明显解释（有人在享受乐趣、有人好奇等等）如此不一致，以至于我觉得有人认为这是一个合理的假定动机有点令人费解。

附录：我测量文章的动力

从某种意义上说，我为什么决定写这些文章并不重要，但如果我读到别人关于这个话题的文章，我仍然会好奇是什么促使他们写作，所以以下是我写测量文章的动力（就本列表而言，包括我整理数据但不进行直接测量的文章）。

• danluu.com/car-safety：我当时在考虑买车，想知道鉴于美国测试中汽车大多获得高分，我是否应该预期制造商之间在安全性方面存在显著差异。
  • 我没有把它写进文章是因为我觉得它太琐碎了（因为数量级很明显，即使不进行计算也能看出来），但我还计算了在车祸中死亡的概率，以及使用一辆较旧的二手车与一辆较新的二手车之间的预期寿命变化。
• danluu.com/cli-complexity：当我看到Gary Berhardt展示如何计算ls单字母命令行选项数量时，我产生了这个想法，这让我想知道这是不是近期的变化。
• danluu.com/overwatch-gender：我当时刚看到两个巨大的Reddit帖子在争论女性在线游戏中受到的待遇是否存在性别偏见，我觉得我获取相关数据的时间会比人们在那些帖子中写评论的时间短。
• danluu.com/input-lag：我想知道我是否应该相信我的感觉，即我使用的现代计算机比我以前用过的旧设备延迟高得多。
• danluu.com/keyboard-latency：我想知道有多少延迟来自键盘（显示延迟已经由https://blurbusters.com进行了很好的测试）。
• danluu.com/bad-decisions：我看到理性社区有人为糟糕的棒球执教决策辩护，说它们不是什么大事，因为它们一年可能只让你输掉四场比赛，这不算什么，我想知道糟糕的执教决策到底有多大影响。
• danluu.com/android-updates：我好奇由于大多数Android手机无法更新，有多少不安全的Android设备在外面。
• danluu.com/filesystem-errors：我好奇文件系统在解决2005年一篇论文发现的数据损坏错误方面改进了多少。
• danluu.com/term-latency：我觉得终端基准测试都在测量一些基本上与用户体验无关的东西（吞吐量），我想知道如果有人测量可能更重要的东西会是什么样子；我也想知道我感觉iTerm2很慢是真实的还是我的想象。
• danluu.com/keyboard-v-mouse：关于键盘与鼠标生产力最被广泛引用的来源明显是虚假的，并且被陈述得极其自信；我想看看非虚假的测试是否会得出相同或不同的结果。
• danluu.com/web-bloat：我在美国进行了一次公路旅行，在那里网络基本上无法使用，我想量化在没有非常快速的互联网访问时网络的不可用性。
• danluu.com/bimodal-compensation：我好奇我们是否正在看到编程领域中层工作的空心化，就像我们在法律工作中看到的那样。
• danluu.com/yegge-predictions：我印象中Steve Yegge对科技未来的预测异常准确，我想看看我的印象是否正确。
• danluu.com/postmortem-lessons：我想看看关于事后分析原因有什么数据，看看我是否能改变我的运作方式并变得更有效率。
• danluu.com/boring-languages：我好奇我使用的软件中有多少是用无聊的、古老的语言编写的。
• danluu.com/blog-ads：我想知道如果我想让博客变现，我能赚多少钱。
• danluu.com/everything-is-broken：我想看看我遇到这么多软件错误的印象是否正确。许多人告诉我，人们经常遇到很多软件错误的想法是选择性记忆造成的错觉，我想知道这对我来说是否属实。
• danluu.com/integer-overflow：我曾与一位语言设计师讨论，他确信整数溢出检查太昂贵而不能做，理由显然站不住脚（因为如果你做100%是整数操作的基准测试，它确实昂贵），我想看看我快速心算的开销估算是否数量级正确。
• danluu.com/octopress-speedup：在观看了Dan Espeset的演讲后，我想知道是否有我可以对当时的Octopress网站进行的简单优化。
• danluu.com/broken-builds：我与某人进行了一系列讨论，他声称他们的项目有非常好的构建正常运行时间，尽管它经常中断；我想知道他的说法相对于其他类似项目是否正确。
• danluu.com/empirical-pl：我想知道有哪些研究支持那些声称有坚实经验证据证明“花哨”类型系统优越性的人。
• danluu.com/2choices-eviction：我好奇如果将“两次随机选择”应用于缓存淘汰会发生什么。
• danluu.com/gender-gap：我想验证一篇声称科技领域薪资没有性别差距的文章中的说法。
• danluu.com/3c-conflict：我想创建一个简单的例子来说明对齐对内存延迟的影响。

顺便说一句，写下这个列表让我意识到我脑中关于我何时以及如何开始认真对待数据的叙事一定是错误的。我以为这是我当前工作带来的东西，但显然不可能，因为我当前工作之前的相当一部分文章都是关于数据分析和/或测量事物的（我甚至没有列出一些我阅读论文并查看其中数据的数据驱动文章）。看到上面的列表后，我意识到我做上述项目不仅远在我有这份工作之前，甚至远在我有这个博客之前。

附录：为什么你不能相信某些评测

做好的测量既会增加也会减少其影响力，这一点的原因在于，大多数发布的测量效果并不好。这增加了理解如何做好测量以及进行良好测量的个人价值，但它削弱了对其他人的影响，因为人们通常不理解什么使测量无效，并且没有好的算法来决定信任哪些测量。

发布的测量/评测存在问题的原因多种多样。评测的一个主要问题是，在某些行业中，评测者严重依赖制造商提供评测样品。

汽车评测是其中最极端的例子之一。《消费者报告》是唯一独立采购评测车辆的主要评测机构，这常常导致他们与其他评测机构意见相左，因为他们会尝试购买大多数人购买的配置版本，而这通常与制造商提供给评测者的配置版本有很大不同，并且《消费者报告》通常能避免评测那些被特意挑选或调校过的不具代表性的车辆。有几次，《消费者报告》的评测员（他们也购买汽车）表示，他们认为有人意识到他们为《消费者报告》工作，然后说他们需要把车留宿一晚才能给他们刚刚购买的车；当这种情况发生时，评测员会放弃购买。

汽车之间存在相当大的个体差异，评测者得到的车往往是那些被挑选出来避免外观问题（油漆问题、面板间隙等）并且检查过更严重问题的车辆。此外，汽车的软件和固件可以被微调（例如，众所周知，宝马的评测车有引擎“调校”，如果你以类似方式改装你的车，会使保修失效）。

另外，因为《消费者报告》不是从制造商那里获取评测车，他们不必手下留情，可以写出非常负面的评测，这在汽车杂志上很少见，在汽车YouTube博主那里也不常见，你通常需要字里行间去解读才能得到诚实的评测，因为明确提到汽车负面内容的评测可能意味着失去访问权限（那个自称“savagegeese”的YouTube博主曾提到在给出诚实评测后难以获得一些公司的车辆访问权限）。

相机镜头是另一个有文献记录评测者会拿到异常好的样品的领域。镜头之间的个体差异巨大，因此供应商会挑选好的样品借给评测者。在许多情况下（例如任何FE卡口的ZA蔡司镜头或RX-1上的蔡司镜头），根据人们需要尝试和退回多少镜头才能得到一个好样品来看，似乎中等质量的镜头存在明显的制造缺陷，并且平均而言，可能只有十分之一的镜头没有明显缺陷（如果只有少数几个镜头有问题并被连续退回，也可能出现这种情况，但很少有摄影师真正检查他们的镜头是否存在制造差异问题）。由于获取大量镜头的成本很高，镜头个体差异的程度在镜头租赁开始测量之前一直未被量化；他们发现不同制造商可能有非常不同水平的个体差异，我希望这能对那些目前销售大量坏镜头却挑选好的样品给评测者的镜头制造商施加压力。

硬盘驱动器是另一个有文献记录评测样品不具代表性的领域。Extreme Tech曾多次报道，ADATA、Crucial和Western Digital向评测者提供的SSD评测样品与消费者购买的不同。我觉得这个案例有趣的一点是Extreme Tech说：

同意评测制造商的产品是各方信任的延伸。提供样品的制造商相信评测将是高质量的、彻底的和客观的。评测者则相信制造商提供的样品准确地反映了最终产品的性能、功耗和整体设计。当读者来阅读评测时，他们相信相关的评测者确实测试了硬件，并且发布的任何基准测试都是公平运行的。

这听起来像是评测者的工作是接受供应商交给他们的信任，然后运行好的基准测试，免除了评测者获取代表性设备并确保其代表性的责任。这让我想起SRE的座右铭，“希望不是一种策略”。信任供应商不是一种策略。我们知道供应商会为了在基准测试中表现更好而说谎和作弊。说这是供应商撒谎或作弊的过错可以推卸责任，但这不会导致评测变得准确或对消费者有用。

虽然我们只讨论了几个有已发表证据表明评测不可信、因为被公司损害的特定领域，但这并不特定于那些行业。作为消费者，我们应该预料到任何不是由可信的、独立的机构进行的、购买自己评测样品的评测都是被损害的，并且不代表中等消费者的体验。

评测的另一个问题是，大多数在搜索中排名靠前的在线评测实际上只是SEO联盟农场。

一个更普遍的问题是，评测也受到与未评测物品完全相同的问题影响：人们通常无法分辨哪些评测实际上是好的，哪些不是，因此评测网站是基于评测质量以外的因素被选择的。一个典型的例子是Wirecutter，它在科技人士中如此受欢迎，以至于注意到旧金山那么多科技公寓都摆放着Wirecutter推荐的相同物品已经是个老掉牙的笑话。对于没在旧金山生活过的人，你可以通过阅读这篇关于如何“不可能”不买Wirecutter推荐物品的帖子的评论来一窥这种心态，评论中充满了人们向发帖人保证，由于其时间的高价值，不做其他任何事情将是不负责任的。

我觉得有趣的是，如果你认真对待基准测试（在任何领域），只需阅读中位数Wirecutter评测的方法论，甚至无需尝试评测中的物品，你就能看出方法论很差，并且他们通常会选择平庸、有时甚至是同级最差的物品。对此的彻底探讨真的值得专门写一篇文章，但我在这里举一个评测不良物品的例子：在https://benkuhn.net/vc中，Ben Kuhn研究了如何创造良好的视频通话体验，其中包括尝试各种麦克风和网络摄像头。自然，Ben尝试了Wirecutter推荐的麦克风和网络摄像头。网络摄像头相当差，不比使用一台古老的2014年iMac或他的2020年MacBook的摄像头好（而且在我看来，实际上差得多；稍后详述）。麦克风也大致相当于使用他笔记本电脑的内置麦克风。

我有很多使用Wirecutter推荐网络摄像头的经验，因为很多人都有它，并且它差得惊人且很独特。Ben指出，如果你看一张静态图片，当他使用的那个房子里，白平衡很糟糕，如果你和其他使用过这款摄像头的人交流，这是个常见问题。但我觉得更严重的问题是，在许多条件下（我认为大多数情况下，因为经常见到），网络摄像头会定期重新对焦，导致整个视频反复失焦然后再对焦（另一个问题是它经常对焦在错误的东西上，但这不那么常见，我并非在每个使用Wirecutter推荐网络摄像头与我通话的人那里都看到这个）。实际上，就在昨天，我和一个朋友通话，他用的不是我通常看到的配置，而是那个平庸但完全可接受的MacBook摄像头。他的视频每10-30秒就会失焦一次，所以我问他是不是用的Wirecutter推荐的网络摄像头，他当然是，因为除了这个，科技人士还会买哪个有同样问题的摄像头？

这种评测质量水平在Wirecutter评测中相当典型，并且它们似乎是科技人士中最受尊敬和使用最广泛的评测网站。

附录：资本主义

我上高中时，有一群早期的“愤世嫉俗者”会做一些事情，比如读《钟形曲线》并把它的论点向任何愿意听的人宣扬。

他们最喜欢的话题之一是自由市场如何自然会导致生产好产品的公司脱颖而出，而生产差产品的公司会消失，从而使事物通常安全、物有所值等等。我仍然经常看到科技行业的人持这种观点，包括那些用Wirecutter推荐物品填满公寓的人。我觉得人们一边争辩市场通常会导致产品变好，一边自己却购买价格虚高的垃圾，这种并列充满了讽刺意味。公平地说，并不全是价格虚高的垃圾。有些是价格虚高的平庸之作，有些实际上还不错；只是它和你在亚马逊上不读第三方评测而随意购买的东西没有太大区别。

关于相关讨论，请参见这篇关于人们一边声称市场消除了歧视，一边自己却在进行歧视的文章。

附录：测量（或缺乏测量）影响的其他例子

• 电子稳定控制系统
  • 丰田RAV4：评测前 评测后
  • 丰田Hilux 评测前 评测后
  • 日产Rogue：在《消费者报告》发现稳定控制系统问题后进行了重大改进。
  • Jeep大切诺基：评测前 评测后
• 工作上的一些无聊事：一年前，我写了这两篇文章，关于工作中的可观测性基础设施。当时，这项工作已经带来了8位数的成本节省，现在这个数字已经远超9位数。这可能值得单独写一篇文章，但大部分工作在有人真正能观察到发生什么之后就变得直截了当了。
  • 相关地：在看到几个问题影响生产服务后，我写了一个小型（5千行代码）解析器，用于解析各种主机级日志中出现的每一行，作为检查那些未在我们的指标中捕获的问题是否被记录。这发现了那些未使用自动化解决方案来捕获和补救主机级问题的集群中的重大问题；对于某些集群，超过90%的主机正在主动损坏数据或存在严重的性能问题。这导致创建了一个新团队来处理这类问题。
• 轮胎
  • 几乎所有制造商（米其林除外）随着轮胎磨损，其湿滑路面、雪地和冰面性能都会严重下降
    • Jason Fenske说其中的技术原因之一是（还有其他原因）提高抓地力的刀槽花纹通常不会被切到全深度，因为这样做会显著增加制造成本，因为切割刀槽的设备需要更强且磨损更快。
    • 一个非技术原因是许多发布的轮胎测试都是在全新轮胎上进行的，因此轮胎制造商通过仅制作部分深度的刀槽花纹就能获得几乎相同的营销基准值。
  • 随着Tire Rack知名度的提高，一些轮胎制造商使其刀槽花纹更具多向性，以改善转弯时的操控性，而不是主要或仅垂直于行驶方向切割花纹（这主要只对加速和制动有帮助，《消费者报告》的雪地和冰面评分分别基于在雪地上直线加速和在冰面上直线制动，而Tire Rack的冬季测试评分则强调全方位的雪地操控性）
  • 测量影响如何受限制的一个例子：米其林冬季轮胎项目经理Farrell Scott表示，在设计米其林X-ICE Xi3的后继产品时，主要设计标准之一是改变轮胎的外观，因为米其林发现客户认为X-ICE Xi3尽管与普利司通Blizzak WS80一起被认为是最佳的全能冬季轮胎（在某些方面略好，某些方面略差），但潜在客户通常会选择其他轮胎，因为它们看起来更像人们心目中“有侵略性”胎块的冬季轮胎（著名的诺记Hakkapeliitta轮胎系列在这方面做得更好得多）。他们也改了名字；新轮胎没有按数字递增，而是命名为米其林X-ICE SNOW，以强调该轮胎适用于雪地和冰面。
  • 尽管有些消费者确实阅读评测，但许多（可能大多数）消费者并不阅读！
• 用于实时视频的HDMI转USB转换器
  • 如果你阅读Camlink 4k的文档，他们会指出该设备在Windows上应使用批量传输，在Mac上应使用等时传输（如果使用他们的软件，它会自动进行此调整）
    • Fabian Giesen告诉我，这可能是出于和他同事测试特定USB3设备在Windows上只有5个测试的芯片组中有1个正确支持等时传输（其余会蓝屏或死机）相同的原因
  • 我尝试了各种便宜的HDMI转USB转换器作为Camlink 4k的替代品，至今尚未找到一款便宜且能在各种计算机上正常工作的。它们通常至少在我能访问的一台计算机上、使用至少一款我想用的软件时能工作，但在某些情况下根本无法工作或提供非常扭曲的视频。也许有人应该发布HDMI转USB转换器质量的基准测试！
• HDMI转VGA转换器
  • 许多这类转换器会变得非常热，然后过热，在15分钟到2小时内停止工作。有些甚至摸起来都不热。祝你好运，弄清楚哪些能用！
• 水过滤
  • Brita声称他们的“长效”滤芯能去除铅。然而，两位不同的亚马逊评测者表示，他们在过滤前后测量了受污染水中的铅含量，发现铅含量并未降低。
  • 以前水流经“长效”滤芯的速度非常慢，这是购买该滤芯用户常见的投诉。现在一些（或许是所有）“长效”滤芯过滤水的速度快得多，但过滤效果未达到Brita声称的水平。
• 体育裁判
  • 棒球裁判以做出正确判罚能力差而闻名，我们拥有做出近乎完美判罚的技术已有数十年了，但许多人争辩说，由人类做出不正确判罚是“比赛的一部分”，如果计算机参与判罚，比赛就不会那么真实了。
  • 一些体育项目已部分屈服于在可能时做出正确裁决的压力，例如在橄榄球中，NFL教练在1999年被允许基于录像资料每场比赛挑战两次判罚（如果前两次挑战成功，2004年开始为三次），模仿了小众的USFL在1985年创建的系统。
• 储物容器
  • 乐柏美储物容器（Rougneck和Toughneck）过去以其质量和耐用性而闻名。当然，从短期来看，减少使用材料和容器强度更有价值，所以另一家公司收购了该品牌并继续使用它，生产外观相似但以堆叠容器时会压弯而闻名的容器，而这正是可嵌套/可堆叠容器的全部意义。我没有看到有人真正对储物容器的承重能力进行过认真基准测试，所以通常你无法知道这是否会发生在你身上。
• 扬声器振动隔离方案
  • Ethan Winer得出结论，这些是发烧友的安慰剂
    

感谢Fabian Giesen、Ben Kuhn、Yuri Vishnevsky、@chordowl、Seth Newman、Justin Blank、Per Vognsen、John Hergenroeder、Pam Wolf、Ivan Echevarria和Jamie Brandon的评论/修正/讨论。

由 mimo-v2.5 模型翻译，花费 17031 tokens

在经典的1986年文章《没有银弹》中，弗雷德·布鲁克斯认为，在某种意义上，几乎没有太多方法可以提高程序员生产力。他的推理是，编程任务包含一个核心的本质/概念复杂性¹，这种复杂性从根本上无法通过任何潜在的技术进步（如语言或工具）来攻克。然后他运用了阿姆达尔定律的论证，指出由于复杂性的1/X是本质的，因此通过技术改进永远不可能获得超过X倍的提升。

在文章接近尾声时，布鲁克斯声称编程中至少一半（大部分）的复杂性是本质的，将所有技术创新组合起来的潜在改进上限限制在最多2倍²：

所有针对软件过程中偶然问题的技术攻击，都从根本上受到生产力方程式的限制：

任务时间 = Σ（频率_i * 时间_i）

如果我相信，如我所信，任务的概念组成部分现在占据了大部分时间，那么无论对仅仅是概念表达的任务组成部分进行多少活动，都无法带来大的生产力提升。

布鲁克斯陈述了程序员生产力可以提升的上限。但是，在实践中，要正确陈述这个上限，就必须能够构想出那些由于当前技术摩擦过大而无人会合理尝试解决的问题。

在无法预测未来的情况下，这是无法估计的。如果我们知道未来，可能会发现程序员可以高效使用的计算能力或存储资源存在某种实际限制，从而限定了程序员可用的资源，但要界定偶然复杂性的程度，仍然需要正确推断程序员将如何能够使用比现在多无数倍的资源，这如此困难，我们不妨称之为不可能。

此外，对于每一类可能存在的工具，人们必须有效地预见所有可能的创新。布鲁克斯的策略是查看现有的工具类别，并指出每一类要么无效，要么虽有效但已发展到头。这不仅是错误的，因为它低估了当时尚未存在、尚未有效或他不熟悉的工具类别（例如，他否定了形式化方法，却没想到提及fuzzing工具、不完全形式化验证代码的静态分析工具、valgrind之类的工具等），而且还因为布鲁克斯认为每一个有重大改进的工具类别都已发展到头，但事实证明它们都没有。例如，布鲁克斯认为编程语言已基本发展到头，而就在“脚本语言”兴起之前，以及在GC语言接管绝大多数编程之前³。尽管你偶尔会听到类似的说法，但没有多少人会主动用C语言编写一个web应用程序，因为现代语言带来的收益不可能只是相对于现代语言的2倍。

布鲁克斯否定的另一个领域是人工智能，他说“用于语音识别的技术与用于图像识别的技术似乎没什么共同点，而且两者都与专家系统中使用的技术不同”。然而，这当然不再正确——神经网络在图像识别和语音识别方面都非常有效。它们作为编程工具是否有效尚待确定，但布鲁克斯反对人工智能论证的一个关键点已被证伪，认为一个显著改进的GPT-2可能会给程序员带来显著的生产力提升并非牵强。当然，布鲁克斯无法预见神经网络在语音和图像识别方面变得有效，这是合理的，但正是这一点使得布鲁克斯否定人工智能以及计算机科学其他所有领域的所有未来进步变得不合理。

布鲁克斯还低估了实践和支持实践的工具所带来的收益。仅举一例，看看老派编程大师的主张，我们有肯·汤普森认为语言安全性毫无用处，bug的发生是因为人们编写了脆弱的代码，如果他们不想有bug就不应该这样做；还有杰米·扎温斯基认为，在紧迫的期限下，自动化测试是浪费时间，“第一次就做对有很多好处”而无需测试。布鲁克斯承认测试的重要性，但他唯一提到的可能改进是能让初学者测试更容易的专家系统。如果你看看中等规模现代软件项目的复杂性，它们已经远远超出了80年代所见过的任何软件项目。如果你真正思考一下使用老派正确性实践来处理这些项目意味着什么，我认为从那些实践到现代实践的加速对于一个典型团队来说是无限的，因为大多数使用那些实践的团队如果面临许多大公司已独立解决的问题（例如，生产一个具有某种声明式SLO的分布式数据库），根本无法产出一个可工作的产品。有人可能会质疑无限加速的说法，但任何参与过认真对待正确性的复杂项目的人都会使用能带来巨大开发加速的工具和技术，轻松超过相对于80年代实践的2倍提升，这种可能性似乎布鲁克斯从未想到，因为他认为由于测试涉及的本质复杂性，重大的测试改进是不可能的。

另一个基本的工具/实践例子是版本控制。一个支持多文件提交、分支、只要开发人员不修改同一行就能正常工作的自动合并等功能的版本控制系统，是一项相当现代的发明。在90年代，微软处于软件开发的前沿，他们直到Win2k之后才设法获得一个能支持他们所需仓库规模（Win2k开发的3000万行代码）并支持分支的版本控制系统。分支是通过简单地复制整个源代码树，然后手动尝试合并源代码树的副本来模拟的。更改源代码树需要特殊批准，由于手动合并的痛苦，整个Win2k团队（5000人，包括1400名开发人员和1700名测试人员）在顺利的情况下每天只能合并100个更改（在构建团队因花时间修复构建中断而停滞的糟糕日子里，则是0）。这是布鲁克斯写作十年后的事情，仅仅通过更好的版本控制工具、测试工具和实践、机器加速允许更快的测试等，就仍然存在着轻松一个数量级的加速机会。请注意，除了没有意识到版本控制和测试工具后来会带来巨大的生产力提升外，布鲁克斯还声称硬件加速不会显著提高开发人员的生产力，尽管硬件速度被认为是Win2k开发速度的一个主要限制因素。布鲁克斯无法想象有人会构建像Win2k这样复杂、真正能利用更快硬件的项目。当然，使用布鲁克斯时代的工具和实践，实际上不可能构建像Win2k这样复杂的项目，但工具和实践进步如此之快，以至于十年后就成为可能，即使由于“石器时代”的工具和实践，开发速度与我们今天习惯的相比慢如蜗牛。

从上面另一个子部分来看，布鲁克斯没有将CI/CD列为潜在的生产力改进，因为他甚至无法想象会有能够支持现代构建实践的工具。1995年写作时，布鲁克斯提到微软有人告诉他他们每晚构建。对此，布鲁克斯说启用每天（至少）一次构建可能工作量太大，并指出贝尔北方研究公司（Bell Northern Research）非常合理地每周构建一次。布鲁克斯写完后不久，谷歌成立了，谷歌的工程师甚至无法想象满足于微软那样的设置，更不用说每周构建了。他们不得不编写大量定制软件，将谷歌规模的单体仓库纳入今天被认为是现代实践的水平，但他们做到了。我工作过的一家成立于1995年的初创公司也建立了自己的CI基础设施，支持从HEAD进行持续合并和构建，因为任何着眼于可能实现而不是认为所有可能实现的事情都已完成的人都会这么做。对于大型项目，仅仅拥有CI/CD并保持干净的构建，相对于每周构建，应该轻松实现2倍的生产力提升，这比布鲁克斯声称的一半复杂性是本质所允许的更大。幸运的是，谷歌、我工作过的那家初创公司以及许多其他地方的工程师们并不相信不可能获得2倍的提升，并且实际上构建了能够带来巨大生产力提升的工具。

从某种意义上说，审视《没有银弹》非常类似于我们查看Unix并发现Unix大师们说我们应该像70年代那样编写软件，以及他们发明的语言和任何语言一样安全。早在计算机发明之前，长辈们就一直告诉下一代，他们已经做完了所有能做的事情，下一代将无法取得更多成就。在计算机时代，我们在编程之外也看到了无数类似的预测，比如克利夫·斯托尔现在臭名昭著的预测，即互联网不会改变任何东西：

有远见者看到了一个远程办公工作者、交互式图书馆和多媒体课堂的未来。他们谈论电子城镇会议和虚拟社区。商业和商务将从办公室和购物中心转移到网络和调制解调器上。数字网络的自由将使政府更加民主。

胡说八道。我们的计算机专家是不是缺乏常识？事实是，没有在线数据库能取代你的日报……那电子出版呢？试试在光盘上读一本书。最好的情况，这也是一种不愉快的苦差事：笨重电脑的近视光芒取代了书本友好的页面。而且你不能把那台笔记本电脑带到海滩上。然而，麻省理工学院媒体实验室的主任尼古拉斯·内格罗蓬特预言，我们很快就会直接通过互联网购买书籍和报纸。呃，当然……然后是网络业务。我们被承诺了即时目录购物——只需点击即可获得超值优惠。我们将通过网络订购机票、进行餐厅预订并协商销售合同。商店将过时。那么为什么我本地的购物中心一个下午的营业额就超过了整个互联网一个月的处理量？

如果你稍微搜索替换一下，斯托尔说的和布鲁克斯一样。当然，过去的技术改变了事物，但我无法想象新技术会如何改变事物，所以它们根本就不会改变。

即使对编程一无所知，我们也能看到这类论点在历史上从未站得住脚，并且相当有信心长辈们这一次并非正确。

布鲁克斯在成为实践者之后很长一段时间里一直在写作软件，但在1964年进入学术界后，并没有费心去跟进工业界发生的事情，这一点从我们审视的1986年文章中已经很明显，但如果你看他2010年的书《设计之设计》，这一点就更加明显，他在其中依赖于他早期文章和书籍中使用的相同例子，其大部分新材料来自他建造的一所房子。我们已经看到程序员试图将他们的知识推广到土木工程时，通常会说出任何土木工程二年级学生都能观察到是错误的愚蠢言论，结果证明，试图从房屋建造技术中提炼出关于软件工程设计技术的深刻见解同样不可行，但既然布鲁克斯没有跟上行业步伐，这就是他所能提供的。虽然存在超越时代和行业的永恒见解，但布鲁克斯有非常具体的建议，例如像鸡尾酒会式的外科手术团队那样管理软件团队，这些想法源于思考如何改进布鲁克斯在50年代IBM看到的开发实践。但事实证明，工业界已经远远超越了IBM在50年代的软件实践，那些相对于IBM在50年代实践有所改进的想法在70年后并非特别有用。

回到本文的主要话题，结合事后诸葛亮来看他关于偶然复杂性的具体论述，我们可以看到布鲁克斯1986年关于“我们基本上已经获得了高级语言所能提供的所有生产力提升”的说法，与1955年汇编语言程序员说汇编语言和任何语言一样好⁴的说法没有太大区别，而他对其他类别的主张也类似。这些主张主要证明的是缺乏想象力。当布鲁克斯提到概念复杂性时，他指的是使用1986年布鲁克斯所熟悉的（在他认为是编程问题的）问题上的概念构建块的复杂性。没有任何理由认为布鲁克斯1986年对编程的理解是根本性的，就像我们不应该认为1955年汇编程序员的想法是根本性的一样。人们经常嘲笑那句传言的“640K应该对任何人都足够”的话，但布鲁克斯说在所有潜在的生产力改进类别中，我们已经完成了大部分可能的事情，这是类似的，而且并非传言！

如果我们展望未来，可能是偶然的复杂性比例实际上是无限的。有人可能会争辩说，如果我们审视现在，这些术语并非毫无意义。但是，尽管这会因领域而异，我个人从未参与过一个不是完全被偶然复杂性主导的非平凡问题，这使得本质复杂性的概念在我参与过的任何值得讨论的问题上都毫无意义。

附录：具体问题

让我们看看我最近在工作中做的几件事如何印证这个本质复杂性的说法：

• 从一堆主机scp以读取和下载日志，然后解析日志以了解问题的范围
• 查询我雇主所有软件每个实例两年的指标数据，针对某些类别的软件，然后生成各种图表，以了解我对我们的软件正在做什么以及如何使用计算机资源的一些疑问

日志

如果我们把这个任务分解一下，我们有：

• 从几十万台机器scp日志到本地机器
  • 用一个Python脚本来完成这个，以获得比pssh/parallel-scp更好的并行性和更健壮的错误处理
    • 编写脚本大约1分钟
• 在日志下载时做其他工作
  • 解析下载的日志（几TB）
    • 用一个Rust脚本来完成这个，写几分钟（这里用Rust而不是Python是出于性能原因——仅仅是打开日志并逐行扫描的惯用Python实现，在我不想将任务分发到多台机器时，就已经比我想要的慢了）

在1986年，也许我会用telnet或ftp代替scp。现代脚本语言还不存在（perl创建于1987年，而perl5，第一个有人认为是现代版本的，于1994年发布），因此编写一个具有并行性和“足够好”的错误处理的代码，会比今天花费多一个数量级以上的时间。事实上，我认为仅仅在管理连接池的同时实现半体面的错误处理，就很容易比我完成这个整个任务（不包括在后台下载日志的时间）所花费的时间长一个数量级。

接下来是解析日志。比较“1TB”这样的绝对数字是不公平的，所以我们只称之为“足够让我们关注性能”（我们将在指标示例中更详细地讨论规模）。今天，我们可以选择高性能语言，轻松编写快速、安全的代码，并利用库（例如，正则表达式库⁵）的力量，这些库使我们能够轻松编写一个快速而粗糙的脚本来解析和分类日志，将工作分配到我计算机的所有核心上（我认为Zig也能做到这一点，但我用了Rust，因为我团队有相当数量的Rust程序员）。

在1986年，不会有可比的语言，但更重要的是，我无法轻松找到、下载和编译相应的库，而不得不手动编写所有解析代码，将一个几分钟的任务变成一个运气好也要花一个小时才能完成的任务。此外，如果我不知道如何使用库或知道可以使用库，我可以轻松地在StackOverflow上找到如何解决问题的方法，这将大大减少偶然复杂性。不用说，1986年并没有真正的相当于谷歌搜索StackOverflow解决方案的东西。

而且，即使在今天，这个任务，一个非常标准的程序员开发/SRE任务，在比1986年的类似任务至少快一个数量级之后，仍然几乎完全是偶然复杂性。

如果数据导出到我们的指标系统中，或者如果我们的集中式日志工作方式稍有不同，整个任务将是微不足道的。如果两者都不成立，但日志格式更统一，那么在获取日志后我就不需要编写任何代码；rg或ag就足够了。如果我看一下我在任务本质概念核心上花费了多少时间，它如此之小以至于难以估计。

查询指标

我们真的只需要一个反例，但我认为通过一个更复杂的任务来看看布鲁克斯的论点如何扩展，更具说明性。如果你想跳过这个冗长的例子，点击此处跳到下一节。

我们可以将我的指标查询任务视为由以下子任务组成：

• 编写一组Presto SQL查询，有效地扫描大约100TB的数据，从一个数据集中（如果我不维护只包含相关数据子集的表，该数据集大约为100PB的数据）
  • 编写第一个查询大约30秒，查询完成需要几分钟，使用大约1个CPU年的CPU时间
• 编写一些ggplot代码来绘制我好奇的各种属性
  • 不确定这花了多长时间；比查询完成的时间短，所以没有增加这个任务的总时间

这些任务中的第一个在今天完成起来比1986年快了多个数量级，我甚至无法在1-2个数量级内大胆猜测今天快了多少，但让我们把第一个任务分解成组成部分，以了解任务变得更容易的方面。

将绝对数字如100PB转换到1986年是不公平的，但仅仅是拥有一个收集和持久化综合数据的管道，类似于我作为消费软件公司正在研究的数据（关于我们软件资源使用和效率的各种数据），在1986年会被认为是荒谬的。在这里，我们看到了偶然-本质复杂性概念作为生产力改进上限的一个致命缺陷：具有太多偶然复杂性的任务甚至不会被认为是可能的。布鲁克斯所看到的偶然复杂性限制实际上是他想象力的限制，而不是根本性的。

布鲁克斯明确否定了增加计算能力是提高生产力的一种方式（“嗯，一个人能有效使用多少MIPS？”，后面会更多讨论），但存储和CPU能力（更不用说网络速度和RAM）是如此巨大的偶然复杂性来源，以至于它们限制了布鲁克斯能够构想出的问题空间。

在这个例子中，假设我们在1986年以某种方式有足够的存储来保存我们想要查询的数据。接下来的部分将是调度大约1个CPU年的资源，并让查询在几分钟内完成。与存储问题一样，这在1986年也会是荒谬的⁶，所以我们遇到了第二个如此巨大的非本质复杂性，以至于会让1986年的人根本想不到这个问题。

接下来是编写查询。如果我是在为Cray-2编写并想要高效，我可能会用Cray的Fortran 77方言编写查询。我能在每个查询不到300秒内完成吗？没门；我用Scala/Scalding甚至都无法接近，我认为即使用Python/PySpark也很悬。这是我们看到收益最小的一个方面，而我们仍然明显超过一个数量级。

在我们处理完数据后，必须生成图表。即使使用今天的技术，我认为不使用ggplot也会在生产力上损失至少2倍。我尝试过每一个据称等效的主要绘图库（无论哪种语言），我尝试过的每个库要么在绘制我认为在ggplot中是基础的图表时存在多个阻塞性错误，要么太底层，以至于我被迫手动完成在ggplot中微不足道的事情，损失了超过2倍的生产力。在2020年，仅仅一个库的存在就在这一个步骤上为我节省了2倍。如果我们回到1986年，在图形语法概念和任何合理的实现出现之前，即使假设有一些神奇的工作站硬件能够在合理的时间内完成我所做的绘图操作（我的机器渲染图表非常慢；Cray-2根本无法在合理的时间范围内完成渲染），我在绘图上损失的时间也不可能少于两个数量级。

从1986年到今天，这个问题偶然复杂性减少的数量级之多，我甚至无法估计，然而这个问题仍然包含如此大比例的偶然复杂性，以至于再次难以猜测复杂性的哪一部分是本质的。写下我能想到的所有偶然复杂性将需要至少2万字，但仅仅为了提供一点复杂性的风味，让我写下几件事。

• SQL；这是一件表面简单但实际上极其复杂的事情
  • 还有，Presto SQL
• 任意Presto限制，有些来自Presto本身，有些来自我们操作Presto的具体方式以及我们使用的版本
  • 当我以特定方式同时使用numeric_histogram和cross join unnest时，会触发一个内部Presto数据结构断言失败。因为编写会暴露该bug的查询、等待它失败然后再重写它是浪费时间，所以我有一个心算的启发式方法来猜测，对于任何同时使用这两个结构的查询，我是否会遇到该bug，并应用它来避免编写两个查询。如果启发式方法适用，我会编写一个更冗长、执行更慢的查询，而不是那个更直接的查询
  • 我们按日期对数据进行分区，但当我在查询中连接表时，Presto会丢弃这一点，导致在连接长时间跨度的数据时出现非常大且昂贵的连接，尽管原则上这可以是一系列廉价的连接；如果连接大到导致我的查询失败，我本质上会编写一个小查询编译器来执行逐日查询，然后根据需要对数据进行后处理，而不是编写朴素的查询
    • 有很多情况下，查询中的某种优化可以使查询可行，而无需跨天拆分查询（例如，如果我想将主机级别的指标数据与包含主机所在集群的表连接，这是一个跨多年数据的非常慢的连接，但我也知道哪些类型的主机在哪些集群中，这在某些情况下使我能够过滤掉主机级别指标数据中的主机，如核心计数和总内存，这可以使这个连接的较大输入足够小，从而使查询能够成功，而无需手动分区查询）
  • 我们有一个“快”但内存限制“低”的Presto集群和一个“慢”但内存限制“高”的集群，所以我需要在心中估算查询所需的每个节点的内存，以便将其调度到正确的集群
  • 等等
• 出于性能原因，我应该在Presto中计算CDF或直方图，还是留到最后让ggplot计算
• 我需要对数据进行多少降采样（如果需要的话）才能让ggplot处理，以及这可能会如何影响分析
• 任意ggplot的东西
  • 在散点图中大约需要多少个点，我才应该停止使用size = [number]，而应该切换到单像素绘图，因为将点绘制为圆太慢了
  • 点的最小允许不透明度是多少
  • 如果我超过散点图中可以看到渐变的最大密度限制，我需要将图像制作得多大以适当降低密度（我什么时候会这样做而不是使用热图值得单独写一篇文章）
  • 等等
• 所有这些都涉及我用来编写和检查查询的工具，但还有一个关于在编写查询以生成有效结果时必须考虑的所有数据问题的思维模型，包括时钟偏差、Linux计费错误、指标管道问题、由于底层数据源问题导致的数据问题等。
• 等等

对于Presto和ggplot，我都在脑海中隐含地记住了数百件事，以使我的查询和图表能够工作，我选择使用这些，因为它们是我知道的可用工具中开销最低的。如果有人问我必须处理的复杂性中有多少是本质的，我会说它如此之低，以至于无法估计。对于某些查询，可以说它是零——我的工作之所以必要，仅仅是因为某些任意的怪癖，没有这个怪癖就不需要工作。但即使在某些查询似乎必要的情况下，我也认为令人难以置信的是，本质复杂性可能超过我必须处理的复杂性的1%。

重新审视布鲁克斯关于计算机性能的观点，即使我在2020年处理由于硬件性能限制而带来的复杂性，并且希望今天有更快的计算机，但布鲁克斯在1986年否定了更快的硬件对开发者生产力几乎没有提高作用：

个人工作站功率和内存容量的确定而快速的增加，能为软件艺术带来什么收益？嗯，一个人能有效使用多少MIPS？程序和文档的编写和编辑完全得到了当今速度的支持。编译可以得到提升，但10倍的机器速度肯定会……

但这至少在两个层面上是错误的。首先，如果我能够使用更快的计算机，我大量的偶然复杂性会消失（如果计算机足够强大，我就不需要像Presto这样复杂的工具；我可以在我的本地计算机上运行查询）。我们现在有了快得多的计算机，但拥有更快的计算机仍然会使许多复杂的工程任务变得微不足道。正如詹姆斯·黑格（James Hague）指出的，在80年代中期，由于性能限制，编写拼写检查器是一个严肃的工程问题。

第二，（仅举一例）ggplot之所以存在，是因为计算机速度如此之快。从事性能工作的人们一个常见的抱怨是，当你查看工具执行的基本操作与当今硬件的速度相比时，工具X存在2到10个数量级的效率低下⁷。但有多少程序员能够实现现代多路服务器一半的潜在性能？我猜不到千分之一，我肯定说不到百分之一。而且性能知识并非与其他知识无关——在年龄和经验相同的情况下，它与“系统”以外领域的知识呈负相关，因为花时间学习实现计算机一半潜在性能所需的深奥偶然复杂性，就是花时间不学习“直接”应用的领域知识。当我们看到需要大量领域知识（例如ggplot）或规模大到需要大型团队实施（例如IntelliJ⁸）的软件时，如果机器慢了几个数量级，编写可用软件需要榨取机器的大部分性能，那么这些软件的大部分都不会存在。幸运的是，硬件变得快得多，使绝大多数开发人员可以忽略与性能相关的偶然复杂性，而专注于在当今提高生产力所需的其他所有偶然复杂性。

更快的计算机既减少了工具用户遇到的偶然复杂性，也减少了工具创建者需要处理的偶然复杂性，从而允许更有生产力的工具得以存在。

2022年更新

很多人都说这篇文章是错误的，因为布鲁克斯显然说的是X，而布鲁克斯并不是指我在本文中引用的内容。但人们对于布鲁克斯真正意思的说法五花八门，因此总的来说，这些反驳是自相矛盾的，因为他们认为布鲁克斯“显然”指的是某个特定的东西，但如果这么明显，人们就不会对布鲁克斯的意思有这么多不同的想法了。

当然，当遇到像布鲁克斯文章这样的罗夏墨迹测试文章时，这是不可避免的，文章陈述了各种不同且矛盾的内容。

感谢Peter Bhat Harkins、Ben Kuhn、Yuri Vishnevsky、Chris Granger、Wesley Aptekar-Cassels、Sophia Wisdom、Lifan Zeng、Scott Wolchok、Martin Horenovsky、@realcmb、Kevin Burke、Aaron Brown、@up_lurk和Saul Pwanson的评论/修正/讨论。

由 mimo-v2.5 模型翻译，花费 20641 tokens

每当有一个基准测试被认真对待时，有些人就会开始针对基准进行优化。计算机领域的一些著名例子包括CPU基准测试specfp和视频游戏基准测试。在specfp中，Sun通过编译器调整将179.art（specfp的一个子基准测试）的得分提高了12倍，这本质上是重写了基准测试内核，使得Sun UltraSPARC的整体specfp得分提高了20%。有时，GPU厂商会在驱动程序中添加专门的基准测试检测代码，在基准测试期间降低图像质量以产生更高的基准测试分数。当然，针对基准进行优化并非计算机独有，我们看到人们在其他领域也这样做。这种行为并不令人惊讶，因为通过作弊来提高基准测试分数比通过实际改进产品来提高分数要便宜得多（因此投资回报率更高）。

因此，当人们过分重视高度具体和知名的基准测试时，我通常持怀疑态度。如果没有其他数据，你不知道当条件与基准测试条件不完全相同时会发生什么。对于GPU和CPU基准测试，大多数人都可以使用略微调整的条件来运行标准基准测试。如果结果在条件的小变化下发生显著变化，这就表明厂商即使没有作弊，至少也在掩饰真相。

物理设备的基准测试可能更难以复现。车辆碰撞测试就是一个典型例子——它们是高度具体和知名的基准测试，并且在测试运行中会消耗一辆汽车。

虽然有多个组织进行碰撞测试，但每个组织都遵循特定的规程。汽车制造商，如果有意愿，可以针对碰撞测试分数而不是实际安全性来优化他们的汽车。检查碰撞测试是否被过度具体的优化所操纵，对于非亿万富翁来说并不真正可行。我们能检查的最简单方法是查看当新测试添加时会发生什么，因为这让我们可以看到制造商并未为了获得好分数而进行优化的碰撞测试结果。

虽然有汽车碰撞测试结果显然比没有好，但这些结果本身并没有告诉我们当发生与基准测试不完全匹配的事故时会发生什么。不幸的是，如果我们发生车祸，我们无法要求碰撞车辆的驾驶员改变他们的位置、撞击角度和速度，以使碰撞符合IIHS、NHTSA或*NCAP的测试规程。

在本文中，我们将查看IIHS在添加（驾驶员侧）小重叠和乘客侧小重叠测试时的得分，这些测试分别于2012年和2018年添加。我们将从结果摘要开始，然后讨论这些结果的含义以及评估汽车安全时需要考虑的其他因素，随后是方法的详细信息。

结果

以下排名主要基于车辆在2012年添加驾驶员侧小重叠测试时的得分表现以及在修改后改善测试结果的模型得分。

• 第一梯队：无需修改即表现良好
  • 沃尔沃
• 第二梯队：无需修改时表现一般；修改后表现良好
  • 无
• 第三梯队：无需修改时表现差；修改后表现良好
  • 梅赛德斯
  • 宝马
• 第四梯队：无需修改时表现差；修改后表现一般
  • 本田
  • 丰田
  • 斯巴鲁
  • 雪佛兰
  • 特斯拉
  • 福特
• 第五梯队：修改后表现差或未进行修改
  • 现代
  • 道奇
  • 日产
  • 吉普
  • 大众

这些描述是近似的。本田、福特和特斯拉最不符合这些描述，福特可以说介于第四和第五梯队之间，但也可以说优于第四梯队且不符合分类，而本田和特斯拉并不真正适合任何类别（他们的类别是最接近的拟合），但有些其他类别也不完美。详细信息如下。

总体评论

如果我们看看美国的整体死亡率，汽车事故在相当大的年龄范围内是主要死因。虽然数字会因我们查看的数据集而异，但当驾驶员侧小重叠测试被添加时，IIHS估计25%的车辆死亡来自小重叠碰撞。同样值得注意的是，自90年代以来，小重叠碰撞就被认为与相当一部分车辆死亡有关；这在2012年并不是一个新概念。

尽管小重叠碰撞很重要，但从IIHS在2012年和2018年添加驾驶员侧和乘客侧小重叠测试的结果来看，几乎所有汽车制造商都在优化基准而非整体安全性。除了沃尔沃，所有被调查的汽车制造商在驾驶员侧小重叠测试添加之前生产的汽车在驾驶员侧小重叠碰撞中表现都很差。

当2012年添加驾驶员侧小重叠测试时，大多数制造商修改了他们的车辆以提高驾驶员侧小重叠测试分数。然而，直到IIHS在2018年添加乘客侧小重叠测试之前，大多数制造商都忽略了乘客侧。当新测试添加时，他们也加强了乘客安全性。公平地说，有些汽车制造商在2012年驾驶员侧测试添加时就意识到了小重叠碰撞的问题，并且不需要进一步修改就能在乘客侧小重叠测试中获得好成绩，包括梅赛德斯、宝马和特斯拉（可能还有其他几家，但其他情况的数据较薄；沃尔沃不需要提示）。

其他基准测试限制

我们可以在多个其他领域观察到大多数汽车制造商在以安全为代价优化基准。

性别、体重和身高

另一个问题是碰撞测试假人的过拟合。长期以来，成人NHTSA和IIHS测试使用1970年代的50%男性假人，身高5'9"，体重171磅。监管机构在1980年要求使用女性假人，但由于里根时代的预算削减，最初计划被搁置，NHTSA直到2003年才将女性假人放入汽车中。女性假人是男性假人的缩小版，缩小到1970年代的5%身高和体重（4'11"，108磅；另一种型号是4'11"，97磅）。在正面碰撞测试中，使用女性假人时，她总是乘客（一个5%女性在驾驶员座位上出现在NHTSA侧面碰撞测试和IIHS侧面碰撞测试中）。作为参考，2019年美国成年男性平均体重为198磅，美国成年女性平均体重为171磅。

使用1970年代美国成年男性碰撞测试假人会导致对1970年代50%男性的一定程度过拟合。例如，从90年代开始，制造商开始添加系统以防止颈部扭伤。沃尔沃和丰田使用一种系统，可以减少男性和女性的颈部扭伤，并且似乎对女性略有更多益处。大多数汽车制造商使用的系统减少了男性的颈部扭伤，但平均而言，对女性颈部扭伤影响很小。

看来我们也看到了类似的一般碰撞优化，而不仅仅是颈部扭伤。我们没有这方面的碰撞测试数据，并且查看真实世界安全数据超出了本文的范围，但我将指出，在NHTSA将5%女性假人放入一些碰撞测试之前，大多数非沃尔沃命名的汽车制造商在侧面碰撞中存在基于性别的显著死亡率差异（男性死亡率较低，女性死亡率较高）。

沃尔沃声称几十年来一直在使用计算机模型模拟如果女性（包括孕妇）卷入车祸会发生什么。

其他碰撞

据说沃尔沃有一个碰撞测试设施，他们进行许多测试机构不进行的其他碰撞测试。他们在小重叠测试添加时得分高的一个原因是在IIHS开始进行小重叠碰撞测试之前，他们就已经在进行小重叠碰撞测试了。

沃尔沃还表示，他们测试翻滚（IIHS测试车顶强度，NHTSA根据车辆属性计算车辆翻滚的难易程度，但两者都不测试真实翻滚事故中发生的情况）、后部碰撞（沃尔沃声称如果有儿童在3排SUV的第三排，这些测试尤其重要）和驶出道路（沃尔沃有一个他们使用的“标准”沟渠；他们声称这个测试很重要，因为驶出道路与很大一部分车辆死亡有关）。

如果其他汽车制造商进行类似测试，我找不到太多详细信息。根据碰撞测试分数，在2012年之前，他们似乎没有进行甚至没有考虑小重叠碰撞测试。根据2018年乘客侧小重叠测试添加时许多汽车制造商得分较低的情况，我认为如果其他汽车制造商有大量测试机构未进行的碰撞测试套件会令人惊讶，但理论上可能他们进行了，只是没有包括乘客侧小重叠测试。

注意事项

我们不应从这些测试结果过度概括。正如我们上面指出的，碰撞测试结果测试非常具体的条件。因此，当几个新碰撞测试添加时，我们能得出的结论也非常具体。此外，在解释这些结果时，我们还应记住许多其他事情。

有限的样本量

这些数据的一个局限性是我们没有大量相同型号副本的结果，因此我们无法观察型号内变化，这可能是由于测试条件的微小、实际上随机的差异以及相同型号不同副本之间的制造差异造成的。我们可以观察到这些确实重要，因为有些汽车在测试相同型号的两个副本时会看到不同的结果。例如，这是IIHS关于道奇Dart报告中的一段引用：

道奇Dart在2013车型年推出。Dart进行了两次测试，因为第一次测试期间车载（汽车内部）摄像头的电源中断。在第二次Dart测试中，当铰链从门框撕裂时，驾驶员门打开了。在第一次测试中，铰链严重损坏，下方铰链撕裂，但门保持关闭。在每次测试中，Dart的安全带和正面及侧面帘式气囊似乎充分保护了假人的头部和上身，并且来自假人的测量显示头部和胸部受伤风险很小。

看起来，如果车载摄像头的电源没有断开，将只有一次测试，就不会知道由于铰链撕裂导致门脱落的风险。一般来说，我们没有关于如果测试相同型号的另一个副本会发生什么的直接信息。

仅使用IIHS数据，我们在这里可能做的一件事是考虑同一制造商制造的（或基于相同平台构建的）不同型号的结果。虽然这不如同一型号的多次测试好，但同一制造商不同型号之间的测试结果是相关的，并且知道例如一个型号的第二次测试偶然显示显著更差的结果应该降低我们对同一制造商其他测试分数的信心。有些事情使这复杂化，例如，如果查看丰田，雅力士实际上是马自达2的重新贴牌，所以也许这不应被视为汇总测试结果的一部分，并且进行这种统计分析超出了本文的范围。

实际测试的车辆可能不同

虽然我认为这不应影响本文的结果，但查看碰撞测试结果时要考虑的另一个问题是结果如何在型号之间共享。正如我们刚才看到的，相同型号的不同副本可能有不同的结果。有些相似的车辆通常被视为用于碰撞测试目的的相同车辆，并将共享相同的分数（只有一个型号会被测试）。

例如，起亚Stinger和Genesis G70就是如此。起亚Stinger比G70长6英寸，一辆全轮驱动的全加载Stinger比基础型号G70重约500磅。IIHS测试的是G70型号——如果你查找起亚Stinger，你会得到Stinger的分数，备注为基础型号G70被测试。考虑到名义上相同的汽车（如上面提到的道奇Dart）可能得到不同的分数，这是一个相当大的差异。

质量可能随时间变化

我们也应谨慎不要过度概括时间。如果我们查看最近沃尔沃（基于沃尔沃P3和沃尔沃SPA平台的车辆）的碰撞测试分数，分数非常出色。然而，如果我们查看基于较旧福特C1平台¹的沃尔沃型号，其中一些的碰撞测试分数不那么好（特别是，虽然S40得分不差，但在某些类别中得分为可接受，而不是全部良好）。尽管沃尔沃最近的碰撞测试分数出色，但这并不意味着他们一直或将永远拥有出色的碰撞测试分数。

型号可能因市场而异

我们也不能概括不同市场销售的汽车，即使对于听起来可能相同的车辆也是如此。例如，查看这段欧洲销售的日产NP300与非洲销售的日产NP300的碰撞测试视频。由于欧洲汽车经过EuroNCAP测试（类似于美国汽车经过NHTSA和IIHS测试），在欧洲销售的车辆经过优化以在EuroNCAP测试中获得好成绩。对在非洲销售的汽车进行碰撞测试只是最近才开始，因此汽车制造商没有公共关系压力来优化他们的汽车以进行基准测试，他们会生产更便宜的型号或表面上相同型号的更便宜变体。这似乎与大多数汽车制造商在美国或欧洲所做的一样——只要他们能做到而不使基准测试分数变差，他们就在优化成本。只是由于没有非洲碰撞测试基准，这意味着他们可以全力以赴地在成本-安全性权衡上追求成本²。

这份报告比较了美国和欧洲汽车型号，并发现了由于法规差异导致的安全差异。他们发现欧洲型号在正面/侧面碰撞中受伤风险较低，并且驾驶员侧后视镜的设计方式降低了车道变换碰撞的风险，相对于美国设计，而美国车辆在翻滚中更安全，并且车灯使行人更可见。

非碰撞测试

随着时间的推移，碰撞安全的“低垂果实”越来越多，使得碰撞避免相对更加重要。碰撞缓解测试与碰撞测试相比相对原始，我们看到碰撞测试过去和现在都有重大漏洞。人们可能期望，根据我们在碰撞测试中看到的，沃尔沃为他们的碰撞避免技术（牵引力控制、稳定性控制、自动制动等）使用一套特别好的测试，但与熟悉车辆安全测试的人进行的“酒吧间”讨论似乎表明情况并非如此。最近有一些沃尔沃车辆被召回，因为安全系统错误地没有触发。我不打算在这里讲述这个故事，但我会说这相当可怕，表明存在严重的系统性问题。从其他后台讨论来看，作为汽车公司，宝马在安全软件方面相对认真，但这种测试缺乏严谨性，对于见过主流CPU发布过程的人来说将是可怕的。

碰撞避免变得更加重要也可能有利于那些拥有更用户友好的驾驶辅助系统的公司，例如，在多次测试中，《消费者报告》给通用的Super Cruise系统最高评分，而他们一再指出特斯拉的Autopilot系统促进了不安全行为。

不同重量车辆的分数不可比

一辆得分为良好的2700磅小型车可能比一辆得分为可接受的5000磅SUV表现更差。这是因为小重叠测试涉及将车辆撞向固定障碍物，而不是具有特定重量的参考车辆或类车辆障碍物。这在某种意义上等同于将车辆撞向相同重量的车辆，因此就像2700磅小型车被测试通过撞向另一辆2700磅小型车，而5000磅SUV被测试通过撞向另一辆5000磅SUV。

如何增加信心

我们讨论了一些应该降低我们对碰撞测试分数信心的原因。如果我们想增加对结果的信心，我们可以查看其他测试机构的测试结果并汇总，还可以查看公开的碰撞死亡数据（稍后会更多讨论）。我没有查看其他机构分数的条款和条件，但一个复杂情况是IIHS不允许你使用其API或数据转储来显示任何类型聚合的结果（我为了这篇文章没有使用他们的API，因为那很耗时）。

使用真实世界碰撞数据

公开的碰撞死亡数据很复杂，值得单独一篇文章讨论。在本文中，我将指出，如果你查看美国人最容易获得的相关数据，这些数据并未显示沃尔沃特别安全（或不安全）。例如，如果我们查看这份涵盖2014型号的2017年报告，两个沃尔沃型号进入报告，两者在其类别中得分大致中等。在上一份报告中，一个沃尔沃型号被包含，它是同类中最好的之一，在下一份报告中，一个沃尔沃型号被包含，它是同类中最差的之一。我们可以在其他型号中观察到这种方差。例如，在2014型号中，大众高尔夫在所有车辆中（不仅仅在其类别中）有最高死亡率之一。但在2017型号中，它在所有车辆中有最低死亡率之一。不清楚有多少变化来自随机方差，有多少是因为2014和2017大众高尔夫之间的差异。

总的来说，噪声似乎是结果中的一个重要因素。如果我们查看提供的信息，我们可以看到几件奇怪的事情。首先，有许多车辆的死亡率95%置信区间从0到N。我们应该有很强的先验信念，即没有2014型号车辆如此安全以至于在车祸中死亡的概率为零。如果我们采用贝叶斯方法（尽管我认为报告的作者不是），有人告诉我们一辆车的真实死亡率不确定性区间有≥5%包含零，我们会说要么我们应该使用更具信息性的先验，要么我们应该使用一个可以纳入更多数据的模型（在这种情况下，也许我们可以尝试理解同一类别中不同型号死亡率之间的方差，然后使用该类别的死亡率作为先验，或者如果我们认为相关，可以纳入同一品牌下其他型号的信息）。

有些人反对使用信息性先验作为偏见洗白的一种形式，但我们应该注意IIHS分析中使用的先验并非完全无信息。报告的所有区间都停止于零，因为他们利用车辆不能创造生命的事实将区间限制在零。但我们有几乎同样强大的信息，即没有2014型号车辆的预期死亡率为零，使用该信息与将区间限制在零并报告死亡率不确定性区间的负数没有根本不同。

此外，IIHS数据只包括驾驶员死亡。这是可以理解的，因为这是标准化乘客数量的最简单方式，但这意味着我们不可能看到汽车制造商在乘客侧小重叠安全性方面的改进（直到2018年乘客侧小重叠测试添加），以及沃尔沃认为重要的情况（3排SUV第三排儿童）缺乏后部碰撞测试的结果。这也意味着我们无法观察沃尔沃所做的一些事情的影响，例如，非常早期在自动制动系统中进行行人和骑车人检测，在驶出道路事故中添加溃缩区以减少背部伤害（他们观察到这些事故经常导致改变生活的脊柱损伤，由于车辆掉落的冲击）等。

我们还可以观察到，在IIHS分析中，许多可能想控制的因素没有被控制（例如，没有控制行驶里程，这将使卡车看起来相对更差，豪华车辆看起来更好；也没有控制农村与城市行驶里程，这也将产生相同方向的影响）。看到数字受混杂因素影响的一个方法是查看汽车的全轮驱动或四轮驱动与两轮驱动版本。它们通常有截然不同的死亡率，尽管安全差异并不大（而且差异通常有利于两轮驱动车辆）。一些合理的原因包括随机噪声、购买同一车辆不同版本的人的差异，以及车辆使用方式的差异。

如果我们想回答“哪些汽车品牌或型号更安全或不那么安全”的问题，我不认为任何公开可用的汇总令人满意，我认为我们需要查看源数据并进行自己的分析，以查看数据是否与我们在碰撞测试结果中看到的相符。

结论

我们查看了12个不同汽车品牌以及当IIHS添加小重叠测试时它们的表现。我们看到只有沃尔沃在公司因IIHS公开羞辱小重叠安全性差之前就认真对待这种事故，尽管小重叠碰撞至少自90年代以来就被认为是死亡的重要来源。

虽然我没有预算进行其他测试，例如在完全占用的车辆中进行后部碰撞测试，但似乎合理甚至可能的是，大多数非沃尔沃的汽车制造商如果测试机构决定添加另一种类型的碰撞测试，将会得到一般或差的测试分数。

额外：“真正的工程”与编程

正如Hillel Wayne所指出的，尽管程序员通常对“真正的工程师”做什么有理想化的看法，但当你比较“真正的工程师”所做的与程序员所做的，通常并没有那么不同。特别是，程序员常见的抱怨是他们不需要为他们的错误或糟糕设计承担责任，即使在那些造成生命损失的情况下。

虽然汽车公司可以在某些情况下因不安全设计而承担责任，但仅仅优化一组小范围的基准测试（这肯定导致了额外的死亡，而不是优化安全性而不是基准分数），并不是工程师或公司通常被追究责任的事情。

额外：声誉

如果我看看我扩展社交圈的人对车辆安全的看法，特斯拉的声誉遥遥领先。如果你看广泛的消费者调查，情况就不同了，沃尔沃通常获胜，其他制造商争夺遥远的第二名。

我觉得特斯拉的事情很有趣，因为他们的回应基本上与你从一家认真对待安全的公司所期望的相反。当发生严重问题（关于安全或其他方面）时，他们通常有非常快速的回应，基本上是“一切正常”。我期望一个认真对待安全或改进的组织回应“我们正在调查”，然后发布详细的事后分析解释哪里出了问题，但这似乎不是特斯拉的风格。

例如，在驾驶员侧小重叠测试中，特斯拉有一个相关得分的型号，即使在修改后改进分数，它也得分为可接受（低于良好，但高于差和边缘）。特斯拉对结果提出异议，称他们制造“历史上最安全的汽车”，并暗示应忽略IIHS，因为他们有不良动机，转而支持一个客观且没有不良动机的机构的碰撞测试分数，即给予特斯拉好分数的机构：

虽然IIHS和世界各地数十家其他私人行业组织有自己的方法和动机以适合其主观目的，但目前最客观和准确的独立车辆安全测试由美国政府完成，该政府发现Model S和Model X是其测试过的所有汽车中受伤概率最低的两辆车，使它们成为历史上最安全的汽车。

正如我们所看到的，特斯拉并不罕见地优化一组特定的碰撞测试并在意外类型的碰撞中获得一般的分数，但他们的回应是不寻常的。然而，从愤世嫉俗的公共关系角度来看，这是有道理的。正如我们在过去几年中看到的，大声宣称某事，无论是否真实，即使有确凿证据表明它是不真实的，似乎不仅有效，这种夸大的言辞似乎吸引超级粉丝，他们会积极捍卫品牌。如果你在youtube上观看汽车评论员，他们有时会提到他们收到仇恨邮件，因为他们像评论任何其他汽车一样评论特斯拉，而他们没有看到任何其他品牌有类似情况。

苹果在90年代和00年代初也有效地使用了这个剧本，当时他们在性能上迅速落后，并没有通过提高性能来回应，而是进行了一系列广告宣传活动，声称他们拥有世界上最好的性能，并在桌面上发布“超级计算机”。

另一个声誉怪癖是我认识相当多的人认为他们能买到的最安全的汽车是“60年代和70年代制造的美国汽车，不是塑料制成的”。我们没有直接相关的小重叠碰撞测试分数对于旧车，但我们确实有的关于旧车的测试数据表明，它们在整体安全性方面与现代汽车相比表现极差。例如，查看这辆1959年雪佛兰Bel Air与2009年雪佛兰Malibu的碰撞测试。

附录：方法摘要

顶部结果部分使用小重叠测试的分数，因为我认为它是测试测量的安全性最难偷工减料的，并且它已经存在足够长的时间，我们可以看到修改现有型号和后续型号变化的影响，这对乘客侧小重叠测试不成立（其中许多型号仍未测试）。

对于乘客侧小重叠测试，有人可能争辩说驾驶员侧更重要，因为你几乎总是有驾驶员在车祸中，可能有前排乘客也可能没有。此外，对于小重叠碰撞（模拟只有25%重叠的头对头碰撞），驾驶员侧碰撞比乘客侧碰撞更可能发生。

除了检查沃尔沃的分数，我没有查看车顶碰撞测试分数（于2009年添加）。我不打算详细描述车顶测试，但对于车顶测试，有人可能争辩说车顶测试分数应与车辆的翻滚概率评分一起使用，因为车顶测试只测试车顶强度，这只与车辆翻滚相关。我认为，鉴于数据所示，这种反对在许多情况下不成立（车顶测试分数最差的车辆通常是翻滚率相对较高的车辆），但在某些情况下成立，这将使分析复杂化。

在大多数情况下，我们每个型号只得到一个报告的测试结果。然而，一个型号可能有多个版本——包括在进行旨在改进测试分数的安全变化之前和之后。如果对型号进行了以改进安全性的更改，测试分数通常是在更改之后，我们通常看不到更改之前的分数。然而，有许多例外情况，这些在详细结果部分有说明。

在本文中，分数只在型号在新测试引入之前或附近引入时才计数，因为后来引入的型号可能有针对测试进行优化的设计更改。

附录：详细结果

在每个测试中，IIHS给出一个整体评级（从最差到最好）为差、边缘、可接受或良好。测试有子分数，但我们不打算在此分析中使用。在每个子部分中，我们将查看当小重叠测试添加时有多少型号获得了每个分数。

沃尔沃

所有被检查的沃尔沃型号在测试添加时（车顶、驾驶员侧小重叠和乘客侧小重叠）都得分为良好（最高可能分数）。一个型号，2008-2017 XC60，在2013年进行了更改以在侧帘气囊在小重叠碰撞中触发。其他型号未经修改即被测试。

梅赛德斯

在三个具有驾驶员侧小重叠测试结果的预先存在的型号中，一个未经修改得分为边缘，两个在结构修改后得分为良好。我们只有未经修改测试分数的型号（梅赛德斯C级）在2014年后不久进行了全面重新设计，就在驾驶员侧小重叠测试引入后不久。

如上所述，我们通常只能看到未经修改的型号或经过修改的型号的公共结果，因此，对于得分为良好的型号，我们实际上不知道如果你在梅赛德斯更新设计之前购买车辆会如何得分，但我们拥有未经修改的一个型号的边缘分数是一个负面信号。

此外，当乘客侧小重叠测试添加时，梅赛德斯车辆通常也得分为良好。这表明梅赛德斯不仅在驾驶员侧增加了保护以提高测试分数。

宝马

在两个我们有相关测试分数的型号中，两个都在修改前得分为边缘。在其中一个案例中，还有在2017型号中进行结构更改后的分数（回想一下驾驶员侧小重叠测试于2012年引入），该型号之后得分为良好。另一个型号在2016年后进行了全面重新设计。

对于五个我们有相关乘客侧小重叠分数的型号，所有都得分为良好，表明为提高驾驶员侧小重叠测试分数而进行的更改不仅仅是在驾驶员侧进行。

本田

在五个我们有相关驾驶员侧小重叠测试分数的本田型号中，两个得分为良好，一个得分为边缘，两个得分为差。得分为边缘的型号在2015年进行了结构更改和安全带更改，将其分数改为良好，其他型号未更新或没有更新的IIHS分数。

在六个我们有乘客驾驶员侧小重叠测试分数的本田型号中，两个未经修改得分为良好，两个未经修改得分为可接受，一个在修改保险杠后得分为良好。

所有这些型号在驾驶员侧小重叠测试中都得分为良好，表明当本田增加驾驶员侧安全性以在驾驶员侧测试中得分为良好时，他们没有将相同的更改应用于乘客侧。

丰田

在六个我们有未经修改型号相关驾驶员侧小重叠测试分数的丰田型号中，一个得分为可接受，四个得分为边缘，一个得分为差。

得分为可接受的型号进行了结构更改以将其分数提高到良好，但仅限于驾驶员侧。该型号后来在乘客侧小重叠测试中被测试并得分为可接受。在四个得分为边缘的型号中，一个在2017年进行了结构修改，将其分数提高到良好，另一个进行了气囊和安全带更改，将其分数提高到可接受。得分为差的型号在2014年进行了结构更改，将其分数提高到可接受，随后进行了进一步更改，将其分数提高到良好。

还有四个型号我们只有修改后的分数。其中，一个得分为良好，一个得分为可接受，一个得分为边缘，一个得分为差。

总的来说，更改似乎只进行在驾驶员侧，并且在乘客侧小重叠测试引入时，车辆乘客侧小重叠分数与修改前的驾驶员侧分数相同。

福特

在两个我们有未经修改型号相关驾驶员侧小重叠测试分数的型号中，一个得分为边缘，一个得分为差。这两个型号都生产到2019年，两者都没有更新的测试结果。在三个我们有修改车辆相关结果的型号中，两个得分为可接受，一个得分为边缘。还有一个型号在小重叠测试引入的年份发布，另一个在之后一年发布；两者都得分为可接受。不清楚这些是否应被视为修改，因为设计可能在发布前进行了最后一刻的更改。

我们只有三个相关的乘客侧小重叠测试。一个是良好（对于2015年发布的型号），另外两个是差；这些是上面提到的在驾驶员侧小重叠测试中分别得分为边缘和差的两个型号。这些型号似乎继续生产到2019年，没有进行安全更改。这两个未经修改的型号都是卡车，这对于卡车来说并不罕见，这也是卡车死亡率普遍较高的一个原因——直到最近，许多卡车基于旧平台，很长时间没有更新。

雪佛兰

在三个我们有修改前相关驾驶员侧小重叠测试分数的雪佛兰型号中，一个得分为可接受，两个得分为边缘。其中一个边缘型号在2015年进行了结构更改以及导致侧帘气囊更早展开的更改，这将其分数提高到良好。

在四个我们只有修改后相关驾驶员侧小重叠测试分数的雪佛兰型号中（所有都进行了结构修改），两个得分为良好，两个得分为可接受。

我们只有一个相关的乘客侧小重叠测试分数，那个分数是边缘。那是在修改以将驾驶员侧小重叠测试分数从边缘提高到良好的型号上，表明更改是为了提高驾驶员侧测试分数而不是提高乘客安全性。

斯巴鲁

我们没有任何型号在修改前有相关乘客侧小重叠测试分数。

一个型号进行了更改以使其气囊在小重叠测试中展开；它得分为可接受。两个型号进行了某种结构更改，其中一个得分为良好，一个得分为可接受。

进行气囊更改的型号在2015年进行了结构更改，将其分数从可接受提高到良好。

对于一个我们有相关乘客侧小重叠测试分数的型号，分数是边缘。此外，对于一个进行结构更改的型号，据指出，在更改中，包括防火墙左侧部分的更改，表明更改是为了提高驾驶员侧测试分数，而不是提高乘客侧小重叠碰撞中的乘客安全性。

特斯拉

只有一个型号有驾驶员侧小重叠测试的相关结果。该型号在修改前和修改后都得分为可接受。

现代

在五个我们有相关驾驶员侧小重叠测试分数的车辆中，一个得分为可接受，三个得分为边缘，一个得分为差。我们没有迹象表明型号被修改以提高其测试分数。

在两个我们有未经修改型号相关乘客侧小重叠测试分数的车辆中，一个得分为良好，一个得分为可接受。

我们还有一个型号的分数，该型号进行了结构修改以得分为可接受，后来进行了进一步修改，允许其得分为良好。该型号于2017年推出，在未修改的情况下在驾驶员侧小重叠测试中得分为良好，表明它被设计为在驾驶员侧测试中取得良好分数，而没有对乘客侧碰撞的类似考虑。

道奇

在五个我们有未经修改型号相关驾驶员侧小重叠测试分数的型号中，两个得分为可接受，一个得分为边缘，两个得分为差。还有两个型号在2015年为安全进行了结构更改后有测试分数；两个都得分为边缘。

我们没有任何型号的相关乘客侧小重叠测试分数，但即使有，修改后型号的糟糕分数意味着我们可能无法知道是否进行了类似的更改到乘客侧。

日产

在七个我们有未经修改型号相关驾驶员侧小重叠测试分数的型号中，两个得分为可接受，五个得分为差。

我们有一个型号只有修改后型号的测试分数；正面气囊和安全带在2013年进行了修改，侧帘气囊在2017年进行了修改。修改后的分数是边缘。

一个得分为差的型号在2015年进行了结构更改，将其分数提高到良好。

在四个我们有相关乘客侧小重叠测试分数的型号中，两个得分为良好，一个得分为可接受（该型号在驾驶员侧测试中得分为良好），一个得分为边缘（该型号在驾驶员侧测试中也得分为边缘）。

吉普

在两个我们有未经修改型号相关驾驶员侧小重叠测试分数的型号中，一个得分为边缘，一个得分为差。

有一个型号我们只有修改后的测试分数；该型号的气囊和安全带进行了更改，更改后得分为边缘。该型号后来也在乘客侧小重叠测试中被测试并得分为差。

另一个型号有相关的乘客侧小重叠测试分数；它得分为良好。

大众

两个我们有未经修改型号相关驾驶员侧小重叠测试分数的型号都得分为边缘。

在两个我们只有修改后分数的型号中，一个在2013年进行了修改，修改后得分为边缘。它然后在2015年再次修改，修改后得分为良好。该型号后来在乘客侧小重叠测试中被测试，其中得分为可接受，表明更改有差别地有利于驾驶员侧。另一个在2015年进行更改后得分为可接受，然后在2016年进行进一步更改后得分为良好。2016型号后来在乘客侧小重叠测试中被测试并得分为边缘，再次表明更改有差别地有利于驾驶员侧。

我们有另外两个型号的乘客侧小重叠测试，两者都得分为可接受。这些是在驾驶员侧小重叠测试引入很久之后于2015年推出的型号，并在驾驶员侧小重叠测试中得分为良好。

2021年更新

IIHS发布了他们新的“升级”侧面碰撞测试的第一组结果。他们一直在谈论做这个已经有一段时间了，并提到在真实世界数据（一些）严重碰撞中，他们观察到车厢侵入显著大于他们测试中所见的。他们提到一些车辆在新测试中表现相对较好，一些表现较差，但直到现在才发布官方分数。

新侧面碰撞测试的结果与本文中描述的结果不同。到目前为止，只有小型SUV的结果被发布，只有马自达CX-5得分为“良好”。在本文中测试中表现良好的三个制造商中，只有沃尔沃有公共结果，他们得分为“可接受”。我有一些问题：

• 沃尔沃的其他型号（他们的大多数车辆基于与具有公共结果的车辆不同的平台）会得分更好吗？
• 沃尔沃会快速更新他们的车辆以在测试中获得最高分吗？与许多其他制造商不同，我们没有来自沃尔沃的最近数据，因为他们不需要更新他们的车辆以在最后两个新测试中获得最高分
• 宝马和梅赛德斯要么在新测试中得分良好，要么再次快速更新他们的车辆以得分良好吗？
• 其他马自达车辆也会在没有更新的情况下得分良好吗？

2024年更新

在2024年对2018-2022年每英里死亡率的分析中，最差的汽车制造商从最差开始是特斯拉、起亚、别克、道奇，然后是现代。别克在本文中未排名，起亚和现代被视为等同，因此在排名的四个品牌中，三个在这个评级中得分最差。并且，正如本文最初指出的，特斯拉不太适合分类，并且显示为安全最差的迹象，也可能平均，并且在某些维度上（ADAS / 自动驾驶），特斯拉似乎安全性非常差，因此有充分的理由认为特斯拉也应被置于最差类别。

还要注意，三个评级良好的制造商中没有一个在每英里最高死亡率型号列表中有一个型号。但很难说有多少是关于汽车的，有多少是关于其他属性（如汽车的使用方式），因为每英里死亡率与汽车价格呈相当强的负相关，并且所有三个制造商都是豪华品牌，其售价远高于平均。豪华车也往往比平均更大更重，而重量也与每英里死亡率负相关。

在排名的时间段内，特斯拉似乎拥有最高的平均售价（甚至高于三个顶级豪华品牌），并且每辆车重量也远高于中位数，使得特斯拉成为每英里死亡率的极端异常值。

附录：杂项

一些名牌汽车品牌未被包括。有些因为它们在美国的销量相对较低和/或迅速下降（三菱、菲亚特、阿尔法·罗密欧等），有些因为测试的车辆重叠度很高（起亚、马自达、奥迪），有些因为没有具有驾驶员侧小重叠测试分数的相关型号（雷克萨斯）。当一家公司拥有多个品牌时，如FCA拥有吉普、道奇、克莱斯勒、公羊等，这些没有被汇总，因为大多数不是汽车迷的人不会认识到FCA，但可能认识到吉普、道奇和克莱斯勒。

如果API的服务条款允许你以任何方式使用IIHS数据，我会包括较小的品牌，但由于API附有关于如何显示或讨论数据的非常严格的条款，这些条款与探索性数据分析不兼容，并且在查看数据之前我不知道我想要如何显示或讨论数据，所以我手动提取了所有这些结果（并且没有点击任何最终用户许可协议等），这相当耗时，因此在更全面覆盖和我生活的其余部分之间存在权衡。

附录：我应该买什么车？

这取决于你在寻找什么，没有办法提出全面的建议。有关特定车辆的实用信息，Alex on Autos是我知道的最佳来源。我通常不喜欢视频作为实用信息的来源，但汽车杂志往往比youtube汽车评论员信息量少得多。有更受欢迎的汽车评论员，但他们的受欢迎似乎来自于有魅力的联合主持人之间的机智聊天或其他不仅不直接提供信息，实际上还减少了信息提供的事情。如果你只想知道汽车如何工作，Engineering Explained也相当不错，但那里的信息通常不实用。

对于可靠性信息，《消费者报告》可能是你最好的选择（你也可以查看J.D. Power，但他们聚合信息的方式使其对消费者来说用处大大降低）。

感谢Leah Hanson、Travis Downs、Prabin Paudel、Jeshua Smith和Justin Blank的评论/纠正/讨论

由 mimo-v2.5 模型翻译，花费 23242 tokens

这是一篇90年代匿名发表的旧文存档，作者使用的化名似乎已从互联网上消失。

我注意到《星际迷航：航海家号》新增了一个角色，一个博格人。（从剧照看，24世纪他们仍在为女性培育胸部尺寸。）让我恼火的是制片人的评论（我概括一下），"七的加入将为我们提供无限的故事可能性。"

哦。真的吗。

听着，他们根本没有认识到自己已有的故事潜力。我看了几集《航海家号》，当我的"胡扯探测器"爆表时就弃剧了。（也许只看几集就评判他们不太公平。但让我忍受"全息肺"这种玩意儿也不公平啊。）

对于那些不看《星际迷航：航海家号》的人，其设定是这样的：星舰"航海家号"，一种太空轻型护卫舰，被传送到了距离其应到之处亿万光年之外的地方。以最高速度计算，他们需要超过七十年才能返回家园与亲人团聚。出于某些我们无需在此深究的原因，船员由忠诚的星际联邦成员和叛军混合组成。

在纸面上，这看起来不错。船员间有不稳定的联盟，有返航途中的探索，还有整套"太空孤岛"的戏码。而且《航海家号》远没有《进取号》那么大——人在上面待那么久对心理健康不利。

但是这个点子真能撑起一整部剧吗？连续看五年"船员斗嘴"或者"他们找到超光速星际旅行的新线索但又落空"会有趣吗？我认为不会。

（事实上，船员们太快就安顿下来了。）

电视剧集的需求颠覆了设定。电视剧的基本需求是让观众认识并关心我们的常驻角色——我们希望他们每周都出现在客厅。我们必须关心他们的变化、需求和愿望。当他们陷入险境时我们必须担心。但我们知道这是电视剧，所以很难真正担心。我们知道角色下周还会回来。

而故事的需求则要求某人自愿改变，认识到某种差异。改变的需要可以从外部强加，但实际的改变必须是自我驱动的。（这是电视剧的基本悖论：唯一被允许改变的是客串角色，但促成改变的工具必须是常驻角色，因此剥夺了两个角色做有趣事情的机会。）

具有严格剧集连续性的剧集（第二集必须承接第一集）允许改变——但它们在剧集停播后进入联合播放时更难销售。经济因素有利于角色一成不变。

一些剧集——比如《希街蓝调》——通过让角色真正可有可无来规避险境问题。有些角色出场几集后就死了，提醒我们常驻角色也可能如此。有时常驻角色确实会死。

（当角色在试播集就发生改变时，可能会有问题。一位被邀请为玛丽·泰勒·摩尔最后一部剧工作的编剧从设定中看出，它只够精彩六集，之后便无路可走。福克斯电视台由蒂娅·里奥尼主演的首部剧集《飞行盲区》，试播集非常有趣，但设定了一个无法维系的情境。）

有人告诉我，《航海家号》唯一有趣的角色一直是那个可以改变的医生。他是唯一被允许成长的角色。

因此，《航海家号》的第一个问题是角色不允许改变——或者改变是外部强加的。（顺便说一句，强加的改变是开始故事的好方法。角色随后会反抗，这很有趣。但它也是结束故事的糟糕方式。）

第二个问题是他们没有利用好手头的元素。回到第一季。有一集讲船上有个叛徒，和珍威舰长一样聪明。（精神病学测试怎么会漏掉这个，我不知道，但星际迷航宇宙的精神病学一直运气不佳。）在牵着珍威鼻子走了五十分钟后，她识破了他，并与他对质。他承认了——然后传送离开了飞船，方便地与当地人达成了交易。

对电视剧来说这很完美。我们有了一个据称聪明的反派在外面可能回来，珍威也遇到了对手——但我感觉被耍了。故事在哪？结局在哪？

我认为他们应该这样做。这不是传统电视剧的做法，但我认为它会是更好的故事。

首先，这集应该在珍威与坏人对质并逮捕他时结束。他被关进禁闭室——并且一直关着。观众会在这里获得一些胜利感。

但现在禁闭室里有个和珍威一样聪明的人。突然间，我们设定了《沉默的羔羊》。（我不介意"借鉴"，如果借鉴的是好来源。）每当问题足够大时，珍威就有这个选择：她可以去禁闭室，试图与坏人达成交易。"飞船完蛋，你也完蛋。"不仅如此，船上还有个与他有独特关系的人——一种不受正式军衔约束的关系。坏人到底想要什么？

每当珍威情绪低落时，他可以嘲讽她。"顺便说一句，我想到一个办法能让大家用十分之一的时间回家。你呢，舰长？"

你不会让他每集都出现。但任何时候你需要那额外的推动，他就在那里。记住，我们可以通过与原集相同的戏法让他随时逃脱。

此外，抓住他是一回事；关住他是另一回事。你可以用一次囚犯越狱尝试来生成另一整集故事。但那会是中间部分。让我们谈谈我希望看到的结局。

让我们虚构一场危机。博格能发电机爆炸；我们深处曲速空间；我们出色的技术员团队拼凑修复了传感器，发现了一颗可能适合修复的M级行星。只是它太远了。余量很小——但并非不可能。船上多了两个人。每个人需要一定量的食物、空气、水等。在压力下，尼利克斯承认他的族人可以进入假死状态，于是他这么做了。医生英勇尝试，但负责维护博格能发电机的工程师死了。（嗯。电力不足。医生只能在某些关键时刻被唤醒。）看起来不错——但他们一直在消耗空气直到死亡；必须再死一个船员，其余人才能活下去。

有人想起了禁闭室里的那个人。"他有罪的问题，"图沃克说，"已经解决。舰长的权威是绝对的。你完全有权举行简易军事法庭并判处他死刑。"

珍威拒绝了。"星际联邦不这样做。"

但如果她不这么做，所有人都会死。压力现在来到了珍威这边。作为珍威，她在寻找技术解决方案。"找到答案，该死！"最后期限临近。过了某个时点，囚犯必须死，连同另一个人一起。

一名船员（常驻角色）自愿赴死。在珍威接受前，另一名（常驻角色）船员也自愿了，珍威被迫做出决定。——图沃克指出，虽然如果该成员自愿赴死在道德上可以辩护，但飞船没有这两个船员中任何一个都无法继续运行。没有囚犯却可以继续。显然囚犯不如那些船员有价值，但她是舰长。必须做出这个决定。

我们无畏的技术团队认为可能有解决方案，但会耗尽几乎所有储备，他们需要另外六个小时来评估可行性。船上有人试图为她解决问题——杀掉囚犯——失败消耗了更多宝贵电力。现在最后期限提前了，超过了六小时的期限。技术团队的方案不再可行。

就囚犯而言，他现在开始讨价还价。他说他有办法帮忙。真的吗？他曾试图摧毁飞船。而且他不会在获得完全赦免前透露方法。

（这些都是基本的情节设计：不断堆积困难。在角色面前放个胡萝卜，不断把它拽走。）

棘手的部分是结局。要求结局必须合乎逻辑地从前文推导出来。如果你要使用技术解决手段，就必须在剧集前半段做好铺垫。否则就是技术废话。就是机械降神。（每当有人在最后广告休息后说："当然！如果我们反相抗波子流，就没事了！"我就想给编剧脑袋来一下。）

根据这里设定的情境，我们有三种可能的结局：

• 某位船员试图通过自我牺牲来解决问题。（记住，麦考伊和史波克这么做过。）这是个薄弱的解决方案（除非珍威这么做），因为它转移了对珍威决定的焦点。
• 珍威与囚犯达成协议，他们一起想出解决方案（不涉及抗波子流）。这会产生有趣的后续影响：给予囚犯自由——同时船上所有人都恨透了他。至少可以作为另一集的素材。
• 珍威杀死囚犯但拒绝举行军事法庭。她可能侥幸成功——囚犯可能幸存；他们一直祈求但不能依赖的百万分之一机会实现了——但她决定杀死囚犯而非自己的船员。

我倾向的结局是第三种，即使囚犯不必死。我们设定的决定是艰难的，且意义重大。这是一个指挥决策。她最终是否杀死囚犯并不重要；重要的是她决定这么做。

约翰·加利肖曾将所有故事归类为成就故事或决策故事。决策故事更难写，因为两种选择都必须有意义。

由 mimo-v2.5 模型翻译，花费 5358 tokens

许多人似乎认为分布式追踪没有用，或者至少没有极大力气就不值得，对于比FB小的公司来说更是如此。例如，这里有 一些公开对话，听起来像我经历过的许多私下对话。当然，价值存在于某处，但解锁它的成本太高了。

我认为这高估了从追踪中获取大量价值所需的工作量。在Twitter，Rebecca Isaacs能够描绘出从追踪中获取价值的愿景并加以执行（得到了许多其他人的帮助，包括Jonathan Simms、Yuri Vishnevsky、Ruben Oanta、Dave Rusek、Hamdi Allam等许多人¹），使得工作很容易收回成本。本文将描述我们构建的追踪“基础设施”，并描述一些我们发现其有价值的用例。在此之前，让我们先了解Rebecca愿景实现前的一些背景情况。

在高层次上，我们可以说我们有一个以追踪视图为导向的系统，并遇到了所有可能预期的那些问题。这些问题在Cindy Sridharan的这篇文章中有更详细的讨论。然而，我想更详细地讨论我们遇到的具体问题，因为我认为看看哪些具体事物导致了问题是有用的。

总的来说，这些问题足够严重，以至于追踪多年缺乏所有权，甚至可以说是无人负责。有些人利用业余时间维护或改进，但缺乏从追踪中获取明显价值导致了一个恶性循环：从追踪中获取价值的高壁垒使得组织难以资助，从而使得让追踪更可用变得困难。

一些导致追踪投资回报率低的问题包括：

• 模式使得无法在“原位”运行简单查询
• 没有真正的聚合信息方式
  • 无法找到有趣或有代表性的追踪
• 无法知道实际采样率，采样高度非代表性
• 时间

模式

模式实际上是一组追踪，其中每个追踪是一组跨度，每个跨度是一组注释。每个非根跨度都有一个指向其父跨度的指针，因此可以确定追踪的图结构。

就本文而言，我们可以将每个追踪视为包括所有子RPC的外部请求，或请求的子集，而不是在请求顶部作为根。我们也追踪一些非请求的东西，如构建和git操作，但为简单起见，我们将在本文中忽略这些，尽管我们将讨论的技术也适用于它们。

每个跨度对应一个RPC，每个注释是开发者选择记录在跨度上的数据（例如，RPC负载大小、跨度时系统中各种队列的队列深度，或中断RPC的GC暂停的GC暂停时间）。

从具有集合（集合）模式中产生的一些问题包括：

• 执行任何使用追踪固有图结构信息的查询需要读取追踪中的每个跨度并重建图
• 因为没有每个追踪信息的索引或摘要信息，任何对追踪的查询都需要读取追踪中的每个跨度
• 实际上，由于上述两项在查询时以临时方式执行成本过高，人们运行的唯一查询是“给我几个匹配简单过滤器的跨度”的某种变体

聚合

直到大约一年半前，查看追踪的唯一支持方式是去UI，从搜索框和下拉菜单的组合中按服务名过滤，然后查看最近追踪的列表，其中您可以点击任何追踪以获得“追踪视图”。每个搜索返回N个最近的结果，这些结果不一定代表所有最近的结果（原因在下面的采样部分提到），更不用说代表任何其他时间跨度的所有结果了。

根据上述模式部分讨论的问题，由于跨大量运行查询成本过高，无法提出诸如“我正在查看的任何追踪是否代表常见追踪，或者我正在查看的是奇怪的边缘情况？”或“显示特定尾部事件的追踪，例如，当服务A到服务B的请求超时或当服务A到某个后端数据库的写放大> 3倍时”，或甚至“只显示我完整的追踪，即我们没有丢弃追踪中的跨度的追踪”之类的问题。

此外，如果您点击一个“太大”的追踪，查询会超时，您将无法查看追踪——这是缺乏任何速率限制逻辑加上模式的另一个常见副作用。

采样

在多个地方做出了采样或不采样的决定。没有列出所有这些地方的文档，甚至无法猜测采样率，而无需审计所有代码以找出采样决定的位置。

此外，在多个地方由于实现而做出了无意的采样决定。跨度从启用追踪的服务发送到本地代理，然后到“收集器”服务，然后从收集器服务发送到我们的后端数据库。跨度可能在这些点中的任何一个被丢弃：在本地代理中；在收集器中，其节点经常崩溃并丢失所有数据；以及在后端数据库中，后者因热键或一般高负载而拒绝写入。

这种以追踪ID为数据库键的设计，没有中间逻辑来调节写入，意味着一个1M跨度的追踪（我们有）会在几秒内导致1M次写入同一个键。另一个问题是有成千上万扇出的请求（在我工作过的每家科技公司都存在），这可能在几毫秒内导致数千次写入同一个键。

另一个采样怪癖是，为了避免错过不从前端开始的追踪，逻辑导致每个RPC独立采样决定。如果你做一下数学计算，如果你有一个像我们这样的面向服务的架构，采样率听起来像中等偏低，比如，你最终大部分跨度将从叶子RPC开始，导致单跨度追踪。对于非叶子RPC，大部分将从叶子的第二层开始，以此类推。我们大部分负载和存储成本来自这些实际上无用的追踪，从或接近叶子开始，如果你想对跨度做任何分析以了解整个系统的行为，你必须在计算所有其他独立采样决定的同时考虑这个采样偏差。

时间

没有真正针对时钟偏移进行调整（有一些，但它试图进行本地成对调整，这实际上没有改善情况，反而使合理考虑时钟偏移更加困难）。

如果您只是天真地计算跨度花费的时间，甚至使用来自单个主机的时间戳（这消除了许多可能的时钟偏移来源），您会得到很多负持续时间的跨度，这当然是不可能的，因为结果不能在创建结果请求之前返回。而且如果您比较不同主机上的时间，结果更糟。

解决方案

这些问题的解决方案分为我认为的两个桶。对于诸如收集器节点崩溃或后端数据库丢弃请求导致的跨度丢失等问题，有一些使用众所周知且广泛使用的技术的直接工程解决方案。对于这一对特定问题，短期权宜之计是进行一些GC调优，将收集器节点崩溃率降低约100倍。这只需要两分钟，然后我们用真正的队列替换了收集器节点，该队列可以吸收更大的流量突发并调节写入数据库。对于我们在每次RPC上掷采样骰子导致过采样叶子级跨度的问题，这是大多数人在面试中会做对的小问题之一，有时在作为较大系统的一部分时可能会丢失，有多种解决方案，例如，由于每个跨度都有父指针，我们可以在相关位置知道RPC是否有父节点，并且我们可以做出采样决定，并仅当跨度没有父指针时创建traceid，这导致每个跨度被采样的均匀概率，每个采样追踪都是完整追踪。

另一个桶是构建数据集和工具（并添加注释），允许用户回答他们可能有的问题。这不是一个新想法，Dapper论文的第5部分在2010年就讨论过。

当然，一个主要区别是Google可能在Dapper上投入了至少两个数量级的努力来构建工具，而我们在追踪基础设施上投入的工具建设少得多，因此我们的许多工具粗糙得多，例如，Dapper论文的图6显示了一个追踪视图，显示一组相关直方图，使理解追踪上下文变得容易。我们还没有做那个UI工作，所以类似的视图需要运行一个简单的SQL查询。虽然这并不难，但向用户提供数据比让用户查询数据是更好的用户体验。

在已完成的工作中，最简单的明显高ROI的事情是构建一组包含人们可能想查询的信息的表，结构使得常见的查询不需要做大量工作。

我们按天分区有以下表：

• trace_index
  • 高级追踪级信息，例如，追踪是否有根；根是什么；如果相关，命中的请求端点是什么等。
• span_index
  • 关于客户端和服务器的信息
• anno_index
  • 人们经常想查询的“标准”注释，例如，请求和响应负载大小、客户端/服务器发送/接收时间戳等。
• span_metrics
  • 计算的指标，例如，跨度持续时间
• flat_annotation
  • 所有注释，以防您想查询不在anno_index中的内容
• trace_graph
  • 对于每个追踪，包含追踪的图表示，用于需要图结构的查询

仅仅拥有这组表，可以通过SQL查询（或在某些情况下使用Scalding或Spark作业，例如进行图查询时Presto SQL不理想）查询，就足以让追踪收回成本，从难以证明合理到明显高价值。

我们可以用这组表回答的一些问题包括：

• 对于这个有问题的服务，给我一组有代表性的追踪
• 对于负载增加的服务，显示是哪个上游服务导致了负载
• 给我所有对下游服务X有异常写放大的服务列表
  • 来自特定服务或特定端点的流量是否导致异常写放大？例如，在某些情况下，我们看到B到C的总写放大没有异常，但当B由A调用时，B到C的放大率非常高。
• 显示我们对各种请求在序列化/反序列化上与“实际工作”相比花费的时间
• 显示不同类型的请求在后端工作方面的成本
• 对于移动端检测到的高延迟请求，显示后端发生了什么
• 显示此请求端点的延迟关键路径集（使用我们目前的注释，这有一些问题，可能值得单独发文）
• 显示此服务依赖的服务的CDF
  • 这是一个分布，因为特定服务是否调用另一个服务是数据相关的；一个服务平均每1000次调用才调用另一个服务并不罕见

我们正在构建和构建其他工具，但仅仅能够轻松地对追踪数据（包括最近和历史数据）运行查询和聚合，就足以收回我们想要进行的所有其他工作的成本。这类似于我们在查看指标数据时看到的情况，获取我们已有的数据并以一种让人们立即运行任意查询的方式暴露出来立即产生了回报。为追踪这样做不如为指标这样做直接，因为数据更丰富，但它不是一个根本不同的想法。

我认为拥有除了原始数据之外的东西查看对追踪也比对指标更重要，因为指标的原始“追踪视图”等价物，一个“仪表板视图”其中您只是查看图表，显然且直观有用。如果那是您为指标拥有的全部，人们不会说不值得资助您的指标基础设施，因为仪表板真的很有用！然而，很难看到如何从原始追踪视图中获取价值，这是许多关于追踪无价值评论的来源。指标数据和追踪数据之间的这种复杂性差异使得高层追踪视图的附加值大于指标。

将我们的数据以非NoSQL数据库中块状格式存储也使我们更容易在追踪数据上构建工具，让不想运行SQL查询的用户从我们的追踪数据中获取价值。一个例子是服务依赖探索器（SDE），主要由Yuri Vishnevsky、Rebecca Isaacs和Jonathan Simms构建，得到了Yihong Chen的帮助。如果我们尝试查看单个请求的RPC调用图，我们会得到相当大的内容。在某些情况下，调用树的深度可能达到数百层，并且在某些层看到20或更多的扇出也很常见，这使得天真可视化难以解释。

为了了解SDE的工作原理，让我们看一个较小的例子，其中相对容易理解正在发生什么。想象我们有8个服务，A到H，它们如下树所示相互调用，我们有服务A被调用10次，总共调用服务B10次，B分别调用D、D和E 50、20和10次，其中两个D通过不同的RPC端点（调用）区分，即使它们是同一个服务，等等，如下所示：

如果我们从节点E的角度看SDE，我们会看到以下内容：

我们可以看到直接呼叫者和被呼叫者，E的100%调用来自C，并且E的100%调用也调用C，并且当调用C时我们有20倍负载放大（200/10 = 20），与我们在上面RPC树中看到的相同。如果我们查看间接被呼叫者，我们可以看到D有4倍负载放大（40 / 10 = 4）。

如果我们想查看E下游C直接调用的内容，我们可以选择它，我们将获得指向C的直接后代的箭头，在这种情况下，是E的所有间接被呼叫者。

对于更复杂的例子，我们可以查看服务D，它在我们的原始树中以橙色显示。

在这种情况下，我们的摘要框显示：

• 在2020年5月28日，有...
  • 10个总TFE根追踪
  • 110个总追踪到D的RPC
  • 2.1千个总由D引起的追踪RPC
  • 3个从TFE端点到D端点的唯一调用路径

我们在树中看到D三次的事实在摘要框中指示，它说我们有3个从我们的前端TFE到D的唯一调用路径。

我们可以展开对D的调用，在这种情况下，看到两个调用以及每个调用的流量比例。

如果我们点击其中一个调用，我们可以看到特定调用call4的上游和下游依赖关系，如下所示，我们可以看到即使服务D对于call3访问服务C、H和G，它也从不访问这些服务。类似地，我们可以看到其上游依赖包括直接被C调用，间接被B和E调用，但不被A和C调用：

我们从SDE可以轻松看到的一些事情是：

• 服务或RPC调用引起的负载
  • 我们有异常负载放大的地方，无论这是服务的一般情况还是仅发生在某些调用路径上
• 什么导致服务或RPC调用的负载
• 我们在哪里以及为什么得到循环（对于Strato等非常常见）
• 什么导致奇怪的超深追踪

这些都是用户可以通过查询我们存储的数据获得的事情，但拥有一个带有UI的工具，让您实时点击探索事情，降低了发现这些事情的障碍。

在上面显示的例子中，有少数服务，因此您可以从更常用的节点海洋视图中获得类似信息，其中每个节点是一个服务，可视化上有一些注释，但当我们查看真实追踪时，显示数千个服务和全局视图使得很难看清发生了什么。Rebecca的一些早期分析使用了这样的视图，但我们发现您需要很多隐含知识才能很好地使用这样的视图，一个丢弃更多信息并突出显示几件事的视图使得没有恰好具有正确隐含知识的用户更容易从查看追踪中获取价值。

虽然我们在这里演示了RPC计数/负载的视图，但我们也可以显示其他内容，如延迟、错误、负载大小等。

结论

更一般地说，这只是对我们在拥有基本分布式追踪设置后从数据中构建的几件事情的简要描述。您可能不想完全按照我们所做的做，因为您可能有不同的问题，并且您极不可能遇到我们的追踪基础设施遇到的确切问题集。通过与其他公司人士的私下交流，我不认为我们遇到的问题水平是唯一的；如果有什么不同的话，我们的追踪基础设施比许多或大多数同行公司（不包括FB/Google/Amazon等巨头）处于更好的状态，因为它基本上可以工作，人们可以并且确实使用我们拥有的追踪视图来调试真实的生产问题。但正如他们所说，不快乐的系统以自己的方式不快乐。

像我们之前对指标分析的看法一样，这项工作是增量完成的。由于追踪数据比指标数据丰富得多，在编写生成本文提到的表的Scalding（MapReduce）作业之前，我们花了更多时间进行临时数据分析，但个别分析足够有价值，以至于在最初的几周清理一些最糟糕的数据质量问题并使用现有基础设施运行（极其痛苦的）临时分析之后，这个项目集几乎没有不收回成本的时候。

回顾关于是否值得从事追踪基础设施工作的讨论，人们经常指出多家公司的众多失败来证明购买（而不是构建）决策的合理性。我认为这并非完全不合理，类似项目的基础失败率不应被忽视。但另一方面，描述的大多数工作并不超级棘手，除了获得组织认同和清楚了解追踪可以带来的价值之外。

有一点超出了本文范围，可能值得单独发文，那就是追踪和指标虽然不完全正交，但互补，只拥有其中一个会让你对许多问题视而不见。你将为此付出高昂代价，以各种方式：不必要的事件、额外的调试事件时间、由于运行基础设施效率低下而导致的更高货币成本等。此外，虽然指标和追踪各自比单独拥有任何一个提供更好的可见性，但一些问题需要同时查看两者；我做过的最有趣的分析之一涉及连接（通常使用字面SQL连接）追踪数据和指标数据。

具体来说，一个容易用追踪看到但用日志看很烦人的东西（除非您添加日志试图特别查找这一点，您可以为任何单个案例这样做，但可能不想为追踪使其可见的数千件事这样做），是我们上面看过的：“显示从负载均衡器到A的特定调用路径导致对服务B高负载放大的情况，B可能在调用图中距离A多跳。在某些情况下，这会很明显，因为A通常导致B高负载放大，但如果只在某些情况下发生，用追踪仍然容易处理，但如果您只看指标，那会非常烦人。

一个您需要连接追踪和指标数据的例子是查看像坏主机对延迟的性能影响。通常，您无法注释经过主机的适当跨度，因为如果您知道主机在跨度时是坏的，主机就不会在生产中。但您有时可以用历史数据找到一组坏主机，然后查看经过主机的延迟关键路径以确定坏主机的端到端影响。

每个人都有自己的偏见，关于追踪，我的偏见通常来自尝试直接改进成本、可靠性和延迟的工作，因此示例集中在这些方面，但追踪也有许多其他用途。您可以查看《Distributed Tracing in Practice》或《Mastering Distributed Tracing》以获取其他视角。

致谢

感谢Rebecca Isaacs、Leah Hanson、Yao Yue和Yuri Vishnevsky的评论/修正/讨论。

由 mimo-v2.5 模型翻译，花费 12965 tokens

1. 缓冲区太小，导致性能不佳，在高负载下有时会灾难性地变差。
2. 缓冲区太大，导致内存浪费，也就是金钱浪费。

但与其随机查看服务，我们完全有理由查询所有服务，并得到一个可以改进配置的服务列表，按性能降级或成本节省排序。如果我们为 JVM 幸存者空间编写了这个查询，它同样适用于其他配置参数（例如，其他 JVM 参数、CPU 配额、内存配额等）。然而，由于数据一致性和性能问题的组合，为所有服务编写一个工作的查询比我预期的要困难一些。数据一致性问题包括：

• 任何给定指标可能有约 100 个名称，例如，我发现了 94 个不同的 JVM 幸存者空间名称
  • 我怀疑还有更多，这些只是我通过简单搜索找到的
• 相同的指标名称可能对不同服务有不同含义
  • 可能是计数器或计量器
  • 可能有不同单位，例如，字节与 MB 或微秒与毫秒
• 指标有时被标记为错误的服务名称
• 僵尸分片可以在集群管理器启动新分片实例后继续运行并报告指标，导致特定分片名称的指标重复且不一致

我们的指标数据库 MetricsDB 是专门用于处理监控、仪表板、警报等的，不支持通用查询。这完全合理，因为监控和仪表板在可观测性需求的马斯洛层次结构中低于通用指标分析。在其他公司人士的非正式讨论中，围绕 MetricsDB 的整个系统似乎解决了困扰其他类似规模公司的问题，但其专业化意味着我们无法对 MetricsDB 中的指标运行任意 SQL 查询。

另一种查询数据的方法是使用写入 HDFS 的 Parquet 格式的副本，它允许人们运行任意 SQL 查询（以及编写消费数据的 Scalding（MapReduce）作业）。

不幸的是，由于指标名称数量众多，HDFS 上的数据无法以列式格式存储（每个名称一列）——Presto 如果列数过多会出问题，而我们有足够多的不同指标，远远超过了那个限制。如果不使用列式格式（并且不应用任何其他技巧），任何非平凡查询都会读取大量数据。结果是，你无法跨所有服务或所有主机运行任何非平凡查询（甚至许多平凡查询）而不超时。Scalding 没有类似的超时限制，但其性能要差得多，一个简单的 Scalding 查询针对一天的数据通常需要三到二十小时，具体取决于集群负载，这使得 Scalding 不适合任何探索性数据分析。

鉴于已有的数据基础设施，解决这两个问题的一个简单方法是编写一个 Scalding 作业，存储我们关心的性能或容量相关查询中 0.1% 到 0.01% 的指标数据，并将其重写为列式格式。我猜测至少 90% 的指标是几乎在任何情况下都几乎没人会想看的东西，而在任何人在乎的指标中，绝大多数与性能无关。这样做还有一个可喜的副作用，因为只有极小一部分数据是相关的，所以长期存储它的成本很低。标准的指标数据转储在几周后会被删除，因为其规模大到长期存储成本过高；更长的指标记忆期对于容量规划或其他更倾向于拥有历史数据的分析将很有用。

我们保存的数据包括（但不限于）每个服务的每个分片的以下内容：

• 各种缓冲区的使用率和大小
• CPU、内存和其他利用率
• 线程数、上下文切换、核心迁移
• 各种队列深度和网络统计
• JVM 版本、功能标志等
• GC 统计信息
• Finagle 指标

以及每台主机的：

• 来自 procfs 的各种信息，如 iowait 时间、空闲 等
• 机器所属的集群
• 主机级信息，如网卡速度、主机核心数、内存
• 主机级"健康"问题统计，如热节流、机器检查等
• 操作系统版本、主机级软件版本、主机级功能标志等
• Rezolus 指标

对于变化非常频繁的东西（如主机网卡速度），我们每天存储一次，但大多数内容都以与其他指标相同的频率和粒度存储。在某些情况下，这显然是浪费的（例如，对于 JVM 临时阈值，这通常在服务的所有分片中都相同且很少变化），但考虑到我们现有的指标基础设施，这是最简单的处理方式。

虽然这个项目的初衷是找出哪些服务的 JVM 幸存者空间配置不足或过度，但它始于 GC 和容器指标，因为这些是非常明显的观察点，此后我们一直在逐步添加其他指标。为了了解我们可以查询的内容类型以及如果你懂一些 SQL，查询有多简单，这里有一些示例：

极高的 p90 JVM 幸存者空间

这是最初目标（找出配置不足/过度的服务）的一部分。任何具有极高 p90 JVM 幸存者空间使用率的服务，其幸存者空间很可能配置不足。类似地，任何在峰值负载下 p99 或 p999 JVM 幸存者空间使用率极低的服务，很可能配置过度（此处未显示查询，但我们可以将查询范围限定在高负载时段）。

一个 Presto 查询，用于获取跨所有服务的极高 p90 幸存者空间：

with results as (
  select servicename,
    approx_distinct(source, 0.1) as approx_sources, -- 服务的分片数量
    -- 实际查询使用 [coalesce and nullif](https://prestodb.io/docs/current/functions/conditional.html) 处理边缘情况，为简洁起见省略
    approx_percentile(jvmSurvivorUsed / jvmSurvivorMax, 0.90) as p90_used,
    approx_percentile(jvmSurvivorUsed / jvmSurvivorMax, 0.50) as p50_used,
  from ltm_service 
  where ds >= '2020-02-01' and ds <= '2020-02-28'
  group by servicename)
select * from results
where approx_sources > 100
order by p90_used desc

无需查看大量仪表板，我们可以直接获取列表，然后向相应的团队发送配置变更差异，或者编写一个脚本，获取查询输出并自动生成差异。上述查询为任何基本的利用率数字或比率提供了模式；你可以用类似的查询查看内存使用情况、新旧代 GC 频率等。在一个案例中，我们发现一个服务浪费了足够的 RAM，足以支付我十年的工资。

我正在逐步远离使用简单百分比的阈值来发现问题，但我展示这个查询是因为这是人们通常想做的、有用的事情，而且我可以编写它而无需花费大量篇幅解释为什么这是合理的事情；我更倾向于做的事情超出了本文的范围，可能值得单独写一篇文章。

网络利用率

上述查询是跨所有服务的，但我们也可以跨主机进行查询。此外，我们可以进行连接主机属性、功能标志等的查询。

使用一组查询，我们能够确定有相当多的服务尽管主机级网络利用率很低，却触及了网络限制。然后，计算平台团队逐步推出了网络上限的更改，我们使用类似下面的查询进行监控，以确定没有出现性能下降（理论上，如果增加网络上限导致主机或交换机触及网络限制，可能会发生这种情况）。

通过网络更改，我们能够观察到更小的队列深度、更小的队列大小（字节数）、更少的数据包丢弃等。

下面的查询仅显示队列深度以保持简洁；添加所有提到的数量只需多输入一些名称。

我们可以做的一般事情是，对于平台或服务级功能的任何特定推出，我们可以看到其对实际服务的影响。

with rolled as (
 select
   -- 推出在时间段内对所有主机是固定的，可以从时间段中任意选择一个元素
   arbitrary(element_at(misc, 'egress_rate_limit_increase')) as rollout,
   hostId
 from ltm_deploys
 where ds = '2019-10-10'
 and zone = 'foo'
 group by ipAddress
), host_info as(
 select
   arbitrary(nicSpeed) as nicSpeed,
   hostId
 from ltm_host
 where ds = '2019-10-10'
 and zone = 'foo'
 group by ipAddress
), host_rolled as (
 select
   rollout,
   nicSpeed,
   rolled.hostId
 from rolled
 join host_info on rolled.ipAddress = host_info.ipAddress
), container_metrics as (
 select
   service,
   netTxQlen,
   hostId
 from ltm_container
 where ds >= '2019-10-10' and ds <= '2019-10-14'
 and zone = 'foo'
)
select
 service,
 nicSpeed,
 approx_percentile(netTxQlen, 1, 0.999, 0.0001) as p999_qlen,
 approx_percentile(netTxQlen, 1, 0.99, 0.001) as p99_qlen,
 approx_percentile(netTxQlen, 0.9) as p90_qlen,
 approx_percentile(netTxQlen, 0.68) as p68_qlen,
 rollout,
 count(*) as cnt
from container_metrics
join host_rolled on host_rolled.hostId = container_metrics.hostId
group by service, nicSpeed, rollout

变得容易回答的其他问题

• X 的延迟、CPU 使用率、CPI 或其他性能影响是什么？
  • 增加或减少每个容器监控的性能计数器数量
  • 调整内核参数
  • 操作系统或其他发布版本
  • 增加或减少主机级超额订阅
  • 一般的主机级负载
  • 重试预算耗尽
• 对于上面相关的项目，在一般情况下或特定条件下，X 的分布是什么？
• 哪些主机在控制了负载等因素后，其上所有服务都表现出异常差的服务级性能？
  • 这通常被证明是由于硬件配置错误或故障
• 除了对主机级负载的一般影响外，哪些服务与其他服务"相处不融洽"？
• 故障转移或其他高负载事件的延迟影响是什么？
  • 考虑到未来的高负载事件和当前增长，我们应该预期未来会有什么水平的负载？
  • 哪些服务在故障转移期间负载增加，哪些服务负载不变，哪些介于两者之间？
• 对于任何固定大小的缓冲区或分配，我们可以进行哪些配置更改以在不增加成本的情况下提高性能或在不降低性能的情况下降低成本？
• 对于某些特定的主机级健康问题，如果我们看到 N 次，它再次出现的概率是多少？
• 等等，有许多问题在你可以对历史指标数据编写任意查询时变得容易回答

设计决策

LTM 是一个尽可能无聊的系统。每个设计决策都源于采取阻力最小的路径。

• 为什么使用 Scalding？
  • 它是 Twitter 的标准工具，集成使得一切都变得简单。我尝试过 Spark，它有一些优势。然而，当时，使用 Scalding 我可以免费获得我需要的集成，而 Spark 则需要手动集成工作。
• 为什么使用 Presto 而不是像 Druid 这样允许实时切片和切块查询的工具？
  • Rebecca Isaacs 和 Jonathan Simms 当时正在做相关的链路追踪工作，我们知道我们希望 LTM 与他们创建的任何系统进行连接。这在 Presto 中很简单，但当时使用像 Druid 这样的工具需要更多的规划和工作。
  • George Sirois 将一部分数据导入了 Druid，以便我们可以试用它，它提供的功能非常好；可能值得在某个时候重新审视它。
• 为什么不用 Postgres 或类似的工具？
  • 我们想要存储的数据量使得这在没有大量努力的情况下不可行；尽管数据存储成本相当低，但它仍然是一个"大数据"问题。
• 为什么用 Parquet 而不是更高效的格式？
  • 在支持的标准格式中，它是最合适的（另一个主要支持的格式是原始 thrift），引入新格式将比这个项目大得多。
• 为什么系统不是实时的（至少延迟一小时）？
  • Twitter 的批处理作业管道很容易构建，只需要阅读一些关于其工作原理的教程，然后编写类似的东西，但具有不同的业务逻辑。
  • 几年前，在我加入 Twitter 之前，有人提出了一个关于构建实时分析管道用于指标数据的方案，但最终没有建成，因为（我估计）制作一个 MVP 需要一到四个季度的工作，并且不清楚哪个团队有合适的授权来做这件事，同时有四个季度的人手。但增加一个批处理作业只需要一天，你不需要为一天的工作进行路线图和规划会议，你可以直接去做，然后增量地进行后续工作。
  • 如果我们寻找的是配置错误或优化机会，它们很少在一小时内消失（如果它们消失了，那它们的总体影响一定很小），而且实际上它们通常会持续数月到数年，所以我们放弃实时性并不会损失太多（我们确实失去了将输出用于某些监控用例的能力）。
  • 实时版本将会是一个系统，其显著的运营成本使得一个人无法在不承担过度负担的情况下操作它。这个系统比我预想的有更多的运营/维护负担，平均每月大约需要我 1-2 天的时间，这在目前构成了系统总成本中相当大的一部分，但它从不需要报警，而且工作量很容易由一个人处理。

无聊的技术

我认为撰写关于像这样仅仅是无聊工作的系统的文章被严重低估了。我阅读的许多帖子和演讲都使用了热门技术系统。我对新的热门技术没有任何意见，但许多有用的工作来自于将无聊的技术组合在一起并做显而易见的事情。由于关于无聊工作的帖子和演讲相对较少，我认为撰写像这样的东西比它理应具有的价值更大。

例如，几年前，在当地由 Matt Singer 为我们这类规模的公司组织的基础设施讨论会上（基本上是比 FB/Amazon/Google 小的公司），我询问是否有人做过类似我们刚完成的工作。当时没有一个人在做（或者至少没人承认），两家不同公司的工程师表示震惊，我们竟然可以存储如此多的数据，而不仅仅是每个时间段的平均值，甚至还有一些直方图信息。这项工作过于直截了当和显而易见，不可能是新颖的，我确信许多地方的人已经构建了类似的系统。这实际上只是将指标数据长期存储在 HDFS（或者，如果你喜欢更通用的术语，数据湖）上，采用允许交互式查询的格式。

如果你计算一下在我们这类规模的公司中，像这样的指标数据存储项目的存储成本，它基本上就是四舍五入的误差。我们单独发布的变更就很容易支付了数十年的存储成本。我认为当人们一直部署成本更高的分析和可观察性工具时，没有理由对存储几年甚至十年的指标感到震惊。但事实证明，这很令人惊讶，部分原因是人们不撰写如此无聊的工作。

另一个不相关的例子是，前段时间，我在一家类似规模的公司遇到一个人，他想从指标数据中获得类似的见解。他们没有从像这个项目这样一天就能完成的东西开始，而是从深度学习开始。虽然我认为将机器学习和/或统计应用于基础设施指标是有价值的，但他们将一个可能在几个人天内为公司带来显著价值的项目变成了一个需要人年的项目。如果你只打算要么应用由具有基础设施经验的人指导的简单启发式方法和简单统计模型，要么天真地应用深度学习，我认为前者具有更高的投资回报率。将复杂的统计/机器学习和实践者指导的启发式方法结合起来可以比单独使用任何一种获得更好的结果，但我认为从一个需要一天构建、再花一两天开始应用的简单项目开始，而不是从一个需要数月或数年构建和应用的项目开始，更有意义。但有很多偏见倾向于做更大的项目：它能成为一个更好的简历项目（深度学习！），在许多地方，它能成为一个更好的晋升案例，人们更有可能就使用深度学习的酷系统发表演讲或撰写博客文章。

上述讨论了为什么撰写工作对整个行业有价值。我们在之前的文章中讨论了为什么撰写工作对进行撰写的公司有价值，所以我这里不再赘述。

附录：我搞砸的事情

我认为遗憾的是，你听不到系统的缺点，除非通过非正式渠道交流，所以这里列出一些我事后看来相当明显的错误。当其他事情事后变得明显时，我会添加到这里。

• 没有将几乎所有内容都使用 double 类型
  • 在理想世界中，有些东西不是 double，但我们指标栈中的所有内容都经过了一个阶段，基本上每个指标都被转换为 double
  • 我将大多数"应该"是整数类型的东西存储为整数类型，但执行从 long -> double -> long 的转换永远不会比直接执行 long -> double 转换更精确，而且它为其他问题打开了大门
  • 我将一些不应该作为整数类型的东西存储为整数类型，这导致小值不必要地失去精度
    • 幸运的是，这尚未导致我做过的任何可操作分析出现严重错误，但有些分析可能会出现问题
• 使用断言而不是将错误条目写入某种"错误条目"表
  • 由于超出本文范围的原因，在 Scalding 作业中记录错误或警告没有真正合理的方法，因此我使用断言来捕获不应该发生的事情，这导致每次发生意外情况时整个作业都会终止；更好的解决方案是将错误输入条目写入一个表中，然后如果该表不为空，则将该表作为软警报发送电子邮件
    • 一个例子，如果有一个记录错误条目的表，可以节省一些运营开销，例如我们遇到了异常的时钟偏移（3600年），导致时间戳溢出。如果我有一个记录错误条目的表，错误条目将从输出中省略，这是正确的行为，这将节省一次中断以及不得不推送修复并重新部署作业。
• 代码中的 Longterm vs. LongTerm
  • 我最初编写时不确定应该如何大写，而当我做出决定后，我没有搜索并消除所有写错的内容，所以现在这种无意义的不一致性在多个地方存在

当你快速赶制东西而没有充分思考时，就会出现这类事情。最后一项很容易修复，问题不大，因为 Twitter 普遍使用 IDE 意味着基本上任何受影响的人都会得到 IDE 提供的正确大写。

第一项问题更大，因为它实际上可能导致分析不正确，而且修复它需要对我们现有的所有数据进行迁移。我猜到这一步，这大约需要半周到一周的工作，而我本来可以通过多花三十秒思考一下我在做什么来轻松避免。

第二项介于两者之间。在第一项和第二项之间，我认为我大概为此系统的直接工作量增加了大约一倍（所以，不包括在系统数据上花费的分析时间，只是构建系统所花的时间），这基本上没有带来任何好处。

感谢 Leah Hanson、Andy Wilcox、Lifan Zeng 和 Matej Stuchlik 的评论/修正/讨论

由 mimo-v2.5 模型翻译，花费 12283 tokens

我一直在与运营企业工程博客的人交流，我认为奇怪的一点是，即使对于一家估值九位到十位数的公司，我的个人博客获得的流量也常常超过其整个工程博客的流量，而我的博客流量高出一个数量级的情况也并不少见。

我觉得这很奇怪，因为这类科技公司通常有成百上千名员工。他们几乎肯定比我更有能力写出引人入胜的博客，并且公司从引人入胜的博客中获得的价值也远大于我。

就前者而言，公司的员工会完成更有趣的工程工作、拥有更多有趣的故事，并且比任何拥有个人博客的个人拥有更深入的知识。就后者而言，我的博客有助于我求职，也有助于公司招聘。但我只需要一份工作，因此，更多的曝光最多能让我找到一份稍好一点的工作，而除了我工作过的那家公司外，所有其他我工作过的科技公司都迫切需要招聘，并且经常流失候选人给其他公司。此外，即使我们面试同一个职位，如果公司喜欢我们中的多个候选人，它通常只会创造更多职位，所以我在面试时并不真正与其他候选人竞争。这个博客在求职方面的关键作用在于，该流程是否能接受显著的非面试反馈，或者我是否会因为他们进行常规面试而失败。对于这一点，额外一篇文章的边际价值可能非常低。另一方面，公司在招聘方面的竞争相对直接，因此相对于另一家公司，更有吸引力对他们来说是有价值的；复制Cloudflare或Segment在其工程“品牌”方面所采用的策略将带来显著的招聘优势。这个策略并非秘密：这些公司向世界广播其成果，并且通常很乐意谈论他们的博客流程。

尽管拥有一个“优秀”的企业工程博客似乎有明显的好处，但大多数企业工程博客充斥着工程师不想阅读的内容。关于一切多么了不起的模糊、高层次的空话，内容营销，关于新热点的含糊其辞的文章（今天，可能是将深度学习应用于不适当的场景；十年前，可能是将“大数据”应用于不适当的场景）等。

为了理解拥有优秀企业工程博客的公司有何共同点，我采访了三家拥有引人入胜的企业工程博客的公司（Cloudflare、Heap和Segment）以及三家拥有乏味的企业工程博客的公司（我不会透露其名称）的员工。

从高层次来看，引人入胜的工程博客的流程具有以下共同特征：

• 简单的审批流程，不需要太多审批环节
• 很少或不需要非工程审批
• 审批流程有隐式或显式的快速SLO（服务水平目标）
• 审批/编辑流程主要是让帖子对工程师更具吸引力
• 高层领导（联合创始人、C级高管或VP级别）直接、高层次地支持保持博客流程轻量化

吸引力较弱的工程博客的流程则具有以下共同特征：

• 审批流程缓慢
• 需要多个审批环节
• 需要重要的非工程审批
  • 非工程审批会提出让作者感到沮丧的修改意见
  • 来回修改可能持续数月
• 审批/编辑流程主要是为了降低帖子的风险、移除具体引用、让帖子变得更模糊，对工程师的吸引力更低
• 实际上没有高层支持博客
  • 领导层可能抽象地认同博客是好的，但其优先级不够高，无法采取具体行动
  • 改革流程以使博客更容易非常困难；之前的尝试已经失败
  • 改变流程以减少开销需要所有“利益相关者”签字同意（在一个案例中是14人）
    • 任何单一利益相关者都可以否决
    • 没有任何单一利益相关者可以批准
  • 利益相关者对批准任何减少开销的提议持谨慎态度
    • 批准意味着承担感知到的风险（万一发生不好的事情），而对他们来说没有感知到的好处

一家拥有引人入胜博客的公司的一位员工指出，只有一个审批人和/或一个主要审批人的缺点是，如果此人很忙，帖子可能需要几周才能获得批准。这是公平的，这是集中式审批的一个缺点。然而，当我们与其他流程进行比较时，在一家公司，人们指出审批通常需要三到六个月，尾部案例可能需要一年。

对于习惯了快节奏公司的人来说，几周似乎很长，但对于在较慢节奏公司工作的人来说，如果审批流程只需要两倍的时间，他们会欣喜若狂。

以下是我采访的三家公司（以sha512sum顺序呈现，巧合的是按公司规模递增排序，从几百名员工到近千名员工）向我描述的流程：

Heap

• 有人有一个写文章的想法
• 作者（工程师）与一位“伙伴”配对，伙伴负责编辑并批准文章
  • 伙伴是一位有良好写作记录的工程师
  • 这可能需要几轮修改，可能会改变文章的主旨
• CTO阅读并批准
  • 通常只有很小的反馈
  • 可能会提出类似“设计师可以让这个图表更好看”的建议
• 发布文章

第一轮编辑阶段过去是在一个Slack频道里发布草稿，让“所有人”评论文章。这是一次不愉快的体验，因为“所有人”都会发表评论，需要大量修改。这个流程旨在避免收到“过多”的反馈。

Segment

• 有人有一个写文章的想法
  • 通常来源于：内部文档、外部演讲、已发布的项目、Segment构建的开源工具
• 作者（工程师）撰写草稿
  • 可能会有一位资深工程师与他们一起撰写草稿
• 直到最近，没有真正的人负责反馈流程
  • Calvin French-Owen（联合创始人）和Rick（工程经理）通常会提供大部分反馈
  • 可能还会从经理和工程领导那里得到反馈
  • 通常，第3稿被认为是完成稿
  • 现在，有一位全职编辑负责编辑文章
• 还会在工程团队内交流，从15-20人那里获得反馈
• 公关和法务会看一下，进行轻量级审批

已经做出的一些改变包括：

• 曾经在试图建立“工程品牌”时，将撰写深度技术文章作为最高优先级
• 举办过“博客静修”，花一周时间撰写一篇文章
• 在绩效评估和职业阶梯中明确将写作和演讲作为奖励标准

尽管有法务和公关审批，Calvin指出“总的来说，我们尽量保持轻量化。我认为博客更大的问题是缺乏文章，或者是模糊、高层次、不感兴趣的内容，而不是泄露太多信息。”

Cloudflare

• 有人有一个写文章的想法
  • 内部博客是文化的一部分，有些文章来自内部博客
• John Graham-Cumming（CTO）阅读每一篇文章，其他人也会阅读并发表评论
  • John是文章的审批人
• Matthew Prince（CEO）也普遍支持博客
• “非常快速”的法务审批流程，SLO为1小时
  • 这个流程如此轻量级，以至于一个人并没有真正将其视为审批，另一个人甚至没有提到它（第三个人确实提到了这一步骤）
  • 公关通常不参与

需要注意的是，这仅适用于技术博客文章。产品公告有更重的流程，因为它们与销售材料、新闻稿等相关联。

我发现有趣的一件事是，Marek因为Cloudflare的博客而面试（这篇关于他们第四代服务器的2013年博客文章引起了他的注意），现在他既是他们的关键工程师之一，也是Cloudflare博客上引人入胜文章的主要来源之一。目前，Cloudflare博客已经至少培养了几代员工，他们因为看到博客文章而来面试，现在又为博客撰写引人入胜的文章。

反面案例 #1

• 许多人建议我将这家公司作为正面案例，因为他们在早期有一个像上面那样的半轻量化流程
• 唯一使流程变得非轻量化的因素是，一位创始人坚持审批文章，并且经常会大量重写，但博客当时很成功，是招聘的重要驱动力
• 随着公司规模扩大，创始人审批花费的时间越来越长，导致博客流程出现长时间延迟
• 在某个时候，聘请了一位外部人士接管博客发布流程，因为领导层认为这很重要
• 之后，流程充满了典型的反模式，审批需要数月，有工程师感到沮丧的多轮修改，使他们的博客文章吸引力降低
  • 多人告诉我，他们在写了一篇文章后发誓再也不为公司写博客文章了，因为这个过程太痛苦了
  • 好消息是，由于博客曾经拥有合理流程的悠久历史，博客良好产出的记忆仍然给许多外部人士留下了对其公司及其工程的良好印象