https://CodePlato3721.github.io/zh/tags/code-review/Recent content in Code Review on Code PlatoHugo -- gohugo.iozhSat, 04 Jul 2026 00:00:00 +0000https://CodePlato3721.github.io/zh/post/ai%E6%97%B6%E4%BB%A3%E6%88%91%E4%BB%AC%E5%BA%94%E8%AF%A5%E6%80%8E%E4%B9%88%E5%AE%A1%E6%A0%B8%E4%BB%A3%E7%A0%81-%E4%BB%8E%E5%AE%A1%E6%A0%B8%E5%88%B0%E5%AE%A1%E8%AE%A1/Sat, 04 Jul 2026 00:00:00 +0000https://CodePlato3721.github.io/zh/post/ai%E6%97%B6%E4%BB%A3%E6%88%91%E4%BB%AC%E5%BA%94%E8%AF%A5%E6%80%8E%E4%B9%88%E5%AE%A1%E6%A0%B8%E4%BB%A3%E7%A0%81-%E4%BB%8E%E5%AE%A1%E6%A0%B8%E5%88%B0%E5%AE%A1%E8%AE%A1/<img src="https://pub-deacd49348914a49b1254b01f351ef0d.r2.dev/2026/07/code-review-in-the-ai-era-from-review-to-audit/cn/banner.png" alt="Featured image of post AI时代我们应该怎么审核代码：从审核到审计" /><h1 id="ai时代我们应该怎么审核代码从审核到审计">AI时代我们应该怎么审核代码：从审核到审计 </h1><h2 id="pr-review的迷思">PR Review的迷思 </h2><p>在这个时代最迷茫的一群人就是程序员，程序员每天做的最迷茫的一件事情就是review PR。</p> <ul> <li>agent写代码太快了，行数太多了，人工review不过来。大部分都是机械式的点approve</li> <li>agent写代码基本不犯低级错误，看了感觉也是白看</li> </ul> <p><img alt="AI时代的PR review" class="gallery-image" data-flex-basis="360px" data-flex-grow="150" height="1024" loading="lazy" sizes="(max-width: 767px) calc(100vw - 30px), (max-width: 1023px) 700px, (max-width: 1279px) 950px, 1232px" src="https://pub-deacd49348914a49b1254b01f351ef0d.r2.dev/2026/07/code-review-in-the-ai-era-from-review-to-audit/cn/01.png" srcset="https://CodePlato3721.github.io/01_2620468101951417916_hu_947b29864cbee25d.png 800w, https://pub-deacd49348914a49b1254b01f351ef0d.r2.dev/2026/07/code-review-in-the-ai-era-from-review-to-audit/cn/01.png 1536w" width="1536"></p> <p>于是有人就想出让一个agent去review另一个agent的PR。但是这样做的效果并不好。你经常会发现真正的模式问题agent并不能发现，agent发现的都是一些无关紧要的小问题，有些甚至都不是问题。</p> <p>也有的人建立了一些skill来让agent更好的review代码。但是我们反过来想，是不是把这些规则直接放到项目的ABS(Agent Behavior Specification)文件中，让agent直接根据这些规则写出合规的代码，不就好了?</p> <h2 id="问题出在哪里">问题出在哪里 </h2><p>PR Code Review 这个行为在手写代码的时代非常有用。因为人手写代码经常犯错。别的程序员可以帮你看代码从而</p> <ul> <li>发现你代码中的错误</li> <li>通过看你的代码熟悉项目</li> <li>发现你代码中的 code smell</li> <li>发现你代码中不符合项目规范的地方</li> </ul> <p>而对于 agent 来说：</p> <ul> <li>按照目前agent写代码的水平，你几乎不可能发现低级错误</li> <li>agent 不需要看某个 PR 来熟悉项目</li> <li>code smell 问题 agent 看不出来</li> <li>如果你做的好，可以让 agent 加载项目规范，就没有不合规的问题</li> </ul> <p>我经常说 agent 写出来的代码没有小问题，只有大问题。 我观察到两个现象：</p> <ul> <li>项目从多人维护慢慢转为单人维护单项目。这样的话很难review别人的代码，因为跨项目review需要的上下文不具备。</li> <li>agent写的PR越来越大。当PR大到一定程度的时候，review也变成了不可能的任务</li> </ul> <h2 id="新的审核">新的审核 </h2><p>所以我认为在AI时代我们的审核方式需要革命性的改变。具体有以下的改变。</p> <h3 id="新的时间点">新的时间点 </h3><p>以前 Review PR的一个好处就是，人跟人之间的信息是不共享的，思维方式也不一样。所以一个人可能可以发现另外一个人的问题。这个问题在agent coding的场景下几乎不存在。所以review别人的PR意义并不大。</p> <p>但是不是说不需要review了。而是我们应该尽量在代码<strong>还未被commit的时候review</strong>。review的时间节点改变了。我们应该在把agent写出的意大利面式的代码推送到repo之前喊停，避免大量的无用代码被推送到服务器，并浪费别的engineer的注意力。</p> <p>有人说这不是废话吗？agent写完代码我肯定会看一眼。还真不是。因为你会发现agent有时候会说帮你写完代码后自动就commit&amp;push了。你需要显式的叫停agent，不让它自动commit&amp;push。可以通过设置提交锁和hook来实现。</p> <p>我自己是建立了一套标准，让agent写完代码后生成一个临时的<strong>提交锁</strong>文件，名叫CR(commit request)，并在agent的hook中增加检测CR的行为。如果该提交锁文件存在，则拒绝commit。CR文件必须是你自己手动删掉的，或者通过一套标准删掉。我自己是设置了规则，只有我说approve的时候agent才会删掉CR文件，并提交代码。</p> <h3 id="新的标准">新的标准 </h3><p>在AI时代，review代码的重点应该从发现代码的小错误转变为：</p> <ul> <li>看是否有code smell</li> <li>看是否过度设计</li> <li>看是否有跟项目风格不统一的实现</li> <li>看是否符合需求</li> <li>新的关注点：<strong>看这个PR是否过大</strong></li> </ul> <p>最后一个关注点是随着agent写代码后产生的。一个过大的PR本身就是一个问题。如果这个PR大到上千行，并且不能被精简。那么说明这个task过大了。应该被拆分成多个可被检验的小task，分步实现。一个PR不应该大到不可被review。如果这样的话这本身也是一个code smell。</p> <p>一个合理的PR应该是只关注一件事情，而且这件事情虽然代码可能多，但是核心的思路应该是简单，容易理解的。比如你批量修改了某个符合固定模式的代码，虽然代码多，但是你可以很容易的看出其重复的部分。人脑会跳过这些重复的代码。它们并不会对你的思维造成负担，分散你的注意力。</p> <h3 id="新的动作">新的动作 </h3><p><strong>阅读变为询问</strong>：以前review的时候是我们自己去一行一行的看代码。现在我们应该努力的多问agent的代码意图和设计。通过不停的问来让你快速理解代码。我发现经常在问的过程中agent自己也会发现问题所在。</p> <p><strong>改代码改为改规则</strong>：当review发现了agent写的代码的问题之后，我们并不应该手动的去修改代码。因为就算你改了这一次，下一次agent依然会犯同样的错误。我们应该指示agent去修改代码。然后指示agent去修改规则文档。我把这些规则文档称之为ABS(Agent Behavior Specification)。比如 CLAUDE.md, BEST_PRACTICE.md, 等</p> <p><img alt="改代码改为改规则" class="gallery-image" data-flex-basis="360px" data-flex-grow="150" height="1024" loading="lazy" sizes="(max-width: 767px) calc(100vw - 30px), (max-width: 1023px) 700px, (max-width: 1279px) 950px, 1232px" src="https://pub-deacd49348914a49b1254b01f351ef0d.r2.dev/2026/07/code-review-in-the-ai-era-from-review-to-audit/cn/02.png" srcset="https://CodePlato3721.github.io/02_11644253990264407633_hu_785431e66ea7ee5c.png 800w, https://pub-deacd49348914a49b1254b01f351ef0d.r2.dev/2026/07/code-review-in-the-ai-era-from-review-to-audit/cn/02.png 1536w" width="1536"></p> <h3 id="新的频次">新的频次 </h3><p>以前我们每个PR都要有人approve才能merge。由于现在的情况变了：</p> <ul> <li>单人项目增多</li> <li>agent产出效率高于人工审核</li> <li>agent对于类似需求可以根据规则重复的做出相同质量的代码</li> </ul> <p>所以我们不需要在整个项目的整个周期中review每一次的代码改动。而是转为：</p> <ul> <li>项目初期review所有的代码改动，并逐渐建立规则库</li> <li>项目中后期对于简单需求的代码改动可以skip review，但是设置阈值。当skip review的次数达到阈值后，人工review观察是否需要完善规则</li> </ul> <h2 id="新的名字代码审计">新的名字：代码审计 </h2><p>这种新的review方式具有以下特点：</p> <ul> <li>在项目初期完整审核，在项目转为大型项目后抽检</li> <li>重要的不是保证代码的正确，而是保证写代码的方式的合规</li> </ul> <p>这很像财务审计。所以我觉得新的项目代码审核方式应该叫代码审计更合适。</p> <p><img alt="从审核到审计" class="gallery-image" data-flex-basis="360px" data-flex-grow="150" height="1024" loading="lazy" sizes="(max-width: 767px) calc(100vw - 30px), (max-width: 1023px) 700px, (max-width: 1279px) 950px, 1232px" src="https://pub-deacd49348914a49b1254b01f351ef0d.r2.dev/2026/07/code-review-in-the-ai-era-from-review-to-audit/cn/03.png" srcset="https://CodePlato3721.github.io/03_9142991911166664411_hu_3c9fdd03bdcc55d4.png 800w, https://pub-deacd49348914a49b1254b01f351ef0d.r2.dev/2026/07/code-review-in-the-ai-era-from-review-to-audit/cn/03.png 1536w" width="1536"></p> <hr> <h2 id="关于作者">关于作者 </h2><p>我是代码Plato。</p> <p>我相信，人类的创造力才是 AI Coding 的真实之树，而代码与模型不过是投射在洞穴墙上的影子。</p> <p>微博：@代码Plato 主页：https://weibo.com/u/1041257881</p>