你的 AI 编程工具,可能正在偷传你的整个工作区

“

上传是从你机器上发生的，但你连自己解密看看里面有什么都做不到。

—— 小谢不开摆

9 月 18 号晚上，一个叫 ferstar 的开发者清理本地磁盘，顺手看了一眼 ZCode 的网络请求。

然后他愣住了。

据他贴出的抓包记录，这个他每天都在用的 AI 编程工具，正在把他整个工作区打包、加密、上传到阿里云。不是当前这个项目，是整个工作区——包含完整的 Git 提交历史、LFS 大文件缓存、reflog 操作记录，还有一部分全局开发配置。

据他实测，一次快照约 4.2 万个文件、313MB，其中 .git 目录占了 86.6%。

更让人后背发凉的是两个细节：按爆料时的情况，这个上传是默认开启的，客户端设置界面里找不到关闭选项；加密用的 RSA 公钥由服务端动态下发，私钥只存在云端——也就是说，上传是从你机器上发生的，但你连自己解密看看里面有什么都做不到。

这件事到今天（9 月 21 日）还没收尾。而它值得每一个用 AI 工具干活的人认真看一遍。

📌 本文看点

把节奏捋一遍，你会看到一场典型的现代危机公关：

一家企业的数据主权问题，最后用股价曲线画了出来。

全网都在骂“偷传数据”，但我觉得更值得讨论的是：这为什么会被做成默认开启？

理解一下 Coding Agent 的处境。要给你生成代码仓库知识库、要支持跨会话的历史回溯、要做上下文检索——它就必须读你的全部代码。这在技术上几乎没得选。所有做 Coding Agent 的团队，都在做同一件事：为了服务你，先读完你的一切。

问题不在“读”，在三个边界的缺失：

第一，默认开启。

把一个会外发数据的开关做成出厂默认，是拿用户的资产给厂商的功能做数据燃料。用户不知情，就不是授权。

第二，无法关闭。

设置界面里找不到选项，等于剥夺了用户的判断权。你没法选择“我不用这个功能”。

第三，不可验证。

加密私钥只在云端，用户本地无法解密。也就是说，官方说“只用于生成 Wiki、随后销毁”，你只能选择相信，没有办法自己确认。

而中信建投证券今天的点评，一句话点到了要害：

开源之后，开发者能直接检查数据调用、网络请求、本地代码处理逻辑——产品从“相信公司”转向“可以自己验证”。

所以这件事的真正教训，不是“某家公司不老实”，而是：当一个工具要求访问你的全部文件时，“可验证”应该比“可信”更重要。

事后看，智谱的动作其实挺标准，一共五步：

覆盖了技术修复、外部审计、代码透明、数据政策、社区治理五个层面，算得上系统性回应。

但要打分的话，扣分扣在第一步：把“设计选择”说成“功能默认开启”。措辞上像是在讲一个配置失误，而用户愤怒的点恰恰是——这个配置是你设计的。

信任这东西有个特点：重建速度永远慢于损毁速度。据媒体报道，另一位企业用户张楠的回应更直接——九个私仓、四个上线项目、所有服务器凭据都已被打包上传，他已经和法务固定证据、先发函、后续考虑起诉。开源代码能不能被有效审查、“数据不留存”能不能真正落地，都还需要时间证明。

不管你用不用 ZCode，只要你用 AI 编程工具，这五步值得今晚花二十分钟跑一遍：

把镜头拉远一点，这件事其实是一个预告。

我们正在把越来越多的上下文权限交给工具。Agent 越能干，需要读的东西就越多——读你的文件、你的邮件、你的日历、你的聊天记录，才可能替你干活。这个交换看起来很划算，但它的前提是：你知道它读了多少、拿去做了什么、存在哪里。

这三件事，目前很少有工具能讲清楚。

对一人公司来说，这一点尤其要命。你的代码、你的素材、你的客户资料、你的账号凭据，就是你的全部生产资料。工具的权限边界，就是你的资产边界。你不可能像大公司那样养一个安全团队，你能做的，是选那些“敢让你自己验证”的工具。