事件起源：开发者意外发现静默上传机制

9月17日晚，知名开发者ferstar仍在技术群中推荐智谱旗下的AI编程工具ZCode。然而次日，他在清理一台存储仅256G的MacBook Air时，发现用户目录下的zcode文件夹异常庞大。占用超过700兆空间的文件夹中，包含约257兆本地会话数据库、130兆应用依赖，以及一个引发争议的v2/checkpoints目录。该目录下存在一份超过300兆的加密文件，状态显示ZCode扫描了用户本地打开的一个商业项目。系统将该项目的约345兆工作区内容打包、加密，生成了313兆的基线全量快照。由于文件体积过大，上传连续失败564次，导致加密包一直滞留在本地pending目录中等待重试。

“真正引起他注意的，是一个叫v2/checkpoints的目录，里面放着一份超过300兆的加密文件。”

尽管ferstar通过路由器日志确认数据未离开局域网，但核心问题在于ZCode为何在用户无主动操作下生成仅服务端可解密的文件并反复尝试上传。为查明去向，ferstar拆解了客户端app.asar文件，还原出完整流程：ZCode向zcode.z.ai请求凭证后获取阿里云OSS签名及RSA公钥，在本地将项目压缩为tar.gz格式，使用AES-256-CTR加密并用RSA封装密钥后上传。值得注意的是，这并非未启用的预留代码。ferstar发现一份仅538个文件、加密后约15KB的公开代码仓库快照已成功被服务端接收，且其他Windows用户也复现了相同机制。

数据构成与隐私政策缺失的严重错位

ferstar进一步分析了本地留下的快照文件清单，在一个包含四万两千多个文件的样本中，数据构成呈现出惊人的比例失衡。.git目录占到了整个数据包的86.6%，其中Git大文件存储缓存占56.8%，Git对象库占29.6%。相比之下，真正的当前源代码和文档反而只占大约13.4%。这意味着ZCode准备上传的不仅是模型完成任务所需的代码，还包括完整的提交历史、已删除的配置和密钥、未推送分支及内部GitLab域名等敏感信息。

“ZCode准备上传的，不只是模型完成当前任务需要的那几行代码，还可能包括完整的提交历史、已经从当前版本删除的配置和密钥……”

更严重的是，用户几乎无法通过界面阻止这一行为。旧版ZCode虽有“体验优化”和“仓库快照索引”开关，但ferstar检查3.12.3版本代码后发现：体验优化仅决定数据是否用于模型训练，仓库快照索引仅控制服务端建索引。两个选项均不阻止本地生成快照或关闭上传链路。上传组件在登录后无条件启动，触发条件包括每次发送提示词前及仓库维基更新。ferstar的日志显示最多出现62次快照事件。即使手动删除待上传文件，ZCode也会在约半小时后重新生成并继续重试。

“隐私政策里没有一个字提到，会整包上传用户的全部Git历史。”

ZCode当时的隐私政策仅提及收集对话中的文本和代码，未披露工作区全量打包上传的事实。所谓的“数据优化计划默认关闭”主要针对训练用途，并不影响工作区数据的上传行为。

开发者质问与智谱的初步回应及局限

9月18日，ferstar公开调查结果并向智谱GitHub提交Issue，提出三个核心质问：第一，为何上传范围是全部而非当前上下文？回滚功能无需带走已删除的旧密钥；第二，为何加密设计为仅服务端可解？RSA私钥仅存云端，导致用户甚至客户端自身无法查看数据；第三，为何隐瞒且不可关闭？上传组件无开关控制，失败564次仍坚持重传。

“这不是bug反馈，这是对产品诚信的质问。”

ferstar提出五项要求：公开数据流向、提供真实生效且默认关闭的开关、修改加密方案让用户拥有解密能力、修订隐私政策如实披露范围与频率，以及说明已上传数据的处理及删除渠道。面对舆论发酵，智谱于当日下午发布致歉声明。官方将问题归因于ZCode的代码库索引功能，称该功能原本用于本地生成索引以支持会话检查点恢复、历史版本回退和仓库维基。由于上线初期默认开启，导致部分用户受影响。

智谱表示上传数据在维基页面生成后立即销毁，并承诺开源ZCode代码库引入第三方审查。这一回应确认了两个事实：一是确实存在仓库数据上传而非仅本地检查点；二是相关功能早期默认开启。截至9月20日，ZCode最新版本3.14.0已移除上传代码且服务器接口返回404。然而，智谱承诺的开源和第三方审查尚未完整落地。历史数据是否彻底删除、受影响用户规模及具体版本范围，外部研究者无法独立验证。智谱单方面声明的“用完即销毁”缺乏服务端日志、数据保留策略或第三方审计结果支撑。

企业追责升级与跨境传输疑虑

