#人工智能 在被曝光擅自收集开发者完整仓库后，Grok Build 昨夜悄悄调整云端策略不再上传数据，这似乎是有意识的行为而非 BUG。昨天蓝点网提到 Grok Build 会上传开发者的整个仓库，这远远超出模型所需的上下文代码范围，SpaceXAI 到现在还未发布任何回应，但调整服务器临时关闭了数据上传。查看全文：https://ourl.co/113901
昨天蓝点网提到有安全研究人员发现 SpaceXAI Grok Build CLI 编程开发工具会在未经用户同意的情况下，将工具未使用的代码仓库乃至 Git 提交历史都上传到谷歌对象存储中，这种行为存在非常严重的数据泄露风险，尤其是对企业来说这可能会泄露内部机密信息。
Grok Build 的行为在开发者社区引起广泛关注且同时引起诸多开发者的恐慌，因为没有开发者想自己的完整仓库内容都被商业公司获取，大量开发者呼吁立即停用 Grok Build 确保安全，而 SpaceXAI 似乎也看到研究人员发布的消息，所以通过云端悄悄禁用数据上传开关。
发布原始报告的安全研究人员 CereLab 在 2026 年 7 月 13 日 3 点左右发布帖子称，Grok Build 的数据上传选项已经通过云端禁用，具体来说 Grok 服务器返回 disable_codebase_upload: true 该选项指的是开启关闭上传代码仓库，显然 SpaceXAI 这也是有意识的操作。
然而问题在于开发团队可以随时从云端重新启用数据收集选项，Grok Build 并非开源软件因此无法进行完整的代码审计，如果是开源的至少社区还可以通过代码进行分析和识别，而没有开源就只能依靠安全研究人员花时间进行监视、逆向工程以及抓包分析。
值得注意的是，研究人员的安全分析报告最早是在 7 月 11 日发布的，随后在 7 月 12 日和 13 日引起的关注越来越多，到 7 月 13 日夜里 SpaceXAI 通过云端禁用仓库上传功能合计已经有 3 天，如果说开发团队没注意到这件事那是不可能的，但问题在于到现在 SpaceXAI 并未发布任何官方回应来解释这件事。
信任这种东西失去后很难找回，即便 Grok 4.5 模型再好用也有前提那就是足够安全，现在 Grok Build 擅自收集开发者的完整仓库显然已经违反信任原则，而悄悄禁用上传功能但不发布任何回应的做法更加糟糕，这只会让更多开发者远离 Grok Build。
还有更多使用 Grok Build 的开发者担忧自己已经被上传的数据怎么办，这些仓库里可能包含大量敏感信息，被 SpaceXAI 收集总归不是好事，所以这里又回到透明度问题，如果 SpaceXAI 能够正面回应或许还有沟通的机会，至少也应该从云端删除所有仓库不再留存未经开发者同意收集的数据。
问题是现在 SpaceXAI 完全是在装死，所以现在除了继续声讨 SpaceXAI 外好像也没有其他好办法。
