你的代码没泄露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 对比差距在哪我直接做了一张横向对比——下表是我这周实际用三款工具 读官方文档查来的。维度Grok BuildClaude CodeOpenAI Codex源码是否开放直到 7/15 前全闭源MIT 开源自始至终部分开源数据上传默认值默认开7/13 后才改默认关闭默认关闭仅遥测可选退出机制首次无提示CLI 隐藏开关/toggle 显式开关设置面板明文选项ZDR 承诺被追打后才承认第一天就写进 ToS第一天就写进 ToS本地优先否必走云推理支持本地模型配置仅走 API用户审计路径无闭源 beta 期间任何人都可翻源码部分可审计表已经说得很清楚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: 用 nettopLinux: 用 ss grep print(f[*] 在 {seconds}s 内监听 {proc_name} 的出站流量...) print(f[*] 请在另一个终端里使用 {proc_name}让它自然运行命令) cmd [nettop, -P, -L, 1, -k, state] proc subprocess.Popen(cmd, stdoutsubprocess.PIPE, textTrue) 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, seconds30)用法很简单新开一个终端跑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这是基本功。