事件随后升级为法律博弈。太原承明科技有限公司向北京智谱华章科技发函，指控ZCode未经授权上传数据资产和商业秘密。承明科技要求彻底删除数据、说明流向、提供操作日志，并质疑数据是否可能发生了跨境传输。函件指出，独立取证发现上传是自动、批量触发的完整归档，涉及源代码、架构、版本历史、数据库口令及员工个人信息。承明科技注意到ZCode部分网络请求指向新加坡主体，但服务协议签约方为北京智谱华章。

“函件还把争议引向了两个之前没有被充分讨论的问题，一个是之前上传的数据是不是已经彻底删除了，另一个是这些数据有没有可能发生了跨境传输。”

承明科技特别提到一个关键细节：智谱在9月18日公开致歉的当天凌晨，他们仍然检测到了上传行为。这引发了对“问题已修复”声明真实性的怀疑。承明科技要求智谱说明实际数据处理者、数据存储地及第三方共享情况，并保留索赔和诉讼权利。截至目前，智谱尚未就函件作出公开回应。

行业对比：Grok Build与Cursor的技术路径差异

ZCode并非首个陷入代码上传争议的AI编程工具。今年7月，xAI旗下的Grok Build被曝将用户代码库上传至Google Cloud。安全机构Cereblab调查显示，Grok Build上传范围覆盖完整代码库、被忽略文件及可恢复的已删除数据。马斯克随后关闭自动上传并承诺删除数据。

“Cereblab当时做了一个很有意思的测试，他们用大约12G的不可压缩数据做实验……模型推理只用了不到两百KB，却上传了超过5G的仓库内容。”

Cereblab测试显示，模型请求仅用192KB数据，但存储通道接收了约5.1G。这证明存在独立的仓库上传系统而非正常上下文传输，目的地为名为grok-code-session-traces的Google云端存储Bucket。两起事件表象相似，但Grok Build主要被质疑未尊重文件排除设置，而ZCode问题更进一层：涉及完整Git历史、不可关闭的上传链路及私钥仅服务端持有。

业内处理代码仓库通常有三种方式：按需读取、代码库索引和云端工作区。Cursor采用前两种与云端智能体并存模式。技术说明指出，首次建立索引时上传每个文件生成嵌入向量，后续利用Merkle Tree算法仅同步变化部分。Cursor的语义索引主要处理代码文件及语法片段，智能体检查点保存在本地独立于Git，仅捕获修改文件状态而非完整Git对象库。

“ZCode的问题恰恰出在这里……如果目的只是恢复智能体修改过的文件，通常只需要记录修改前后的文件差异或者在本地保存检查点就够了。”

Cursor同样承认新代码库索引时会上传文件并保存哈希，但其隐私模式承诺数据不用于训练。这揭示了三个不同概念：是否用于训练、是否上传服务器及是否长期保存。关闭训练授权不等于代码不会被发送，数据经过加密也不等于服务方无法读取。ZCode实际收集范围（86.6%为.git目录）与官方解释的功能目的存在明显落差，若仅为回滚或维基生成，无需上传大文件缓存及未推送分支记录。

信任危机：从模型安全到系统架构的审视

国外播客主Cole Morgan在复盘Grok Build事件时指出，外界常聚焦模型本身（如提示词注入、敏感信息泄露），但Claude Code、Codex、Cursor等产品包含包裹模型的Harness框架。真正需要审查的对象不能只有模型，还应包括负责赋予权限、调度和处理数据的Harness本身。

“真正需要审查的对象不能只有模型，还应该包括负责赋予模型权限、调度工具和处理数据的这个Harness本身。”

存在两层信任问题：一是模型是否滥用用户赋予的权限；二是Harness是否在任务外执行额外操作（如后台建立全仓库快照上传）。此外，连接的MCP服务器、插件及云存储厂商每增加一个组件，都扩大安全暴露面。ZCode事件同时触碰后两层红线：加密私钥仅服务端持有是Harness架构选择，上传组件无条件启动且范围超出合理边界也是Harness策略问题。

“模型本身只是一个根据输入生成输出的引擎，它不会决定要不要打包整个仓库……这些都是写在Harness代码里的确定性逻辑。”

结论

智谱ZCode风波揭示了AI编程工具在数据隐私与系统架构上的深层隐患。事件核心不在于模型能力，而在于包裹模型的软件层（Harness）在未经充分告知和授权下，静默上传包含完整Git历史及敏感配置的工作区快照。尽管智谱已修复代码并致歉，但历史数据是否彻底删除、受影响范围及跨境传输情况仍缺乏第三方验证。行业需建立更清晰标准：数据采集透明、开关真实有效、加密后用户拥有解密能力。开发者应仔细阅读隐私政策，警惕设置开关的局限性，对核心项目评估风险或采用本地部署。AI编程工具的安全信任基础，正从单一的模型可靠性转向对整个软件系统数据生命周期的审视。