AI 编程代理的「反压」验证体系：让你的代码代理学会自我审查

原文来源：Backpressure is all you need — 让 AI 编码代理在人类介入前自动验证自身输出的系统性方法

使用 AI 编码代理开发有一个尴尬的矛盾：要么让代理完全自治地跑任务，速度快但容易引入难以察觉的 bug；要么把它当成高级自动完成工具频繁打断审查，虽然安全但效率不升反降。

这篇文章就聚焦其中间地带——如何构建一个验证体系，使 AI 代理能够独立工作较长时间，同时确保它在产出低质量代码时被及时"反压"回来修好后再继续。

什么是反压

在系统工程中，"反压"指的是下游组件向上游信号无法继续接受更多工作的机制，迫使生产者放缓、缓冲或卸载负载——就像水管末端的阀门，当水流过快时会自动关小。

软件开发的例子随处可见：自动化测试在 PR 评审前对开发者施加反压；TypeScript 的类型检查在编译时就捕获错误；CI 流水线在合并前运行 linter、测试、金丝雀发布等一系列检查。这些都是你的代码被人类看到之前的质量保障。

问题在于，当前 AI 编码代理的反压机制仍然是一个人类——人工审查输出并反馈修正。 每次 LLM 写完一段代码，你需要停下手头的工作去检查、指出问题、让代理修改、再检查……这和不用 AI 有什么区别？

下一步不是让 AI 写更多代码，而是让 AI 学会在提交之前自我验证。

七层反压机制

作者将这些机制构建进了 Claude 的循环中。核心思路是：不是在任务结束时跑一次检查，而是在每一轮迭代中运行。

1. Linting、测试与简单验证脚本

这是最基础的一层。关键区别在于，这些检查在每一轮迭代中都运行，而不是只在任务结束时。每次代理写完一段代码，必须跑一遍所有检查，通过才能继续写下一段。

具体检查项包括：

Linting 通过 —— 代码风格一致性，防止一团乱麻
测试全绿 —— 回归测试保障已有功能不被破坏
新行为有测试覆盖 —— 自动检查新增代码是否引入了相应的测试
commit message 格式验证 —— 规范提交信息，方便追溯

作者所做的改动很简单：将这一系列质量检查写入了 Claude 的 /goal 循环描述中，并强制它在每次写入补丁后执行。

你必须在每次写入补丁后运行检查，而且在所有检查通过之前，不允许写下一段新代码。

2. 手动测试（cURL + 真实浏览器）

自动化测试覆盖不了所有东西。有些交互只能通过真实使用来验证。

你需要教会代理如何启动本地依赖（Docker、数据库、前后端），然后：

用 cURL 测试 API 端点——验证请求响应的正确性
用 Playwright MCP 做浏览器端到端测试——验证 UI 交互流程

这一层在迭代循环稳定之后（即所有自动化检查都通过了）运行一次，而不是每次迭代都跑——因为它通常比较耗时。

3. 基准测试

对性能敏感的应用程序，基准测试是必需的反压层级。要让基准测试可用，你需要投入时间做好基础设施：

一键运行：单命令即可执行全套基准测试
多套测试方案：不同时间预算、不同测试类别
结构化输出：解析输出比漫无目的看日志更重要
专门编写的 skill：命名为 run_benchmarks，内置结果解读启发式规则

比如，你的基准测试可以设置在首次迭代时不通过，迫使代理优化代码路径后再继续。这在涉及数据库查询或 API 响应时间的项目中特别有效。

4. 评审代理（Review Agents）

这是作者评测中最有效的反压机制——远胜于其他所有手段。

评审代理的本质是一个专门的 AI 角色，负责评审其他 AI 写的代码。它可以关注多个维度：

功能性 —— 代码逻辑是否正确
测试充分性 —— 测试覆盖是否全面
类型安全 —— typescript 类型是否正确使用
简洁性 —— 代码是否过于复杂，能否简化

作者建了一个 review_agent skill，在每一次迭代中都运行，并在结束时对整个变更集再运行一次。未来计划进一步拆分出多个专注不同维度的评审代理。

评审代理之所以有效，是因为它模拟了一个真实的 Code Review 流程——写代码的人有了"被人盯着"的压力，自然会写出更干净、更规范的代码。用在 AI 身上效果也一样。

5. 计划阶段评审

在写任何代码之前，先用一个轻量级的计划来描述你的方法——关注架构和设计方案，不要深入到实现细节。

然后让评审代理对这个计划进行评估，通过后才进入编码阶段。事实证明，在计划阶段发现问题比在代码写了一半时发现要高效得多。

计划不需要很详细——几百字的描述就足够。核心是让人和 AI 对"要解决什么问题"、"用什么方式解决"达成共识。

6. 视觉设计评审

前端开发场景下，使用 Playwright MCP 截取截图，然后与 Figma 设计稿或需求文档中的图片做对比。

评审 skill 包含的启发式规则包括：

对齐 —— 元素位置是否与设计一致
间距 —— 边距和间距是否符合规范
色彩对比 —— 颜色是否可读

作者坦率地表示不确定这一层的实际效果有多大（因为视觉感受仍然比较主观），但值得放入实验清单。

7. PR 监控

这是作者评测中第二有效的反压机制——仅次于评审代理。

打开 PR 之后，不要以为工作就完成了。设置一个监控周期（例如 24 小时），自动检查：

新评论 —— reviewer 的反馈
CI 失败 —— 持续集成的运行结果
合并冲突 —— 代码是否和其他分支冲突

当检测到问题时，让代理自动处理并重新推送。这模拟了一个真实的开发流程——你提交 PR 后收到反馈，修改代码，再提交。

完整的反压循环

把这些层级组合起来，形成一个完整的循环：

计划阶段：创建计划 → 评审计划 → 修改直到通过
迭代阶段：写补丁 → 运行所有检查（lint、测试、基准、评审代理、视觉评审）→ 修到全绿 → 继续下一段
迭代后阶段：手动测试（cURL + 浏览器）→ 完整基准测试 → 对整个变更集的最终评审
PR 监控：打开 PR → 监控反馈 → 自动处理问题 → 完成

任何依赖人类来捕捉机器错误的系统，最终都会被人类而不是机器所限制。

如何自己尝试

作者发布了 @lucasfcosta/backpressured 包。你可以直接运行：

code

npx @lucasfcosta/backpressured

然后在 Claude 中使用：

code

/backpressured <你的目标描述>

或者要求 Claude 使用 backpressured skill。你可以通过向项目添加 BACKPRESSURE.md 文件来自定义检查项——用自然语言描述你的质量要求即可。

作者的展望

这个方案目前还依赖 SKILL.md 来定义验证规则，但作者期待下一个版本能在模型层面原生支持——AI 框架应该内置这样的验证循环。

评审代理方面，他计划拆分成多个专注的代理（可读性评审、复杂度分析、测试覆盖率审核、类型安全性检查），每个代理只关注一个维度，减少复杂度。

更长远来看，趋势很明确：把"拒绝权"从人类转移到 AI 自身。就像我们在持续集成中做的那样——自动化检查决定了代码能不能合并，不依赖任何人的否决。同样的逻辑应该延伸到 AI 编写的代码上。