我以前一直纳闷，为什么我比大多数人看到的 Bug 要多得多。我每周都能轻易碰到数百甚至上千个 Bug，感觉什么东西都不太正常，但和我聊过的大多数人却完全没有这种体会。很长一段时间里，我以为这和我使用电脑的方式有关，但慢慢地我意识到，其实大家踩到的是同样的 Bug，只是没有注意到而已。

如果你不是程序员，这样看世界或许是更好的看世界的方式，但我觉得对于程序员来说，治好对质量／Bug 的盲视是有帮助的。我已经在不少朋友和熟人身上试过（无非就是把 Bug 指出来而已）。几周之后，那些本来就有意愿的人，也会慢慢开始注意到 Bug 了。

正因为我会注意到这些问题，在好几份工作中，总监、副总裁、高管之类的人有时会让我去评估某个东西，因为他们想要一个真正能发现问题（必要时还能自己修或推动修复）的人的真实意见。有时候我什么问题也找不到（很可能只是问题不在我能注意到的类型里）。更多时候，我发现的问题介于“轻微”到“中等”之间。而有时，问题会严重到可以说那东西根本就没法用。

最后这一类让我有点困惑，因为当我去翻看这个东西是怎么变成现在这样的内部讨论时，往往看到的都是一连串“这东西很棒、运行得很好”之类的评价，可当我自己打开试用时，却发现只有经过好几步违反直觉的变通操作才能让它跑起来。更常见的情况是，普通用户不仅根本用不起来，还会得到一种让人哭笑不得／火冒三丈的糟糕体验，糟到会去跟朋友吐槽的程度。

这篇文章的想法在我脑子里大概放了十年左右，但我一直犹豫要不要写，因为潜意识里我总担心，是不是我在无意中触发了大多数用户根本不会碰到的古怪边界情况。但在看到越来越多产品上线后直接栽跟头、而用户遇到的恰好就是我之前看到的那些问题之后，我不再觉得我碰到 Bug 是因为做了普通用户不会做的怪异操作。如果一个产品在我手里显得问题严重，那它很可能就是真的有严重问题。而如今有了 LLM 的加持，我甚至可以让 LLM 在很多方面扮演普通用户，来证明这些问题在各种不同场景下都能复现。

几个例子

我不想举那些本身就是我的职责去评估好坏的具体例子，因为即便内部的例子是出于建设性、对事不对人的目的，放到外部再发表，也未必会被这样理解，所以我只举几个不那么有趣、论据也不那么充分的“随机”例子。

前段时间，我写过一篇关于一些网页搜索查询结果的分析，发现 Google、Bing 和 Kagi 的结果都很差。总体来说，主流搜索引擎都没能为这些查询返回好的结果，返回的页面充斥着低质量的 SEO 垃圾，还有一些根本就是诈骗网站。顺便说一下，按照前面提到的标准，我会把这种情况归为“中等”而非“严重”（严重指的是比如搜索引擎有一半时间返回 500 错误、大多数结果都是诈骗网站之类；我对“严重”的定义是普通用户根本没法用，而不仅仅是体验很差）。几乎没人¹对我关于 Google 和 Bing 搜索结果的描述提出异议，但很多人说我对 Kagi 的评价错了。有些人还把他们实际搜到的结果发给我看。在每一个这样的例子里，我都没看到什么像样的好结果（比如关于季节性预报的查询，搜索根本没返回最新的季节预报），而且结果里满是 SEO 垃圾。有个人把他的 Kagi 过滤器列表和搜到的结果一起发给我，并没有断言结果好坏，但其他人普遍坚称结果很好，尽管那些结果既没有链向有用的内容，又充满垃圾——除非用户做了类似把 GitHub 置顶的操作，这对那些目标是下载托管在 GitHub 上的软件的查询确实有效，但对文章里的其他查询当然就完全没用了。

