「全绿」这两个字，我现在看到会先问一句：是哪一层绿。
前段时间让 AI 改完一批代码。后端七层测试、前端四类测试，它交回来的报告逐层列了条数、失败数、耗时——全绿。
我没直接信，自己跑了一遍全量。三条红。
一、这条规矩本来是为了省时间
项目原先的规矩是：改一层，只跑那一层。
来历也很实在。最早每个改动都全量跑，一轮八九分钟，迭代节奏被拖得很死。后来发现绝大多数改动只碰一层，于是改成按层跑，快的几秒、慢的一分多钟。
省下来的时间是真的。代价是：跨层的那部分，再也没有被检查过。
所以问题不在于它偷懒，而在于它跑的那个范围，本来就看不见这三个坑。
二、三条红分别是什么
第一条最刺眼。 测试汇总表里有一列叫「失败数」，永远是 0。同一轮里，Django 自己打出来的是 FAILED (failures=3)。
原因是汇总表去读测试运行器返回结果上的 failures 属性，而 Django 5.2 的运行器返回的是失败条数这个整数，不是结果对象。在整数上取属性取不到，返回空列表，空列表长度是 0。
第二条：一个用例读到的任务编号是 2，而不是它自己造的 42。那个 2 是上一个用例留下的——上下文变量在退出时没有还原，出作用域以后还赖在那儿，后面不相干的代码读到了别人的东西。
第三条：某个端点支持哪些请求方法，取决于之前有没有人先请求过它。因为这份信息是第一次请求时才塞进去的，后来的用例拿到的就不一样。
三条的共同点：单独跑都绿，按顺序一起跑就红。
三、同一个坑还有别的长相
不是跑测试，而是跑用例的时候也遇到过：同一个视图上挂了两层权限判断，「这个人是不是任务成员」被问了两次。用例只把第一处打桩了，第二处照旧看到已登记，于是请求被挡在门外，返回 403。
结果是用例变绿了，缺陷还在。
规则是：打桩打在真源那一层，一次 patch 覆盖所有委派点。 判据也很简单——用例绿了，先问一句「它复现的真是那个交错吗」。
四、我们现在的做法
- 改动的层跑完，提交前必跑一次全量。分层跑是迭代时的省时手段，不是验收标准。
- 汇总脚本要断言「跑了几条」，不能只断言「失败 0」。0 条失败也可能是 0 条执行。
- 跨层的改动（权限、上下文、缓存、请求方法）单独写一条用例，不靠别人的用例顺带覆盖。
- 报告里贴原始输出，不贴自己汇总的表。
这几条写进了我们的交付流程，见技术能力与交付流程。如果你们内部也在用 AI 改代码，最容易出事的不是它写得对不对，是它验证的范围够不够。