相信 AI 的工作之前，先检查什么？

结账程序通过了测试，但消费刚好 50 美元的顾客，仍会被收取 55 美元。

这是一个人为放入错误的小型 Python 教学案例。它说明了用 AI 写代码、公式或自动化流程时容易忽略的问题：测试通过，只能说明被检查的那些情况通过了。

我的做法是，先约定什么结果才算正确，再让 AI 验证工作是否完成。检查时，既要看普通情况，也要看规则刚好发生变化的边界，以及两条规则一起生效的情况。

四笔订单，把问题摆出来

我们给这家虚构商店定了两条规则：运费 5 美元，商品原价合计满 50 美元免运费；优惠券只降低商品付款金额，不取消原本已经获得的免运费资格。其他商店可以采用不同政策，这里先把自己的规则写清楚。

同一个有错误的程序，前两笔订单通过，后两笔暴露了问题。

50 美元那笔检查的是精确边界。错误代码要求金额“大于 50”，因此刚好达到免运费门槛的顾客反而被收了运费。

60 美元那笔检查的是规则组合。八折优惠减去 12 美元，商品应付 48 美元；但原价 60 美元已经满足免运费条件。错误程序用打折后的金额重新判断，又加上了 5 美元。

修正这两处规则后，原来的四个检查全部通过。这证明这些情况得到了修复。完整商店还需要检查税费、退款、舍入和其他实际要求。

让 AI 给出你能核对的结果

你不一定要逐行读代码。把真实规则交给 AI，可以这样要求：

先不要改实现。根据这些要求，列出输入和预期结果的表格，包括普通情况、精确边界，以及多条规则同时生效的情况。解释每个预期结果，供我核对。确认后运行检查，展示实际结果，并明确保留失败项和未检查项。

中间的核对很关键。如果 AI 误解了政策，又按同一个误解编写程序和测试答案，两边可能完全一致，却一起违反了原意。关键例子需要你自己算一遍，或者请负责政策的人确认。

在表格里，边界可能是折扣到期的那一天；在自动化流程里，组合情况可能是同一个事件重复送达。真正有用的问题很具体：按照约定的规则，这个输入应该得到什么结果？

把确认过的检查留下来

这次实验的线索来自 review-layers。它在编程工作周围加入验证与审查关卡。我们通过本地适配器运行了固定版本的控制逻辑：Python 检查是真实执行的，模型回复是模拟的。检查失败会阻止该路径继续，结账代码即使通过检查，仍保留人工审查要求。

这验证了一部分控制流程，没有证明实际安装插件的可靠性、模型审查准确率，或它相对普通测试的收益。上面的结账方法，用常规测试工具同样可以做到。检查先准确表达承诺，重复执行才有意义。

下次 AI 说“完成了”，请它展示普通情况、边界情况和规则组合。先确认答案，再运行检查，最后把这些检查保留给下一次修改。这样，你能说清楚为什么相信这个结果，也知道还有哪些地方没有被验证。