抽象地讲，我能理解粉丝往往会对自己喜欢的东西的缺点视而不见。比如，我在看了沃尔沃在样本外碰撞测试中的表现后买了一辆沃尔沃，之后有时会在沃尔沃车主论坛上搜问题的答案。十多年来，现有的可靠性数据（我觉得修沃尔沃的技师们的口碑经验也印证了这一点）都显示沃尔沃的可靠性只能算一般到很差，但沃尔沃论坛里当然满是坚称沃尔沃是最可靠的车之一、数据全都错了的人。

一个可能更切题的例子是 Blackboard（课程管理系统）。在它还是大学课程最广泛使用的软件时，学生和教授都普遍讨厌它。我觉得可以公平地说，在我的社交圈里，它是被讨厌得最广泛的软件（也有更让人讨厌的软件，比如 Visual SourceSafe，但那些更讨厌的软件使用面不够广，不足以成为总体上被讨厌最多的）。维基百科上这样写道

Blackboard 已经成为“教育领域最不受欢迎——甚至最被人憎恶的公司之一。”

2011 年 12 月，《Fast Company》报道称，在 Amplicate 的客户意见调查中，93% 的受访者表示“讨厌”这家公司。

我还年轻、说话更没分寸的时候，碰到过一个在 Blackboard 工作的人，想都没想就傻乎乎地脱口而出类似“在做这么多人讨厌的软件的公司工作是什么感觉？”的话。幸运的是，对方完全没有被冒犯，反而感到困惑，因为他以为那是广受喜爱、用户非常喜欢的软件。他根本不相信我说的是真的，我只好打圆场说是我搞错了，然后把话题岔开了。当时作为一个更年轻、更天真的我，真的很惊讶：在我的社交圈里大概是被讨厌得最广泛的软件，在我遇到的这位（大概还有其他）员工眼里，却是备受欢迎的软件。

我能理解沃尔沃论坛为什么会变成那样，毕竟现在的汽车总体上已经足够可靠，人们一般不会遇到抛锚，所以很容易产生“数据肯定不对，毕竟我的车就从来没坏过”这样的想法。但更让我费解的是，一个人怎么能看着一堆充满垃圾的搜索结果，却飞快地写条消息来解释这些结果有多好——即便他是某个搜索引擎的粉丝；或者一个人怎么会认为用户普遍喜爱一款以被讨厌而闻名的软件，以至于我问到的每个人都跟我说它有多烂（常常是主动抱怨）、有新闻专门讨论人们多讨厌这款软件、甚至维基百科页面上都提到了人们近乎一致的厌恶。另一个类似 Blackboard 的例子是 Discourse（论坛软件）的网页性能，这篇文章的灵感之一就来自我与一些认为 Discourse 性能很好的员工的讨论。这件事让我觉得有意思的地方在于，Discourse 实际上有一段代码会拖慢真实的页面加载，以在 LCP 这类网页性能指标上作弊。这已经远远超出了单纯为基准测试做优化的范畴，上升到了真正作弊的程度——不仅对用户毫无好处，反而损害了用户体验。在某种程度上，实现这种作弊手段并指导用户如何避免无意中破坏作弊的程序员，必定知道自己应用的真实性能很差，但人们很容易对此筑起心理屏障。

到现在，我已经不会说感到惊讶了，因为这类事情我见得太多，反而如果没发生我才会觉得意外，但我依然好奇，当这种事发生时，人们脑子里到底在想什么。

举一个非编程的例子，我们之前在这篇讨论人们对“显而易见”事实看法不同的文章中提到，有一名篮球运动员，主观上被普遍认为是他那个时代最脏的球员。NBA 并不追踪球员“脏”的客观指标，但在各种衡量方式上他似乎都遥遥领先。举例来说，虽然就像 1950 年之前的篮板一样，击裆并不是官方统计的数据，但他肯定保持着本世纪用拳打、脚踢、膝顶或其他方式击打对手裆部的纪录（按时代调整后他也应该保持纪录，不过由于 80、90 年代整体打法更脏，他未必保持历史总纪录）。在讨论中，他所在球队的大多数球迷似乎对此视而不见，而“自然的抢板动作”和“自然的投篮动作”已经成了调侃这些球迷的常用梗——因为他们在为这名球员击打对手裆部时的扭曲动作辩解时，显得如此茫然无知。

