ZCode 把 Git 历史传上云，智谱解释不了的是什么

先把“上传”说清楚

这次最容易被一句“AI 编程工具本来就要上传代码”带过去。但这句话把几种完全不同的行为揉成了一件事。

这里有一个重要的证据边界：313 MB、42,411 个文件和 86.6% 的 .git 占比，是研究者对自己设备上一个项目快照的统计，不是所有用户的总量统计；failureCount: 564 也只说明该快照记录了 564 次失败重试，不能反过来证明它成功上传了 564 次。

但样本不需要代表所有用户，才足以说明设计问题。如果一个程序在用户没有明确选择“上传整个仓库”的情况下，具备了打包整个仓库并向云端发送的能力，风险就已经成立了。它到底影响了多少人，是后续需要补充的事实，不是判断这条产品边界是否越过的前提。

.git 不是一个藏起来的当前目录

很多非开发者会把 .git 理解成 Git 的缓存目录，仿佛删掉也只是丢失几个版本按钮。实际上，Git 的官方数据模型把提交、目录树、文件内容和标签都存成对象；提交对象还带着父提交、作者、时间和提交说明。Git 官方文档直接把 .git 描述为包含项目完整历史的压缩对象数据库。Git 数据模型

这意味着，工作区里当前看不见的东西，未必在 .git 里消失了：

• 后来删掉的配置和密钥，可能仍存在于尚未被回收的历史对象中；
• 没有推到远端的分支名，可能暴露正在开发的产品方向；
• .git/config 可能带出内部 Git 服务的域名、仓库路径和账号线索；
• reflog 记录本地分支和 HEAD 指针的变化，包含远端仓库通常看不到的操作痕迹。

Ferstar 给出的那份清单里，.git/lfs 约 196.1 MB，.git/objects 约 102.2 MB，.git/logs 约 0.6 MB，三者合计已经占了绝大部分体积。Git 官方也提醒，reflog 是本地仓库的记录，不会随远端分支自动共享；它恰恰因此更像开发者自己的内部草稿，而不是公开代码。Git reflog 说明

所以，“上传了代码”这个说法太轻了。上传当前工作树，是把一张照片交出去；上传 .git，是把拍摄过程、废片、草稿和删掉后仍留在底片里的内容一起交出去。

智谱的解释只解释了触发点

智谱 9 月 18 日的说明把问题归因于“代码库索引”功能，具体说是 Repo Wiki 生成时可能触发仓库数据上传，Wiki 在云端生成后相关数据会立即销毁；公司称该功能上线初期默认开启，问题已经修复，并承诺开源 ZCode、邀请第三方审查，同时给用户重置一次周额度。公开转述的官方说明

这个解释不是完全没有道理。要生成仓库 Wiki，产品确实需要读取代码；检查点恢复、版本回退也确实需要保存某种状态。问题是，产品意图不能自动替实现结果背书。

我在当天核验到的 ZCode Wiki 文档，已经把边界写得更清楚：它声称只按安全规则过滤、按需读取代码上下文，并把 .git、依赖目录、构建产物、缓存和本地运行状态排除在外。现行 Wiki 文档 这至少说明修复后的目标是什么，却不能单独证明旧版本从未把这些内容打包。

官方说明仍然留下了几处关键空白：

1. 如果上传链路只是为 Wiki 服务，为什么旧客户端快照中会出现完整 .git、LFS 和 reflog，而不是 Wiki 所需的筛选后代码？
2. 如果“优化体验”和“仓库快照索引”两个设置只影响训练授权或服务端索引，却不阻止本地捕获和上传，那么用户看到的开关就没有覆盖真正的风险点。
3. “生成后立即销毁”具体指 OSS 对象、业务数据库、备份、副本还是解密后的临时文件？保存多久、谁能查到、有没有日志或第三方审计？
4. 受影响的是哪些版本、多少工作区、哪些上传已经成功？为什么用户需要从本地 checkpoints 目录反向推测自己的状态？

这些问题没有被“这是 Repo Wiki 的默认设置”回答。它最多解释了为什么产品团队可能想读仓库，没有解释为什么客户端把数据边界扩大到了整个 Git 仓库。

“为了训练”目前不能写成事实，但训练价值确实很大

这里需要把情绪和证据分开。目前没有公开证据证明 ZCode 这批快照已经被送进了智谱的 RL 后训练数据集。把“未经说明的上传”直接写成“智谱正在偷拿代码训练模型”，在事实层面跨了一步。

