用 LLM 自动化代码评审，又不惹烦团队

📋 概述

一个 LLM 评审者该在抓那些人类会略过、枯燥的东西时赢得位置——缺失的空值检查、被吞掉的错误、什么都没断言的测试——而在其他时候保持安静。它一旦在每个 PR 上发十二条评论、一半在复述 diff 已说过的内容，就成了负债。差别几乎全在于你怎么界定范围和设置门槛，而不是选哪家厂商。作者在几个仓库上跑过 LLM 评审（托管工具和自建 GitHub Action），能坚持过第二周的团队都做了同一件事：让机器人保持咨询性质、收窄它被允许评论的范围、并把每个误报当作要修复的配置 bug 而非要忍受的噪音。LLM 值得介入的只是 linter 之上的"模糊层"：看起来没问题但吞掉或误分类失败的错误处理、新代码里的 off-by-one 和边界逻辑、跑绿却没断言所宣称行为的测试、以及未参数化的查询或粘贴进配置的密钥等安全隐患。