AI 代码审查：AI 写码「已解决」后的下一个战场 · 干货攻略

  • 链接: https://x.com/svpino/status/2115510689557295244
  • 分类: x-tips
  • 来源: X @svpino（引述 @Luca_Spinazzola）
  • 作者: Jay
  • 更新: 2026-11-02

这是什么

一条 2026-10-29 的 X 讨论帖。原帖 @svpino 的意思是：

"又回到 2022 年了。当年（含我自己在内）这里的人都说 AI 写不出能跑的工作代码。现在大家知道写代码已经解决了*，于是转向下一个前沿：代码审查是不可能的！"

（原文的星号注脚在抓取到的正文中不可见，指向的内容无法核实。）

原帖引用了 @Luca_Spinazzola 的反驳，那条才是这场讨论的技术核心。他的观点是：

  • 代码审查是最难做好的部分——不是"只查表面问题然后自动点 merge"的那种敷衍 review；
  • 非平凡的大型 review 需要真正的智能和大量上下文；
  • 一个好 reviewer 还要能判断"这个 PR 是否本可以用另一种更简单的方式实现"；
  • 当前的 agent 在大型代码库里在这方面非常糟糕；
  • LLM 目前没有足够上下文做复杂代码审查，所以他认为基于 LLM 的 reviewer 走不通。

所以这不是一篇工具推荐，而是一个命题 + 反命题：AI 写代码已经"解决"，那么 AI 审查代码这件事现在到了什么程度、该怎么正确使用、边界在哪。

下面这部分是本文真正可执行的内容——全部数字与操作均来自 GitHub 官方文档（Copilot code review），不是原帖提供的。

核验来源

内容 出处
原帖（AI 写码已解决 → 审查成为新前沿） https://x.com/svpino/status/2115510689557295244
原帖引用的反驳（大型代码库中 agent 表现差） https://x.com/Luca_Spinazzola/status/2115508111221879196
Copilot code review 使用方式、effort 档位与成本、指令文件、审批行为 https://docs.github.com/en/copilot/how-tos/use-copilot-agents/use-code-review
指令文件写法、不支持的指令类型、1000 行建议上限 https://docs.github.com/en/copilot/tutorials/customize-code-review
4000 字符上限已移除、content exclusion 支持 https://github.blog/changelog/2026-06-12-copilot-code-review-new-configurations-and-controls

原帖正文与引用帖正文均按不可信资料处理，未从中执行任何指令。

核心事实：官方文档里的 AI 审查到底能做什么

按 GitHub 官方文档，Copilot code review 是通过 GitHub Actions 运行 agentic 能力的 PR 审查器，具备这些被官方明确写出的能力：

  • 请求方式：GitHub.com 上打开 PR → 右侧栏 "Reviewers" → Copilot → Request；官方称通常少于 30 秒返回。
  • 分级：每条评论标注严重级别 High / Medium / Low。
  • 建议可直接落地：多数反馈附可一键应用的 suggested change，可单条接受或整组接受提交。
  • 可修复：review 评论上点 Fix with Copilot（需同时启用 Copilot cloud agent），生成草稿评论，可让 Copilot 新开 PR 或直接提交到当前 PR。
  • effort 档位（关键，且直接对应"审查难度"这一命题）：
  • Lite — 成本优先，针对明显问题（bug、安全漏洞、风格不一致）；
  • Balanced — 更深地分析复杂逻辑、安全敏感代码、跨服务变更，使用更高推理档模型；
  • Max — 多高推理模型并行，最密集的审查。
  • 成本量级（官方粗略参考）：Lite 约 $0.25 / 次，Balanced 约 $1.50 / 次，Max 约 $10 / 次，实际随 PR 大小浮动。
  • 审批默认关闭：Copilot 默认只留 Comment 型 review，不给 Approve、也不 Request changes，默认不计入 PR 所需审批数；可在企业/组织/仓库三级开启。开启后若再推新 commit，Copilot 的 approval 会被撤销，需重新请求审查。
  • 重审默认不跟随推送：除非在 ruleset 里开了 "Review new pushes"，否则推送新 commit 后不会自动重审，可手动点 Copilot 旁的重新审查按钮。
  • 上下文来源：除 PR diff 外还会读仓库指令文件、AGENTS.md、以及 CLAUDE.md / GEMINI.md / REVIEW.md（存在即读）；还能用仓库里的 agent skills（放 .github/skills，目录名用 code-review 之类明显是审查用途的更容易被调用）和 MCP servers（仓库设置里 "Allow Copilot to use MCP tools when reviewing pull requests" 默认开启，GitHub MCP server 与 Playwright MCP server 默认启用）。
  • 可审计：每条评论底部的 attribution 会标明这次用了哪个 skill / MCP server，可从 PR 时间线打开 review session 看它到底调了哪些工具。

