马斯克说一个字节不留，这话在工程上没法验证

马斯克这次的回应，只有一个词，True。

承认了。Grok Build 偷传用户代码这事，是真的。

紧接着一句承诺，所有此前上传到 SpaceXAI 的用户数据，完全彻底删除。原话是 Zero anything whatsoever will remain，一个字节不留。

从安全研究员发报告，到社区炸锅，到一把手亲自下场认错清零，前后不到 48 小时。坦率讲，这个响应速度在大厂翻车史里算快的。隔壁有些公司出这种事，公关稿能磨一个礼拜，磨出来还是「高度重视、深表歉意」那套车轱辘话。

但我今天想聊的不是道歉。满屏都在写马斯克认错，写危机公关教科书，我盯着的是那句承诺里最响亮的部分。

一个字节不留。

好家伙，这话听着真痛快。可你要是写过后端，管过存储，你的第一反应大概和我一样，这话怎么验证。

先把上半场快速过一遍，两天前这事刚爆出来的时候我写过一篇，拆的是流量细节，看过的朋友可以快进到下一段。独立安全研究者 @cereblab 建了一个钓鱼测试仓库，里面埋满做了唯一标记的假 API 密钥、假数据库密码，然后给 Grok Build 下了一个不能再简单的任务，什么都不用干，回答一个 OK 就行，不许打开任何文件。它乖乖回了 OK，转身把整个仓库连完整 git 历史一起打包，传到了 Google Cloud 上的一个存储桶。12GB 的测试仓库，实际传出 5.1GB，拆成 73 个包，一个不落。同一时间正经干活的对话流量，只有 192KB。偷运走的数据量，是干活的 27,800 倍。这一手钓鱼仓库加逐帧回放，有点子牛逼，原始报告现在还挂在 GitHub 上。

那个「帮助改进模型」的开关呢，关了没用，照传不误。它管的只是你的数据要不要拿去训练，压根不管你的代码有没有离开电脑。另一位研究者在自己机器上复现时翻出更吓人的记录，日志里记着 339 次自动上传，其中一次的上传对象，是他整台电脑的主目录。SSH 密钥、密码管理器、浏览器数据，你数字生活的全部家当。

而 Grok Build 官网宣传页上写的是 local-first。本地优先，你的代码留在你自己电脑上。

嗯。

现在回到那句「一个字节不留」。我跟你说，在分布式系统里，删除从来不是一个动作，它是一个愿望。

数据进了云端存储桶之后会发生什么，做过基础设施的朋友都门儿清。对象存储默认跨区冗余，一份数据落盘，可能同时躺在三个机房。开了版本控制的桶，删除只是打个墓碑标记，旧版本原地不动。再往下数，定期快照、备份归档、灾备副本，每一层都是一份独立拷贝。还有日志，访问日志、请求日志、计费日志，就算里面不存文件内容，文件名、路径、大小这些元数据也早就在别的管道里流转过一遍了。

所以「删除一份数据」的真实工作量，是把这棵副本树上每一个节点都找到并且抹掉，还得保证没有哪个角落的缓存、哪个工程师导出来调试的数据集漏在外面。这不是按一下删除键，这是一场跨系统的考古行动。

这还只是存储层。更麻烦的问题在上面一层，这批代码有没有进训练管线。

SpaceXAI 没说。如果进了，事情就从「删文件」升级成「从模型权重里删知识」。这个方向学术圈有个名字，machine unlearning（机器反学习，让训练好的模型忘掉特定数据的影响），2022 年就有系统性综述，但到今天的诚实结论依然是，在前沿大模型这个量级上，它是论文课题，不是产品功能。真要彻底反学习一批数据，基本等于回滚到那批数据进来之前的 checkpoint 重新训练，没有哪家公司会为一次公关事故付这个成本。

所以最可能的剧本是，清掉存储桶里的原始文件，声明训练管线没碰过这批数据，收工。

你信不信，全看你自己，因为没有任何技术手段能替你验证。

