经过多轮迭代的反复打磨，我们终于把 LLM 自动修 Bug 的流水线从数据输入、评分机制、Bug 分类到任务调度，全部架构优化了一遍。前置工程问题一个不剩，流水线的完整性、公平性、准确性都拉到了顶格。结果呢？数据给了我们一记冰冷的回旋踢：31% 的 A 级修复率——这就是当前通用 LLM 修 Bug 的硬天花板，任你工程优化再猛，也撬不动这堵墙。

一、5 轮流水线迭代：工程优化走到尽头，瓶颈依旧存在

R13 版本最终跑完 410 批常规任务、0 异步任务、29 批大容量任务，合计产出 494 条有效修复样本。五轮迭代下来，所有工程短板都被我们磨平了。

最亮眼的是 hint_bug_type 机制：原本那些只能盲猜的通用未知 Bug，数量直接暴跌 82%。分类器彻底告别闭眼猜的状态，能精准锁定 Bug 类型、区分问题场景。异步任务异常清零，种子任务成功率稳定在近 90%。这意味着输入、分类、调度、评分全链路已经成熟——没有任何工程层面的短板了。

但矛盾就在这里暴露得赤裸裸：分类越准，修复却没有变好，甚至失败率不降反升。

五轮迭代的数据一拉，有效修复率从 19.2% 涨到 42.7%，涨幅超过 23 个百分点。可最关键的 F 失败率呢？始终在 42%–49% 的区间里打转，几乎纹丝不动。所有能做的工程优化全落地了，流水线再也挤不出迭代空间。剩下的瓶颈不是工具、流程、Prompt 的问题——是 LLM 自身能力的天花板。31% 的 A 级完美修复率，稳稳地杵在那儿，告诉你：这就是通用 LLM 修 Bug 的真实极限。

二、拆解本质：LLM 修 Bug，从来不是理解，只是高级匹配

为什么工程优化拉满了，修复正确率依旧卡在 31%？答案可能会碘伏很多人的认知：LLM 修复代码 Bug，本质上根本不是代码推理与语义理解——它只是一次高级的 embedding 相似度匹配，然后统计文本拼接。它从没有真正“读懂”过代码，只是在复刻训练数据里已有的模式。

很多人以为 LLM 修 Bug 是智能推理，可它的真实工作逻辑简单到让人失望：拿到带 Bug 的代码和 Bug 类型标签，然后在海量训练数据里检索最相似的代码片段和修复案例，靠统计概率拼出最常出现的修复方案。全程没有理解、没有推演、没有逻辑验证。

这就是 31% 天花板的根源：只有大约 31% 的代码 Bug，其场景、逻辑、问题模式恰好和 LLM 训练数据里的案例高度吻合，能通过相似度匹配完成完美修复。剩下近 70% 的 Bug，涉及项目特有的 API、私有业务逻辑、隐含调用协议、生产环境专属的边界场景——这些是 LLM 训练数据里从未覆盖的内容。不管你怎么优化 Prompt、优化流水线、优化分类，它都只能盲猜，修复失败是必然的结局。

三、改错慢、改不对的根源：LLM 没有世界模型

落地实践中还冒出一个关键现象：LLM 生成代码极快，但修复 Bug 的速度慢了一个数量级。这个速度差，暴露了 LLM 的核心缺陷——它没有可以模拟的代码世界模型。

人类开发者修 Bug，最大的优势是心智模拟。看到一段问题代码，我们能在脑子里模拟运行流程、推演变量变化、预判边界问题、判断修复方案是否适配上下文——不用编译、不用运行，就能提前筛掉无效方案、避开错误修复。

LLM 完全没有这种能力。它不知道代码运行后的真实状态，不知道调用链里的隐含约束，不知道一处修改会引发哪些连锁副作用，无法进行任何心智模拟。对外部执行的依赖，成了它的唯一判断依据。

四、重新定位飞轮价值：不修 Bug，只造数据

五轮迭代走完，最初的核心目标被彻底推翻：Bug 飞轮的价值，从来不是提升即时修复率——而是持续产出高质量、可落地、稀缺的真实 Bug 训练数据。数据，是整个 LLM 修复闭环中，唯一不依赖模型自身能力的核心资产。

基于这套数据资产，后续的迭代方向彻底清晰。不再去做“强行突破 31% 天花板”的无效尝试，而是聚焦三条落地路径：搭建真实代码修复评测基准；构建 RAG + 可移植性判断的修复体系；垂直项目偏科微调 + 搭建完整执行反馈闭环。

结语

五轮流水线优化，让我们彻底看清了 LLM 修 Bug 的终极真相：31% 的完美修复率，是一堵真实存在的能力围墙。以前总想靠工程优化、Prompt 迭代、流程打磨去撞破这堵墙，到头来发现全是徒劳。

31% 是一堵墙。墙不是用来撞的，是用来知道路的。

承认 LLM 的固有边界，不再执着于无限提升单次修复成功率，转而深耕数据资产、搭建评测体系、重构修复流程、构建反馈闭环——这才是突破瓶颈、实现长期价值的唯一正确路径。LLM 不能成为修 Bug 的主力，但高质量的飞轮数据，终将喂养出真正能突破天花板的下一代代码智能模型。