GitHub Copilot 統計數據.

GitHub Copilot 是少數幾個在三個有用層面擁有公開數據的 AI 編碼產品：廣泛用戶、付費訂閱者和組織。微軟表示，Copilot 在 26 財年第一季度擁有超過 2600 萬用戶，在 26 財年第二季度擁有超過 470 萬付費訂閱者，在 26 財年第三季度有近 14 萬個組織使用 Copilot。

這些數字使 Copilot 成為 AI 編碼領域最清晰的公開商業錨點，但它們也製造了一個容易的陷阱。Copilot 用戶不自動等於每月活躍用戶。付費訂閱者不等於一個組織。組織數量並未揭示每天有多少開發人員使用 Copilot。GitHub 的 超過 1.8 億開發人員 和 超過 5 億次合併的拉取請求 是強大的分發背景，但它們是 GitHub 平台指標，而不是 Copilot 使用指標。

2026 年的真實故事是，Copilot 已從 AI 結對程式設計師轉變為開發人員工作流程層。它現在涵蓋 IDE 完成、聊天、拉取請求、程式碼審查、CLI、雲端代理、Agent HQ、第三方代理、模型選擇、MCP、使用遙測和 基於使用量的計費。這使得 Copilot 統計數據只有在分母明確時才有用。

GitHub Copilot 的規模

Copilot 的主要數字使用不同的分母，因此應將它們視為獨立的用戶、訂閱者和組織信號，而不是一個單一數字。

三個容易混淆的數字

閱讀 GitHub Copilot 統計數據最安全的方法是將其視為一個階梯。最頂端是微軟聲稱的 超過 2600 萬用戶，這是最廣泛的公開 Copilot 規模信號。這個數字應被引用為公司報告的用戶數字，而不是每月活躍用戶、每日活躍用戶或付費用戶，除非微軟如此定義。GitHub 發言人此前向 TechCrunch 澄清，早期的 2000 萬 Copilot 數字指的是歷史總用戶數，這是一個有用的提醒，要保守地使用用戶措辭。

下一個階梯是付費採用。微軟的 超過 470 萬付費 Copilot 訂閱者 在商業上比廣泛的用戶規模更有意義，因為它反映了付費席位或訂閱，微軟還給出了 75% 的同比增長率。但付費訂閱者仍然沒有揭示每日活躍使用、接受的建議、拉取請求結果、安全影響或團隊層面的價值。

組織覆蓋範圍位於另一個階梯。微軟的 近 14 萬個組織 數字顯示 Copilot 在組織帳戶中廣泛部署，同一個 26 財年第三季度電話會議表示企業訂閱者同比幾乎翻了三倍。這與 14 萬個具有相同部署深度的企業客戶不同。一個組織可能只有一個小型試點；另一個組織可能有數萬名開發人員。

內部使用指標是另一個類別。GitHub 自己的 使用指標文件 將 Copilot 指標分為採用、參與度、接受率、程式碼行數和拉取請求生命週期指標。在 協調文件 中，如果用戶發起的互動計數大於零，則該用戶被視為活躍用戶，程式碼完成接受率是接受的程式碼活動除以生成的程式碼活動。

這個定義很有價值，因為它防止了草率的說法。企業儀表板中的 Copilot 活躍用戶與微軟公開的 2600 萬用戶數字不同。接受率不等於生產力。程式碼行數是方向性輸出，而不是經過審查和發布的軟體；GitHub 的 程式碼行數文件 明確將這些指標框定為跨完成、聊天和代理功能的建議、添加和刪除行數的方向性衡量。

調查採用屬於另一個階梯。JetBrains 表示，在其 2026 年 1 月的調查中，29% 的專業開發人員 在工作中使用了 GitHub Copilot，而 Stack Overflow 表示 50.6% 的專業開發人員 每天使用 AI 工具。這些是有用的工作流程信號，但調查採用不是 Copilot 市場份額，不應與微軟的產品遙測數據混合。