但反过来，把完整 Git 仓库说成“对训练没什么用”，同样不诚实。智谱自己的 ZCode Agent 文档把 GLM-5.3 的 Agentic Coding 后训练描述为覆盖长轨迹、多轮工具调用、子任务分解和环境反馈。ZCode Agent 文档 这至少说明，软件工程过程数据正是它想优化的对象。

一份完整仓库能提供什么，取决于它有没有和会话、工具调用及执行结果关联起来：

这也是为什么“完整仓库”比“当前文件”更有价值：它不只是更多 Token，而是包含了状态变化。如果再把用户 Prompt、Agent 的工具调用、补丁、测试输出和最终结果串起来，就能形成一条接近真实软件工程的轨迹。相关研究已经把仓库级上下文、可执行反馈和编码轨迹视为代码 Agent 自我演化的重要证据；另一项代码修复研究也使用真实仓库和构建验证来做 RL，并报告 RL 在匹配环境下带来明显收益。Self-Evolving Coding Agents、Agentic Reinforcement Learning for Real-World Code Repair

不过，一份快照本身不是 RL 数据集。它更像训练环境的状态和原料，离“知道用户想完成什么、Agent 做了哪些动作、哪个结果应该得到奖励”还差几步。正因为训练价值需要通过这些关联才能兑现，数据的用途、留存和是否进入训练，就更应该在采集之前说清楚，而不是等用户发现加密包之后再用“生成 Wiki”概括过去。

我的判断是：不能据此认定智谱已经拿这些仓库做了后训练；但完全可以认定，这不是一批没有价值的误上传数据。它潜在地覆盖了模型最缺、也最昂贵的真实工程过程。对用户来说，是否已经训练只是一个问题；厂商是否在没有明确授权的情况下建立了获取这类数据的能力，是更早、更确定的问题。

真正塌掉的是信任边界

这件事还暴露了一个经常被“开源模型”四个字遮住的区别：模型权重开放，不等于包裹模型的桌面端、Agent Harness、更新机制和数据通道都开放。

用户可以在本地运行一个开放权重模型，却把整个工作区交给一个闭源运行时；模型可能没有主动上传工具，桌面端的 sidecar 仍然可以在模型调用之外打包文件。此时“我用的是本地模型”并不能推出“代码没有离开电脑”。

一个合格的仓库索引功能当然可以存在，但至少应该做到：

• 第一次启用时明确说明上传对象、目的、留存时间和接收方；
• 打包前展示可读的文件清单，并把 .git、密钥、依赖和构建产物在打包层硬排除；
• “是否上传”“是否建索引”“是否用于改进模型”是三个独立、可验证的开关；
• 用户拥有停止上传、删除云端数据和查看处理记录的入口；
• 客户端、服务端协议和删除流程接受独立审计，而不是只承诺“近期会开源”。

对已经使用过 ZCode 的人，最现实的动作也不是等一句“我们不会保存”：先升级到明确修复后的版本，检查 ~/.zcode/v2/checkpoints（Windows 通常对应 %USERPROFILE%\.zcode\v2\checkpoints）里是否还有待上传快照；如果仓库历史中曾经出现过密钥、令牌或内部凭据，就按已经暴露过来处理并轮换，而不要只检查当前工作树。删除本地待上传文件，也不能证明云端曾经没有收到副本。

智谱现在最需要补的不是额度，而是证据。开源主程序、公布受影响版本和用户范围、解释开关与上传链路的对应关系、提供删除和留存审计，才能回答这次争议真正的问题：用户交给它的是一次明确的代码调用，还是一座自己并不知道已经被搬走的仓库矿山。

参考资料

• Ferstar：扒一扒 ZCode 静默上传全量 Git 历史的骚操作，2026 年 9 月 18 日。本文关于快照体积、文件清单、加密和触发逻辑的主要技术材料。
• ZCode 官方 Wiki 文档，2026 年 9 月 18 日核验。用于对照修复后文档声称的读取范围与排除规则。
• ZCode Agent 官方文档，2026 年 9 月 18 日核验。用于说明官方对长轨迹、工具调用和环境反馈后训练的产品表述。
• 新浪科技转述的智谱 ZCode 说明，2026 年 9 月 18 日。用于核对官方回应、修复、开源和额度重置说法。
• Git 官方数据模型文档 与 git-reflog 文档，2026 年 9 月 18 日核验。用于说明 .git、Git 对象和 reflog 的数据含义。
• Self-Evolving Coding Agents，2026 年 8 月。用于说明仓库级上下文、可执行反馈和编码轨迹在代码 Agent 研究中的位置。
• Agentic Reinforcement Learning for Real-World Code Repair，2025 年 10 月。用于说明真实仓库、构建验证和 RL 后训练之间的关系。