ARTICLE · 1053461

AI 写代码真相.你的 AI 助手,每次提问都在搬运代码库 ?

发布时间：2026-09-21 22:07:46 最近访问：2026-09-21 22:07:46

一个 313MB 的加密文件，躺在一台 MacBook 里，试着把自己传出去 564 次，全失败了。

你打不开它。

你是这台电脑的主人，这是你自己项目的快照。但解开它要用的那把钥匙，在云端的服务器上。你手上只有一个几百兆的密文，连生成它的那个客户端也解不开。

事情发生在 9 月 18 日，一个叫 ferstar 的开发者清理磁盘的时候发现的。

01 他发现有个东西一直在后台跑

ferstar 那天在 MacBook 上腾空间，注意到一个叫.zcode的目录，体积超过 700MB。不该这么大。

他翻了进去。里面有个 313MB 的加密压缩包，状态写着上传失败 564 次——所以还留在本地；另有一个 15KB 的小文件，状态是已上传。

从可见的文件名看，那个大包是他正在做的一个商业项目的完整快照，42411 个文件。他把客户端拆了，是个 Electron 应用，app.asar里的逻辑摊开来看得清清楚楚。

▲ 从登录到上传，整条链路都在本地完成，只有终点在别人的服务器上

结论是这样的：只要账号处于登录状态，ZCode 桌面端就会在后台静默打包整个工作区。当前可见的代码文件只占一小部分，大头是完整的.git版本历史、LFS 大文件缓存、reflog，还有全局应用配置。.git目录占了整个快照的 86% 以上。

打好的加密包会直接 HTTP POST 到阿里云对象存储（OSS），凭证每次动态获取、临时授权，绕开了智谱自己的应用层。

不是通过它家服务器中转，是直接往云存储上扔。

另一位开发者冯若航在同一天说，他在自己机器上至少看到过三个文件被传走。

▲ 313MB 里 86% 是版本历史，不是你正在编辑的那些文件

凌晨发的帖子，当天傍晚就炸了。

02 真正让人后背发凉的，是那句关于钥匙的话

ferstar 在分析里写了一段，我认为是整件事里最该被记住的：

更讽刺的是：加密用的 RSA 公钥是服务端动态下发的，私钥只存在云端。你本地生成的那份几百兆的密文，连你自己和客户端本体都解不开。

这一句，把它跟"普通隐私纠纷"彻底分开了。

一般的隐私争议，吵的是"你该不该传"。这件事吵的是更靠上一层的东西：你连它传了什么、后来删没删，都没法自己验证。

因为加密这件事本身就是单向的。设计者用一把只有自己拿得到的钥匙把文件锁死，再顺着自己的通道送出去。整个过程里，文件的主人一直在信息盲区——不知道内容、不知道终点发生了什么、也不知道那些东西后来的去向。

▲ 公钥从服务端下发，私钥留在云端；锁是给你看的，钥匙从来没到过你手里

智谱后来回应说，上传的数据会在云端的 Wiki 页面生成之后"立即销毁"，不会保存。这话大概率是真的。

但请注意它意味着什么。这句话只有智谱能说，也只有智谱能证明。问题不在信不信，而在这套做法从设计上就没给外部验证留下位置。

03 为什么"整个 Git 历史"是另一个量级的东西

这里有一层区分，比那个 313MB 的数字重要得多。

一个项目的 Git 目录，记的是从项目第一天开始的每一次改动。它和此刻磁盘上躺着的那些文件，不是一回事。

你半年前不小心提交过一次.env，后来撤了、改回来了、密钥也轮换了——那几行东西仍然在历史里待着，只是你平时看不到。废弃没删的分支，还在。CI 配置里写死的内网主机地址、某次临时调试留下的注释、一句当时随手敲的 commit message，都在。

这些东西的敏感度往往比当前工作目录更高，因为它们本来就不打算给人看。开发者自己也不常翻。

