GitHub Copilot coding agent 的代码审查环节为什么不能省

GitHub Copilot coding agent 结束任务后，交付物不是“可以直接上线的代码”，而是一个需要核对的拉取请求。它可以在自己的云端开发环境里修改文件、运行项目测试和代码检查，并把结果推到 PR；但测试只证明某些已写出的检查通过，不能替团队判断需求是否理解正确、权限是否越界，或架构取舍是否合适。

代码审查不能省的原因很简单：coding agent 负责扩大实现速度，审查负责把实现结果重新放回需求、安全和系统上下文中。两者是接力关系，不是替代关系。

coding agent 产出的是待审查的拉取请求

官方流程是：给 Copilot 分配 issue，agent 在隔离环境中处理任务，完成后打开拉取请求并把用户加为审查者。此时最有价值的动作不是立刻点合并，而是先看变更范围：它改了哪些文件，是否顺手调整了依赖，测试是否覆盖了题目中的验收条件，提交说明是否与实际 diff 一致。

这也是代码代理和普通代码补全的区别。代理可以跨文件工作，甚至调用验证工具；范围越大，越需要有人把“它做了什么”与“我们允许它做什么”对照一次。

测试通过，仍可能留下四类问题

GitHub 的负责任使用文档明确提醒，agent 生成的代码可能在语义、正确性或安全性上出问题，代码审查也可能漏报或误报。因此，CI 的绿色状态应当被看作证据之一，而不是合并许可。

尤其要注意代理可能“完成了题目文字”，却没有完成产品语义。例如把“只允许项目成员读取”实现成了“登录用户都能读取”，单元测试仍可能全部通过，因为测试数据没有覆盖另一类账号。这种判断必须回到权限模型和验收条件。

把审查前移到 draft PR，合并前再做一次人审

GitHub 推荐在 draft pull request 阶段请求 Copilot code review：先处理高置信度的正确性、安全性和可维护性问题，再推送修复，确认主要评论已解决，最后把 PR 标记为 ready for review。这样人工 reviewer 可以把时间留给设计取舍、产品影响和跨服务行为，而不是重复指出明显问题。

1. 打开 draft PR，先核对 issue、验收条件与 diff 是否对齐。
2. 在 Reviewers 中请求 Copilot；把评论分成“需要修复”“需要澄清”和“可接受取舍”。
3. 优先处理高置信度的正确性、安全性问题，修复后重新推送并看 CI 和评论变化。
4. 由人工 reviewer 检查权限、数据、异常路径、依赖和回滚方案，再提交最终 review。

如果一次修改跨越多个服务或包边界、改变安全或数据敏感行为，或者一次性采纳了大量建议，合并前应再次请求 re-review。审查的价值不在于多跑一次模型，而在于确认“修复旧问题”没有制造新问题。

团队应该怎样设置这条门禁

小团队可以选择自动审查所有 PR，并在 draft 阶段尽早获得反馈；变更频繁的仓库可以让新 push 触发重新审查。混合技术栈的单体仓库，则应补充路径级 instructions，把不同目录的架构边界和安全重点告诉审查者。

Copilot code review 还会消耗 AI credits；更深入的 Balanced review 适合复杂逻辑、敏感代码或跨服务变更，但成本和运行时间通常高于 Lite。是否启用自动审查、是否允许 Copilot approval 参与合并要求，都应由仓库策略和团队风险等级决定，不能因为有自动评论就取消必需的人类批准。

最小检查清单可以固定在 PR 模板中：需求是否完成、改动是否超范围、权限与数据是否安全、测试是否覆盖新分支、失败如何回滚、重大修改是否已 re-review。这个清单比一句“请 AI 看一下”更容易留下可追溯证据。

常见问题

Copilot coding agent 已经跑过测试，还需要人工看 diff 吗？

需要。测试只覆盖现有断言和执行路径，人工仍要判断需求、权限、架构和变更范围。

Copilot code review 没有发现问题，可以直接合并吗？

不建议。无评论表示本轮没有产生反馈，不等于代码不存在风险；GitHub 也把 AI review 定位为人工审查的补充。

什么情况下必须重新请求 review？

跨服务或包边界的改动、涉及安全或数据敏感行为的改动，以及批量采纳建议后的大改动，都应在合并前 re-review。

相关入口：Copilot agents 工作流程、Copilot code review 说明、拉取请求生命周期教程。