使用 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。代理無法確認自己的發現，因此單一審查者的意見永遠不會自行晉級。

檢閱分頁會顯示發現清單，可依種類與狀態篩選，並有一個用於已略過發現的切換開關，就在彙整代理所發佈的產物旁。確定性檢視 — 群組、多軸儀表板、合約與視覺差異 — 在伺服器端計算，但應用程式中沒有對應介面；這一輪會產生什麼，請見審查運算。

檢查分歧面板

當兩位審查者把發現錨定到同一個檔案與行號，但評價相差很大時 — 優先順序相差兩級以上，或是一方稱之為 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 因為某一行不屬於差異的一部分而拒絕某個行內錨點，整筆審查會重新送出，並把每一項發現都收進內文，確保沒有任何東西被悄悄丟掉。

其他內建管線則會直接貼到 GitHub：cross_review、pr_triage、ticket_to_pr 與 pre_merge_gate 都以一個留言步驟作結。只有 pr_review 會把輸出留下來交給你。

自行派送審查者

如果你想控制由哪些角色審查該 PR，以及每一個角色查看哪些檔案，請在既有的審查空間中使用 dispatch_reviewers MCP 工具，或將審查者節點加入管線。兩條路徑，以及該工具的確切簽章，都在派送審查代理。