微软秘密地将 Copilot 设为 400 万次提交的共同作者。开发者们发现了。

2026年4月下旬的某个时候，开发者们开始在他们的 Git 历史记录中发现一个意想不到的名字。

“Co-authored-by: Copilot <copilot@github.com>”

它出现在完全由手工编写的提交中。出现在明确禁用了 AI 功能的提交中。出现在生产代码、开源项目和企业仓库中。在人们意识到发生了什么之前，GitHub 上估计有 400 万次提交带有这个标签。开发者的反应是迅速的：Hacker News 上获得了 1,458 分和 805 条评论，Reddit 上出现了愤怒的讨论帖，论坛上反复出现一个词——“破坏”。

Microsoft 更改了 VS Code 中的一个默认设置，在没有发布说明的情况下将其发布，并意外地创造了 AI 归属权争论中的决定性时刻。该公司在几天内撤回了这一更改。但这一事件引发的问题将比任何补丁都更持久：当 AI 工具默默地声称你的工作归功于它时，你构建的东西到底属于谁？

究竟发生了什么

该功能本身并不复杂。git.addAICoAuthor，于 2026 年 3 月在 VS Code 1.110 中引入，旨在当 GitHub Copilot 贡献代码时，在 Git 提交中附加共同作者（co-author）标签。它发布时的默认设置为“off”，对于一个修改永久仓库元数据的功能来说，这是一个合理的初始状态。

4 月 16 日，一个拉取请求改变了一切。由 VS Code 团队成员 Dmitriy Vasyura 审查并合并的 PR #310226，将默认值从“off”更改为“all”。“all”设置正如其字面意思：它为通过 VS Code 进行的每一次提交都添加了“Co-authored-by: Copilot”，无论 Copilot 是否有所贡献。正如 ItsFOSS 所记录的, 该设置还忽略了 chat.disableAIFeatures，那些在编辑器中明确关闭了所有 AI 功能的开发者仍然被打上了标签。

VS Code 1.118 于 4 月 29 日发布，并启用了这一新默认设置。没有发布说明，没有通知，也没有解释这一变化的文档。开发者们发现它的方式和他们发现任何事情的方式一样：通过阅读自己的 git 日志，发现了一些本不该存在的东西。

受影响的规模并不小。 ByteIota 估计约有 400 万次提交受到影响。GitHub Copilot 被 90% 的财富 100 强公司使用。这些组织中的每一个，其提交历史中都被静默注入了 AI 联合作者标签，包括受 SOC 2、ISO 27001 和 FDA 软件验证要求约束的代码库。

Microsoft 在 5 月初发布的 VS Code 1.119 中撤销了这一默认设置并致歉。一位发言人告诉 The Register，这一变化旨在“提供透明度”，但承认该实施方案“未达到开发者的预期”。该单一设置已被改回“关闭”状态。但那 400 万次提交记录依然存在。

为什么开发者们如此愤怒

愤怒并非源于一个 git trailer。它关乎谁有权决定你工作的价值。

首先是信任危机。VS Code 是这一代开发者的默认编辑器。它运行在全球最大的公司内部，处理着全球最敏感的代码库。在这样一款拥有极高信任度的工具上，未经通知就更改一个会修改永久仓库元数据的默认设置，这绝非功能更新，而是违反了工具与用户之间的隐性契约。开发者不会阅读每一份变更日志。他们信任每天使用的编辑器所提供的默认设置，不会悄无声息地篡改其工作的法律记录。

其次是版权问题。美国版权局已裁定，缺乏足够人类署名的 AI 生成作品不受版权保护。如果提交记录中出现 "Co-authored-by: Copilot"，就会引发一个令人不安的问题：Microsoft、GitHub 或 OpenAI 是否拥有该代码的部分版权？答案几乎肯定是否定的。但这种模糊性本身就是问题所在。从 GPL 到 MIT 再到 Apache，开源许可证都假设了人类署名。在每一次提交中添加 AI 共同作者（包括未使用 AI 的提交），会给每一个涉及的项目引入法律不确定性。ByteIota 将其称为“版权混乱”。这一描述并非夸大其词。

对于企业开发者来说，问题更加具体。受监管的行业要求每一项提交都必须追溯到获得授权的人类开发者。SOC 2 审计会问：这段代码是谁写的，什么时候写的？ISO 27001 要求：这项更改是否经过授权？FDA 软件验证要求：你能证明有资质的工程师审查过这个吗？自动化的 AI 共同作者标签破坏了这些链条中的每一个环节。400 万次提交代表了一个巨大的合规难题，而这个难题是由 Microsoft 创造、发布，并仅在遭到强烈抵制后才修复的。

