AI 改完代码怎么验证：3 条 git 命令加 1 张对照表，5 分钟跑完回归
上周五下午，我让 AI 改了一个导出接口的字段顺序。它回我「已完成修改，只动了三行」，diff 也确实只有三行。
我当时在等一个电话，扫了一眼就合了。晚上运营发消息说导出的 Excel 列全错位了，第一列变成了 id。
问题出在哪？它把字段顺序改了，但导出模板是按列号取值的。diff 上看，这次改动干净、合理、甚至还加了注释。它没错，是我没验。
那之后我给自己定了一条硬规矩：AI 说「改好了」不算交付，跑完三条命令、填完一张表才算。
一、为什么「改好了」不能当结论
AI 判断完成的标准，是它写的代码和它的解释能对上。这是文本层面的自洽，不是运行层面的正确。
我踩过的坑基本就三类：
| 类型 | 表现 | 例子 |
| 语义反了 | diff 看着更整齐，逻辑是反的 | offset = page * size 改成 (page-1)*size 但前端传参没改 |
| 夹带改动 | 顺手「优化」了没让它动的文件 | 让它改接口，它把工具函数重写了 |
| 验证跳步 | 说「已测试通过」，其实没跑 | 输出里只有它自己编的一句「测试通过」 |
这三类，靠读 diff 都能漏。所以我不读 diff 下结论，只跑命令看输出。
二、第 1 条：先看改动面有没有超预算
git diff –stat
git diff –stat | tail -n 1
第一条看清是哪些文件，第二条只看汇总行（N files changed, X insertions(+), Y deletions(-)）。
判据我按改动大小定，写在任务描述里：
| 任务类型 | 允许文件数 | 允许改动行数 |
| 改文案 / 改字段 | 1 | ≤20 |
| 改单个接口 | ≤3 | ≤80 |
| 重构 | ≤8 | ≤300 |
超了就停，不看代码。上周那个导出错位的问题，如果当时跑了这条，会看到 5 files changed——我一个「改字段顺序」的任务，它动了 5 个文件，这里面就有导出模板。
三、第 2 条：拿当前改动和基线对照跑测试
这条是核心。很多人只跑一次测试，看到绿色就过——但测试本来就是这个项目该过的，跑过说明没改坏，不说明改对了。
我的做法是先取基线，再比结果：
# 1. 当前改动先存起来（含未跟踪文件）
git stash push -u -m "ai-change"
# 2. 在基线上跑一遍，记下失败数
npm test 2>&1 | tail -n 5
# 3. 恢复改动，再跑一遍
git stash pop
npm test 2>&1 | tail -n 5
判据只有一句：两次的失败数量必须一致，且失败用例名一致。
如果基线是 2 个失败、改完还是那 2 个，说明这次改动没有引入新问题；如果变成 3 个，多的那个就是它带进来的。反过来，如果基线 2 个、改完 0 个，也要看一眼——它是不是把测试也改了。
Python 项目换一下命令就行：
pytest -q 2>&1 | tail -n 3
要求它贴最后 3 行，不要贴全量日志。全量日志里 300 行输出夹一条 warning，人是看不出来的，它自己也不会看。
四、第 3 条：确认没有夹带
git status –porcelain
git log –oneline -3
第一条列出所有被改动的文件（含未跟踪），第二条看最近三次提交。
我用它抓夹带。有一次让它修一个日期格式化的 bug，它修完还新建了 utils/date_helper.js，说是「顺手抽了个公共方法」。这个文件没进任何测试，线上第一次调用就报 undefined——因为导出路径没有引它。
判据：git status –porcelain 里的文件清单，必须和我在任务里写的「允许改动范围」逐个对上。多一个都要问一句为什么。
五、一张对照表，贴在任务最后
三条命令跑完，填这张表。不填表不算完成：
| # | 检查项 | 命令 | 通过判据 | 不通过怎么办 | |
| 1 | 改动面 | `git diff –stat \\ | tail -n 1` | 文件数、行数在预算内 | 回滚，缩小任务范围重来 |
| 2 | 回归对照 | git stash → 跑测试 → git stash pop → 跑测试 | 两次失败数、失败用例名一致 | 只修新增的失败，不动原有失败 | |
| 3 | 无夹带 | git status –porcelain | 文件清单 = 允许改动范围 | 多余的改动单独回滚 |
这张表我会直接粘进给 AI 的任务开头，让它自己跑、自己填、把原始输出贴回来。
有一个细节很重要：判据由我写，命令可以让它补。 你把判据也交给它，它会写出一条刚好等于当前实现的判据，等于自己出题自己判卷。我一般只写「两次失败数必须一致」，至于用什么命令取这个数，它比我熟。
六、跑了三周之后的变化
三周里我记了 21 个改动任务：
- 只写「改一下这个功能」的 7 个，返工 4 个；
- 写了改动范围 + 三条命令 + 对照表的 14 个，返工 2 个。
返工的那 2 个，一个是判据漏了「空数据不能报 500」，一个是预算给太宽（8 个文件），它真的动了 8 个。
所以这套东西不是让 AI 变聪明，是让我能在 5 分钟内判断它这次到底干了什么。改完不验证，等于把回归测试交给运气。
这个系列会一直写下去，下一篇记录我怎么把每次改动写成一张能查的表——出了问题能直接定位到是哪一次改的。
本文由我按实际使用记录整理，部分表述借助 AI 润色；命令与数据均来自本地仓库实测。
