你以为 AI 编程工具只读它完成当前任务需要的那几段代码。但在你电脑某个 700MB 的隐藏目录里，躺着一个你自己都解不开的加密包——里面 86.6% 是你仓库从第一天起的全部历史。

9 月 18 日，开发者 ferstar 的一次普通磁盘清理，把智谱旗下的 AI 编程工具 ZCode 推上了风口浪尖。这件事在技术圈传了几天，有公司直接内部停用，有企业发了律师函，智谱三次回应、开源代码、请第三方审计。

我们就把整件事拆开看：到底发生了什么、真正危险的是什么、以及今晚你能做什么。

01 一个 313MB 的"待上传"包裹

事情的起点很普通。ferstar 清理磁盘时发现，ZCode 在用户目录下的本地文件夹（~/.zcode）已经占了 700 多 MB。

其中 v2/checkpoints/ 目录约 303MB，里面有一个 313MB 的加密文件。随附的状态文件写明了几件事：

• 它来自一个商业项目，类型是全量快照；
• 项目总容量约 10GB，排除依赖文件后，仍有约 345MB 内容被打包，"几乎全是核心资产"；
• 这份快照此前已经上传失败了 564 次，一直滞留在本地，客户端还在不停重试。

一个 313MB、重试了 564 次的包，任何一个对系统有点敏感的人看到这里，都会问一句：这是什么？要发到哪去？

ferstar 把客户端的 app.asar 拆开、核对网络连接，还原出了一条完整链路：

步骤	发生了什么
① 申请凭证	客户端向 zcode.z.ai 请求，拿到阿里云 OSS 的表单签名、存储路径、大小限制，以及本轮 RSA 公钥
② 本地打包	在本地把工作区打成 tar.gz
③ 本地加密	AES-256-CTR 对称加密内容，再用 RSA-OAEP-SHA256 封装对称密钥（标准信封加密）
④ 直传 OSS	绕过智谱自己的业务服务器，把密文直接传到阿里云 OSS
⑤ 回调登记	上传成功后，由 OSS 回调智谱后端登记

注意这个"直传"设计——数据不经过厂商业务服务器中转，而是用户客户端拿着临时凭证直接丢进对象存储。从工程角度这很常见、也更省带宽；但从用户视角，这意味着这件事可以做得非常安静。

而它真正引爆舆论的，是下一节——打包的范围。

02 被带走的不是代码，是"从第一天起的全部历史"

密文打不开，但客户端生成快照时留下了一份明文文件清单。ferstar 对清单里的 42,411 个文件做了统计，结果是这样的：

内容	占快照比例
.git/lfs/（大文件缓存）	56.8%
.git/objects/（完整 Git 对象库）	29.6%
.git/logs/（reflog 等）	0.2%
.git 目录合计	86.6%
当前源码与业务文档	约 13.4%

也就是说，这个包里 86.6% 是版本控制历史，真正的当前代码只占一成多。

很多人对 .git 目录没有概念，觉得"不就是些版本记录吗"。恰恰相反，一个仓库最不该被外人拿走的，往往就是它的历史。因为里面可能有：

• 你已经删掉的密钥、口令、数据库连接串——文件在工作区里删了，但在历史提交里永远留着；
• .git/config 里记录的内网 GitLab 域名、仓库路径、甚至带凭证的 remote 地址；
• 还没推送的本地分支名、被 reset 抹掉的提交记录——它们会暴露你正在做什么、做到了哪一步；
• LFS 缓存里的大文件历史版本（设计稿、数据导出、内部文档）。

做测试和做安全的人都懂一句话：代码泄露暴露的是现状，Git 历史泄露暴露的是演进。 你三年间改过哪些接口、密钥轮换过几次、哪个模块反复返工、内部系统怎么命名——全在里面。

这是整件事第一个、也是最实质的争议点：用户对"AI 工具读代码上下文"是有预期的，但对"它把整个仓库连同全部历史静默打包"，完全没有预期。

03 两个开关，都关不掉上传

如果说全量历史是"范围"问题，那接下来这个，是"控制权"问题。

ZCode 的设置里有两个看起来很让人安心的开关：

• 「优化体验」
• 「仓库快照索引」

名字听着都该能关掉上传。但 ferstar 对照客户端代码后发现——没有一个开关在管"上不上传"这件事：

开关	它实际控制的
优化体验	数据能不能被授权用于模型训练
仓库快照索引	服务端要不要给已经传上去的快照建立索引

即使两个都关掉，本地快照照样生成、照样进入上传流程。快照组件在客户端启动时被无条件加载，唯一前提是你处于登录状态；触发点在每次发送提示词前、任务结束后，一个活跃会话的日志里最多出现过 62 次捕获记录。

手动删掉待传包也没用——半小时内它重新生成，上传计数从 564 变成 565。

这是我觉得整件事里最值得每个产品人和管理者警惕的一点：

不是没给你选择，而是给你的选择，和你真正需要选择的东西，不是同一件事。

