ZCode偷传代码事件：比”上传”更恶劣的，是”偷偷”

一、一个 313MB 的加密包，扯掉了 AI 编程工具的遮羞布

2026年9月18日，一位网名叫 ferstar 的开发者在清理磁盘时，发现智谱 ZCode 在用户目录的隐藏文件夹里留了七百多兆的东西，其中一份是 313MB 的加密数据包。他顺着网络请求和本地文件一点点排查，把整条上传链路逆向了出来，结果让整个开发者社区倒吸一口凉气：用户只要登录了 ZCode，客户端就会在后台把当前工作区整个打包——注意，是整个——包括完整的 Git 提交历史、大文件缓存、分支操作记录、甚至全局配置文件，加密之后静默上传到阿里云的对象存储。

几个数字值得单独拎出来说：他那个 345MB 的工作区被打成 42411 个文件，光 .git 目录就占了 86.6%；上传失败计数器记了 564 次，也就是说就算网络掐断，后台进程也会锲而不舍地重试。这执着劲儿，说实话，要是用在产品体验上，ZCode 的风评肯定不是今天这样。

二、让我后背发凉的，是那把"只有服务器能用的钥匙"

这类隐私争议其实不算新鲜，但 ZCode 这次在技术层面上把事情做绝了。客户端用的是信封加密：数据先拿本地生成的对称密钥加密，再用服务端下发的 RSA 公钥把对称密钥包一层。问题在于，解密用的私钥只存在 Z.ai 的云端。 ferstar 把本机所有私钥试了个遍，解不开——你自己电脑上躺着的那份密文，你自己解不了，客户端自己也解不了，全世界只有远端服务器能还原你的全部代码。

ferstar 在帖子里有句话，我认为会被写进以后的教科书："一把只有服务器能用的钥匙，唯一用途就是保证服务器随时能读你的代码。"这话可能重了点，但它点破了一个基本常识：加密在这个架构里不是用来保护用户的，是用来排除用户的。

更要命的是第二个细节：客户端里的隐私开关根本管不住这个上传。 ferstar 关掉体验优化、关掉仓库快照索引，打包照样跑，最后是在操作系统内核层面把目录写权限锁死，抓取才停下来。多名技术人员独立复现了同一现象。换句话说，软件给了一个"关闭"按钮，但这个按钮不接任何线。作为用户，你按下去的每一次，都是一场行为艺术。

还有一个细节被讨论得不多，但我觉得同样关键：那 42411 个文件里，源码和文档只占 13.4%，剩下八成六全是 .git 目录——其中大文件缓存占了 56.8%，底层版本对象占 29.6%。也就是说，真正被"顺手"传上去的，不是你现在写的代码，而是你过去几年每一次提交、每一次试错、每一版被你以为已经删掉了的代码。提交历史这个东西，平时没人看，可真要挖起来，里面埋着早年硬编码的临时密钥、测试环境密码、内部接口地址，都是开发者的命根子。

三、智谱的道歉很及时，但我对"补偿方案"有点看法

舆论发酵当天，智谱在官方渠道和用户群里同步回应：问题源于"代码库索引"功能，本意是支持会话检查点恢复、历史版本回退和 Repo Wiki，其中 Repo Wiki 生成页面时会触发仓库上传，数据在云端生成页面后立即销毁、不会保存；承认功能上线初期默认开启是问题根源，已完成修复，承诺近期开源 ZCode 代码库、邀请第三方独立审计并持续公开进展，同时给全体用户额外发放一次周额度重置。

我的态度很明确：回应速度值得肯定，"开源+第三方审计"也是行业里最有诚意的止血方式之一。但有两处我吃不下去。

第一处是"上传后立即销毁"这个说法。销毁承诺管的是云端存储环节，可风险早在"上传"这个动作发生的一瞬间就已经兑现了——传输链路可不可信、存储桶权限配置有没有问题、有没有被中间人截获，这些都不是一句"我们用完就删"能覆盖的。用不保存来回应偷上传，逻辑上站不住。

