用 AI 编程之后，写代码这件事不再是瓶颈了，那问题来了：AI 产出了大量的代码，该怎么 Code Review 呢？
刚好，最近看到 Claude Code 团队发了一篇博客叫《Solving Code Review at Anthropic》，讲的就是他们内部怎么审 AI 写的代码。
先说两个数字。Claude Code 自己大约 90% 的代码是 Claude 写的，从今年 6 月到 9 月，Claude Code 代码库合入的 PR 数量翻了一倍多，需要回滚的比例反而降了 40% 多。
他们并没有取消 Review。相反，他们把大部分“读代码”的体力活交给 AI，人的时间只花在 AI 搞不定的地方。同时，他们花大力气确保出错之后能快速撤回。
这篇文章我就带大家一层层拆开这套流程，看看哪些做法是普通团队也能直接抄作业的。
一、AI 写得越快，Review 为什么越跟不上？
Anthropic 的 monorepo（所有项目放在一个大仓库里），今年 5 月每天合入的改动大约是 2500 个，到了 9 月，每天超过 3 万个。Claude Code 有自己独立的仓库，压力一样不小。
改动量四个月涨了十几倍，人读代码的速度可一点没变。Claude Code 团队自己说得也很直白：按这个速度发版，逐行人工 Review 非常困难，甚至可以说不可能。
面对这个缺口，大部分团队的第一反应是硬扛。
硬扛有两种扛法。第一种是加人加时间，让资深工程师多花时间审 PR，结果就是这些人手上正专心写着代码，隔一会就被拉出来，去帮别人挑一些低级错误。他们专门算过这笔账：为了抓一个常规错误打断一个资深工程师，成本远比跑一次自动 Review 高得多。
第二种是放水。PR 太多看不过来，干脆扫一眼就直接点通过。这种情况有多普遍？在 Claude Code 的 Code Review 功能开放内测之前，Anthropic 内部只有 16% 的 PR 能收到真正指出问题的评论，剩下的大多数，说白了就是被扫了一眼。
加人扛不住，放水又兜不住。Claude Code 团队的做法是先退一步，重新想清楚 Review 到底是干什么的。
二、Code Review 到底在防什么？
Claude Code 团队先把 Code Review 的作用拆成了两件事。
第一件是在代码上线前，把问题找出来、修掉。第二件是让团队对代码库有共同的理解——你读同事的 diff，就知道系统哪里改了、各个模块怎么拼在一起。
这篇文章主要讲第一件事，第二件我们放到后面再说。
那“找问题”这件事，靠什么来保证呢？
很多人的答案是：靠“有人读过这段代码”。但 Claude Code 团队觉得，这个标准太粗糙了。
打个比方，你去做体检，真正关心的是该查的项目有没有查到，至于医生有没有亲手把你从头摸到脚，其实没那么重要。血常规交给仪器，影像交给机器，医生的精力留给看报告和做判断。
代码也是一样的道理。所以他们把问题换了个问法：“这个改动可能出什么错，该由哪一道检查来拦住它？是自动检查，还是人？”
问题一换，Review 发生的时间也跟着变了。
以前的 Review 是终点的一道关卡：写完代码、提 PR、等同事来审。现在的 Review 是一直在跑的，更像打字时的拼写检查，边写边查。
大部分改动在人看到之前，已经被 Claude 审过、修过至少一轮了，常规错误基本在这一步就被消化掉了。
既然 Review 不等于“人读代码”，那衡量 Review 做得好不好，看什么呢？
Claude Code 团队给出的答案是：人的时间。人的时间是整套流程里最稀缺的东西，要省着用。
这里有个细节很关键。人的时间包括两部分：一部分是审代码花的时间，另一部分是烂代码上线后修 bug、处理事故花的时间。你如果只砍掉第一部分，第二部分跟着涨起来，那全是白忙活。
所以他们定的目标是：Claude Code 的大部分 PR（覆盖 CLI、桌面端、Web 端和移动端），最多只需要一个人参与就能合入，这个人甚至可以是作者自己。同时，回滚和事故不能变多。
具体盯三个指标：每个 PR 要几个人批准、人写了多少条评论、PR 卡在那里等人处理了多久。批准次数这一项，既看一般的 PR，也看最慢的那 5% 的 PR。回滚率和事故率作为护栏，用他们的话说：“如果它们涨了，我们并没有省下人的时间，只是把时间挪了个地方。”
目标定下来了，接下来就是怎么做到。
三、人看之前，AI 已经拦了几道？
我们先跟着一个改动走一遍全程。一个改动从工程师的电脑（或者 Slack 里的一个 Claude 会话）出发，要经过这几个阶段。
提 PR 之前，AI 自己先把代码跑一遍验证。提 PR 时，跑必须通过的 CI（自动构建、自动跑测试的流水线），再加上 Claude 代码审查和安全审查，然后根据风险决定要不要人批。合并时要排队重新检查；合并后先用功能开关只给内部员工打开，再一步步放给更多用户，最后盯着线上，有问题就马上补一个修复，或者直接回滚。
你会发现，这条路上大部分环节都是自动的，人只出现在风险最高的那一环。
看到这估计有同学就问了：层数这么多，是不是有点过度设计？Claude Code 团队用了一个很形象的模型来解释。每一层检查都像一片带孔的奶酪，能拦住一部分问题，也会漏掉一部分，但每片奶酪的孔位置不一样。几片叠在一起，一个问题想穿过所有孔的概率就很低了。就算真穿过去了，最底下还有快速回滚兜着。
写完之后，凭什么相信 AI 说的「搞定了」？
用过 AI 写代码的同学应该都遇到过：Claude 说“已经完成了”，你一跑，报错。
所以第一层的做法很简单：别信 AI 嘴上说的，看代码真跑出来的结果。具体来说，给 Claude 一个能自己跑的东西，比如测试、构建，或者一张拿来对照的设计稿截图，然后要求 Claude 把运行结果拿出来，光说一句“做完了”不算数。接着再开一个上下文干净的子 agent，专门审一遍这次的 diff。
对了，为什么要另开一个干净的上下文？因为写代码的那个会话里，塞满了 Claude 自己的思路和假设。让同一个会话自己审自己，很容易顺着原来的思路一路点头。换一个没有包袱的 agent 来看，更容易发现问题。
除此之外，团队里很多人在提 PR 前还会跑几个内部 skill，一个专门找 bug，一个负责精简 diff，一个把功能从头到尾真实操作一遍，UI 改动还要对照设计规范查一遍。
Claude Code 的作者 Boris Cherny 说过，给 Claude 一个验证自己工作的手段，可能是拿到好结果最重要的一件事。他估计这套方法能让最终效果好两到三倍。
这一层还有个很聪明的做法。当自动 Reviewer 反复指出同一类问题时，团队不会每次都手动去改，而是回到源头一次解决：写进 skill、加一条 lint 规则，或者更新说明文件。
说明文件主要有两个。CLAUDE.md 告诉 Claude 这个项目是什么、技术栈、约定、目标，还有明确不做的事。每次 Review 都会加载它，所以在大型代码库里要写得短，其他内容放在别的文档里，从 CLAUDE.md 指过去就行。Reviewer 也会拿它当标准，代码违反了里面的约定、或者改动让里面某一行过时了，都会被指出来。REVIEW.md 是代码负责人写的，告诉 Reviewer 在这块代码里什么最重要。
什么样的 REVIEW.md 算写得好？好的 REVIEW.md 都很短，会写清楚在这个仓库里“出错”长什么样。比如文档仓库的出错是“写的内容是假的”，配置仓库的出错是“把请求转发到了错的地方”。这份文件还会限制 Nit（鸡毛蒜皮的小意见）的数量，列出哪些目录可以不用审，要求 Reviewer 给出具体的文件和行号作为证据，不准光看一个变量名就瞎猜。另外，REVIEW.md 还要求总结的第一句先报数量，没问题的时候就直说“没有要修的”，别硬凑意见。
团队还会单独检查 Reviewer 到底有没有遵守 REVIEW.md。写了不执行，等于白写。
光看这几条描述，可能还是不知道具体怎么下笔。Code Review 的官方文档里正好给了一份示例，是给一个后端服务写的 REVIEW.md，我翻译成中文放在这里。
# 审查说明
## 在这个仓库里，什么算 Important
只有会搞坏功能、泄露数据或者导致没法回滚的问题，才标 Important。
比如逻辑错误、没有限定范围的数据库查询、日志或报错信息里带了个人隐私数据、
不向后兼容的数据库迁移。代码风格、命名、重构建议，最多算 Nit。
## 限制 Nit 数量
每次审查最多报 5 条 Nit。
## 不要报
- CI 已经在管的东西，比如 lint、格式、类型错误
- src/gen/ 下自动生成的文件，以及所有 *.lock 文件
- 故意不按生产规则写的纯测试代码
## 每次必查
- 新增的 API 接口，必须有集成测试
- 日志里不能出现邮箱、用户 ID 或者请求体
- 数据库查询必须限定在调用方所属的租户范围内
你会发现，这份示例和前面说的几条要点基本对得上。先重新定义什么算严重问题，再给 Nit 设上限，然后列出不用管的东西，最后补上这个团队自己最在意的规则。
对了，前面说的“要给文件和行号做证据”，官方文档也给了一句现成的写法：“关于代码行为的判断，必须引用源码里的文件名和行号，不能只靠命名去推断”。这一句加进 REVIEW.md，能少掉不少让作者白跑一趟的误报。
AI 审查怎么做到不吵人？
过了 AI 自己验证这一层，PR 提上去，每一个 PR 都会先被 Claude 审一遍，然后才轮到人。
这次 Claude 审的范围就大了。Claude 拿这次的 diff 对照整个仓库，再对照 PR 里写明的意图，回答几个问题：这个改动解决了要解决的问题吗？和现有代码合得来吗？会不会把别的地方搞坏？如果是修 bug 的 PR，Claude 还会去找根本原因。
这个能力对外的版本，就是 Claude Code 的 Code Review 功能，现在 Team 和 Enterprise 套餐都能用，本地跑 /code-review 可以用一个轻量版。值得一提的是，对于个人开发者或小团队，RouteFast.ai 这类 API 中转服务也提供了低成本体验 Claude API 的途径。
效果怎么样呢？内测上线后，Anthropic 内部被指出真问题的 PR 占比，从 16% 涨到了 54%。超过 1000 行的 PR 大多能被找出问题，小 PR 大多数是干净通过的。
管理员还可以给每个仓库设置审查深度，分 Quick、Standard、Deep 三档。Deep 适合那种“漏一个 bug 的代价，比多花点审查时间贵得多”的地方。
说到 AI 审代码，大家最头疼的其实是另一件事：太吵。一个 PR 下面挂了二十条评论，十五条是“建议把变量名改得更清晰”。真问题被淹没在一堆废话里，看两次之后大家就直接无视了。
Claude Code 团队的解法是，评论发出来之前先验一遍。多个 agent 同时去找 bug，找出来的每一条，再交给另一组 agent 投票。足够多的 agent 都认为是真问题，才会发出来。只涉及代码风格、编译警告这类提示，或者顺手清理代码的意见，直接丢掉。这些过滤规则也不是拍脑袋定的，团队先在自己的 PR 上做了 A/B 测试，效果好才留下来。
留下来的问题直接挂在对应的代码行上，按严重程度排序，每条打一个标签：Important（重要）、Nit（小问题）或者 Pre-existing（原来就有的）。这个 Pre-existing 标签我觉得特别贴心。代码库里早就存在的 bug，被这次 Review 顺带扫出来了，打上这个标签，就不会让人误以为是这次提交的作者写出来的。
最后一条规矩是：每一条评论都必须回应。要么修掉，要么写个理由把讨论关掉。很多时候，作者下班后会有一个 agent 连夜把修复做掉，第二天一早回来，PR 已经又过了一轮。
哪些检查有一票否决权？
前面说的 AI 审查给的是意见，这一层的检查是能直接拦住合并的。
首先，安全有一套单独的自动审查。只要 bug 审查或者安全审查里还有没处理的问题，PR 就合不进去。处理方式还是那两种：修掉，或者写一句简短的理由关掉，误报就是这样清掉的。如果后面的某次提交把问题修好了，这条问题会自动消失，不用人去手动关。想在自己团队里搭这套，可以用开源的安全审查 GitHub Action，或者 /security-review 命令。
然后是常规的自动检查：lint、类型检查、全平台测试、构建。一个普通的 CLI PR，在有人看之前可能已经跑了几十项检查。
PR 模板里还有两个必答题：“这个改动是怎么测试的”和“出了问题怎么撤回”。Claude 可以帮你填，但提出这个改动的人得签字确认。说实话，这两个问题看着简单，很多团队的 PR 描述里都没有。尤其是“怎么撤回”，提前写好，出事时照着做就行，不用等线上着火了再现场想。
四、哪些代码还需要人来批？
AI 拦完一轮，终于轮到人了。但也不是每个 PR 都要人来批。改一个文档错别字，和改自动更新器的逻辑，风险差了十万八千里，审查力度当然也应该不一样。
Claude Code 团队把改动分成了三个风险等级。
| 风险等级 |
典型改动 |
需要几个人批准 |
| 低 |
文档、文案、内部功能、默认关着开关的纯新增功能 |
不需要人，自动审查和安全检查全绿就行 |
| 中 |
普通的产品改动，以及缓存、自动更新器、系统提示词这类敏感区域 |
一个人 |
| 高 |
风险最高的代码，以及少数规定必须两个人看的目录和文件 |
两个人 |
这张表看着简单，真正值得抄的是背后的几条规矩，我挨个说。
第一条，级别由改动本身决定，跟作者是谁无关。 你以为资深工程师提的 PR 就可以少审？其实不行。定级的是一个自动判断风险的分类器，它读一遍这次的改动，判断属于哪个风险等级。然后还有第二个分类器，专门再问一句：“就算这个等级说不用人看，这个具体的改动需不需要再找个人看看？”另外有些目录和文件无论如何都要人看，比如代码负责人标记为敏感的区域，还有所有控制自动构建、自动测试流程的配置文件。
第二条，只有信得过的作者，才能享受少审一道的待遇。 每个仓库有一份可信作者名单，基本就是负责这个仓库的团队成员。不在名单上的人提的 PR，都要再找一个人批准。另外，agent 的批准永远不能算作人的批准。自动审查可以放行一个低风险改动，但如果规则要求一个人来批，这个名额 agent 顶不了。
第三条，谁发起的改动谁负责。 agent 写的 PR，指挥这个 agent 的那个人，自动算作必需的审查人之一，就跟这段代码是他亲手敲出来的一样。这一条我觉得特别重要，它把“AI 写的，不关我事”这条退路彻底堵死了。
第四条，一次批准只对一个具体的 commit 有效。 批准之后，如果又有新的 commit 进来，而且系统没法担保这些 commit 没问题，比如 agent 又推了一次代码，或者有人手动解决了合并冲突，那就得重新批准。这条规矩防的是一种很常见的情况：人批完了，agent 又悄悄改了一版，最后合进去的代码，其实根本没人批过。
漏过去的问题怎么办？
前面几层再严，还是会有漏网之鱼。所以最后两层管的是：就算漏了，也能尽快发现、尽快撤回。
先说 merge queue（合并队列）。这里有个很容易被忽略的场景：两个 PR 各自跑测试都没问题，但两个一起合进去，就把主分支搞坏了。merge queue 的做法是，让 PR 排队合并，轮到谁，就把谁的改动叠加到最新的主分支上，再把所有检查重跑一遍。这样就不会出现“各自都对，合起来就错”的情况。
新功能上线时，通常会加一个功能开关（feature flag），先只对 Anthropic 内部员工打开。内部员工每天都在重度使用，很多问题在用户发现之前就被员工先撞上了。正式版本先发 latest 渠道，stable 渠道晚一步跟上。真出了问题，直接把功能开关关掉就行，不用重新部署。Claude Code 有每周轮换的值班，事故复盘时会问一个问题：这个问题本来应该被哪一层拦住？
说到这里，Claude Code 团队也很坦诚，承认了一个短板：发现问题现在还是靠作者、值班人员，以及回滚和事故的看板。他们还没有做“指标一变差就自动收紧审批”的熔断机制。工程师们希望先有这个，再让更多代码走零人工合并。团队里一位同事说了句挺有意思的话：“放慢速度确实能降低出错率，但主要是因为你什么都干得少了。”所以他们宁可在“快速发现、快速修复”上下功夫。
五、AI Reviewer 自己是怎么变好的？
讲到这里，整套流程最核心的一环其实是 AI Reviewer。那问题来了：怎么知道这个 Reviewer 是在变好还是变差？Claude Code 团队做了三件事。
用自己踩过的坑当考卷
团队把历史上引发过事故的 PR 都收集起来，连同后来的修复和回滚一起，再请熟悉那块代码的工程师逐个确认：bug 到底是什么，藏在哪里。这就成了一份考卷，Reviewer 每天都要跑一遍。每出一次新事故，考卷就多一道题。改 Reviewer 的提示词、换工具、换模型，都要拿这份考卷全量打分，分数涨了才保留，没涨就丢掉。
我觉得这个做法特别值得普通团队学。很多人调 AI Review 的提示词全凭感觉，改完觉得“好像好一点了”，但到底好没好，没人说得清。拿自己真实踩过的坑当考卷，比任何公开的跑分榜单都实在。
怎么衡量 Reviewer 有多吵？
想多抓 bug 其实很容易：你让 Reviewer 什么都报，召回率立马上去了，只不过里面混着一大堆根本不是 bug 的东西。所以必须同时盯着噪音。团队的做法是看人怎么对待每条评论。每一条 Reviewer 留下的评论，按 PR 作者的反应分成四类：修了、说它错了、说这是故意这么写的、觉得无所谓。另外，他们还会拿已知没问题的干净 PR 去跑 Reviewer，统计 Reviewer 有多少次报出了一个“会让人做出有害改动”的问题。
他们写下来的优先级是：第一抓真 bug，第二减少审查轮次。这里有个很容易想不到的点：当写代码的是 agent 时，噪音的代价会变得更高。人看到一条无关紧要的 Nit，几秒钟就跳过了。agent 不会跳过，它会认认真真去改，于是又多一次 commit，又多一轮审查。
审查为什么必须收敛？
这一点估计很多用 AI 互审的同学都踩过坑。agent 写，agent 审，两个 agent 可以互相给对方找活干，没完没了。他们就真遇到过：有一个 CLI 的 PR，一个晚上来回审了五十多轮，最后是作者自己出手才叫停的。
团队拿 Reviewer 反复报的那些问题，跑了一下 git blame（可以查出每一行代码是什么时候写的），发现大约 59% 的代码，在 Reviewer 第一轮审查时就已经在那里了。简单来说，Reviewer 很少在找新 bug，它是每一轮都多翻出几个老 bug。
讲真，这个坑一部分是他们自己挖的。大家已经习惯了默认跑好几轮，因为每多一轮总能多抓到点什么。这在高风险改动上值得，放到每个 PR 上就不划算了。所以团队开始把“几轮能通过”和召回率一起盯，并且改了重新审查的规则：
- 设轮次上限，审到第三轮还没过，Reviewer 会让作者停下来，重新考虑一下方案。
- 前几轮过后，只审新增的 diff。
- 报问题时报出一类 bug，让作者把所有同类的地方一次修完，别只修一行。
- 已经报过的问题，不再重复报。
另外，团队还有审查 agent 每晚扫一遍现有代码，老 bug 在别的地方冒出来之前就先揪出来。这样也不用指望每次 PR 审查去顺带清理。改完之后的效果是这样的：一轮审查加修复就能通过的 PR 比例，从 65% 涨到了 78%；需要五轮以上的 PR，从 8.9% 降到了 1.5%；平均需要审查的次数，从 2.08 次降到了 1.32 次。
六、人省下来的时间，该花在哪里？
AI 接手了大部分阅读，人并没有闲下来。有五件事，还是得人来做：
- 决定要不要做。方向、品味、范围，这些 AI 替不了。有一个团队已经宣布自己的 Review 瓶颈解决了，但对团队外部提交的改动，依然保留人工审查，就是为了有人能问一句“这件事我们到底该不该做？”
- 审查高风险代码，比如计费、自动更新器、CI 工作流。
- 审查架构，尤其是那种会被别人照着抄的模式。
- 读懂证据。测试输出、跑了什么命令、返回了什么、截图、Reviewer 的问题列表。如果你说不清这些检查可能漏掉什么，那就去要一次真正的 Review，别随手点通过。
- 对结果负责。每一个上线的改动，不管是谁敲出来的，都有一个人要为它负责。
第四条我想多说两句。以前审代码，你读的是代码本身；现在你读的是证据：测试跑了什么、结果是什么、AI 找出了什么。这其实对人的要求更高了，你得知道一套检查能覆盖什么、覆盖不了什么。
说回第二章留下的那个问题。Review 的第二个作用是让团队共享对代码的理解。现在大部分代码是 AI 在读，那人怎么熟悉代码呢？他们的回答挺出乎我意料的。他们没有正式的流程，团队里也没有谁能把 Claude Code 整个项目的全貌装在脑子里，他们也觉得没必要有人装着。谁想了解代码库的某一块，就让 Claude 针对那一块写一份讲解，几分钟就好，而且反映的是代码现在的样子。有人还会更进一步，让 Claude 做一个可视化的小页面，按自己喜欢的学习方式来讲那块代码。
他们的判断是：逐行读一个改文案的一行 diff，几乎学不到什么；读一份你马上要改的模块的讲解，能学到很多。再加上团队习惯在公开的 Slack 频道里干活，别人在做什么，做的过程中就能看到。
那代码合进去之后出了问题，谁来管？团队的规矩是“谁合入，谁负责”。中小改动合进去出了问题，一般由作者自己修。这条规矩能跑得通，靠的是几个前提：改动都很小，容易审、容易调、容易撤；所有东西都能撤回，flag、回滚、分阶段发布，大部分错误几分钟就能撤掉；影响范围决定把关力度，代价高的代码配更多人、更多检查；线上问题能通过监控数据和内部使用很快暴露出来。
还有很重要的一点：这不是追责。让作者去修，是因为作者对这段代码最熟。事故复盘看的是整套系统哪里出了问题。
最后还有一种情况：有些代码本来就不该合进去。agent 让开工变得很便宜，所以一定会有一些工作做着做着，发现根本不该合进去。通常是频道里有人问一句“为什么要做”，或者提一下之前的某个决定，或者建议一条更简单的路，作者就把 PR 关掉或者改个方向。因为代码写得快，关掉 PR 也不觉得心疼。这里的关键是：换方向的建议要在讨论里早点提，别等 PR 都写完了，再留一条卡住合并的评论。
七、普通团队可以从哪里开始？
看到这里，估计有同学会觉得：Anthropic 有自动定级的分类器、有合并排队、有自己的评测集，我们公司哪有这条件。
其实 Claude Code 团队在博客最后专门说了，这套东西的大部分组件，现在就能用上。我按普通团队的处境，挑出最容易落地的几步。
个人马上就能做的：
第一，让 AI 拿结果说话。把测试、lint 命令写进一份简短的 CLAUDE.md，再配个 hook，每次改完代码自动跑格式化和 lint。
第二，提 PR 前先审一遍。本地跑一下 /code-review 和 /security-review，或者开一个上下文干净的子 agent 来审。
第三，同样的意见说过两次，就写进规则文件。要注意，本地的 /code-review 只读 CLAUDE.md，REVIEW.md 是给 Code Review 服务用的，所以想在本地生效的规则，放进 CLAUDE.md。
团队可以推动的：
先从 PR 模板下手，加上“怎么测的”“有什么风险”“怎么撤回”三个问题。AI Reviewer 也别一下子全铺开，先挑一个仓库试点，调几周 REVIEW.md 再推广。然后定两条规矩：所有评论处理完才能合并；审查轮次设个上限，前几轮之后只审新增的 diff。最后把敏感的地方锁死。用 GitHub 的 CODEOWNERS（给目录指定负责人）和分支保护规则，让鉴权、计费、CI、发布流程这些目录必须由人来批。
再配上两条规矩。第一，AI 点的通过不算数。规则要求人来批的，必须是真人点通过。第二，人批完之后又有新代码推上来，之前的批准就作废，得重新批。GitHub 分支保护里有现成的开关（Dismiss stale approvals）可以打开。
长期要建设的：
按改动本身写下风险分级，一开始从严，有了数据再放宽。把事故和回滚攒成评测集，每次改 Reviewer 都拿它打分。衡量的时候盯人的时间，同时拿回滚率和事故率当护栏。
最后提醒一句：别一上来就让代码零人工合并。Code Review 产品在发布时就说明了，批准 PR 依然是人的决定，产品只给出问题，不负责批准。Anthropic 自己的仓库走得更远一些，允许代码负责人决定哪些低风险改动只靠自动检查就能合入。但他们自己也说了，还缺一个能自动收紧审批的熔断机制。人家有这么多层兜底都还在小心往前挪，我们就更没必要一步到位了。
最后
读完这篇博客，我最大的感受是：Code Review 的重心正在变。以前 Review 考验的是你读代码的能力，现在越来越考验你设计检查体系、读懂检查证据的能力。人省下来的时间，花在判断要不要做、把关高风险代码、对结果负责这些 AI 替不了的地方。
有个做法我挺认同的：每次 Review 漏掉了什么，他们就去问“模型当时缺了什么信息”，然后把补救措施写进 CLAUDE.md、写进 skill，或者加一道新检查。
你们公司现在 AI 写的代码是怎么审的？是硬着头皮逐行读，还是已经有了自己的一套办法？欢迎在评论区聊聊，也欢迎到 云栈社区 和更多开发者一起交流 AI 编程的落地实践。
参考文章：
发表于 昨天 22:52
|
查看: 6|
回复: 0
/1 