Copilot 規模：用戶、付費訂閱者和組織

GitHub Copilot 的規模故事始於微軟 26 財年第一季度的聲明：Copilot 是「最受歡迎的 AI 結對程式設計師」，擁有 超過 2600 萬用戶。這是一個針對具名 AI 編碼產品的龐大公開數字。它也比付費指標更廣泛，這就是為什麼謹慎措辭很重要的原因。將其視為公司報告的用戶規模，除非後來的微軟或 GitHub 來源將其定義為活躍使用。

廣泛用戶數字隨著時間的推移而增加。2025 年 7 月，GitHub 發言人告訴 TechCrunch，Copilot 的歷史總用戶數已超過 2000 萬；到 26 財年第一季度電話會議時，微軟引用了超過 2600 萬用戶。兩者都是廣泛覆蓋的數字，而不是活躍或付費計數，因此趨勢是規模信號而不是參與度信號。

付費指標更清晰。在 26 財年第二季度，微軟表示 GitHub Copilot 擁有超過 470 萬付費訂閱者，同比增長 75% (微軟 26 財年第二季度)。微軟還表示，個人開發人員的 Copilot Pro+ 訂閱環比增長 77%，顯示出更高使用量的個人層級的增長，而不僅僅是企業採購。

組織指標顯示了 Copilot 在團隊中的傳播程度。在 26 財年第三季度，微軟表示 近 14 萬個組織 使用了 GitHub Copilot，並且企業訂閱者同比幾乎翻了三倍。這是最好的公開證據，證明 Copilot 不僅僅是個人開發人員的附加組件。它已成為組織層面的軟體採購。

儘管如此，組織數量仍需注意。它沒有說明一個組織有五個席位還是五萬個席位。它沒有披露活躍使用、接受的程式碼或生產結果。除非來源使用確切的客戶分母，否則也不應將其改寫為「客戶」。 「使用 Copilot 的組織」已經足夠強大，無需誇大。

具名的企業案例有助於鞏固規模。微軟表示，西門子在成功向 3 萬名開發人員 推出 Copilot 後，全面採用了 GitHub。微軟還表示，數萬名 AMD 開發人員使用 Copilot，每月接受數十萬行程式碼建議 (微軟 26 財年第一季度)。這些都是有用的證明點，但它們是具名案例，而不是 14 萬個組織的平均值。

GitHub 平台背景：開發人員、拉取請求和分發

Copilot 的分發優勢來自 GitHub 的平台基礎。微軟表示，GitHub 擁有 超過 1.8 億開發人員，正以歷史上最快的速度增長，並且每秒增加一名開發人員。這不是 Copilot 用戶數，但它解釋了為什麼 Copilot 可以通過 GitHub 帳戶、儲存庫、拉取請求、Actions、問題和 IDE 整合接觸開發人員。

最有趣的入門統計數據是微軟聲稱 80% 的新 GitHub 開發人員在第一週內開始使用 Copilot。這是一個分發和激活信號。它表明 Copilot 在 GitHub 旅程的早期就已嵌入。它沒有說明這些開發人員中有多少成為留存的活躍用戶或付費訂閱者。

拉取請求活動是另一個有用的分母。微軟表示，超過 5 億次拉取請求 在過去一年中在 GitHub 上合併，因為 AI 編碼代理推動了創紀錄的使用量。這個數字很重要，因為 Copilot 的代理功能越來越多地以拉取請求、審查和分支結束。除非 GitHub 發布更窄的指標，否則它仍不應被框定為 Copilot 創建的 PR。

GitHub 在 2026 年計費轉變之前讓 Copilot 更容易試用。2024 年 12 月，GitHub 宣布在 VS Code 中推出免費的 Copilot 層級，並表示 GitHub 已擁有超過 1.5 億開發人員；該免費層級在推出時為登錄的個人 GitHub 用戶每月提供 2000 次程式碼完成和 50 條聊天訊息 (VS Code 中的 GitHub 免費 Copilot)。目前的 GitHub 文件 現在將 Copilot Free 列為沒有組織或企業訪問權限的個人開發人員的計劃，具有有限的 Copilot 功能和自動模型選擇。

