文章目录 / 点击展开
GitHub Copilot 适合把“读懂变更、列出风险、补充测试”变成结构化流程，但不应替代评审者做最终判断。可靠做法是先限定审查范围，再要求它引用具体文件和代码证据，最后用测试验证建议。
审查前先准备上下文
不要一上来让 Copilot “审查整个仓库”。先提供本次 PR 的目标、变更文件、不可改变的行为和验证命令。大型改动应按模块分批审查。
建议准备以下信息：
- 需求或缺陷说明，以及明确的验收标准。
- PR diff、受影响的入口和数据结构。
- 项目的测试、格式化和静态检查命令。
- 安全、兼容性、性能等特殊约束。
Copilot 的官方能力和支持范围会变化，启用前可核对 GitHub Copilot 文档。涉及私有代码时，还要确认组织策略和数据使用设置。
第一步：让 Copilot 解释变更
先验证它是否理解代码，而不是直接索要修改方案。
请根据当前 diff 说明：
1. 这次变更解决什么问题；
2. 数据从哪里进入、经过哪些函数、在哪里输出；
3. 哪些现有行为可能受到影响；
4. 哪些判断仍缺少上下文。
每条结论必须引用文件名和函数名，不要猜测未展示的实现。如果解释与需求不一致，先补充上下文。模型连变更目的都没有理解时，后续风险判断通常不可靠。
第二步：按风险类别审查
把泛泛的“有什么问题”拆成四类：正确性、安全性、性能和可维护性。要求只报告有代码证据的问题，并区分“必须修复”和“建议改进”。
审查当前变更，只报告能够从代码中证明的问题。
按以下格式输出：严重程度、文件与函数、触发条件、影响、最小修复、验证方法。
优先检查：空值与边界、权限绕过、错误处理、并发状态、资源释放、查询次数和兼容性。
不要把个人风格偏好当作缺陷。对高风险发现应回到代码中复核触发路径。Copilot 可能把理论风险当成真实问题，也可能忽略框架已经提供的保护。
第三步：先补回归测试
发现缺陷后，不要立即接受大段重构。先让 Copilot提出能稳定复现问题的最小测试，再确认测试在修复前失败、修复后通过。
测试至少覆盖正常输入、边界值、异常输入和历史回归场景。生成的断言必须验证业务结果，不能只断言函数“没有抛错”。
第四步：执行小步重构
重构提示中明确“保持外部行为不变”，并限制每次只处理一个问题。适合交给 Copilot 的任务包括提取重复逻辑、缩小函数职责、补充类型约束和统一错误映射。
每一步都运行原有测试，并查看 diff 是否包含无关格式化、命名变化或依赖升级。需要大范围架构调整时，应先写迁移计划，而不是在同一个 PR 中边生成边试错。
合并前检查清单
- Copilot 的结论是否引用了具体代码位置。
- 所有高风险问题是否能用测试或复现步骤证明。
- 是否检查了权限、敏感信息和错误日志。
- 新测试是否包含有效断言，而非只追求覆盖率。
- 重构是否保持接口、数据格式和错误行为兼容。
- diff 中是否出现与目标无关的改动。
- CI、格式化、类型检查和测试是否全部通过。
常见问题
Copilot 能自动批准 PR 吗
不建议。它可以提供第二视角，但业务上下文、风险接受和发布责任仍应由人承担。高风险仓库还应要求至少一名独立评审者。
为什么要先解释变更再审查
解释阶段可以暴露上下文缺失和理解偏差。直接让模型找问题，容易得到与真实目标无关的通用建议。
重构建议很多时应该一次完成吗
不要。先处理有明确收益且能验证的改动，保持提交小、测试完整、可以单独回滚。
可以结合 Cursor 结对编程工作流 完成代码修改，再用 ChatGPT 开发工作流 做独立方案复核。