两个产品在 24 小时内相继发布。这不是巧合，这是一个信号。

如果你最近逛技术社区，可能会注意到一个奇怪的现象：几乎每个 AI 公司都在做代码审查工具。OpenAI、Anthropic、Cursor、Augment、Cognition，甚至 Linear——这个做项目管理的公司也加入了战局。

有人把这比作「硬苏打水时代」：就像 White Claw、Truly 等品牌在硬苏打水市场疯狂内卷一样，AI 代码审查工具也进入了「人手一个」的阶段。而像 Greptile、CodeRabbit、Macroscope 这样的「纯代码审查代理」，则成了这个领域的「White Claws」。

但问题是——它们真的有用吗？

信号还是噪声？开发者的真实体验

Hacker News 上的讨论一针见血：「信号与噪声比」是当前所有 AI 代码审查工具的最大痛点。

一位开发者吐槽：「我的 PR 收到了 20 个评论，其中 19 个是无关紧要的废话，只有 1 个真正重要。」这种「狼来了」效应导致开发者最终选择忽略所有 AI 评论——包括那些真正有价值的。

更荒谬的是，有用户反馈 Greptile 曾建议「静默异常」（即使异常已被处理），指出「Python 3.14 不存在」（这版本确实不存在），以及建议将「async/await 模式改为应用服务」等模糊不清的建议。

相比之下，CodeRabbit 获得了较多好评：「工作得很好，发现了许多 bug/实现问题」，且「不会像 Greptile 那样过度评论」。Claude 的用户则称赞其「能理解非平凡的变化」，曾发现过 go test -race 都没捕获的竞争条件。

但 Claude 也有问题：非确定性。每次运行发现的问题都不一样，且「倾向于过早优化」。

独立审查的「审计员悖论」

Greptile 在其博客中提出了一个核心观点：审查代理必须与编码代理分离。

他们的比喻很犀利：「审计员不准备账本，狐狸不守鸡舍，学生不批改自己的论文。」

这个观点引发了争议。有人质疑：「像 Cursor 这样的公司完全可以创建完全独立的编码和审查产品，但仍捆绑在一起分发，这算哪门子独立？」

更深层的问题是：完全独立的代码审查可能会忽略大局。外部审计员可能不理解组织目标的更大背景——某些决策对独立实体看似不合理，但在组织整体目标下却是有意义的。

自动驾驶的「监督者困境」

Greptile 还提出了一个有趣的类比：如果未来大量代码由 AI 自动生成并由同一 AI 审查批准，那人类的角色就像「自动驾驶中的监督者」——坐在驾驶座上，但什么都不做。

这听起来很荒谬，但现实中确实如此。L3 级自动驾驶要求驾驶员在系统请求时介入，但大部分时间只是「监督」。这种角色转变引发了一个问题：如果超级智能的机器在验证代码，人类只是在「盖章」，那这个盖章的意义何在？

人类工程师的「降维」与「升维」

随着 AI 代码审查的普及，工程师的角色正在发生微妙变化。

一方面，工程师从「一线执行者」转向「AI 指挥官」——核心能力从代码实现转向定义问题、拆解任务和评估结果。有公司内部工程师已几乎不直接编写代码，转而担任产品经理或架构师角色。

另一方面，工程师需要更多关注「系统设计与业务价值实现」。机器智能越发达，人类的直觉、同理心等特质越显珍贵。

闭环流程：人类、编码代理、审查代理的三角舞

Greptile 推出的 Claude Code 插件展示了他们设想的未来工作流：

人类表达意图 
    ↓
编码代理执行 
    ↓
审查代理发现问题并反馈 
    ↓
循环直至批准
    ↓
歧义时通过 Slack 联系人类

这个闭环听起来很美好，但实际落地仍有挑战。有用户指出，AI 经常在不同 PR 中给出相互矛盾的建议——一次建议使用 snake_case，另一次建议 camelCase；或者重复评论已解决的问题。

真正的痛点：AI 缺乏「系统理解」

多位开发者指出，AI 代码审查工具最大的局限是缺乏对整个系统架构、业务约束和上下文的理解。

例如：

• AI 会指出「理论上可能但实践中不可能的问题」
• 会建议「你忘了更新这个引用」，但实际上这个引用在另一个 PR 中处理了
• 会在命名、风格等小细节上过度评论，而忽略真正重要的功能问题

这些问题的根源在于：AI 工具往往限制上下文以节省 token 成本，导致模型只能基于有限信息进行推测。

未来：顾问，而非守门人

Hacker News 上一位用户的总结很精辟：「如果 AI 审查工具无法区分真正的问题与噪声，它就只是昂贵的 linter。」

另一位用户补充：「AI 审查工具应该成为『顾问，而不是守门人』，每个问题都应包含『可能出错如果…』的说明。」

这或许指明了方向：AI 代码审查不应试图取代人类，而应成为人类的「增强智能」——发现人类可能遗漏的问题，但最终决策权仍在人类手中。

毕竟，代码审查不仅仅是找 bug，更是传递知识、统一风格、确保架构一致性的过程。这些需要理解业务背景、团队文化和长期目标的工作，短期内还难以完全交给机器。