最新

大家好！我们正在构建 Haystack（[haystackeditor.com](https://haystackeditor.com)），旨在帮助团队应对由于编码代理的兴起而导致的需要审查的拉取请求数量激增的问题。 Haystack 用一个队列替代了 GitHub 的 PR 审查系统，在人类需要阅读任何差异之前，先对每个 PR 进行分类。它会查看差异、代码库以及生成该 PR 的编码代理对话。然后，Haystack 将其分配到以下三个类别之一： 1. **可以合并**。这意味着该 PR 有足够的证据支持团队可以在没有其他人审查的情况下进行合并。 一些例子： - 一个小的 UI 文本更改，包含显示最终状态的截图。 - 一个后端更改，作者显然测试了重要路径，并在真实环境中运行了更改。 2. **需要修复**。这意味着该 PR 存在错误或违反了代码库中的某项规则，因此需要作者进行修复。 一些例子： - 代理被要求通过添加分页来加快加载大型表格的速度，但 PR 仍然一次性加载所有结果，并在 UI 中“实现”了分页。 - PR 静默捕获错误，而不是记录、显示或处理它。这违反了团队的“禁止静默错误吞噬”规则。 3. **需要人工审查**。这意味着该 PR 不能被作者充分验证，或者涉及代码库中的敏感部分（根据用户输入的指导原则确定），因此需要人工审查。 一些例子： - PR 更改了计费中的大量逻辑。 - PR 更改了重要的用户流程，如入职，但作者仅运行了单元测试，从未打开应用程序检查整个流程。这违反了团队的规则，即高影响的面向用户的更改需要手动验证。 Haystack 不会从逐行差异开始，而是立即告诉审查者 PR 背后的目标、作者做出的设计决策（根据他们的编码代理对话得出），以及作者为验证拉取请求的有效性所做的工作量（例如，运行脚本、检查前端等）。 通过这种方式，审查从“发生了什么变化？”转变为“这是正确的行为吗？是否有证据证明它有效？”。 这里有一个简短的演示：[视频链接](https://www.tella.tv/video/streamlining-code-reviews-with-haystack-65zj)。 我们之前推出了 Haystack 作为理解大型 PR 的工具（[链接](https://news.ycombinator.com/item?id=45201703)）。正如许多人可能会感同身受的那样，Opus 4.5 的发布完全打破了我们对工程师能多快编写 PR 的认知。 随着编码代理在 4.5 版本中变得更加强大，我们意识到拉取请求并没有随着我们的编码速度而扩展。随着团队中的每个成员每天能够产生超过 20 个拉取请求，代码审查迅速变得认知上疲惫且帮助不大。 与其他人交谈后，我们了解到许多人有类似的感受，目前面临的二元选择是要么完全不进行审查，要么试图跟上源源不断的拉取请求。 Haystack 是我们尝试的第三条道路。我们仍然相信代码审查，但随着编码代理生成更多代码，人工审查者的注意力变得更加宝贵和昂贵。 Haystack 帮助团队将注意力集中在那些人类可以有意义地改变 PR 结果的拉取请求上。对于这样的 PR，Haystack 向审查者展示了 PR 的意图、作者是否证明了其有效性，以及哪些设计决策需要第二双眼睛的审查。 我们仍处于早期阶段，正在探索 Haystack 是否真正改善了代码审查。我们非常欢迎任何反馈！

这是一个从零开始构建中等价格机器人狗的食谱，使用所有商业和3D打印的零件，由树莓派5和ROS2 Jazzy控制。目前已经实现了一种手动编码的行走步态，可以通过控制器控制其向前移动或改变方向。它尚未配备进行强化学习训练所需的惯性测量单元（IMU）；然而，我相信这是目前可用的最简单设计之一，适合多种开发路径。

请访问以下链接查看内容： [https://twitter.com/cursor_ai/status/2056415413077233983](https://twitter.com/cursor_ai/status/2056415413077233983)