神的陨落：Fable 5竟然也会写bug

这周发生了一件事，让我对 AI 模型的认知产生了一次不小的震动。

我一直是 Fable 5 的重度用户。在我心里，它是当下最强的编码模型，没有之一。它的推理能力、解题能力、找 bug 的能力，都让我觉得这东西已经强到我没法评价了，因为它的水平在我之上，我看不出它哪里不好。

我甚至写过一篇文章《Claude Mythos可能是历史上第一个超人工智能（ASI）》，认为 Mythos 系列（Fable 5 正是它的变种）可能已经跨过了某条历史性的线。那时候我是认真的。

直到这周，我在一个项目里连续发现了好几个 Fable 5 写出来的 bug。

不是产品层面的问题，不是设计层面的问题，就是代码逻辑有漏洞。写错了。

这件事对我的冲击很大，因为它打破了我一个根深蒂固的假设：Fable 5 这么善于找 bug，它自己写的代码应该是严谨的。

但事实证明，不是这样的。现在回头看那篇关于 ASI 的文章，我觉得自己当时乐观了。Fable 5 确实在某些维度上远超人类专家，但"远超"和"完美"之间还隔着一段很长的距离。它能几小时扫出几千个安全漏洞，但它自己写的代码里也会藏着漏洞。这个矛盾本身就值得深想。

善于找 bug，不等于写代码没 bug

仔细想想，"它能找到别人的 bug，所以它自己不会犯 bug"这个假设本身就有问题。

"能发现别人代码里的错误"和"自己写代码不犯错"，是两种完全不同的能力。审查别人的代码，是一个相对受限的任务：代码已经写好了，上下文是明确的，你只需要集中注意力去找局部的逻辑问题。这件事对注意力的要求是聚焦的、单一的。

但从零写一个系统就完全不同了。你要同时考虑架构设计、状态管理、边界条件、模块之间的交互、异常处理……每一个维度都在竞争你的注意力。在这种多维度并行处理的过程中，任何一个维度稍微分神，就可能漏掉一个细节。

这在计算机科学里有一个经典的类比：验证一个答案是否正确，往往比从零找到正确答案要容易得多。这就是 P 与 NP 问题的核心直觉。你可以很快验证一个数独的答案对不对，但要从空白格子自己填出来就难多了。

人类也是这样。最好的代码审查者，自己写代码的时候一样会犯错。最好的编辑，自己写文章的时候也会有语病。这不是态度问题，是认知资源分配的结构性限制。

让我觉得值得深思的是：如果 AI 也逃不过这个问题，那它可能就不是"人性的弱点"了。它指向的是某种更底层的东西。在有限的计算资源下，不管你是碳基大脑还是硅基芯片，生成和验证这两类任务对资源的需求模式天然就是不同的。这不是缺陷，是物理约束。

不只是"偶尔犯错"，是能力结构本身的取舍

发现 Fable 5 会犯错之后，我开始重新审视另一个之前困扰我的现象：Fable 5 的语言表达为什么感觉变差了？

之前我以为这是因为它太聪明了，聪明到语言表达已经超出了我的理解能力，所以我觉得"不好"只是我看不懂。但最近读了智谱创始人唐杰教授的一篇分析，我才意识到事情没那么玄乎。

唐杰提到一个很关键的事实：GLM-5.3 和 GLM-5.2 的基座模型、架构、参数量完全一样，唯一的变量是后训练阶段增加了强化学习。就是这一个变量，让模型在编码和长程任务上获得了大幅提升。（关于这个话题，我写过一篇更详细的拆解：《深度解读：GLM创始人唐杰眼中的Scaling Law与大模型变强的真正逻辑》）

这说明什么？说明当基座足够大的时候，模型的能力方向不是由参数量决定的，而是由后训练的方向决定的。你把训练资源往编码方向砸，编码就变强。但资源是有限的，编码变强的同时，其他方面可能就被挤压了。

回头看 Fable 5，逻辑就通了：它的编码能力和长程推理能力确实非常强，但语言表达的精细度下降了。这不是因为它太聪明我看不懂，是它在训练过程中把资源大幅向编码倾斜了。

