2002 年 10 月，微软首席执行官史蒂夫·鲍尔默给客户写信，讲程序崩溃之后的事。他说，程序崩了，很少有人打电话找技术支持，「而是直接把程序关掉」。窗口一关，bug 也不见了，微软根本不知道它来过。
这是实打实的代价。鲍尔默写道，哪怕相对简单的软件也有几百万行代码，「有很多地方可以藏 bug」，测试没能全找出来。那么，先修哪一个？
Office 部门的一个小团队想了个办法。软件一出错，就弹窗问用户要不要给微软发一份错误报告。鲍尔默承认，让软件像 E.T. 一样「打电话回家」是有风险的。客户还是发了，报告汇集到微软几台专用服务器上。
如果 bug 均匀分布，每修一个，崩溃就少一小份，修哪个都差不多。鲍尔默报告的却是另一幅图景：「大约 20% 的 bug 造成了 80% 的错误。」接着他补了一句，说这件事让他「震惊」：「1% 的 bug 造成了一半的错误。」
一个大洞，二十个针眼
少数几个原因，常常闯下大部分的祸。先数清楚，再动手。
一只桶上有一个大洞、二十个针眼。先补手边够得着的针眼，你能忙一下午，水还是大半往外流。先找到那个大洞，一块补丁下去，桶就能装水了。
有些原因发作的机会就是多。程序每次启动都要跑的那段代码里有个 bug，它闯祸的机会，比藏在一个几乎没人点开的菜单里的 bug 多得多。可在 bug 清单上，两者都只占一行。只有数一数，才分得出谁是谁。
回报写在鲍尔默的信里：靠错误报告，Office XP 第二个服务包消除了一半以上的 Office XP 错误。
给这条规律起名字的人，后来亲口承认名字起错了。质量专家约瑟夫·朱兰在 20 世纪 20 年代中期注意到，缺陷按次数一排，少数几种占了大部分。后来，通用汽车的一位经理给他看了一项研究：通用高管的薪酬分布，和意大利经济学家维尔弗雷多·帕累托的一个数学模型吻合得出奇。帕累托研究的是财富分配有多不均。朱兰写《质量控制手册》（1951 年）时，要给这条普遍规律起个短名字，就借了帕累托的名字。「关键的少数，次要的多数」也是他造的词，后来「次要」改成了「有用」。1974 年他写文章认错：帕累托的模型讲的是经济，本不打算用到别的领域。「要是我换个性子，」他写道，「肯定就把它叫作朱兰法则了。」
而且 80/20 只是个形状，不是常数。朱兰自己下的定义里没有数字：「相对少数的贡献者，占了效果的大头。」鲍尔默的信里也看得出来：同一堆报告，切一刀是 20% 对 80%，换一刀就是 1% 对一半。
不会崩溃的错误
微软这套系统后来叫 Windows 错误报告（WER），它把报告分进一个个「桶」，每个桶装很可能由同一个 bug 引起的报告。系统收上来、客户也同意发送的崩溃，都会落进某个桶里。
AI 助手把日期弄错，什么都不会崩。对话照常往下走，没有报告自动发出。得有人把对话读一遍，判断哪里错了。
做公寓租赁 AI 助手的 Nurture Boss 就是这么干的，参与其中的哈梅尔·侯赛因 2025 年 3 月把过程写了出来。团队把对话放进电子表格，一行一段，每个不对劲的回答旁边写一句备注，再用大语言模型把备注归类，然后计数。结果三类问题占了六成以上：对话衔接（漏掉上下文、回答别扭）、转人工（没意识到该把用户交给真人）、改约时间。日期是重灾区，比如用户说「两周后约个时间看房」。团队专门为这类情况写了测试，之后日期处理的成功率从 33% 提到了 95%。
你也可以给常用的 AI 工具数一回：挑五十段让你失望的对话，各贴一个短标签，排序。针对排第一的那类改一处，下周再数，看那一行有没有变短。
一堆投诉
假设你管着一家小网店的客服邮箱，这一周积了 212 封投诉。上回遇到这种情况，你是从第一封开始，一封一封回的。
这一回，你先花一小时，给每封邮件贴个标签。有四个标签绕着同一件事打转：没收到确认邮件、没有物流单号、「我的订单到底下成功没有」，还有人因为拿不准，又下了一单。这四个标签加起来占了一半多，而且都指向同一个地方：结账页面改版以后，订单确认邮件（物流链接就在里面）再也没发出去过。剩下的尺码不对、箱子破了，各有各的原因。
标签也可能排出来差不多平均。朱兰把这种看不出明显分界的情形叫作「尴尬区」。遇到这种时候，先看看有没有哪个标签指向你能改的东西。如果一个都没有，这堆投诉也许本来就没有一小撮主要原因，一封一封回，就是该做的事。
这一回有。你先给改版以后下单的每个人写信：订单已经成功，这是物流链接，重复下的单这样取消。然后把确认邮件修好，再去回尺码和破箱子的投诉。到了下一周，「我的订单在哪」从邮箱里最大的标签，变成了每天零星几封。