平均而言，人类很擅长忽略自己喜欢的事物中的缺点，包括（而且往往尤其是）自己的工作或自己公司的工作。不管是好是坏，我似乎恰恰相反，我的思绪会立刻转向自己和自己工作中的缺陷。好几次，因为一篇博客文章，有人给我发消息说类似“如果有人批评你的工作你会怎么想？”或“如果有人说你的工作不好你会怎么想？”之类的话。对于前者，我的想法是，我会费尽周折去找能挑出我推理漏洞的人来批评，所以如果有人对我的工作提出哪怕有点道理的批评，那真是太好了。对于后者，我通常觉得自己的工作充满重大缺陷，所以，呃，是的，说它不好似乎挺合理的。我工作中确实有一些方面我觉得有趣或不错，但总体而言，我不觉得自己做过的任何东西能算得上好。我并不是说我没有盲区，但我觉得在这一点上，我比大多数人稍微不容易陷入这种盲视²。

习惯性的规避

如果回想我有过的类似盲区，有一件事立刻浮现在脑海，那是我小时候，一个朋友来用我的电脑。要理解这个故事，你得知道那还是机械鼠标的时代。时间一长，碎屑会粘在鼠标滚球上，除非清理掉，否则会导致光标轨迹飘忽不定。

当我的朋友试着用我的电脑时，他发现鼠标根本没法用，指针的移动几乎是随机的。可当我重新坐下来用鼠标时，却完全没觉得有任何问题，但仔细观察我为了让指针平稳地走直线而做的手部动作时，我发现自己正疯狂地把手甩来甩去。我意识到，随着滚球上碎屑的慢慢积累，我一定是逐渐适应了它，而我正通过做出相反方向的 erratic 动作来抵消鼠标极不稳定的轨迹³。我觉得自己居然完全没意识到在做这些，实在很神奇，也总会想，我现在是不是也在做类似的事情。

我有时会想起自己为了绕过 Bug 而养成的一整套规避习惯。比如，新建一个 Google Docs 文档时，我以前会立刻把想要的标题输进去。大概十年前左右的某个时候，Google Docs 增加了一种延迟，导致你在刚打开文档时往标题框里输入的内容会被覆盖掉，所以我现在养成了一个习惯：打开 Google Docs 后先做点别的事，过一会儿再改标题。随着 Google Docs 添加的功能越来越多，我也养成了一系列习惯来避开各种坑（比如在“错误”的时机去搜索，结果调出的是无用的浏览器自带搜索，而不是 Google Docs 的搜索）。

我的感觉是，所谓电脑素养和软件素养，很大一部分就是积累大量这类习惯，并且在无意识层面去执行它们。这些习惯往往非常具体，比如我在微软工作时养成的一个习惯：登录前先把笔记本的 Wi-Fi 开关拨到关闭（我注意到其他人也这么做）。这是因为有个服务经常会让你的登录失败，提示“There are currently no logon servers available to service the logon request”。但如果那个服务完全连不上，这个检查就会被跳过，你反而能直接登录。

质量盲视

我们可以用这类例子填满一整篇文章，但还是回到本文的主题：一个常被提及的克服质量盲视的方法是让人们自己吃自己的狗粮（dogfood 自己的软件）。平均而言，这比不 dogfooding 要好得多，但它只在人们没有琢磨出（然后又忘掉）那些绕过软件问题的习惯的程度上才有效。平均来说，程序员很擅长绕过软件的各种小毛病（在 LLM 出现之前，你必须得会这一套才能成为高效的程序员），所以如果不留意，程序员很容易注意不到这类问题。

反过来说，让应用变得易用的很大一部分，似乎就是让这些古怪的习惯变得不再必要。虽然这听起来应该很容易做到，但就我所见人们尝试就这类问题提供反馈时，大多数开发者的本能反应似乎是“啊？做 X 很简单啊，只要做[一连串复杂操作，如果没人专门解释过或看别人做过，没用过很多次应用的正常人根本想不到]就行了”或者“啊？你没看到吗？说明书第 43 页明明写得很清楚，只要先按第 261 页附录 B 的步骤操作就行了？”

