ai-ready 标签。
这个标签是执行开关，不需要别的命令、表单或单独的队列。环境就绪、额度可用，且没有排队或版本范围限制时，Orbi 通常一分钟内开始；常规定时认领每五分钟运行一次。
派发一张 Issue
不想自己写 Issue？在状态页点「写需求」，说说你想改什么，Orbi 先写成草稿，你点「交给 Orbi 开始做」后才开始做。详见写需求。- 在 GitHub 上你连接的仓库里，建一张 Issue，描述一个改动。
- 加上
ai-ready标签。
ai-ready 加 bug。ai-fix-needed 用于接续已经有 PR 的交付返修，不是新缺陷的分类标签。
这个标签已经存在了，准备工作环境时和其余 ai-* 标签一起建好了。
Orbi 认领后，Issue 上会出现 ai-in-progress，状态页的标题变成「Orbi 正在写代码」，并显示这张 Issue 和进度，这张 Issue 也会出现在「任务记录」里。
Orbi 只处理你连接的仓库里的 Issue。其他仓库里的 Issue 会被忽略，即使 App 装在那儿也一样。
从状态页派发
连接后 Orbi 会读仓库，建议能马上做的事。「Orbi 建议先做这些」每批最多三条：- 已有 Issue：「让 Orbi 做这个」立即打上
ai-ready，直接交给 Orbi。 - 新任务：「查看需求」先打开已经写好的草稿。你可以让它调整；确认后点「交给 Orbi 开始做」，才会建 Issue 并派发。
ai-ready，提交后直接进入队列。已有任意 ai-* 标签的 Issue 不会列入待交付列表。
做过交付、Orbi 空闲时，页面还可能提供 README 运行说明的小任务；只有你点「试试 →」才会新建并派发。
这张 Issue 该怎么写
按你给一个能干但没看过你代码库的同事写需求的方式写。Orbi 把 Issue 正文和评论当成它的指令，所以你写在那里的内容就是规格说明。 真正有用的几点： 说清要改什么，知道位置的话也说清在哪。「报表页的导出按钮生成的 CSV 没有表头行，应该有」比「修一下导出」能给的信息多得多。 说清你怎么判断它做成了。 验收标准就是独立评审拿来对照检查的东西。「下载的 CSV 第一行是与列标题一致的表头」是可检查的；「导出正常工作」不是。 一张 Issue 只装一个改动。 打包的 Issue 产出打包的 pull request，更难评审，也更容易需要修复轮次。 明确写出约束。 如果某个公开 API 不能变、某个文件不能碰、或者必须用某种特定做法，就在 Issue 里说。Orbi 不会自己推断禁止事项。 不要要求环境做不到的事。 交付跑在一个只有你仓库的隔离环境里，不会碰你的生产系统。需要生产凭据、真实第三方账号或一次真实部署的验收标准在那里无法满足，要求这些的 Issue 会一直空转到ai-blocked。如果你需要那类证据，自己去拿，并在 Issue 里写明它不属于本次交付的验收范围。
从哪张开始
第一张 Issue 值得认真挑。一个范围切得好的小改动，比如那个新手小任务、一个有清晰复现路径的 bug、一个缺失的测试、一次范围可控的重构，跑得快，还能让你看完整个循环。含糊的架构类工作，留到你看过 Orbi 怎么处理你的代码库之后再说。 你的 CI 决定合并和发布门禁能执行哪些自动检查。独立审查遵循目标仓库声明的测试和覆盖率要求。没有 CI 时，缺少检查记录不能证明测试通过，交付仍依赖独立审查和其余合并条件；已有的待完成或失败检查不会当作通过。见安全边界。中途转向
你不用等结果出来才能纠偏。Issue 处于ai-in-progress 时，加一条写着新决定的评论，或者改 Issue 正文，正在跑的会话会读到这个纠正并带着它重启，通常一分钟内。
一次交付接受 3 次这样的重启，而且只有实际拥有该仓库 write 权限的人的评论才能让它转向。见交付生命周期。
优先级
加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 是一次修复轮次，属于正常。
当有事需要你，比如一次审批、一次确认、缺少的信息或者一张卡住的 Issue，状态页会在状态主卡的「需要您处理」下面说明。