GitHub Copilot 與私有程式碼助手的比較

過去一個月，我和三個不同的團隊進行了同樣的對話。每一次都以相同的方式開始：有人在群組裡轉發了 4 月 24 日的 GitHub Copilot 政策更新，一個沉寂了一年的 Slack 討論串突然活了過來。我們還該繼續用 Copilot 嗎？該換掉嗎？該自行部署嗎？「私密」在這個領域究竟代表什麼？

我是 Dora。幾週前我寫過這次政策變更本身——改變了什麼、哪些人豁免、哪些團隊應該重新審視。這篇文章要回答的是下一個問題：審視過你的 Copilot 設定之後，你究竟如何在繼續使用託管助手和轉向私有或自架方案之間做出決定？我不會告訴你該選哪個，而是要列出我觀察到各個團隊所使用的決策標準，以及每個標準在哪裡悄悄失效。

這不是一份企業採購指南。我是工具使用者，不是資安長。但「託管 vs. 私有」已經不再是抽象議題——它每週都出現在開發者的工作流程決策中。

團隊現在考慮的兩個方向

目前有兩個陣營，沒有哪個是錯的，它們各自針對不同的目標做最佳化。

繼續使用 Copilot 並搭配政策控管

第一個陣營認為：Copilot Business 或 Copilot Enterprise 已經解決了資料疑慮。4 月 24 日的變更只適用於 Copilot Free、Pro 和 Pro+——也就是個人方案。根據 GitHub 的 Copilot 方案文件，GitHub 不會使用 Copilot Business 或 Copilot Enterprise 的資料來訓練模型，這項契約承諾在 4 月 24 日之前成立，現在依然成立。如果你的團隊使用的是 Business 或 Enterprise 席位，這次政策更新並不會改變你的資料曝險狀況，而是改變了你對公司電腦上個人帳號的謹慎程度。

這個陣營正在獲得更多佐證。GitHub 最近推出了美國和歐盟地區的資料駐留以及 FedRAMP 授權模型，管理員可以在 Copilot 設定中將組織限制為僅使用資料駐留或 FedRAMP 合規的模型。如果你的疑慮是「推論在哪裡執行」而非「我的程式碼是否在訓練別人」，這個功能很實用。

論點很直接。Copilot 擁有深度的 IDE 整合、最大的使用者基礎，以及強大的多檔案情境理解能力。切換成本是真實存在的。如果風險已在契約層面解決，為什麼要搞亂你的技術棧？

轉向私有或自架的程式碼助手

第二個陣營不把契約視為最終答案。他們的問題是結構性的：即便在 Copilot Business 上，推論仍然在微軟的基礎架構上執行，模型由第三方操作，資料流由一份可以再次更新的廠商政策所規範。在他們看來，4 月 24 日的變更正是政策會改變的證據。

因此他們考慮私有部署，有幾種選擇：

廠商託管的私有部署 — Tabnine 和 Codeium 等助手提供 VPC、地端或氣隙部署，讓模型在你的基礎架構內執行。受監管產業的大多數企業客戶選擇這條路。
開源助手搭配自架模型 — 例如 Continue.dev 加上 Ollama 加上專為程式碼優化的開放權重模型。Continue 不綁定單一 AI 提供者，支援完全在自有硬體上執行的本地模型。
透過企業平台的自帶模型設定，讓你將助手指向自己的 LLM 端點。

這裡的假設不是「Copilot 不好」，而是「長期的治理姿態不應依賴單一廠商的契約文字」。

真正的決策標準

這是我觀察到大多數團隊卡住的地方。他們以「託管 vs. 私有」開始討論，最後卻沒有做出決定，因為問題框架本身就錯了。真正的決策落在兩個問題上，而這兩個問題在成為資安問題之前，首先是工作流程問題。

資料治理與合規

把你的程式碼分成三個桶，而不是兩個：

廠商訓練完全不是問題的程式碼（開源貢獻、行銷網站程式碼、開發工具）。
有專利保護但未受監管的程式碼（內部工具、大多數公司的大多數產品程式碼）。
涉及受監管資料流的程式碼（金融、醫療、國防、公部門——任何有明確資料處理規則的領域）。

第一桶在任何方案上都沒問題。第三桶早在 4 月 24 日之前就已促使團隊轉向企業合約。模糊地帶在第二桶——而且對大多數團隊來說，這是最大的桶。

對於第二桶，問題在於契約豁免是否足夠。最低標準：要求 Business 或 Enterprise 方案，並在你的 AI 可接受使用政策中記錄這項要求。是否進一步採用私有部署，取決於你的稽核人員、法務團隊或企業客戶要求你證明什麼。如果「我們用的是 Copilot Business，這是契約條款」是利益關係人接受的答案，你大概沒問題。如果他們問「那推論在哪裡執行」，你面對的就是另一種對話了。

開發者體驗與維護成本

這是「自建 vs. 購買」的爭論通常會跳過的部分，卻是決定你的選擇能否撐過六個月的關鍵。

託管助手在這裡有真正的優勢。Copilot 會更新模型、推出新功能，並吸收你看不到的基礎架構工作。大多數開發者調查顯示 AI 工具的採用率超過 70%——而大多數這些工作流程都使用託管工具，因為託管工具對開發者來說不需要任何持續的運維工作。

