事件爆发：独立开发者发现异常加密文件

9月16日，一位网名为ferstar的独立开发者在清理磁盘时，发现智谱ZCode的数据目录异常占用了700多兆空间。深入排查后，他在checkpoints文件夹中发现了一个313兆的加密文件及对应的明文状态记录。该记录揭示了令人震惊的数据打包细节：本地一个10GB的商业项目，排除依赖包后仅核心知识产权部分就被打包为345兆。更关键的是，状态文件中显示该包的类型为“baseline基线”，即全量基线快照而非增量更新。这意味着智谱并非只上传修改部分，而是将整个项目核心代码一次性打包。此外，状态文件中记录的“失败次数”高达564次，表明ZCode在本地不断重试上传这313兆的加密包，即便用户删除文件，系统也会重新生成并继续计数上传。这种执着且隐蔽的行为让ferstar意识到这并非简单的缓存错误，而是有预谋的数据抓取。

技术拆解：非对称加密与绕过业务服务器的上传路径

为了查明真相，ferstar利用TypeScript源码可反编译的特性，对ZCode客户端进行了逆向工程分析。他发现整个上传流程采用了非对称加密机制：客户端首先向智谱服务器请求公钥，随后在本地将包含整个Git仓库历史的数据包使用公钥加密。由于私钥仅在服务器端持有，用户本地无法解密查看上传内容。最恶劣的是，加密后的数据包被直接发送至阿里云对象存储，绕过了智谱自己的业务服务器表单。这种架构设计使得上传行为在应用服务器的日志中不留痕迹，具有极强的隐蔽性。ferstar通过明文存在的“打包文件清单”进一步确认了内容构成：42,411个文件中，Git大文件缓存占56.8%（196.1兆），完整提交历史对象库占29.6%（102.2兆）。整个包中高达86.6%的内容是Git目录，而当前源代码仅占13.4%。这种设计不仅泄露了代码逻辑，更可能暴露历史密钥、未发布的本地分支及开发过程中的所有踩坑记录。

隐私政策与功能开关的虚假性：加密包无法关闭且无明文告知

面对公众质疑，智谱在9月18日发布的隐私政策FAQ中仅提及“收集你在对话中提交的文本、文件和代码”，对全仓快照和Git历史只字未提。然而，实际行为与政策严重不符。ZCode客户端虽然设有“优化体验”和“仓库快照索引”两个开关，但ferstar测试发现关闭这两个选项后，数据依然照常打包上传。这表明隐私控制开关形同虚设。触发机制也极为激进：一是每次用户提交Prompt（回车）时即尝试抓取；二是标记为“仓库Wiki更新”的任务完成时触发。智谱声称这是为了构建代码索引以节省Token，但将完整的Git历史打包上传并非生成Wiki所必需的操作。这种“默认开启、无法关闭、加密传输”的设计，配合9月18日当天发布的道歉声明中声称“问题已修复但未更新软件版本”的做法，引发了关于“云控开关”的严重担忧——即智谱可能在云端随时重新开启该功能，而用户对此毫无感知和控制权。

公关应对与行业对比：避重就轻的道歉与“为了你好”的话术

事件曝光后，智谱在官方飞书群内发布道歉声明，承诺开源代码、接受第三方审计并重置用户额度。然而，其应对策略被指“避重就轻”：仅承认代码库索引功能存在问题，却未提及每次回车即上传的激进机制。更令人不安的是，声明发布后ZCode版本并未更新（仍为9月17日发布的3.12.3版），且GitHub上未建立任何官方开源仓库，第三方审计机构及报告也未公布。这种“先安抚后拖延”的策略让人联想到360等厂商曾使用的“为了你好”式话术——以优化体验或安全为名，行侵犯用户数据之实。对于B端和政府客户而言，这种将完整开发历史上传至第三方服务器的行为构成了巨大的合规风险。尽管智谱承诺“索引完成后立即销毁代码”，但由于加密密钥掌握在云端，用户无法验证数据是否真正被删除。目前，智谱的开源承诺和审计进展仍待观察，这一事件也引发了整个AI编程工具行业对数据隐私边界的深刻反思。

竞品隐私机制与智谱行为的本质差异

