GitHub Copilot 新规：默认用个人代码训练 AI，用户需手动退出。隐私担忧引用户不满，考虑转投其他平台。
原文标题：用得越多、失业越快？GitHub 大改 Copilot 规则：默认拿个人代码训练 AI，还搬出 Anthropic 挡枪！
原文作者：AI前线
冷月清谈：
怜星夜思：
2、GitHub 拿微软、Anthropic 和 JetBrains 当挡箭牌，说他们也在这样做。但这种“大家都在做”的说法，能说服你吗？
3、如果让你来设计一个更合理的 Copilot 数据使用策略，你会怎么做？
原文内容
当地时间 3 月 26 日，GitHub 宣布，自 4 月 24 日起，除非用户主动选择退出，Copilot Free、Pro 和 Pro+ 用户与 Copilot 的交互数据将被用于训练和改进其 AI 模型。此次调整不适用于 Copilot Business 和 Copilot Enterprise 用户。此外，免费获得 Copilot Pro 权限的学生和教师不受此次更新影响。
GitHub 强调用户仍然保有选择权。对于不希望参与训练的个人用户，可以在设置中的 “Privacy（隐私）”选项里手动退出。GitHub 强调会提前 30 天通知用户，并允许随时退出。不过，值得注意的是，Free、Pro 和 Pro+ 个人用户被默认纳入了训练范围，需要自行设置退出。
被吐槽很难找到的退出设置
根据 GitHub 的说明，可被用于模型训练的数据包括：
-
用户接受或修改后的输出内容
-
用户发送给 GitHub Copilot 的输入内容，包括展示给模型的代码片段
-
用户光标位置周围的代码上下文
-
用户编写的注释和文档
-
文件名、代码仓库结构以及导航模式
-
用户与 Copilot 功能的交互，包括 Chat 和行内建议
不过，GitHub 也划出了一些不会被纳入本次项目的数据范围：
-
来自 Copilot Business、Copilot Enterprise 或企业拥有的代码仓库的交互数据
-
在 Copilot 设置中选择退出模型训练的用户的交互数据
-
静态存储的 issue、discussion 或私有仓库内容。
官方特意使用了“静态存储”这个说法，是因为当用户主动使用 Copilot 时，Copilot 确实会处理来自私有仓库的代码。这些交互数据是运行服务所必需的，并且除非选择退出，否则它们可能会被用于模型训练。
GitHub 明确表示，Business 和 Enterprise 客户的数据不会用于模型训练，原因是现有合同明确禁止这样做；如果某个 GitHub 账户属于付费组织，或者是付费组织的外部协作者，该账户的交互数据也会被排除在训练之外。对此，GitHub 的解释是，这是合同义务所决定的，并称自己对保护训练数据“很有信心”。
GitHub 对这项调整的解释是，Copilot 的使用量正在快速增长，模型需要更多“真实世界数据”来覆盖越来越多的编码场景。
GitHub 称，过去一年，其已经开始利用微软员工的交互数据训练模型，这一做法带来了明显改进，包括多种编程语言中的建议采纳率提升，“这证明了真实世界的交互数据确实能够提升模型在更广泛、更多样的使用场景中的表现。”
GitHub 强调，AI 辅助开发的未来赖于开发者提供的真实世界交互数据，因此除了微软员工数据之外，公司也将开始使用 GitHub 员工的交互数据来训练模型。”
数据共享方面，用于训练的数据可能会被 GitHub 和微软内部负责 AI 模型开发的人员访问，也可能交由签有合同限制的服务提供商代为处理，但不会卖给第三方，也不会提供给第三方模型厂商用于训练他们自己的模型。
GitHub 提到微软、Anthropic 和 JetBrains 也在采取类似措施，以说明自己并不是孤例。与此同时，GitHub 直接回应了一个尖锐问题：如果真实用户代码对模型这么重要，这是否意味着 GitHub 的竞争优势更多来自现有用户基础，而不是更好的研究？
对此，GitHub 的回答是，“目前已有 2600 万开发者 在使用 Copilot，这提供了极为丰富的使用场景和需求，因此公司希望通过用户自愿贡献的交互数据，让 Copilot 更好地覆盖多样化编码任务。”
除此之外，GitHub 还面临一个信任层面的老问题。GitHub 专门回应了外界对 Copilot Chat 暴露私有代码的担忧。GitHub 的说法是，外界提到的案例涉及第三方收集“曾短暂公开后又转为私有”的代码，不属于 GitHub 主动暴露数据的范畴；对于此次新计划收集的数据，公司会通过访问控制、审计日志和自动化过滤来保护，包括过滤 API key、密码、token 和个人身份信息。
GitHub 的回应，显然没有开发者买单。
有用户直言：“我真的非常讨厌这种做法。”
首先，它一上来就给出了具有误导性的“退出”操作说明。 如果我进入账户设置，再点 Copilot，实际上什么都不会发生，只是那个列表项展开而已。我根本没法像邮件里写的那样，在那里“选择是否允许将你的数据用于 AI 模型训练”。
其次，真正可以退出的设置项，文字表述和邮件里的说明也对不上。 所以他们就是在故意把人绕晕，赌很多用户根本找不到这个设置。更离谱的是，它还被放在设置页面最底部。
第三，我也不清楚，如果我的仓库里加了协作者，而他们没有选择退出，那我的代码会不会也被拿去用？ 总之，这次政策调整烂透了。也许是时候看看别的 Git 平台了。我对 GitHub 也算有些经验，确实该试试别家了。这件事反而成了一个催化剂。
贪婪是没有尽头的。
而且这种事情本来就不该默认开启。 账户应该默认是退出状态，只有在你自己愿意的情况下，才主动打开。
除了退出设置的坑，还有用户陷入账户界定的迷茫中：
我有一个大约 20 人的组织。我们并没有在组织层级启用 Copilot；但当我进入 Security Code Quality 时，我却能使用 Copilot 来生成修复建议。而且正因为它没有被正式启用，所以那里也没有“退出”的选项。
所以我现在想知道，这个功能到底是来自我个人账号的 Copilot 免费版（因为它并没有在组织层面启用），还是说其实存在一个我没看到的、某种“隐藏的”组织级 Copilot 免费版。我只想弄清楚，我是不是需要去推动所有能访问这个组织的人都退出这次更新。
“这是我做过最快的退出操作。”“我正在认真考虑因为这件事关闭我的 GitHub 账号。”“如果有其他替代方案请告诉我，我实在受够了这种把消费者当成产品对待的做法。”这类声音充斥整个社区。
参考链接：
https://github.blog/news-insights/company-news/updates-to-github-copilot-interaction-data-usage-policy/
声明：本文为 InfoQ 整理，不代表平台观点，未经许可禁止转载。
OpenClaw 出圈，“养虾”潮狂热，开年 Agentic AI 这把火烧得不可谓不旺。在这一热潮下，自托管 Agent 形态迅速普及：多入口对话、持久记忆、Skills 工具链带来强大生产力。但这背后也暴露了工程化落地的真实难题——权限边界与隔离运行、Skills 供应链安全、可观测与可追溯、记忆分层与跨场景污染、以及如何把 Agent 纳入团队研发 / 运维流程并形成稳定收益。
针对这一系列挑战，在 4 月 16-18 日即将举办的 QCon 北京站上，我们特别策划了「OpenClaw 生态实践」专题，将聚焦一线实践与踩坑复盘，分享企业如何构建私有 Skills、制定安全护栏、搭建审计与回放机制、建立质量 / 效率指标体系，最终把自托管 Agent 从可用的 Demo 升级为可靠的生产系统。