第二处是那个补偿方案。出的是隐私信任危机，送的是算力额度——这好比开车撞了人，递过去一张加油卡。我理解增长团队的难处，但从用户视角看，这个方案暴露的恰恰是问题本身：在产品的价值排序里，用户数据安全和"多用一周"被放在了同一个天平上。

四、作为一个天天跟"默认勾选"打交道的人，我想说两句

我在金融行业做产品，日常工作里有一半时间在和合规条款、授权弹窗、明示同意这些词较劲。所以当我看到"功能上线初期默认开启"这行字的时候，我的第一反应不是愤怒，是熟悉——太熟悉了。

干我们这行的都清楚：默认开启从来不是一句技术描述，它是一个产品决策。每一个默认勾选背后，都站着需求文档里一行"提升功能渗透率"的指标，站着某个人的 OKR。把锅甩给"初期默认开启"，等于说是按钮自己把自己勾上的。我不接受这个说法，我相信大多数用户也不接受。

中国个人信息保护法和 GDPR 对这类行为的要求其实非常一致：处理个人信息要取得个人的明示同意，不能以默认授权的方式替用户做主。放到 ZCode 这个案子里，"生成 Repo Wiki"这个功能是不是有价值？我认为有。"需要读全量仓库才能生成"是不是成立？也算成立。但"不打招呼就把包含四年提交历史的 .git 目录传到云上"，和前面两件事之间隔着的，就是合规红线和职业操守。这条线不难看，只是跨过去的时候，数据会跑得比道歉快。

五、这个事件真正的行业警示，藏在"开源"的误会里

先把视野放宽一点：这种"为了模型能力踩过数据边界"的案子，ZCode 远不是第一起。马斯克的 Grok 被曝出默认拿 X 平台用户数据训练模型，没有弹窗、没有通知，用户得钻进多级设置里手动关闭，爱尔兰数据保护委员会随后介入调查并对其提起诉讼，被指违反 GDPR 的明示同意原则；Anthropic 也因为修改协议默认收集对话数据惹过争议。这些公司最后都道了歉、改了默认项，但每一次的成本都由整个行业的信任存量买单。我的判断是，只要"先上车后补票"的收益还大于代价，抄近道的人就断不了，ZCode 也不会是最后一个。

有个细节很有意思：GLM 的模型权重一直是开放的，很多开发者因此下意识地以为 ZCode 也是开源的——权重是开的，工具是闭的。 ferstar 的排查帖在开源中国、博客园、V2EX、Linux.do 几个技术社区接连炸锅，智谱 GitHub 反馈仓库当天就出现了 Issue #707 这样的实证帖，里面相当一部分人的震惊点就在这里：我信任的那个"开放"，根本不覆盖我手上这个客户端。

顺着这个逻辑往下走，接下来 AI 编程工具大概率会分化成两派：一派继续闭源做体验，赌用户懒得计较；另一派把"数据不出本地"当成核心卖点来做。Petri Kuittinen 在这场讨论里撂下一句很硬的话："不要信任闭源的 AI harness。"这话激进吗？激进。但当"关掉开关不管用"被复现过一次又一次之后，激进就成了理性的保守。我的建议是：手上有敏感仓库的，趁周末检查一遍本地目录的异常写入，必要时直接从系统层面锁权限；对隐私要求高的，优先考虑开源 agent 或者本地部署的方案。

六、信任这东西，建立要几年，崩塌就一个默认勾选

智谱承诺开源代码库、引入第三方审计，我认为这能止血，但难治本。信任的建立靠的是日常每一次"没出事"的积累，崩塌只要一次默认勾选。这次事件里我最希望行业记住的，不是那 564 次重试，也不是 313MB 的密文，而是一个朴素得有点土的道理：用户把代码交给你，是托付，不是默认。谁把这个顺序搞反了，谁就会被拎出来写进下一篇这样的文章。