为什么编码能力容易通过强化学习提升，而语言能力不容易？这个问题我在之前的文章《会编程的大模型千篇一律，有灵魂的大模型万里挑一》里做过更深入的分析。核心原因很直接：编码任务有明确的奖励信号。代码能跑就是能跑，测试能过就是过，对错分明，RL 可以高效地优化。但语言表达的"好"是什么？是流畅？是精准？是有层次感？是有洞察力？这些标准是模糊的、多维的、主观的，很难给出一个清晰的奖励信号让 RL 去优化。

一个有力的佐证是：同一家公司（Anthropic）的另一条模型线 Opus 4.6，没有像 Fable 5 那样大幅向编码方向倾斜，至今在语言表达的流畅性和细腻度上仍然是顶级的存在。同一家公司，同一个技术底座，不同的训练方向选择，产出了能力轮廓截然不同的两个模型。这恰恰说明这个 trade-off 是真实的工程选择，不是技术瓶颈。

所以我对 Fable 5 之前的判断需要修正：它不是一个全面超越一切的"神级模型"，它是一个在编码维度上极其优秀、但在语言维度上有所牺牲的偏科生。

当然，这种 trade-off 不一定是永久的。如果未来在语言质量的奖励建模上有突破，编码和语言可能可以同时提升。但至少在当前阶段，各家模型厂商都在根据自己的战略判断做取舍，没有谁真正做到了"全面碾压"。

那代码能不能做到零 bug？

想通了"Fable 5 也会犯错"这件事之后，我自然就产生了下一个问题：如果连最强的模型都写不对代码，那未来有没有可能彻底解决这个问题？有没有一天，AI 写的代码就是没有 bug 的？

这个问题的答案，比我预想的要深刻。

先看一个例子。假设有这样一段程序：

n = 4whileTrue:if 这个偶数不能写成两个质数的和(n):print("找到反例了！")break    n += 2

逻辑很简单：从 4 开始，逐个检查每个偶数，看它能不能被写成两个质数的和。如果找到一个不行的，就输出结果并停下来。如果都行，就一直循环下去。

这段代码有没有 bug？

答案取决于"哥德巴赫猜想"（每个大于 2 的偶数都能写成两个质数的和）是不是真的。如果猜想成立，这段代码永远不会停，是一个死循环 bug。如果猜想不成立，它终究会找到反例然后正常退出。

但哥德巴赫猜想是数学界几百年来都没有证明的问题。这意味着：判断这几行代码有没有 bug，等价于解决一个人类顶级数学家都解决不了的难题。

这不是人为构造的极端情况。图灵在 1936 年就证明了一个更一般的结论：不存在一个万能程序，能判断任意其他程序是否会停下来（著名的"停机问题"）。而"这段代码有没有 bug"在很多场景下可以归约到停机问题，所以通用的零 bug 检测，在数学上就是不可能的。

但也不必因此悲观。这是理论上的天花板，不是说实践中无法改善。现实中大部分代码不涉及未解数学猜想。在受限的领域（比如"写一个排序函数"），模型完全可以生成形式化可验证的正确实现。在真实项目中，通过测试、代码审查和静态分析，也可以大幅降低 bug 率。

更合理的期待不是"零 bug"，而是"bug 的密度持续下降，发现和修复的速度持续加快"。

但这引出了一个重要的实践结论：不管未来的模型多强，写完代码之后的检查环节都不应该省略。这不是因为不信任模型，而是因为整个系统的风险来源不只是"模型可能犯错"这一个维度。需求本身的模糊性（你以为你说清楚了但实际没有）、外部环境的变化（API 升级了、依赖库改了）、模块组合的复杂性（每个模块单独没问题但交互出问题），这些都不是模型变强就能消除的。

类比建筑行业：再好的建筑师也需要结构审查、消防审查、质量检验。没有人会因为建筑师足够优秀就取消这些流程。检查不是对模型的不信任，是对工程的尊重。

既然没有神，怎么办？

想清楚这些之后，我开始调整自己的工作流。

之前的做法是：交给 Fable 5，写完直接用。因为我信任它。

现在的做法是：写完之后，用别的模型来交叉检查。

我试了一下，效果出乎意料地好。用 Kimi3 查一遍，用 GLM5.3 查一遍，用 GPT 5.6 sol 查一遍，它们确实能从不同的视角发现一些 Fable 5 遗漏的问题。当然，它们的报告里也有误报，但没关系，最终让 Fable 5 再确认一遍就行。

