事件时间：2026年9月18日曝光，9月18—22日持续发酵。本文事实均来自公开报道与开发者逆向分析。
先问一个问题：你装了一款 AI 编程工具，登录账号之后，它在后台把你整个项目的 Git 历史、被删掉的密钥、甚至你本地的全局配置文件，打包加密送到了云端——而你在界面上根本找不到一个真正管用的关闭开关。
多数人的第一反应是：这是黑客攻击吗？是公司被黑了吗？
都不是。这恰恰是最近刷屏的"智谱 ZCode 传包门"最反直觉的地方——把代码搬走的，不是外部攻击者，而是工具本身。而围绕这件事的讨论里，"加密了就安全""我关了改进模型开关""AI 只会发我正在写的那几行"这三种说法，几乎个个都踩在技术误区上。
一、事件复盘：一个硬盘占用异常引发的连锁反应
时间线很清楚，我们按公开报道梳理：
9月16日，ZCode 推送 v3.12.2 版本，更新日志里有一条"优化仓库快照上传的内存占用"。这条日志在事件发酵后被删除。
9月18日，技术博主 ferstar 在排查本地磁盘占用异常时，发现一个约 313MB 的加密文件，打不开，但附带清单显示它装了约 4.2 万个文件，其中超过 8 成是项目历史修改记录。他随后做了逆向分析，并把过程公开。当天晚间，智谱在 ZCode 用户群首次致歉，把问题归因于"代码库索引"功能上线初期默认开启，称数据只用于云端生成 Repo Wiki，用完立即销毁、不保存，同时承诺开源、引入第三方审查、补偿一次周额度。
9月19日，智谱推出修复版本。太原一家企业客户承明科技公开"十二问"，称独立取证后发现"修复效果存疑"，并质疑数据删除、私钥保管、是否跨境传输等问题。
9月20日晚，智谱宣布 MaaS 平台将上线"数据内容不留存"功能。
9月21日，智谱宣布 ZCode 正式开源，邀请中国信息通信研究院与绿盟科技开展安全审计。
9月22日，官方披露经审计确认相关云存储数据已按要求处理，央广网、中新网、36氪等媒体持续跟进。
需要强调的是：目前没有证据表明这是一起"数据泄露给第三方"的外部入侵事件，争议的核心是厂商自身的默认行为是否越界。这是两码事，后面会展开。
二、技术核心拆解：一个"本地索引"为什么需要把仓库搬走
1）到底传了什么，怎么传的
根据公开的逆向分析，ZCode 在用户登录状态下，会在两个时机打包：每次用户向 AI 提问之前，以及一次任务结束之后。一次活跃使用中可观察到多达 62 次快照。
被打包的内容远超"当前编辑的文件"：
- 整个工作区的当前源码
- 完整的 Git 提交历史、reflog 操作记录
- LFS 大文件缓存
- 跨项目的 ZCode 全局配置
更关键的是打包顺序这件事。客户端的文件筛选逻辑是按顺序判断的：历史记录目录的放行，排在密钥过滤（.pem、.key 等）和 1MB 体积上限之前。这意味着，针对密码文件的过滤和大小限制，对历史目录下的内容不生效——一个曾经提交进 Git、后来又被删掉的密钥，会原样被带走。
2）"加密上传"的真相：锁是服务器发的，钥匙也在服务器手里
这是整件事最容易被误读的技术点。
客户端的流程是：先向智谱服务器要两样东西——一份临时上传凭证、一把加密用的公钥；然后在你本地压缩、加密；再绕过智谱自己的业务服务器，直连阿里云 OSS 上传，最后由云存储回调智谱后台。
这里用的是非对称加密。打个比方：公钥是一把挂锁，谁都能用来把箱子锁上；私钥是钥匙，只有持有者能打开。ZCode 把锁发给你，让你自己锁箱子，但钥匙只留在服务器那一侧。
所以"传输过程是加密的"这句话本身没撒谎——它防的是路上被第三方偷看。但它证明不了另一件事：厂商自己能不能打开这个箱子。答案是能，因为私钥在它手里。你自己反而解不开。
3）为什么界面上的两个开关都不管用
这是争议的真正焦点。逆向对照代码后发现，界面上看似相关的两个选项其实各管各的：
- "优化体验"——只控制数据是否用于模型训练
- "仓库快照索引"——只控制服务端收到数据后建不建检索目录
两个都关掉，本地的打包和上传组件在软件启动时就无条件加载，唯一前提是你处于登录状态。也就是说，用户看到的控制项，控制不了真正在发生的事。
有开发者手动删掉那个 313MB 的待发送文件，半小时后它又自动重新生成；该文件当时已失败重试 564 次。另一位开发者在自己 Mac 上独立复现，4 个工作区的快照记录里，至少 1 份写入了"服务端已接收"的确认标记——这个标记按代码逻辑只有上传被服务端确认后才会出现，说明数据确实离开了本地。
4）隐私政策这条线，为什么也站不住
ZCode 隐私政策英文版对收集范围的描述，是用户"通过对话"提交的文本、文件和代码。但后台自动快照不是你"通过对话"提交的，它不在这个描述范围内。政策里还写明：当新功能涉及与原始目的没有直接关联的信息收集时，应通过页面提示等方式另行告知并单独取得同意。
这就把问题从"产品体验"抬到了"合规"层面。
5）这不是行业孤例
值得一提的是同类先例：今年 7 月，独立安全研究者 cereblab 抓包发现 xAI 的编程 Agent 工具 Grok Build 会把整个项目打包传到谷歌云存储，包括用户在对话里明确说"不要读取"的文件和未脱敏的密码；更早还有 Claude Code 被发现回传代理、网关地址、时区等环境信号，Anthropic 工程师事后确认那是一次有意实验。
把这些放在一起看，行业正在形成一个新共识：Agent 厂商自身的数据行为，本身就应该被当成一级风险来审视，而不只是防外部黑客。
三、三个最常见的技术误区
误区一："数据加密了，传上去就没风险"
错。这次用的是服务器端公钥加密，它的作用是传输途中不被第三方截获，而不是"厂商看不了"。当私钥只在厂商手里时，加密防的是路人，不是锁箱子的人。判断一份上传数据对你是否可控，要看解密能力在谁手上、留存多久、谁有权限访问——而不是看"有没有加密"这四个字。
误区二："我关了'改进模型'开关，数据就不会上传"
这是把两条独立的线拧成了一条。"是否用于训练"和"数据是否离开你的电脑"是两件事：前者管用途，后者管去向。关掉训练授权，只意味着"别拿我的数据训模型"，并不等于"别把我的数据传上去"。Grok Build 被曝光时也是同样的结构。看 AI 工具的隐私设置，要分别找"上传/遥测"和"训练/改进"这两类开关，缺一不可。
误区三："AI 编程工具只会发我正在写的这几行代码"
为了理解上下文，工具确实需要读代码，这是合理的；但合理不等于"可以全量打包"。这次被诟病的不是"读代码"，而是范围、可见性和可控性三方面同时越界：86.6% 是 Git 历史而非当前代码、你在本地看不到包里有什么、删了还会自动重建、界面开关管不住。行业里完全有"本地做索引、按需最小化上传"的做法，所以问题不是技术做不到，而是默认行为选了最省事的那条路。
四、实操指引：开发者和普通用户现在能做什么
给普通开发者
搞清楚你装的 AI 工具到底连了哪里
在自己机器上用抓包工具看一眼它的网络出口。Mac 上可以用 Little Snitch 或 Charles，Windows 上可用 Wireshark/Fiddler。重点看：它连了哪些域名、什么时候发起请求、单次上传多大。你不需要逆向代码，只需要知道"谁在什么时候往哪传了多少"。
敏感仓库别裸奔式登录
涉及公司核心代码、密钥、客户数据的项目，不要在未确认行为前登录 AI 工具的云账号；可以用单独的沙箱目录、单独的机器或只读工作区来跑 AI 辅助编程。企业更应把 AI 编程工具纳入软件准入清单，像评审第三方 SDK 一样评审它的网络行为。
清干净你的 Git 历史 而不只是删本地文件
这是很多人忽略的一点：在 Git 里 git rm 删掉一个密钥文件，它仍然躺在历史提交和 reflog 里。正确做法是：
- 本地扫描密钥：用
gitleaks、trufflehog这类工具扫整个历史 - 真正清除历史中的敏感内容：用
git filter-repo重写历史（注意会改变 commit 哈希，团队协作前先沟通） - 一旦怀疑密钥泄露，第一步不是删文件，而是立刻去对应平台吊销并轮换那把密钥——删文件挡不住已经传出去的东西
区分三类开关 逐项确认
打开工具设置时，分别找：是否允许上传/遥测、是否允许用于训练、是否有本地索引模式。优先选择支持"纯本地索引"或"云端上传显式确认"的产品。把"改进模型"当成默认关闭，是值得养成的习惯。
给企业/团队
- 与 AI 工具厂商签署数据处理协议（DPA），写明数据范围、留存期限、删除机制、是否跨境、私钥保管方式
- 要求厂商公开声明数据出口清单（连哪些服务器、传哪些类别），方便安全团队独立比对
- 关注"同意链路"问题：点"同意"的是开发者个人，承担后果的是公司，公司需要在制度层面把这个口子补上
- 发现异常时，先留存本地证据（待上传文件、网络包、版本号、日志），再联系厂商，必要时通过正规监管渠道反映
五、写在最后
ZCode 这件事到今天，道歉、修复、开源、第三方审计、数据不留存，一套动作几乎在 72 小时内全部走完，反应速度确实罕见。但它留下的真正问题，不是"这家公司坏不坏"，而是一个更普适的技术命题：
当 AI Agent 变成你电脑上的常驻程序，它默认替你做的每一个决定——拍快照、打包、上传、加密——到底有几个是你真的知情、真的能关的？
加密解决的是路上安全，不是访问权；开关解决的是训练用途，不一定是数据去向；"本地索引"和"云端上传"之间，也从来不是同义词。把这三对关系想清楚，下次再装任何一款 AI 编程工具，你都会比别人多一层安全感。
觉得有用，欢迎转给身边天天和 AI 写代码的朋友。你现在用的 AI 编程工具，你知道它往哪传数据吗？评论区聊聊。