解决 PR 瓶颈：Haystack 如何对 AI 生成的代码进行分流处理

随着复杂编程代理（以 Opus 4.5 等模型能力的飞跃为代表）的兴起，软件开发的效率发生了根本性的转变。虽然工程师现在可以以前所未有的速度生成拉取请求（PRs），但人类审查这些代码的能力并未成比例地增长。当一名团队成员每天能产生超过 20 个 PR 时，传统的逐行 diff 审查就变成了一个信息“消防栓”，不仅在认知上令人疲惫，而且往往收效甚微。

这正是 Haystack 旨在解决的核心问题。Haystack 并不将每个 PR 都视为手动审查的同等候选对象，而是引入了一个分流层，根据风险、证据和意图对 PR 进行过滤和路由，从而确保人类的注意力被花在能够对结果产生实质性影响的地方。

从“改了什么？”转向“它有效吗？”

传统的代码审查侧重于 diff：哪些行被添加或删除了？ 在 AI 增强的工作流中，这种方法是低效的。Haystack 将审查者的注意力转向目标和验证证据。审查者看到的不再是直接从代码开始，而是：

• 目标： PR 的预期用途。
• 设计决策： 实现背后的逻辑，基于工程师与编程代理之间的对话。
• 验证证据： 关于作者如何验证更改的文档（例如，运行的脚本、前端检查或端到端测试）。

通过将审查重心放在行为和证据而非语法上，该过程变成了对意图的验证，而不是对每个字符变化的手动审计。

分流系统：审查的三种分类

Haystack 用分流队列取代了标准的 GitHub PR 列表，将 PR 分为三个不同的类别：

1. 安全合并

这些是具有充分证据表明可以在无需人工干预的情况下合并的 PR。示例包括：

• 伴有最终状态截图的小型 UI 文案更改。
• 作者已提供在真实环境中测试关键路径的明确证据的后端更改。

2. 需要修复

这些 PR 会被标记出来，要求作者在到达人类审查者之前进行纠正。这可以防止审查者在显而易见的错误或违反策略的行为上浪费时间，例如：

• 逻辑失败： 一个代理被要求实现分页，但它反而加载了所有结果并在 UI 中模拟分页。
• 规则违反： 一个静默吞噬错误的 PR，违反了团队的“禁止静默吞噬错误”策略。

3. 需要人工审查

此类别预留给高风险更改或缺乏充分验证的更改。这包括：

• 敏感区域： 对关键逻辑的更改，例如计费系统。
• 验证不足： 高影响力的用户端更改（如引导流程），作者仅运行了单元测试，但未能进行手动端到端验证。

AI 审查中的哲学转变

Haystack 的引入引发了关于 AI 在开发生命周期中角色的必要讨论。一些怀疑论者问，让 AI 审查 AI 编写的代码是否是一种循环论证。然而，其价值主张并非完全自动化，而是增强。

正如一位社区成员所指出的，理想的未来是 AI 作为一个支持系统——类似于电影 Limitless 中的概念——增强人类的能力而非完全取代人类。通过作为一个过滤器，说“检查这些特定部分，因为它们值得注意”，AI 允许人类保持作为质量和架构的最终仲裁者，同时消除琐碎验证的枯燥工作。

结论

随着编码速度持续加速，软件开发生命周期的瓶颈正在从编写代码转向审查代码。通过将人类注意力视为一种稀缺且昂贵的资源，Haystack 提出了一个系统，其中分流先于审查，确保最关键的逻辑得到最严密的审查，而琐碎的任务则交由自动化处理。