AI 编程助手统计数据.

AI 编程助手不再是好奇开发者的辅助实验。到 2026 年，更好的问题是您指的是哪种采纳：调查使用、日常习惯、付费席位、企业推广、接受的代码建议、基准性能，还是实际交付的经过审查的代码。

这种区别很重要，因为头条数字很大。Stack Overflow 表示，84% 的受访者使用或计划使用 AI 工具进行开发，其中 50.6% 的专业开发者每天使用。JetBrains 表示，在其 2026 年 1 月的 AI 脉搏调查中，90% 的专业开发者定期在工作中使用至少一种 AI 工具，74% 采用了专门的 AI 开发者工具。微软表示，GitHub Copilot 拥有超过 470 万付费订阅者，并被近 14 万个组织使用。

但当大数字被错误地归类时，它们可能会产生误导。基准分数不是用户数量。付费订阅者不是每日活跃开发者。生成的代码行不是经过审查、安全、已部署的软件。2026 年的真实情况是，AI 编程工具已成为主流、商业化且日益智能化，而艰巨的工作已转移到审查、治理、可追溯性以及衡量团队是否交付了更好的软件。

AI 编程助手一览

头条数字使用不同的分母，因此应将其视为独立的调查、商业、能力和治理信号，而不是一个数字。

仔细解读采纳数据

解读 AI 编程助手统计数据最安全的方法是将其视为一个阶梯。最顶层是广泛的调查信号：开发者是否尝试过 AI 工具、是否每天使用，或是否计划很快使用。Stack Overflow 的84%“使用或计划使用”数字是一个强烈的采纳信号，但它与专业开发者中 50.6% 的日常使用率不是同一个指标。

下一个阶梯是特定于工作的使用情况。JetBrains 2026 年 1 月的 AI 脉搏调查很有帮助，因为它将通用 AI 工具与专门的开发者工具分开。它报告称，90% 的人定期在工作中使用 AI 工具进行编码和开发，74% 采用了专门的 AI 开发者工具。这仍然是调查证据，但它比一般的“开发者喜欢 AI”民意调查更接近专业工作流程。

商业规模是另一个阶梯。微软公布了 GitHub Copilot 的用户、付费订阅者和组织数量：超过 2600 万用户、超过 470 万付费订阅者和近 14 万个组织。这些是指定 AI 编程助手最强烈的公开指标，但每个指标都回答了不同的问题。

再往下是产品交互指标。GitHub 自己的使用指标文档将活跃 Copilot 用户定义为用户发起的交互次数，并将代码完成接受率定义为接受的代码活动除以生成活动。这些定义阻止了一个常见的错误：接受的建议与合并的拉取请求不同，合并的拉取请求与可靠的生产软件也不同。

基准测试位于一个独立的类别。SWE-bench Verified 的500 个人工验证实例有助于比较编码代理在软件工程任务上的表现，而更广泛的 SWE-bench 系列对于理解能力进展很有用。但基准通过率不是用户数量、客户数量或企业投资回报率。

开发者采纳：AI 已成为工作流程的常态

最强烈的调查证据指向同一个方向：AI 辅助现在在软件开发中已是常态。Stack Overflow 2025 年的调查报告称，47.1% 的受访者每天使用 AI 工具，17.7% 每周使用，13.7% 每月或不频繁使用，5.3% 计划很快使用，16.2% 没有计划使用。在专业开发者中，日常使用率上升到 50.6%。

JetBrains 以不同的调查设计讲述了类似的故事。其 2025 年开发者生态系统报告基于数据清洗后的24,534 名开发者，并按地理、就业、语言和产品使用情况进行加权，同时明确指出 JetBrains 用户可能更有可能响应。在此框架内，JetBrains 报告称，85% 的人定期使用 AI 进行编码，62% 的人依赖至少一种 AI 编程助手、代理或代码编辑器。

2026 年 1 月的 AI 脉搏更新使市场图谱更加精细。它涵盖了全球10,000 多名专业开发者，本地化为八种语言，并根据 2025 年开发者生态系统分布进行加权。在该调查中，90% 的人定期在工作中使用至少一种 AI 工具，74% 采用了专门的开发者 AI 工具，GitHub Copilot 在工作中被 29% 的人使用，Cursor 和 Claude Code 各被 18% 的人使用。