GitHub 的開源和教育計劃對於分發也很重要。Octoverse 2024 表示，超過 100 萬 開源維護者、經過驗證的學生和教師免費使用了 Copilot，該免費計劃在 2024 年增加了 100%。這與付費採用不同，但它解釋了為什麼 Copilot 可以在學生、維護者和新開發人員中傳播，然後才進行付費購買。

產品介面：從內聯建議到 Agent HQ

GitHub Copilot 在公眾想像中最初是作為自動完成工具出現的，但目前的 GitHub 文件描述了一個更廣泛的產品。官方的 功能頁面 列出了 Copilot Chat、內聯建議、拉取請求摘要、GitHub Desktop 提交訊息、Copilot CLI、Copilot 雲端代理、第三方編碼代理、Copilot 程式碼審查和 IDE 中的代理模式。

內聯建議仍然很重要，因為它們是摩擦最小的介面。GitHub 文件表示 Copilot 為許多語言和框架提供建議，尤其適用於 Python、JavaScript、TypeScript、Ruby、Go、C# 和 C++ (GitHub 程式碼建議)。但該產品不再僅限於編輯器中的幽靈文本。

根據 GitHub 文件，Copilot Chat 現在出現在 GitHub、受支持的 IDE、GitHub Mobile 和 Windows Terminal 中。Copilot CLI 允許開發人員從終端工作並在本地工具、GitHub.com 或移動設備之間移動會話 (GitHub 功能)。微軟表示，Copilot CLI 的使用量在 26 財年第三季度環比幾乎翻倍，這使得 CLI 成為少數具有公開增長信號的 Copilot 介面之一 (微軟 26 財年第三季度)。

Copilot 雲端代理將 Copilot 轉變為非同步工作。GitHub 的文件將其描述為一個自主 AI 代理，可以研究儲存庫、創建實施計劃、在分支上進行程式碼更改並打開拉取請求以供審查。雲端代理的 起始頁面 顯示了入口點變得多麼廣泛：GitHub 問題和儀表板、GitHub Mobile、IDE、REST API、GitHub CLI、GitHub MCP Server、Jira、Slack、Microsoft Teams、Azure Boards、Linear 和 Raycast。

Agent HQ 是戰略層。GitHub 在 Universe 2025 上推出了 Agent HQ，作為協調開發人員工作中代理的單一工作流程。微軟的 26 財年第一季度記錄稱 Agent HQ 是協調來自 OpenAI、Anthropic、Google、Cognition、xAI、開源模型和內部模型的編碼代理的組織層，圍繞 GitHub 原語（如 PR、問題和 Actions）構建。

功能矩陣顯示了為什麼產品介面統計數據需要日期標籤。GitHub 列出了對 VS Code、Visual Studio、JetBrains、Eclipse、Xcode 和 NeoVim 的支持，但並非所有功能都適用於每個客戶端；功能矩陣 將某些功能標記為預覽，並指出該頁面本身處於公開預覽狀態。例如，程式碼完成得到廣泛支持，而高級代理技能、BYOK、自定義代理、視覺和工作區索引則因 IDE 和版本而異。

該平台也正在向其他代理開放。GitHub Agentic Workflows 支持 GitHub Copilot、Anthropic Claude、OpenAI Codex 和 Google Gemini 引擎，如果未指定引擎，則 Copilot 為默認引擎。這使得 Copilot 既是產品又是多個編碼代理的工作流程層。

定價和計費：2026 年 6 月 1 日的轉變

2026 年 Copilot 商業模式最重要的變化是轉向基於使用量的計費。GitHub 宣布所有 Copilot 計劃將於 2026 年 6 月 1 日過渡，將高級請求替換為 GitHub AI 積分，並根據模型費率計算輸入、輸出和緩存令牌的使用量 (GitHub 計費公告)。GitHub 的舊版 計費變更文件 更直接地說明了相同的變化：在 2026 年 6 月 1 日之前，計費是基於高級請求的；在 2026 年 6 月 1 日之後，互動成本取決於模型和令牌計數。

