使用 AI 輔助審查

本指南說明如何讓審查代理審查一個 pull request，以及如何把結果發佈到 GitHub。

開始一次 AI 審查

開啟該 PR，前往它的總覽分頁
開啟操作列中的 ⋯ 溢位選單，然後選擇詢問 AI

該項目只在 PR 處於開啟狀態時出現 —— 它是合併前的操作。在檢閱分頁的空狀態上（此時尚未有任何審查），同一個按鈕也會以詢問 AI 的形式提供。

Control Center 會啟動預置的 pr_review 管線，並開啟該 PR 的檢閱分頁，讓你可以看著它執行。管線會：

開啟該 PR 專屬的審查空間，其隔離工作樹已把該 PR 檢出至它的 head
按工作區的檢閱等級派出審查者 —— 預設三個（預置的 qa、architect 和 engineer 代理，同時並行）。系統不會偵測語言或領域
由主導（CEO）代理把他們的發現項匯總成一份走查
收尾：把發現項歸入共識分桶並計算判定。當關聯達到 awaiting approval 時， 發佈到 GitHub 會出現在檢閱分頁上

審查的深入程度由工作區的檢閱等級決定 —— light（一位審查者）、balanced （三位，預設值）或 thorough（全部五位，另加保安與效能專家）—— 在 設定 → 工作區 → 一般的工作區政策卡片上設定。較輕的級別提交的發現項數量完全一樣，只是它一開始放在最顯眼處報告的較少。

所有審查者都發文到該 PR 唯一的審查空間，這正是他們的發現項可以相互比較的原因。各部分如何配合，見 AI 審查。

pr_review 只附帶手動觸發器。要讓它在每個已發佈的 PR 上自動觸發，請自行加入觸發器 —— 見派發審查代理。你也可以直接從 GitHub 啟動一次審查，無需任何管線觸發器：在 PR 上 @ 提及伺服器的機械人，或加上 ai-review 標籤 —— 見從 GitHub PR 與 Control Center 對話。

如果彈出提示說此 pull request 上已經有一次審查正在執行，那就是確有一次仍在進行中；留在檢閱分頁，或開啟管線來找到它。

閱讀發現項

審查者把發現項記錄為審查空間中的審查節點。每個節點包含：

欄位	說明
類型	`bug`、`suggestion`、`recommendation`、`question` 或 `ticket`
優先級	P0（嚴重）→ P3（細微）
類別	`security`、`stability`、`data_integrity`、`correctness`、`performance` 或 `maintainability`
檔案與行號	發現項錨定在何處
原始程式碼	發現項所針對的程式碼
建議程式碼	提議的修正
信心	審查者有多確信
狀態	`open` → `consensus-ready` → `resolved` 或 `dismissed`

只有當一位_同行_審查者確認後，發現項才會到達 consensus-ready。代理無法確認自己提出的發現項，因此單一審查者的意見永遠不會自行升級。

檢閱分頁會顯示發現項清單（可按類型與狀態篩選，並有一個用於顯示已忽略發現項的切換開關），旁邊是匯總代理所發佈的產出物。確定性檢視 —— 群體、多軸儀表板、契約 diff 與視覺 diff —— 在伺服器端計算，但應用程式中沒有對應介面；這一遍會產生什麼，見審查運算。

檢查分歧面板

當兩位審查者把發現項錨定到同一個檔案與行號，但評價相差很大時 —— 優先級相差兩級或以上，或是一個稱之為 bug 而另一個稱之為 suggestion —— 發現項清單上方會出現一個分歧面板。先讀這些：正是在這裡，審查者的意見出現分歧，而你的判斷最有價值。

閱讀判定

當主導代理收尾時，它會計算出一個判定：

判定	含義
Ship	未發現任何阻塞性問題
Hold	有應在合併前處理的問題
Block	有必須修正的嚴重問題

該判定帶有一個總體信心分數，以及按優先級統計的發現項數量。

接著審查軸向會加入其中，而它們只會令判定變得更嚴重。受閘門約束且失敗的軸向會強制給出 Block；受閘門約束、無法完成（partial）或根本無法執行（unavailable）的軸向，至少會強制給出 Hold。證據從缺絕不會讓閘門通過。

把審查發佈到 GitHub

發佈是一個獨立的步驟，且刻意由使用者把關。pr_review 管線會把審查留在 Control Center 裡；它不會發佈到 GitHub。

在檢閱分頁上，等到發佈到 GitHub 出現
按下發佈到 GitHub

Control Center 只會送出一條 GitHub 審查。已經解決或已忽略的發現項會被略過。該按鈕會包含所有仍然未解決的發現項，並且在 Ship 時提交 APPROVE。（MCP 工具 publish_review_to_github 的預設行為仍然是只提交經同行確認的發現項，並且除非你傳入 approve_on_ship，否則不會批准。）帶有檔案與行號錨點的發現項會變成行內評論；其餘一切都歸入摘要正文，每一項都帶有「— Control Center AI review」頁腳，令來源清楚明確。 Block 判定會以 REQUEST_CHANGES 提交；Hold 以 COMMENT 提交；Ship 則由該按鈕以 APPROVE 提交。隨後提示會顯示已發佈。審查會以伺服器的應用程式身分發佈。

如果 GitHub 因為某一行不屬於 diff 而拒絕一個行內錨點，整份審查會重新送出，並把每一項發現項都歸入正文，確保沒有任何東西被悄悄丟棄。

其他內建管線則會直接發佈到 GitHub：cross_review、pr_triage、ticket_to_pr 和 pre_merge_gate 都以一個評論步驟結尾。只有 pr_review 會把它的輸出留給你處理。

自行派發審查者

如果你想控制由哪些角色審查該 PR，以及每個角色檢視哪些檔案，請在現有的審查空間中使用 dispatch_reviewers MCP 工具，或向管線加入審查者節點。兩條路徑，以及該工具的確切簽名，都見於派發審查代理。