开源维度的影响则让一切变本加厉。受贡献者许可协议（CLA）约束的项目维护者醒来后发现，他们的提交历史被第三方篡改了。如果一个项目要求贡献者签署 CLA，而 Copilot 在未签署任何协议的情况下作为共同作者出现在提交中，那么该项目知识产权转让的法律基础就会被削弱。这种损害不是理论上的，它是元数据，而元数据是永久存在的。

令人不安的问题：这真的是个意外吗？

Microsoft 并非不小心发布了一个错误的默认设置。它是在测试开发者是否会容忍 AI 抢夺他们的工作功劳。答案是否定的。

看看时间线。该功能在 3 月份引入时，默认设置为 "off"，这显然是正确的选择。4 月 16 日，一个 PR 将其更改为 "all"，这是最激进的设置。4 月 29 日，它正式发布。六周内经历了三个刻意的步骤。仓促的错误不会遵循这样的轨迹。

看看设置选项。git.addAICoAuthor 提供了三个选项："off"、"own" 和 "all"。"Own" 仅在 Copilot 实际贡献代码时才添加联合作者（co-author）标签，这本可以是一个合理且透明的默认设置。而 "all" 则是一个为了最大化归属权而牺牲准确性的选择。在一个已有 "own" 选项的情况下，将设置从 "off" 更改为 "all" 的 PR 是在表达一种立场，而不是在修复 bug。

看看这个设置忽略了什么。chat.disableAIFeatures 是终极选项，代表开发者在说：“我不希望 AI 参与我的工作流。”但 "all" 这一默认设置覆盖了它。那些明确选择完全退出 AI 的开发者仍然被打上了 AI 联合作者标签。这已经从激进变成了不可理喻。

再看看竞争环境。GitHub Copilot 正在与 Cursor 和 Claude Code 进行三方混战。Cursor 的年化收入刚刚突破 20 亿美元，据报道正寻求 500 亿美元的估值；而 Claude Code 在开发者满意度调查中以 46% 的“最受喜爱”评分领先。Copilot 占据着企业市场（90% 的财富 100 强公司），但 Cursor 的增长速度更快。在这种环境下，数百万次提交中的联合作者标签起到了原生营销的作用。每一次 git log 都变成了 Copilot 的广告牌。每一次 git log 的输出都是一种隐性背书。

没有发布说明。没有用户通知。一个会修改永久仓库元数据的功能，在静默状态下发布，被设置为最大化归属权，覆盖了明确的退出选项，并服务于明确的营销目的。Hacker News 上的开发者并没有称其为意外。他们直言不讳地指出了它的本质。

道歉声明也证实了这一点。Microsoft 将最初的更改描述为一项“透明度”功能，但却以最不透明的方式实施：静默、无通知，并采用了范围最广的默认设置。一个旨在增加 AI 归属权信任的功能，却摧毁了开发者对实现该工具的信任。

对比：当工具开始在你的作品上署名

Copilot 事件在细节上是史无前例的，但它所暴露的紧张关系却无处不在。

Grammarly 纠正你的写作，但它不会在你的署名栏中添加 “Co-authored-by: Grammarly”。Adobe Photoshop 的 AI 生成填充不会在图像上添加 “Co-created with Adobe AI” 的水印。Midjourney 为了平台合规性会将图像标记为 AI 生成，但并不会强制个人艺术家在作品集中注明该模型。这些工具做出了一个选择：用户拥有输出结果，工具是隐形的。

GitHub Copilot 做了不同的选择，而 Git 让这个选择产生了深远影响。Git 历史记录不是创作画布，而是法律记录。提交（commit）中的共同作者（co-author）字段在开源治理、版权转让和企业合规中具有特定含义。未经同意更改它不像添加水印，而像是篡改签名。

在这种背景下，Copilot 处于技术栈中的位置使其具有独特的危险性。它运行在基础设施层，静默、自动，并嵌入在数百万用户使用的默认编辑器中。Grammarly 是你安装的插件，Midjourney 是你访问的网站，而 Copilot 是你每天早上打开的工具中的默认设置。当基础设施改变了记录你工作的方式时，你可能直到律师询问时才会注意到。

行业对于专业工具中的 AI 归属尚无标准。Microsoft 试图通过更改默认设置来单方面设定一个标准，而不是通过提议标准。开发者社区的反应不仅仅是针对这个默认设置，而是针对这样一个原则：影响法律记录的标准不能由一家公司通过一个 PR 来设定。

下一步是什么

Microsoft 撤回了默认设置，但那 400 万次提交记录依然存在。对于受监管行业的企业来说，这些提交记录意味着一项清理工程：审计仓库、记录元数据污染，并向审计员证明 AI 共同作者标签并不反映真实的 AI 署名。预计 SOC 2 框架将在下一个审计周期内，针对提交历史中的 AI 元数据增加明确的指导方针。

