AI 说「改完了」怎么确认真改完了：git diff + 测试 + 一张验收表的 3 步复核

用 AI 改代码最省时间的时刻，往往也是风险最高的时刻：它回一句「已修复，请验证」，你扫一眼觉得差不多，就合并了。等发现不对，通常已经是第二天。这篇不讲怎么让 AI 少出错，只讲它说改完之后，我怎么做复核 。三步，每一步都有一句能直接复制的命令。## 为什么不能直接信「已修复」模型是在生成"最合理的下一段文本"，不是在保证"这段文本正确"。它说"已修复"，意思是"按我看到的线索，这段现在看起来是通的"，而不是"我替你验证过"。有几种情况最容易翻车：- 改动碰到它没读到的文件（它只看了你贴进去的那几段）- 错误被它"绕过"而不是"修好"（比如把报错整个 try 掉）- 它改了行为逻辑，但没改调用方所以复核的目标很朴素：看它到底动了什么、跑一遍、再对一遍。 ## 第 1 步：先看 diff，不看它的总结AI 的文字总结可能有水分，git diff 不会。先看改了哪些文件、增删多少行：bashgit diff --stat再逐行看一遍实际改动，这一步别跳：bashgit diff看 diff 时我重点盯三件事：有没有顺手改了不该改的文件 （配置、别人负责的模块）；有没有凭空冒出一个 try/catch 把异常吞掉 ；函数签名改了但调用处没跟着改 。这三条是我踩得最多的。## 第 2 步：跑一遍"最小可执行"的测试不必等完整 CI，先在本地跑通最小闭环：bash# 有测试就先跑测试pytest -q# 没测试，至少把被改动的入口跑一遍python main.py --dry-run跑不过就不用往下谈；跑过了也别急着合，测试覆盖不到的地方它照样能错。## 第 3 步：对照事前写好的验收表这一步最容易被省，也最该做。在派活之前 ，先把这次要满足的条件写成几条；改完之后逐条打勾，而不是改完再凭感觉说"看起来行"。| 验收项 | 判定方式 | 结果 ||---|---|---|| 原来报的错不再出现 | 复现原场景 | || 正常路径结果不变 | 跑一遍主流程 | || 边界输入不崩 | 空值 / 超长 / 特殊字符各跑一次 | || 没有新增依赖 | 看 diff 里的 import | || 没有吞异常 | 看 diff 里新增的 except / try | |验收表不用长，五条以内，关键是事前写、事后逐条 。"事前"这两个字是重点------改完再编的验收条件，多半是照着结果倒推的。## 一个具体的例子接手一个「读 CSV 出报表」的脚本，原有问题是遇到空行会崩。AI 的改法是在读取循环里加了一句 if not line.strip(): continue。按三步复核：- diff ：只动了读取循环那一处，没有顺手动别的 → 通过- 跑：主流程正常，空行场景不再崩 → 通过- 验收表 ：补测了「整个文件全是空行」的极端输入，它没处理，会返回一张空报表 → 记一条待办，这次不算修完第三条才是这次复核的价值。如果只盯着"不再崩了"，这活就算过了，实际上"全是空行"这个边界还没交代。## 验收清单（可以直接抄）- 派活前就写好了验收条件，不是事后补- 看过 git diff --stat，也逐行看过 git diff- 确认没有改到计划外的文件- 确认没有新增"吞异常"的写法- 跑了测试，或至少跑了最小可执行入口- 空值 / 超长 / 特殊字符各跑一次- 逐条对照验收表，没过的进待办AI 的长处是把它能做的部分做得很快；复核的价值是别让那部分"看起来对"直接进主干。三步加起来通常就几分钟，比事后回滚便宜太多。---作者：信可维。日常做 AI 工具实测与效率方法整理，也做软件著作权申请材料的辅助整理与格式规范。文中命令为实际使用整理，按自身环境记录，非官方口径。