目前的個人計劃文件列出了三個付費個人層級。Copilot Pro 每月 10 美元，總計每月 1,500 個 AI 積分；Copilot Pro+ 每月 39 美元，總計每月 7,000 個 AI 積分；Copilot Max 每月 100 美元，總計每月 20,000 個 AI 積分 (GitHub 個人計劃)。根據相同的當前頁面，Copilot Free 每月包括 2,000 次程式碼完成，而 Copilot Student 包括無限次完成。

組織定價是基於席位加上基於使用量的。GitHub 文件列出 Copilot Business 每用戶每月 19 美元，包括每用戶 1,900 個 AI 積分，以及 Copilot Enterprise 每用戶每月 39 美元，包括 GitHub Enterprise Cloud 的每用戶 3,900 個 AI 積分 (GitHub 組織計費)。超出包含池的使用量按每個 AI 積分 0.01 美元收費，並且付費計劃在當前文件中保持程式碼完成和下一個編輯建議無限。

這改變了工程領導者對 Copilot 經濟學的看法。在基於使用量的計費之前，團隊通常主要考慮席位和請求配額。轉變之後，模型選擇、令牌量、代理工作流程、程式碼審查以及 CLI/雲端代理活動都變得與成本相關。微軟在 26 財年第三季度明確表示，GitHub 正在轉向基於使用量的定價，以使定價與使用量和成本保持一致 (微軟 26 財年第三季度)。

程式碼審查是一個很好的例子。GitHub 文件表示 Copilot 程式碼審查有兩個成本組件：模型互動的 AI 積分和用於代理上下文收集和工具使用的 GitHub Actions 分鐘數 (GitHub 程式碼審查文件)。GitHub 的計費公告還表示，Copilot 程式碼審查除了 AI 積分外，還將消耗 GitHub Actions 分鐘數。

模型選擇與企業 AI 控制

Copilot 不再被最好地理解為單一模型編碼助手。微軟在 26 財年第三季度表示，大多數 Copilot 用戶利用多個模型。GitHub 文件還顯示，模型可用性取決於計劃、客戶端以及組織或企業限制 (配置模型訪問)。

模型託管是企業關注的問題。GitHub 文件描述了不同模型系列的託管方式。對於 Google 模型，GitHub 表示提示和元數據根據 Google 的數據承諾發送到 Google Cloud Platform；對於微軟的 MAI-Code-1-Flash，模型託管在 GitHub 租戶的 Azure 上；對於開源模型，GitHub 表示它們託管在由 GitHub 和微軟管理的美國 Azure AI Foundry 基礎設施上，並且提示和響應不會發送給原始模型開發人員 (GitHub 模型託管)。

GitHub 為企業增加了穩定性概念。2026 年 3 月 18 日，GitHub 將 GPT-5.3-Codex 指定為 Copilot Business 和 Copilot Enterprise 的基礎模型和長期支持模型，LTS 支持從指定之日起持續一年 (基礎和 LTS 模型)。這很重要，因為企業需要的不是最新的模型；他們需要可預測的可用性、遷移窗口和管理控制。

模型目錄變化很快。GitHub 於 2026 年 6 月宣布為 Copilot 推出 MAI-Code-1-Flash，並於 2026 年 6 月 26 日 將其普遍提供給 Copilot Business 和 Copilot Enterprise。相同的更新系列顯示了為什麼 Copilot 統計數據中的模型事實需要確切的日期。

自帶密鑰支持增加了另一個治理層。GitHub 的企業 BYOK 文件 列出了來自 Anthropic、AWS Bedrock、Google AI Studio、Microsoft Foundry、OpenAI、OpenAI 兼容提供商和 xAI 的受支持提供商密鑰，同時警告微調模型功能和輸出質量可能有所不同。GitHub 的 MCP 文件 還將模型上下文協議定位為一種通過主要 Copilot 介面（包括 IDE、CLI、Copilot 應用程式和 GitHub.com 代理委託）擴展 Copilot 與現有工具和服務的方式。

