你的 AI 编程助手,在上传什么?

清理电脑的时候，他发现自家目录里多出了 700 多兆。

里面是打包好的整套代码库：完整的 Git 历史、删过的密钥、团队的提交记录。它被卡在本地的待上传队列里，此前已经连续 564 次重试失败。

让这批开发者紧张的，恰恰是这份没有传上去的东西。

【发生了什么】

9 月 18 日，开发者 ferstar 在博客里披露，智谱的 AI 编程工具 ZCode 在用户登录状态下，会把整个工作区打包成加密文件，后台上传到阿里云 OSS。

被打包的不只是当前代码。.git 目录里的提交历史、LFS 大文件缓存、reflog 操作记录和全局开发配置，一并打包成 tar.gz。加密用的公钥由服务端下发，私钥只在云端，用户在自己机器上解不开自己的文件。

当天傍晚，智谱在官方用户群致歉，把原因归到"代码库索引"功能：它用于支撑会话检查点恢复、历史版本回退和 Repo Wiki，而 Repo Wiki 生成页面时会触发数据上传。官方称数据生成 Wiki 后立即销毁，问题出在该功能上线初期默认开启、客户端里没有可关闭的开关。

9 月 19 日，v3.14.0 推送，更新日志写明修复仓库百科异常上传。同日，太原承明科技向北京智谱华章发出公开函件，提出 12 项书面答复要求，限期 10 月 10 日前回复。

9 月 21 日上午，ZCode 在 GitHub 开源，同步公布中国信通院与绿盟科技的两份第三方结论：涉事 OSS 存储桶为云端零数据，对象与桶本身均已删除，新版客户端未发现可触发本地快照或文件外发的路径。

【技术拆解】

AI 编程工具要理解一个项目，必须跨越"读一行"和"懂全貌"之间的距离。为了建立项目底稿，工程上常见做法是先把本地工作区整体快照，再决定要不要传、怎么传。

问题出在第二步。打个比方：你想让助理看懂一份档案，合理的做法是他在你办公室里翻；而现在不少实现，是把整柜连胶带带货一起寄走，看完再寄回来。

真正被审核的是 .git。你三年前误提交过一次数据库口令，后来删了、也加进了 .gitignore，但明文永久留在历史对象里。.gitignore 管不了这些已进历史的东西。

还有一个更隐蔽的点：**加密只解决传输途中被谁截获，不解决云端能不能解开。**私钥在厂商手里，所谓"用完即销毁"就成了一句无法从外部验证的承诺。

【为什么这次不一样】

这里有一个多数转载都写错的地方。广为流传的"313MB 商业代码库被上传"，根据技术取证实际结果是：那个包在原作者机器上停留了很久，连续上传失败数百次，没有离开本机。技术分析目前能确认由服务器接收的，是一个约 538 个文件的小型公开代码库，压缩后大约 15KB。

这不等于替厂商开脱。恰恰相反，它把问题照亮得更清楚了：**让人不安的不是"损失了多少"，而是"这条链路默认存在"。**一个产品可以在实际损失接近零的情况下丢掉信任，因为它越过的那条线叫未经同意。

第二层是品类变了。过去的模型是网页对话框，监管焦点和用户的注意力都在输出内容安不安全。现在的编程智能体同时握有本地读写权限和网络出口，能力与权限天生同源。这不是某家公司心术不正，而是这类产品绕不开的结构。

说到这里要停一句：这件事里没有"AI 自己想偷数据"。它既没有意识，也不需要意识。一段按既定逻辑跑的代码出了问题，就是出了问题，把它写成科幻反而会掩盖真正需要查的地方。

【对普通人的影响】

第一，花三分钟看一眼本地目录。ZCode 的用户可以查 ~/.zcode（macOS、Linux）或 %USERPROFILE%\.zcode（Windows）的体积和待上传队列，这是社区实测给出的位置。用别家工具的，同样值得去它的本地数据目录翻一遍，看有没有超出预期的打包痕迹。

第二，把凭证按"已经泄露"处理一轮。凡是在项目历史里出现过的数据库口令、接口密钥、云服务凭证，现在就去轮换。删文件和加 .gitignore 都挡不住已经进了 .git 历史的明文。

第三，企业采购时别只读隐私政策的文字。拿客户端实际请求的域名去比对签约主体，两者对不上就得问清楚；把零数据留存、删除证明、外发审计写进合同条款，而不是写进对方的宣传稿。

把客户端开源，解决的是"能不能被检查"，不是"下一个版本会不会再长出手"。这类产品注定要把代码读写权和网络出口同时交给同一个程序，我们既然接受了这份便利，就得认下它附带的义务：每一次版本更新之后，重新查一遍它往外发了什么。