一个开关，如果说不清自己掐断的是哪一段执行路径，那它关掉的就只是你的警惕心。我自己做变更管控时有条土规矩：任何标着"可关闭"的能力，都得能讲清楚它断的是哪根线；讲不出来的，就当它关不掉。

最后真正能挡住它的，是一个系统级操作：把检查点目录设为不可写（macOS 的 chflags uchg、Linux 的 chattr +i），让捕获逻辑在写盘这一步直接被内核拦住——没有本地产物，上传链路自然就断了。

隐私政策是声明，界面开关是声明，提示词也是声明；只有落在执行点的边界，才算边界。

04 密钥在谁手里，决定它是"备份"还是"采集"

还有一个细节，技术博主们反复提到，我认为是定性的关键。

ZCode 用的是标准信封加密：本地内容用临时对称密钥 AES-256-CTR 加密，对称密钥再用 RSA-OAEP-SHA256 封装。加密本身没问题，甚至可以说做得很规范。

问题在于——RSA 公钥是服务端动态下发的，私钥从不下发，只存在云端。

结果就是：你本地这几百 MB 的密文，你自己解不开，ZCode 客户端也解不开，只有云端能解。 ferstar 用本机所有私钥都没能打开。

这就引出一个很朴素的判断标准：

一个功能的加密密钥归谁，直接决定它的性质是"备份"还是"采集"。

如果这个快照真是为了"本地检查点回滚""跨设备同步"，那它应该像 macOS 的 Time Machine 一样——密钥握在用户手里，数据是你的，工具只是帮你存。 现在的架构却是：数据在你电脑上生成，但只有厂商的云端能读。

加密保护了"传输过程不被第三方偷看"，但它没有回答"数据最终能被谁看"。这两件事，很多时候被混为一谈了。

05 这不是孤例：Grok、Claude、三星都翻过车

如果你觉得这是某一家的问题，那可能要失望了。

• 约两个月前（2026 年 7 月），xAI 的编程工具 Grok Build 被发现将用户的整个 Git 仓库打包上传到谷歌云存储，在开发者社区引发过几乎一模一样的抗议；
• 更早，Claude 也卷入过代码数据上传的争议；
• 2023 年 3 月，三星半导体开放 ChatGPT 仅 20 天就发生三起泄密——员工把测量源码、良率代码、内部会议录音贴进对话框，机密直传境外无法收回，三星随后禁用并自研工具。

但要注意区分性质：三星是员工主动粘贴的误用，ZCode 和 Grok 是客户端在后台自动、批量上传。后者更隐蔽，因为它不依赖任何人犯错——只要你登录，它就自己跑。

这说明这不是某个团队"使坏"，而是一类结构性问题：当 AI 编程工具都在卷"理解整个仓库""跨会话记忆""一键生成 Wiki"这些能力时，把数据搬到云端去处理，是最直接的工程路径。于是"读取范围"和"上传范围"的边界，就在一次次功能迭代中悄悄外扩。

06 法律视角："默认不用于训练" ≠ "默认不上传"

事件里有个表述特别值得拿出来讲，因为它骗到了很多人。

智谱的隐私政策里写着：优化计划默认关闭，"在您主动选择加入前，我们不会将您的输入信息、生成内容或产品使用数据用于产品及模型训练与优化"。

很多用户看到这句就放心了。但这里藏着一个关键的偷换：

"默认不用于训练" 不等于 "默认不上传"。训练授权和收集授权，本来就是两个独立的同意。

我可以不拿你的数据训练模型，但我依然可以把它传到云端、生成一个 Wiki 页面、然后删掉。上传行为本身，是一个需要单独告知、单独征得同意的动作。

对照现行《个人信息保护法》：

条款	要求	这件事的疑点
第十七条	处理前以显著方式、清晰语言完整告知目的、方式、种类、保存期限	隐私政策只说收集"对话中提交的文本、文件和代码"，未提及整库快照和 Git 历史
第六条	目的明确、直接相关、影响最小的最小必要原则	AI 推理通常只需发送任务相关片段，全量仓库连历史一起传是否"最小范围"存疑
第十四条	同意须在充分知情前提下自愿、明确作出	默认开启、无关闭入口，难以构成"明确同意"

此外，快照落地到阿里云 OSS 属于委托第三方处理，隐私政策也应当清晰披露这一层。

作为一个用户，我觉得最朴素的标准就一句话：如果它要在你不知情时默认开启，那它就应该在隐私政策里用最直白的话写明——而不是让用户靠逆向工程去发现。

07 智谱的三次回应：公允地说，补救动作不慢

这一节我想尽量客观。因为骂一家公司容易，但看清"危机响应做得怎么样"，对我们判断整件事、以及对自己做产品，都更有价值。

时间线：

时间	动作
9/18 凌晨	ferstar 发布逆向分析
9/18 傍晚	智谱在官方用户群首次致歉：问题源于"代码库索引"的 Repo Wiki，上线初期默认开启；称数据云端用完即销毁；承诺开源、第三方审计；全员补偿一次周额度重置
9/19	推送 v3.14.0，更新日志写明"修复仓库百科异常上传的问题"
9/19	太原承明科技有限公司发函追责，提出 12 项答复要求（销毁证明、私钥保管、是否跨境等），保留诉讼权利
9/21	第三次回应：已开源（github.com/zai-org/ZCode）；信通院、绿盟完成首轮核查

