微软2026年初部署Claude Code和GitHub Copilot CLI的研究

# 命令行 AI 编码代理的采用与影响  
## 微软 2026 年初推出 Claude Code 和 GitHub Copilot CLI 的研究  
来源：https://arxiv.org/html/2607.01418  
Emerson Murphy‑Hill, Jenna Butler, and Alexandra Savelieva  
Microsoft  
[email protected]  
[email protected]  
[email protected]  

###### 摘要  
推出 Anthropic 的 Claude Code 和 GitHub 的 Copilot CLI 这类代理式命令行工具的组织需要知道：谁会尝试使用、谁会持续使用，以及这些工具是否能产生足够的产出以证明其成本合理。在组织规模下，令牌消耗每年可达数百万美元，因此误判采用率、留存率或影响，可能使推出成本高昂却并未改变工程效率。通过研究微软在 2026 年初推出期间数万名工程师的行为，我们发现：首次使用主要通过社交网络传播；留存更多与工程师的编码活动相关，而非人口统计特征；采用者合并的拉取请求数量比原本预期多约 24%。我们使用合并的拉取请求作为产出的代理指标——承认合并的 PR 并不等同于它带来的价值——并且这种提升在我们的四个月观察窗口期内持续存在。这些结果表明，命令行编码代理既不是被统一采用的，也并非仅仅是新奇效应；组织应将可见的同伴使用作为推出策略的核心。