▲ 删掉的还在，改过的还留着；工作目录是结果，历史是过程

所以当一个编码助手被要求"读一下我的项目"，它读到的边界到底在哪，这个答案决定了它是工具还是别的什么。

编码类 AI 的安全问题，也比聊天类难处理得多。聊天机器人拿到的是你敲进去的那几段话；编码助手被授予的是你一整台开发机——源码、凭据、SSH key、内部仓库。它被信任的范围，和它被审计的范围，落差一直很大，这笔账行业里欠了很久。

04 官方回应了，但有些问题没有回答

9 月 18 日 17 点 44 分，智谱在官方 ZCode 用户群里致歉。

说法是：问题源于"代码库索引"功能。这个功能本来帮用户在本地生成仓库索引，支持会话检查点恢复、历史版本回退和 RepoWiki；而 RepoWiki 在云端生成 Wiki 页面时，可能会触发仓库数据上传。该功能上线初期默认开启，部分用户受到影响，目前问题已经修复。

补救三条：近期开源 ZCode 代码库；邀请第三方评估人员审查系统运行情况；给全体 ZCode 用户额外一次周额度重置。

ferstar 随后做了一件事，我觉得比曝光本身更有价值。他把出问题的 3.12.3 和修复后的 3.14.0 都做了逆向，再跟官方说法逐条对照，结果有几处对不上：

官方说 RepoWiki 生成页面时"可能"上传。但问题版本里，sidecar 是伴随登录常驻的，每次提问前、以及执行 repo-wiki-update 时，都会无条件触发上传。

官方没提到有关闭上传的开关。实际上，把界面上的"优化体验"和"仓库快照索引"都关掉之后，后台依然会打包、依然尝试上传到 OSS。这两个开关管的分明是"是否用于训练"和"云端是否建索引"，都不是"是否打包上传"本身。

3.14.0 版的实测则是：上传链路代码已被彻底移除，sidecar 逻辑也拆掉了，不再触发打包上云。

至于此前已经传上去的数据有没有真被销毁，从外部仍然无法证实。ferstar 提了三个还没被回答的问题——"立即销毁"如何从外部证明，谁保留了私钥的解密权；官方说的"检查点回滚机制"和"立即销毁"在工程逻辑上本来就矛盾，那云端到底留了什么；承诺开源的，会不会只是最新一次提交的快照，恰好不含问题版本里那个上传组件。

▲ 官方口径与实测结果逐条对照，出入在于"可能"和"每次"

还有一个事实值得单独拎出来：ZCode 的隐私政策里，写的是收集"在对话中提交的文本、文件和代码"。而这次争议里的事，是后台自动加密打包整个 Git 仓库。这个动作，不在那句话覆盖的范围内。

这件事真正的分水岭在这里：一个 bug 会被修掉，一个默认值是被某个人决定的。

如果只是写错了，修完就结束了。但"上线初期默认开启、而且关不掉"这组描述，说的是一个被设计出来的东西，不是一个坏掉的东西。两者接下来该追问什么，方向完全不同。

公开报道里还有一条：目前已有公司在内部停用 ZCode。一位国内头部机器人公司的软件工程师匿名告诉媒体，他们公司出于安全考虑，已经禁止内部使用智谱的工具。

05 上一次，有人把这件事做对了

两个月前，xAI 的编程工具 Grok Build 出过几乎一样的事。开发者发现它把用户整个 Git 仓库打包上传到 xAI 的服务器，而它的宣传里写着会话期间不会传出任何代码库内容，那个宣称能拦住它的开关也根本没起作用。

有意思的是后面。

马斯克确认了上传行为。xAI 删掉了此前收集的用户数据，写明零保留政策，加了一个隐私相关的接口。然后有人用同一个客户端重新测了一遍，观测到上传已经关掉了。

最后这个动作——独立重测确认——才是把一句声明变成一件事实的那一步。