这是整件事里我最想说透的一点。删除没有回执。证明一份数据存在很容易，拿出来给你看就行。但证明一份数据不存在，工程上做不到，逻辑上也做不到，你永远不知道是不是还有一个你没检查到的地方。GDPR 给了欧洲用户被遗忘权，落地这么多年，执行方式也是企业自己出合规声明，监管偶尔抽查，没有哪个环节是技术验证的，因为真的验证不了。

马斯克的承诺同样如此。SpaceXAI 的官方声明里没有第三方审计，没有删除报告，就一条推文。哪怕他们真心实意把每个副本都清干净了，你我拿到的凭据，和他们敷衍了事时拿到的凭据，是一模一样的。都是那条推文。

真的就是一声叹息。

还有一个细节很多人没注意。报告发出当天，上传行为悄悄停了，用户不需要更新任何软件，服务器那头直接掐断。这说明什么，说明传不传这件事的控制权从头到尾都在服务端，今天能一键停，当初就能一键开，明天也能一键再开。你机器上跑的那个二进制没变，变的是云端的一个配置项。这种架构下，任何「我们不再收集」的承诺，有效期就是到下一次配置变更为止。

那用过 Grok Build 的人现在该干嘛。我的建议只有一条原则，别等承诺兑现，按已泄露处置。

密钥全换。凡是 Grok Build 打开过的项目，里面出现过的每一个凭据都当成已经泄露，API key 轮换，数据库密码改掉，OAuth token 撤销重发。注意 git 历史也算数，你半年前 commit 进去又删掉的那个密钥，在完整历史被打包上传的那一刻就跟着走了。git rm 救不了你，git 这玩意的设计初衷就是永远记住一切。

盘一遍外泄面。除了密钥，仓库里还躺着什么，内部接口文档、没发布的功能代码、客户数据样本、配置里写死的内网地址。企业用户尤其要做这一步，因为你可能需要向你自己的客户履行数据泄露的披露义务，这件事 SpaceXAI 的道歉替你办不了。

给 AI 工具上网络围栏。这次的发现方式一点都不神秘，抓出站流量而已。Little Snitch、LuLu 这类出站监控装一个，看看你电脑上每个 AI CLI 都在往哪儿发东西，@cereblab 那份报告就是现成的操作手册。想更彻底一点，把 agent 关进 devcontainer 或者虚拟机里跑，出站白名单只放行推理 API 的域名，其余一律拦下。我日常就是搭 agent 工具链的，一条体感供参考，权限这东西给出去容易收回来难，最小化永远是对的。agent 的工作目录就是项目目录，别让它有机会看到你的主目录。

最后一条，别以为换一家的 agent 就安全了。这次 Grok Build 被抓，不是因为它比别人坏，是因为有人较真去抓了它的包。同样的流量分析方法，对 Claude Code、Codex、Cursor、Gemini CLI 一样适用。信任不该建立在「还没被抓到」上面。

替 SpaceXAI 说句公道话。出事之后上线的 /privacy 命令，一键关闭数据留存外加追溯删除，产品动作是对的。做了四年端到端加密产品、刚被挖过去的高管 Andrew Milich 亲自站台背书。48 小时从装死到清零，这套危机响应放在整个行业里确实不难看，IT 之家的报道甚至说这在 AI 圈还是头一回。

但响应好和值得信任，是两回事。宣传页上 local-first 挂了两个月，数据就往外传了两个月。这不是 bug，是产品行为和产品承诺的背离。开关做出来了，开关不管事，这也不是 bug，是开关的定义和用户的理解压根不在同一个位面。这种背离被抓到一次，后面每一句承诺的可信度都要打折，包括这次的「一个字节不留」。

数据这东西，像倒进海里的墨水。马斯克可以承诺以后不再倒了，这个我信，产品改起来不难。但已经倒进去的那些，谁也捞不回来。声明海水是干净的没有用，你只能假设，你的那片海已经被染过了。

True 是个好词。用来认错，一个词顶一篇公关稿。但它只能用在承认上。承诺那一半，永远没法用一个 True 来标记完成，因为没人能跑那个测试。

换密钥去吧。