7月10日，一位安全研究员给Grok Build发了一条指令："只回复OK，不要打开任何文件。"他同时在后台挂了网络监控。结果令人脊背发凉——Grok Build在没有任何提示的情况下，把整个代码仓库打包上传到了xAI的Google Cloud Storage服务器。一个12GB的项目，实际对话只需要192KB的数据，却被传走了5.1GB。
更可怕的是，日志里记录了339次自动上传，其中一次传的是整台电脑的主目录：SSH密钥、密码管理器文件、浏览器数据，全部打包发走。而这一切，发生在一个声称"本地优先（local-first）"的终端编程工具上。
事情是怎么暴露的
Grok Build是马斯克旗下xAI在2026年5月推出的终端AI编程智能体，用Rust编写，定位类似Claude Code和Codex CLI——在命令行里读取代码、修改文件、执行Shell命令，完成从规划到Git提交的全流程。发布时官方强调它"优先在本地运行"，听起来很安全。
但安全研究员@cereblab在逆向二进制文件和截获的metadata.json中，发现了一个名为grok-code-session-traces的Google Cloud Storage存储桶。上传机制默认开启，即使用户在设置里关掉了"改进模型"选项，/v1/settings接口依然返回trace_upload_enabled: true。也就是说，那个开关是摆设。
报告冲上Hacker News头条后，马斯克本人用一个词回应："True。"他承诺此前上传的所有用户数据已被永久删除，未来将彻底关闭数据留存机制。48小时后，xAI宣布Grok Build全面开源——84万行Rust代码，Apache 2.0协议，GitHub上几小时斩获超过1.2万Star。
开源是真的，但问题没解决
开源当然值得肯定。这是目前唯一完全开源的终端编码智能体，开发者可以自己编译、自己审计、出了问题直接提PR。它的架构设计也有亮点：用Git worktree实现真正的任务隔离，每个子智能体在独立工作目录里操作，合并时才暴露冲突；支持MCP协议扩展、检查点回滚，还兼容AGENTS.md生态，从Claude Code迁移几乎零成本。
但把开源当作隐私事件的"句号"，是危险的。三个事实需要认清：
第一，开源的是框架，不是历史。 84万行代码让你能审计当前的实现，但7月10日之前被传走的数据已经不在你手里了。如果你的代码库里有专有算法、客户数据或生产密钥，它们可能已经在某个云存储桶里躺了几周。开源不能撤回已发生的泄露。
第二，"本地优先"不等于"数据不出本地"。 Grok Build的本地运行能力是真的，但默认开启的trace上传机制让"本地优先"这个卖点变成了半句话。问题不在于工具能不能联网，而在于它在用户不知情的情况下，把整个仓库当作"遥测数据"传走了。
第三，这不是Grok独有的问题。 Claude Code、Codex CLI、Cursor，几乎所有AI编程工具都需要把代码发送到模型服务器才能工作。区别在于：显式发送和隐式上传。前者你知道代码去了哪里，后者你以为它没去。
开发者现在该做的三件事
不管你用哪个AI编程工具，这次事件都应该让你做一次彻底的安全自查。
审计你的工具配置。 打开你正在用的AI编程工具，找到数据上传、遥测、模型改进相关的所有设置项。逐个确认它们的实际行为，而不是只看开关标签。Grok Build的教训是：开关关了，接口还在返回true。用网络监控工具（如Little Snitch、GlassWire）抓一次包，看看工具在你不操作时到底往外发了什么。
隔离你的敏感文件。 .env文件、SSH密钥目录、密码管理器数据库——这些东西不应该出现在AI编程工具能访问的工作目录里。用.aiignore或工具自带的文件排除功能，把敏感路径挡在外面。更彻底的做法是：在Docker容器或虚拟机里跑AI编程工具，物理隔离比配置隔离可靠。
定期轮换被暴露过的密钥。 如果你在过去两个月用过Grok Build，假设你的API密钥和数据库密码已经泄露。不要等出事再处理——现在就去轮换所有出现在被扫描目录里的凭证。AWS、GitHub、数据库的访问令牌，全部重置。
写在最后
马斯克开源Grok Build，与其说是慷慨，不如说是被迫。隐私丑闻当前，开源是最快的信任修复手段。但84万行代码的开源，掩盖不了一个事实：在AI编程工具的架构里，"你的代码"和"工具的数据"之间的边界，至今由厂商单方面定义。
开发者需要的不是厂商的承诺，而是可审计的默认行为。Grok Build开源了，你可以自己看代码、自己编译、自己决定它能不能联网——这是进步。但下一个工具呢？在行业形成"数据上传必须显式授权且可独立验证"的共识之前，每个用AI写代码的开发者，都得自己当自己的安全员。
查一下你的工具，现在。