直接回答：AI审查Pull Request最适合做第一轮系统化Review：先确认PR目标和变更范围，再按功能缺陷、安全、性能、可维护性、测试五类检查，所有结论必须指向具体diff。AI Review不能替代必需的CI状态检查和人工批准。[1][2]
先给AI足够的PR上下文
- PR要解决的问题或Issue；
- 设计约束、不可改的API和兼容要求；
- 完整diff，而不是只选一段；
- 测试结果和失败日志；
- 仓库自己的Review规范。
GitHub Copilot code review支持通过仓库级和路径级custom instructions定制Review关注点，因此把团队规范写进仓库，比每次临时重复提示更稳定。[1]
五类审查清单
| 维度 | 重点问题 |
|---|---|
| 缺陷 | 空值、边界、异常分支、状态不同步、并发 |
| 安全 | 输入验证、权限、密钥、注入、日志泄露 |
| 性能 | N+1、重复IO、无界循环、缓存失效、大对象复制 |
| 可维护性 | 职责、命名、重复代码、隐式副作用、复杂度 |
| 测试 | 新行为是否覆盖、旧行为是否回归、失败路径是否存在 |
让AI按“证据等级”输出
建议每条评论都包含：位置、问题、触发条件、影响、修复建议、置信度。没有明确触发路径的问题只能标为“疑似”，不能写成确定Bug。
安全Review要特别防误报
AI容易把“看起来危险”的代码一律报高危。正确做法是要求它解释数据是否真的可控、权限检查是否在上游、危险API是否有安全封装。安全问题至少要给出输入→危险点→影响的路径。
性能Review不要只凭代码形状
性能问题优先找复杂度或明显重复IO，但最终还要结合profile、查询计划或基准测试。看到循环并不自动等于性能Bug。
CI与AI Review如何配合
GitHub状态检查可反映构建、测试、代码扫描和部署等验证结果；如果分支规则要求状态检查通过，它们会成为合并条件。[2] 最稳的流程是：静态工具/测试 → AI Review → 人工Review → 合并。
可复制的Review提示词
请审查这个PR，不要直接改代码。
背景：[Issue目标]
不可破坏：[兼容/API/性能约束]
按以下顺序检查：
1. 功能缺陷与边界条件
2. 安全与权限
3. 性能
4. 可维护性
5. 测试遗漏
每条问题必须给出文件/行、触发条件、影响、修复方向和置信度。
没有证据的猜测单独列为“待验证”。参考来源
- GitHub Docs：Copilot code review（核验于 2026-08-08）
- GitHub Docs：Status checks（核验于 2026-08-08）
- GitHub Docs：Customize Copilot code review（核验于 2026-08-08）
更新记录
- 2026-08-08：核验GitHub当前AI code review与状态检查机制。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
相关文章
百度热点