代码90%由AI生成时代，Claude Code的Code Review体系拆解
先从一个容易被忽略的底层矛盾切入。当一个代码仓库绝大多数提交不再来自工程师逐行敲写，而是由大模型Agent批量输出，传统代码评审范式的根基就被动摇了。经典CR的隐含前提是，提交量可控，人工具备完整的上下文，人的阅读速度、思考速度可以匹配代码产出速度，人是第一道质量防线。
Code Review 只回了个 LGTM，问题怎么还在？
Code Review 最怕的结局不是争论风格，是评论区飘着「LGTM」「看着没问题」，合并后该炸的坑还在：边界没测、错误被吞、命名各写各的。批了，却没改动——和「纪要一贴就没下文」是同一类病：缺的不是态度，是可执行的评论。
半年过去，Claude Code 的 /code-review 变了多少
五月的时候我研究过Claude Code的/code-review命令，拆的是当时那个插件市场里的版本：8 个步骤、5 个并行 Sonnet、Haiku 打分 0–100、过滤掉 80 分以下、最后 gh 评论到 PR 上。半年后的今天，我把当前版本的实现又扒了一遍。
Claude Code 团队是如何进行代码审查的
Claude Code 团队约九成代码由模型编写，每日变更量从 5 月约 2500 次涨到 9 月超 3 万次，PR 数量翻倍而回滚比例反降四成。
Codex产品分析：从写代码的助手，到别人产品里的一个零件
【媒体】This week in Claude Code， Codex and Gemini CLI，AI Coding Guide，2026-11-01 见原文链接。
15.2 review bot 装一堆，大事故照样漏
一个「装了五个 review bot——大事故照样漏」的故事某中型 SaaS 团队——CTO 看到「AI code review」风很大——一口气装了五套自动化审查工具：- CodeRabbit (PR 自动 review 评论)- Greptile
Gerrit 迁移 Gitee CodeReview 实战：全量数据一条没丢
在服务汽车电子、芯片半导体、操作系统以及高端制造等行业客户的过程中，Gitee 技术团队经常被问到同一个关键关切：代码仓库用 git clone 配合 git push 很快就能搞定，但在旧 Gerrit 平台上运行多年的在途 Change、历史累积的原子评审流转记录，以及数以万
九成代码AI写，谁来审？Claude Code亮出6道关卡！
Claude Code约90%的自身代码，已经交给Claude编写。写代码的换成了AI，改动数量也跟着暴涨:6月到9月，合并进代码库的PR数量，翻了一倍多。
30次评审、几次事故后，我把Code Review缩成10条
组里新同学又问：“你有时10分钟过500行PR，有时50行看半小时，评审到底在盯什么？”答案一句话：评审不是逐行找茬，是带优先级做风险控制。新手逐行扫格式，老手先扫“出了事会不会炸、炸了能不能救、三个月后还能不能改”。