火绒抓到上传43G数据：“智谱”AI编程工具ZCode被指“行为像木马”

编辑：kid

9 月 18 日，国内开发者社区彻底炸开了锅。

起因是一名开发者在清理电脑磁盘时，偶然注意到智谱旗下大火的 AI 编程工具 ZCode 在本地占用了数百兆空间。顺着目录排查下去，扒出了一桩让程序员群体极度震惊的内部机制：只要客户端处于登录状态，ZCode 就会在后台静默将用户的整个本地工作区打包加密，直接上传到阿里云对象存储。

被打包的资产包含完整的代码文件，连同最底层的.git提交历史、LFS 大文件缓存、分支操作日志乃至历史凭据，全被一锅端走。

消息一经曝光，Linux.do、V2EX 和各大技术群迅速沸腾。有用户晒出火绒流量监控，发现该进程在后台悄悄上传了多达 43GB 的海量数据；更有开发者在社区怒斥：“这可不是什么对话内容的范畴，整个打包还拿非对称加密往外送，这跟木马有什么区别？”

01

一个 313MB 的压缩包，炸出全量上传链路

这起风波的源头，来自博主 ferstar 的一次本地取证。

他在排查~/.zcode目录时，在快照文件夹里发现了一个体积高达 313MB 的.enc加密文件。伴随的一份状态文件清晰记录着：系统扫描了本地一个商业项目，排除依赖后把剩余的 345MB 内容打包成全量快照，因为网络问题连续尝试上传失败了 564 次，一直卡在本地重试队列里。

为了弄清楚这几百兆核心商业代码到底要被送往哪里，开发者顺手解包了客户端的安装包进行逆向分析，一条极其隐蔽的上传链路随之浮出水面。

整套流程设计得相当熟练。客户端首先向官方服务器发起请求，换取对象存储的表单凭证与公钥；本地打包并加密完成后，客户端绕过官方自有的业务服务器，直接通过 HTTP 表单把加密压缩包甩给阿里云 OSS。

最让技术人员无法接受的，是其采用的加密姿态。文件内容采用对称密钥加密，但这把对称密钥又被一层服务端下发的 RSA 公钥包裹。私钥从头到尾只保存在云端服务器。这意味着用户本地生成的加密快照，用户自己打不开，客户端本体也打不开，全天下只有后端的私钥能够解密。

正如社区用户在讨论中所指出的那样：“如果真是为了帮用户做断点恢复或跨设备同步，解密密钥理应存放在用户本地。拿非对称加密搞上传，就是不想让你看清楚它到底传了什么。”

02

近九成是 Git 历史：底裤被翻了个底朝天

密文虽然被服务端钥匙锁死，但客户端本地留下的文件清单清晰记录了被打包的全部内容。在包含 4.2 万个文件的清单里，整个项目近九成的体积全都是.git目录。

其中，LFS 缓存占了 56.8%，完整的 Git 历史对象库占了 29.6%，其余才是当下的业务源码。

这意味着云端拿走的远不止开发者当前写在屏幕上的代码，还包括项目自创建以来的全部历史底细：

• 以往提交中早就被覆盖删除的敏感配置和历史密钥；

• 本地尚未推送到远端私有仓库的新分支名称；

• 内部自建代码托管平台的内部域名与项目路径。

平时使用 AI 编程，大家习惯于让模型读取当前文件或特定上下文。开发者发帖质疑：“Git 历史在需要的时候让 Agent 读取，通过接口调用放到临时上下文里就好，凭什么把整套版本历史全量打包上传？”

更让大家心寒的是设置项里的“障眼法”。

许多用户以为只要在软件里关掉“优化体验”或者“仓库快照索引”，就能阻止数据上报。然而逆向代码显示，负责打包和上传快照的模块在客户端启动时被无条件加载。只要账号处于登录状态，不管界面上的开关怎么选，后台照样照常打包上传，界面里根本没有任何真正有效的总开关。

有用户在官方交流群晒出火绒监控显示单个进程狂传 43GB 的截图，发出来两三分钟便被管理员撤回，更激化了社区的不信任情绪。

03

官方紧急致歉承诺开源，但裂痕已难弥合

随着开源社区与各大技术论坛的声讨浪潮持续升级，智谱 ZCode 团队在 9 月 18 日紧急发布说明与致歉。

官方解释称，该问题源于产品中的“代码库索引”功能，特别是 Repo Wiki 模块在初期默认开启，生成项目知识库页面时触发了仓库数据的上传。官方特别强调，Wiki 页面在云端生成完成后，上传的相关数据会立即销毁，云端不会留存用户代码。

针对开发者的质疑，官方给出了三项补救举措：

第一，紧急修复相关代码逻辑，关闭默认上传；

第二，承诺近期将 ZCode 客户端代码库正式开源，并邀请第三方专业人员对系统运行进行独立审计；

第三，为全体 ZCode 用户额外发放一次周额度重置，作为补偿。

这一幕让很多程序员联想到了此前 xAI 旗下的 Grok Build 事件。当时 Grok 同样因为采集开发者本地环境引发众怒，最后同样以承诺删除云端数据和开源相关代码收场。

但在许多开发者看来，这次的事件更加恶劣。Grok 至少在产品界面中有明示提示，ZCode 却在用户毫不知情的前提下静默打包，甚至用服务端单向私钥对上传内容进行防窥加密。

这种偷偷摸摸的做法，彻底踩穿了工程伦理与数据安全的红线。即便事后承诺开源与数据销毁，也难以迅速抚平用户对于核心代码资产外泄的恐慌。

04

AI时代，程序员的防线在何处

大模型工具的普及正在重构开发者的日常。很多人习惯了让 AI 帮自己写函数、修漏洞、理逻辑，却容易忽视终端软件背后的控制权隐患。

当一款编程工具拥有了读写全盘文件的权限，当商业公司的指标压力压过对隐私的敬畏，开发者的核心数字资产就会变成随时可能被打包带走的猎物。

在厂商真正将代码开源、建立起严密的第三方审计之前，最有效的防护反倒退回到了操作系统底层。许多工程师已经开始用操作系统的不可变文件锁直接冻结本地缓存目录，从内核层面阻止任何非授权的写入和打包。

技术进化的初衷是为了解放双手，绝不能以让渡底线安全为代价。AI 工具跑得再快，一旦在透明度和尊重用户上翻了车，失去信任的代价任何巨头都难以承受。

— 完 —

科技前沿进展每日见