Show HN: Haystack – 审查需要人工关注的PR

嘿，HN！我们正在构建 Haystack（<a href="https://haystackeditor.com/">https://haystackeditor.com/</a>），帮助团队应对由于编码代理的兴起而导致的待审查拉取请求数量的激增。<p>Haystack 用队列取代了 GitHub 的 PR 审查系统，在人工阅读任何差异之前对每个 PR 进行分类。它会查看差异、代码库以及产生该 PR 的编码代理对话。然后 Haystack 将其归入以下三个类别之一：<p>1. 可安全合并。这意味着该 PR 有足够证据表明团队可以无需另一个人审查就合并。<p>一些示例：<p>-- 一个小的 UI 文案更改，附有显示最终状态的截图<p>-- 一个后端更改，作者明确测试了重要路径并在真实环境中运行了变更<p>2. 需要修复。这意味着该 PR 存在 bug 或违反了代码库的规则，因此需要作者修复。<p>一些示例：<p>-- 代理被要求通过添加分页来加快加载大型表格的速度，但该 PR 仍然一次加载所有结果，并在 UI 中“实现”了分页<p>-- 该 PR 静默捕获错误，而不是记录、显示或处理它。这违反了团队的“禁止静默吞没错误”规则<p>3. 需要人工审查。这意味着该 PR 无法由作者充分验证，或者涉及代码库的敏感部分（根据用户输入的指南确定），因此需要人工审查。<p>一些示例：<p>-- 该 PR 更改了计费中的大量逻辑<p>-- 该 PR 更改了重要的用户流程（如注册引导），但作者只运行了单元测试，从未打开应用检查端到端流程。这违反了团队关于高影响用户界面更改需要手动验证的规则。<p>Haystack 不是从逐行差异开始，而是立即告知审阅者 PR 背后的目标、作者做出的设计决策（来自其编码代理对话）以及作者为验证拉取请求正常工作所做的努力（例如运行脚本、检查前端等）。<p>通过这种方式，审查从“改了什么？”转变为“这是正确的行为吗？以及有证据表明它有效吗？”<p>这里有一个快速演示：<a href="https://www.tella.tv/video/streamlining-code-reviews-with-haystack-65zj" rel="nofollow">https://www.tella.tv/video/streamlining-code-reviews-with-haystack-65zj</a><p>我们之前发布过 Haystack 作为理解大型 PR 的工具（<a href="https://news.ycombinator.com/item?id=45201703">https://news.ycombinator.com/item?id=45201703</a>）。你们中的许多人可能都有同感，Opus 4.5 的发布完全颠覆了我们对工程师能够多快创建 PR 的认知。<p>随着编码代理从 4.5 开始变得更好，我们意识到拉取请求并没有随着我们的编码速度而扩展。我们团队的每个成员每天能产出超过 20 个拉取请求，代码审查很快就变得认知上令人疲惫且不那么有帮助。<p>在与其他团队交流后，我们了解到许多人也有类似的感受，目前面对要么完全不做审查，要么试图跟上拉取请求洪流的二元选择。<p>Haystack 是我们尝试的第三条路。我们仍然相信代码审查，但随着编码代理产生更多代码，人类审阅者的注意力变得更加宝贵和昂贵。<p>Haystack 帮助团队将注意力集中在那些人类能够有意义上改变结果的 PR 上。对于这些 PR，Haystack 向审阅者展示 PR 的意图、作者是否展示了它正常工作，以及哪些设计决策需要第二双眼睛。<p>我们仍然处于早期阶段，正在探索 Haystack 是否真正能改进代码审查。我们非常欢迎任何反馈！