21CTO 导读：前两天被开发者扒出"静默打包上传完整 Git 历史"的 ZCode，智谱官方正式回应三重动作：道歉，整改并把代码开源。

2026 年 9 月，智谱旗下 AI 编程客户端 ZCode 陷入舆论漩涡。

开发者发现软件会在后台静默打包上传本地完整代码仓库，事件从开发者社群的信任危机，进一步升级为关乎数据存储、跨境传输的公共合规事件。智谱快速完成致歉、修复客户端、开源项目、引入第三方安全审计，还在 MaaS 平台推出数据不留存机制。这起风波，也成为国内 AI 工具深入本地工作目录之后，行业面对数据边界问题的一次现实演练。对于 AI 企业而言，数据存放在哪里、数据如何流转，早已不再只是后台技术细节，而是直接关乎企业生存的核心命题。

一次上传失败，撕开静默的数据上传链路

9 月 18 日凌晨，独立开发者 ferstar 发布逆向分析文章，把 ZCode 推到风口浪尖。该开发者清理磁盘时，发现本地留存一份 313MB 加密压缩包，包内包含自己商业项目的全套开发资产。这份数据包之所以遗留在本地，是因为后台上传操作累计失败了 564 次，反复重试均未成功。

根据逆向分析结果：用户登录状态下，ZCode 客户端会自动生成工作区完整快照，里面囊括 Git 全部版本历史、LFS 大文件缓存、reflog 操作记录；数据在本地完成加密之后，直接上传阿里云 OSS 对象存储。加密使用服务端下发的 RSA 公钥，加密完成之后，就连用户本人以及本地客户端，都没有办法解密这份数据包。

多位开发者在技术社区复现了该现象。事发当天下午，智谱通过官方用户群公开致歉。官方解释，问题来源于新上线的 “代码库索引（Repo Wiki）” 功能，该功能用于会话断点恢复、版本回滚以及仓库知识库页面生成，上线阶段默认开启，导致用户在不知情的情况下触发上传。官方同时表示，上传的数据在云端生成 Wiki 页面之后会立刻销毁，并且承诺开源 ZCode 客户端、引入第三方机构开展安全审查。

企业用户发函，抛出数据跨境疑问

道歉声明并未平息舆论。9 月 19 日晚间，太原承明科技有限公司公开发函披露，8 月 28 日至 9 月 14 日期间，企业有 6 个工作区被 ZCode 打包上传，单个归档文件最大达到 391.94MB。企业表示，上传的并非零散代码片段，而是完整归档包，其中包含源代码、已经被删除的 Git 提交记录、数据库密码、接口密钥、云凭证以及员工和用户个人敏感信息。

函件带来最受行业关注的线索，指向数据跨境风险。ZCode 客户端网络请求指向zcode.z.ai、cdn‑zcode.z.ai域名，背后运营主体 JINGSHENG HENGXING TECHNOLOGY PTE.LTD，是智谱 2023 年 11 月在新加坡设立的间接全资子公司。

对比产品中英文版用户协议，矛盾点显现：英文版协议写明由新加坡主体处理数据；中文版隐私政策则标注运营主体为北京智谱华章。中文版政策承诺，境内业务产生的个人信息存储在中国境内，跨境传输必须提前告知并且获取用户许可。承明科技就此提出质疑：代码数据是否实际出境、有没有向第三方流转、是否用于模型训练，并且列出十一项整改诉求，要求 10 月 10 日前收到书面答复。

就在企业公函曝光的同一天，ZCode 推送 3.14.0 版本，更新日志写明修复仓库百科异常上传问题，完成技术层面止损。

开源、第三方审计、零留存机制，三重整改落地

9 月 21 日，智谱正式将 ZCode 在 GitHub 开源，交由全球社区审视客户端代码逻辑。

安全审计由中国信息通信研究院联合绿盟科技完成，审计结论显示：阿里云 zcode‑prod 存储桶以及全部对象已经全部删除，云端不存在遗留数据；3.14.0 版本彻底移除 Repo Wiki 功能，切断本地快照打包、上传的整套链路。

智谱对外承诺，今后会按月对外发布安全审计报告，建立常态化漏洞奖励计划，根据漏洞危害等级发放奖励；同时向全体用户致歉，为受影响用户重置平台周调用额度。

除 ZCode 客户端整改以外，智谱 MaaS 平台同步跟进企业客户诉求，宣布即将上线数据内容不留存功能，面向企业与开发者申请开通。开启之后，模型调用的输入输出不会做持久静态存储，数据仅用于完成本次请求计算。

但该机制存在明确边界：Batch API 批处理接口、File API 文件接口这类需要服务端留存任务与文件的场景不适用；另外出于法律法规、违规行为核查，平台依然可能留存相关数据至少 30 天。

放眼海外行业，这种 “零留存” 模式已经是海外头部大模型厂商面向企业客户的标配，OpenAI、Anthropic 均提供同类申请制能力，同时附带合规例外条款。如今在国内，该类能力还属于稀缺选项；对于金融、政务、医疗这类强监管行业，数据是否落盘，已经成为大模型采购的关键评判标准。

风波背后：AI 编程工具，该划下怎样的数据边界

本次事件的特殊之处，在于发生在 AI 编程工具这个高价值数据场景。开发工具必然需要读取本地代码、解析项目结构，但是读取理解项目，和完整打包搬走整套仓库，二者有着本质的边界。

当解密密钥完全掌握在服务端，本地用户无法解密自己的加密数据包，用户对于自身数据的可控性就已经消失。产品架构设计上，Repo Wiki 这类增值能力，完全可以全部在本地完成运算，却被设计成依赖云端处理。在没有获得用户明确许可的前提下静默上传，这已经不只是功能 bug，而是产品架构设计挤压用户数据边界。

这件事也给国内出海布局的 AI 企业敲响合规警钟。大量国内公司会设立海外子公司承接业务，但是中英文协议数据处理主体表述不一致，极易引发客户对于数据出境的质疑。随着《个人信息保护法》、数据出境安全评估规则逐步落地，在存储位置、出境路径、知情同意上面的模糊处理，会同时带来法律风险与用户信任危机。金融、能源、政务等行业采购 AI 工具时，会重点核查：工具是否默认上传本地代码、是否存在数据出境风险。

智谱本次的处置链条：快速致歉、修复漏洞、开源客户端、引入权威第三方审计、建立定期披露机制，代表部分国内 AI 企业，正在从出事之后被动救火，转向依靠透明度重建用户信任。合规不再仅仅是法务部门的文档工作，而是需要前置到产品架构、功能设计、商业谈判的全流程。

结语

ZCode 事件以一轮集中整改暂时画上句号，但整个 AI 行业的数据合规考题才刚刚开始。

这一次，是开发者靠逆向分析，挖出本地遗留的异常数据包；未来会有更多 AI Agent、AI 开发工具进驻个人电脑、企业内网。数据去往哪里、谁有权处理、能否彻底删除、会不会跨境，不能只依靠企业自证清白，而要固化为产品的底层设计，形成全行业统一的基准规范。

智谱这一次事件暴露出的问题与整改方案，值得整个行业拿来对照反思。

作者：手扶拖拉斯基