微軟近期宣布將 GitHub Copilot 的代碼審查功能正式開放給所有 Azure DevOps 客戶，並取消了先前需要申請才能使用的限制。這項舉動背後反映了微軟在產品策略上的重要轉向。長期以來，微軟一直鼓勵企業將代碼庫從 Azure Repos（微軟提供的雲端版本控制系統）遷移到 GitHub，以便利用 GitHub 更強大的 AI 與 Agentic Development（代理開發，指 AI 能自主執行複雜開發任務的模式）體驗。然而，現實情況是許多大型企業受限於組織規模、自定義配置、合規性要求以及產業限制，無法輕易完成遷移。因此，微軟決定採取將 GitHub 的 AI 能力直接移植到 Azure Repos 的策略，讓無法遷移的團隊也能在原有的工作流中獲得 AI 輔助。
核心功能與運作機制
Copilot Code Review 的核心功能是在 Pull Request（PR，拉取請求，開發者請求將代碼合併至主分支的過程）中自動產生審查評論。這項工具不僅能提供建議，還支持高度的自定義化。管理員可以在組織、專案或單一代碼庫層級設定 Onboarding（啟動）控制，並透過自定義指令（Custom Instructions）來定義 AI 審查的標準。這些指令可以應用於整個專案，也可以針對特定的代碼路徑進行精細化設定。
此外，該功能支持透過分支策略（Branch Policies）觸發自動審查。值得注意的是，Copilot 的審查定位為建議性質，它僅會留下評論，而不會直接執行批准（Approve）或要求修改（Request Changes）的操作。這意味著 AI 的審查結果不會滿足企業設定的強制審查者政策，也不會直接阻擋代碼合併，最終的決策權仍留在人類開發者手中。
技術實作與基礎設施限制
在技術底層，Copilot Code Review 運行在 Azure Pipelines 的基礎設施之上。它預設使用組織的預設代理池（Agent Pool），且目前僅支持最新版本的 Ubuntu Server 鏡像，不支持 Windows 鏡像或自託管代理（Self-hosted agents）。
為了確保系統穩定性，微軟設定了明確的併發限制（Concurrency Limits）：每個組織最多 5 個併發審查，每個用戶 2 個，而每個 PR 僅限 1 個。如果組織內有大量團隊同時提交 PR，審查請求將進入排隊狀態。此外，該功能對代碼庫有硬性要求，包括代碼庫大小必須在 10 GB 以下，且單次 PR 變更的文件數不得超過 100 個且不能有合併衝突。另外，舊有的 TFVC（團隊基礎版本控制）系統並不在此支持範圍內。
計費模式與成本管理挑戰
這項功能的計費方式較為特殊，採取按次審查計費。每次完成的審查會根據輸入、輸出以及快取 Token（AI 處理文本的基本單位）的消耗量，轉換為 GitHub AI 積分。PR 的規模越大、自定義指令越複雜，消耗的積分就越多。
在成本監控方面，雖然微軟引入了 Azure DevOps 專案標籤（Project Tags），讓團隊能將成本分攤到具體專案而非僅看到組織總額，但仍存在顯著的延遲問題。所有審查費用會在完成 48 小時後才出現在 Azure Cost Management 帳單中。由於 Azure 的預算設定僅能發出通知而無法強制停止資源使用，這意味著如果一個繁忙的專案啟用了自動審查，可能會在成本數據更新前就已經產生兩天份的費用。
實務意義與潛在限制
對於依賴 Azure DevOps 的企業而言，這項更新大幅降低了導入 AI 審查的門檻，讓開發者無需面對高風險的平台遷移即可提升代碼品質。然而，目前該功能仍處於公開預覽階段（Public Preview），缺乏正式的服務等級協議（SLA）且支持有限。
從實務操作來看，Copilot 的審查目前缺乏對話能力，它不會在提交新代碼後自動重新審查，也不會閱讀人類開發者的回覆或進行後續追蹤。在預覽期間，部分用戶也回報了執行過程中的不穩定現象，例如審查進程在特定階段卡死後被自動取消。因此，微軟建議企業採取漸進式部署，先在少數代碼庫中啟用，監控每日使用量與成本，確認 AI 的建議品質符合預期後，再全面推廣至整個組織。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。