一个 313MB 的加密包:AI 工具悄悄上传了整个项目

title: 一个 313MB 的加密包：AI 工具悄悄上传了整个项目date: 2026-09-23category: 社会热点

事情是从一个文件夹开始的。

9 月 17 日晚上，一个网名叫 ferstar 的开发者，还在技术群里跟人安利 ZCode——智谱出的那款 AI 编程工具。

第二天他就被"打脸"了。

9 月 18 日，他清理本地磁盘，发现用户目录下的 ~/.zcode 文件夹，占了 700 多 MB。

顺着查下去，他找到一个 313MB 的加密文件。状态文件显示，这个包对应的是他某个 10GB 大小的商业项目，"几乎全是核心资产"——而它之所以还躺在本地，是因为上传失败，失败了 564 次。

如果那 564 次里成功了任何一次，这件事到现在也不会有人知道。

它到底传了什么

为了搞清楚这东西要往哪去，他把客户端程序包拆开做了逆向分析。

结论是这样的：只要用户处于登录状态，ZCode 桌面端就会在后台，把整个工作区加密打包，直接传到阿里云 OSS。

打包的不只是当前项目的源代码。还包括：

完整的 Git 版本历史、LFS 大文件缓存、reflog 操作记录，以及部分全局开发配置文件。

这是什么意思？相当于把你一个项目从头到现在的每一次修改记录、删掉过的内容、没提交的草稿、以及一些早就从当前代码里移除的敏感信息，全部打成一包。

举个具体点的例子。你曾经在代码里写过一次数据库密码，后来意识到不妥，把那一行删了。在当前代码里，它确实没有了。

但在 Git 的历史记录里，它还躺着——版本控制的设计初衷，本来就是保留每一次修改。

所以一份「完整的 Git 历史」，往往比当前代码本身更敏感。

还有一点更让人不舒服。

加密用的 RSA 公钥是服务端动态下发的，私钥只存在云端。也就是说，本地那份几百兆的密文，连他自己和客户端都解不开。

有开发者还发现，即便在设置界面手动关掉数据上传开关，后台进程仍在继续传。

之后发生了什么

9 月 18 日当天，智谱在官方用户群里致歉。

他们的解释是：问题出在一个叫**「代码库索引」的功能上。这个功能是为了支持历史版本回退、会话恢复和 Repo Wiki（代码仓库知识库）。生成 Wiki 页面的时候，可能会触发仓库数据上传。而这个功能上线初期是默认开启的**。

智谱强调，上传的数据只用于在云端生成 Wiki 页面，页面生成后会立即销毁，不予保存。

之后的几天，动作很密集：

9 月 19 日，推出修复版本。9 月 20 日晚，宣布 MaaS 平台上线**「数据内容不留存」**功能，并承诺开源 ZCode、邀请中国信通院做安全审计。9 月 21 日，ZCode 正式开源，同时说明整改已完成，由信通院和绿盟科技完成审计。

从致歉到开源到第三方审计，五天里走完了五步。有分析认为，这已经是国内同类事件里处理得比较快的一次。

同期还有一些细节：智谱给全体 ZCode 用户额外提供了一次周额度重置作为补偿；并明确表示，从未将相关云端数据用于模型训练。这一条后来被券商研报引用，作为「对后续模型训练没有影响」的依据。

市场也给了反应。9 月 21 日，智谱港股股价早盘承压，盘中一度跌超 5%。

但争议没有就此停下。

为什么道歉了，还是没平息

有两个关键的疑问，我觉得值得说清楚。

第一个是时间点。

9 月 20 日，太原一家科技公司正式向智谱发出函件，要求就数据删除、私钥保管、以及是否发生跨境传输作出书面说明，并保留索赔与诉讼的权利。

他们的理由是：公司技术部门独立取证确认，ZCode 的上传是自动触发、批量发生的；而且道歉当日的凌晨，仍有上传记录。

他们质疑上传目的地是香港的阿里云 OSS 存储桶，涉及数据出境。

第二个，是「不留存」这三个字到底管什么用。

浙江大学网络空间安全学院的副教授张秉晟有一句话说得挺直白：

「数据不留存，不代表数据没有出域。」

意思是，数据在服务器上没落盘，和它没有离开你的机器，是两回事。在传输和生成页面的那个过程中，风险窗口是存在的。

一位企业用户（报道中化名张楠）的说法更具体。他说自己公司用 ZCode 已经很久，九个私有仓库、四个已上线项目、所有的服务器凭据，都已经被打包上传了。他已经和法务固定了证据，先发函，后续考虑起诉。

他的观点是：「索引和 Git 全历史是两回事。一个是字典目录，一个是整本字典，还包括以前的版本。」

还有一个细节：目前开源的 ZCode，是新建的仓库，不是最初的版本。有开发者认为，这样的开源"意义不大"。

据媒体报道，已经有公司在内部停用了 ZCode。

这件事，跟你有什么关系

你可能会想：我又不写代码，这跟我有什么关系。

我觉得至少要关心三件事。

第一，这不是第一次，也不会是最后一次。

同样的事情在此之前已经发生过两次——Claude 和 xAI 的 Grok 先后卷入过类似争议。有报道提到，Grok 的编程工具被发现把用户整个 Git 仓库打包上传到谷歌云存储。

而快思慢想研究院的一位评论员说得很实在：「默认开启的代码库采集功能」，是这个行业的普遍现象，不是某一家公司的疏忽。

也就是说，问题不在某个具体的产品，在于这行的产品设计习惯。

第二，判断标准不该只看「有没有传」，还要看「传了之后谁能解开」。

这次最让人不安的一点，其实不是上传本身。

是私钥只在云端。你本地生成的那份密文，你自己解不开——这意味着你对这份数据的控制权，实际上已经交出去了。

以后再评估一个 AI 工具，除了看它要不要上传，还可以问一句：这些数据在哪、谁能看到、什么时候删、我能不能验证。

第三，普通人也能做的几件小事。

一、翻一下你常用 AI 工具的设置里，有没有「索引」「知识库」「云端同步」这类开关，以及它是开还是关。

这类功能往往就是为了让回答更准，所以默认开着。默认开着本身不算错，但你得知道它在。

二、别把最敏感的东西交给还没验证过的工具。

密码、私钥、身份证照片、客户名单——这些东西放进去之前，先想一秒：如果它被传走了，最坏的结果是什么。

三、企业用户，把数据边界写进采购流程里。

这次出来维权的，恰恰是公司用户。个人开发者丢的可能是一个练手项目，公司丢的是核心资产和服务器凭据。买工具之前，问清楚数据出域规则，比事后再追责成本低得多。

四、如果你已经用过，别慌，但值得做一次清理。

先看看本地的工具目录里有没有堆积的打包缓存——这次的线索，就是从一个 700 多 MB 的 ~/.zcode 文件夹里翻出来的。发现异常的大文件，删掉它，然后把项目里用过的密钥和口令轮换一遍。

尤其是企业团队。凭据这种东西，一旦出过域，换掉是唯一稳妥的做法。

最后一句话

这事的定性还在走。智谱已经致歉、修复、开源、请了第三方审计；批评的一方认为「数据不留存不等于没出域」，要的是可验证、可追责的长期机制。两边说的都有各自的道理，结论等监管和司法一步步给。

但有一句判断，我觉得不太会变。

AI 工具这几年进步得太快，快到我们习惯了把东西直接交给它——代码、文档、病历、合同，甚至整台电脑里的文件夹。

而它的数据规矩，明显没跟上它的能力。

下次把一个文件拖进某个 AI 工具之前，多问一句它拿去做什么。就一句，可能就够了。