自架助手則完全相反。Continue.dev 加上 Ollama 加上程式碼專用模型是我見過效果不錯的工作流程——但它需要團隊中有人負責模型選擇、GPU 或硬體預算、版本更新，以及本地模型能力與前沿託管模型之間的差距。這個差距是真實存在的。本地模型已經縮短了很多距離，但在複雜的多檔案推理方面，前沿託管模型仍然領先。

廠商託管的私有部署則折衷兩者。你能獲得自架的隱私姿態，加上廠商持續的模型更新，代價是更高的席位定價和更多的前期採購工作。對受監管產業的團隊來說，這是許多人願意做的交換。對非受監管產業的團隊來說，通常不值得。

當團隊請我比較各個選項時，我持續回頭審視的五個維度：

感知速度 — 你實際打字時建議出現的速度
工作流程契合度 — 與你已在使用的 IDE、程式碼庫和審查流程整合的程度
模型覆蓋範圍 vs. 選擇成本 — 是否提供模型選擇，以及選擇是否帶來評估開銷
成本可預測性 — 固定席位費、按用量計費還是自架基礎架構成本
大規模效能 — 當十個開發者同時使用，或程式碼庫超過某個規模時會發生什麼

前三點，託管工具預設勝出。私有部署在使用量穩定的情況下，於成本可預測性上勝出。大規模效能則完全取決於部署方式。

Copilot 仍然合適以及不再合適的情況

這一部分我必須誠實說明 Copilot 的邊界，以及我自身觀察的邊界。

Copilot 仍然合適的情況：當你的團隊使用 Business 或 Enterprise 方案，且程式碼屬於第一桶或第二桶；當你的稽核人員和客戶接受契約資料承諾為充分依據；當你的開發者深度整合在 GitHub 生態系統中，而 Copilot 從程式碼庫、Pull Request 和 Issue 中汲取的情境至關重要；以及當你沒有足夠人力或意願去運維模型基礎架構。

Copilot 不再合適的情況：當你的程式碼屬於第三桶，且合規框架要求可證明的資料隔離；當你的企業客戶在合約中要求其資料不得通過第三方 AI 推論，而你的程式碼涉及其資料；或者當你已因其他原因投資了私有模型基礎架構，額外增加程式碼助手是漸進式而非全新的工作。

我不會告訴你哪個方向代表未來，哪個不是。大多數開發者最終使用 2-3 個工具——常見的組合是一個重型代理、一個行內補全工具和一個具彈性的開源選項。「託管 vs. 私有」在團隊層面愈來愈是一個錯誤的二元對立。許多團隊兩者都用，針對不同的程式碼路徑，以不同的工具受不同的政策管轄。

常見問題

每個團隊現在都需要私有程式碼助手嗎？

不需要。4 月 24 日的政策變更影響的是個人 Copilot 方案。如果你的團隊使用 Business 或 Enterprise 方案，且程式碼不屬於受監管類別，契約豁免與之前相同。應該認真評估私有部署的團隊，是那些「你的稽核人員或企業客戶要求什麼」這個問題的答案已經超出契約文字範疇的團隊。

自架的取捨是什麼？

三個真實的取捨。模型品質——本地開放權重模型已縮小了很大差距，但在複雜推理方面仍落後前沿託管模型。運維成本——必須有人負責基礎架構、模型選擇和更新。硬體——在可接受速度下進行本地推論需要像樣的 GPU。

優勢也是真實的：零資料外洩、大規模使用下成本可預測、完全控制團隊使用的模型。

團隊應如何比較治理與速度？

不要抽象地比較，而是針對特定的程式碼路徑來比較。「我們的開發者可以在行銷網站程式碼庫上使用託管助手嗎」和「我們的開發者可以在支付服務上使用託管助手嗎」是不同的問題。我見過的大多數團隊最終採取差異化政策——在大多數程式碼庫上允許使用託管助手，在特定的敏感程式碼庫清單上使用私有部署或不使用 AI 輔助。比單一政策更難設定，但對風險在程式碼庫中的實際分布更誠實。

什麼情況應該觸發重新評估工具選擇？

我會關注三個信號。廠商政策變更，實質影響你的資料曝險——4 月 24 日就是一個例子。新的合規義務——SOC 2 稽核、客戶合約條款、區域資料保護規定。團隊內部的工作流程變化——工程師從五人增加到二十五人，使託管按席位定價與自架基礎架構之間的成本動態發生翻轉。

如果上述情況都沒有發生，你現有的決定可能仍然有效。

結論

「GitHub Copilot vs. 私有程式碼助手」這個問題，誠實的答案是它沒有唯一答案。每當某些事情改變——你的程式碼、你的客戶、廠商的政策、你的團隊規模——你就要重新問這個問題。4 月 24 日的政策變更讓這個問題感覺緊迫，但對大多數團隊來說並不是。它只是提醒我們，這個決定從來就不是永久的。

我繼續使用混合方案：大多數工作使用託管方案，不想離開我電腦的程式碼使用本地方案，在一個客戶合約要求的團隊環境中使用廠商托管的私有部署。這是一個可行的設定，不是一個建議。如果你有不同的程式碼組合或不同的義務，適合你的正確答案會看起來不同。

我的資料到此為止，請自行進行稽核。我幾週前寫的政策審查是一個合理的起點，之後的決定由你來做。

待續。

往期文章：