## 1 引言  
像 Anthropic 的 Claude Code、Google 的 Gemini CLI 和 GitHub 的 Copilot CLI 这类代理式命令行工具，在软件开发者中越来越受欢迎。这些工具利用调用大语言模型的代理，代理从命令行代表用户执行半自治命令。2026 年初，Pragmatic Engineer 的调查显示，Claude Code 是受访者中最受欢迎的 AI 开发者工具[26 (https://arxiv.org/html/2607.01418#bib.bib8)]。与此同时，考虑是否购买此类工具的组织尚不清楚哪些工程师可能采用并使用它们。2025 年底，StackOverflow 对超过 49,000 名受访者的调查[35 (https://arxiv.org/html/2607.01418#bib.bib9)]显示，开发者对 AI 的信任度正在下降，并且“开发者愿意但又不情愿使用 AI”。*即使*组织选择使用 AI，执行这些工具所需的令牌也可能很昂贵。在极端高用量下，Fortune 报道了 Meta 员工对 AI 的使用情况[14 (https://arxiv.org/html/2607.01418#bib.bib10)]：  
> *在 30 天内，仪表盘上的员工总使用量超过 60 万亿令牌，排名最高的单个用户平均使用了 2810 亿令牌。使用最便宜的 Claude Opus 4.6 版本（每百万令牌 5 美元），单单这一个用户就可能让 Meta 花费超过 140 万美元。*  
即使在使用量较为适中的情况下，组织也可能想知道应该期待怎样的投资回报。因此，任何推出都伴随着三个关切：*哪些工程师会采用*、*他们是否会持续使用该工具*，以及*该工具是否能产生足够的额外产出——我们将其操作化为合并的拉取请求——以证明其成本合理*。为了考察这些问题，我们分析了 2026 年初微软向其工程师提供两种代理式命令行工具——Claude Code 和 Copilot CLI——在大约四个月的使用和拉取请求 (PR) 活动窗口中的经验。本文贡献了首个利用开发者级别遥测数据来分析代理式命令行工具的采用及其对拉取请求产出影响的实地研究。先前的开发者 AI 采用研究通常依赖调查和访谈，而先前的产出研究大多从公开仓库信号推断 AI 使用（第 2 节 (https://arxiv.org/html/2607.01418#S2)）；我们的企业设置则能观察到每一位可能采用的工程师以及直接使用情况。在此设置中，我们将首次使用与留存分开，跟踪合并 PR 产出与工具使用强度的关系，比较两种不同工具，并利用内部开发者调查来帮助解释结果。  
我们通过两项研究来分析采用与影响。*采用研究*（第 4 节 (https://arxiv.org/html/2607.01418#S4)）询问谁采用：在可能使用 Copilot CLI 的工程师中，谁尝试使用它（RQ1），以及在尝试过的人中，谁持续使用它（RQ2）。*产出研究*（第 5 节 (https://arxiv.org/html/2607.01418#S5)）询问采用带来了什么：使用任一工具是否产生更多的合并 PR（RQ3），具体工具是否重要（RQ4），以及哪些工程师受益最多（RQ5）。采用研究仅覆盖 Copilot CLI，这个工具在推出时有明确的合格采用者群体；产出研究则同时覆盖 Claude Code 和 Copilot CLI。

## 2 相关工作  

### 2.1 开发者 AI 辅助的采用  
技术采用的研究在社会科学中有着悠久的历史，从 Rogers 的创新扩散理论[32 (https://arxiv.org/html/2607.01418#bib.bib15)]到更偏向技术的信息系统研究[12 (https://arxiv.org/html/2607.01418#bib.bib16),39 (https://arxiv.org/html/2607.01418#bib.bib17),40 (https://arxiv.org/html/2607.01418#bib.bib18)]，这些研究告诉我们采用受个人、社会和组织因素影响。在本文中，我们使用*采用*作为一个总括术语，指开发者对工具的采纳，并将其分解为该文献视为不同的两个阶段[32 (https://arxiv.org/html/2607.01418#bib.bib15),5 (https://arxiv.org/html/2607.01418#bib.bib14)]：*首次使用*——开发者的第一次使用——以及*留存*——这种使用是否持续。我们将两者分开研究，因为正如我们的结果所示，预测首次使用的因素并非预测留存的因素。  
在开发者 AI 领域，Reyes‑Reina 及其同事最近关于 AI 工具在软件开发中采用的系统综述描述了 25 项研究[30 (https://arxiv.org/html/2607.01418#bib.bib26)]。然而，该综述中的每项实证研究都基于调查、访谈或焦点小组——或者，在直接观察行为的情况下，基于一次性实验室任务；*没有*一项研究利用开发者实际采用的观察数据。我们正好填补了这一空白，得益于能够获取 (1) 纵向、个人可识别的 AI 工具使用遥测数据，以及 (2) 关于开发者的人力资源 (HR) 数据。  
除了该综述，最近有几项研究利用观察数据考察开发者 AI 采用。Daniotti 等人通过提交分类器推断 AI 辅助编码，以记录 AI 的全球扩散[11 (https://arxiv.org/html/2607.01418#bib.bib27)]；Yang 通过工具默认的提交合作作者尾部标记，在 16,000 名科学家中识别 Claude Code 采用者[43 (https://arxiv.org/lang/2607.01418#bib.bib29)]；Robbes 及其同事通过提交尾部标记、配置文件和分支名称，在 GitHub 项目中检测 AI 代理采用[31 (https://arxiv.org/html/2607.01418#bib.bib28)]。但这些研究都只观察那些在公开仓库中留下信号的开发者，因此“非采用者”仅仅是没有任何此类信号的人——将真正的未使用与受抑制或不可见的使用混为一谈。由于缺乏*合格*工程师的名单，他们无法清晰地将采用者与非采用者分开。我们的企业设置提供了缺失的分母：*可能*采用微软批准的代理式命令行工具的全体工程师人口，以及谁尝试了 AI 以及谁持续使用它的日志。

### 2.2 开发者 AI 辅助的影响  
AI 辅助如何影响开发者生产力已沿着三个维度进行了检验：开发者*自我报告*的内容、他们在*受控任务*中的表现，以及他们在实际工作中*交付*的内容。  
最常见的开发者生产力证据是自我报告的。最近的一项系统综述发现，开发者满意度调查是衡量生产力的主要方式[21 (https://arxiv.org/html/2607.01418#bib.bib37)]。此类调查普遍发现，接受更多 AI 建议的开发者报告感觉更高效、更满意[45 (https://arxiv.org/html/2607.01418#bib.bib38),25 (https://arxiv.org/html/2607.01418#bib.bib40),1 (https://arxiv.org/html/2607.01418#bib.bib41)]，并且他们认为编写和实现代码是 AI 帮助最大的地方[15 (https://arxiv.org/html/2607.01418#bib.bib39)]。然而，开发者报告的内容不一定与最终交付的内容相符。  
第二类证据来自受控实验，这些实验可以建立因果关系，但任务与实际工作的相似程度各不相同。在这类研究中，结果大多是正面但并非完全一致：几项研究发现使用 AI 能更快完成任务[28 (https://arxiv.org/html/2607.01418#bib.bib32),41 (https://arxiv.org/html/2607.01418#bib.bib44),33 (https://arxiv.org/html/2607.01418#bib.bib45),6 (https://arxiv.org/html/2607.01418#bib.bib43),27 (https://arxiv.org/html/2607.01418#bib.bib4)]，而少数研究报告没有显著差异或需要花费大量时间验证 AI 输出[38 (https://arxiv.org/html/2607.01418#bib.bib6),22 (https://arxiv.org/html/2607.01418#bib.bib42)]。那些让开发者自带实际工作的研究提高了生态效度，但规模缩小：在一项 19 名参与者的研究中，AI 仅解决了大约一半的开发者的实际任务[19 (https://arxiv.org/html/2607.01418#bib.bib46)]，而在另一项 16 名开发者的研究中，AI 反而使完成时间*增加*了 19%[4 (https://arxiv.org/html/2607.01418#bib.bib47)]。在自然环境中将 AI 随机分配给开发者的现场实验同样结果不一，从合并拉取请求无显著变化[9 (https://arxiv.org/html/2607.01418#bib.bib49),8 (https://arxiv.org/html/2607.01418#bib.bib51)]到显著的拉取请求提升[10 (https://arxiv.org/html/2607.01418#bib.bib34)]。  
第三类证据与我们的研究最为接近，即观察开发者在实际环境中的产出。一些研究比较了群体采用 AI 前后的产出，发现变化不大：一家公司的 39 名开发者在两年内提交次数无变化[36 (https://arxiv.org/html/2607.01418#bib.bib56)]，三个敏捷团队的提交量也无变化[37 (https://arxiv.org/html/2607.01418#bib.bib58)]，尽管这种前后比较容易受到季节性混杂因素的影响。另一些研究通过间接信号（提交配置文件、提交合作作者尾部标记或最初支持的语言）推断 AI 使用，报告的影响包括：初始提升较大但几个月后消退[16 (https://arxiv.org/html/2607.01418#bib.bib1),29 (https://arxiv.org/html/2607.01418#bib.bib59),2 (https://arxiv.org/html/2607.01418#bib.bib2)]、无影响[18 (https://arxiv.org/html/2607.01418#bib.bib54)]，以及合并拉取请求增加高达 40%[44 (https://arxiv.org/html/2607.01418#bib.bib53)]。然而，通过间接信号推断使用，在实际 AI 使用方面既存在假阳性也存在假阴性。与我们的研究最接近的几项研究通过订阅或遥测数据直接识别 AI 使用，避免了这个问题，报告的合并 PR 提升从百分之几到超过 60% 不等[13 (https://arxiv.org/html/2607.01418#bib.bib55),34 (https://arxiv.org/html/2607.01418#bib.bib52),20 (https://arxiv.org/html/2607.01418#bib.bib57),17 (https://arxiv.org/html/2607.01418#bib.bib12)]。然而，这些研究都没有专门针对代理式命令行工具使用遥测数据——它们主要研究基于 IDE 的 AI 工具。这正是我们的产出研究所填补的空白：测量在实际环境中使用代理式命令行工具对拉取请求吞吐量的影响。

## 3 背景  
在 2026 年上半年，微软工程师可以访问两种经批准的代理式命令行工具：Copilot CLI 和 Claude Code。GitHub 于 2026 年 2 月 25 日宣布 Copilot CLI 正式可用；微软通过产品预览计划更早获得了访问权限。Claude Code 通过一条较窄的路径到达微软工程师：从 2025 年底开始，特定部门和个人员通过托管计划获得访问权限，并且随着计划成熟，访问列表不断演变。在整篇文章中，我们将 2026 年 1 月 5 日——即我们前期和后期之间的分界点，也是微软内部更广泛使用这些工具开始腾飞的时刻——称为*推出*。这种推出的不对称性影响了采用研究的样本；而出产研究则考察了实际采用的工程师，覆盖了这两种工具。  
两项研究的观察窗口均于 2026 年 4 月 29 日关闭；此后不久，一份内部公告表示，大约一个月后大多数工程师的 Claude Code 许可证将终止，受影响的工程师被指示过渡到 Copilot CLI。我们在该时间点之前结束分析窗口，因为将工程师被迁移出 Claude Code 的周次纳入会混淆我们的结果：迁移中的工程师看起来像是自然采用 Copilot CLI 的用户，而 Claude Code 的使用会因政策原因而非工程师偏好而下降。  
在此时期之前，微软员工已通过非 CLI 形式使用 GitHub Copilot 多年。这些形式包括 VS Code 等 IDE 中的代码补全、聊天和代理模式。因此，读者不应将我们的发现广泛解释为关于 AI 工具，而应理解为关于代理式命令行工具在非 CLI 工具已可用背景下的采用与影响。

## 4 采用研究  
采用研究考察 Copilot CLI 在两个阶段的采用——首次使用和留存——研究对象是推出时有资格采用该工具的工程师，即我们在第 4.2 节 (https://arxiv.org/html/2607.01418#S4.SS2) 中定义的样本。我们还利用一项开发者调查（第 4.6 节 (https://arxiv.org/html/2607.01418#S4.SS6)）来帮助解释我们发现的采用模式。两项研究中的量化流程和图表均使用在作者指导下由 AI 助手编写的代码实现，并经作者验证；我们在致谢中给出了完整的 AI 使用声明。

### 4.1 研究问题和结果变量  
采用研究回答两个问题，尽管它们自然地放在一起，但需要不同的数据结构和统计模型。我们陈述每个问题及其操作化的结果变量。

**RQ1.** 在可能使用但尚未使用 Copilot CLI 的工程师中，谁首先尝试它？  
我们将首次使用定义为工程师在推出后的窗口内首次打开 Copilot CLI。对于每个工程师‑周 \((i,w)\)，其中工程师 \(i\) 之前没有 Copilot CLI 活动，首次使用结果 \(A_{i,w}\) 在 \(i\) 于第 \(w\) 周内有任何 Copilot CLI 活动时为 1，否则为 0；一旦 \(A_{i,w}=1\)，工程师 \(i\) 不再贡献后续行。由于仍面临首次使用风险的群体每周都在缩小，这给出了一个工程师‑周面板上的离散时间风险。

**RQ2.** 在采用 Copilot CLI 的工程师中，谁持续使用它？  
我们将留存定义为持续的早期使用：如果采用者从首次使用开始的 14 天中至少有 5 天记录了 Copilot CLI 活动，则被视为留存。5/14 的阈值近似于“在最初两周内大约一半工作日使用了 Copilot CLI”，旨在区分“尝试并留下”与“尝试并放弃”。我们排除了首次使用距离工具使用观察窗口结束不足 14 天的采用者，因为他们的留存窗口尚未完全结束。由于留存仅针对已采用的工程师定义，因此它是一个横截面结果，每个采用者一行。

### 4.2 样本  
采用研究的样本包括微软软件工程师，每位工程师都有资格尝试 Copilot CLI。