Haystack

Hey PH！我们正在构建 Haystack，帮助团队应对由于编码智能体的兴起而需要审查的 PR 数量的激增。

Haystack 用一个队列取代了 GitHub 的 PR 审查系统，在人工阅读任何 diff 之前，它会对每个 PR 进行分类。它会查看 diff、代码库以及产生该 PR 的编码智能体对话。然后 Haystack 将 PR 分入以下三个类别之一：

1. 可以安全 merge。这意味着该 PR 有足够的证据支持，团队可以在没有他人审查的情况下直接 merge。

一些例子：- 一个小的 UI 文案修改，附带显示最终状态的截图- 一个后端改动，作者明显测试了重要路径并在真实环境中运行了变更2. 需要修复。这意味着该 PR 存在 bug 或违反了代码库中的规则，因此作者需要修复它。

一些例子：- 要求智能体通过添加分页来加速加载大型表格，但该 PR 仍然一次加载所有结果，只是在 UI 上“实现”了分页- PR 静默捕获错误，而没有记录、展示或处理它，违反了团队“禁止静默吞错误”的规则3. 需要人工审查。这意味着该 PR 无法被作者充分验证，或者涉及到代码库的敏感部分（由用户输入的指南决定），因此需要人工审查。

一些例子：- PR 更改了计费中的大量逻辑- PR 更改了像 onboarding 这样的重要用户流程，但作者只运行了单元测试，从未打开应用端到端检查流程，违反了团队关于高影响用户侧更改需要手动验证的规则。

Haystack 不是从逐行 diff 开始，而是立即告诉审查者 PR 背后的目标、作者所做的设计决策（来自其编码智能体对话），以及作者为验证该 PR 正常工作做了多少工作（例如运行脚本、检查前端等）。

通过这种方式，审查从“改了什么？”转变为“这是正确的行为吗？有证据表明它有效吗？”。

这里有一个快速演示：https://www.tella.tv/video/strea...

我们之前发布过 Haystack，作为理解大型 PR 的工具（https://news.ycombinator.com/ite...）。你们中的许多人可能也有同感，Opus 4.5 的发布完全粉碎了我们对于工程师能多快制作一个 PR 的认知。

随着编码智能体从 4.5 变得更好，我们意识到 PR 并没有随着我们的编码速度而扩展。团队中的每个成员每天都能输出超过 20 个 PR，代码审查很快就变得认知上令人疲惫，而且帮助不大。

与其他人交流后，我们了解到许多人也有类似感受，目前面临两难选择：要么完全不进行审查，要么试图跟上大量的 PR。

Haystack 是我们尝试的第三条路。我们仍然相信代码审查，但随着编码智能体生成更多代码，人工审查者的注意力变得更有价值，也更昂贵。

Haystack 帮助团队将注意力集中在那些人工可以有意义地改变 PR 结果的 PR 上。对于这类 PR，Haystack 向审查者展示该 PR 想要做什么、作者是否展示了它有效，以及哪些设计决策需要第二双眼睛。

我们还处于非常早期的阶段，正在摸索 Haystack 是否真的能让代码审查变得更好。我们非常希望能得到各种反馈！