GPT-5.5和Opus 4.8都搞不定的Bug，被Fable 5一晚上解决

今天这篇，是一个破案故事。

主角不是我。主角是 Claude 家刚发布的新模型，Fable 5。

—

一、悬案

事情要从几个月前说起。

我的Raphael AI ( https://raphael.app ) 收到一类诡异的投诉：用户登录自己的账号，看到的却是一个陌生人——陌生人的名字，陌生人的头像，陌生人的全部生成历史。

第一次看到投诉截图的时候，我头皮发麻。

然后这种投诉却一次又一次出现，连国内用户也反馈给我了。

（在这里谢谢 @欢乐哥 ，他是Raphael AI的重度用户，连续反馈了两次）

这类 bug 有多邪门，我列给你看：

百万级用户里，只有几百人中招。概率低到像都市传说。我根本没有办法可以复现它！

无法复现。我们怎么测都测不出来，测试环境从来没出现过。

双向互串。A 能看到 B 的账号，B 也能进 A 的。

跨设备。一边是 Mac 上的 Chrome，另一边是 iPhone 上的 Safari。

全球随机。东京、巴黎、多伦多……毫无地域规律。

最邪门的是最后一条：数据库查不出任何异常。登录凭证全部唯一，安全检查全过，代码里翻不出任何"共享状态"。

它就这么挂着。像房间里有一只看不见的蚊子，你知道它在，但你拍不到它。

二、自信的错误答案

我当然第一时间求助了AI。事实上，这个Bug第一次出现到现在已经好几个月了，我不断再让AI协助我。

先问 GPT-5.5，我把所有的日志、Cloudflare API、Sentry API全部给它了。老读者知道，我以前是 GPT-5.5 的吹爆党，重要的事都喜欢找它要第二意见。

GPT-5.5 的回答斩钉截铁：

“这是 Cloudflare 的缓存 bug。你的代码没有问题。建议你向 Cloudflare 提交工单反馈。”

它说得太笃定了，笃定到我差点真的去提工单。

再问 Opus 4.8。它很诚实，排查了一圈，说找不到确定的方向。

这里也能看出来Opus 4.8一个胜过GPT-5.5的优点 —— 它的确更容易承认“我不知道”，幻觉概率更小。

诚实是诚实，但案子还是悬着。

这一轮下来，我想说一句体会：

自信的错误答案，比没有答案更危险。

没有答案，你最多原地踏步。自信的错误答案，会烧掉你最贵的东西——时间，还顺便烧掉你对正确方向的注意力。

三、Fable 5 说：别猜了

Fable 5 发布后，我把这个悬案丢给了它。

它做了一件让我愣住的事。

它没有给答案。

它说（大意）：现有的信息，不足以定位问题。任何结论都是猜测。我们停止猜测，开始埋取证。

然后它当场设计了一套"破案监控系统"：

1. 给每一个登录相关的响应装上"进出对账"——这个请求进来的时候你是谁，出去的时候服务器发给你的是谁的凭证，一一比对，对不上就报警。
2. 给每个用户的浏览器装上"身份哨兵"——没经过登出，身份却换了人？立刻上报现场证据。

下面展示一些截图

我非常佩服：它提前写好了判决书。它说，如果日志 A 出现，说明病在服务端，看日志里的路径就知道是哪个端点；如果 A 始终不出现、而 B 持续报警，说明病在网络层，该去查另一个地方。

证据还没回来，每种证据对应什么结论，它已经安排明白了。

这像什么？像刑警破案。不靠灵感，不靠直觉，靠在每个路口装监控，让嫌疑人自己走进画面里。

这里送大家一条今天就能用的方法论，也是我这次最大的收获：

遇到悬案，别让 AI 猜，让 AI 「设计取证」。

猜测的尽头是运气。取证的尽头是真相。

四、真相：一个 await

监控装好，部署上线。日志回来了，毒源现形。

凶手是我们用的一个广为人知的开源认证库——BetterAuth 的某个老版本。

用大白话讲讲这个 bug。

服务器处理登录的时候，要往一个"响应头容器"里装用户的登录凭证。正常的写法，每个请求一个容器，各装各的。

这个库的老版本呢，所有请求共用一个容器。

平时相安无事。因为大部分时候，请求是一个一个排队来的。

但是，往容器里装凭证的过程中，有一步异步操作——代码里的一个 await——会让整个流程"挂起"那么零点几毫秒。

就在这零点几毫秒里，如果恰好有另一个用户的登录挤了进来——

两个人的凭证，装进了同一个容器。

用户 A 的登录凭证，装进了用户 B 的响应。B 的浏览器一收下，B 就变成了 A。

一个 await，让用户变成了别人。

这一个解释，把前面所有的"邪门"全部串起来了：

为什么无法复现？因为它只在两个请求挤进同一毫秒时触发，本地测试根本没有那个并发量。

为什么百万人里只有几百人中招？因为这是一场概率游戏，流量越大，开奖越频繁。

为什么全球随机、跨设备？因为毒在服务器的响应里，跟你用什么设备、在哪个国家，毫无关系。

Fable 5 给它的定性是：教科书级的并发事故，只有高并发的生产环境才会现形。

这类Bug在BetterAuth里还有好几处，我就不一一展开了

更有意思的是——这个 bug，BetterAuth库的官方并不知道。

新版本是彻底重写的，不是老版本的升级。老版本的坟，没人去挖。

我们大概是全球第一批挖开看的人。

这里说“们”，我可能是有点狂妄了。准确的说，是Fable 5，不是我。

五、还没完：退烧之后，还要清病灶

你以为打个补丁就结束了？

没有。这才是这个故事里我最想保留的部分。

第一版补丁打上去，部署，报警继续响。

排查发现一个特别"工程"的坑：这个库发布的时候带两套构建产物（懂行的朋友知道，ESM 和 CJS，可以理解为同一本书的精装版和平装版）。我们只补了其中一套——而线上实际跑的是另一套。

补全两套。报警频率降下来了。

但还在响。

换别的 AI，到这一步大概率开始车轱辘话了。Fable 5 又看了一轮新日志，给出第二个判断：急性中毒已经止住了，但几个月的串号，在数据库里沉淀下了慢性病灶——近百对用户被错误地"绑"在了一起，他们每次登录，系统都在两个身份之间掷硬币。

于是又是一轮：先备份，再生成一张"清理决策表"让我过目，然后单事务清洗数据，最后给数据库上了唯一约束——把复发的门，从根上焊死。

对了，排查途中还有个黑色幽默：之前另一个AI（Codex GPT-5.5)帮我修别的问题时，顺手引入了一个慢查询，恰好把这个并发 bug 的触发窗口放大了几个数量级。

