代码审查是团队协作里最耗时间的环节之一——一个中等规模的 PR，人工审完往往要半小时到一小时，而审查者还可能漏掉风格不一致、潜在安全风险这类细节。GitHub Copilot Code Review 把 AI 拉进了审查流程：它能在 PR 提交后自动给出反馈、指出问题，甚至生成一键修复的代码建议。下面看看怎么把它用起来，以及如何用自定义指令让它真正适配你的项目。
开启 Copilot Code Review
Copilot Code Review 目前对 GitHub Enterprise Cloud 和 Team 计划的仓库开放。开启方式很简单：
- 进入仓库 Settings → Code review 页面。
- 找到 GitHub Copilot code review 选项，勾选启用。
- 选择审查范围——可以设为对所有 PR 自动审查，也可以限定为特定分支或目录。
启用后，每次创建或更新 PR 时，Copilot 会自动跑一轮审查，结果以评论形式出现在 PR 的 diff 里。你不需要额外装插件或改 CI 配置，它直接集成在 GitHub 的 PR 界面中。
如果只想在部分场景触发，可以在 PR 描述里手动请求 Copilot 审查：在 PR 右侧面板的 Reviewers 里选择 Copilot，和选人工审查者一样操作。
用自定义指令让审查贴合项目
Copilot 默认的审查视角是通用的——它会关注常见 bug、安全问题和可读性。但每个团队有自己的规矩：命名规范、禁止使用的 API、特定的错误处理模式等。要让 Copilot "懂"你的项目，需要写一份自定义指令文件。
在仓库根目录创建 .github/copilot-instructions.md，Copilot 审查时会读取这份文件作为额外上下文。文件内容不需要复杂格式，用自然语言写清楚就行。
下面是一个实际可用的示例，针对一个 Python 后端项目：
# .github/copilot-instructions.md
## 代码风格
- 函数和变量命名使用 snake_case，类名使用 PascalCase。
- 每个公开函数必须有 docstring，格式遵循 Google Style。
- 单行不超过 120 字符，超过时优先用括号续行而非反斜杠。
## 禁止事项
- 不要使用 `eval()` 或 `exec()`，任何动态代码执行都不允许。
- 不要直接 `import os` 后用 `os.environ`，统一通过 `settings.Config` 读取环境变量。
- 不要在业务逻辑里裸抛 `Exception`，必须使用项目定义的异常类（见 `app/exceptions.py`）。
## 安全要求
- 所有数据库查询必须通过 SQLAlchemy ORM，禁止手写 SQL 字符串拼接。
- 用户输入在进入模板渲染前必须经过 bleach 清洗。
- JWT 过期时间不超过 15 分钟，刷新 token 不超过 7 天。
## 测试要求
- 每个新增的 API endpoint 必须有对应的 pytest 用例，放在 `tests/api/` 下。
- Mock 外部服务调用，不要在测试里发真实 HTTP 请求。
把这份文件提交到仓库后，Copilot 在审查 PR 时会参考这些规则。比如有人提交了一个手写 SQL 拼接的查询，Copilot 就会指出这违反了项目的安全要求，并建议改成 ORM 方式。
指令文件可以随项目演进持续更新。团队新增了规范就往里加，Copilot 的审查质量会跟着提升。
一键修复与审查交互
Copilot 的审查评论有两种形式：
- 问题指出：标出代码中的风险或不符合规范的地方，附带解释。
- 建议修复：直接给出一段替换代码，旁边有一个 Commit suggestion 按钮——点一下就能把建议代码合进 PR，不需要手动复制粘贴。
一键修复在处理风格问题和小 bug 时特别高效。比如 Copilot 发现你漏了 docstring，它会生成一段符合项目规范的 docstring，你点一下就提交了。
对于更复杂的问题，Copilot 通常只给出分析而不生成修复，这时需要人工判断怎么改。这个分界是合理的——涉及架构或业务逻辑的变更，AI 不该替你做决定。
如果你想在自己的 CI 里也调用 Copilot 的审查能力，可以用 GitHub Actions 集成。下面是一个最小化的 workflow 示例，在 PR 提交时自动请求 Copilot 审查：
# .github/workflows/copilot-review.yml
name: Request Copilot Review
on:
pull_request:
types: [opened, ready_for_review]
jobs:
copilot:
runs-on: ubuntu-latest
permissions:
pull-requests: write
steps:
- name: Request Copilot code review
uses: actions/github-script@v7
with:
script: |
// 为 PR 添加 Copilot 作为审查者
await github.rest.pulls.requestReviewers({
owner: context.repo.owner,
repo: context.repo.repo,
pull_number: context.payload.pull_request.number,
reviewers: [] // Copilot 不在 reviewers 列表里
});
// 通过评论触发 Copilot 审查（替代方案）
await github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: context.payload.pull_request.number,
body: '@copilot 请审查这个 PR，重点关注安全风险和代码风格。'
});
注意：Copilot Code Review 的 API 触发方式随 GitHub 版本更新可能变化。上面的 workflow 是一种可行的集成思路，实际部署前请确认你仓库所在 GitHub 计划支持该功能，并查阅最新的 GitHub Copilot 文档 验证触发方式。
审查边界与落地建议
Copilot Code Review 能显著减少审查者的机械劳动，但它有几个明确的边界需要记住：
- 它不是安全审计工具。Copilot 能发现明显的 SQL 注入或硬编码密钥，但不会做深度安全分析。安全关键项目仍需要专业工具（如 Snyk、CodeQL）和人工审计。
- 它不理解业务意图。Copilot 看到一段代码可能觉得"冗余"，但那段代码也许是为了兼容某个遗留接口。审查者需要补充这个判断。
- 自定义指令不是万能的。指令文件太长或太模糊，Copilot 可能忽略关键规则。保持指令精简、具体、可操作——10 条明确的禁令比 50 条笼统的建议更有效。
落地时可以按这个 checklist 推进：
- ✅ 确认仓库所在 GitHub 计划支持 Copilot Code Review。
- ✅ 在 Settings 里启用，先设为手动触发，观察几轮审查质量。
- ✅ 编写
.github/copilot-instructions.md，从最关键的 3-5 条规则开始。 - ✅ 跑了两周后，收集团队反馈：哪些审查有用，哪些是噪音。据此调整指令文件。
- ✅ 噪音率降到可接受水平后，切换为自动审查模式。
- ✅ 仍然保留人工审查作为最终关卡——Copilot 是初审，不是终审。
把 Copilot 当成一个不知疲倦的初级审查者：它帮你筛掉风格问题、明显 bug 和常见安全坑，剩下的架构和业务判断留给团队。这样分工，审查效率能提上去，质量也不会掉下来。