为什么同样让AI修Bug，有时一次就对，有时越修越偏？“证据完整度”才是关键

原创于 2026-08-20 15:04:25 发布 · 212 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

ChatGPT与Codex使用教程

人工智能

codex

很多开发者用 AI 修 Bug 时，都会遇到一种非常明显的反差。

有些问题，你把报错丢给 AI：

帮我看看这里为什么报错。

它很快就能找到原因，改一两处代码，问题解决。

但另外一些 Bug 明明看起来也不复杂，AI却会出现完全不同的表现：

第一轮判断错方向；
第二轮改了A文件，问题还在；
第三轮又怀疑B模块；
改动文件越来越多；
原来的Bug没解决，还产生了新的问题；
最后甚至开始重复之前已经验证失败的方案。

于是很容易产生一个疑问：

为什么同一个模型、同一个项目，修不同Bug时表现差距会这么大？

很多时候，真正决定成功率的并不是模型突然变强或变弱。

而是：

AI手里到底掌握了多少能够证明问题原因的有效证据。

可以把它理解成一个很实用的概念：

证据完整度。

一、AI修Bug并不是“看到错误就知道答案”

开发者自己修Bug，其实也不是靠猜。

真正的调试过程通常是：

看到异常
↓
收集信息
↓
提出假设
↓
验证假设
↓
排除错误方向
↓
定位根因

AI本质上也需要经历类似过程。

区别只是，它能够更快地：

阅读代码；
搜索调用关系；
分析错误信息；
对比多个文件；
生成可能原因。

但如果一开始提供的信息本身就不完整，它仍然只能：

根据有限线索推断最可能的原因。

推断不等于证明。

这就是为什么有些Bug能一次修对，而另一些会越修越偏。

二、最容易一次修对的Bug，通常“证据链很短”

比如运行代码直接报：

TypeError: Cannot read properties of undefined

同时堆栈明确指向：

user.service.ts:84

打开代码发现：

const name = user.profile.name;

而 profile 在某些情况下确实可能不存在。

这时候证据非常集中：

明确错误
+
明确行号
+
明确变量状态
+
很短调用链

AI几乎不需要进行复杂推理。

所以往往一次就能找到问题。

这种Bug的特点是：

现象离根因很近。

三、真正难修的是“现象和根因隔得很远”

比如前端页面显示：

保存失败。

表面看可能是前端表单问题。

继续查才发现：

前端提交
↓
API请求
↓
后端Controller
↓
Service
↓
数据库事务
↓
消息队列
↓
异步任务失败

最后真正原因可能是：

后台异步任务读取了旧字段。

这时候用户看到的现象和真正根因，中间已经隔了很多层。

如果只把一句：

保存失败，帮我修一下。

交给AI，它就只能从最容易看到的位置开始猜。

比如：

表单校验；

API参数；

请求格式；

异常处理。

这些方向都“有可能”。

但没有一个被真正证明。

四、报错信息越完整，AI越不需要猜

很多人给AI修Bug时只会说：

这里报错了。

或者：

项目跑不起来。

这类信息对AI帮助非常有限。

更有效的是提供：

完整报错
+
完整堆栈
+
复现步骤
+
预期结果
+
实际结果

例如：

用户第一次打开页面正常，刷新后报错。
只在登录状态下出现。
控制台完整错误如下。
API返回正常。
预期应该恢复用户信息，但页面一直加载。

这时候AI能够明显缩小搜索范围。

因为它已经知道：

不是所有请求都失败；

不是首次加载失败；

问题和刷新状态有关；

后端响应正常。

每增加一条确定信息，就相当于排除一批错误假设。

五、“能复现”本身就是非常重要的证据

有些Bug最大的问题不是复杂。

而是：

根本无法稳定复现。

例如：

偶尔白屏。

这种描述几乎无法直接定位。

如果能够进一步发现：

只有连续快速切换两个页面时才会出现。

问题立刻具体很多。

继续发现：

网络速度较慢时出现概率更高。

搜索范围又会进一步缩小。

这时候可能开始怀疑：

请求竞态；
状态覆盖；
组件卸载；
异步返回顺序。

所以调试里最有价值的步骤之一，就是把：

偶尔出现

变成：

在什么条件下一定出现。

一旦复现条件稳定，AI就拥有了验证修改是否有效的标准。

六、代码很多，不代表证据就多

这是AI调试里一个很容易出现的误区。

开发者发现AI修不对，于是把更多代码全部塞进去：

整个src目录
全部配置
全部日志
几十个相关文件

看起来上下文变大了。

但真正与Bug相关的可能只有5%。

剩下的内容反而会制造噪声。

AI需要在大量信息里判断：

哪些才是真正重要的。

所以：

上下文数量 ≠ 证据完整度。

真正有价值的是：

与当前现象直接相关的信息

而不是：

尽可能多的信息

七、一次修不对以后，最危险的是“继续猜”

典型过程是：

第一轮AI认为：

可能是缓存。

改了缓存逻辑。

问题没解决。

第二轮：

那可能是异步问题。

继续改。

还是失败。

第三轮：

可能是状态同步。

又改几个文件。

最后Diff越来越大。

真正的问题在于：

每次失败以后，并没有增加新的证据。

只是不断换假设。

这时候AI其实是在：

猜测
↓
失败
↓
换一个猜测
↓
再次失败

而不是：

假设
↓
增加日志
↓
获得证据
↓
排除假设

两种调试方式差别非常大。

八、修Bug失败后，应该先问“我们现在知道了什么”

比如第一次修改失败以后，不要马上让AI：

继续修。

更好的方式是：