话虽如此，我觉得治好人们的质量盲视是可行的，因为我已经成功过好几次。我觉得这只有在对方愿意接受时才真正有效，因为人们对故意视而不见的能力是无限的，但在愿意接受的情况下，只要把他们没注意到的问题指出来，似乎就有效了。几年甚至十年后，有时还会有人告诉我，他们现在到处都能看到 Bug 了。

我觉得这件事值得做的原因是，我见过一些个人和团队因为高度的质量盲视而发布了一些因产品质量问题而成功几率大打折扣、甚至完全没有成功机会的东西⁴。有意识地、主动地用质量换速度是一回事⁵，但在我见过的这些情况里，总有一种质量盲视——参与项目的所有人都以为自己发布的是非常高质量的东西，而事实并非如此。

这件事从来都很重要，但随着编码智能体的出现，它变得更加重要了，因为一方面，以前所未有的速度炮制低质量软件变得前所未有的容易，另一方面，提升质量也变得前所未有的容易，无论是更好的性能、更少的 Bug等等。

但是，要做到这一点，你必须真正意识到这是可能的，意识到质量是可以提升的。

感谢 Yossi Kreinin、Dennis Snell、Michael Malis、Emu Chu、Gary Bernhardt、Jon Surrell 和 Matt Mullenweg 的评论／指正／讨论。

顺理成章地，Gary Bernhardt 在阅读本文草稿时就碰到了一个 Google Docs 的 Bug。

P.S. 就像我在最近四篇文章里提到的，我一直在尝试更快地写文章，因为有了 LLM，看数据、搞清楚事情变得容易得多，但由于我不是用 LLM 来写，写一篇文章所需的时间并没有本质变化，除非我想在质量与速度的权衡上移到另一个点。之前的结果是，我会做一些实验，告诉几个朋友，然后就再也不写出来，因为根据阿姆达尔定律，把任何东西写出来都会实质上耗尽我用来做实验的全部带宽。事实上，尽管我一直在尝试这么做（我的目标是每篇写作用时 30 分钟），自从写完上一篇之后，我已经有三个我觉得完全可以写成一篇不错博客的结果还没来得及写（还没算工作上做的那些，那还会再多几项）。如果不用 LLM 替我写，我看不到有什么合理的方法能把每篇的用时显著压缩到 30 分钟以下（而且我觉得我经常会超过这个目标，花更多时间），所以，不用 LLM 的选项就是：要么是一些比我正常文章潦草得多的文章（一种人写的潦草），要么就是几乎不发文章。

总之，如果你对这些快速（也肯定错得更多）的写作有什么看法，欢迎告诉我你的想法（X Bsky Mastodon）！

附录：广告盲视

Michael Malis（Freshpaint 创始人兼前 CEO）提到（是在消息里说的，所以是消息体的格式）

对于一个相似但不同的数据点——我在广告方面也见过类似的盲视。当我向人们解释 Freshpaint 时，我会说我们帮助医院做营销

我常被问到的一个问题是，医院为什么要做营销。奇怪的是，如果你留意一下，医院其实做了大量的营销

在旧金山，有大量关于 UCSF／Sutter Health／Stanford 以及各种治疗项目的公交广告和广告牌

这和 Michael 的评论以及本文的主题都不是同一个话题，但我想说，我和不少完全不相信广告有用的人聊过，不过我在曾工作过的一家大公司里，和一位我信任其数据方法和判断力的人聊过广告的 A/B 测试，并在另一家公司亲自看过数据，我觉得在那些案例中，广告带来真实提升（远超广告成本）的因果证据是很强的。在我亲自看过的那个案例中，他们做了一个按地理区域切分的 A/B 测试，在一些地区投放广告，在另一些地区不投（这是在全球范围内做的，区域是像美国的州、加拿大的省之类）。之所以要做这种按地理的切分，是因为即便有跨设备追踪，也无法 100% 确定某个人是否真的看到了广告（当然即便用这种切分也依然如此，而且我会更偏好那种更按人口聚集区来划分、不会在比如人们很可能每天通勤跨越边界的地方做切分的方案，但这种混杂一般会让真实的提升比估计的提升更高），所以人们有时会做这种按地理切分的 A/B 测试。

