登录
周一早上，你打开一个 PR。30 个文件，1200 行改动，测试全绿。
你往下滚。命名整齐，类型齐全，注释也挑不出毛病。滚到一半开始加速，滚到最后点了通过。
两周后有人问，这个模块为什么变成这样。你答不上来。当时你也没看懂，只是没找到明显的错。
这不是谁不认真。代码生产的速度换了一个量级。
10 月 28 日，GitHub 发布 Octoverse 2026：过去一年 179 亿次 push、343 亿次 commit、13 亿个合并 PR。GitHub
更关键的是，9 月每 100 个 PR 有 40 个以上初稿由 AI Agent 起草，当月发起约 1.1 亿个 PR。知乎
Sonar CEO Tariq Shaukat 引用数据：AI 编码普及后，代码行数涨 2450%，commit 涨 240%，发布频率只涨 30%。知乎
Anthropic 自报，Claude Code 约九成代码由 Claude 写，主仓库每天合入的变更从五月 2500 个涨到九月三万以上。知乎
数字得打折看，但方向清楚：写代码被压短，后面的环节浮了上来。
Sourcegraph 工程总监 Andrew Norrish 的演讲主题，就是评审成了新瓶颈。哔哩哔哩
评审为什么跟不上？因为过去那套动作，是按人的产出节奏设计的。
一个人一天写几百行，reviewer 有时间逐行看，也有时间问"这里为什么这么改"。取舍和踩坑，就在问答里传开。
现在 diff 动辄上千行。人认真看的量有上限，超过就会从逐行判断滑到模式识别——看着合理，于是放行。
AI 生成的代码又恰好很整齐。这种整齐很容易让人放松警惕。
Shaukat 还引用研究：AI 建议正确时，人 93% 赞同；AI 犯错时，五次有四次人也点头。他管这叫"认知投降"。知乎
让 AI 来审 AI 也不稳。同一段代码重复评判，模型结论有 7% 到 17% 不一致；追问"你确定吗"，7% 到 34% 会推翻自己。知乎
所以变的不仅是工具，而是评审对象。它不再只是看代码，还要看改动想干什么、对系统结构意味着什么。diff 只给第一样。
已经有团队在改流程。
Meta 不让 AI 对着 diff 提意见，而是让它现场写一个"必须失败"的测试：改动前通过，改动后报错。
跑挂了，就不是模型觉得你有问题，而是运行时摆出了事实。
Meta 公布：2026 年上半年，这套系统在提交阶段拦下 74 个严重隐私 bug，同期隐私类严重故障减少 20%。知乎知乎专栏
工程师几乎不读测试代码，只需回答：这个行为变化，是不是你本来想要的？
Anthropic 层层设卡：提 PR 前 agent 跑测试、构建和 lint，另一个 agent 审 diff，再加 CI、AI 评审和安全评审。知乎
低风险零人工批准，高风险两人；合并后分批放量，能回滚。
阿里把确定性放在前面。开源的 Open-Code-Review 先用 Go 流水线过滤、分组、匹配规则，再让 LLM 跨文件推理，最后校验注释位置。
内部跑了两年，服务数万开发者，检出数百万缺陷。知乎
三个例子的共同点：不再指望某个人或某个模型"看仔细点"，而是把评审拆成几道能验证的关卡。
对普通开发者来说，三件事值得马上做。
第一，把 PR 改小。不是切碎绕规则，而是按"能独立验证的行为"提交。一次几百行，质量就会下滑。
第二，先审意图，再审实现。PR 描述写清目标、不做什么、影响哪些接口；先看文件分布和依赖变化，再看代码。顺序反了，最贵的判断会拖到最后。
第三，用能跑的证据替"看起来对"。复现脚本、失败测试、基准数据，都比"我检查过了"有用。AI 评审可以当筛子，别当判决。
关键约束、事故教训、当初为什么没选另一个方案，不在代码里。评审时多问一句，是它们唯一能传下去的机会。
写代码变便宜之后，判断"该不该做、做到什么算对"变贵了。
瓶颈从键盘移到评审，未必是坏消息。它只是把程序员的价值，重新放回了判断力上。