这个策略有效的核心原因是：不同模型的训练数据、架构偏好和强化学习方向不同，它们各自有不同的"盲区"。一个模型的盲区，恰好可能是另一个模型的敏感区。这和软件工程中 code review 的逻辑一模一样：写代码的人最难发现自己的 bug，因为他的思维模式会沿着同一条路径走。

有意思的是，用来检查的模型不需要比 Fable 5 更强。

我甚至试过用 Qwen3.8-27B 来检查 Fable 5 的代码。一个 27B 参数的模型去审查一个比它大几个数量级的模型写出来的代码，听上去有点荒谬。但它确实偶尔能抓到一些东西。原因不是它"更聪明"，而是它的训练数据和思维路径跟 Fable 5 足够不同。一个围棋九段可能会自动过滤掉"不优雅"的棋路，但一个业余棋手反而可能注意到那步"俗棋"恰好能解决当前的问题。强模型有强模型的思维惯性，这种惯性有时候恰恰是盲点的来源。

同样的逻辑也适用于蒸馏模型。Opus 5 在很多基准测试上跟 Fable 5 几乎持平，SWE-bench Verified 上甚至高了一个百分点（96.0% vs 95.0%）。按说蒸馏模型应该是"老师的弱化版"，但蒸馏过程中的信息压缩不是均匀的，它会丢失一些东西，也会被迫学到一些不同的内部表示。就像你把一幅油画拍成照片，照片损失了笔触质感，但可能让构图问题反而更明显了。所以蒸馏模型也完全可以拿来做交叉检查，它看到的不一定比老师少，只是看到的东西不一样。

这就引出一个自然的追问：那是不是应该把市面上所有模型都跑一遍，才是最全的？

理论上，是的。每多一个不同的模型，就多一个潜在的视角。但实践中有递减收益的问题。前两三个不同的模型带来的"视角增量"最大，因为它们之间的训练差异足够显著。但从第四、第五个开始，新增的独特视角越来越少，而误报噪音却在持续累积。每个模型都会提出一些"其实没问题但它觉得有问题"的建议，你花在辨别误报上的时间会越来越不值得。

所以这不是一个"越多越好"的问题，而是一个成本收益的权衡。至于最优数量是多少，我现在没有确切的答案。我自己目前的做法是用三到四个训练路径差异较大的模型来交叉检查，但这个数字是从个人实践里摸索出来的，不是什么严格的结论。不同的项目复杂度、不同的风险容忍度，最优组合可能完全不同。

不过有一点我比较确定：选模型的核心标准不是"谁更强"，而是"谁更不同"。一个重度 RL 编码模型、一个语言能力强的通用模型、一个国产模型（训练数据分布和英文主导的模型有显著差异）、一个参数量明显不同的小模型，这种多样性比单纯堆叠同类型的强模型有价值得多。

写在最后

回过头看，从"把 Fable 5 当神"到"理性地看待它的能力边界"，这个认知转变并不是一件坏事。

之前我对它的期望是"它什么都能做好"，遇到问题就觉得是自己的 prompt 没写好。现在我知道了，它在编码维度上确实非常优秀，但它不是全能的。它有自己的能力轮廓，有自己的强项，也有结构性的局限。

而且这些局限不是 Fable 5 独有的。各个模型现在的能力差距，远没有两年前那么大了。Kimi3、GLM5.3、GPT 5.6 sol、Qwen 系列，这些模型在编码能力上都非常强。"最强模型"和"其他模型"之间的距离在收窄，差异更多体现在能力的分布形状上，而不是绝对的高低。

去神化不是看低它，是找到更高效的使用方式。多个"不完美"的模型协作起来，互相校验，互相补盲区，这比依赖任何单一的"神级模型"都要可靠。

没有哪个模型是神。但想通了这一点之后，你反而能比以前用得更好。

我建了一个AI学习研究群，目前几十来人，都是在真正动手搞AI的人。

如果你也在自己跑模型、写代码、做项目，

或者使用Claude和Claude code，

欢迎点赞关注转发一键三连，然后加我微信，备注写清"你在做的AI方向"，聊得来的话我拉你进群。纯围观的和小白就不加了，有一定门槛。当然你也可以简单粗暴的甩给我999元，我拉你进群，这个没门槛。