DORA 增加了技术组织视角。Google 的 2025 年 DORA 摘要称，该报告基于全球近5,000 名技术专业人士，其中 90% 报告在工作中使用 AI，每天使用 AI 的时间中位数为两小时。DORA 还表示，65% 的人严重依赖 AI 进行软件开发，超过 80% 的人报告生产力提高。

需要注意的是，这些并非相同的人群。Stack Overflow 调查的是广泛的开发者社区。JetBrains 调查开发者并提供加权细节。DORA 调查技术专业人士并研究团队系统，而不仅仅是编程助手。所有这三项都指向高采纳率，这一点意义重大；它们使用不同的分母，这正是它们不应合并为一个数字的原因。

GitHub Copilot 是最明确的付费采纳锚点

GitHub Copilot 并非整个 AI 编程助手市场，但它是文档最完善的商业锚点。微软在 FY26 Q1 表示，GitHub Copilot“现在拥有超过 2600 万用户”，而 GitHub 本身拥有超过 1.8 亿开发者。同一财报电话会议表示，80% 的新 GitHub 开发者在第一周内就开始使用 Copilot，并且在过去一年中合并了超过 5 亿个拉取请求。

付费用户数量比用户数量更清晰。在 FY26 Q2，微软表示 Copilot 拥有超过 470 万付费订阅者，同比增长 75%，并且个人开发者的 Copilot Pro+ 订阅环比增长 77%。微软还提到西门子在向 30,000 多名开发者推广 Copilot 后广泛采用 GitHub，这是一个具体的企业案例，不应推广到所有客户。

到 FY26 Q3，微软表示近 14 万个组织使用 GitHub Copilot，企业订阅者同比增长近三倍，大多数用户使用多种模型，并且 Copilot CLI 使用量环比几乎翻倍。微软还表示，它正在将 Copilot 转向基于使用量的定价，以使定价与使用量和成本保持一致。

产品本身也在变化。GitHub 已超越自动补全和聊天，发展成为一个编码代理，可从问题和分支工作，以及 Agent HQ，GitHub 将其定位为编码代理的组织层。它还增加了模型选择，涵盖 OpenAI、Anthropic 和 Google 模型。2026 年，“AI 编程助手”越来越意味着一个模型、策略、代理和审查界面的生态系统——而不仅仅是一个自动补全框。

市场比 Copilot 更广阔

最安全的市场地图是按工作流程表面划分，而不是按虚构的市场份额划分。GitHub Copilot 是最大的公开记录的付费锚点，但 JetBrains 2026 年的调查显示开发者使用多工具堆栈：Copilot 拥有 76% 的认知度和29% 的工作采纳率；Cursor 拥有 69% 的认知度和 18% 的采纳率；Claude Code 达到 18% 的采纳率（在美国和加拿大为 24%）；OpenAI Codex 在调查窗口内拥有 27% 的认知度和 3% 的采纳率；Google Antigravity 在 11 月发布后达到 6%。

该调查还显示，通用聊天界面仍然很重要：28% 的开发者在工作中使用 ChatGPT 进行编码，8% 使用 Gemini，7% 使用 Claude 的聊天机器人。Stack Overflow 的代理工具部分也显示，ChatGPT 和 GitHub Copilot 是使用或构建代理的受访者中常见的开箱即用工具，Claude Code、Google Gemini、Microsoft Copilot、Replit、Tabnine、Amazon CodeWhisperer、Cody 和 Devin 处于长尾。

对于创始人来说，这张地图比虚假的排名更有用。销售“另一个编程助手”是一个弱势地位，除非产品拥有特定的层级：仓库上下文、安全审查、测试生成、迁移、代码搜索、代码库入门、终端自动化、云执行、策略、评估、计费或代理编排。

生产力：更快的代码创建是真实的，但并非自动的投资回报率

最常被引用的积极生产力研究是 GitHub 的受控 Copilot 任务实验。使用 Copilot 的开发者完成 JavaScript HTTP 服务器任务速度提高了 55%，平均耗时 1 小时 11 分钟，而没有 Copilot 则为 2 小时 41 分钟。这是一个真实的结果，但它是一个任务设置——它支持“Copilot 可以加速某些编码任务”，而不是“每个开发者都快了 55%”。

