把"代码审查"交给 AI，是这两年最顺理成章也最微妙的一件事。像 Claude Code、Cursor 这类编程 Agent 已经能把 review 意见直接写进 PR 评论区，CI 里挂一个审查机器人也越来越常见。变化很香：半夜提交的代码有人先看一遍，人力 reviewer 从重复劳动里解脱。但真出事时，责任算谁的，一下子变得说不清。
先看事实层面。现在的 AI 审查主要做三件事：风格与明显 bug 提示、安全检查（硬编码密钥、危险函数调用）、以及对照需求描述判断"这改动是不是跑题了"。GitHub Action 里接一个审查模型，一次 PR 几秒钟出十几条评论，成本几乎为零，这是它迅速铺开的原因。
微妙的地方在归因。一个五十人左右的创业团队，上周把"AI 审查通过"设成了合并的前置条件，结果一次线上故障追下来，根因是 AI 在 review 时漏看了一个边界条件——它标了"看起来没问题"，人类 reviewer 也就没再细看。问"谁负责"，答案是尴尬的：写代码的人说"AI 通过了"，审代码的人说"AI 都看了"，最后谁都没为那次漏看担责。这种"责任稀释"正是把判断权让给模型后最该警惕的副作用。
对不同角色，含义不一样。对个人开发者，AI 审查是免费的第二双眼睛，能拦住低级错误，但别把它当免检章——它看不懂你业务里的隐含约束；对团队负责人，该想清楚的是流程怎么定：是"AI 意见仅供参考"，还是"AI 通过才能合并"，两种选法背后是截然不同的风险敞口；对企业决策者，采购这类能力时要问清"审查记录能否审计、误判能否追溯"，否则合规上会卡壳。
如果你团队正要上 AI 审查，现在能做的一件事很具体：在 PR 模板里加一行"本 PR 已人工复核关键路径"，把"人最终负责"写进制度，而不是默认甩给模型。工具可以省时间，但签那份"我看过、我负责"的，得还是人。本站收录的 Claude Code、Cursor 和 GitHub Actions 都支持接这类审查流程，接法不同，责任边界也得各自厘清。
说到底，AI 审查解决的是"看得够不够快"，解决不了"该不该信"。把速度交给它，把签字留给人，这条线划清楚了，工具才真是帮手而不是背锅侠。