AI 代码看似正确，隐蔽缺陷更难排查

AI 生成的代码能通过测试，也可能悄悄漏掉一页订单。dev.to 的一篇文章用分页取整错误说明：智能体产出的代码看起来合理，常规测试也全绿，业务边界却可能出错。作者把这种「近乎正确」的输出视为比明显报错更棘手的问题，因为缺陷容易通过审查，直到上线后才暴露。

目前能确认什么

节选中的分页函数用 Math.floor(total / pageSize) 计算总页数。100 条订单、每页 20 条，结果是 5，测试通过；改成 101 条，结果仍是 5，尾页便被漏掉。在这个计算场景里，应使用向上取整的 Math.ceil，得到 6 页。

测试通过，只能证明代码满足已有测试，不能证明业务边界正确。

作者引用 Stack Overflow 2025 开发者调查：在回答 AI 工具困扰问题的 31,476 人中，66% 选择了「答案几乎正确，但还差一点」，45.2% 认为调试 AI 代码更耗时。这些数字反映受访者的感受，不能直接当作 AI 代码的缺陷率。

作者还主张把改动拆小，并用可执行命令定义完成条件，例如运行类型检查和测试。

我的判断

对程序员更有用的提醒，是把审查重点从「像不像正确代码」移到「哪些输入会让它出错」。分页至少要覆盖整页、余一条和零条记录；零条时返回什么，则必须先明确业务约定。

小改动方便检查，但检查命令的价值取决于覆盖内容。若测试仍只有整除场景，反复运行也抓不到这个错误；类型检查同样无法判断这里该向上还是向下取整。

接收 AI 改动前，补一个能推翻当前实现的边界用例，比再读一遍顺眼的 diff 更有说服力。

节选没有交代开头故事是否来自真实事故，不能把它当作已核实的生产案例。Claude Code 的 Stop hook 配置也尚未展示完整，具体如何约束完成流程，仍需完整内容或官方文档确认。