软件工程 on Code Plato

AI时代我们应该怎么审核代码：从审核到审计

Sat, 04 Jul 2026 00:00:00 +0000

AI时代我们应该怎么审核代码：从审核到审计

PR Review的迷思

在这个时代最迷茫的一群人就是程序员，程序员每天做的最迷茫的一件事情就是review PR。

agent写代码太快了，行数太多了，人工review不过来。大部分都是机械式的点approve
agent写代码基本不犯低级错误，看了感觉也是白看

于是有人就想出让一个agent去review另一个agent的PR。但是这样做的效果并不好。你经常会发现真正的模式问题agent并不能发现，agent发现的都是一些无关紧要的小问题，有些甚至都不是问题。

也有的人建立了一些skill来让agent更好的review代码。但是我们反过来想，是不是把这些规则直接放到项目的ABS(Agent Behavior Specification)文件中，让agent直接根据这些规则写出合规的代码，不就好了?

问题出在哪里

PR Code Review 这个行为在手写代码的时代非常有用。因为人手写代码经常犯错。别的程序员可以帮你看代码从而

发现你代码中的错误
通过看你的代码熟悉项目
发现你代码中的 code smell
发现你代码中不符合项目规范的地方

而对于 agent 来说：

按照目前agent写代码的水平，你几乎不可能发现低级错误
agent 不需要看某个 PR 来熟悉项目
code smell 问题 agent 看不出来
如果你做的好，可以让 agent 加载项目规范，就没有不合规的问题

我经常说 agent 写出来的代码没有小问题，只有大问题。我观察到两个现象：

项目从多人维护慢慢转为单人维护单项目。这样的话很难review别人的代码，因为跨项目review需要的上下文不具备。
agent写的PR越来越大。当PR大到一定程度的时候，review也变成了不可能的任务

新的审核

所以我认为在AI时代我们的审核方式需要革命性的改变。具体有以下的改变。

新的时间点

以前 Review PR的一个好处就是，人跟人之间的信息是不共享的，思维方式也不一样。所以一个人可能可以发现另外一个人的问题。这个问题在agent coding的场景下几乎不存在。所以review别人的PR意义并不大。

但是不是说不需要review了。而是我们应该尽量在代码还未被commit的时候review。review的时间节点改变了。我们应该在把agent写出的意大利面式的代码推送到repo之前喊停，避免大量的无用代码被推送到服务器，并浪费别的engineer的注意力。

有人说这不是废话吗？agent写完代码我肯定会看一眼。还真不是。因为你会发现agent有时候会说帮你写完代码后自动就commit&push了。你需要显式的叫停agent，不让它自动commit&push。可以通过设置提交锁和hook来实现。

我自己是建立了一套标准，让agent写完代码后生成一个临时的提交锁文件，名叫CR(commit request)，并在agent的hook中增加检测CR的行为。如果该提交锁文件存在，则拒绝commit。CR文件必须是你自己手动删掉的，或者通过一套标准删掉。我自己是设置了规则，只有我说approve的时候agent才会删掉CR文件，并提交代码。

新的标准

在AI时代，review代码的重点应该从发现代码的小错误转变为：

看是否有code smell
看是否过度设计
看是否有跟项目风格不统一的实现
看是否符合需求
新的关注点：看这个PR是否过大

最后一个关注点是随着agent写代码后产生的。一个过大的PR本身就是一个问题。如果这个PR大到上千行，并且不能被精简。那么说明这个task过大了。应该被拆分成多个可被检验的小task，分步实现。一个PR不应该大到不可被review。如果这样的话这本身也是一个code smell。

一个合理的PR应该是只关注一件事情，而且这件事情虽然代码可能多，但是核心的思路应该是简单，容易理解的。比如你批量修改了某个符合固定模式的代码，虽然代码多，但是你可以很容易的看出其重复的部分。人脑会跳过这些重复的代码。它们并不会对你的思维造成负担，分散你的注意力。

新的动作

阅读变为询问：以前review的时候是我们自己去一行一行的看代码。现在我们应该努力的多问agent的代码意图和设计。通过不停的问来让你快速理解代码。我发现经常在问的过程中agent自己也会发现问题所在。

