审查输出

GitHub 官方文档明确提醒：Copilot pull request 要像任何贡献一样认真 review。PR 摘要只能当导览，不能替代 diff、测试、workflow 和 reviewer 判断——把"AI 写的"当成审查通过的理由，是这一节最常见的错误。

1. Review 的基本顺序

建议顺序：

1. 看 PR 目标和 Copilot summary。
2. 看 changed files，确认没有越界文件。
3. 看 tests、linters 和 workflow 状态。
4. 特别检查 .github/workflows/ 变更。
5. 留 review comments 或 @copilot follow-up。
6. 需要时 checkout branch 人工修。
7. 满足团队规则后再合并。

flowchart TD
    PR["Copilot PR"] --> Summary["读 summary"]
    Summary --> Diff["审 changed files"]
    Diff --> Workflows["审 Actions / workflows"]
    Workflows --> Tests["测试和 lint"]
    Tests --> Decision{"可接受?"}
    Decision -->|否| Comment["@copilot 请求修改"]
    Comment --> PR
    Decision -->|人工接管| Push["checkout branch / push commits"]
    Push --> PR
    Decision -->|是| Merge["merge"]

    style Workflows fill:#fef3c7,stroke:#d97706,stroke-width:2px
    style Comment fill:#dbeafe,stroke:#2563eb,stroke-width:2px
    style Merge fill:#dcfce7,stroke:#16a34a,stroke-width:2px

2. Pull request approval 规则

官方页面说明，如果仓库要求 PR approvals，你自己批准 Copilot PR 不会计入所需 approval 数量；仍需要另一个 reviewer 批准。

这条规则很重要：Copilot 开的 PR 不应绕过团队保护分支和 review gate。

3. 用 @copilot 请求修改

可以在 PR comment 里 mention @copilot 请求修改。官方文档说明：

• 默认情况下，Copilot 会直接向当前 PR branch push commits。
• 如果你希望它创建单独 PR，要在评论里明确说明。
• Copilot 只响应对仓库有 write access 的用户评论。
• 当它开始新 session 时，评论会出现 eyes reaction，并在 PR timeline 里出现 started work event。
• 同一 PR 的后续 session 会记住之前上下文。

建议把 review comments batch 后再提交，减少来回干扰。

4. GitHub Actions 要谨慎

官方页面说明，Copilot push changes 后，GitHub Actions workflows 默认不会自动运行。原因是 workflows 可能有特权并访问 secrets。

你需要先审 PR，确认可以运行 workflow，再点击 Approve and run workflows。尤其要检查：

• .github/workflows/ 是否被修改。
• workflow 是否新增 secrets 访问。
• 是否新增 deployment、release、cloud 操作。
• 是否运行来自不可信路径的脚本。

也可以配置 cloud agent 自动运行 workflows，但商业项目默认应先人工审。

5. Merge conflicts 和反馈

官方文档说明，遇到 merge conflicts 可以用 Fix with Copilot 按钮，或用 @copilot 评论请求解决。Copilot 会分析冲突、解决并验证 build/tests/linter，然后请求你 review。

也可以用 thumbs up / thumbs down 给 Copilot PR 或 comment 反馈。反馈不是 review 结论，只是质量信号。

深读：为什么 Actions 默认不自动运行是合理的

CI/CD workflow 可能接触 secrets、部署权限和外部服务。一个 agent 修改 workflow 后直接触发，风险明显高于普通代码 diff。

所以默认先审再运行，是把自动化的速度放在安全边界之后。团队可以放开，但应该基于仓库成熟度和权限模型，而不是为了省一次点击。

本章自检

完成本章后，用这 4 个问题检查：

1. PR changed files 是否只在任务范围内？
2. 是否检查了 workflow、secrets、deployment 和 release 相关改动？
3. 是否需要另一个 reviewer 批准？
4. 失败时是用 @copilot 继续迭代，还是人工 push 修复？

通过标准：Copilot PR 的合并标准不低于人类 PR。

官方来源

• Review output from Copilot —— 官方审查输出页，覆盖 PR review、@copilot、merge conflicts、Actions 和反馈。
• Troubleshooting GitHub Copilot cloud agent —— 官方排障页，覆盖 session logs、write access 和 stuck session。
• Responsible use of GitHub Copilot cloud agent —— 官方 responsible use 页面。

接下来去哪