信任受损将需要更长时间来修复。开发者将更仔细地观察 VS Code 的每一次更新，而竞争对手也深知这一点。Cursor 和 Claude Code 都有机会在信任和透明度上实现差异化。Cursor 的增长轨迹已经威胁到了 Copilot 在企业市场的统治地位，信任优势将加速这种威胁。

监管机构的关注已成必然。自动化 AI 共同署名的版权影响尚未经过法庭检验，但它们与 FTC 和欧盟对 AI 透明度的积极监管兴趣相交织。如果监管机构问“Microsoft 是否通过自动化共同作者标签对开发者代码主张版权”，答案是否定的，但这个问题本身能被提出来，这本身就是问题所在。

更广泛的问题在于行业是否吸取了正确的教训。每家 AI 工具公司都面临同样的诱惑：通过对用户输出主张署名权来展示采用率。ChatGPT 不会在你的邮件中添加“由 ChatGPT 编写”。Notion AI 不会在你的文档上盖上“与 Notion AI 共同创作”的印章。Copilot 事件是关于底线在哪里的第一次重大考验，而底线守住了。开发者拒绝让工具在他们的作品上署名。

从这次事件中产生的标准将塑造未来十年的 AI 工具治理。它应该是简单的：选择性加入、细粒度、可审计，并且永远不应用于 AI 未参与的工作。Microsoft 以惨痛的方式学到了这一点。问题在于下一家公司是否能在产品发布前学到这一点。

FAQ：关于 Copilot 共同作者争议的常见问题

Microsoft 是故意的吗？

时间线表明这是深思熟虑的结果，而非意外。该功能于 3 月推出，默认设置为“关闭”。4 月 16 日的一个 PR 将其更改为“全部”，这是最激进的设置。它于 4 月 29 日发布，且没有发布说明。六周内分三步走。“全部”默认设置忽略了那些明确禁用了 AI 功能的开发者。无论是故意还是疏忽，结果都是一样的：400 万个 commit 在未经同意的情况下被贴上了标签。

这会影响我的开源项目许可证吗？

有可能。美国版权局已裁定，没有足够人类署名的 AI 生成作品不能获得版权。如果你的 commit 中出现“Co-authored-by: Copilot”，它会引入关于署名的歧义。大多数开源许可证都假设贡献者是人类。法律影响尚未在法庭上得到检验，但元数据污染是真实且永久的。

如何检查我的 commit 是否受到影响？

运行 git log --format=full 在你的仓库中运行并搜索 "Co-authored-by: Copilot"。如果你在未使用 Copilot 的提交中发现了它，说明你的仓库受到了影响。你也可以检查 VS Code 设置中的 git.addAICoAuthor 来确认其当前值。

会有监管后果吗？

很可能。版权和合规性影响与 FTC 和欧盟对 AI 透明度的监管兴趣交织在一起。像 SOC 2 这样的企业合规框架可能会增加关于提交历史中 AI 元数据的指南。这一事件加速了关于 AI 归属标准的讨论。

我应该停止使用 Copilot 吗？

联合作者（co-author）功能才是问题所在，而不是 Copilot 本身。该设置已被撤回。但信任损害是真实存在的。关注 git 历史完整性的开发者应该验证他们的设置，并更仔细地关注未来的 VS Code 更新。这里涉及的原则——即修改法律记录的功能应采用“选择性加入（opt-in）”默认设置——适用于每一个 AI 工具，而不仅仅是 Copilot。

下次打开编辑器时，请检查你的 git 配置。一个简单的设置，git.addAICoAuthor, 决定了你的名字是否能独立出现在你亲手完成的工作中。Microsoft 了解到，当工具将开发者的劳动成果据为己有时，开发者是会察觉到的。该公司在一周内修复了该设置。但其测试的这一原则，则需要数年时间才能尘埃落定。

AI 工具理应放大你的工作成果，而非据为己有。信任不是一个配置选项，它本身就是产品。一旦失去信任，任何 git revert 都无法将其挽回。

Copilot 事件是整个 AI 行业的一个测试案例。当一个工具在未经询问的情况下修改你的永久记录时，信任受损的程度与代码改动的大小并不成正比，而是与这种改动所暗示的“谁在控制你的工作”成正比。Microsoft 在一周内吸取了教训。对于其他所有 AI 工具公司来说，问题在于他们是否也需要经历一次类似的事件才能学会这一点。依赖 AI 工具的知识工作者，从代码编辑器到知识库，都应该问同一个问题：谁在控制我所创造的事物的记录？