一个开发者清理电脑磁盘时，发现用户目录下的 .zcode 文件夹占了 700 多 MB。其中最扎眼的一份 313MB 加密文件，状态记录显示，它来自他电脑上某个约 345MB 的商业项目，被打包、加密，反复尝试上传，失败了 564 次，一直卡在本地。

这个人叫 ferstar。9 月 18 日，他把完整的逆向调查发了出来。智谱的 AI 编程工具 ZCode，由此踩进一场信任危机。而这场危机，值得每一个把代码交给 AI 工具的人看一眼。

一、它到底传了什么

很多人第一反应是，不就是上传点代码吗，AI 编程工具本来就要读代码。错。ferstar 拆开那份加密包的清单，42411 个文件里，源码和文档只占 13.4%，剩下的 86.6% 是 .git 目录，也就是完整的版本修改史。

Git LFS 缓存占 56.8%，提交历史对象库占 29.6%。这意味着，你早就删掉的密钥、改过的配置、没推送到远端的本地分支、藏在 .git/config 里的内网域名，全都在里面。你以为传走的是当前几行代码，实际被端走的是整个项目的全部历史。智谱后来也承认，部分用户的仓库数据，确实被传到了云端。

二、最吓人的三个细节

第一，这包你解不开。加密用的 RSA 公钥由服务端下发，私钥只存在智谱云端。也就是说，连你自己都打不开这份被上传的密文，能解开的只有对方。

第二，你关不掉它。软件界面上有两个开关，一个管数据能不能拿去训练模型，一个管云端建不建索引，没有一个能关掉本地打包和上传。开发者手动删掉那份待传包，半小时后，软件又默默生成了一份。

第三，它绕开了自己的业务服务器，直接把文件传到了阿里云对象存储，由云端回调确认。ferstar 在一次正常使用里，数到了 62 次快照记录。这已经不是什么功能设计的副产品，而是一条默认常开、用户无法干预、数据最终捏在别人手里的上传链路。

 

三、智谱道歉了，但三个问号没解开

9 月 18 日傍晚，智谱在用户群里致歉，说问题来自一个默认开启的"代码库索引"功能，数据用完即销毁，不会保存，并承诺开源客户端、引入第三方审查、补偿一次周额度。

话音刚落，疑点就来了。第一，影响范围有多大。智谱只说"部分用户"，没说这个功能默认开启过多久、涉及哪些版本、多少仓库真的传成功了、里面有没有企业私有代码。

第二，历史数据真删了吗。"用完即销毁"是企业单方面声明，外部研究者能查客户端还发不发数据，却进不了智谱的服务器，无法验证文件何时删、备份里有没有副本、私钥由谁管。

第三，开源怎么落地。截至发稿，ZCode 只公开了插件市场等项目，出问题时的历史代码和服务端接口设计还没看到。9 月 20 日，太原承明科技直接向智谱发了正式函件，独立取证指出上传内容远超隐私政策范围，还点出一个敏感问题，客户端网络请求指向新加坡主体，而签约方是北京智谱华章，数据到底有没有出境，得说清楚。要求 10 月 10 日前书面答复。

四、这不是孤例

把这三起事件摆在一起看，共性很清晰，产品为了"理解"一个代码仓库，最终把远超当前任务需要的数据送上了云。一句话概括，功能优先，隐私让步。

这些事，全是社区个人做逆向、抓包发现的，不是监管或审计查出来的。换句话说，还有多少"默认开启"的上传，只是还没被人拆出来，没人知道。

五、真正该问的问题

我们总在问，模型会不会骗我、会不会泄露我的信息。但 ZCode 这件事提醒我们，包在模型外面那套软件系统，才是真正该盯着的对象。

模型要读代码，可以理解。可一个大型仓库几万甚至几十万个文件，不可能每次都全塞进模型上下文。于是厂商在客户端里加了索引、快照、检查点这些组件，由它们决定读什么、传什么、留什么。这套东西，行内叫 Agent Harness。它拿到的权限、调度的工具、处理的文件，比模型本身大得多。

ZCode 的问题，不是模型不可信，而是这套 Harness 在设计时，把"方便"放在了"告知和授权"前面，把解密的钥匙捏在了自己手里，把关闭的开关藏了起来。你真正信任的，到底是那个会写代码的模型，还是那套你打不开、关不掉、钥匙还捏在别人手里的软件系统？

 

数据主权不在你手里的时候，所谓信任，就只是一句单方面声明。

数据来源：ferstar 逆向调查（2026-09-18）、智谱 ZCode 官方致歉说明（2026-09-18）、太原承明科技致智谱函件（2026-09-20）、IT之家与观察者网及腾讯新闻跟进报道。