在代码上传争议中，Cursor、Claude Code 和 Codex 等主流工具均采取了更为克制的隐私保护策略，这与智谱的行为形成鲜明对比。Cursor 将代码切分为小块进行向量化处理，明文上传计算后直接删除源文件，服务器仅保留向量结果和混淆后的文件名。其官方文档明确承诺不存储用户代码，且提供隐私模式开关，开启后不再上传数据。Claude Code 则在本地读取源文件，仅将当前任务所需部分发送至接口，不建立索引也不上传整个仓库。对于企业版和 API 客户，其承诺数据绝不用于训练。Codex 同样强调本地运行，虽然提供云端版本以便在沙箱中执行，但这需要用户主动下单，且不会在未授权情况下上传整个仓库。相比之下，智谱被指在用户登录时即自动上传完整的 Git 历史，且加密打包传输。这种一登录就全量扔上去的行为，在业界并无先例。

智谱开关失效与“开源”承诺的疑点

尽管智谱声称拥有有效的隐私开关，但实际体验显示该功能形同虚设。用户关闭上传开关后，数据仍在持续传输；甚至在删除本地仓库并重建后，智谱依然能获取代码。这种开关做摆设、关了还传的做法，被作者定性为“你没得选”而非简单的 Bug。此外，智谱在事发后承诺开源以自证清白，但这一策略存在巨大风险。作者引用了马斯克旗下 xAI 的 Grok Build 案例：该工具曾在今年 7 月将包含 SSH 密钥等敏感信息的完整 Git 包上传至谷歌云，即便用户要求关闭仍继续传输。xAI 随后开源了代码，但被扒出两个猫腻：一是上传功能仅通过注释停用而非删除，云端开关随时可恢复；二是开源仓库清除了所有历史提交记录（Commit），只保留了经过大量补丁打制后的最终版本。智谱目前尚未建立官方仓库，其“开源”承诺是否也会经历同样的第二刀清洗历史的过程，仍有待观察。

开源模型与 AI Agent 工具的安全边界辨析

针对“使用中国开源模型不安全”的观点，作者指出这是一种误解。开源大语言模型（LLM）本身可以部署在本地或全球任何服务器上，其潜在风险主要限于回答中的意识形态偏差，这完全可以通过微调（Fine-tuning）来解决。例如，日本、阿联酋和沙特等地已成功利用中国开源模型进行定制化调整。使用本地部署的开源模型在安全上是可控的。然而，风险的核心在于AI Agent 工具（如编程助手或办公插件）。这类闭源工具会读取、传输甚至写入本地文件，构成了实质性的数据泄露渠道。作者建议用户优先选择活跃的开源 AI Agent 项目，如 DeepSeek Harness、小米 MiMo Code 或 Kimi Code（仅 CLI/TUI 部分开源）。对于闭源产品如 MiniMax Code、豆包或 WorkBuddy，若代码内容涉及隐私（“小心思”），则应谨慎使用。作者自身主力工具为 Claude 和 ChatGPT，仅在无隐私顾虑时使用豆包等闭源产品。

事件总结与使用建议

智谱此次事件并非简单的代码片段泄露，而是项目从生到死完整过程的窃取。尽管官方道歉迅速且承诺修复、开源及第三方审计，但截至文章发布日（9月18日后），未建立仓库、未发布新版本、无审计动作。作者认为，对于国产 AI Agent 工具应保持警惕，优先选择开源且社区活跃的项目。闭源产品若缺乏透明度（如开关失效、历史清洗），则存在极大的隐私隐患。事无不可对人言是判断工具安全性的简易标准：若用户无法坦然公开其代码内容，则不应使用存在黑盒传输风险的 Agent 工具。

结论

智谱ZCode事件证实了其在未充分告知且无法有效关闭的情况下，通过非对称加密绕过业务服务器日志，将包含完整Git历史及核心代码的全量基线快照上传至第三方存储。尽管官方承诺开源并接受审计，但截至观察期未发布新版本或建立仓库，且隐私开关形同虚设，存在云端随时恢复传输的隐患。

与Cursor等竞品仅上传必要片段不同，智谱的行为构成了实质性的数据泄露风险。对于涉及敏感代码或合规要求高的用户，该工具目前不具备安全性；建议优先选择开源透明、具备本地控制权的AI Agent工具，遵循“事无不可对人言”的使用原则。