GitHub又把选择权藏进设置里：私有仓库训练AI争议，为何让开发者集体炸锅
GitHub 这次惹到开发者，不是因为它做了什么惊天动地的新技术，而是因为它又一次碰到了程序员最敏感的神经：代码所有权、私密性，以及“你凭什么替我默认同意”。
事情的起点很简单。Hacker News 上有人发帖提醒，如果用户不在 4 月 24 日前手动选择退出，GitHub 的相关设置会允许平台将私有仓库内容用于 Copilot 功能改进或模型训练相关用途。帖子很短，情绪却很浓，评论区的反应也很直接：有人表示“根本不知道有这回事”，有人开始寻找 GitHub 的替代品，还有人半开玩笑半认真地哀叹，“那些付费多年、却没看到通知的人，算是白白贡献了训练数据”。
这类讨论在今天的 AI 时代已经不新鲜了，但每次落到 GitHub 身上，火药味都会格外重。原因很简单：这里放着的不是用户随手点过赞的内容，不是社交平台上的公开碎片，而是企业代码、产品原型、自动化脚本、商业逻辑，有时甚至是一个创业公司真正的命根子。
真正让人不舒服的，不是AI，而是“默认替你决定”
如果把这件事仅仅理解成“GitHub 想拿私有代码训练 AI”，其实还不够准确。更刺痛开发者的地方，在于 opt-out，也就是默认加入、主动退出，而不是 opt-in，也就是先征得同意、再开始使用。
这听起来像一个产品经理的设置细节，实际上却是平台态度的分水岭。对于普通用户来说，一个被埋在设置页面深处的开关，和一份明明白白弹到眼前的授权确认，心理感受完全不同。前者像是在说：“我们先这么做了，你要是不愿意自己去关。”后者至少承认了一件事：这不是理所当然，这是你的权利。
技术平台近几年越来越依赖这种“默认同意”的机制。一方面，它能显著提高数据覆盖率；另一方面，它也总能让公司在法务上找到某种合规落点。但问题是，法律上站得住，不等于信任上站得稳。开发者群体对权限、数据边界和版本控制的敏感，远高于一般互联网用户。你可以说服他们接受复杂 API，接受漫长的 CI 流程，甚至接受离谱的依赖地狱，但你很难说服他们接受一句轻飘飘的“我们已经帮你打开了”。
GitHub 这些年靠什么赢得市场？当然不只是代码托管，更是“开发者基础设施”的身份。基础设施最重要的品质，不是酷炫，而是可信。仓库一旦被视作可能被平台用于别的目的，哪怕只是“改进功能”，那种隐约的不安全感就会迅速扩散。
私有仓库为什么格外敏感：代码不是帖子，它往往就是生意本身
很多非技术读者可能会觉得，训练 AI 用点代码，跟训练 AI 用论坛发言、新闻文章差别不大。实际上，差别很大。
公开代码仓库本来就在开放网络上，许可证、可见性、再利用边界都相对清楚。私有仓库则完全是另一回事。它里面可能有未发布的产品功能、内部工具、客户定制逻辑、运维脚本、API 密钥误提交后的历史痕迹，甚至包含公司尚未申请专利的关键实现。哪怕平台宣称不会“直接泄露”，很多团队依然会警惕：这些数据究竟会被如何清洗、聚合、脱敏、使用？谁能访问？会不会在模型输出中形成某种“记忆残留”？
这并不是杞人忧天。过去几年，围绕生成式 AI 训练数据的争议几乎每个月都在上演：图片网站、媒体机构、程序员社区、作者群体，都在问同一个问题——平台是否有权把用户创造的内容转化成模型能力，再反过来卖给市场？这个问题在 GitHub 身上尤其尖锐，因为 GitHub Copilot 本身就曾因训练来源与代码版权问题引发大量讨论。程序员们对“代码会不会被学习”不是没有心理准备，而是他们想知道：边界在哪里，解释是否透明，选择是不是出自自己。
更现实的一层在于商业关系。很多公司愿意把代码放在 GitHub 上，是因为它已经成了事实标准，协作生态、CI/CD、Issue、PR、权限管理都围着它转。一旦这种基础设施型平台把 AI 训练默认选项伸进私有领域，用户会本能地想到一个老问题：我们究竟是在使用服务，还是在源源不断为平台补贴原料？
从Copilot到整个行业，AI公司正在重写“默认规则”
GitHub 的这次争议，放在更大背景里看，其实是 AI 行业普遍趋势的缩影。过去两年，几乎所有大型平台都在重新定义用户数据的用途：搜索引擎把点击行为用于模型优化，办公软件把文档交互用于智能助手改进，设计平台把创作内容变成生成能力的燃料。以前平台收集数据是为了推荐和广告，现在则多了一项胃口极大的新需求：模型训练。
而模型训练有个天然冲动，就是越多越好。数据规模越大，任务越细分，系统就越可能在竞赛里占上风。于是我们就看到一种越来越熟悉的操作：公司更新条款、调整设置、给出一个默认勾选，再把退出入口放在帮助页面或账户选项里。形式上，它是“给了你选择”；体验上，它更像“如果你不注意，就算你答应了”。
这也是为什么 Hacker News 上的讨论会迅速引发共鸣。开发者并不天真，他们知道 AI 产品需要数据，也知道大型平台不可能放弃训练机会。但他们仍然对这种做法反感，因为这触及了互联网平台治理里一个很古老、却总被重新包装的问题：默认值究竟是在服务用户，还是在操纵用户？
如果我们横向比较，会发现一些企业在处理这类问题时更谨慎。某些面向企业市场的 SaaS 厂商，会明确承诺客户数据不用于基础模型训练，或者把训练权限设计为合同层面的显式选择。原因并不高尚，更多是因为企业客户真的会走人。GitHub 面对的是同样一群极度重视控制权的人，却似乎仍希望用消费互联网那套“默认开启、需要自行关闭”的手法来推进功能，这就难免显得傲慢。
GitHub真正要修复的，是开发者心里的那条裂缝
从产品角度看，GitHub 当然可以辩解：设置入口已经提供，用户有权关闭，平台也许并没有恶意，甚至内部团队可能真心相信这是为了让 Copilot 更懂真实开发场景。问题在于，今天的开发者已经不太愿意继续把“相信我们”当作默认前提了。
这种情绪变化，并不只发生在 GitHub。过去，程序员多少带着一点工程师式的浪漫，愿意相信工具平台和自己站在同一边；如今，云服务涨价、API 政策反复、开源公司商业化转向、AI 产品四处找数据，让这种朴素信任变得越来越稀缺。平台每多一次不够透明的动作，都会让用户默默多做一层备份、多准备一个镜像、多看一眼替代方案。
所以，这次风波的后续，不一定会立刻演变成大规模迁移。现实很骨感：GitHub 的生态位太强，绝大多数团队不会因为一个设置就连夜跑路到别的平台。但它会留下更长远的后果——开发者会越来越倾向于把 GitHub 视为“必要但不值得完全信任的基础设施”。这比一次舆论翻车更麻烦，因为信任一旦变成折损项，平台未来推出任何 AI 增强功能，都要付出更高的解释成本。
说到底，AI 时代真正稀缺的不是训练数据，而是授权关系里的诚意。代码托管平台当然可以做 AI，也完全可以做得很好，甚至帮开发者省下大量时间。但前提应该是：别把用户最重要的资产，当成一个默认勾选框背后的“可利用资源”。
这件事也抛出了一个很值得继续追问的问题：当平台既是基础设施提供者，又是 AI 产品销售者时，它还能否公平地对待用户数据？如果答案含糊不清，那么开发者接下来要学习的，恐怕不只是新框架和新模型，还包括一件老派却必要的事——定期检查设置页面里那些看起来不起眼、实际上很要命的开关。