你的代码没泄露？Grok Build 默认上传那个坑，连 Anthropic 都不敢踩

你的代码没泄露？Grok Build 默认上传那个坑，连 Anthropic 都不敢踩

Gigazine 今早炸了一篇报道——标题直接怼脸："SpaceXAI 的 Grok Build 一直在往服务器传代码，默认就是开着的。"

我读完脊背发凉，不是因为它新，是因为我昨天刚写过。在上一篇"Grok Build 开源了"里我建议大家去翻源码看 extension system，还强调"你终于有机会看清黑盒"——好吧，现在黑盒直接自己爆开了：黑盒里面就装着你传上去的代码。

Musk 今天下午被迫承认，措辞还是那种经典的"我们一直在优化体验"。措辞下面的事实却很硬：Grok Build 从第一天起，就默认把用户的编码数据上传到 SpaceXAI 服务器。你说你关了？他们说你关了他就认——可他默认就是开的。

一、那个默认开启的上传，到底传了什么？

Gigazine 扒出来的信息量很大，但核心就一段：Grok Build 的 CLI 里埋了一个 Telegraf 监控代理，负责把"编码过程中产生的数据"打包上报。代码片段、diff、错误堆栈——只要你没主动关掉，全自动往外吐。

Telegraf 这个角色大家应该熟，Metrics 采集器。Grok Build 拿它当数据管道，把用户在 terminal 里的一举一动变成一条条打点日志，推回 SpaceXAI 的后台。名义上是"改善产品体验"——潜台词是你的代码就是训练素材。

这事有一个特别容易被忽略的点：Grok Build 是闭源 beta。用户在用的 5 月到 7 月这段时间，没有一个人能去翻源码确认"你到底传了什么"。这和 Anthropic 的 Claude Code 正好反着——Claude Code 从第一天就开在 GitHub 上，所有数据流向社区都能审计。闭源 + 默认上传 = 用户只能靠厂商自己说。

更让人不安的是上传内容的粒度。根据 Gigazine 对早期 beta 用户的采访，Telegraf 上报的不只是"你执行了什么命令"这种元数据——它会把命令的输出、报错信息、甚至部分代码片段一并打包。也就是说，你在 Grok Build 里调试一段涉及数据库连接串的代码，那段连接串可能已经躺在 SpaceXAI 的日志服务器上了。

二、SpaceXAI 三次回应，三次打自己脸

看看 SpaceXAI 官方博客的时间线——

5 月首发：博客里埋了一行小字说"可选择退出数据上传 (opt-out)"。注意用词：可选择退出。翻译成人话就是"默认不退"。没有弹窗，没有高亮，没有首次启动的确认对话框。

7/13 Gigazine 报道当天：SpaceXAI 紧急改口说"其实我们用的是 zero data retention (ZDR)"。ZDR 是 Anthropic 先提的——意思是你传的数据不留存、不训练、你们走了就删。但你仔细看 SpaceXAI 的措辞："从一开始就尊重 ZDR"——从头到尾没承认数据确实上传过，只是说"我们删了"。

7/13 晚：更进一步承认上传功能默认开启，并把默认状态改为关闭。注意，这是被记者追着打之后才改的，不是在第一个用户投诉时就改的，更不是在设计阶段就规避的。

三次回应三连套：先淡化→再甩锅 ZDR→最后被迫改默认。每一步都是把"我们已经做的事情"重新包装成我们"一直在做的事情"——危机公关的标准范式。

我特别想追问一句：如果 Gigazine 没挖出来，SpaceXAI 打算什么时候主动承认？答案是永远不会主动承认——因为用户根本不知道数据被上传了，没有任何动力去问这个问题。这就是"默认开"最可怕的地方：它利用的不是用户的许可，而是用户的无知。

更值得警惕的是，Grok Build 不是孤例。过去一年里，我至少见过三款 AI 工具用同样的套路——默认开启数据上报、把开关藏在 CLI 参数深处、被曝光后才紧急改成默认关。这不是"个别公司的道德问题"，这是整个 AI 工具行业的结构性惯性：先拿数据，再谈合规。

这种惯性背后有一个冰冷的事实：AI 模型的护城河不是参数量，是数据飞轮。谁先拿到 100 万个真实 coding session 的日志，谁的下一代模型就更懂开发者。Grok Build 默认上传的本质，就是用"免费工具"换"训练数据"——用户以为自己在白嫖，其实自己就是产品本身。

三、和 Codex / Claude Code 对比，差距在哪？

我直接做了一张横向对比——下表是我这周实际用三款工具 + 读官方文档查来的。

表已经说得很清楚：Anthropic 和 OpenAI 敢把"默认关闭 + ZDR"写在第一天，是因为他们把选择权真真切切地交给了用户；SpaceXAI 是先把事情做了，再在被发现后给用户一个可以关掉的选项。这不是技术差距，是默认值的差距——默认值背后是立场的差距。

下面这张图把三款工具的数据流向画出来了——你可以一眼看出 Grok Build 那条"默认上传"的线有多刺眼。

四、为什么开发者还在往火坑里跳？

这里我想说一点不舒服的真相。Grok Build 事件出来之后，我刷了一遍社区讨论，发现一个很反直觉的现象：骂得最凶的人，往往也是冒险在用 beta 版的生产人。

为什么？三个驱动力——

第一，模型宣传太诱人。"Grok 4.5 benchmark 创纪录""Plan mode 自动规划任务"——对一个天天跟 deadline 赛跑的工程师，这些标签的引力远大于角落里那行"默认开启数据上传"。人在被性能承诺吸引时，风险敏感度会自动打折。

