AI 编程工具越能干,你的代码就越藏不住

一个 313MB 的加密文件，躺在开发者自己的硬盘里，他自己打不开。

9 月中旬，开发者 ferstar 在清理磁盘空间时，发现一个叫 ~/.zcode 的目录占了 700MB 以上。他顺着目录往下翻，在 v2/checkpoints/ 里找到一个 313MB 的加密文件，旁边躺着一份明文可读的状态文件，里面写着三行关键信息。

第一行，kind 是 baseline —— 这是全量基线快照，不是增量。

第二行，两个体积：加密后 313,070,842 字节，对应的工作区 345,549,173 字节。他的商业项目总共 10GB，排除掉 node_modules 这类依赖后剩下 345MB，几乎全是核心资产。

第三行，failureCount 是 564 —— 这个包已经上传失败 564 次，还留在本地排队，等着下一次重试。

而解密它的钥匙，不在他手上。

它传走的是什么

ZCode 是智谱 AI 的桌面编程工具，能读写代码仓库、操作终端、跑长任务。

ferstar 把客户端的安装包解开，还原出这条链路：

• 客户端先向 zcode.z.ai 申请上传凭据；
• 服务端返回一个快照 ID、一组阿里云 OSS 的表单签名，以及这一轮的 RSA 公钥；
• 客户端把工作区打成压缩包，用 AES-256-CTR 加密，再用服务端给的公钥把密钥包起来；
• 加密包直接上传到阿里云 OSS，由 OSS 回调智谱后端，登记这个快照。

他另外查了运行时的网络连接：ZCode 一边连着 zcode.z.ai，一边连着两个阿里云 OSS 存储节点。代码走的不是"你点一次、它传一次"的路，是常驻的。

那这个包里到底是什么？在 42,411 个文件里，.git 目录占了 86.6%：

这才是这件事真正的分量。 Git 的对象库不是"当前代码的快照"，而是这个仓库从第一次提交至今的完整谱系：

• 早期提交里删掉的 API key，还留在对象历史里；
• 没推送出去的本地分支名，会暴露还没发布的产品计划；
• .git/config 里，有内部主机名和仓库路径。

换句话说，上传的不是"你现在打开的那几个文件"，是几年的工程历史。

最扎心的一层：开关关不掉

ZCode 的设置里有两个看起来相关的开关。ferstar 对着代码看了一遍：

• 「体验优化」
   —— 只控制数据是否用于模型训练；
• 「仓库快照索引」
   —— 只控制服务端是否建立索引。

两个开关，都不控制"打包和上传"这条管线。

原因是这套捕获机制跑在主机级的后台进程里，位置在 agent 工具循环之外。所以你在 agent 界面里怎么设权限，都够不到它。它只需要一件事：一个有效的登录凭证。

触发频率也不低：提示词发出前一次、任务完成后一次，一个会话里最多记录了 62 次捕获。更直白的是这个动作——他把本地的加密包删掉，半小时之内又生成了一个同样大小的新包，重试计数接着往下走。

这就不是"某次误操作触发了上传"，而是一条默认常开的链路。

而且这不是孤例。在智谱的公开反馈仓库里，另一位用户提交了报告：ZCode 3.12.3（macOS）和 3.10.0（Linux）上有同样的行为；即使把「仓库快照索引」设成关闭，仍然留下了已经登记的快照记录——其中一份清单里有 2,000 多个 .git 路径，另一个待上传的加密包接近 1GB。这份报告被标了常规的 P2 优先级。

智谱怎么回应

9 月 18 日傍晚，智谱发布情况说明并道歉。官方口径是：

此次问题源于 ZCode 的「代码库索引」功能……Repo Wiki 功能在生成 Wiki 页面时可能会触发仓库数据上传。Wiki 页面在云端生成后，相关上传数据会立即销毁，不会保存。由于该功能在上线初期默认开启，部分用户因此受到影响。

配套的整改有三条：相关问题已完成修复；近期开源 ZCode 代码库；邀请第三方评估人员审查，并持续公开进展。另外给全体 ZCode 用户额外补了一次周额度重置。

这条回应把问题定性为功能设计越界，而不是恶意收集数据——这跟 ferstar 的技术结论并不冲突：一条默认开启的管线，和"决定要偷偷拿走用户数据"，是两件事。

但有几个问题还悬着。为什么生成一个代码知识库页面，需要上传包含完整 Git 历史的全量快照？云端"立即销毁"，用户靠什么验证？修复之后具体改了哪几行逻辑？这些在官方说明里都还没有答案。

但真正的问题不是这一家

如果只把它读成"一家公司翻车"，就浪费了这件事。

看时间线：ZCode 在 8 月用户破百万，产品刚把「目标模式」「子智能体」「远程控制」这些能力推向全项目执行——Agent 不再只是补全一行代码，而是自己规划、自己改多个文件、自己跑测试。

能力越自主，它就越需要完整仓库。 要能回滚，就得有检查点快照；要能理解整个项目，就得有完整索引；要跨会话记住上下文，就得把仓库知识库搬到云端。

这条逻辑对任何一家做 AI 编程工具的公司都成立。

问题出在边界和能力的更新速度不一样：

能力已经从"聊天框"跑到了"整个代码仓库"，而隐私政策里写的还是"用户在对话中提交的文本、文件和代码"。

ZCode 的隐私政策通篇没有提到"打包上传完整工作区"和"完整 Git 历史"。这不是措辞上的疏忽——它反映的是一个行业性的时间差：产品功能的迭代以周计，而数据边界条款的修订以年计。

还有一个细节值得留意：被逆向的那一版是 8 月 14 日发布的 v3.7.7；而 9 月 17 日发布的新版 3.12.3，更新日志里没有任何一条涉及仓库快照或它的控制项——那天，正好是这件事被公开的前一天。

所以，你能做什么

这事最实用的部分在这里。三个动作。

一、先看它在你硬盘上留了什么。

ZCode 这件事，是 ferstar 清磁盘的时候发现的。你也不妨去看一眼手上那些 AI 编程工具的数据目录：占了多大、有没有你不认识的快照、缓存、待上传队列。

二、看你有没有真的关掉。

关一个开关之前，先问清楚它控制的是什么。「体验优化」关掉的是训练授权，「仓库快照索引」关掉的是服务端索引——都不是"要不要上传"。开关的名字，未必等于你理解的那件事。

三、判断它的数据边界，和你的业务匹不匹配。

个人练手的小项目，和公司的核心业务仓库，对"代码离开本机"的容忍度完全不同。如果你的仓库里有密钥历史、有没发布的业务计划、有内部架构，那你要看的不是"这个工具的隐私政策写得好不好"，而是"它的数据边界写在哪一年"。

一个可以直接拿去用的判断：别看你授权了什么，看它跑了什么。

最后

这件事有个很轻的收尾。

ferstar 在文章里说，他会等 ZCode 开源，然后对着源码再写一篇——因为开源版本里到底会不会带上那套被捕获的上传模块，只能看了才知道。

承诺已经给了，接下来看代码。

对我们来说，这件事的价值不在于记住"哪家出过事"，而在于换一个提问方式：

以前我们问：这个 AI 工具好不好用。 现在得加一句：它替我干活的时候，顺手拿走了什么。

· · ·