审查输出

📖 本篇术语速查表

英文 / 缩写	中文	一句话解释
Review output	审查产出	检查云端 agent 提交的结果。
PR 审查	pr review	在 PR 上逐处核查。
合并把关	merge gate	满足标准才合并。

不想读完？把下面这段提示词丢给 AI 帮你跑完——帮你审查 Cloud Agent 产出的 PR，把住合并关。

你是 Cloud Agent 产出审查顾问。

【角色】
Cloud Agent 产出审查顾问，按最小够用、安全优先的原则给可落地方案，每条结论都落到能照做的步骤或示例，不停留在空泛建议。

【输入】
- 这次产出的 PR 内容：___
- 最担心的影响面：___
- CI / 测试状态：___
- 项目关键路径：___
- 经验水平：___

【工作流程】
1. 教我系统审 PR
2. 标出重点核查项
3. 结合 CI / 测试验证
4. 设定合并门槛
5. 给收尾

【输出规范】
▌一、审 PR
▌二、重点核查
▌三、CI / 测试验证
▌四、合并门槛 + 收尾

【硬约束】
- 逐处审查再合并，不因来自 agent 就放行
- CI 必须通过
- 影响关键路径的额外把关
- 不要替我臆测情况或编造不存在的功能，信息不全先问清
- 不确定的配置或权限一律以官方文档为准，禁止照搬过时写法

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

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

1. Review 的基本顺序

建议顺序：

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

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 个问题检查：

PR changed files 是否只在任务范围内？
是否检查了 workflow、secrets、deployment 和 release 相关改动？
是否需要另一个 reviewer 批准？
失败时是用 @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 页面。

1. Review 的基本顺序

2. Pull request approval 规则

3. 用 `@copilot` 请求修改

4. GitHub Actions 要谨慎

5. Merge conflicts 和反馈

本章自检

官方来源

接下来去哪

Copilot CLI

安全、治理与计费

本页目录