那个让我抓狂的bug，我竟然被雇来专门修复它

我挠不到的痒处

想象一下：你正在查阅文档，不停地输入文字，搜索结果却在你三个字符前输入的内容和你现在输入的内容之间不断闪烁。这就像和一个永远慢你三秒钟的人交谈一样。

作为背景，Mintlify为开发者提供托管文档网站（类似于 GitBook，但更酷）。他们收购了我之前的公司 Trieve，讽刺的是，Trieve 正是他们三万多个文档网站背后的搜索基础设施提供商。所以，我不仅是个受挫的用户，还是那个搜索技术被……嗯，可以说是“差强人意”地实现的人。

问题出在哪里？他们没有中止防抖搜索查询。每次按键都会触发一个新的搜索请求，但旧的请求却不断返回，造成混乱的竞争条件，使搜索感觉迟缓且不可靠。

看看这疯狂的景象：

我之前还是供应商的时候，就在我们的共享 Slack 频道里提到过这个 bug。“嘿，你知道你们的搜索功能有这个竞态条件问题吗？”我会这样说，既想帮忙，又不想显得自己是那种爱挑剔客户产品问题的人。

但这并非当务之急。这无可厚非——还有更重要的事要做，更关键的功能需要发布，以及真正能影响营收的工作。即使每次使用都让人略感不爽，但略微不流畅的搜索体验并不会让你的业务一蹶不振。

那种挫败感是真真切切的。我靠搭建搜索基础设施为生，眼睁睁看着自己的技术因为一个简单的前端疏忽而瘫痪，就像看着有人开着法拉利，挂着一档，还拉着手刹去送披萨一样。

收购完成后，我正式加入了团队，可以访问代码库，你猜我修复的第一个问题是什么？

你说对了。是该死的搜索竞争条件。

解决方案是什么？一个简单的AbortController。当新的搜索查询开始时，中止之前的查询。我知道，这听起来很革命性。现在搜索结果能够真正与你当前输入的内容相对应，而不是被动地追赶你的按键操作。

这让我想起乔治·霍茨在埃隆收购推特后短暂注册过账号，修复了烦人的登录弹窗，然后就迅速离开了。有时候，你就是得自己动手解决一下。

真正让我感到沮丧的是：如果 Mintlify 在那两年痛苦的日子里是开源的，我只需要提交一个 PR 就行了。一个 AbortController，也许 10 行代码，搞定——所有人的问题都解决了。

然而，这个小小的烦恼却在成千上万个文档网站上不断滋生，如同数字时代的酷刑一般，缓慢地侵蚀着用户体验。这并非因为修复它有多么困难，而是因为那些真正关心并愿意修复它的人却无法触及到修复的入口。

别误会我的意思——我理解公司为什么选择专有模式。这其中有合理的商业考量。但开源有一种令人着迷的赋能作用：当遇到问题时，你可以真正采取行动，而不是只能对着空气抱怨。

如果感觉 Mintlify 的搜索功能现在更流畅了，输入时响应也更灵敏了——那就是我的感受。我修复了困扰我两年多的搜索体验 bug，感觉棒极了。

但从更宏观的角度来看：这就是传奇产品诞生的方式。

并非通过宏大的举措或革命性的功能，而是通过对大多数人会忽略的细微之处的精益求精。比如10毫秒的提升，那些只影响0.1%用户的边缘情况，以及那些几乎难以察觉却能让一切都变得更好的改进。

终于有能力解决那些让你烦恼的事情，哪怕它们微不足道，也会带来一种深深的满足感。

尤其是当它们是微观的。

归根结底，用户体验不是在会议室或设计冲刺中打造出来的，而是一次次解决一个个小问题，一次次修复一个小缺陷，一次次添加一个 AbortController 代码，最终才得以实现的。

有时候，解决这些小问题的动力非常强烈，你甚至会被专门雇佣去做这件事。