改代码改为改规则：当review发现了agent写的代码的问题之后，我们并不应该手动的去修改代码。因为就算你改了这一次，下一次agent依然会犯同样的错误。我们应该指示agent去修改代码。然后指示agent去修改规则文档。我把这些规则文档称之为ABS(Agent Behavior Specification)。比如 CLAUDE.md, BEST_PRACTICE.md, 等

新的频次

以前我们每个PR都要有人approve才能merge。由于现在的情况变了：

单人项目增多
agent产出效率高于人工审核
agent对于类似需求可以根据规则重复的做出相同质量的代码

所以我们不需要在整个项目的整个周期中review每一次的代码改动。而是转为：

项目初期review所有的代码改动，并逐渐建立规则库
项目中后期对于简单需求的代码改动可以skip review，但是设置阈值。当skip review的次数达到阈值后，人工review观察是否需要完善规则

新的名字：代码审计

这种新的review方式具有以下特点：

在项目初期完整审核，在项目转为大型项目后抽检
重要的不是保证代码的正确，而是保证写代码的方式的合规

这很像财务审计。所以我觉得新的项目代码审核方式应该叫代码审计更合适。

关于作者

我是代码Plato。

我相信，人类的创造力才是 AI Coding 的真实之树，而代码与模型不过是投射在洞穴墙上的影子。

微博：@代码Plato 主页：https://weibo.com/u/1041257881

AI时代的开发范式：ABS

Tue, 16 Jun 2026 00:00:00 +0000

AI时代的开发范式：ABS

观点

目前关于 AI 编程，大致有几种不同的观点：

不相信 AI，只把 AI 当作代码生成器使用。生成一些片段代码后复制到项目中，开发流程依然和过去完全一样。
100% 相信 AI，采用纯 Vibe Coding 模式。完全不看生成后的代码，只不断补充网上搜集来的最佳实践和更细致的验证条件。只要验证条件通过，再加上足够多的最佳实践约束，就能够得到可用的项目。
半相信 AI。把写代码的工作完全交给 AI，但不相信 AI 能做好设计或者测试。因此自己通过 Ask 模式参与设计，或者让 AI 搭建测试脚手架，再由自己完成测试工作。

那么，究竟哪一种才是正确的方向？

迷思

在这个时代，随着 Loop Engineering 的出现，源代码似乎已经不再属于程序员。UI 界面似乎不再属于设计师，测试脚本似乎不再属于测试人员，甚至连需求文档也开始不再完全属于产品经理。

但与此同时，完全没有人类参与的情况下，又很难真正做出一个可用的产品。那么留给人类的工作究竟还剩下什么？人脑与模型之间真正的 Gap 又在哪里？

新的范式

从电路板到集成电路

我大学学的其实不是计算机，而是电子工程。最早的电路设计是在电路板上手动焊接各种元器件，包括三极管等具备一定逻辑能力的器件。后来随着集成电路的诞生，这些底层逻辑逐渐被封装起来。工程师只需要编写 HDL 代码，就能自动生成复杂的电路结构。

没有人再关心某个晶体管究竟是如何连接到另一个晶体管的，我们的思维开始向更高层次迁移。关注的不再是元器件之间的连接方式，而是更抽象、更高层级的问题。

从代码到 ABS

ABS是什么

ABS，全称 Agent Behavior Specification。

你在项目中看到的 AGENTS.md、CLAUDE.md、MEMORY.md 等文件，本质上都是用于规范 Agent 行为的文件。它们都属于 ABS。

如何实践

工程师的工作不应该是一行一行地写代码，也不应该是一行一行地审查代码。当然，也不是完全不关心 Agent 的实现过程，只看最终结果。工程师依然需要保留对细节的掌控能力，你仍然会在项目初期或者某个特定阶段深入审查代码。

但这件事的性质已经发生了变化。过去审查代码是为了交付产品，现在审查代码则是为了校准 Agent。你看完之后，不再第一时间去修改代码、文档或者配置，而是去思考：为什么 Agent 会这样做？它缺少了什么规则？哪些经验应该被沉淀下来？