一个 AI 埋的雷，给另一个 AI 的 bug 当了扩音器。

直到看到Fable 5给我的“完结撒花”！ 我终于松了一口气。

六、那一晚，我在干什么？

说出来不怕大家笑话。

我在复制粘贴。

把服务器的日志粘给它。把它给的命令粘到服务器。

折腾到后半夜，破案、打补丁、清数据、上约束、装好长期监控，全链路走完。

复盘的时候我意识到，那一晚我的角色，是一个给侦探递咖啡的助手。

真正的侦探，是 AI。

七、Not Productivity, Rather Capability

这件事过去几天了，我还在回味那种震撼。

让我震撼的，其实不是"它修好了"。

是它解题的方式：

它知道自己不知道，所以拒绝猜。

它设计实验，让证据说话。

它修完急性病，还主动去找慢性病。

它给自己的每一个动作，都留了验证手段。

这不是"答题答得好"。这是顶级工程师才有的工作品味。

很多人说，AI 是生产力工具。我以前也这么说。

现在我觉得，这个说法太小看它了。

生产力，是把同样的事，做得更快。

能力，是做到以前根本做不到的事。

这种全球范围内可能只有库作者本人才能定位的 bug，放在过去，我的选项只有两个：高薪去请一位世界级的并发专家——请不起，也找不到；或者，让它永远挂着。

现在，它住在我的终端里。

Not productivity, rather capability.

不是你做事的速度变快了。

是你能做到的事，变多了。

世界又变了。这次变的不是工具，是你能成为谁。