工作流
让 AI 写二分检查脚本，定位第一个坏提交
缩小回归范围之前，先保证同一个提交总能得到同一结果。
资料核验2026.11.12 · Git · 已有版本历史的项目
导出文件的列顺序错了，但上周的版本正常。让助手从最近二十个提交里猜，通常会先盯上看起来最像的一个。先把问题变成可执行判断，Git 才能替你缩小范围。
让助手从这一步开始
让助手写一条只验证 CSV 表头顺序的脚本，使用固定样例和同一条生成命令。先在两个已知版本运行并核对退出码，再交给 bisect。让它给出依赖缺失时的跳过条件，区分代码回归和环境不可运行。
做出可靠的好坏判定
挑一份固定输入，把表头和预期数组比较。先在已知正常提交和当前异常提交各跑一次。确认结果稳定后，开干净工作区，使用 git bisect start，标记当前为 bad、旧提交为 good，再用检查脚本跑 git bisect run。
历史版本因为依赖缺失而无法执行时，脚本可以用退出码 125 跳过。检查脚本放在切换提交时不会消失的位置。最后记下结果，再执行 git bisect reset。
找到首个出错提交后，读它的差异并再跑一次对照。提交位置能缩小调查范围，具体原因还要看改了什么。
把问题变成可重跑的样例
把目标表头固定为 id,name,total。正常版本比较相同即退出 0，顺序不同退出 1，历史版本缺必要工具才返回 125。先在首尾两端运行检查，保存输出。中间版本不断切换时，测试样例也应在可复用的路径上。
核对这几项输出
- 已知正常版本返回成功。
- 已知异常版本能稳定失败。
- 历史版本根本无法执行时返回 125。
- 结束后记录首个坏提交并复位工作区。
怎么判断改动能不能收
如果脚本靠当下日期或网络结果判定，二分可能误判。用固定输入和干净目录验证两端后再跑，最终阅读坏提交的差异，检查它是否真的能解释失败。找到了位置仍需通过因果验证。
如果历史版本有一段因为依赖下载失败而跳过，Git 可能只能给出若干候选。让助手把跳过原因和结果一并交回，不要把它补写成精确定位。接下来可以为候选区间准备离线依赖，再针对同一输入重跑检查。