企業控制不僅僅是關於模型。內容排除 允許組織配置 Copilot 應忽略的文件；排除的內容不會影響內聯建議、聊天響應或 Copilot 程式碼審查。程式碼引用檢查建議是否與公開可用的程式碼匹配，並可以根據策略設置丟棄匹配或顯示引用 (GitHub 程式碼建議)。

治理模式很明確：Copilot 2026 年的產品統計數據不僅僅是關於有多少人使用它。它們還關於啟用哪些模型、如何計費、允許哪些上下文、如何引用建議以及團隊如何衡量模型和功能的使用。

Copilot 使用指標：團隊實際可以衡量什麼

Copilot 的公開採用數字對於市場背景很有用。企業領導者在推出後需要一套不同的指標。GitHub 的 使用指標文件 表示 Copilot 指標分為採用、參與度、接受率、程式碼行數和拉取請求生命週期指標。

採用回答了獲得許可的開發人員是否活躍使用 Copilot。GitHub 的指標文件將每日活躍用戶定義為在特定日期與 Copilot 互動的唯一用戶，協調文件將活躍用戶狀態與用戶發起的互動計數大於零相關聯 (指標協調)。在評估推出是否活躍時，團隊應優先選擇這個數字而不是「分配的許可證」。

參與度顯示使用深度。GitHub 表示，參與度指標包括跨功能的頻率和廣度，例如每個活躍用戶的平均聊天請求數。接受率衡量開發人員接受建議的頻率，並在儀表板和 API/導出字段中一致計算。它可以表示相關性，但高接受率不自動意味著高質量軟體。

程式碼行數指標特別容易被誤用。GitHub 表示 程式碼行數指標 是 Copilot 輸出的方向性衡量，量化了跨完成、聊天和代理功能的建議、添加或刪除行數。方向性輸出很有用，但它與合併、測試、安全或可維護的程式碼不同。

拉取請求生命週期指標使 Copilot 更接近交付結果。GitHub 表示，這些指標包括拉取請求創建和合併計數、合併的中位時間以及審查建議活動，允許團隊將整體拉取請求活動與 Copilot 創建的拉取請求進行比較。這是 Copilot 不僅僅是程式碼生成工具的層面：團隊可以研究 AI 輔助工作流程是否改變了吞吐量和週期時間。

指標產品在 2026 年變得更具操作性。GitHub 宣布 Copilot 使用指標於 2026 年 2 月 27 日 正式推出，具有儀表板和 API 訪問、組織級別可見性、細粒度訪問控制和數據駐留支持。GitHub 隨後於 2026 年 3 月 2 日添加了 計劃模式遙測，並於 2026 年 3 月 20 日為自動模型選擇添加了 模型級別解析。

團隊級別報告是另一個重要的里程碑。2026 年 5 月 14 日，GitHub 宣布了一份 用戶團隊報告，可以與每個用戶的使用報告結合使用，以生成團隊級別的 Copilot 指標，包括活躍用戶、完成、聊天、語言、IDE、功能和模型細分。需要操作上重要的注意事項：少於五個 Copilot 席位用戶的團隊將被排除，並且屬於多個團隊的用戶可以在每個團隊聚合中計數，因此團隊總數不能相加以重現組織總數。

生產力、安全性和治理

最常被引用的 Copilot 生產力統計數據是 GitHub 的受控任務研究。使用 Copilot 的開發人員完成 JavaScript HTTP 伺服器任務的速度快了 55%，平均耗時 1 小時 11 分鐘，而沒有 Copilot 的開發人員則耗時 2 小時 41 分鐘；GitHub 報告了統計顯著性，95% 的置信區間為 21% 到 89% (GitHub 生產力研究)。這是一個針對特定任務設定的有力證據。

