Orbi 用 Issue 驱动开发、审查与部署

给 GitHub Issue 打个标签，AI 就接手需求整理、编码、评审、合并和部署。Orbi 想把这条链路串起来，做成一个开源、可自托管的「软件无人值守工厂」，许可证是 AGPL。

它值得关注的地方，是把 AI 编程的入口前移到了需求，把终点延伸到了部署。不过，原文是一份简短的产品介绍，没有演示记录、成功率或对照数据。读这篇时，需要分清产品宣称覆盖的流程与已经得到验证的效果。

一个标签之后，究竟接了哪些工作

Orbi 把 GitHub Issue 作为任务入口。用户打上标签后，它会根据仓库上下文提出可以交付的需求建议，并检查任务描述是否足够明确。

描述太薄的工单会被拦住，再补充验收标准，或者拆成子任务。这个顺序很关键：如果「完成」没有定义，后续即使代码能运行，也很难判断有没有解决问题。

进入开发阶段后，Orbi 会在独立的 worktree 中写代码、运行项目测试，再创建 PR。worktree 可以理解为同一个 Git 仓库的另一份工作目录，用来隔离当前任务的文件改动。

随后，一个独立的 AI reviewer 检查 PR，Orbi 根据评审意见继续修改，直到评审通过。最后，它还会合并代码、创建包含 tag 和发布说明的 release，并执行部署。

Orbi 的核心主张，是把从工单到上线的交接也交给自动化流程。

但这条链路的具体边界没说清。原文没有说明使用什么模型、如何配置触发标签、支持哪些部署环境，也没有交代评审通过与测试通过分别如何判定。

为什么把状态全部放进 GitHub Issues

Orbi 宣称，GitHub Issues 是唯一保存状态的地方，因此不需要另外运行数据库。

对已经围绕 GitHub 协作的团队，这个选择有直接吸引力：任务入口和执行状态留在熟悉的位置，自托管时也少维护一个数据库。它还采用 AGPL 许可证，允许用户自行部署。

不过，「没有数据库」只能说明状态存储的选择，不能据此推断整个系统部署简单。执行代码需要什么环境、模型调用如何配置、仓库和部署权限如何管理，原文都没有展开。

类似地，把状态放进 Issues，并没有自动回答任务中断后如何恢复、多项任务如何协调、状态更新失败后如何处理。这些问题需要实现细节或实际运行记录来证明，产品介绍本身给不出答案。

我的判断

我认同它先检查需求、再编码的顺序。验收标准不清楚时，增加生成代码的速度，很容易让返工也一起加速。独立 worktree、测试和单独的 AI 评审，也都围绕真实交付中的问题展开。

但「独立 AI reviewer」提供了另一轮检查，不等于已经证明它能可靠发现错误。原文没有交代评审者与编码者是否使用不同模型、能看到哪些上下文，也没有给出漏检率或返工次数。

相比 AI 写代码、人工审 PR 和发布的常见做法，Orbi 把自动化范围扩展得更远，潜在收益是减少人工交接；代价是需要验证更多环节，尤其是自动合并和部署的条件。

原文提供的是完整流程的产品主张，尚不足以证明无人值守交付已经可靠。

这里甚至没有足够的实验描述可供复现，不能把它当成一份效果报告。

能拿来做什么

• 可以先改进日常 AI 编程的工单模板，把目标、范围和验收条件写清楚，再让 AI 开始实现。这个做法直接对应 Orbi 对薄工单的处理思路。
• 如果准备试用 Orbi，可以选一个测试较完善的前端或 Node 仓库，用范围明确的小任务验证从 Issue 到 PR 的链路，再检查评审、合并和部署各自如何触发。
• 评估时记录人工介入、测试结果和部署结果，检查「评审通过」是否对应真正满足验收条件。原文没有这些数据，需要自己补齐。
• 考虑自托管前，先阅读部署文档与 AGPL 许可证，并确认模型配置、执行环境和权限要求。原文只明确了无需另建状态数据库，其他运维条件仍待核实。