目录一、为什么不让 AI 直接猜范围太大上下文装不下它没有好坏标准检查必须能重复二、准备一份会回归的仓库造出那一次回归三、四条命令跑完坏提交里改了什么四、退出码才是好坏标准五、让 AI 写检查脚本时的约束六、几个容易踩的坑小结功能昨天还是好的今天坏了。git log里躺着几十个提交每个说明都像那么回事。这时候把整段 log 贴给 AI让它猜「是哪一次引入的」它会挑一个看起来最像的。看起来像和真的是那一次不是一回事。我现在的做法是先写一个能重复执行的检查好的提交退出码是 0坏的提交退出码不是 0。然后让git bisect自己去折半。提交再多检查次数也只是对数级。这篇用一份 9 次提交的示例仓库把过程走一遍。一、为什么不让 AI 直接猜范围太大上下文装不下一次回归前后往往夹着很多次无关提交改文案、补注释、调日志。把这些 diff 全贴进对话既贵也会把真正那一行淹没掉。它没有好坏标准AI 看到的是代码长什么样不是这段代码在你的输入上返回什么。没有一个固定的检查它只能按「这行改动看起来危险」来猜。猜错了后面的分析全建在错的提交上。检查必须能重复bisect 会把工作区反复切到不同的提交上每次都执行同一条命令。所以检查要满足三件事不靠人眼看输出、不改工作区、同一次提交上反复跑结果一样。偶发才失败的问题不适合拿来 bisect那种情况先把复现条件固定下来。二、准备一份会回归的仓库示例是一个折扣函数。金额大于等于 100 时打九折否则原价。defprice(amount):ifamount100:returnint(amount*0.9)returnamountprice(100)应该得到 90。检查脚本只做这一件事退出码交给 bisect#!/bin/shpython3-cimport price; assert price.price(100) 90断言失败时Python 的退出码是 1。这正是 bisect 眼里的「坏提交」。造出那一次回归在一个空目录里建仓库先提交好的版本中间夹几次无关提交再把改成后面再补几次无关提交。需要本机已经能正常git commit。gitinit-bmaincatprice.pyEOF def price(amount): if amount 100: return int(amount * 0.9) return amount EOFcatcheck.shEOF #!/bin/sh python3 -c import price; assert price.price(100) 90 EOFchmodx check.shgitaddprice.py check.shgitcommit-madd price rule: 100 and above gets 10 percent offforiin1234;doechonote$inotes.txtgitaddnotes.txtgitcommit-mrecord note$idonepython3-cfrom pathlib import Path; p Path(price.py); p.write_text(p.read_text().replace(amount 100, amount 100))gitaddprice.pygitcommit-mtighten discount boundaryforiin567;doechonote$inotes.txtgitaddnotes.txtgitcommit-mrecord note$idone这样一共 9 次提交。最后一次上./check.sh会因为AssertionError失败。边界从「大于等于 100」变成了「大于 100」金额正好是 100 时不再打折。这段检查脚本我是在 WES Code 里写的写完在终端里执行git bisect run。三、四条命令跑完当前提交是坏的最初那次提交是好的。把这两头标上再把检查脚本交给 bisectgitbisect startgitbisect badgitbisect good$(gitrev-list --max-parents0HEAD)gitbisect run ./check.shgit rev-list --max-parents0 HEAD取的是仓库里最早的那次提交也就是还没改坏的版本。已经知道某个标签或某次发布是好的就把最后一行里的命令换成那个提交。bisect 每次切到一个提交就执行./check.sh。我这次它检查了 3 次次序抽到的提交说明检查结果1record note 4通过记为好2record note 5断言失败记为坏3tighten discount boundary断言失败判定为第一处坏提交最后一行结论是tighten discount boundary is the first bad commit。这次提交只动了price.py1 行新增、1 行删除。坏提交里改了什么- if amount 100: if amount 100:9 次提交里无关的 note 占了 7 次。bisect 没有在那些提交上停留直接落到了改边界的这一次。查完记得退出否则工作区会停在 detach 的状态gitbisect reset找到这次提交后我会在 WES Code 里把price.py的这次 diff 和check.sh放进同一个对话对照着看边界条件是怎么被改掉的。四、退出码才是好坏标准bisect 不看脚本打印了什么只看退出码。下面是我这台机器上git help bisect写的规则git 2.49.0退出码bisect 怎么处理0当前提交是好的1 到 127除去 125当前提交是坏的125当前提交没法测跳过其他中止整个 bisect我这次断言失败的退出码是 1落在「坏」那一档所以被记成坏提交。125 是留给「这次编译不过、测不了」的。帮助里的写法是编译失败就跳过编译成功再跑检查gitbisect runsh-cmake || exit 125; ./check.sh这里有个容易反的点。帮助里专门写了126 和 127 是 shell 用来表示「命令不可执行」和「命令没找到」的。脚本忘了chmod xshell 返回的是这类退出码bisect 会把当前提交当成坏的而不是跳过。脚本本身跑不起来时结论就不可信了。五、让 AI 写检查脚本时的约束检查脚本适合交给 AI 起草因为好坏标准是人定的脚本只是把标准写成退出码。我用的约束是仓库里有一次回归。请写一个检查脚本 check.sh要求 1. 用下面这条业务规则做判断price(100) 必须等于 90等于就退出 0否则退出 1 2. 不要修改被测代码不要 git commit 3. 同一次提交上反复执行结果必须一样 4. 依赖没装好或编译失败时退出 125不要退出 1 5. 写完先在当前提交上跑一遍把退出码告诉我第 1 条必须人来写。不写清楚「什么叫坏」它就会按自己的理解挑一个断言bisect 找出来的提交也就跟着偏了。六、几个容易踩的坑工作区不干净。有未提交的改动时bisect 可能拒绝切换或者把你的改动和历史提交混在一起。开始前先看git status。老提交缺文件。检查脚本如果调用了某次提交之后才加进来的命令或文件老提交上会直接失败然后被记成坏的。失败原因要看一下是业务断言失败还是「文件不存在」。后者应该用 125 跳过。偶发失败。数据竞争、依赖网络的测试同一次提交上这次过、下次不过。bisect 会把同一次提交一会儿当好、一会儿当坏最后给出的「第一处坏提交」没有意义。中途手改代码。bisect 进行到一半时不要在那个提交上改文件再提交。范围会被你自己的新提交搅乱。查完不 reset。忘了git bisect reset的话后面的提交会进到一条不属于任何分支的历史上。小结回归前后提交很多时不要让 AI 对着git log猜是哪一次先写一个只看退出码的检查好是 0坏是 1测不了是 125git bisect bad、git bisect good、git bisect run三条就能把范围缩到一次提交找到那一次之后再把 diff 交给 AI 看为什么错而不是反过来文中的二分定位是我在 WES Code 里做的官网是 weisyn.com。你们排查回归时习惯用 bisect还是对着 git log 一条条看欢迎评论区聊聊。觉得有用的朋友欢迎点赞、收藏、关注后面会继续分享 AI 编程的实战经验。