那些意外变成特性的 Bug：当代码漏洞改写计算史

比起草台班子将错就错的神话，面对异常数据时的观测定力才是真的

社交网络上常年流传着一类爽文：某家公司的程序员把代码写崩了，结果不仅没被开除，这个 Bug 反而成了拳头产品,妥妥的爽文主角剧本。

最常被搬出来的有三个：Audio Hijack 写错试用期拯救公司、《太空侵略者》因硬件跑不动意外做出难度曲线、Gmail 撤回发送源于服务器 5 秒延迟修不好。

但是凭借一个工程师的直觉，我觉得事情可能并不那么简单。我去找了一些资料，发现很多有意思的事情，有一些确实是因为一个阴差阳错的‘bug’，反而让产品大卖，但是更多的情况，他们是后人编造的“地摊文学”。产品能大卖，完全是因为他们找到了用户真实的需求。

写错试用期，反而救了公司

2002 年，Paul Kafasis 和两位合伙人刚从大学毕业，发布了 macOS 录音工具 Audio Hijack 1.0。

他们最初的商业模式很常规：提供 15 天无限制试用，期满后收取 16 美元授权费。

到了 1.6 版本，计时逻辑出了问题。

代码里的试用期从 15 天（Days）被写成了 15 分钟（Minutes）。只要用户录音超过一刻钟，软件就会持续向音频通道注入白噪音，并弹出警告弹窗，锁死。

Audio Hijack 早期版本的 15 分钟试用弹窗，来源：Rogue Amoeba 官方博客 https://weblog.rogueamoeba.com/2025/08/21/when-a-bug-saved-the-company/

试用时间从 360 小时被砍成 0.25 小时，缩水整整 99.93%。

按常理这属于 P0 事故，团队本该连夜回滚或发修复补丁。

Paul Kafasis 在 2025 年 8 月的官方复盘博文《When a Bug Saved the Company》中写道：

"In version 1.6, we accidentally broke the intended 15 days of unrestricted usage." "Compared to giving away two-plus weeks for free, this stricter limitation led to dramatically higher sales."

准备发补丁前，他们看了眼后台：软件销量在当月暴涨。

原因很现实：15 天对录音工具太宽容了，用户录完一段音频就关掉，两周后早就忘了这回事。15 分钟的限制正好卡在用户验证完核心价值的节点上，想要导出完整音频，只能立刻付费。

团队没有发布恢复 15 天的补丁，而是把 15 分钟限制做成了正式策略。靠着这笔现金流，三位创始人在一年内全职投入创业，这家公司一直活到现在。

2 MHz 芯片跑出来的难度曲线

第二个案例发生在 1978 年。

太东（Taito）工程师西角友宏在开发街机游戏《太空侵略者》（Space Invaders）。当时市面上没有适合跑密集画面的现成主板，他只能基于主频仅 2 MHz 的 Intel 8080 微处理器自行焊接硬件。

硬件很快就会遇到算力瓶颈。

1978 年《太空侵略者》街机机台，来源：Wikimedia Commons CC BY-SA 3.0，摄影：Rama https://commons.wikimedia.org/wiki/File:Space_Invaders.JPG

游戏开始时，屏幕上有 55 只外星怪物，每帧都要重绘坐标。8080 处理器主频被吃满，画面刷新率极慢，怪物只能一顿一顿地缓慢挪动。

但随着玩家逐一击落外星人，屏幕上的活动实体变少，处理器的渲染负担迅速下降。

没有了计算负担，8080 开始全速执行指令。仅剩的几只外星怪物速度飙升，在屏幕两端飞快闪烁。

如果按常规思路，程序员应该加一段空循环把帧率锁死在固定速度。

西角友宏测试时发现，怪物越来越快带来了极强的紧迫感，远比固定匀速刺激得多。他选择保留这个硬件缺陷，顺便把四音符背景音效的循环节奏与运算速度绑定在一起。

游戏史上的第一个动态难度曲线（Dynamic Difficulty Curve），就这样被留在了成品里。

Gmail 撤回发送：彻底造假的地摊传说

短视频里最火的段子长这样：“Google 工程师发现 Gmail 服务器有 5 秒延时修不好，干脆在前端加了个撤回按钮，假装是特性。”

只要懂一点网络通信，就会发现这个逻辑站不住脚：SMTP 协议把报文投递出去就脱离了客户端控制，5 秒延时绝不可能被封装成特性。

翻看 CNN 与 Vice 当年对关键当事人的采访，真实过程完全是另一回事。

2006 年，Google 设计师 Michael Leggett 负责 Google Finance 界面设计。深夜写完一封包含敏感讨论的长邮件后，他本想点“保存草稿”，结果误触了紧挨在旁边的“发送”按钮。

邮件在没有二次确认的情况下直接发了出去。

这次事故让他意识到人在发邮件后存在心理后悔期。2007 年他调入 Gmail 团队，拉上工程师藤岛悠三（Yuzo Fujishima）专门做了一个前端延时队列：

点击发送后，浏览器不会立即发送请求，而是先在本地定时器里挂起 5 到 30 秒，并在顶部展开撤回链接。倒计时结束且没有操作，才向服务器发起真实发信请求。

这里没有修不好的 5 秒网络延时，只有一次针对人机交互痛点的防御性设计。短视频之所以把它传成 Bug，只是因为“程序员掩盖事故”比“设计师手滑提需求”更适合当八卦消费。

另一个被留下的漏洞：MySpace 漏配的过滤器

2004 年的社交巨头 MySpace 也有过类似经历。

根据 Julia Angwin 的调查专著《Stealing MySpace》，工程师 Toan Nguyen 在赶工重写底层系统时，忘记开启用户简介输入框的 HTML 与 CSS 标签转义过滤。

MySpace 2006 年用户破亿截图，来源：Wikipedia Public Domain https://en.wikipedia.org/wiki/File:Myspace-count-200608211853UTC.png

在现代 Web 标准下，这是典型的存储型 XSS 漏洞。

但用户发现输入标签能改变排版后，就直接用各种自定义字体、荧光背景，甚至自动播放音乐装扮主页。

管理层查验后台后发现，花时间装扮主页的用户日均在线时长是普通用户的四倍多。团队因此压下了修复补丁，把这个安全隐患直接包装成了平台的核心竞争力——“个性化主页”。

留给工程师的真实思考

这几个案例之所以让人津津乐道，是因为当事团队面对代码偏离预期时，没有急着按下恢复代码的回车键，而是多看了一眼用户的实际反馈。

但这绝不是放任糟糕代码的借口。

现实中 99.9% 的未预期缺陷只会带来报警电话、死锁和故障单。MySpace 放任代码注入，后来引发了感染百万用户的 Samy 蠕虫病毒，留下巨大的安全隐患，最终为 Facebook 的后来超越埋下了伏笔。

能变成杀手级特性的缺陷属于极低概率的幸存者偏差。

真正有价值的动作，是在面对异常数据与奇怪的用户用法时，多保持一份好奇：在关闭工单之前，看看用户到底在用那个不合规矩的逻辑来解决什么问题。