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 旅程的早期就已嵌入。它没有说明这些开发者中有多少人会成为留存的活跃用户或付费订阅者。

拉取请求活动是另一个有用的分母。微软表示，过去一年在 GitHub 上合并了超过 5 亿个拉取请求，因为 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、Issues 和 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 美元，包含 1500 个每月总 AI 积分；Copilot Pro+ 每月 39 美元，包含 7000 个每月总 AI 积分；Copilot Max 每月 100 美元，包含 20000 个每月总 AI 积分（GitHub 个人计划）。根据同一当前页面，Copilot Free 每月包含 2000 次代码补全，而 Copilot Student 包含无限次补全。

组织定价是基于席位加基于使用量的。GitHub 文档列出 Copilot Business 每用户每月 19 美元，包含每个用户 1900 个 AI 积分，Copilot Enterprise 每用户每月 39 美元，包含 GitHub Enterprise Cloud 每个用户 3900 个 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 的方式，涵盖主要 Copilot 界面，包括 IDE、CLI、Copilot 应用程序和 GitHub.com 代理委托。

企业控制不仅仅是关于模型。内容排除允许组织配置 Copilot 应忽略的文件；排除的内容不会影响内联建议、聊天响应或 Copilot 代码审查。代码引用检查建议是否与公开可用的代码匹配，并可根据策略设置丢弃匹配或显示引用（GitHub 代码建议）。

治理模式很明确：Copilot 2026 年的产品统计数据不仅仅是关于有多少人使用它。它们还涉及启用了哪些模型、如何计费、允许哪些上下文、如何引用建议以及团队如何衡量模型和功能的使用情况。

Copilot 使用指标：团队实际可以衡量什么

Copilot 的公开采用数字对于市场背景很有用。企业领导者在推广后需要一套不同的指标。GitHub 的使用指标文档称 Copilot 指标分为采用、参与度、接受率、代码行数和拉取请求生命周期指标。

采用率回答了获得许可的开发者是否正在积极使用 Copilot。GitHub 的指标文档将日活跃用户定义为在给定日期与 Copilot 交互的唯一用户，并且协调文档将活跃用户状态与用户发起交互计数大于零相关联（指标协调）。在评估推广是否活跃时，团队应优先选择此数字而非“分配的许可证”。

参与度显示了使用深度。GitHub 表示，参与度指标包括跨功能的频率和广度，例如每个活跃用户的平均聊天请求数。接受率衡量开发者接受建议的频率，并在仪表板和 API/导出字段中保持一致计算。它可以指示相关性，但高接受率并不自动意味着高质量软件。

代码行数指标特别容易被误用。GitHub 表示，代码行数指标是 Copilot 输出的方向性度量，量化了跨补全、聊天和代理功能的建议、添加或删除行数。方向性输出很有用，但它与合并、测试、安全或可维护的代码不同。

拉取请求生命周期指标使 Copilot 更接近交付成果。GitHub 表示，这些指标包括拉取请求创建和合并计数、合并中位数时间以及审查建议活动，允许团队将总体拉取请求活动与 Copilot 创建的拉取请求进行比较。这是 Copilot 不仅仅是代码生成工具的层面：团队可以研究 AI 辅助工作流是否改变了吞吐量和周期时间。

2026 年，指标产品变得更具操作性。GitHub 于 2026 年 2 月 27 日宣布 Copilot 使用指标普遍可用，提供仪表板和 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 个场景中生成了 1689 个程序，发现其中约 40% 在该设置中存在漏洞（arXiv 2108.09293），而 2022/2023 年的用户研究发现，使用 AI 代码助手的参与者编写的代码安全性显著降低，并且更有可能相信他们的代码是安全的（arXiv 2211.03622）。这些论文应被视为历史安全证据，而不是当前的 Copilot 漏洞率。

基准测试也应得到同样的谨慎对待。SWE-bench Verified 是一个经过人工验证的 500 个软件工程任务子集，用于评估编码代理和语言模型。它对于理解能力进展很有用，尤其是在 Copilot 变得更具代理性时。它不是活跃用户、付费订阅者、组织数量或生产质量的证据。

市场背景：AI 编码工具栈中的 Copilot

开发者调查显示了 Copilot 的重要性，这超越了微软的收益。JetBrains 2026 年 1 月的 AI Pulse 调查涵盖了全球 10000 多名专业开发者，发现 90% 的人在工作中定期使用至少一种 AI 工具进行编码和开发任务。调查还发现，74% 的人采用了专门的开发者 AI 工具，如编码助手、编辑器或代理，而不仅仅是通用聊天机器人。

在该调查中，GitHub Copilot 仍然是知名度和采用率最高的 AI 编码工具：全球 76% 的认知度和 29% 的工作使用率。JetBrains 还表示，在拥有 5000 多名员工的公司中，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 帮助，但团队需要信任、可追溯性和成本控制。

这些数字能证明和不能证明什么

缺失的数字与已发布的数字同样重要。GitHub 和微软发布了用户规模、付费订阅者、组织数量和平台背景，但他们没有发布清晰的 Copilot 日活跃用户数、付费收入的渠道划分或每个组织的平均席位数。

将 Copilot 的数据置于背景中

使用微软投资者财报电话会议记录获取 Copilot 最广泛的公开规模数据：用户、付费订阅者、组织、GitHub 开发者、新开发者入门、PR 数量、企业订阅者增长、多模型使用和 CLI 增长（微软 26 财年第一季度、微软 26 财年第二季度、微软 26 财年第三季度）。

使用 GitHub 文档获取当前产品事实：计划、价格、AI 积分配额、计费机制、模型托管、功能可用性、使用指标、内容排除、代码引用和负责任使用控制。使用 JetBrains、Stack Overflow、DORA 和 GitLab 获取开发者工作采用、信任、治理和审查瓶颈的背景信息，同时记住它们的分母是调查人群而非 Copilot 遥测数据。

常见问题

来源和延伸阅读