随后，让 Agent 自己去完成修改，而你负责总结规律，并将其写入 ABS。例如：

可以改进的地方写入最佳实践，例如 BEST_PRACTICES.md。
不应该再犯的错误写入禁令，例如 NEVER.md。
项目架构的调整写入架构定义，例如 ARCHITECTURE.md。
其他长期有效的规则继续沉淀到对应的 ABS 文件中。

因此，在 AI 时代，工程师最重要的产出不再是代码本身，而是 ABS 文件。ABS 才是新时代的源代码，而代码只是 ABS 的编译结果。

单文件 vs 多文件

ABS 文件到底是一个 CLAUDE.md 或 AGENTS.md 就够了，还是应该拆分成 ARCHITECTURE.md、STACK.md、NEVER.md 等多个文件？社区已经出现了很多不同的规则文件组织方式，那么哪一种更好？

当我们把 ABS 视为新时代的源代码之后，这个问题其实很好回答。

第一，哪种颗粒度更好？答案是多文件。原因和传统软件工程完全一样：职责划分更清晰、更适合多人协作、更容易维护、更容易定位问题，同时也能够减少代码冲突。

第二，哪种命名规范更好？是叫 STACK.md 还是 ARCHITECTURE.md？其实并不重要。就像今天的软件开发一样，重要的不是文件名本身，而是你是否完成了合理的职责划分。你需要知道哪些内容属于架构层，哪些内容属于最佳实践层，哪些内容属于禁止事项层。至于具体文件叫什么名字，并不是关键，关键是这种组织思想。

工作场景

那么，AI 时代的工程师究竟应该如何工作呢？下面这个例子或许能帮助你感受未来的软件开发方式。

Tom 早上 9 点来到公司，泡了一杯咖啡，准备开始一天的工作。

编排面板

他打开 Agentic Development Workflow 面板（这个名字已经长到不需要解释它是干什么的了）。

首先查看各个 Agent 的工作状态。哪些 Agent 被 Block 住了？哪些 Agent 昨晚又提交了多少个 PR？哪些 Agent 的效率明显下降？这些信息会成为他一天工作的起点。

编辑 ABS

随后他发现一个 Agent 被卡住了，需要 Human-in-the-Loop 的支持。于是他帮助 Agent 解决了问题，并把解决方案写进 NEVER.md，防止其他 Agent 将来遇到类似问题。

处理完所有被卡住的 Agent 后，他开始查看昨天的监控数据。这时他发现某个 Agent 为一个非常简单的需求编写了几百行单元测试，这让他觉得有些异常。于是他仔细阅读这些测试代码，结果发现 Agent 编写了大量 Mock，对实现细节进行了过度依赖，形成了一套非常脆弱的测试体系。

于是他让 Agent 重新编写测试。这一次，更偏向芝加哥学派，而不是伦敦学派。随后，他把这条经验补充到了 BEST_PRACTICES.md 中。

Agent行为监控

接着，系统面板弹出一个通知。某个 Agent 已经连续 10 轮无人值守地产出代码。根据他预先设置的阈值，现在应该切换到人工辅助模式。

在这种模式下，Agent 不再自动提交和审核代码，而是每一步都需要人类参与确认。通过审查最近的工作记录，他发现这个 Agent 已经开始出现轻微的架构漂移。于是他怀疑其他 Agent 可能也存在类似问题，随后抽查了其他几个 Agent 的工作成果，并相应更新了 ARCHITECTURE.md、BEST_PRACTICES.md 等文件。

核心问题攻坚

下午，老板交给他一个非常困难的任务。这个任务涉及大规模架构调整，模型暂时还无法独立完成。

于是他将 Agent 切换到人工辅助模式。接下来几个小时里，他和 Agent 一起完成了架构设计、方案验证以及实现工作。与此同时，那些 Bug 修复、UI 微调、配置更新等相对标准化的任务，依然由无人值守的 Agent 自动完成。

就这样，一天的工作结束了。

Tom 关掉电脑，下班回家。

而他的 Agent 们，则继续工作。