如何分配人工和 AI 审查并提高检查可信度？

核心回答

人工与 AI 的审查分工，应按出错影响、业务歧义和独立验证条件决定，而不是按文件长短或 AI 自称有多确定。AI 适合先筛空值、异常分支、重复逻辑、可疑调用和测试遗漏；确定性的格式、类型和依赖问题交给工具检查。权限、资金、数据迁移、核心业务规则和架构取舍，由熟悉业务的人重点审阅。

提高可信度的关键，是让每条结论都有可回查证据：文件位置、触发条件、实际后果，以及复现或检查方法。AI 回复“没问题”只表示没有报告发现项，不证明代码没有缺陷；还要核对它看了什么，并执行与本次风险相称的独立验证。

展开说明

先把审查范围和规则给清楚

提供本次差异、需求及验收条件、相关接口约定和调用方。只给一个函数，AI 可能看不到事务边界；只给整仓库，又容易失去重点。让它先围绕变更追到输入、状态变化和消费者，再报告会影响正确性的发现。

例如退款逻辑改了时间字段，AI 可以追踪字段来源和使用位置，但“退款按发生时间还是按原订单时间归属”需要业务口径。口径明确后，模型才能辅助找不一致的实现，测试才能有独立预期。

按问题选择证据

待检查问题	主要验证方式	人工重点
格式、类型、已知危险写法	格式工具、编译器、静态分析	确认规则适用及扫描范围
边界、异常、调用契约	用例、集成检查、差异审阅	核对预期和遗漏分支
业务口径、权限、数据变化	业务样例、服务端状态及权限检查	规则解释与影响判断
页面布局与交互	真实页面操作、视口和状态检查	体验、可读性与需求符合度

低风险且有可靠自动检查的变更，可以采用自动门禁加抽查；高影响变更增加业务负责人审阅。所谓“AI 检查就够了”，应是团队接受了这些检查覆盖范围内的剩余风险，而不是模型拥有绝对正确性。

验证发现，也验证漏查风险

对 AI 报告的缺陷，回看真实调用链并复现，过滤不存在的执行路径和不可能输入；对“没有发现”，检查重要验收行为是否确实被覆盖。可以安排独立上下文的第二次审阅，减少对生成过程的附和，但多个模型仍可能共同误解同一条需求。

保留执行命令、退出码和原始输出，确认对应当前改动。检查有没有修改测试预期、关闭检查或把失败输出截掉。无需把所有小改动都升级为完整安全审计，但不能以审查篇幅替代验证。

可能的追问

除了前端和接口测试，还有什么方法？

类型检查、静态分析、数据库约束、契约测试、日志与调用链核对、变更前后状态比较，都能提供不同证据。性能变化需要相同负载下测量；资金或权限逻辑还要核业务不变量。方法按变更风险选择，不能把每种检查全部跑一遍当成默认流程。

第二个 AI 也说没问题呢？

可信度可能增加，但不是证明。更有价值的是它是否补看了独立证据、设计了能推翻原结论的反例，以及这些检查是否实际执行。

参考资料