你刚刚在终端里敲下 grok -p "帮我修一下这个 bug"，然后看着它逐行分析代码、给出修复方案，觉得这工具真不错。
但你不知道的是，就在你敲下回车的那一瞬间，一个你从未授权过的远程幽灵已经悄然启动。它绕过了你的 .gitignore，翻开了你的 .env 文件，把你完整仓库的每一行代码、每一次提交历史、连同你藏在环境变量里的那条 API Key，一起打包上传到了 xAI 的 Google Cloud Storage 存储桶里。而且，你关掉了所有改善模型的选项，它依然在传。
这不是猜测，也不是阴谋论。这是一位代号 cereblab 的开发者，用 mitmproxy 对 Grok Build CLI v0.2.93（2026 年 7 月版本）做了一次完整的网络抓包分析后，得出的结论。证据链完整，可复现，已开源在 GitHub Gist 上。
三个致命发现
.env 文件被完整上传，未做任何脱敏
cereblab 搭建了一个测试仓库，内部放置了带有金丝雀标记的假 .env 文件，然后用 mitmproxy 拦截 Grok Build 发出的所有 HTTPS 流量。结果令人震惊。
明文出现在两个通道中。
第一个通道是模型交互本身：POST /v1/responses 的请求体中，.env 文件的内容以原文形式随提示一起发送到了 xAI 的大模型推理端点。这让模型能够读取你的密钥——这在功能上或许可以理解，但隐患在于，这些内容被记录在 xAI 的对话历史中。
第二个通道更致命：Grok Build 会将整个 session_state 打包上传至 POST /v1/storage，而 xAI 服务器返回了 HTTP 200（接受成功）。这意味着，你的 .env 文件不但被模型读过，还被完整存档到了远程服务器上。cereblab 在二进制文件中找到了目标存储桶的名称：grok-code-session-traces，指向 Google Cloud Storage。捕获的 staged_metadata.json 中，每个文件的 fileId 字段直接写着 gs://grok-code-session-traces/repo_changes_dedup/v2/…/sha256_…。
整个仓库被完整上传，即使你没有要求它读
这可能是最令人不安的发现。
cereblab 做了一个更极端的实验：他给 Grok Build 的提示是 "reply OK, do not read any files"。然后，他通过抓包看到，Grok Build 仍然通过 POST /v1/storage → 200 上传了整个仓库的 git bundle。
捕获的 uploaded_repo.bundle 文件只有 152 KB，但用 git clone 恢复后，里面包含了一个 src/_probe/never_read_canary.txt 文件——这个文件是 cereblab 专门放置的，并且明确告诉 Grok Build 不要读取它。但金丝雀标记仍然出现在了上传的 bundle 中，连同完整的 git 历史记录，悉数被上传。
为了排除偶然性，cereblab 在另一个完全不相关的仓库（cereblab_auth Worker）上重复了实验，捕获了 uploaded_repo_auth.bundle（SHA-256: 0ee53653），git clone 后同样恢复出了金丝雀文件 CANARY-AUTH-4T8K2-NEVERREAD。
12 GB 仓库的沉默传输
规模测试的结果更加触目惊心。
cereblab 创建了一个 12 GB 的随机文件仓库，从未让 Grok Build 读取其中任何文件。然后启动 Grok Build，只要求它做最基本的回应。网络抓包数据如下：
/v1/storage（存储上传通道）：传输了 5.10 GiB，全部返回 HTTP 200/v1/responses（模型推理通道）：仅传输了 192 KB- 比值：约 27,800 倍
这个数字说明了一切。Grok Build 上传的不是它读了什么，而是你整个仓库的完整副本。模型推理通道的数据量极小，只包含最基本的提示和回应；而存储通道则像一条沉默的输油管道，无声无息地把你仓库里的所有内容泵到了 xAI 的云存储中。
关闭改善模型选项无效
xAI 在设置中提供了一个改善模型的选项，用户通常会认为关闭它就能阻止数据被收集用于训练。但抓包数据显示，即使关闭了该选项，/v1/settings 端点的返回中 trace_upload_enabled 字段仍然是 true。存储上传照常进行，HTTP 200 照常返回。
这不是 bug，这是架构选择
云端优先的架构设计
Grok Build 的架构设计是典型的云端优先模式。CLI 工具本身只是一个薄客户端，真正的工作——代码理解、推理、计划生成——都在 xAI 的服务器上完成。这意味着，每一行代码在本地被看到之前，已经被上传到了远程服务器。
这不是漏洞，而是架构选择。但问题在于，xAI 没有在安装流程、首次运行或任何文档中明确告知用户这一点。cereblab 在原文中写道：他没有在 CLI 的安装或快速入门材料中找到这一机制的任何说明。
全量上传是行业分水岭
AI 编程助手上传代码并非新鲜事。GitHub Copilot 会上传当前文件上下文，Claude Code 会上传项目结构和工作区文件，Cursor 有隐私模式。但差异在于选择性。
Grok Build 的上传策略是行业中少见的极端案例。你上传的不是这段代码有问题，而是这是我三年来写的所有代码，包括我删掉的版本。
全量 git 历史意味着什么
全量 git 历史的上传带来了几个层面的风险。
第一层是已删除的密钥。你曾经 commit 然后又 revert 的 API Key，仍然在 git 历史中。Grok Build 一并上传了。
第二层是业务逻辑演化。竞争对手可以通过分析你的 git 历史，了解你的产品是如何从 v1 演进到 v10 的，包括你放弃的方案和踩过的坑。
第三层是内部基础设施痕迹。CI/CD 配置、数据库连接字符串、内部域名，这些都可能在 git 历史中以某种形式留下痕迹。
第四层是法律和合规风险。对于处理 PHI、PII 或金融数据的公司，将完整仓库上传到第三方云存储可能违反 HIPAA、GDPR 或 SOC 2 合规要求。
xAI 为何选择这种设计
从技术角度，有几种可能的解释。
第一种解释是极致的产品体验。为了让模型获得最完整的上下文，xAI 选择了上传全部的策略——这样模型永远不会因为缺少上下文而出错。代价是隐私。
第二种解释是训练数据收集。即使关闭了改善模型的选项，上传仍然继续。trace_upload_enabled 始终为 true。这可能意味着，这些数据被用于模型训练之外的其他目的，例如产品改进、错误分析或未来模型训练。
第三种解释是设计疏忽。也许这只是一种先上线再优化的工程策略。但考虑到 xAI 是一家以安全著称的公司，马斯克多次强调 AI 安全，这种解释的说服力有限。
对开发者的影响与行业启示
你需要知道的事实
如果你是 Grok Build 的用户，或者正在考虑使用它，以下是你需要知道的事实。
第一，你的完整仓库（包括 git 历史）正在被上传到 xAI 的 Google Cloud Storage，即使你明确告诉 Grok Build 不要读取文件。
第二，你的 .env 文件中的密钥以明文形式被上传，出现在模型推理记录和存储备份中。
第三，关闭改善模型的选项无效，上传仍在继续。
第四，这些数据存储在 grok-code-session-traces GCS 存储桶中，而不是 xAI 自己的基础设施。
行业矛盾
Grok Build 的全量上传事件，暴露了 AI 编程工具一个更深层的行业矛盾：产品体验与用户隐私之间的本质冲突。
为了让 AI 助手更聪明，它需要更多上下文。为了让它在不联网的情况下也能工作，你需要本地模型。但 Grok Build 选择了云端全量处理的路线，而它的隐私开关形同虚设。
这不是 xAI 一家的问题。Cursor、Copilot、Claude Code——每一个 AI 编程助手都在读取你的代码和保护你的隐私之间寻找平衡点。但 Grok Build 把这个平衡点推到了极致的一端。
怎么办
在 xAI 官方回应之前，开发者可以采取的措施包括：在隔离环境中使用 Grok Build，不对敏感项目启用；使用 mitmproxy 等工具监控 Grok Build 的网络流量；等待 xAI 官方对 cereblab 的分析做出回应，明确数据存储策略和保留期限；考虑使用本地模型替代方案，如 Code Llama、DeepSeek Coder 等。
一个 CLI 工具，可以读取你三年前犯下的错误、你昨天写下的密钥、以及你明天要发布的商业计划。不是因为它被黑客入侵了，而是因为它被设计成如此。这才是真正的 AI 安全问题——不是 AI 会不会毁灭人类，而是你的代码，在你还不知道的时候，已经被送到了千里之外的服务器上。
快报