比 Grok、Cursor 都狠？智谱ZCode“偷传代码”风波升级，企业发函追责

摘要：这场风波最初并不是由安全公司披露，也不是因为用户发现代码已经泄露，而是源于一次普通的磁盘清理。 9月20日，ZCode“静默上传代码”风波进一步从开发者社区的技术质疑，升级为企业层面的正式追责。 太原承明科技有限公司向ZCode客户端开发运营方北京智谱华章科技股份有限公司发出函件，称ZCode涉嫌在未经充分告知和授权的情况下，上传其公司数据资产及商业秘密，并就数据删除、流向说明、操作日志、责任主体和可能的数据出境等问题提出多项整改要求。 承明科技要求智谱在10月10日前作出书面答复，同时保留索赔、向监管部门投诉举报及提起诉讼等权利。 按照承明科技在函件中的说法，其独立取证发现，相关上传并非偶发的代码片段传输，而是自动、批量触发的完整归档，可能涉及项目源代码、系统架构、版本控制历史、数据库口令、云服务凭证及员工个人信息。 承明科技还称，在智谱9月18日公开致歉当日凌晨，其仍检测到相关上传行为，因此对智谱所称“问题已经修复”的具体时间和实际效果提出质疑。 函件还将争议引向两个此前尚未得到充分说明的问题：此前上传的数据是否已经彻底删除，以及数据是否可能发生跨境传输。 承明科技称，ZCode部分网络请求指向新加坡主体，而产品服务协议的签约方为北京智谱华章，因此要求智谱说明实际的数据处理者、存储地点及是否向第三方共享。 据企查查显示，太原承明科技成立于2026年4月20日，距今也才不到半年时间。 截至发稿前，智谱尚未就这封函件作出公开回应。 今天晚些时候，InfoQ 联系到了承明科技发言人，确认发函属实。据其介绍，承明科技向 ZCode 发送的电子邮件中一共包含四份附件，内容为相关取证记录和取证报告。原问责函链接下午曾短时间无法访问，现已恢复可正常访问。 事件回溯 整场风波的起点，要从一名开发者清理电脑磁盘时发现的一个313MB加密包说起。 9 月 17 日晚，开发者 ferstar 还在技术群里向其他人推荐智谱旗下的 AI 编程工具 ZCode。 第二天，他在清理一台只有 256GB 存储空间的 MacBook Air 时，发现用户目录下的 ~/.zcode 文件夹占用了超过 700MB 空间。 其中，约257MB来自本地会话数据库和执行日志，约130MB属于应用程序及运行依赖。真正引起他注意的，是一个名为 v2/checkpoints 的目录：这里存放着一份超过300MB的加密文件。 与这份文件对应的状态信息显示，ZCode曾扫描其本地打开的一个商业项目，将约345MB的工作区内容打包、加密成一份313MB的“baseline”全量快照，并尝试上传。由于文件体积等原因，这次上传连续失败了564次，加密包一直停留在本地的 pending 目录中等待重试。 需要明确的是，这个313MB的商业项目压缩包最终并没有成功传出本地。 开发者后来通过路由器连接记录和流量日志确认，相关数据没有离开局域网。但问题也由此出现：ZCode为什么要在用户没有主动操作的情况下，把整个项目制作成只有服务端才能解密的文件，并反复尝试上传？ 为了弄清这份加密包的去向，ferstar 进一步查看了ZCode的运行日志，并拆解客户端的 app.asar 文件。其还原出的上传流程显示，ZCode会先向 zcode.z.ai 请求快照上传凭证；服务器随后下发阿里云OSS表单签名、文件路径、大小限制和RSA公钥；客户端则在本地将项目压缩为 tar.gz，使用AES-256-CTR加密，再用服务器下发的RSA公钥封装密钥，最后把文件直接上传到阿里云OSS。 这不是一段没有启用的预留代码。除上述上传失败的商业项目外，ferstar 还发现，一份只有538个文件、加密后约15KB的公开代码仓库快照，状态已经显示被服务端接收。 ferstar 表示，其他 Windows 用户也复现了相同的目录、状态文件和上传机制。 本地留下的快照文件清单显示，在一个包含42411个文件的样本中，.git目录占整个数据包的86.6%：其中Git LFS缓存占56.8%，Git对象库占29.6%，reflog操作记录占0.2%，当前源代码和文档反而只占约13.4%。 这意味着，ZCode准备上传的不只是模型完成当前任务所需的代码片段，还可能包括完整提交历史、已经从当前版本删除的配置和密钥、尚未推送的本地分支、内部GitLab域名，以及历史操作记录。 更大的问题在于，用户当时几乎无法通过产品界面阻止这一过程。 用户关闭设置，为什么仍然挡不住上传？ 争议的另一个焦点，是用户是否拥有明确的知情权和关闭权。 旧版ZCode界面中存在“体验优化”和“仓库快照索引”两个相关选项。按照通常理解，用户关闭这些功能后，客户端至少不应继续把整个仓库上传至云端。 但 ferstar 对 3.12.3 版本的代码检查发现： “体验优化”开关只决定用户数据是否被授权用于模型训练，“仓库快照索引”开关只控制服务器是否对已经上传的快照建立索引。两个选项都不会阻止客户端在本地生成快照，也不会关闭上传链路。 相关上传组件在用户登录后便被加载，没有通过用户偏好设置进行前置判断。代码中还存在两类触发条件：一类是在用户每次发送提示词之前执行快照，另一类与 `repo-wiki-update` 任务有关。ferstar 的一段会话日志中，最多出现过62次快照事件。 他曾手动删除这份待上传的313MB文件，但约半小时后，ZCode又重新生成了一份，失败次数也从564次增加到565次。 根据 ferstar 在9月18日存档的ZCode隐私政策，当时政策只明确提到平台会收集用户“在对话中提交”的文本、文件和代码，没有明确披露客户端可能打包完整工作区、Git历史并上传云端。ZCode所说的“数据优化计划默认关闭”，也主要针对训练用途，并不等于工作区数据不会被上传。 这彻底惹怒了ferstar。 9月18日，ferstar 公开完整调查，并在智谱 GitHub 官方反馈仓库提交 Issue，要求智谱解释上传范围、数据用途、保存时间、关闭机制及存量数据处理方式。 该Issue明确质问：为什么一个用于检查点恢复的功能，需要收集完整Git历史？为什么解密私钥只由服务端持有，用户自己都打不开？为什么用户连关闭开关都不给？ 智谱承认上传行为，称数据“用完即销毁” 随着事情的不断发酵，智谱终于坐不住了。 据IT之家报道，当天17时44分，智谱在用户群发布说明并致歉。至此，ZCode在特定版本中存在仓库数据上传行为，已经不再只是开发者单方面的逆向推测。 智谱将问题归因于ZCode的“代码库索引”功能。 按照官方解释，该功能原本用于在本地生成仓库索引，以支持会话检查点恢复、历史版本回退和Repo Wiki等能力；其中，Repo Wiki在云端生成知识库页面时，可能触发仓库数据上传。由于该功能上线初期默认开启，因此影响了部分用户。 智谱同时表示，上传数据会在Wiki页面生成后立即销毁、不会保存，相关问题已经修复。公司接下来将开源ZCode代码库，引入第三方评估人员进行审查，并公开审查进展。 也就是说，这份回应实际上确认了两个事实：一是ZCode确实存在仓库数据上传，而不仅仅是在本地创建检查点；二是相关功能早期处于默认开启状