第二，"我用的是副项目代码"的错觉。几乎每个用户都这么想——"我 Grok Build 里跑的不是核心业务代码，传了又怎样"。但真正写代码的人都清楚，副项目里的代码片段往往藏着架构思路、接口命名、业务逻辑的组织方式——这些才是最值钱的部分。

第三，信任品牌的光环。SpacexAI + Musk，这个组合在很多人眼里自带"技术领导"滤镜。领导者的产品让用户不自觉地放松审计意识。Anthropic 就聪明，它把自己绑在"安全"这个标签上，让用户天然带着警惕去用它——结果用起来反而更踏实。

这不是受害者有罪论，这是一次很典型的人机信任错位：我们把"技术领先"和"道德可靠"混为一谈。

五、5 分钟自检：你的 AI 工具在偷传什么？

我写了一段脚本，能帮你即时检查新装 AI CLI 工具的网络流量方向。它不是银弹，但它能让你第一次装工具的那一晚就发现端倪。

#!/usr/bin/env python3 """ai_tool_sniffer.py — 监控 AI CLI 工具的网络出站，检测是否意外上传代码""" import subprocess, sys, time from datetime import datetime def monitor_process(proc_name: str, seconds: int = 30): """监控指定进程 name 的出站连接（仅 macOS / Linux）""" # macOS: 用 nettop；Linux: 用 ss + grep print(f"[*] 在 {seconds}s 内监听 {proc_name} 的出站流量...") print(f"[*] 请在另一个终端里使用 {proc_name}，让它自然运行命令") cmd = ["nettop", "-P", "-L", "1", "-k", "state"] proc = subprocess.Popen(cmd, stdout=subprocess.PIPE, text=True) outgoing = set() start = time.time() try: for line in proc.stdout: if time.time() - start > seconds: break if proc_name.lower() in line.lower() and "Established" in line: parts = line.split() if len(parts) >= 3: dst = parts[2] if any(k in dst for k in ["api.", "ingest.", "telemetry.", "metric."]): outgoing.add(dst) finally: proc.terminate() print(f"\n=== 检测完成 {datetime.now().strftime('%H:%M:%S')} ===") if not outgoing: print("[+] 未发现遥测 / 数据上传域名（在测试窗口内）") return print(f"[!] 发现 {len(outgoing)} 个疑似遥测域名：") for d in sorted(outgoing): print(f" → {d}") print("\n建议：") print(" 1. 去官方文档搜 'telemetry' / 'data collection'") print(" 2. 找 opt-out 开关（环境变量 / 配置文件）") print(" 3. 找不到就默认不信任，换工具") if __name__ == "__main__": target = sys.argv[1] if len(sys.argv) > 1 else "grok" monitor_process(target, seconds=30)

用法很简单：新开一个终端跑python ai_tool_sniffer.py grok，然后在另一个终端里正常使用 Grok Build 做点事情——30 秒后脚本会列出所有连出去的域名。看到 telemetry / ingest / metric 开头的域名，就该警觉了。

当然，这招对闭源工具只能看到域名，看不到内容。但"能看到谁在传"已经比"完全不知道"强一个量级。你不需要成为安全专家，你只需要在装工具的第一晚多跑一条命令。

另外还有一个更粗暴的兜底：把 AI CLI 工具放进 Docker 容器，只给它挂载当前项目目录，不给它访问 ~/.ssh、~/.aws、~/.gnupg 的权限。这样即使它想传，也传不出你的密钥。

我把这套自检流程整理成一个 checklist，每次装新 AI 工具都会过一遍——

• 查源码：工具是否开源？不开源就默认不信任
• 查默认值：数据上传默认开还是关？默认开就改配置
• 查 ZDR：有没有 zero data retention 承诺？没有就假设数据会被训练
• 查退出路径：opt-out 开关藏在哪？找不到就换工具
• 跑流量监控：装完第一晚跑一次 sniffer，看有没有可疑域名
• 隔离执行：敏感项目放进 Docker，限制文件系统访问权限

六、从 Grok Build 追问：AI 工具的"默认值"到底该由谁定？

这次事件让我反复想一个问题：AI 工具的默认值，到底是产品决策还是伦理决策？

表面上，"默认开启数据上传"是一个产品选择——降低新用户的上报门槛，让团队更快拿到反馈。但当你把"代码"这个特殊数据类型放进来，它就不再是产品问题——代码是开发者最核心的知识产权。默认开启上传，等于默认把用户最值钱的东西让渡出去。

Anthropic 的 Claude Code 做了一个很好的示范：默认关闭上传，但把 ZDR 写进 ToS，把审计路径交给开源社区。这不是"不会做上传"，是主动选择不做。OpenAI 的 Codex 也是类似路线——默认关闭，用户主动选择才开。

反观 SpaceXAI，它不是技术上做不到"默认关闭"——7/13 之后它不就改了吗？它只是在"默认开"的这段时间里，已经拿到了足够多的数据。这才是让人最不舒服的地方：不是不能改，是改之前已经吃够了红利。

我无意把 SpaceXAI 钉在耻辱柱上——Grok Build 开源本身是一件好事，它让社区终于能审计这个黑盒。但开源不能成为"先上车后补票"的借口。你不能用"我们后来开源了"来为"我们之前偷传了"辩护。

这件事给所有 AI 工具开发者提了一个醒：默认值不是产品细节，是立场声明。你默认开什么，就代表你默认用户愿意让渡什么。

而对我们这些每天用 AI 写代码的人来说，提醒更简单——装任何新 AI 工具的第一晚，先跑一遍流量监控，再决定要不要把它接进生产项目。这不是 paranoid，这是基本功。