7月13日，X用户@a_green_being发帖称，Grok把他“整个用户目录”上传到了xAI的服务器，附图显示目录里有SSH密钥、密码管理器数据库、文档、照片、视频。这条帖子拿到了1.3万次浏览，评论区迅速炸出一批“我也遇到过”和“建议立刻改密码”。
但把“用户目录”和“上传”这两个词拆开看，事情比标题更具体，也更值得说清楚。
不是目录，是仓库——但对开发者来说更麻烦
第三方网络层测试显示，问题大概率出在Grok Build CLI——xAI面向开发者的终端编程代理，运行时会直接读取整个Git仓库，包括历史提交记录。如果开发者习惯把.env文件或密钥文件放进项目目录里（这在小团队和个人项目中相当常见），CLI扫描仓库时会把它们一并带走。
这和普通Grok聊天应用不是一回事。xAI官方说明里，聊天应用只处理用户主动附加的文件，属于“按需读取”；而Build CLI的设计前提是“运行于仓库上下文内”，默认行为更接近“全量扫描”。原帖说的“整个用户目录”，可能是对“整个代码仓库”的误读或夸大，但对受影响的开发者来说，仓库里的密钥同样是真实凭证，不因为叫法不同就变得不敏感。
关闭“改进模型”开关，为什么没用
评论区不少人第一反应是“我关了训练开关，应该没事”。这正是最容易踩的坑。
xAI的“Improve the model”开关，控制的是数据是否被用于训练，属于训练用途设置。它不管数据会不会被服务器端读取、暂存、传输——那是一个独立的操作性上传环节，CLI工具执行任务时该扫描还是会扫描，跟这个开关没有关系。
- 风险.用户以为“关了开关=数据安全”，实际上开关只挡住了下游用途，挡不住上游采集。
这个误解不是个案，是几乎所有把“训练开关”当“隐私开关”用的用户都会犯的错误。xAI隐私政策里写得很直白：上传内容属于“用户内容”，可能用于提供、分析、维护、改进、研究服务，也可能因法律要求披露给第三方——官方本身就建议用户不要提交敏感信息，这句提示常年被忽略。
训练开关管的是用途，不是入口，两者从设计上就不是一回事。
打了补丁，不等于历史数据已经清空
目前能确认的进展是：xAI已经下发服务器端标志位，禁用了Build CLI的代码库上传功能。这算是一次快速止损，但止损的只是“接下来会不会继续泄露”，不解决“已经泄露的怎么办”。
第一手被上传的SSH密钥、密码库数据是否已经存储、是否进入过训练语料、现在是否已被删除——这几个问题目前都没有xAI的官方正面回应。对照xAI自己公布的Private Chat模式“30天内删除”承诺，这次事件里数据保留和处理流程有没有同样兑现，同样是空白。
作为对比，GitHub Copilot和Cursor这类同样具备本地文件/仓库访问权限的AI编程工具，此前也都因为“扫描范围超出预期”被开发者社区质疑过。这不是Grok一家的独有问题，而是所有具备文件系统或仓库访问权限的AI Agent类工具共享的架构风险：工具越“聪明”，默认读取范围往往越大，用户对它到底看了什么、传了什么，可见性反而越低。
- 结论.判断一个AI编程工具是否安全，别看它有没有训练开关，看它是“按需读取”还是“默认全量扫描”。
对正在用类似CLI工具处理私有仓库的开发者，眼下能做的动作很具体：检查仓库根目录有没有裸露的.env或密钥文件，把敏感凭证挪出被扫描范围，已经暴露过的密钥直接轮换，别等厂商给说法。