AI学习专题 | 第25篇:CI亮红灯之后,把报错丢给AI让它自己改

上一篇我们把门禁立起来了：推上去，服务器自动跑一遍检查，红灯不让合主干。

然后问题就来了。

红灯亮了，日志刷了一屏，你盯着那行 FAILED test_days.py::test_same_day 发呆。自己改吧，得先读懂报错；丢给 AI 吧，又怕它瞎改一通。

今天把这件事讲透：怎么把 CI 的报错交给 AI，以及交付之后你必须把的那一道关。

AI 需要三样东西，缺一样它就开始编

很多人是这么问的：

测试挂了，帮我看下

AI 只能猜。猜你用什么框架、猜报错长什么样、猜代码在哪。猜错了就编，编出来的东西看着挺像回事，跑一遍还是红。

CI 报错交给 AI，得给全三样。

第一样，完整的报错日志，从命令那行开始整段复制。

不要只截最后一行 FAILED，真正有用的信息在上面：

    def test_same_day():>       assert inpatient_days(date(2026, 3, 1), date(2026, 3, 1)) == 1E       assert 0 == 1E        +  where 0 = inpatient_days(datetime.date(2026, 3, 1), datetime.date(2026, 3, 1))

这是我本地真跑出来的。E 开头的行是关键：assert 0 == 1 说明期望 1 天、实际算出 0 天；后面那行 where 0 = inpatient_days(...) 直接告诉你锅在这个函数里。

只给 FAILED test_days.py::test_same_day，AI 知道哪个测试挂了，不知道为什么挂。

第二样，复现命令。

就是 CI 里跑的那条，比如 python -m pytest -q。有了命令，AI 才能照着同样的动作去验证，而不是凭空想象。

第三样，出问题的那个代码文件。

哪个函数出事就把哪个文件贴给它。别把整个仓库丢过去，噪声太大，它反而抓不住重点。

三样齐了，第一次回答的准确率会高一大截。这不是玄学，是它不用猜了。

一道必须把的关：AI 会改测试刷绿灯

这才是今天真正想说的。

还是上面那个例子。住院天数，当日入院当日出院，按医院规矩算 1 天，我的代码算成了 0 天。测试挂了，我把日志丢给 AI。

它会给出两种改法，两种都能让灯变绿。

改法一，改测试：

-    assert inpatient_days(date(2026, 3, 1), date(2026, 3, 1)) == 1+    assert inpatient_days(date(2026, 3, 1), date(2026, 3, 1)) == 0

跑一下：

...                                                    [100%]3 passed in 0.01s退出码=0

绿灯，完美。

改法二，改代码：

definpatient_days(in_at, out_at):"""住院天数：出院日期减入院日期，当日入出院按 1 天计"""    days = (out_at - in_at).daysreturn days if days > 0else1

再跑：

...                                                    [100%]3 passed in 0.01s退出码=0

也是绿灯。

一模一样的绿灯，退出码都是 0。但第一种改法把"当日出院算 1 天"这条业务规则改成了"算 0 天"，真到结算的时候病人就少算一天费用。测试过了，系统是错的。

AI 为什么会这么干？因为它收到的指令是"让测试通过"，改断言是最短路径。它不知道那条断言背后是医院结算规则，它只知道数字对不上。

所以我给自己定了条死规矩，也建议你照抄：

收 AI 的修复之前，先 git diff 看一眼它动的是哪个文件。动的是测试文件，一律打回。

不是说测试永远不能改。需求变了，测试当然要跟着改。但那是你主动决定的事，不能是 AI 为了让红灯消失自己做的决定。

判断顺序就三步：

1. 跑 git diff，看改动落在 days.py 还是 test_days.py
2. 落在测试文件里，问它一句"为什么不改代码要改断言"，让它说明理由
3. 理由站不住就退回重来，明确告诉它"只许改 days.py"

改完自己再跑一遍

AI 说修好了，不算数。

它在自己的环境里跑通的，跟你的环境不一定一样。依赖版本、Python 版本、有没有那个环境变量，差一样结果就不同。

本地跑 CI 里那条一模一样的命令：

python -m pytest -q

看到 3 passed，再确认退出码是 0，这一步才算走完。两个都对上了，再推上去让服务器跑。

这一步省不得。我见过太多"AI 说好了、推上去还是红"的循环，根子就在本地根本没验证过。

可以抄的一段提问

下面是 CI 的报错日志（完整）：<整段粘贴>复现命令：python -m pytest -q相关代码：<贴 days.py 全文>请定位原因并修复。要求：1. 只允许修改 days.py，不要修改任何测试文件2. 改完说明改了哪一行、为什么3. 不要顺手重构无关代码

第三条是我后加的。不加的话，AI 特别喜欢顺手把整个函数重写一遍，加类型注解、改命名、抽公共方法。改完是能跑，但你 review 要花的力气翻好几倍，而且一旦出问题，你分不清是哪一处改动引起的。

修 bug 就修 bug，别让它顺手装修。

这套流程走下来，CI 红灯从"要我自己啃日志"变成了"AI 定位、我复核"。省掉的是读报错的时间，省不掉的是最后那一眼判断——这一步在你手上，不在它手上。

下一篇聊个更狠的用法：让 AI 自己审自己的代码，在提交之前先找一遍问题。