Critic：让写代码的AI Agent来审查自己的代码

一个反直觉的代码审查思路

在AI编程工具快速普及的当下，越来越多的代码由AI Agent生成。这带来一个新问题：谁来审查这些AI写的代码？Hacker News上一个名为 Critic 的 Show HN 项目给出了一个颇具争议的答案——让写代码的那个Agent来审查它自己写的代码。

这个思路听起来有点像"运动员兼裁判"，但背后有其逻辑。编写代码的Agent掌握着最完整的上下文：它知道自己做了哪些设计取舍、为什么选择某种实现、哪些地方是临时妥协。相比一个从零介入、只能读取diff的外部审查工具，原始Agent对改动的意图理解要深得多。

Critic想解决什么

随着AI辅助编程规模化，人工逐行审查AI产出的代码正在变成瓶颈。团队面对的往往是大段AI生成的改动，评审者既缺乏对生成过程的了解，又要在有限时间内判断代码质量与安全性。

Critic的定位是把"审查"这一步嵌入到Agent的工作流中。由于同一个Agent既是作者又是评审者，它可以在生成代码后立即基于自身的推理链条进行复盘：检查边界条件、验证是否偏离了原始需求、发现潜在的逻辑漏洞。这种"自审"在理论上能拦截一部分低级错误，减轻人类评审的负担。

潜在的价值与明显的局限

从积极角度看，让作者Agent参与审查确实能利用它的上下文优势。它不需要重新推断代码意图，可以更快定位到"我当时为什么这么写"的关键节点，也更容易识别出与需求不符的偏差。

但这个方案的局限同样明显。代码审查的核心价值之一恰恰在于引入独立视角——评审者带着与作者不同的假设和盲区去检查代码，才能发现作者自己意识不到的问题。如果作者和评审者是同一个模型、同一套推理逻辑，那么作者在生成阶段没有考虑到的问题，在审查阶段很可能同样被忽略。换句话说，模型自身的系统性偏差无法通过"自己审自己"来消除。

这也是评审这类工具时需要重点关注的方向：Critic究竟是作为人工审查的替代，还是作为前置过滤器？如果是后者，它更像一个自动化的"自查清单"，先剔除明显问题再交给人类或独立工具复核，这样的定位会更稳妥。

认知科学中有一个相关概念叫"确认偏误"（Confirmation Bias）：人在验证自己的想法时，倾向于寻找支持而非反驳。这一偏误在大语言模型中同样有所体现——模型在自我评估时，往往倾向于为自己的输出辩护，而非批判性地审视。研究者将此现象称为"自我一致性偏差"。这意味着即使设计上赋予Agent审查角色，其推理起点与生成阶段仍共享同一套权重和归纳偏好，系统性盲区很难仅凭换个"角色"来跨越。这也是为什么人工审查或独立模型审查在安全关键场景中仍被认为不可替代。

值得关注的行业趋势

抛开单个产品的成败，Critic反映出AI编程领域一个正在成形的趋势：审查环节本身正在被AI化。当代码生成越来越自动化，配套的质量把关工具也必须跟上，否则AI只是把编写瓶颈转移到了审查瓶颈。

目前市场上出现了两条路线：一条是像Critic这样让生成Agent自审，追求上下文连贯；另一条是部署独立的审查Agent，追求视角独立。两者各有取舍，未来更成熟的方案很可能是二者结合——生成Agent做自审做初筛，独立Agent或人类做终审把关。

需要说明的是，Critic目前在Hacker News上的讨论热度有限（5个赞、1条评论），尚处于早期展示阶段，实际效果和采用情况还有待更多实践验证。对于关注AI编程工具链演进的开发者来说，它提供的是一个值得思考的方向，而非已经成熟的解决方案。

在软件工程领域，静态分析工具（如 SonarQube、Semgrep）和形式化验证长期承担着自动化质量把关的角色，但它们针对的是人类写的代码，规则集由人工维护。AI生成代码的兴起带来了新挑战：生成代码的模式和缺陷类型与人类代码存在差异，例如AI更容易产生"看起来合理但逻辑有细微错误"的代码，而非传统的语法或风格问题。这促使业界开始探索专门针对AI产出代码的审查策略，Critic代表的自审路线与独立Agent审查路线，可视为这一探索的两个早期实验方向。