总之，在这些 A/B 测试中，单看直接收入增长，广告支出回报率就已经相当不错，而且用户量也有增长，这很可能会在未来带来更多收入（后续收入没有做分析）。我不知道广告总体上是否都有效，也不知道你的广告是否有效，但那种被反复提及的“广告总体上没用”的说法，在我看来是错的。

说回 Michael 的评论，我觉得程序员很容易注意不到广告。我认识的几乎所有程序员都用广告屏蔽插件，而且在现实生活中，他们的眼睛似乎也只是从广告上扫过而不会留意。我能理解这怎么会让人产生“广告没用”的想法。到底谁会去看这些东西？但根据我与“普通人”的交流，以及我在 Google 时接触到的数据，许多甚至大多数人根本没意识到很多广告就是广告。当他们做 Google 搜索并点击最上面的结果时，他们常常完全不知道自己看的并不是 Google“认为”最好的链接，而是出价最高买下那个广告位的人的链接。

附录：其他人的评论

Em Chu，关于一个习惯性的 Bug 规避：

我相信这一节你可以收集到无数的例子，但我就是想抱怨一下：当唤醒并解锁我的笔记本（Mac）时，很容易让它进入一种“醒着”却无法使用的状态（黑屏加光标之类），只能通过物理地合上盖子再打开来修复。为了绕过这个问题，我想我通常会在屏幕亮起后等一秒，触碰一下触控板，然后再解锁，不过说实话这大多是下意识发生的，而且显然我还需要多练练，因为我每个月还是会碰到几次这个 Bug。

读到这段后，我观察了一下自己打开笔记本的方式，意识到自己也因为要绕过其他笔记本 Bug 而养成了一些古怪的习惯。这里提到的这个特定 Bug 在我的笔记本上无法复现，看来我可以停掉之前为某台旧笔记本养成的那个习惯性规避操作了。

Gary Bernhardt，关于他阅读本文草稿的经历

在阅读过程中，Google Docs 的界面似乎坏掉了，导致无法向上滚动去看一些评论（见截图[文章中未展示]）。

看了截图后，我发现我见过完全一样的 Bug，并且也有一些规避办法（根据上下文不同而不同）。就软件质量而言，我个人会给 Google Docs 远高于平均分的评价：我觉得它比主要的替代品（Microsoft Word、OpenOffice、以及早已消失的各种旧编辑器如 StarOffice、Lotus 等）要少 Bug、少卡顿得多。即便如此，我也能轻易坐下来写一篇一万字的文章，专门讲 Google Docs 的 Bug 以及我对它们的各种变通。

有时候，我会想能不能找一份整天只修质量问题的工作。这从来没能实现，部分原因是这事优先级不高，部分原因是公司里根本没有这样的常规岗位。我有时会幻想以实习生的身份加入一家公司，就修几个月的质量问题然后离开。实际上，我觉得就算真得到这样的工作，很多修复也会被卡住，作为一个只待三个月的实习生要真正推动变革会非常困难，所以那得是一个基本被废弃、没人在乎我做什么的项目（而且公司的优先级不会那么聚焦于发新功能，以至于修复刚做好就又被改坏了）。

@IncidentNoodle

无意中切题了：<abbr> 标签大约上周在移动端还能用，但现在在任何 iOS 浏览器（Safari／Chrome／Firefox）上都不行了，而且由于延迟很长，我花了好大功夫才搞明白在 macOS 的浏览器（三种都是）上需要悬停才能看到它们

@[email protected]：

德国人对此有一个词——Betriebsblindheit

@oulipien.bsky.social：

