从 draft 到合并的审查流程
安排早期反馈和关键复查，将 AI 评论、测试与规则分析分别使用。
This page has not been translated into English yet. The original Chinese version is shown below.
把 Copilot 审查放进 PR 流程，能让人工评审集中于设计和业务影响。流程应明确何时请求、如何验证反馈，以及最新 diff 是否已经复查，不能只确认“出现过一条审查”。
draft 阶段先处理明确问题
- 创建 draft PR，说明目标、关键改动和验证方式。
- 手工请求 Copilot，或启用 draft 自动审查。
- 优先检查高可信的正确性、安全和明显维护问题。
- 应用适合的修改并验证，推送更新。
- 准备好后标记为可供团队审阅。
Copilot 的评论是需要核实的线索。若建议与代码实际行为不符，可不采纳并记录理由；评论少不代表已经完成测试。
何时值得重新审查
跨服务或跨包变更、敏感数据行为变化、一次接受大量建议后，适合再检查是否引入新风险。更新频繁的 PR 可用 Review new pushes 自动复查；偶尔需要时手工请求更容易控制时间和反馈量。
当前 approvals 如因新提交撤销，重新请求后仍需确认最新结果与合并要求，不能沿用旧批准。
按需增加背景
先添加简短的仓库指令与路径规则，再用 Skills 表达可重复审查步骤。只有外部 issue、incident 或内部平台上下文会影响判断时才接 MCP；只有性能或内网访问需要时才调整 runner。
标准 GitHub-hosted runner 是默认路径，更多扩展不自动保证更好结果。检查每次 session 的实际调用和上下文，而不只看配置已经存在。
用不同工具回答不同问题
| 工具或机制 | 适合提供的证据 |
|---|---|
| Copilot code review | PR 改动中的语义问题、项目惯例与潜在风险 |
| 测试、构建和人工审阅 | 实际运行结果、设计权衡和任务验收 |
| Code scanning / Copilot Autofix | 安全扫描告警与可能修复 |
| GitHub Code Quality | 基于 CodeQL 规则的可靠性、维护性与测试覆盖指标 |
Code Quality 可覆盖 PR 和默认分支，并配合 rulesets 阻止未满足规则或覆盖阈值的改动合并。它与 code review 的模型评论不同；不能仅向审查 prompt 写一句“必须修完才能合并”就获得这种强制机制。
逐步改进指令
将常见漏检改写成具体业务检查，例如订单处理的幂等性、超时与敏感日志，而不是只堆格式要求。用真实 PR 小批量验证，再删除无效或冲突规则。官方教程中的示例响应和修复不确定每次复现，采纳前仍需验证。