同樣的研究不應成為所有開發人員都快 55% 的普遍說法。GitHub 的研究頁面本身討論了為什麼開發人員生產力難以衡量，並使用了更廣泛的生產力框架，包括滿意度、績效、活動、溝通和效率。更安全的說法是，Copilot 可以顯著加快某些任務並改善流程，而團隊層面的結果取決於任務類型、程式碼庫、審查、測試和部署系統。

更廣泛的 AI 開發研究證實了這種複雜的情況。Google 的 DORA 2025 摘要 表示，90% 的軟體開發專業人員在工作中使用 AI，每天平均花費兩小時使用 AI；65% 嚴重依賴 AI 進行軟體開發；超過 80% 報告生產力提高；59% 報告對程式碼品質有積極影響。但 DORA 也報告了一個信任悖論：只有 24% 報告對 AI 有很多或極大的信任，而 30% 報告很少或沒有信任。

METR 是最有用的對照，因為它衡量的是任務時間，而不僅僅是自我報告的生產力。在 2025 年的一項隨機對照試驗中，在成熟儲存庫上工作的經驗豐富的開源開發人員在使用 2025 年初的 AI 工具時，耗時多 19%，儘管他們預計 AI 會使他們的速度提高 24%，後來又認為 AI 使他們的速度提高了 20%。METR 後來表示其 2025 年初的結果 已過時，並改變了實驗設計，因為較新的 AI 代理使用模式使測量更加困難。這個教訓並不是說 Copilot 會減慢團隊的速度。這個教訓是生產力取決於工作。

治理是 Copilot 代理未來運作的關鍵。GitLab 2026 年的 AI 責任調查 表示，85% 的受訪者同意 AI 將瓶頸從程式碼編寫轉移到審查和驗證，92% 報告 AI 生成程式碼存在一些治理挑戰，80% 同意他們的組織採用 AI 工具的速度快於制定治理政策的速度。這不是針對 Copilot 的調查，但它解釋了 Copilot 買家所處的環境。

GitHub 自己的雲端代理 風險文件 直言不諱地說明了為什麼需要控制。Copilot 雲端代理可以推送程式碼更改，因此 GitHub 表示它通過限制誰可以觸發代理、限制它可以推送到的分支、在合併前要求人工審查、在批准前限制工作流程運行以及在某些受保護的工作流程中阻止請求者批准生成的拉取請求來降低風險。GitHub 還表示，Copilot 雲端代理使用 CodeQL，根據 GitHub Advisory Database 檢查新依賴項，使用秘密掃描，並在會話日誌中記錄分析詳細信息。

負責任使用文件增加了人性化的一面。GitHub 的 Copilot Chat 負責任使用卡 警告說，生成的程式碼可能不準確、偏向某些語言或風格、與公共程式碼匹配，或者如果沒有仔細審查，可能會暴露安全漏洞。早期的學術研究發現 AI 輔助編碼存在具體風險：「鍵盤上睡著了？」在 89 個場景中生成了 1,689 個程式，發現在該設置中約有 40% 存在漏洞 (arXiv 2108.09293)，而 2022/2023 年的一項用戶研究發現，可以使用 AI 程式碼助手的參與者編寫的程式碼安全性顯著降低，並且更有可能認為他們的程式碼是安全的 (arXiv 2211.03622)。這些論文應被視為歷史安全證據，而不是當前 Copilot 漏洞率。

基準測試應得到同樣謹慎的對待。SWE-bench Verified 是一個經過人工驗證的 500 個軟體工程任務子集，用於評估編碼代理和語言模型。它對於理解能力進展很有用，特別是隨著 Copilot 變得更具代理性。它不是活躍用戶、付費訂閱者、組織數量或生產質量的證據。

市場背景：AI 編碼工具堆棧中的 Copilot