刚才的方案已经验证无效。根据当前结果，哪些原因已经可以排除？下一步需要增加什么日志或测试才能继续定位？

这句话非常重要。

因为它会把AI从：

继续生成修改方案

切换到：

重新收集证据。

例如可能得到：

已经确认数据库数据正常
已经确认API返回正常
已经确认问题只发生在页面刷新后
下一步检查客户端状态恢复

问题范围已经明显缩小。

九、日志是给AI补证据最快的方法之一

假设一个函数有：

A
↓
B
↓
C
↓
D

最终D返回错误。

但现在不知道在哪一步开始出现异常。

最简单的方法不一定是继续读代码。

而是在关键节点加入：

输入是什么
输出是什么
状态是什么

例如：

A收到userId=123
B查询用户成功
C生成token为空
D验证失败

这时候几乎不用猜。

问题已经缩小到：

B到C之间。

所以当AI开始反复修改时，可以先要求：

暂时不要修代码，在关键调用节点增加最少量日志，先确认异常第一次出现在哪一步。

很多复杂Bug会因此迅速收敛。

十、测试失败也是证据，不只是“结果不好”

很多人看到测试失败，只关注：

AI没修好。

但测试失败本身其实提供了新的信息。

例如修改以后：

test A 通过
test B 失败
test C 通过

这意味着：

当前修改可能已经解决主要逻辑；

但某一个边界条件仍然存在问题。

如果AI继续把整个实现推翻重写，反而浪费了这个证据。

更好的做法是：

分析为什么只有test B失败，它和已经通过的A、C有什么输入差异？

这样测试就从：

成功/失败信号

变成：

定位问题的实验数据。

十一、环境信息经常是最容易缺失的证据

还有一种Bug特别典型：

开发者机器正常。

CI失败。

或者：

Windows正常；

Linux失败。

又或者：

开发环境正常；

生产环境异常。

如果只把代码交给AI分析，很可能永远找不到原因。

因为真正差异可能来自：

Node版本；
Python版本；
操作系统；
环境变量；
数据库版本；
时区；
文件系统大小写；
依赖安装方式。

所以只要出现：

“这里正常，那里异常”

首先应该比较的往往不是代码。

而是：

两个环境到底有什么不同。

环境差异本身就是关键证据。

十二、调用链不完整，也会让AI在错误层级修问题

例如用户权限判断错误。

真正流程是：

中间件
↓
权限Service
↓
缓存
↓
数据库

但AI只看到了Controller。

它可能直接在Controller增加：

if admin...

表面问题解决了。

但实际上把权限规则写进了错误层级。

以后其他接口仍然会出现同样问题。

所以复杂Bug最好先让AI回答：

这个现象从入口到最终数据源，完整调用链是什么？

如果完整链路都还没找到，就不应该急着改代码。

十三、可以给Bug建立一个“证据清单”

在大型项目里，可以把调试信息固定成几类。

现象证据

用户到底看到了什么？

复现证据

什么条件下稳定发生？

错误证据

日志、堆栈、错误码是什么？

代码证据

异常经过哪些函数和模块？

数据证据

输入和中间状态是什么？

环境证据

本地、测试、CI、生产有什么差异？

验证证据

怎样证明问题已经真正解决？

这些信息越完整，AI的推理空间就越小。

十四、一个很实用的AI修Bug工作流

以后遇到复杂Bug，可以不要直接说：

修复这个问题。

而是拆成几步。

第一步：描述现象

说明：

预期
实际
复现步骤
完整错误

第二步：只分析，不修改

让AI：

列出目前能够确定的事实、可能原因以及缺少的证据。

第三步：补证据

通过：

日志；

测试；

搜索引用；

运行命令；

检查数据。

验证最可能的假设。

第四步：定位根因

要求AI说明：

哪条证据能够证明这个位置就是根因？

第五步：最小修改

只修改与根因相关的位置。

第六步：重新复现

确认原Bug消失。

第七步：跑回归测试

确认没有破坏原功能。

这个流程通常比：

错误 → 直接改代码

稳定得多。

十五、什么时候应该停止让AI继续修改？

如果出现下面几个信号，就应该暂停。

Diff越来越大

最开始只是一个Bug，已经改了十几个文件。

根因一直在变化

一会儿说缓存，一会儿说数据库，一会儿又说前端状态。

没有新的实验

只是不断改代码，没有新的日志和测试。

同一个方案开始重复

已经失败的方向又被重新尝试。

出现这些情况，说明当前最缺的可能不是：

更多代码。

而是：

更多证据。

最后

为什么同样让AI修Bug，有时候一次就对，有时候却越修越偏？

真正差别往往不在于Bug看起来有多复杂。

而在于：

AI能不能从现有信息中建立一条完整的证据链。

如果它已经拥有：

明确现象；

稳定复现；

完整错误；

真实调用链；

关键数据；

环境差异；

验证方式。

那么修Bug就越来越接近：

根据事实定位问题。

反过来，如果只有一句：

这里好像有Bug。

AI就只能不断扩大猜测范围。

所以以后发现AI连续两三轮都修不对时，不一定要立刻换模型，也不要马上让它继续大面积修改。

更值得先问一句：

我们现在缺的，到底是哪一条证据？

AI调试真正的效率，不只是模型能提出多少可能原因。

而是：

它能不能快速用证据把错误原因一个个排除，直到只剩下真正的根因。

持续更新 Codex、Claude Code 与大模型开发实战内容，也会整理 AI 会员订阅与使用相关经验。更多深度内容欢迎搜索关注「孤狼GPT」。

标签

#AI编程 #Codex #Claude Code #Bug调试 #Coding Agent