智谱给出了声明，也给了补救，但还没有提供这一步。因为它选择了只有自己能解密的方案，它就把自己放到了一个位置上：只能被信任，无法被验证。

06 开源权重，闭源客户端

这里有一处结构性的张力，我觉得比事件本身更值得想一想。

智谱是靠开源模型立起来的。最好的模型免费放出去，年收入接近 10 亿美元——真正在卖的是模型周围那套软件。这次出问题的，恰好是那套软件。

创始人唐杰有个主张我认同：安全来自广泛的参与和监督，而不是技术壁垒。这个说法本身很好。

只是这回它没有走到开发者机器上装着的那个东西。开源出去的是模型；闭源运行的是那个把你整个工作区打包、加密、送走的程序。

对开发者来说，判断方法可以很简单：一个工具装进你的开发机时，你该问的不是"它的模型开不开源"，而是"它读我磁盘的那部分，我能不能看一眼"。

07 同一周，另一条线也在漏

如果你觉得上面这些还只是某个产品自己的问题，那这一条大概能说明它不止于此。

9 月 17 日，安全公司 AIR Security 披露了一个零点击远程代码执行漏洞，取名叫 Plugin4Shell。四款主流编码 Agent 全部中招：Claude Code、OpenAI Codex、GitHub Copilot、Google Gemini CLI。

毛病出在插件市场最基础的一道保险上，叫 SHA pinning。

原理不复杂：插件通过审核之后，市场会把它锁死在某个具体的 commit 上，就是一串 40 位的哈希。这样一来，你装的插件永远等于审核过的那一版，不会在你眼皮底下悄悄变成别的东西。

AIR 的研究者发现，这四款工具都会去检出被锁定的那个 commit，但从不验证检出结果真的落在那个 commit 上。

利用方式也很朴素。攻击者在自己控制的插件仓库里，建一个名字正好等于那串 commit 哈希的分支。Git 解析时优先认引用名，而不是裸的 commit 对象。于是工作区被换成了攻击者的内容，工具那边依然报告"已按锁定版本安装成功"。

零点击是从哪来的——Claude Code 和 Codex 默认在后台自动更新插件。你不用装任何新东西，只要装过一个你信任的插件，攻击者拿下上游仓库之后，下一次后台更新就会把恶意版本部署下来。

四种处理方式，基本能看出四种态度：

Anthropic 修了，在 Claude Code 2.1.179 里，6 月 17 日确认

OpenAI 修了，在 Codex 0.146.0 里，8 月 12 日确认

微软在披露时还没出修复

谷歌告诉研究者，Gemini CLI 已经废弃、不会修，让用户迁到 Antigravity

▲ 四款产品，同一个漏掉的校验，四种收场

修复本身其实就是一行断言：检出之后，把工作区实际的 HEAD 跟锁定的哈希比一下，不一致就终止。

AIR 给这件事下的判断是：一个漏洞，每一家主要的实验室都犯了。四个独立团队、四套代码，在同一个地方做出同一个错误假设。到这一步就很难再说是谁家的 bug 了。

08 说得出的一句

把两条线放在一起，会发现它们讲的是同一件事。

这一周里，你的编码助手被信任着去读你的磁盘、装你的插件、替你在仓库里改代码。而我们对它的审计能力——能不能看见它传了什么、能不能独立验证它删没删、能不能确认装进来的真是审核过的那一版——并没有跟上。

它被交出去的那些权限是真的，我们对它的检查是名义上的。

以前我们担心 AI 太聪明，眼下这波更实际的问题不是这个。是它拿着我们给的钥匙在做事，而我们连钥匙孔在哪都看不清。

📎 信息来源：21 世纪经济报道、钱江晚报·潮新闻、南华早报、开发者 ferstar 的公开逆向分析与智谱官方回应，以及 AIR Security 对 Plugin4Shell 的公开披露，仅供学习交流。本文配图为程序化绘制。

本文引用内容版权归原作者及原出处所有。如涉及侵权，请联系删除。