開發人員調查顯示了 Copilot 除了微軟收益之外的重要性。JetBrains 2026 年 1 月的 AI Pulse 調查 涵蓋了全球 10,000 多名專業開發人員，發現 90% 的人經常在工作中至少使用一種 AI 工具進行編碼和開發任務。它還發現 74% 的人採用了專門的開發人員 AI 工具，例如編碼助手、編輯器或代理，而不僅僅是通用聊天機器人。

在該調查中，GitHub Copilot 仍然是最廣為人知和採用的 AI 編碼工具：全球 76% 的認知度和 29% 的工作使用率。JetBrains 還表示，在擁有 5,000 多名員工的公司中，Copilot 的採用率達到 40%，而 Cursor 和 Claude Code 的整體工作使用率均達到 18% (JetBrains AI Pulse)。

這並不意味著 Copilot 擁有 29% 的市場份額。這意味著在該調查中，29% 的受訪專業開發人員在工作中使用了 Copilot。這個數字仍然很有價值，因為它支持了 Copilot 在實際工作中很常見，而不僅僅是廣為人知的說法。

Stack Overflow 提供了更廣泛的開發人員情緒背景。在其 2025 年 AI 部分中，Stack Overflow 報告稱，84% 的受訪者使用或計劃在開發過程中使用 AI 工具，50.6% 的專業開發人員每天使用 AI 工具 (Stack Overflow 2025)。但 Stack Overflow 也報告稱，不信任 AI 輸出準確性的開發人員多於信任的開發人員，46% 不信任準確性，只有 33% 信任。高採用率和低信任度可以並存。

這種緊張關係符合 Copilot 的產品方向。Copilot 不僅僅是為了生成更多程式碼。它正在添加程式碼審查、使用指標、模型治理、內容排除、程式碼引用、代理日誌、安全輸出和工作流程控制。該產品正在響應調查顯示的相同市場現實：開發人員需要 AI 幫助，但團隊需要信任、可追溯性和成本控制。

為什麼這對工程領導者和運營商很重要

對於創始人來說，Copilot 驗證了付費 AI 開發人員工具市場。一個擁有 2600 萬+ 用戶、470 萬+ 付費訂閱者和近 14 萬個組織的產品不再是新奇事物。但它也削弱了通用的「AI 編碼助手」定位。競爭或相關產品需要解決更狹窄的痛點：程式碼庫上下文、遷移、審查自動化、測試、依賴項升級、安全分類、模型治理、成本管理、發布工作流程或代理協調。

對於技術 GTM 團隊來說，最清晰的 Copilot 訊息不是「AI 編寫程式碼」。開發人員已經知道這一點。更有用的訊息是，AI 輔助開發正在從個人程式碼生成轉向受控軟體交付。Copilot 自己的產品路線圖指向了這一點：程式碼審查、雲端代理、Agent HQ、使用指標、模型控制、內容排除和安全代理工作流程。

這些數字證明了什麼和沒有證明什麼

缺失的數字與已發布的數字同樣重要。GitHub 和微軟發布了用戶規模、付費訂閱者、組織數量和平台背景，但他們沒有發布清晰的每日活躍 Copilot 數字、付費收入的渠道劃分或每個組織的平均席位數。

將 Copilot 的數字置於背景中

使用微軟投資者記錄來獲取 Copilot 最廣泛的公開規模數字：用戶、付費訂閱者、組織、GitHub 開發人員、新開發人員入門、PR 數量、企業訂閱者增長、多模型使用和 CLI 增長 (微軟 26 財年第一季度、微軟 26 財年第二季度、微軟 26 財年第三季度)。

使用 GitHub 文件來獲取當前產品事實：計劃、價格、AI 積分配額、計費機制、模型託管、功能可用性、使用指標、內容排除、程式碼引用和負責任使用控制。使用 JetBrains、Stack Overflow、DORA 和 GitLab 來獲取有關開發人員工作採用、信任、治理和審查瓶頸的背景信息，同時記住它們的分母是調查人群而不是 Copilot 遙測數據。

常見問題

來源和延伸閱讀