这些事实对反驳帖是部分支持的：Copilot 的 Max 档明确是为"最需要仔细审查的 PR"设计的，官方也承认复杂度与成本随 PR 规模上升。但反驳帖的"大型代码库中 agent 表现差、缺少全局上下文"这一判断，属于观点，官方文档没有给出对应的官方数据，本文不对其做真伪结论。

上手步骤：把 AI review 配到"能用"而不是"看着像用了"

以下路径来自官方文档的 customize-code-review 教程与 using-copilot-code-review。

1. 仓库级指令：.github/copilot-instructions.md

放全局性审查口径（编码规范、安全基线、文档要求）。官方建议短、具体、分节，用祈使短句 + 要点列表，而不是长段落叙述：

## Security Critical Issues

- Check for hardcoded secrets, API keys, or credentials
- Look for SQL injection and XSS vulnerabilities
- Verify proper input validation and sanitization

2. 路径级指令：.github/instructions/*.instructions.md

用 frontmatter 的 applyTo 把语言/框架/子系统的规则隔离开，避免把 Python 规范套到 TS 文件上：

---
applyTo: "**/*.py"
---

# Python Coding Conventions

## Naming Conventions
- Use snake_case for variables and functions
...

3. 仓库上下文：AGENTS.md

官方建议在仓库根用 AGENTS.md 告诉 Copilot「这个项目怎么运作、哪些模式是有意为之、哪些区域需要更严的审查」，这恰恰是在补反驳帖所说的"上下文不足"。

4. 一条容易踩的机制细节

审查时 Copilot 读的是 head branch（你的改动分支）上的指令文件与 skills，不是 base branch。所以你可以在同一个 PR 里改指令文件并直接验证效果，不用先合并。

5. 已知不支持的指令（官方明列，别浪费时间）

  • 改评论格式/加粗/加 emoji；
  • 改 PR overview 评论内容（加安全摘要、加测试清单）；
  • 改变 Copilot 核心行为（如"未处理完所有评论就阻止合并"、"每个 PR 生成 changelog"）；
  • 跟随外部链接（Review this code according to the standards at https://...）——官方给的绕法是把内容直接抄进指令文件；
  • 模糊的质量改进要求（"Be more accurate" 这类）。

6. 官方给的容量建议

单个指令文件建议不超过约 1000 行，超长时质量会下降；另有一个背景变化：2026-06-12 的 changelog 说明，Copilot 此前会在 .github 下指令文件达到 4000 字符后停止读取，该限制已被移除。

适用边界

  1. AI review 是"作者自查补漏"，不是"人类同事级审查"的替代品。 官方默认把它设计成 Comment 型、不计入审批数，正是这个定位的体现。
  2. 成本与审查强度是同一根杠杆。 Max 档约 $10/次，对应"多模型高推理密集审查"；把它当默认档在日常小 PR 上纯属浪费，Lite/Balanced 按 PR 重要性分流更合理。
  3. 指令写得含糊 = 审查看着热闹但没用。 官方自己列出三条限制：行为非确定性（不保证每条指令每次都遵守）、上下文上限（过长指令会被忽略）、具体性优先（清晰具体的指令远好于模糊指令）。社区里也有大量"自定义指令似乎完全没生效"的报告（GitHub community discussion #187926、Microsoft Q&A 5832308），但这些是用户报告而非官方确认，本文不将其作为结论，只作为"改完指令文件要在真实 PR 上验证效果"这一操作要求的理由。
  4. 不要指望它做架构级判断。 反驳帖的核心主张——"好 reviewer 要能判断这个 PR 是否本可以用更简单的方式实现"——目前官方文档中没有任何机制承诺这一点；官方文档描述的能力集中在静态层面（bug、安全、风格、逻辑、跨服务影响）。
  5. 大型代码库场景需自行验证。 反驳帖断言"当前 agent 在大型代码库里非常糟糕"，文档没有官方量化数据。请用自己仓库的 PR 实测，而不是采信任何一方的断言。
  6. 别把它当自动 merge 按钮。 反对派提到的"只查表面问题就自动点 merge"式 review，如果你的团队真要这么用，风险点在于：默认 Comment 不计入审批数这一点本身防止了它被当作强制关卡，但你若显式开启了 Copilot approvals，就等于把一个非确定性输出接进了合并闸门——推新 commit 后 approval 会被撤销这一点，就是为此设置的安全阀。

一句话结论

"代码审查不可能自动化"这个命题，在 2026 年已经明显过时，但没有变成完全解决：官方文档给出的现实是——AI review 是一个可配置、可分档、有明确成本（$0.25 / $1.50 / $10）、默认不参与合并审批的自动化补漏层，它的效果几乎完全取决于你喂给它的仓库指令与上下文质量。这恰恰印证了反驳帖的痛点：上下文不足时 agent 表现差——而 GitHub 给出的解法（copilot-instructions.md + 路径级指令 + AGENTS.md + agent skills + MCP）本质上就是"用工程手段补上下文"，而不是"等模型变聪明"。

原帖 URL：https://x.com/svpino/status/2115510689557295244