從 GitHub PR 與 Control Center 對話

本指南說明如何在不用離開 GitHub 的情況下使用 Control Center：從 PR 頁面要求 AI 審查、在評論中向機械人提問，並在它的審查討論串中延續對話。

這個機械人就是你伺服器自己的 GitHub App —— 也就是已經負責讓人登入和執行背景工作的那一個。無需註冊任何新東西，也沒有任何東西必須能從互聯網連到：伺服器以輪詢方式探索 GitHub 上說了些甚麼，所以位於 NAT 後方的筆記型電腦，行為與公開部署完全相同。

開始之前

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

機械人的登入名稱是 <appslug>[bot]，其中 appslug 是你註冊應用程式時給它的名稱。

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

GitHub 的 @ 自動完成不提供應用程式帳戶，所以登入名稱必須手動輸入 —— 這正是設定卡片讓你可以一按複製的原因。[bot] 後綴是可選的：@myapp 和 @myapp[bot] 都能觸及機械人。

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

為 PR 加上 ai-review 標籤。這是 GitHub 所能提供、最接近把機械人指派為審查者的做法 —— 應用程式帳戶無法佔用原生的「要求審查者」欄位。沒有評論可供回應，所以 GitHub 上不會發佈任何內容；審查會在 Control Center 中啟動
在 PR 對話中評論 @myapp review（或只輸入 @myapp）。機械人會以 👀 回應，然後在審查開始時回覆（或告知已有一個正在執行）

審查者會在該 PR 的審查空間中工作；閱讀與發佈發現項的方式與使用 AI 輔助審查相同。發佈回 GitHub 仍然是由你在 Control Center 所作的決定 —— 從 GitHub 啟動審查，本身不會向 GitHub 發佈任何內容。

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

在 PR 對話中評論：

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

依序會發生以下事情：

在尚未有審查的 PR 上提問，會喚醒該工作區的 CEO 代理；一旦審查執行過，則由最後發言的代理回答，所以後續追問會落到掌握上下文的那一位身上。

在機械人參與的行內審查討論串中回覆 —— 它留下的 diff 評論，或它在該討論串中發佈的答案。無需提及；討論串本身就是定址：

> @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` 標籤沒有評論可供回應
答案	以機械人（應用程式）身分發佈，並出現在問題所提出的同一條渠道上
空間內歸屬	問題屬於你；代理代表你執行，並遵循該空間的自主程度設定
審查	發現項會落在審查空間；發佈到 GitHub 則需手動進行

大約一分鐘的延遲，換來的是完全不需要任何入站網絡存取。掃描沒有任何急迫之處，而伺服器離線期間也不會遺失任何東西 —— 停機期間到達的評論會在下一次掃描時被捕捉到。

提及機械人的評論沒有任何反應。

應用程式是否已安裝在擁有該程式庫的帳戶上，而且該程式庫已連結到工作區？未連結的程式庫會在記錄任何東西之前被略過，所以稍後再連結仍然會送達
你的 GitHub 帳戶是否已連結，而你是否是具備寫入角色的成員？請查看 PR 上機械人的拒絕回覆 —— 它會說明是哪一種
仍然沒有反應？當有東西失敗時，伺服器日誌會寫出掃描和 PR；請尋找 pr_conversation:（輪詢器）和 github_pr_conversation:（橋接）

該標籤沒有啟動審查。

它每個 PR 只觸發一次。如果審查已經執行過，或標籤是在伺服器首次看到該 PR 之前加上的（第一次掃描會靜靜記錄積壓項目，而不是向它蜂擁而上），請改為提及機械人 —— 除非已有審查正在進行，否則 @myapp review 一定會啟動一次。

機械人的答案一直沒有出現在 GitHub 上。

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