提第一张 Issue

派活的方式就是在你连接的仓库里建一张普通的 GitHub Issue，然后加上 ai-ready 标签。 这个标签就是执行开关。别的都不需要 —— 没有命令，没有表单，没有单独的队列。Orbi 按定时器检查新打标的 Issue，所以认领最多要五分钟。

​

派发一张 Issue

1. 在 GitHub 上你连接的仓库里，建一张 Issue，描述一个改动。
2. 加上 ai-ready 标签。

这个标签已经存在了 —— 开通环境时和其余 ai-* 标签一起建好了。 五分钟左右，Issue 上会出现 ai-in-progress，并出现在状态页的 进行中 里。

​

从状态页派发

你不一定要手动打标。当你有还没交给 Orbi 的开放 Issue 时，状态页会把它们列在 挑一张让 Orbi 试试 下面，每张都带一个 让 Orbi 试这张 按钮，点了就替你打上 ai-ready 标签。 还有一个 在 owner/repo 创建 Issue 按钮，它会打开 GitHub 的新建 Issue 表单，指向你连接的仓库，并且标签已经预选好。 已经带了任何 ai-* 标签的 Issue 不会出现在这里 —— Orbi 要么正在处理它，要么已经处理完了。

​

这张 Issue 该怎么写

按你给一个能干但没看过你代码库的同事写需求的方式写。Orbi 把 Issue 正文和评论当成它的指令，所以你写在那里的内容就是规格说明。 真正有用的几点： 说清要改什么，知道位置的话也说清在哪。「报表页的导出按钮生成的 CSV 没有表头行，应该有」比「修一下导出」能给的信息多得多。 说清你怎么判断它做成了。 验收标准就是独立评审拿来对照检查的东西。「下载的 CSV 第一行是与列标题一致的表头」是可检查的；「导出正常工作」不是。 一张 Issue 只装一个改动。 打包的 Issue 产出打包的 pull request，更难评审，也更容易修复中轮次。 明确写出约束。 如果某个公开 API 不能变、某个文件不能碰、或者必须用某种特定做法，就在 Issue 里说。Orbi 不会自己推断禁止事项。 不要要求环境做不到的事。 交付跑在一个只有你仓库的隔离环境里，不是跑在你的生产系统上。需要生产凭据、真实第三方账号或一次真实部署的验收标准在那里无法满足 —— 而一张要求这些的 Issue 会空转到 ai-blocked。如果你需要那类证据，自己去拿，并在 Issue 里写明它不属于本次交付的验收范围。

​

从哪张开始

第一张 Issue 值得认真挑。一个范围切得好的小改动 —— 一个有清晰复现路径的 bug、一个缺失的测试、一次范围可控的重构 —— 跑得快，还能让你看完整个循环。含糊的架构类工作，留到你看过 Orbi 怎么处理你的代码库之后再说。 注意 你的 CI 决定了什么是有保障的。评审跑你仓库的测试套件；发版门禁读你仓库的 check run。如果你的仓库测试很强，Orbi 的保障就强。如果一个测试都没有，两道门禁都会真空通过，交付只靠评审的判断就发出去了。

​

中途转向

你不用等结果出来才能纠偏。Issue 处于 ai-in-progress 时，加一条写着新决定的评论，或者改 Issue 正文 —— 正在跑的会话会读到这个纠正并带着它重启，通常一分钟内。 一次交付接受 3 次这样的重启，而且只有仓库的 owner、maintainer、成员或协作者的评论才能让它转向。见交付生命周期。

​

优先级

加 p0 标签可以让一张 Issue 比别的先被认领。认领顺序是 p0 最先，然后是打了 bug 标签的，最后是其余的。

​

其他类型的活

ai-ready 默认派发开发类工作。配上第二个标签就能做别的任务类型 —— 运维与调研（ai-ops-only）、内容（ai-content-only）、或者发版（ai-release）。见交付生命周期。

​

接下来会发生什么

在 Issue 的标签上或者状态页上跟进。你要看的序列是 ai-in-progress → ai-pr-opened → ai-merged；中间出现 ai-fix-needed 是一次修复轮次，属于正常。 当有一个 pull request 开着等你时，状态页会在 待评审 下面说明。