调查证据显示开发者感受到了好处。JetBrains 表示，近九成使用 AI 编程的开发者每周至少节省一小时，五分之一的开发者节省八小时或更多。DORA 表示，超过80% 的人认为 AI 提高了生产力，59% 的人报告对代码质量有积极影响。GitLab 表示，78% 的人报告代码输出速度更快，73% 的人表示自采用 AI 编程工具以来，整体代码质量有所提高。

问题不在于 AI 是否能让代码更快地出现。它可以。问题在于更快的代码创建是否能转化为更快、更安全的交付。DORA 2025 年的公告称，AI 采纳与吞吐量和产品性能呈正相关，但与软件交付稳定性呈负相关。DORA 更广泛的框架是 AI 放大了一个团队已有的系统：强大的团队可以受益，而薄弱的反馈循环和紧密耦合的系统则会暴露出来。

GitLab 2026 年的调查使下游瓶颈具体化：85% 的人同意 AI 将瓶颈从编写代码转移到审查和验证代码，84% 的人同意最大的挑战是管理 AI 生成的代码，82% 的人表示 AI 生成的代码可能会带来新的技术债务，而他们的组织尚未准备好应对。GitLab 早期的调查还表示，团队成员每周因低效流程损失7 小时，49% 的人使用超过五种 AI 工具，只有 37% 的人会信任 AI 在没有人为审查的情况下处理日常任务。

METR 是最鲜明的反例，因为它衡量的是真实任务而非自我报告。在其 2025 年初的随机对照试验中，16 名经验丰富的开源开发者在成熟的仓库中完成了 246 项任务。他们预计 AI 会将完成时间缩短 24%，之后仍然认为 AI 使他们加快了 20%——但测量的完成时间在允许 AI 的情况下延长了 19%（METR arXiv）。

这并不能证明 AI 编程工具不好。METR 自己的页面现在警告说，2025 年初的结果已过时，其2026 年更新表示，由于开发者越来越多地选择不使用 AI 禁止的工作，选择任务的方式不同，并同时使用多个代理，因此较新的数据难以解释。正确的解读是细致入微的：AI 生产力取决于任务类型、代码库熟悉度、质量标准、审查负担以及围绕代码生成的工作流程的重新设计程度。

代码供应、拉取请求和基准

AI 编程助手正在改变代码的供应。微软表示，数万名 AMD 开发者使用 Copilot，每月接受数十万行代码建议。GitHub 的使用指标文档将代码完成接受率定义为接受的代码活动除以生成的代码活动。这些对于内部推广仪表板很有价值，但它们仍然是交互指标。

下一层是拉取请求工作流。微软表示，在讨论 AI 编码代理和 Copilot 采纳时，过去一年在 GitHub 上合并了超过 5 亿个拉取请求。GitHub 推出了一个 Copilot 编码代理，可从问题和分支工作，以及用于管理多个编码代理的 Agent HQ。这使 AI 辅助更接近交付系统，但它并未消除审查责任。

基准测试显示了为什么每个人都在投资编码代理。SWE-bench Verified 包含500 个人工验证实例，旨在作为编码代理和语言模型更可靠的评估集。HumanEval 作为较旧的代码生成基准仍然很重要，但它是一种历史格式，不能完全代表企业软件工作。OpenAI 关于不再使用 SWE-bench Verified 作为主要评估的说明是一个有用的提醒：随着模型和框架的改进，基准可能会饱和或失去区分能力。

信任、安全和治理是市场的新中心

采纳率很高，但信任度不高。Stack Overflow 2025 年的新闻稿称，46% 的开发者不信任 AI 输出的准确性，高于 2024 年的 31%。详细调查显示，66% 的人引用 AI 解决方案“几乎正确，但不够”，45.2% 的人引用调试 AI 生成的代码耗时。

对于 AI 代理，担忧更为尖锐。Stack Overflow 表示，87% 的人担心 AI 代理信息的准确性，81% 的人对使用代理时的数据安全和隐私有担忧。DORA 的信任悖论也指向同样的方向：只有24% 的人报告对 AI 有很多或极大的信任，而 30% 的人报告很少或没有信任。

