9 月 18 日，有开发者发帖称，智谱的 AI 编程工具 ZCode 会在用户登录状态下，把整个工作区静默加密打包并上传至云端，其中包含完整的 Git 历史、大文件缓存、操作记录与全局配置。消息在开发者社区迅速发酵。
三天后的 9 月 21 日，智谱宣布ZCode 正式开源，并公布整改结果：中国信通院与绿盟科技分别完成安全审计，确认相关云端存储桶已删除、处于云端零数据状态，新版客户端已移除相关功能并切断上传链路。同时向所有用户道歉。
这件事值得聊，但不是因为它热闹——而是因为它把一个行业性问题摆到了台面上。



反常识一："偷传"这个词，其实用错了
先厘清一件事："偷传"是质疑方的说法，不是定性。
把智谱自己承认的内容摊开看，它承认的是——问题源于 ZCode 的"代码库索引"功能，该功能用于支持历史版本检查、会话恢复以及 Repo Wiki（代码仓库知识库）等功能；该功能上线后默认开启，在生成仓库知识库页面时可能触发仓库数据上传；上传数据仅用于生成页面，随后销毁、不会保存。
你看，这里面没有"偷"。智谱承认的是"默认开启 + 告知不足"，这属于产品默认值设计的失误，不是蓄意窃取——这两者在性质认定上差得很远。
但别急着觉得"那没事了"。真正让开发者炸锅的，恰恰不是"传了"这个动作，而是另外四个字：不由你定。
开发者真正在意的是什么：①默认开启——你没同意，它就已经在跑了②无法关闭——据用户反馈，上传过程在客户端里无法主动取消③无法查看——数据虽经加密，但解密所需的私钥在云端，用户本地解不开④传的是核心资产——不是日志文件，是完整的代码历史和可能包含密钥、内部业务信息的研发资产
所以准确的说法是：功能目的可能正当，但程序上不正当。而"程序不正当"在数据合规里，本身就是大问题。
还需要说明：质疑方后续提出的另两项指控——"道歉当日凌晨仍有上传记录""数据出境至境外主体"，截至目前未见智谱的公开回应，也未见独立证实。本文不作判定。
反常识二：开源这件事，把"信任题"做成了"验证题"
这是我认为整起事件里最有行业价值的一步。
AI 工具的数据安全，过去一直是道信任题：厂商说"我们不留存、不训练"，你只能选择信或不信。因为代码是闭源的，你没法验证——它说销毁了，你凭什么相信？
而这次智谱走的路子是：把代码交出来。
整改动作的五个层面：①修复：v3.14.0 客户端移除相关功能，切断本地仓库快照生成与上传链路②审计：中国信通院技术评测 + 绿盟科技审查，确认存储桶及全部数据对象已删除，云端零数据③开源：ZCode 代码库公开，交社区监督④政策：MaaS 平台将上线"数据内容不留存"功能⑤机制：建立常态化安全漏洞反馈与奖励机制
这五步的意义在于：它把"你信不信我"这个没法证伪的问题，换成了"你自己来看、自己来查"这个可以验证的问题。信通院和绿盟的两份结论，是独立于厂商的第三方出具的——这比一百句承诺书都管用。
但也要泼一盆冷水：开源不等于自动可信。代码交出来了，还得真有人去读、去审，审出问题还得有人跟进修复。开源是把门打开了，不等于房间里已经干净了。这套机制能不能长期转起来，才是真正的考验。



反常识三："数据不留存"有边界，别当万能药
这次智谱推出的"数据内容不留存"，很容易被理解成"以后我的数据就绝对安全了"。但把官方说明读完，会发现它有明确的例外条款：
"不留存"不覆盖的情况（智谱说明）：Batch API、File API等需要平台持久化保存任务或文件的功能，不在覆盖范围内· 法律法规要求留存，以及核查涉嫌违规或滥用行为等情况，平台可能留存 30 天及以上· 它关注的是"模型推理完成后数据是否继续留在服务商一侧"，不意味着任何场景下都不保存
另外，浙江大学网络空间安全学院副教授张秉晟的解释也值得记住：智谱目前的处理意味着数据不落盘，但在执行过程中仍然有数据泄露的风险。换句话说——"不留存"管的是事后，"执行中"这一段依然存在暴露面。
还有一个容易被忽略的行业背景：这类零数据留存安排并非孤例。据报道，OpenAI、Anthropic 均已面向部分企业级 API 客户提供零数据留存安排，同时也保留合规、安全及部分产品功能所需的例外情形。这是行业共同的惯例结构，而不是某一家独创的承诺。



还有一个绕不开的难题：道歉能修"以后"，修不了"已经发生"
整改动作覆盖了五个层面，看上去很完整。但信任重建的难点在另一处。
据报道，有企业用户表示不认可目前的整改措施，其所在的公司使用 ZCode 已久，多个私有仓库、上线项目以及服务器凭据都已被打包上传，已着手固定证据、准备进一步维权。另有报道称，近 400 名开发者组成了维权群，并有企业发函追责。
这就是数据泄露和别的故障最大的区别：软件 bug 修完就好了，但已经传走的数据拿不回来。道歉、开源、审计，解决的都是"以后不会再发生"；而"已经发生的那部分怎么办"，才是信任危机真正的硬核。
上海交通大学数据法律研究中心执行主任何渊指出，随着 AI 编程工具从"代码补全"升级为可以读取项目、调用终端、修改文件和操作数据库的智能代理，服务商需要建立更细化的文件级和功能级授权机制；对企业用户而言，也应把 AI 编程工具纳入供应商管理和数据安全体系，明确哪些代码和数据可以提交给外部 AI 工具。
这段建议其实指向一个更根本的转变：以后用 AI 编程工具，可能得像用云服务一样——先签数据处理协议，先划清"什么能传"。



给读者，三句实在话
第一，"偷传"是质疑方的用词，不是结论。智谱承认的是"功能默认开启、告知不足"，已道歉并完成整改。性质认定上，这和"蓄意窃取"不是一回事——但"程序不正当"本身，在数据合规里就是大问题。
第二，开源是这次最有价值的一步。它把数据安全从"信不信厂商"变成了"自己能不能查"。但开源是开始不是终点，得看后续有没有人真去审、审出问题怎么修。
第三，如果你在用 AI 编程工具，有两件事值得现在就做。一是去翻翻你用的工具，有没有"索引""知识库""云同步"这类默认开启的功能，先看清它传什么；二是敏感仓库与密钥做好隔离——别把最核心的东西，交给一个你没读过条款的工具。
说到底，这场风波真正的价值，不在于哪家公司认了错，而在于它逼着整个行业回答一个问题：当 AI 工具开始读取你的项目、调用你的终端、操作你的数据库时，"授权"这两个字，到底该细到什么程度。