微信扫码
添加专属顾问
我要投稿
Fable 5 如何用一套“破案监控系统”,解决了GPT-5.5和Opus 4.8都束手无策的诡异Bug。 核心内容: 1. 一个无法复现、全球随机的用户账号“互串”悬案 2. GPT-5.5与Opus 4.8给出的不同诊断与局限 3. 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 发布后,我把这个悬案丢给了它。
它做了一件让我愣住的事。
它没有给答案。
它说(大意):现有的信息,不足以定位问题。任何结论都是猜测。我们停止猜测,开始埋取证。
然后它当场设计了一套"破案监控系统":
下面展示一些截图
我非常佩服:它提前写好了判决书。它说,如果日志 A 出现,说明病在服务端,看日志里的路径就知道是哪个端点;如果 A 始终不出现、而 B 持续报警,说明病在网络层,该去查另一个地方。
证据还没回来,每种证据对应什么结论,它已经安排明白了。
这像什么?像刑警破案。不靠灵感,不靠直觉,靠在每个路口装监控,让嫌疑人自己走进画面里。
这里送大家一条今天就能用的方法论,也是我这次最大的收获:
遇到悬案,别让 AI 猜,让 AI 「设计取证」。
猜测的尽头是运气。取证的尽头是真相。
监控装好,部署上线。日志回来了,毒源现形。
凶手是我们用的一个广为人知的开源认证库——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。
这件事过去几天了,我还在回味那种震撼。
让我震撼的,其实不是"它修好了"。
是它解题的方式:
它知道自己不知道,所以拒绝猜。
它设计实验,让证据说话。
它修完急性病,还主动去找慢性病。
它给自己的每一个动作,都留了验证手段。
这不是"答题答得好"。这是顶级工程师才有的工作品味。
很多人说,AI 是生产力工具。我以前也这么说。
现在我觉得,这个说法太小看它了。
生产力,是把同样的事,做得更快。
能力,是做到以前根本做不到的事。
这种全球范围内可能只有库作者本人才能定位的 bug,放在过去,我的选项只有两个:高薪去请一位世界级的并发专家——请不起,也找不到;或者,让它永远挂着。
现在,它住在我的终端里。
Not productivity, rather capability.
不是你做事的速度变快了。
是你能做到的事,变多了。
世界又变了。这次变的不是工具,是你能成为谁。
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2026-06-12
谁是 Agent 最强守门员?首个 Agent 技能安全评测基准 SkillTrustBench 正式发布
2026-06-12
Agent skill 迭代式编写实战
2026-06-12
Codex 大降价要来了,这份官方指南手把手教你高效榨干额度
2026-06-11
GPT-5.6首批实测来了!精准狙击Mythos
2026-06-10
如何利用 Harness “一句话交付产品功能”?
2026-06-10
面向 Agent Skill 的 CLI/SSO 鉴权体系:安全、无感、可追溯
2026-06-10
Loop Engineering 循环工程又是什么鬼?
2026-06-10
更懂你的ChatGPT来了!通过做梦整理记忆,事实准确率83%
2026-04-15
2026-04-07
2026-04-07
2026-03-31
2026-03-17
2026-03-17
2026-03-21
2026-04-24
2026-04-17
2026-03-31
2026-06-10
2026-06-10
2026-06-10
2026-06-07
2026-06-06
2026-06-03
2026-06-02
2026-06-01