这是一份专为“AI 生成代码”定制的审查清单（Checklist）。

核心差异：

传统 Code Review 侧重于“查错”和“规范”；

AI Code Review 侧重于“查真”（验证是否存在）和“查漏”（逻辑是否闭环）。AI 写出的代码一般“看起来超级完美”（语法正确、格式美丽），这导致 Reviewer 极易放松警惕，从而漏掉致命的逻辑错误。

您可以将此清单配置为 GitLab/GitHub Merge Request (MR) 的默认模板。

️♂️ AI 代码审查 (Code Review) 清单 v1.0

审查员宣言：

“我不信任 AI 生成的代码，直到我亲自验证了它的每一个逻辑分支。LGTM (Looks Good To Me) 意味着我已经看懂并验证了逻辑，而不是仅仅觉得代码格式美丽。”

第一关：安全性与合规性 (Security & Compliance)

（最高优先级，由 AI 引入的安全漏洞往往隐蔽且低级）

• [ ] 无凭证硬编码： 检查代码中是否包含 API Key、Password、Token 或内网 IP。AI 常常为了“跑通代码”而伪造或硬编码凭证。
• [ ] 无数据泄露： 检查是否将敏感数据（如 PII、用户 ID）直接打印在 Log 日志中。（AI 喜爱加详细的 console.log 或 print 方便调试，但上线前常忘记删）。
• [ ] 依赖包安全性：
• 是否存在幻觉库？ 检查 package.json / pom.xml 中引入的新包是否真实存在？（AI 常常编造名字类似但不存在，或已被废弃的库）。
• 版本是否过旧？ AI 的训练数据有滞后性，检查它是否引入了有已知漏洞的旧版本库。
• [ ] 输入校验： AI 倾向于假设输入永远完美。检查是否对 API 接口、SQL 参数进行了严格的过滤和转义（防止 SQL 注入/XSS）。

第二关：逻辑与正确性 (Logic & Correctness)

（AI 最大的陷阱：一本正经地胡说八道）

• [ ] 幻觉代码验证：
• 调用了某个库的函数时，该函数真的支持这些参数吗？（AI 常混淆不同版本的 API 签名）。
• 正则表达式（Regex）是否真的匹配预期规则？（必须将 AI 生成的正则放到 regex101 等工具中实测一遍，不要人眼看）。
• [ ] 边缘情况 (Edge Cases) 覆盖：
• 输入为 Null、Empty、Negative 或超长字符串时，代码会崩溃吗？（AI 擅长写 Happy Path，常忽略防御性编程）。
• [ ] 循环与递归边界：
• While 或 Recursion 是否有明确的终止条件？（AI 生成的复杂算法容易出现死循环）。
• [ ] 业务逻辑一致性：
• 代码逻辑是否真的符合 PRD 需求？（AI 可能由于对 Prompt 理解不深，写出了“正确的废话”或“逻辑相反”的功能）。

️ 第三关：架构与维护性 (Architecture & Maintainability)

（防止代码库腐化）

• [ ] 上下文一致性：
• AI 新写的函数是否重复造了轮子？（检查项目中是否已有类似的 Utility 工具类）。
• 命名风格是否与现有项目统一？（例如驼峰 vs 下划线）。
• [ ] 代码可读性：
• 拒绝“魔法代码”： 如果 AI 生成了一段极度精简但难以理解的一行代码（One-liner），要求提交者将其拆解或添加详细注释。
• 注释真实性： 检查注释是否与代码实际逻辑匹配？（AI 修改代码后，常常忘记更新上方的注释，导致注释误导人）。
• [ ] 过度设计 (Over-engineering)：
• AI 是否用复杂的“策略模式”去解决一个简单的 if-else 问题？（要求简化不必要的抽象）。

第四关：测试完备性 (Testing)

• [ ] 测试用例独立性： 提交的代码是否包含了对应的单元测试？
• [ ] 测试有效性：
• 测试代码是否只是为了跑通而跑通？（AI 常常写出 expect(true).toBe(true) 这种无意义的测试）。
• 必须包含失败路径（Failure Scenarios）的测试，而不仅仅是成功路径。

给 Reviewer 的“幻觉探测”提问话术

如果在 Review 时感到不确定，请直接向提交者（Human）提出以下问题，迫使他们去验证 AI 的产出：

1. “这段正则比较复杂，请提供你在测试工具中的截图或 Test Case。”
2. “这个第三方库 xyz-utils 我没见过，请确认一下它的最近更新时间和开源协议。”
3. “AI 在这里使用了递归，请解释一下最大深度的限制在哪里？”
4. “请解释一下这行代码如果传入 null 会发生什么？”

落地提议：

1. 集成到 MR Template： 把上面的 Checklist 简化版（选最重大的 5-7 条）直接做成 GitHub/GitLab 的 MR 描述模板，强想要合并代码的人必须勾选。
2. “AI 标签”制度： 要求提交者在 MR 标题或描述中明确标注 [AI-Gen]，对于带此标签的 MR，Reviewer 需自动切换到“高敏感模式”。