治理是这成为商业问题的地方。GitLab 2026 年的调查显示，43% 的人无法可靠地区分其代码库中 AI 生成的代码和人工编写的代码，92% 的人报告存在一些治理挑战，80% 的人同意其组织采纳 AI 工具的速度快于制定政策的速度。GitLab 还表示，87% 的人有信心在 24 小时内确定 AI 生成的代码是否导致了生产事故——但过去一年发生事故的组织中，有 34% 实际上无法做出这种判断。

安全研究解释了为什么审查不能消失。“Asleep at the Keyboard?” 是一项关于 Copilot 风格代码生成风险的较早研究。“Do Users Write More Insecure Code with AI Assistants?” 是另一项关于 AI 编程辅助用户行为的重要历史研究。最近的 USENIX Security 2025 工作继续研究 AI 生成代码如何改变风险状况。旧论文中的确切比率不应盲目应用于 2026 年的工具，但持久的教训是：生成的代码需要来源、审查、测试、策略和安全扫描。

供应商正在通过从纯粹的生成转向控制来应对。GitHub 正在构建指标仪表板、企业控制、模型选择和 Agent HQ。GitLab 将治理、可追溯性和生命周期集成定位为代码生成之后的下一层。JetBrains 将 Air、Central、Junie 和开放代理基础设施定位在编排、本地上下文和模型选择周围。

这对工程领导者和创始人意味着什么

对于工程领导者来说，这些数字指向一个推广漏斗。首先是访问：谁可以使用哪些工具，以及数据边界是什么？然后衡量常规使用：每日和每周活跃使用、接受的建议、委托的任务、代理工作流。然后转向交付结果：拉取请求周期时间、审查时间、测试质量、逃逸缺陷、事件率、开发者满意度，以及 AI 是否改变了瓶颈。

错误的仪表板止步于代码量。GitLab 的85% 审查和验证瓶颈统计数据警告说，更快的生成可能只是将工作转移到下游。DORA 的”镜像和乘数”框架是战略版本：AI 放大其周围的系统。METR 的测量难度是实验版本：开发者即使在受控任务中结果并非如此，也可能感觉更快。

对于创始人来说，市场显然是真实的，但通用定位是薄弱的。“开发者正在使用 AI”不再具有差异化。更强大的产品会解决特定的瓶颈：代码库上下文、迁移、测试、安全审查、依赖升级、知识检索、PR 审查、代理编排、评估、权限或成本控制。官方产品页面越来越多地强调企业打包和工作流程——GitHub Copilot 计划和指标、AWS Q Developer、Gemini Code Assist for business、Claude Code 成本和 JetBrains AI 许可——而不仅仅是代码补全。

对于采购团队来说，数据反对单一工具排行榜。GitHub Copilot 拥有最强大的公开付费采纳锚点，但 JetBrains 显示了一个多工具环境，Stack Overflow 显示了广泛的 AI 工具使用而非特定供应商的市场份额，GitLab 显示组织已经面临工具蔓延问题。一个现实的采购流程会比较 IDE 适配、仓库访问、模型选择、策略控制、可审计性、使用报告、数据保留、安全审查以及工具是否支持公司现有的代码审查路径。采纳数据表明存在需求；它们并未表明每个组织都应该标准化使用相同的界面。

最强大的项目将采纳视为受管理的工程变更，而非软件席位推广。一个团队可以快速推出许可证，但如果开发者只将工具用于孤立的代码片段，仍然无法改变交付结果。从低风险任务开始——文档、测试脚手架、代码解释、简单重构、内部工具——然后只有当团队能够观察接受率、审查负荷、安全发现和事件影响时，才转向高风险变更。

将这些数字转化为决策

将最强烈的统计数据视为一组透镜，每个透镜都有其自己的范围：

2026 年的持久结论是，AI 编程助手已成为主流，但市场正在从“AI 能否编写代码？”转向“团队能否管理 AI 辅助的软件交付？”赢家不会是生成最多代码的团队。他们将是那些知道代码来源、更改原因、谁审查了它、哪些测试保护了它，以及它是否在不增加隐藏风险的情况下改进了产品的团队。

常见问题

来源和延伸阅读