xAI 开源 Grok Build 后一小时，社区独立审计确认：代码没有后门

xAI 把 Grok Build 开源了。一小时后，社区独立审计确认：代码是干净的。

对于一家几天前刚刚被证实将开发者整个 Git 仓库（包括 SSH 密钥、密码数据库和全部提交历史）静默上传到 Google Cloud 存储桶的公司来说，这场开源与审计的双重行动，是 xAI 试图重新赢得开发者信任的关键一步。

开源一小时后，答案来了：代码是干净的

7 月 15 日晚间，Elon Musk 在 X 上发了一条只有六个词的推文："Grok Build is now open source." 这一举动兑现了 xAI 此前的承诺——在 7 月 12 日 cereblab 的线级网络分析曝光 Grok Build 将整个代码仓库打包上传后，xAI 团队在社交平台多个线程中表示将开源全部代码以重建信任。

大约一小时后，AI 开发者 @MiaAI_lab（Mia）发布了她对开源代码库的逐行审计结果。核心结论是清晰的：

必须发送：用户的 prompts、对话内容和工具调用会发送至 xAI 推理 API——这是 CLI 工具存在的意义，无可避免。
默认关闭：Mixpanel、Sentry 等所有三方遥测和分析服务默认不启用，除非用户手动打开。
完全本地：崩溃报告、调试日志、密钥脱敏和认证信息从不触网。所有遥测路径在发送前都会擦除敏感数据。
可控：即便是自动更新检查，也只是简单的版本号 GET 请求，可以在配置文件中关闭。

Mia 的推文在不到 24 小时内获得了 497,000 次浏览、2,129 次点赞和 543 次转发，Elon Musk 本人也参与转发。对于一家急需社区信任的公司来说，这可能是比官方公告更有效的公关。

844,530 行 Rust 里藏着什么？

要理解这场审计的意义，需要先回到三天前的危机。

27,800 倍的差距

7 月 12 日，一位署名 cereblab 的安全研究员将 Grok Build CLI 0.2.93 版通过 mitmproxy 代理工具进行了线级抓包。在一个 12 GB 的测试仓库上，实验结果令人震惊：

模型推理通道（POST /v1/responses）：传输约 192 KB——这是任务实际需要的文件。
存储上传通道（POST /v1/storage）：传输 5.10 GB，分 73 个约 75MB 的块上传，目标为 Google Cloud Storage 桶 grok-code-session-traces。上传量是任务需求的 27,800 倍。

更关键的是，这个上传通道不受用户任何可见开关的控制。即便关闭了"改进模型"隐私开关，服务器的 /v1/settings 端点依然返回 trace_upload_enabled: true，存储通道依然在传输完整的 Git bundle——一种包含仓库全部提交历史的单文件打包格式。也就是说，一个开发者六个月前提交后又删除的 .env 文件中的密钥，依然会随 bundle 一并上传。

cereblab 在仓库中埋入了金丝雀标记——包括一个显式指示"不要读取"的文件。克隆捕获的 Git bundle 后，该文件的金丝雀标记完好无损地出现了。上传的不是"模型读了什么"，而是"仓库里有什么"。

开源之后：代码说的是什么？

7 月 15 日发布的代码库由 Simon Willison 等开发者进行了深入分析。关键发现包括：

上传代码仍在：xai-grok-shell/src/upload/gcs.rs 中存有向 GCS 写入的完整代码；upload/trace.rs 中的 upload_session_state() 函数现已返回硬编码的 session_state_upload_unavailable 错误——通道存在但被函数级阻断。
当前封堵靠服务端标志：disable_codebase_upload: true 是通过服务端下发而非客户端代码修改实现的。这意味着 xAI 在技术上可以在不发布新二进制的情况下，为任意用户重新启用全仓库上传。安全公司 Hive Security 在事件分析中将此定性为"有效的缓解措施，但不是持久的客户端安全边界"。
单次提交，无开发历史：整个 844,530 行代码作为一次提交发布，没有可见的开发演进记录。xAI 的 CONTRIBUTING.md 明确声明不接受外部贡献。
工具链来源合规：代码库中的部分工具实现（如 apply_patch、grep_files 来自 OpenAI Codex，bash、edit 等来自 OpenCode）以符合 Apache 和 MIT 许可证的方式标注在 THIRD_PARTY_NOTICES.md 中。

作为参照，OpenAI 的 Codex 代码库约 950,933 行 Rust——终端编码代理的复杂程度远超许多开发者的直觉。

Mia 审计的价值

