这个问题的严重程度究竟如何？Cereblab的研究人员测试后发现，Grok Build不仅上传了当前正在编辑的文件，连那些被明确标记为“不可访问”的历史文件，以及已经从版本历史中删除的敏感凭证信息，也一并被纳入上传清单。这已经不是简单的隐私疏忽，而是系统性的数据过度收集问题。

所幸的是，截至周一，当研究人员再次测试时，SpaceXAI的服务器已经返回了一个“disable_codebase_upload: true”的标记，意味着代码库上传行为已经不再被触发——至少暂时被关闭了。

面对舆论压力，埃隆·马斯克在X平台上亲自回应，声称此前上传的数据将被“彻底且完全删除”，并强调SpaceXAI“始终尊重用户隐私设置”。不过，他的声明中还附带了一句话：希望用户允许平台保留这些数据，以便定位和调试问题。这句“希望”在批评者看来，多少有些避重就轻的意味。

伦敦国王学院的独立安全研究员Lukasz Olejnik指出了更为现实的风险：如此大规模的数据保留，涉及的内容远不止几行代码——专有源代码、安全漏洞信息、个人数据、基础设施细节以及访问凭证，这些都是攻击者梦寐以求的“金矿”。一旦这些数据发生泄露，后果将难以估量。

SpaceXAI此前给出的应对方案是：通过在CLI中执行“/privacy”命令来关闭数据保留并删除已同步的数据。但Cereblab在调查后指出，这条命令仅对单次会话生效，换句话说，每次打开一个新会话，用户都需要手动输入一遍。这显然不能被视为一个真正的修复方案，更像是临时打补丁。此次事件再次给AI编程工具行业敲响了警钟：代码隐私、数据治理和用户信任这些“软实力”，在技术高速狂奔的时代，恰恰是最容易被忽视、也最致命的短板。