從 GitHub PR 與 Control Center 對話

本指南說明如何在不必離開 GitHub 的情況下與 Control Center 協作：直接從 PR 頁面要求 AI 審查、在留言中向機器人提問，並在它的審查討論串中持續對話。

機器人就是你伺服器自己的 GitHub App — 也就是已經負責讓人登入並執行背景工作的同一個 App。不需要註冊任何新東西，也沒有任何東西必須能從網際網路連線：伺服器以輪詢方式得知 GitHub 上說了些什麼，因此位於 NAT 後方的筆記型電腦，行為與公開部署完全相同。

先決條件

伺服器已註冊並安裝它的 GitHub App，並具備 Pull requests: read and write（用於留言、討論串與表情回應）以及 Issues: read（用於留言搜尋）。兩者都已在該指南的權限清單中
儲存庫已連結到 Control Center 中的某個工作區
不需要 webhook URL、不需要通道、不需要回呼 — 網路端沒有任何要設定的東西

機器人的登入名稱是 <appslug>[bot]，其中 appslug 是你註冊該 App 時所取的名稱。

前往 設定 → 伺服器 → 單一登入，並捲動到 供應商應用程式 卡片
開啟 GitHub 區塊，然後按一下測試
在 機器人登入名稱 填入後複製它。如果它仍顯示空白提示，登入名稱一律是 <appslug>[bot] — 請直接輸入該值，或輸入簡短的 @appslug

GitHub 不會在它的 @ 自動補全中提供 App 帳號，因此登入名稱必須手動輸入 — 這正是設定卡片讓它只要按一下就能複製的原因。[bot] 後綴是選用的：@myapp 與 @myapp[bot] 都能指向機器人。

有兩種方式，兩者都會啟動與 詢問 AI 按鈕相同的那條預置 pr_review 管線：

**為 PR 加上 ai-review 標籤。這是 GitHub 所能提供、最接近把機器人指派為審查者的做法 — App 帳號無法佔用原生的要求審查者欄位。這裡沒有可供回應的留言，因此 GitHub 上不會發佈任何內容；審查會在 Control Center 中啟動
在 PR 對話中留言 @myapp review（或只寫 @myapp）。機器人會以 👀 回應，接著在審查開始時回覆（或告知已經有一個正在執行）

審查者會在該 PR 的審查空間中工作；閱讀與發佈發現的方式與使用 AI 審查相同。發佈回 GitHub 始終是你在 Control Center 中做的決定 — 從 GitHub 啟動審查本身不會把任何內容發佈到 GitHub。

標籤對每個 PR 只會觸發一次：加上它就算是提出要求，而移除後再重新加上並不會重新觸發。若要再次執行審查 — 例如在一次推送之後 — 請提及機器人。

在 PR 對話中留言：

@myapp why does the flaky test in runner_test.dart fail on CI but not locally?

接下來會依序發生的事：

對尚未經過審查的 PR 提問，會喚醒工作區的 CEO 代理；一旦執行過審查，就會由最後發言的代理回答，因此後續追問會落在掌握脈絡的那一位身上。

在機器人參與的行內審查討論串中回覆 — 可能是它留下的差異留言，或它在該討論串中張貼的答案。不需要提及；討論串本身就是定址方式：

> @myapp the retry loop looks O(n²) to me

what would the complexity be with the bounded queue instead?

多輪對話的運作方式相同：每一次回覆都是同一段對話中的另一個問題，以該審查空間作為脈絡，而答案會回到該討論串中。

在 PR 對話時間軸上的追問是一則新的最上層留言，因此仍然需要 @提及。

一則 GitHub 留言送達時，除了登入名稱之外幾乎不帶任何資訊，因此機器人會先解析作者，才會進行任何動作：

你的 GitHub 帳號必須連結到你在 Control Center 中的身分 — 在 設定 → 工作區 → 個人資料與身分 → 程式碼託管 中使用 GitHub 登入，或貼上權杖
你必須是具備寫入角色（member、admin 或 owner）的成員，且隸屬於連結該儲存庫的工作區

其他任何人都會收到一則禮貌的回覆，說明缺少了什麼 — 未知的登入名稱（未連結，或已連結但不是這裡的成員）與唯讀角色就是這兩種情況 — 而他們說的話永遠不會進入該工作區。ai-review 標籤不受這道關卡限制：它沒有作者，因此會在已經連結該儲存庫的工作區中啟動審查。

項目	行為
確認	大約一分鐘內在留言上加上 👀 — 即掃描間隔。`ai-review` 標籤沒有可供回應的留言
答案	以機器人（App）的身分發佈，發佈在提問所在的對話串中
空間內的歸屬	問題算在你頭上；代理代表你執行，並受該空間的自主程度設定約束
審查	發現會落在審查空間中；發佈到 GitHub 須由人工進行

大約一分鐘的延遲，就是換取完全不需要任何傳入網路存取所付出的代價。這輪掃描沒有任何急迫之處，而伺服器離線期間也不會遺失任何東西 — 在停機期間到達的留言，會在下一次掃描時被補上。

提及機器人的留言卻毫無動靜。

App 是否已安裝在擁有該儲存庫的帳號上，且該儲存庫已連結到某個工作區？未連結的儲存庫會在記錄任何內容之前就被跳過，因此之後再連結它仍然會送達
你的 GitHub 帳號是否已連結，且你是具備寫入角色的成員？請查看 PR 上機器人的拒絕回覆 — 它會說明是哪一種情況
還是沒有動靜？伺服器日誌會在出錯時記下該次掃描與該 PR；請尋找 pr_conversation:（輪詢器）與 github_pr_conversation:（橋接器）

標籤沒有啟動審查。

它每個 PR 只會觸發一次。如果審查已經執行過，或標籤是在伺服器第一次看到該 PR 之前就加上（第一輪掃描會靜默記錄待處理的內容，而不是一次全部湧入），請改為提及機器人 — @myapp review 一律會啟動一次審查，除非已經有審查正在進行中。

機器人的答案始終沒有送達 GitHub。

答案本身永遠不會遺失 — 它就在 Control Center 中該 PR 的審查空間裡。發佈失敗（GitHub 故障、權限變更）會被記錄下來，而且不會重試該回覆；如果這件事很重要，請在討論串中再次提問。