ZCode 的仓库快照，越过了哪些数据边界

先看包里有什么，再问为什么打包

“AI 编程本来就要上传代码”绕过了最关键的区别。主动交给模型的当前文件、桌面端捕获的工作区、仓库的版本历史，是三种不同范围的授权。允许工具读代码，不意味着同意它在另一个时刻，把另一批数据交给服务器。

.git 也不是一份可以忽略的缓存。Git 把提交、目录树和文件内容存成对象，提交还关联父提交、作者、时间和说明。当前工作树只是其中一个状态。后来删除的配置和密钥，可能仍留在尚未回收的历史对象里；没有推到远端的分支、本地 reflog、.git/config，还可能带出开发方向、操作痕迹和内部服务地址。

Ferstar 的清单里，.git/lfs 约 196.1 MB，.git/objects 约 102.2 MB，.git/logs 约 0.6 MB。问题因此不只是多传了几个文件：远端代码托管平台通常看不到的本地记录，也可能随着快照离开电脑。上传工作树像交出一张照片，上传 .git 则可能连草稿、废片和底片一起交出去。

不过，这份技术材料能证明到哪一步，需要说清。快照清单支持对采集范围的质疑；逆向重建的链路支持对发送能力的质疑；具体哪些包已经成功抵达云端，还需要对应记录。failureCount: 564 是失败重试计数，不能说成成功上传了 564 次。把这些层次混在一起，反而给真正需要回答的问题留下了躲避空间。对一个用户，后果还取决于哪些数据成功上传、谁访问过以及如何使用；对产品设计，待上传包中已经出现不应默认采集的内容，就值得追究。前者需要补齐影响范围，后者要求收紧采集规则，不能用其中一项尚未查清来搁置另一项。

加密也没有替用户解决这个问题。在研究者重建的链路中，临时密钥由服务端公钥封装，本地没有可自行解密的密钥。这没有把解密控制权交给用户，也不能据此排除服务端读取内容的能力。用户拿到本地密文，无法据此独立审计内容，更不能从“已加密”推出“厂商无法读取”。

“生成 Wiki”能解释用途，解释不了范围

据 2026 年 9 月 18 日媒体转述的群内官方回应，智谱将上传归因于代码库索引和 Repo Wiki：该功能上线初期默认开启，Wiki 在云端生成后相关数据会立即销毁。公司称问题已修复，承诺开源 ZCode、邀请第三方审查，并给用户重置一次周额度。

这不是一个完全不成立的解释。生成仓库 Wiki 确实需要读取代码，检查点恢复也需要保存状态。仅凭一个包含历史的快照，不能排除实现粗糙、多个功能共用捕获链路等解释，更不能跳到“训练才是真实目的”。但无论意图是哪一种，产品都需要回答同一个问题：为什么它实际收集的内容，比用户启用的功能所展示的范围更宽？

是否修复要看实际版本和实现，旧数据如何处理则是另一项责任。对产品目的的解释不能代替对旧版采集范围的交代，新的承诺也不能证明旧包从未形成或上传。

用户界面里的开关尤其需要讲清楚：

如果关闭“优化体验”只撤回训练授权，关闭“仓库快照索引”只改变服务端处理，两者都不能停止本地捕获和上传，那么用户看到的关闭状态就不能表达他想要的拒绝。这里需要的是开关与实际链路的对应证据，不能靠名字猜。

“立即销毁”同样要有可核对的对象：删的是 OSS 对象、解密后的临时文件，还是也包括副本、备份及其他存储？哪些版本受影响，哪些工作区成功上传，处理日志能否支持删除承诺？这些空白没有被“这是 Repo Wiki 功能”填上。即使 Wiki 是唯一用途，过宽的采集边界仍然需要解释。

完整 Git 仓库有训练价值，但不是现成的 RL 数据集

原先让我警惕的另一点，是这类数据并非没有用的误上传文件。仓库保留了多少历史，取决于克隆深度、分支和对象回收等条件。能取得的历史不只是更多 Token，还有同一工程的状态变化：一次重构改了哪些模块，一个尝试后来被怎样回退，测试资产和依赖又给改动施加了什么约束。

仓库上下文、执行反馈和真实工程验证已经是代码 Agent 研究中的重要材料。例如 2026 年 8 月公布的自演化编码 Agent 研究，以及真实代码修复的强化学习研究，都讨论了这些连接。它们支持对潜在价值的分析，不能证明智谱实际使用过这批快照。

但 Git 历史不等于完整的工作过程。提交说明未必交代用户真正想做什么，回退未必证明前一步错误，分支留下的也可能只是个人操作噪声。一个补丁最终被提交，不代表它已经通过可靠测试，更不自动提供强化学习所需的奖励信号。

要把这些原料变成可用轨迹，还需要把用户 Prompt、Agent 工具调用、补丁、测试输出和最终结果对应起来，并处理环境复现与敏感信息。快照提供状态，关联记录补出动作和意图，验证结果才帮助判断动作是否有效。 缺少这些连接，不能把一个加密包直接叫作 RL 训练样本。

所以，我不接受两种省事的说法。一种是“拿到了完整仓库，所以已经用于后训练”；截至 9 月 18 日，材料没有公开证据支持这一步。另一种是“只是生成 Wiki，所以无需讨论训练价值”。有价值不证明已经使用，但恰恰要求用途限制和授权更明确。用户不该等到发现加密包，才知道厂商已经具备获取这类工程数据的能力。

信任要靠哪一层兑现

这件事也提醒我，“模型权重开放”与“工具的数据通道透明”相隔很远。桌面端、Agent Harness、更新机制和 sidecar 都可能在模型调用之外工作。即便运行本地模型，也不能仅凭这一点推断工作区没有离开电脑；要检查的是承载模型的整套运行环境。

仓库索引当然可以做。合理的起点，是首次启用时说清上传对象、目的、接收方和留存时间，打包前展示可读清单，并在打包层排除 .git、密钥等不应采集的内容。停止上传、删除云端数据、查看处理记录，也应是用户能够执行和核对的动作。

对已经用过 ZCode 的人，按这次事件的材料，应该关注明确修复后的版本，并检查 ~/.zcode/v2/checkpoints；Windows 通常对应 %USERPROFILE%\.zcode\v2\checkpoints。本地没有待上传文件，不等于云端没有副本。如果历史中曾出现密钥或内部凭据，就不能只检查当前工作树，需要按可能暴露处理并轮换。

我更关心智谱接下来交出什么证据：受影响版本与范围、开关对应的行为、成功上传记录，以及留存和删除审计。开源可以帮助检查客户端，额度重置可以补偿使用体验，却都不能替代这些回答。用户交出去的究竟是哪一批文件，应当在包离开电脑之前就看得见。

参考资料

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