AI编程生成的代码能处理一个正常样例，只说明这条路径可以运行。空输入、外部服务中断和重复请求，可能进入完全不同的分支。验收时应先确认业务需要怎样处理这些情况，再检查代码是否真正实现了相应行为。
从函数输入开始，区分缺少值、空值与合法的零。订单数量为零，可能是有效结果；字段不存在，则可能意味着数据不完整。若代码用同一个默认值覆盖两者，后续统计就会把缺失当成正常。测试应明确这些输入各自的预期结果，不能只验证程序没有抛出异常。
外部调用的错误需要保留含义。超时、权限不足和返回格式变化，对应的处理方式不同。把所有异常捕获后返回空列表，会让调用方误以为没有记录；一律重试，则可能反复请求一个永远没有权限的资源。代码应把可恢复与需要人工处理的情况区分开，并保留足够信息解释原因。
还要检查状态改变发生在什么时点。假设程序先扣减库存，再调用发货服务，后者失败时订单处于什么状态，需要业务设计给出答案。不能仅因为函数最后返回失败，就认为前面的修改没有发生。涉及多步写入时，应明确事务范围、补偿方式或待处理状态，并测试中途停止后的结果。
边界测试可以围绕业务不变量设计，而不是只照着代码分支重复写断言。例如余额不得因失败请求减少，未授权用户不能读取别人的记录，同一成功提交不能生成两次业务结果。这些要求来自任务本身，即使实现重构也仍然成立。让AI说明每个测试保护什么行为，再检查断言是否真正覆盖结果，比单纯追求测试数量更能发现看似能跑的错误实现。
重复执行也是重要分支。用户双击提交、消息被重复投递或客户端超时重发，都可能让相同业务进入两次处理。代码需要依据稳定业务标识判断是否已经完成，而不是每次生成新编号就重新执行。具体机制取决于系统，但测试必须覆盖前一次结果未知时的再次请求。
让AI补测试时，应先提供预期业务行为，而不只说提高覆盖率。可以要求正常结果、输入缺失、依赖失败和中途写入各有可检查断言。断言应检查数据是否正确、状态是否可恢复，而不是简单断言函数返回某个固定字符串。测试若只重复实现逻辑，可能与错误代码一起通过。
日志也要服务排障。保留请求标识、执行阶段和错误类型，能够让维护人员找到失败位置；密码、令牌和完整敏感资料则不应随异常打印。检查代码时可以故意触发一次失败，确认记录既能说明问题，又没有输出不必要的信息。
最后再观察调用方如何使用错误结果。底层已经区分超时与无数据，上层若又把它们统一展示为成功，业务仍然会被误导。验收应沿着真实调用链走到用户可见状态。AI代码是否合格，应由正常与失败条件下的数据行为决定，而不是由一次运行没有报错决定。