---
title: "审查输出"
description: "说明如何审查 Copilot cloud agent 的 pull request、diff、Actions、merge conflicts 和 follow-up comments。"
verifiedAt: "2026-05-06"
---

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

> [!TIP]
> **阅读目标**：读完本章，你应该能审查 cloud agent 生成的 PR，并知道何时用 `@copilot` 请求修改、何时人工接管。

## 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. 满足团队规则后再合并。

```mermaid
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 结论，只是质量信号。

<details>
<summary>深读：为什么 Actions 默认不自动运行是合理的</summary>

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

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

## 本章自检

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

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

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

## 官方来源

- [Review output from Copilot](https://docs.github.com/en/copilot/how-tos/copilot-on-github/use-copilot-agents/review-copilot-output) —— 官方审查输出页，覆盖 PR review、`@copilot`、merge conflicts、Actions 和反馈。
- [Troubleshooting GitHub Copilot cloud agent](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/troubleshoot-cloud-agent) —— 官方排障页，覆盖 session logs、write access 和 stuck session。
- [Responsible use of GitHub Copilot cloud agent](https://docs.github.com/en/copilot/responsible-use/copilot-cloud-agent) —— 官方 responsible use 页面。

## 接下来去哪

<Cards>
  <Card title="Copilot CLI" description="如果要把 cloud session 带回本地，继续学习 Copilot CLI。" href="/docs/github-copilot/official/05-copilot-cli" />
  <Card title="安全、治理与计费" description="继续学习 access policies、usage、billing 和 content exclusion。" href="/docs/github-copilot/official/08-security-governance" />
</Cards>
