评审并验收云端输出

Copilot 请求评审后，应像审查其他贡献一样检查 PR：确认改动对应任务、验证结果支持结论，并检查是否包含任务之外的修改。会话日志可以补充执行过程，不能代替代码评审。

检查交付材料

先查看 PR 的完整 diff，再打开相关会话日志确认实际运行了哪些测试和命令。提交消息中的会话链接有助于追溯某项修改的来源。

发现问题时，在 PR 评论中提及 @copilot 请求调整，或自己向该分支推送提交。多个相关问题可集中提出，见PR 协作。

独立评审要求

官方评审指南明确：当仓库要求 PR approvals 时，任务发起者对 Copilot PR 的批准不计入要求的数量，需要另一位 reviewer 批准后才能合并。不要把自己的复核或默认 Comment 类型的 Copilot 审查意见当作满足该审批要求。Copilot code review 另有可选的正式 approvals，需按专门审批配置核对实际政策与合并状态。

若 PR 以 Copilot app 身份创建且未归属于某个人，还可能适用额外审批要求，见权限与内置检查。其他仓库规则仍需以 PR 合并区域显示的检查与审批要求为准。

允许 CI 运行

默认情况下，Copilot 推送 PR 改动不会自动运行 GitHub Actions 工作流。先检查拟执行的改动，尤其是 .github/workflows/ 内的文件，再点击合并区域的 Approve and run workflows。

Actions 工作流可能拥有仓库写入权限和 secrets，因此批准工作流与批准代码合并是不同决定。仓库管理员可以配置免人工批准运行，具体见仓库设置。

代理在临时开发环境里运行的测试与 PR 工作流也是两个环节：前者完成，不意味着后者已经启动或通过。

提供产品反馈

Copilot 的 PR 和评论提供赞与踩按钮。选择负面反馈后可补充原因和说明，再提交 Submit feedback。

产品反馈用于评价结果质量；若希望代理修改代码，应另行提交明确的 @copilot 请求。满足验收与仓库要求后，再由你按正常流程合并。