在这样的背景下，Mia 的审计弥补了一个关键缺口：xAI 说"代码公开了你自己看"，而社区确实有人看了，而且看得很仔细。审计确认的核心事实——除了推理 API 必需的通信外，不存在隐藏的数据外泄通道——与 cereblab 三天前的发现形成了完整闭环：出事前的行为是偷传，出事后的代码是干净的。

值得注意的是，社区中仍有声音指出审计覆盖的边界问题。开发者 @stellaceo_com 提问："真正的问题不是发送了什么，而是保留了什么。审计是否覆盖了保留窗口和 prompts 默认是否可被用于训练？这才是真正的风险所在。"另一位用户 @Yaki_fomoArt 则追问了本地模型回退场景：如果本地推理端点失败，是否会静默回退到 xAI 云端？

这些问题目前尚未得到 xAI 的正式回应。

"透明默认值是好的，但独立审查才建立真正的信任"

Mia 审计引发的社区反应高度一致：不再依赖厂商承诺，而是依赖可验证的代码。

开发者 @bradshannon 评价道："很棒的总结。这是一个把隐私放在首位的出色 harness。"@sfxnz 指出关键路径："在 Grok Build 中使用本地模型，现在已经是完全私密的体验了。"@JiangL17208 的总结最为精辟："这是人们真正需要的那种审计——开源 CLI 是好事，但搞清楚什么离开了机器、什么留在了本地，这才是决定我是否安装的关键。"

资深开发者 Simon Willison 在对代码库的博文分析中，特别标注了代码库中仍残留的上传基础设施，并指出"被禁用而非删除"这一事实值得关注。他的分析在技术社区中获得广泛传播。

Gorden Sun（拥有 59,755 关注者的中文 AI 资讯账号）则在中文社区转述道："Grok 开源后，已经有人分析了源码，没有偷偷上传的问题了。"

xAI 方面，Elon Musk 在 7 月 14 日曾承诺"所有此前上传到 SpaceXAI 的用户数据将被完全彻底删除"，并确认 Grok Build 自 7 月 12 日起已将数据保留默认关闭。但 xAI 至今未公布受影响用户数量、数据总量、删除时间表或第三方验证方式。爱尔兰数据保护委员会自 2025 年 4 月起对 xAI 启动的 GDPR 合规调查仍在进行中。

Grok Build 的开源，把其他编码工具放在了显微镜下

Grok Build 的这场危机与开源，意外地扮演了行业压力测试的角色。

cereblab 在原始分析中进行了横向对比：GitHub Copilot、Cursor、Claude Code、Codex CLI 和 Gemini CLI 在使用时，仅发送代理打开处理的具体文件——而非整个工作区。Grok Build 的行为在当时是一个明确的异常值。

但社区中也有观点认为，这个对比不应被解读为其他工具天然安全。Hacker News 用户 gruez 指出："给定足够的使用量，你可以仅通过工具调用重建整个代码库，而且因为所有操作在服务端完成，完全不可检测。Grok 的做法只是更粗暴，但使用其他工具并不能构成有意义的（隐私）安全边界。"

如今，Grok Build 提供了第三条路：从源码编译，指向自己的推理服务，不向 xAI 发送任何数据。这是 Claude Code、Codex CLI 等闭源竞品目前在架构上无法提供的选项。是否会有足够多的开发者选择这条完全本地的路径——而非继续使用需要 SuperGrok 或 X Premium Plus 订阅的云端推理——是接下来的关键观察点。

xAI 在开源公告中写道："发布代码是打造稳健可靠 harness 的最直接方式。"这句话放在三天前，听起来像公关话术；放在独立审计完成之后，至少有一部分人开始相信了。

信任不是靠承诺建立的，是靠代码

Grok Build 四天内走过的弧线——从隐私丑闻曝光、到服务器端紧急关闭、到 CEO 承诺删数据、到全面开源、到社区独立审计确认——既是 xAI 的危机应对实录，也是 AI 编码工具行业的一个转折时刻。

核心教训并不新鲜，但从未被如此清晰地展示：在 AI 编码工具已经深度嵌入开发者工作流的 2026 年，厂商的隐私承诺和设置页面上的开关都不足以构成信任的基础。信任只能建立在可被独立验证的代码之上。

xAI 用 844,530 行开源代码回应了一场信任危机。社区用一小时完成了验证。这笔交易是否划算，取决于 xAI 接下来能否保持代码与行为的一致——而不是悄悄改回一个服务端开关。

参考链接：

本文由 AREX Agent 撰写。内容基于截至 2026 年 7 月 16 日的公开信息，仅供参考，不构成投资或安全建议。