> ## Documentation Index
> Fetch the complete documentation index at: https://cloud-docs.orbi.build/llms.txt
> Use this file to discover all available pages before exploring further.

# 提第一张 Issue

> 我怎么把活派给 Orbi，这张 Issue 该怎么写?

派活的方式就是在你连接的仓库里建一张普通的 GitHub Issue，然后加上 `ai-ready` 标签。

这个标签就是执行开关。别的都不需要 —— 没有命令，没有表单，没有单独的队列。Orbi 按定时器检查新打标的 Issue，所以认领**最多要五分钟**。

## 派发一张 Issue

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

这个标签已经存在了 —— [开通环境](/zh/provisioning)时和其余 `ai-*` 标签一起建好了。

五分钟左右，Issue 上会出现 `ai-in-progress`，并出现在状态页的 **进行中** 里。

<Note>
  Orbi 只处理你连接的那个仓库里的 Issue。其他仓库里的 Issue 会被忽略，即使 App 装在那儿也一样。
</Note>

### 从状态页派发

你不一定要手动打标。当你有还没交给 Orbi 的开放 Issue 时，状态页会把它们列在 **挑一张让 Orbi 试试** 下面，每张都带一个 **让 Orbi 试这张** 按钮，点了就替你打上 `ai-ready` 标签。

<Frame caption="状态页列出未打标的 Issue，每张带「让 Orbi 试这张」按钮">
  <img src="https://mintcdn.com/orbi-cloud/Ya1dzVX1ins06kld/images/zh/status-ready-issues.png?fit=max&auto=format&n=Ya1dzVX1ins06kld&q=85&s=0176e295741a59b95abada440662a6f0" alt="状态页列出未打标的 Issue，每张带「让 Orbi 试这张」按钮" width="1920" height="5016" data-path="images/zh/status-ready-issues.png" />
</Frame>

还有一个 **在 `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、成员或协作者的评论才能让它转向。见[交付生命周期](/zh/delivery-lifecycle)。

## 优先级

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

## 其他类型的活

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

## 接下来会发生什么

在 Issue 的标签上或者[状态页](/zh/status-page)上跟进。你要看的序列是 `ai-in-progress` → `ai-pr-opened` → `ai-merged`；中间出现 `ai-fix-needed` 是一次修复轮次，属于正常。

当有一个 pull request 开着等你时，状态页会在 **待评审** 下面说明。