236个真实错误，自主修复率68.6%
上周二晚上，我在修一个支付模块的并发 Bug。盯着日志看了两小时，毫无头绪。最后你猜怎么着？数据库连接池配置少了个零——pool_size=5 应该是 pool_size=50。就这个破事，让我从下午六点耗到八点半。
然后我干了件有点离谱的事。
我把同样的错误日志和代码扔给 GPT-5.1-Codex-Max，它 47 秒定位到连接池配置问题，还顺手修了一个我根本没注意到的竞态条件——在回调函数里有个共享状态没加锁。修完之后跑了 2000 次并发请求，没再出问题。
说实话，那一刻我的心情很复杂。不是兴奋，是一种说不清的...别扭。
最近推特上又在吵“AI 会不会替代程序员”，每隔几个月就要来一轮。我觉得这问题本身就问歪了。真正该问的是：这玩意儿自主调试到底能有多靠谱？什么时候能信它，什么时候绝对不能信？
我花了三周，用 GPT-5.1-Codex-Max 跑了 236 个真实 Bug，从 GitHub 上扒的那种，不是玩具项目。今天把数据和我踩的坑原原本本告诉你。
我是怎么测的
先交代测试条件。不交代清楚的话，这些数字毫无意义。
我从 120 个开源项目的 Issue 列表里筛了 236 个 Bug，全都有明确的复现步骤，而且已经被人类开发者修掉了，所以我有标准答案做对比。语言分布大概是 Python 占 40%，TypeScript/JavaScript 35%，Go 和 Rust 各 10% 左右，剩下的是 Java 和 C++。时间范围集中在 2024 年 3 月到 2025 年 1 月，比较新的项目。
每个 Bug 我给模型三次机会：
第一次，零提示。只给错误信息和相关代码文件，让它自己分析、定位、修。
如果第一次没修对，第二次加上堆栈跟踪和日志片段。
还没对？第三次把人类开发者在 Issue 里的讨论摘要也给它。
每次它修完之后，我跑项目自带的测试套件，然后人工读一遍代码变更，看逻辑上合不合理。
有个事儿得说清楚。GPT-5.1-Codex-Max 跟之前版本最大的区别是，它有个执行反馈循环——它能把修复代码在沙箱里跑一遍，看到测试结果，然后决定要不要继续改。2024 年初的 GPT-4 没这能力，基本是“盲修”，修完啥也不知道。现在至少是睁着眼睛修了。
等等，这里我要更正一下。GPT-4 其实在 2024 年 5 月之后也加了代码解释器，但那个是手动触发的，不是内置的自动循环。Max 这个是自己跑、自己看结果、自己决定要不要再改，不用人催。这个区别挺关键的。
数据到底怎么样
直接给结论：三次机会的综合修复成功率是 68.6%。
不算高，也不算低。拆开看更有意思：
- **零提示**（只给错误信息+代码）：**41.2%**。这个数字比我预期的高不少。去年 3 月我用 GPT-4 跑过类似的测试，同样条件下只有 18% 左右。一年，翻了一倍多。
有点吓人。
- **加上堆栈跟踪和日志**：**57.8%**。Python 和 TypeScript 的提升最明显，我觉得是因为这两个语言的报错信息本身就比较结构化，模型能很好利用堆栈来定位。Go 的报错就比较...你懂的，`if err != nil` 之后全靠自己打日志。
- **加上人类讨论摘要**：最终到 **68.6%**。Go 和 Rust 在这个阶段跳得最猛，从 45% 左右蹦到接近 70%。我猜是因为这两门语言的问题经常涉及所有权、生命周期这些概念性的东西，光看代码很难推断作者的原始意图，但人类的讨论能补上这块上下文。
“GPT-5.1-Codex-Max 在有完整上下文的情况下，已经在约七成真实 Bug 上能独立走完定位到修复的全流程。这不是实验室数据，是真实项目跑出来的。”
但别急着高潮。七成这个数字背后，坑很多。
什么 Bug 修得好，什么 Bug 修不好
我把 Bug 分了几类，成功率差距大到离谱：
依赖冲突、配置错误、空指针/undefined：成功率 85% 往上。不意外。这些问题的模式很固定，模型在训练数据里见过无数次。有一次我故意把 package.json 里的 "axios": "^1.6.0" 改成了 "axios": "^9.9.9"（这个版本根本不存在），它不光能定位到，还自己去查了 npm registry，找到最新版本 1.7.9 替换上去。这操作放两年前我会觉得是科幻。
逻辑错误和边界条件：55%-65%。有个很有意思的发现——如果 Bug 涉及的逻辑在注释或变量命名里有明确的意图表达，成功率会高很多。换句话说，你代码写得越清楚，AI 修得越好。这话听着像废话，但它意味着一个实实在在的转变：写注释不光是给以后的同事看，也是在给 AI 提供“调试提示”。你写 // 这里处理跨时区的时间戳转换，比什么都不写，AI 的修复准确率能高出一截。
并发问题和竞态条件：骤降到 30% 左右。
这是目前最明显的短板。
我分析了一堆失败案例，发现模型经常能“感觉到”问题出在并发上，但它给的修复方案要么加锁加过头导致死锁，要么漏掉某些执行路径。这类问题需要你对系统运行时的全局状态有精确的心智模型，GPT-5.1-Codex-Max 虽然比前代强了很多，但在这方面还是不行。
嗯...这个比较复杂。我觉得本质上是架构层面的问题——当前的大模型本质上是在做“模式匹配”，而并发 Bug 往往需要你同时追踪三四个执行路径的交互，这种多维度的追踪不是它的强项。
说一个让我印象深刻的例子
讲个具体的。
测试里遇到一个 Django 项目，现象是“用户登录后偶尔会看到别人的购物车”。这个 Bug 在 Issue 里挂了三个月，最后是个资深工程师花了两天才修好。根因是 Redis Cluster 模式下，MGET 跨节点时返回了不完整数据，Session 反序列化的时候混入了其他用户的缓存片段。
我把代码和错误日志扔给 GPT-5.1-Codex-Max。
第一次，它说“在视图函数里加 select_related 来避免懒加载”。完全不对路。问题根本不在 ORM 查询上。这很像初级工程师的毛病——看到什么修什么，不深挖。
第二次给了堆栈跟踪，它定位到了 Session 中间件，但建议“给 Session 读写加锁”。这会导致严重的性能问题，在高并发下基本等于自杀。
第三次我把 Issue 讨论摘要给它。里面有个人提了一句：“问题只在用了 Redis 集群模式的生产环境出现，本地单机 Redis 怎么都复现不了。”
就这一句话。
模型立刻调整了方向，最终定位到 MGET 跨节点返回不完整数据的问题，给的修复方案和人类开发者最终的方案几乎一模一样：改用 pipeline 逐个获取，加了一致性校验。
这件事让我意识到一个关键点：GPT-5.1-Codex-Max 的瓶颈往往不在推理能力，在信息获取。 你给它足够多的线索，它能做出非常精准的判断。线索不够的时候，它会像初级工程师一样瞎猜，而且猜得特别自信——这反而是最危险的部分。
剩下的 31.4% 是怎么翻车的
68.6% 听起来了还行，但剩下的三成多是什么情况？
我仔细看了所有失败案例，集中在三个场景：
第一，跨服务推理的分布式 Bug。比如一个微服务报超时错误，根因在另一个服务的配置变更。模型只能看到当前服务的代码，自然无从下手。这不是能力问题，是信息边界问题。
第二，涉及领域知识的业务逻辑。比如一个财务系统的税费计算 Bug，模型不知道“巴西的 ICMS 税在圣保罗州有特殊减免规则”，它从代码逻辑上看只能说“计算是对的”。这类问题需要外部知识，而模型的知识截止日期决定了它的盲区。据我了解，Max 的知识截止是 2024 年 11 月。
第三，需要架构层面重构的 Bug。模型倾向于“最小改动原则”，这通常是好事，但有些 Bug 的本质是架构设计有问题，修修补补只会让系统更脆弱。模型目前还不具备“这个设计从根本上就有问题，应该重构”的判断力。
“AI 能修 Bug，但判断不了什么时候不该修 Bug。这个判断力，大概是人类工程师在未来很长一段时间内的护城河。”
我现在怎么用这东西
说了这么多数据，回到实际工作流。
我现在遇到 Bug 的流程是这样的：先把错误信息、相关代码片段、最近几天的 commit 记录一起扔给 Max，让它出第一轮分析。大概有一半的情况，它能直接给出正确的定位，或者至少把范围缩小到两三个文件。
省掉了很多“翻日志-猜原因-打断点”的机械劳动。
但我给自己定了条死规矩：模型给的任何修复方案，我必须完全理解之后才能合入代码库。
不是不信任它。
是我发现，当我不理解一个修复的时候，我实际上放弃了对代码的掌控权。上个月它就建议我在一个认证中间件里关掉 CSRF 校验来“修复跨域问题”——技术上确实能让测试通过，但会引入安全漏洞。模型没有恶意，它只是在优化“让测试通过”这个目标，而安全不在它的目标函数里。
这不是它的错。是我们的目标函数设计问题。
最后
GPT-5.1-Codex-Max 的自主调试能力已经跨过了一个重要的门槛：信息充分的情况下，它能独立解决大多数常见 Bug。
但“信息充分”这个前提本身就是最大的限制——真实世界的调试工作，最难的恰恰是弄清楚“我到底需要什么信息”。
如果你问我这东西值不值得用，我的回答是：值得用，但别依赖。 把它当成一个反应极快、读过海量代码但缺乏实际项目经验的初级搭档。它能帮你跑得很快，但方向还得你来把握。
大概就是这样。
留个问题给你：如果你团队接了个能自动修 70% Bug 的工具，你们会改 Code Review 流程吗？还是会对 AI 修的代码走更严格的审查？我挺好奇不同团队的做法，评论区聊聊。
标签： #AI调试 #GPT5 #开发者工具 #软件工程 #人工智能
读者评论 4