第三方核查的结论是：

• 中国信通院技术评测确认，涉事的 zcode-prod 阿里云 OSS 存储桶当前云端零数据；
• 绿盟科技审查确认，桶内全部数据对象及存储桶本身已删除；v3.14.0 已移除 Repo Wiki 入口和生成链路，未发现可触发本地快照或文件外发的功能路径。

此外，智谱 MaaS 平台还上线了"数据内容不留存"功能（提示词和返回结果只在内存中参与当次计算，请求结束即释放），并承诺每月公布安全审计报告、建立漏洞报告机制。受事件影响，其港股当日一度跌超 4%。

ferstar 本人也做了对比验证：v3.14.0 实测上传链路代码确已彻底移除、sidecar 已拆除。 这一点，质疑者本人是认可的。

公允地说，从披露到修复、开源、引入两家权威机构审计，三天内完成这一整套动作，响应速度和补救力度，在同类事件里算快的。

但他也指出了几个至今无法从外部证实、依然成立的问题，我认为这些追问不过分：

1. "立即销毁"如何从外部证明？此前已上传的快照是否被物理清除、谁曾持有解密权？
2. "检查点回滚"与"立即销毁"在工程逻辑上存在张力——云端到底留过什么？
3. 开源的版本是否覆盖问题版本的上传组件，还是只开源最新一次提交？

技术博主披露的是"代码、文件、日志反映出的行为"，官方说明的是"功能目的、处理方式、补救措施"——两部分信息要分开看，最终答案仍取决于开源代码和持续审计。

肯定补救的诚意，也保留合理的质疑，这不矛盾。

08 今晚就能动手的三件事

说了这么多，落到你我自己身上，不管你用的是 ZCode、Grok、Claude 还是别的 AI 编程工具，有三件事今晚就能做。

第一件：翻一遍 AI 工具的本地数据目录。

这类工具一般在用户目录下有同名隐藏目录（ZCode 是 ~/.zcode）。按体积排序，看有没有几十到几百 MB 的密文包或快照。发现后确认三件事：

• 密钥在谁手里？
• 开关能不能真的关掉它？
• 手动删掉后，它会不会重新生成？

如果你就是想彻底断了某个工具的快照上传，在确认会牺牲该工具检查点/时间线功能的前提下，可以对其检查点目录加不可写属性，从内核层面拒绝写入。

第二件：给自己的仓库做一次"历史体检"。

翻一翻历史里有没有早已删除的密钥、内网域名、未发布的分支名：

# 查看历史改动，重点找密钥、连接串、口令
git log -p

如果发现历史里真有泄露过的密钥：

• 立刻轮换那批密钥——这是第一位的，改历史删文件都不如换密钥来得实在；
• 确有需要再用 git filter-repo 之类工具清理历史，并知会所有协作者重新 clone。

记住，能被整包带走的仓库，暴露的不是当前代码，是它从第一天起的全部历史。 密钥别想着"我后来删了就没事"。

第三件：把 AI 编程工具纳入正式的"准入评估"，尤其是公司。

如果你是团队负责人，别等出了事才临时停用。引入这类工具前，就问供应商四个问题：

1. 读取范围是否与当前任务相符？
2. 上传前是否充分告知？
3. 用户能否真正一键关闭（注意，要问清开关断的是哪段路径）？
4. 服务商如何证明数据已经删除？

在拿到满意答案前，商业和涉密项目不要在这类客户端登录、不要纳入工作区；企业可将其纳入第三方安全评估和白名单管理。

写在最后：边界要按"还剩哪些能出去的路"来审计

这件事让我反复想起做安全时的一条原则：

边界要按"可达通道"审计，而不是按"禁止清单"审计。你列了多少条禁令不重要，重要的是系统里还剩哪些能出去的路。

隐私政策写了"不收集"，但客户端留着一条登录即触发的上传通道；开关摆在那里，但它们不控制上传。真正的边界，最后是由文件系统的一个权限位、内核的一次拒绝写入来兑现的。

过去很长一段时间，我们谈 AI 安全，谈的都是"怎么防止坏人从外面攻击 AI"。但 ZCode、Grok、ChatGPT 唤起豆包、以及最近 OpenAI 把"协作 Agent 之间未经授权的文件共享"列为不当行为——这些事指向同一个新的十字路口：

我们也到了必须为 AI 自身的行为划定清晰边界的时候了。

AI 可以读多少、可以传多远、在什么情况下必须先问你、数据最终能被谁解密——这些边界不该由逆向工程师一个个挖出来，而应该在产品设计的第一天就被想清楚、写明白、做进执行点里。

工具能提效，但代码库就是我们这行的核心资产。选 AI 开发工具，数据安全这根弦，得自己绷紧。