你让一个 AI 编程助手整理项目，原以为它只会读取必要文件，后来却发现整个目录都可能被传到云端——如果里面混着密钥、密码库或私人照片，问题就不再只是“功能设计欠妥”，而是你还能不能信任它。
本刊 7 月 15 日报道过，逆向分析者在一次受控测试中观察到 Grok Build 上传完整代码库。如今，xAI 公开了 Grok Build 源码，争议由外部猜测进入社区检查客户端实现的新阶段。但开源能解释电脑这一端做了什么，不能自动证明云端如何保存和使用数据。
先把“黑箱外壳”打开
Grok Build 是 xAI 面向软件开发任务的编程 Agent——不只回答代码问题，还会读取文件、调用命令并执行任务。此次开放的是它的 Agent 外壳（harness），也就是连接模型、文件系统、命令行和权限控制的程序层，其中包括 Grok Build CLI 的代码仓库。CLI 指用户在终端里直接运行的命令行工具。
开放这层代码的意义很直接：社区现在可以检查它收集哪些上下文、何时读取文件、怎样调用工具，以及权限设置是否真正生效。这种系统性检查叫代码审计。
据 Simon Willison 的报道，整个代码库采用 Apache 2.0 许可证发布，约含 844,530 行 Rust 代码，其中约 3% 是 vendored code——随项目一同收进仓库的外部依赖代码。体量不小，真正完成审计不会是一夜之间的事。
官方同时宣布重置所有用户的使用限额。Grok Build 也可以采用 fully open-sourced、local-first 的方式运行，并接入用户自己的 inference，也就是由用户选择的模型推理服务。所谓 local-first，是优先在本地掌控程序与数据流，并不天然代表所有环节都不联网；实际边界仍要看配置和代码行为。
争议核心不是“有没有开源”
据 Simon Willison 报道，此前在某个目录中运行 Grok Build，可能把整个目录上传到 xAI 使用的 Google Cloud buckets，即云端存储空间。一名用户自述，他在个人主目录运行工具后，看到 SSH keys、密码管理器数据库、文档、照片和视频等文件被上传。材料未提供这份报告的原始记录，因此它只能作为用户自述，不能推断所有用户都经历了同样情况。
报道还称，相关上传功能已在社区反弹后停用。xAI 官方表示，早期测试版曾对没有选择 ZDR 的用户默认启用数据保留；ZDR 是 Zero Data Retention，即服务方不保留用户提交的数据。从 7 月 12 日起，Grok Build 已为所有用户默认关闭数据保留。
这是实质性改变，但“默认不保留”不等于整个数据链条完全透明。网络传输、运行日志、遥测信息，以及第三方推理服务如何处理数据，不能仅凭这一项设置得出结论。
为什么现在值得追踪？
开源至少把信任问题变成了部分可验证的问题。此前，外界只能通过网络流量和程序表现逆向推测；现在，研究者可以直接沿着源码检查文件读取、上传路径和权限控制，并提交修复。
不过，“开源灭火”更适合作为对时间顺序的概括，而不是已经证实的动机。xAI 在争议后很快公开源码，评论者认为此举意在挽回信任，但现有材料没有证明两者之间的官方因果关系。
真正的考验也才开始：社区能否从庞大的代码库中复核官方隐私承诺，发现的问题能否获得及时修复，以及公开实现与用户实际运行的版本是否一致。
局限与未知
- 公开仓库当时只有一个发布代码的 commit，也就是一次提交记录，无法据此追溯功能如何形成、上传逻辑何时加入或修改。
- 官方对历史 coding data 使用过“将删除”“正在删除”和“已删除”等不同表述；此前保留的数据是否已经全部清除，尚无独立审计确认。
- 客户端源码可供审计，但不能单独证明服务端的数据保存、日志和使用方式。xAI 所称的“完整用户隐私”，目前仍是需要验证的承诺。