前端 PR 审查如何分配给 AI 与人

我以前会把整个 PR 粘贴到聊天模型里，问一句：“有什么问题吗？”头一个星期，这么做还挺有成就感。后来我发现，它总是漏掉同样的问题：无障碍体验退化了，却没人指出；设计 token 改来改去，单独看又似乎没问题；还有一些逻辑，只有熟悉产品的同事才能看出毛病，模型却给了“LGTM”。

于是，我把 review 拆开了。AI 负责机械检查，人类负责判断。同一个 PR，各有各的职责。

我交给 AI 的工作

给它 diff 和约束条件，别让它凭感觉判断。

• 修改过的文件，或者过滤后的 diff，跳过 lockfile 和自动生成的无关内容。
• 任务单中的验收标准。
• 团队不可妥协的要求：交互元素必须支持键盘操作；如果使用了设计 token，就不能新增硬编码颜色；移动端不能悄无声息地出现布局偏移。

然后，我会要求它做具体检查：

• 排查回归问题：这个 PR 是否破坏了已有模式，比如焦点陷阱、表单提交、空状态？
• API 接口检查：新增的 props 是否缺少类型定义，export 是否被重命名，跨 package 的 import 是否失效？
• 测试是否名副其实：测试是在验证行为，还是只断言 class 名称，或者检查一堆没有意义的 snapshot 差异？
• A11y 冒烟检查：是否缺少标签、误用 role，新增文字与背景的颜色组合是否存在对比度风险？
• 性能隐患：是否新增了 render 期间发起的客户端 fetch；团队明明已有虚拟化方案，大列表却没有采用？

我希望它返回一份检查清单，附上 file:line 定位，而不是重写整个组件。

我不会问模型：“这是一个好的产品决策吗？”它会凭空表现得很有把握。这不是它的职责。

我留给人类的工作

人类负责 review 那些模型仅凭 diff 看不出来的东西：

• 是否符合产品意图？ 任务单写的是“简化空状态”，但 PR 还顺手改了引导用户升级付费的方式，这就需要人来判断。
• 跨团队约定。 设计 token、埋点事件、feature flag，这些都应该让相应的负责人过目。
• 在约束下判断 UX 的好坏。 两种实现可能都“正确”。只有长期接触这套 UI 的同事，才知道哪一种会在下周让用户困惑。
• 风险承受度。 要在周五上线一个 token 重命名只迁移了一半的版本？这得由人决定。

我还会保留一轮人工 review，作为信任上的把关。如果 AI 说“看起来没问题”，而资深同事说“等等”，我会相信资深同事。每次都是如此。

实践中真正有效的分工

1. 作者创建 PR，附上一段简短的说明，交代“改了什么 / 为什么改 / 如何测试”，这段说明仍然由人撰写。
2. Bot 或本地脚本运行 lint、typecheck 和单元测试，完成枯燥但必要的准入检查。
3. 我或脚本把过滤后的 diff 和团队的约束清单交给 AI reviewer。
4. AI 的评论一律视为建议，并明确标注，绝不自动批准。
5. 合并前，仍然由人完成需要判断的 review。

有两条规则，让我避免了不加思考就批准：

• 绝不能让 AI 成为唯一的 reviewer。 即使是“很小”的 PR 也不行。小 PR 也会删掉重要的代码。
• 绝不要让 AI 批准 PR。 要让它找问题。是否批准，是人的决定。

prompt 大致像这样，下面是精简版：

你正在 review 一个前端 PR。只列出问题，不要用表扬凑篇幅。约束条件：[粘贴团队规则]。每个问题都要包含：严重程度（block / should‑fix / nit）、文件路径、问题为什么重要，以及用一句话给出的修改建议。忽略 linter 已经覆盖的代码风格小问题。不要重写大文件。不要编造任务单中不存在的需求。

“不要用表扬凑篇幅”这句话很重要。模型很喜欢先说一句“整体做得很棒！”，再把真正的 bug 埋在后面。

拆分职责后，发生了什么变化

机械检查变快了，产品判断反而变慢了，但这是好事。同事们不再和 Bot 争论间距偏好，而是开始彼此讨论空状态到底该不该提供深层链接。这才是我们真正需要的讨论。

AI 就像一个思维敏锐的初级工程师，对检查清单有着无限耐心。合并按钮仍然由人掌握。把这条界线划清楚，前端 PR review 就不会再像走过场。

如果你的团队已经把 AI review 和人工 review 分开了，我很想听听，有哪些事情是你们坚持不自动化的。这些坚持，往往才是团队真正的设计体系。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。