你有没有那种时刻：半夜两点，分布式系统告警，日志刷了一天屏幕，根因还是一团雾。你抱着电脑想，但凡有个同事能搭把手也好。
【灯光渐暗，你低头看了一眼你最信任的 AI agent】
——你猜它能不能帮你修？答案是：能，但全凭显灵。
这周有人做了个基准测试，叫 DDBench，专门考 AI 修分布式系统 bug。从 13 个开源分布式系统里挖了 60 个历史缺陷，号称是第一个专门针对分布式系统的代码修复基准——这话我信。分布式系统的 bug 难到什么程度呢，懂的都懂。不懂的人只会跟你说"你重启一下试试"。
它拿了 10 个大语言模型去跑同一批题，通过率最高差了 61 个百分点。
同一个 repo，同一个 bug，同一个 prompt。有的模型唰唰两下递上来一份近乎完美的 diff，有的模型在代码库里原地转圈，最后交出一个把错误处理逻辑整个删掉的补丁，自信到让你觉得它在故意演你。
而且这不是目测，论文里做了配对自助抽样，15 组顶级模型组合里 9 组的差异在 p<0.05 的水平上统计显著。
——不，是经过了统计学认证的瞎蒙。
最妙的是它做了个对照：只把缺陷症状和代码仓库给模型，对比额外附一份"受限的调试上下文"——日志、trace、运行时状态、定向的代码调查说明。整体通过率平均涨了 18.1 个百分点。
但真正好笑的是这个提升的不对称性：弱模型靠着调试上下文把题做对了；强模型通过率没怎么动，只是解题效率上去了。
翻译一下：考前划重点，差生抱着重点狂喜猛抄，及格了；优等生瞟了一眼说"这我早知道了"，然后默默把卷子写快了一点。
给 AI 喂日志也是一样的。笨模型：有日志，狂喜，照着翻，找到了。聪明模型：日志扫一遍，确认了自己本来就猜到的 bug 位置，然后加速下笔——正确率没变，变的是速度。
写到这里我本来想展开讲讲"分布式系统 debug 到底难在哪"，后来发现这个坑我能讲三千字，咱们直接跳过。
我真正想说的其实是论文里最不起眼、也最让我笑出声的那句：调试上下文这东西得小心构建，因为——注意，关键词是"因为"——即使日志、trace、runtime state 全都忠实反映了系统的真实状态，模型有时候还是会被带偏。
真日志，真 trace，真状态。每一步都没骗它，它还是自信地走进了一个完全错误的修复方案。
这个点我太有共鸣了。人类 debug 不也是这样吗？日志没骗你，trace 也是真的，你在错误方向上坚信不疑地排查了两个小时，最后发现——是你自己骗了自己。
AI 终于在这一刻像我同事了。
论文现在 Under submission，正在评审。如果评审意见是"建议补充更多真实生产环境的数据"，那我建议作者干脆把审稿人也拉进去测一遍。
——反正结果大概率一样：信息越给越多，方向越带越偏，最后大家都在互相甩锅，只有日志在那里诚实地忠实地刷屏。
（友情提示：Under submission 的意思就是——别人还在看，结果还没出，你自己心里也没底。俗称：分布式系统的日常。🫠）