一、起点：开发者本地发现“没发出去”的密包

9月18日，开发者 ferstar 清理本地目录时发现一个 313MB 加密压缩包，对应自己 10GB 商业项目的工作区快照：完整 .git 历史、LFS 缓存、reflog、应用配置都在里面，状态文件显示已尝试上传 564 次失败，所以留在本地才被看见。

他逆向客户端后还原出链路：
1. 登录态下 ZCode 自动生成工作区快照
2. 向 zcode.z.ai 申请上传凭证 + 服务端下发的 RSA 公钥
3. 本地加密 → 直传阿里云 OSS
4. 私钥在云端，用户自己和客户端都解不开
5. 界面里的“优化体验 / 仓库快照索引”开关，并不能真正阻止打包上传 

多人复现后，智谱当天下午致歉：问题来自“代码库索引 / Repo Wiki”，上线初期默认开启，云端生成 Wiki 后“立即销毁、不保存”，已修复，并承诺开源、第三方审查、补发周额度。

二、升级：企业用户说“不止代码片段，而且还在传”

9月19日晚，太原承明科技发正式函，把事件从“开发者舆情”抬到“企业商业秘密 + 数据出境合规”：
• 8月28日—9月14日，公司 6 个工作区被上传，最大 391.94MB

- 另一个项目打包后传了 32 次失败，留在本地
• 内容不是代码片段，而是：完整源码、系统架构、已删除 git 提交、数据库口令、接口密钥、云服务凭证、员工/终端用户信息、未公开研发规划

• 行为自动触发、批量发生，“不以本公司同意为前提”

- 智谱致歉当天，他们仍检测到上传行为 

三、最要命的一点：中文版 / 英文版协议“两张皮”

承明科技揪出数据流向矛盾：
• ZCode 网络请求指向 zcode.z.ai / cdn-zcode.z.ai

• 英文版协议：服务提供与数据处理者是 JINGSHENG HENGXING TECHNOLOGY PTE. LTD.（新加坡），写明“服务通常自新加坡提供”“个人数据通常在新加坡处理”

• 中文版协议：服务提供方是 北京智谱华章，隐私政策规定境内收集数据存境内、不跨境，跨境需告知并征得同意

- 智谱港交所招股书里，新加坡公司是智谱 2023 年 11 月设立的全资子公司 

所以承明科技的核心追问是：
实际数据处理主体到底是谁？数据有没有出境？有没有境外存储？有没有给第三方？有没有拿去训模型？

四、智谱后续动作（9月21日）

• ZCode 3.14.0：更新日志写“修复仓库百科异常上传”，社区逆向显示旧上传接口返回 404、快照上传链路被拆掉 

• 9月21日智谱再回应：邀 中国信通院 + 绿盟科技 审计；信通院测评称 zcode-prod OSS 存储桶“云端零数据”，绿盟确认存储桶和对象已删除；v3.14.0 已移除 Repo Wiki 与快照外发路径 

- 宣布 ZCode 代码库开源
• MaaS 平台将上线“数据内容不留存”机制 

五、这件事的真正问题，不在“上传了一次”

1. 默认开启 + 无等效开关：AI 编程工具要读上下文也就罢了，把整个 git 历史/密钥/凭证打密包传走，是“开发辅助”越界成“资产收割”。
2. 加密权不在用户：服务端下发公钥 = 用户获得“保密错觉”，云端获得“唯一解密权”。
3. 隐私政策与实体架构不一致：中文承诺境内处理，英文指向新加坡主体——企业法务最怕这种“跨境责任模糊”。
4. “立即销毁”不可自证：客户端不传了 ≠ 服务端没备份、没进训练流水线、没被员工/子系统访问过。没有审计日志和删除证明，一句话安抚不了 B 端用户。
5. AI 编码工具的商业模式原罪：要懂仓库就要碰仓库；碰了仓库就可能顺手拿去改 RAG、做评测、训 Agent。如果不把“默认不传、可验证不传、云端零留存、跨域单主体”写死，下次换个国家/换个子产品还会出事。

六、一句话定性

ZCode 这次不是“bug 没写好”，而是把企业最敏感的研发资产，按消费级 SaaS 的默认逻辑处理了。  
开发者靠“上传失败 564 次”救了自己一回；企业用户靠发函把问题抬到数据出境；但大多数个人开发者、外包仔、小团队——传成功了的，可能永远不知道传过。

要不要我顺着把AI 编程工具（ZCode / Cursor / GitHub Copilot / Grok Build / Claude Code）的“仓库权限边界 + 数据留存红线”整理成一份开发者和公司都可直接用的选型避坑清单？