GitHub悄悄更新服务条款，3000万开发者的Copilot使用数据将成为AI训练燃料。这不是假设——新条款7月1日生效，默认开启，关闭入口藏得比Windows旧版控制面板还深。
开发者发现时，部分人的代码已经被"借"了快一个月。
条款更新的时间线
6月20日，GitHub在博客发布"产品改进"公告，标题温和得像一次常规迭代。核心改动 buried 在第三段：Copilot数据可用于训练AI模型，并与微软共享。
6月26日，Hacker News帖子开始发酵。用户「todsacerdoti」截图对比新旧条款，发现关键一句从"可选"变成了默认同意。帖子4小时内冲到首页，评论区出现熟悉的愤怒配方——"这就是为什么我从不信任云端IDE"。
7月1日，新条款正式生效。GitHub给出的关闭路径：Settings → Copilot → "数据共享" → 取消勾选。四步操作，但第一步的入口在付费用户和免费用户界面位置不同。
GitHub发言人「Alexis Johnson」回应媒体询问时用了个精巧的句式：「我们始终相信用户应该对自己的数据有控制权。」这句话出现在解释为何默认开启的段落里。
数据流向的灰色地带
争议焦点不是"能不能用"，而是"什么被用了"。GitHub官方说明区分了两类数据：
第一类是提示（prompt）——你敲下的代码片段、注释、问题描述。第二类是交互反馈——你接受或拒绝了Copilot的哪个建议，修改了哪里。
前者可能包含公司私有代码，后者能还原你的编程习惯。
更微妙的在于"共享给微软"的边界。GitHub在FAQ里写道：「微软作为GitHub的母公司，可能将数据用于其AI产品改进。」这包括Copilot本身，也包括Azure OpenAI服务、Office Copilot，以及微软未公开的产品线。
开发者「Simon Willison」在X上打了个比方：「这就像你的健身房记录被默认分享给母公司，然后母公司用它训练保险定价模型。条款里写了，但没人会读。」
关闭选项的设计哲学
GitHub提供了退出机制，但设计思路值得玩味。
企业版用户（Copilot Business/Enterprise）默认不开启数据共享，需要管理员统一配置。个人版用户（Pro/Free）默认开启，需要手动关闭。这个分层的逻辑很直白：付更多钱的人，隐私保护是标配；付更少钱的人，隐私是可选升级。
关闭后的生效时间也有讲究。GitHub说明：「更改将在24小时内生效。」但条款生效是7月1日，意味着6月20日到30日之间，部分用户的数据已经被采集，即使他们后来关闭。
一位在金融科技公司工作的后端工程师告诉我，他们团队的合规流程走了11天才完成全员退出。「等我们弄完，每个人的代码风格已经被采样了。」
行业惯例与例外
用用户数据训练AI不是GitHub独创。OpenAI、Google、Anthropic的条款里都有类似表述，区别在默认状态和透明度。
Cursor（AI代码编辑器）在5月更新条款时选择了反向操作：默认关闭数据训练，用户主动开启可获得积分奖励。这个设计被部分开发者称为"付费买隐私的反面教材"。
JetBrains的AI助手则采取了更分裂的策略：本地模型不上传，云端模型默认上传，但明确标注"用于改进产品"而非"训练基础模型"。
GitHub的特殊性在于其生态位。它不是单纯的工具，而是代码托管基础设施。3000万开发者里，相当比例的人并非主动选择Copilot，而是被团队配置、被GitHub Student Pack赠送、被默认安装。
这意味着大量非自愿用户被纳入了数据供给体系。
开源社区的反应呈现分裂。Linux基金会执行董事「Jim Zemlin」在一份声明中表示：「我们理解AI需要数据，但默认同意的模式破坏了开发者与平台之间的信任契约。」
另一边，机器学习工程师群体相对平静。「训练数据就是新时代的石油，」一位在Meta工作的研究员说，「GitHub只是终于把潜规则写成了明规则。」
技术细节的未解之谜
GitHub没有回答几个关键问题：数据保留多久？去标识化到什么程度？微软内部谁可以访问原始数据？
条款里"去标识化"（de-identified）的定义模糊。移除用户名和仓库名是否足够？代码本身的结构特征（命名风格、架构模式）能否反向识别出个人或公司？
2023年GitHub Copilot曾因生成与训练数据高度相似的代码片段被起诉，原告指控其"洗稿"开源项目。那次诉讼最终以GitHub更新过滤器、增加重复检测告终，但训练数据来源问题从未真正解决。
这次条款更新可以看作GitHub的法律补课——既然迟早要用，不如先获得授权。代价是开发者社区的信任透支。
一位在条款更新当天关闭数据共享的独立开发者，在GitHub社区论坛留下了最后一条评论：「我花了三年把项目迁到GitHub，现在考虑迁回自托管。不是因为条款本身，而是因为你们通知我的方式。」
他的项目有127个star，0个issue。这种规模的开发者，GitHub的流失成本计算里可能根本没有这一项。
热门跟贴