@danluu.com 这里的奇闻太离谱了，真希望他当时能更直接一点，问问这个人到底从哪儿得出 Blackboard 会被任何人喜欢的这种想法。用户调查？委托人（而非代理人）调查？内心信念？？？[Blackboard 轶事截图]

[某种变体，比如，人们被老板逼着说自己没看到 Bug]

我不认为这能解释文章里任何一个主要例子，更不用说所有例子了。以文中提到的 Blackboard 为例，我和其他与这位 Blackboard 员工交流的人不太可能是去暗访员工的“神秘顾客”，而这位员工的反应对于任何不是这种假想（实际上根本不存在）的神秘顾客的人来说，显然是荒谬的，所以这样反应只会让他在遇到的很多人眼里显得有点傻，而且毫无好处（比如，看看上面那条引用，似乎就是典型的内部反应）。也许会有少数特别多疑的员工会为了以防万一碰到认识老板、知道他们在哪家公司、还会把话传回去的亲友，并且老板又会在意这种事，而一直维持这种姿态，但这不太可能解释（比如）每一个来跟我解释 Discourse 性能真的很好的 Discourse 员工的情况。

如果看篮球的例子，这就更荒谬了。你或许可以编出某种理由，比如如果你不相信或假装相信最荒谬的辩解，其他球迷就会排斥你，但作为一个和体育迷打交道很多的人，我通常没发现是这样。即便在某种程度上有点像那么回事，那也更多是自我选择的问题——热衷于最极端辩解的球迷会更多地和同样热衷极端辩解的球迷待在一起，而不太热衷这些极端辩解的球迷则会更多地和不太热衷的人待在一起。

另外，单看那些不信这一套而去修复问题的人的职业路径，发现这些问题并加以修复对他们来说发展得很好。假装这些问题不存在（不管是有意识还是无意识）似乎也发展得不错，所以我也不知道修复这些问题是否真的是更好的职业路径，但它肯定也没糟到那种程度，以至于总体上会存在让人假装这些问题不存在的实质性职业压力——即便在某些个别岗位上，确实存在直接要求你假装问题不存在的压力。

Daniel Gibson：

还有谁会用 Shift 键来结束屏保，因为万一按键事件穿透到实际程序，它最不容易产生意外效果？

这让我想起，当我想立刻向 codex 发送一条排队消息并打断当前的工具调用时，我会把手指放在按键上并尽可能快地按下，以缩短工具调用恰好完成、而 Esc 键会完全停止 codex 而不是发送消息的那个时间窗口。我大概应该直接跑一个打过补丁的 codex 版本来修复这个问题和我遇到的其他几个问题，但我已经在做类似尝试某种针对特定工作负载优化的、奇奇怪怪的 ripgrep 版本之类的事——它还额外加了一个原生代码编译器，会在搜索开始的同时在另一个线程里编译匹配表达式，编译完成后就切换过去——所以我并不是反对为了改进工作流而打各种奇怪的补丁，更多是整体精力有限的问题（毫无疑问，写下这段话后，肯定会有人告诉我其实只要按别的键就行，而且花在写这段评论上的时间去问一下 codex 就能知道了）。就像 Google Docs 一样，我认为 codex 在同类中的软件质量算是高于平均水平的，但即便我使用它还不到一年，我也能轻易写出一万字来讲我已经实施的各种变通办法（要么是靠习惯，要么在某些情况下是靠实际的脚本来监控异常行为并自动纠正）。

John Regehr：

直到写完并发布这篇文章后，有人贴出 John 的文章链接，我才想起来，原来 John Regehr 在我开始写博客之前就写过“Operant Conditioning by Software Bugs”！也许我本该用 LLM 去检索一下 prior art，但如果真那么做，我可能就什么都写不出来了，因为真正全新的想法并没有那么多，几乎所有东西都会和别人说过的某种观点相似。不管好坏，我比 John 啰嗦得多，所以这篇文章用了多得多的文字，还塞进了更多随机的故事。如果你觉得我的博客文章太长，却不知怎么还是硬着头皮看到了底部，那你可能会更喜欢 John 的文章而不是我的 :-)。