AI 写的代码，到底该让谁来审

我花了两天试了一下 AI 代码审查。起因是组里一个设计系统组件 PR 堆着没人看，我顺手把 Claude Code 的 /review 接进本地流程，拿一个 Button 组件试了试。结论先放这：它能当初筛，但不能当裁判。

准备：先把「审查什么」写成规则

我是做设计系统的，对代码本身没那么熟，但对交互状态和间距很熟。所以第一步不是丢代码，而是定义审查清单：默认态、hover、focus、disabled、loading；焦点可见性；触控区域；有没有硬编码色值；文案能不能国际化；有没有破坏现有 token。

这里有个坑：规则不写清楚，AI 就会自己发挥。我一开始只说「帮我 review 这个 PR」，它给我吐了一堆「建议增加单元测试」。后来改成「只审查 UI 状态和 token 使用，不补测试，不改业务逻辑」，输出才像人话。PR 是代码合并请求，diff 是变更对比，第一次接触这两个词，可以简单理解成「要合并的改动包」。

上手：它确实会看上下文，但眼睛会飘

我把组件目录和 PR diff 一起丢进去。终端里输出按文件排列，再按状态分组评论，像一列列便签。惊喜是它会发现 disabled 态只改了背景色，没改 cursor 和 focus 环，这种问题我平时走查也常见：这个间距不对，禁用态看起来像没加载完。它还能识别 hover 效果在触屏设备上没意义，建议改成 active 或 press state。

不过一旦只看 diff，它就会漏东西。有个组件用了旧的 spacing token，我让它 review PR diff，它没发现。后来把整个组件库 token 文件也喂进去，它才指出新按钮圆角和现有系统不一致。这个体验跟设计走查很像：只看单页稿，永远发现不了全局规范被破坏。

踩坑与结论：能减负，不能终审

我这边测下来，优点主要有：

• 能把低级状态遗漏、命名不一致、硬编码色值这类问题批量扫出来，相当于一个不知疲倦的初审员。
• 对 PR 描述、变更摘要、风险点整理很顺手，能帮评审人快速建立上下文。
• 如果规则写死，它比临时口头沟通稳定。

缺点也很明显：

• 它会自信地给 AI 自己写的代码打高分。我拿它审它生成的代码，它先说「结构清晰」，再夸「状态完整」，实际漏了键盘焦点出不来的问题。
• 跨文件判断仍不稳。只审 diff 容易表面化，需要全代码库上下文，但上下文一多，它又会开始泛泛而谈。
• UI 体验不能完全靠它。一个按钮看起来「能点」，不代表用户知道现在聚焦在哪里；一个弹窗看起来「规范」，不代表键盘流不卡。

我的判断是：看情况。适合把 AI 审查接在 CI（自动跑测试和检查的流水线）前面，做第一道过滤；不适合让它直接批准合并。尤其设计系统、后台工具、复杂交互流，人类评审人仍然要看状态、看路径、看边界。

一句话总结：AI 可以让 review 变快，但 review 的边界，还是得由人来画。

---

📌 本文编译自 Hacker News，原文：https://news.ycombinator.com/item?id=49559036

版权归原作者所有，本文为基于公开报道的编译与独立分析。