前几天刷到一篇复盘文，作者来自阿里一个做 AI 代码评审的团队，里面提到一个细节：从 26 年开始，身边越来越多人跟他说同一句话——代码是 AI 写的，看不过来，不敢合。微信公众号
这不是个别团队的矫情，先看大背景。AI 编程工具的格局刚重新洗过一遍牌：半年之后,Copilot 市占从 42% 掉到 37%,Claude Code 冲到 28%,Cursor 突破 500 亿美元估值。知乎写代码这一端越跑越快，读代码那一端的问题就藏不住了。
复盘文里引了一份 Faros AI 的报告《The Acceleration Whiplash》：4,000 个团队、22,000 名开发者两年的遥测数据显示，AI 编码工具让每个开发者的任务完成度提高了 34%，代码活动激增 210%，但代价是代码重写率飙升 861%、每个 PR 引发的生产事故比率上升 242.7%、PR 平均审查时间延长 441.5%，未经审查直接合并的 PR 比例也上升了 31.3%。微信公众号一句话：AI 把写代码提速了，没把读代码提速。
知乎上有个 264 条评论的问题：现在程序员的代码大多数都是用AI生成的，后面会成为屎山代码看不懂吗？其中一个 357 赞的回答下面，有条评论被顶得很高：代码量少的时候 review 还有效果，代码量一旦超过 500 行，review 效果就直线下降，人只能看个大概，而 AI 写代码一写就是一大堆。
阿里的解法：把内部跑了两年、20k 月活的工具开源了
今年 5 月中，阿里把内部用了两年的 AI Code Review 工具开源了，项目叫 open-code-review。这几天它连续 5 天挂在 GitHub Trending 首页，star 数破了 2 万。微博8 月 20 日我们查了 GitHub 官方 API：20,968 个 star、1,509 个 fork。
简单说，这是一个跑在终端里的代码审查工具：一条命令进去，它逐个文件读取、自动关联上下文，然后给出精确到行的审查意见。
工具在阿里内部已经跑了两年，20k 月活、采纳率 30%+、误报率不到 5%，合并到基线的有效建议里近八成来自 AI。微信公众号开源两个月，100 多个正式版本、一百多位贡献者，60% 以上的 feature commit 来自外部 PR。微博
和"套个大模型"差在哪
市面上多数开源 AI 审查项目是 demo 级的：prompt 一写，模型一调，质量随缘。open-code-review 的路线不一样：不是"用了大模型"就完事，是"确定性工程×Agent协同"的混合架构，规则该硬编码的地方硬编码，只在真正需要动态决策的地方用 Agent。微博翻译一下：哪些文件必须审、哪些关联文件要打包一起审、哪条规则匹配哪个文件，这些"不能出错的环节"由工程逻辑兜底，模型只负责它真正擅长的动态判断和上下文召回。落到具体能力上，就是内置的 NPE、线程安全、XSS、SQL 注入这类常见缺陷规则，加上精确到行的评论定位。
效果敢不敢晒？官方仓库里放了一份用 200 个真实 PR 标注的 benchmark 评测集，按不同模型、不同工具对比 F1、精确率、召回率、耗时和 token 消耗，下面这张就是中文版的评测表。
还有两个对国内团队很实际的点。一是数据不出本地：只提供框架，不碰用户数据，LLM 你自己选，这点在企业场景里是硬需求。微信公众号二是便宜，按官方口径，token 消耗是"Claude Code + Skills"方案的九分之一——对每个 PR 都要跑一遍审查的团队来说，这笔账是真金白银。
先泼盆冷水：三件事它干不了
热度归热度，装之前，这三条边界得先知道。
第一，拦不住业务逻辑里的隐形 bug。前面那个知乎回答里讲了个事故：一段 AI 生成的库存扣减逻辑，事务处理漏了，review 环节也没人看出来。评论区有人说得直接：举例的这个事故，在 review 的时候没有看库存扣减的事务确实不太应该，这说明之前的 review 流程也效果一般。知乎规则能扫出通用缺陷，但"这个需求为什么这么实现"，还是得靠懂业务的人看。
第二，替不了人做决策。连 open-code-review 团队自己都翻过车：有次让 AI 自由决定怎么优化工具调用逻辑，单测过了就直接发版，结果在上 Hacker News 头条前两天引入了 bug，用户第一次用就踩坑。微博他们后来定了死规矩：AI 可以提多个方案，选哪个必须人来定，核心链路改动必须跑完评测集才能发版。
第三，救不了流程欠的债。同一篇回答下还有条高赞评论：一个需求大几百行全靠 AI 生成，真的很难 review，缺少需求实现的逻辑过程，真正的隐形 bug 很难发现。知乎PR 拆得小不小、测试有没有兜底、规范有没有写下来——这些没做好，换什么审查工具都一样。
谁值得装，怎么装
按"值不值"分三档说：
一个人写一次性脚本、demo 的：不用跟。AI 审查的价值在长期维护、多人协作的项目里，一次性代码自己扫一眼，成本反而更低。
团队协作、AI 代码占比已经很高的：值得试。建议三步走：先用 CLI 或 GitHub Actions 挂上所有 PR，让它守住第一道门；再把团队里口口相传的编码规范写进规则——知乎那条评论把这道理说透了，如果开发规范 AI 不知道的话，新手也不会知道的。知乎规范写进规则，等于顺手给新人和 AI 都立了规矩。最后，涉及钱、库存、权限的核心链路，保留人工复核，别全托管。
担心代码出内网的：它只开源框架、不碰代码，模型自己选，内置 provider 已经从 3 家扩到 14 家，连 Ollama 本地部署都在选项里。
模型接入长什么样？就是在终端里从列表选一项，DashScope、Claude、OpenAI、DeepSeek、Kimi 和本地模型都在同一个列表里。
接下来值得盯的信号
这个方向肉眼可见地热起来了。吴恩达亲授的《AI 代码审查》课程这几天已经在 B 站上线，主题很直白：如何检查 AI 写的代码到底写得好不好。哔哩哔哩同一周，JetBrains 直播了"AI 时代如何保障代码质量"，AI Engineer 大会上"代码审查已死"的议题也在开发者圈子里流传。AI 审查正在从锦上添花，变成 PR 流程里的标配。
值得继续盯两个信号：一是误报率在真实项目里长期稳不稳，官方口径是不到 5%，但社区跑上几个月之后的口碑才算数；二是会不会有更多团队公开自己的采纳率和事故率数据。等这两类数据攒够了，"AI 写码、AI 审查、人做决策"到底能不能成为默认配置，自然有答案。
最后问一句：AI 写代码的这个速度，你们团队的 review 流程还撑得住多久？
