一个藏在本地目录里的加密文件，把代码历史、后台上传和用户授权之间的距离暴露了出来。

数据截至 2026-09-19。

技术博主 ferstar 清理磁盘时，意外地发现智谱推出的 AI 编程桌面应用 ZCode 的数据目录占用了超过 700 MB的空间。沿着目录查下去，他发现到一个约 313 MB 的加密文件，以及一份记录着 564 次上传失败的状态文件。按照他公布的排查结果，这个等待重试的文件，包含了一个商业项目的代码和大量的 Git 历史数据。

于是一篇相关事件的分析文章于 2026 年 9 月 18 日被提交到社区。帖子标题直指 ZCode 在后台上传用户的 Git 历史，引来了关于隐私、开源和软件权限的讨论。据科技媒体快科技当天的报道，智谱公司很快作出回应，承认相关功能曾默认开启，向受影响用户道歉，并称问题已经修复。

智谱官网上将 ZCode 将其定位为与 AI模型 GLM 配合使用的编程工具，支持持续执行开发任务。这类工具需要读取项目，才能理解代码、修改文件和检查结果；但用户交给它的一个任务，究竟授权了多少数据处理，不能仅凭“它需要上下文”来回答。

等待上传的文件里，装着项目的过去

根据 ferstar 的排查，客户端排除依赖目录等部分内容后，将约 345 MB 的项目数据制成了一个约 313 MB 的加密基线快照。这里的“快照”，可以理解为给项目在某一时刻留存的一份副本。

而问题就出在副本的范围。

对非开发者来说，一个代码项目可能只是一组文件。但使用 Git 管理的项目，还有一套保存修改历史的资料。Git 官方文档说明，仓库中的对象存储保存版本相关对象，日志目录记录分支等引用的变化。它们帮助开发者找回旧版本，也可能保留当前文件里已经看不到的内容。

ferstar 没有解开那个加密包。他分析的是打包时留在本地的明文文件清单。在他统计的样本中，.git目录占打包内容总体积的 86.6%，其中包括版本历史对象、用于保存大文件的 LFS 缓存，以及本地操作记录；清单还涉及额外的 ZCode 全局配置文件。

这个发现无疑会改变风险的性质。假设某个密码曾被误写进代码，后来又从当前版本删除，旧提交仍可能找到它。尚未推送的开发记录、内部仓库地址，也可能包含在本地仓库资料中。获得这些内容，可能让接收方看到比当前代码更长的项目历史。

不过，“完整 Git 历史”仍需限定为本地实际存在的数据。Git 官方文档明确，浅克隆等仓库可以只包含部分历史；已经清理、不在本机的对象，也不会因为打包而重新出现。不能把这次发现扩大为所有项目从创建以来的每一份资料都已被收走。

同样，那 564 次失败记录证明的是持续上传尝试，不能单凭它断言这个文件已经上传成功。ferstar 还通过分析客户端代码和网络连接，还原了申请上传凭证、本地打包加密、直传阿里云对象存储的流程。这为上传机制提供了具体线索，但本地清单、网络连接和云端实际接收的数据，仍是不同层次的证据。

智谱的回应解释了用途，仍留下使用范围的疑问

据快科技的报道，智谱在用户群发布说明，称问题源于“代码库索引”功能，相关能力用于会话检查点恢复、历史版本回退和 Repo Wiki。后者可以理解为根据项目内容生成的说明文档。

智谱的说明称，生成 Repo Wiki 页面时可能触发仓库数据上传，页面在云端生成后，上传数据会立即销毁、不会保存。智谱同时表示，该功能上线初期默认开启，影响了部分用户，目前已经修复；后续将开源 ZCode 代码库，邀请第三方评估人员审查系统运行情况，并公开审查进展。公司还宣布额外提供一次周额度的重置。

这份回应确认了相关功能存在上传仓库数据的情形，也给出了产品用途上的解释。它没有逐项回答分析文章中的全部发现。

ferstar 称，他分析的客户端会在提问前等节点捕获快照；“优化体验”开关只影响训练授权，“仓库快照索引”开关只影响服务端索引，这些都不能阻止打包上传。智谱的说明则把上传与 Repo Wiki 的生成联系起来。两者描述的具体触发条件如何对应，为什么快照涉及 Git 历史，哪些版本受到影响，公开说明尚未交待清楚。

“已修复”是公司的声明。说明没有提供足以逐项复核的修复版本、改动清单和测试结果；“立即销毁”也需要服务端证据支撑。可以说，这些问题仍属待核实的状态。

加密把解密权交给了谁

这次争议中，一个容易引发误解的细节是：文件明明已经加密，为什么仍有隐私问题？

按照 ferstar 还原的流程，客户端用临时密钥加密文件，再用服务器提供的公钥封装这把密钥，相应私钥根本不在客户端手中。这属于常见的非对称加密，可以降低数据在传输、存储环节被无关第三方读取的风险。

但加密保护的对象是有边界的。如果解密能力由服务端的密钥体系控制，用户就不能据此获得“服务提供者也读不到”的保证。判断隐私时，需要继续了解谁能调用解密能力、什么任务可以读取数据，以及读取行为是否留下审计记录。

分析文章中进一步把服务端持钥视为收集代码的动机证据。这个推论有点激进。云端处理、托管备份等功能，也可能采用服务端管理密钥的设计；若要在云端分析代码，系统通常需要在某个处理环节获得可读内容。仅凭这套加密架构，无法证明代码上传的恶意目的，更不能证明代码已被用于模型训练。

能够得出的结论更具体：这种设计要求用户信任服务提供者的访问控制和数据处置。但是，一款值得托付产品必须清楚说明这份信任包含了什么。

“不用于训练”只回答了一个问题

核对 ZCode 的隐私说明时，可以看到两个与此直接相关的表述。该页面标注于 2026 年 6 月 15 日生效，说明产品会收集通过对话提交的文本、文件和代码；它也说明，优化计划默认关闭，用户主动加入之前，相关数据不会用于产品或模型的训练与优化。

这份政策没有明确描述自动打包工作区及 Git 历史的机制。更值得对照的是，该声明自身也写明，同意隐私政策不构成对附加功能开启的单独同意，相关授权应结合实际使用另行取得。

训练授权之外，还有数据能否离开设备、发送哪些文件、由谁处理、保留多久等问题。关闭训练选项，并不会在逻辑上自动关闭用于其他目的的上传。一个标注“优化体验”的开关，如果没有说明它究竟控制哪个环节，就很难帮助用户作出准确的选择。

同理，即使智谱所说的“生成后立即销毁”完全落实，上传前的授权问题依然存在。短期处理也可能接触商业秘密。对于某个项目，限制可能就是不得交给外部服务处理，而不限于不得长期保存。

还有一个容易被忽略的后续问题：原始仓库删除之后，生成的 Wiki、索引和相关日志如何处置？这些产物可能保留项目结构或实现细节。这里没有证据表明 ZCode 存在某种特定的衍生数据留存问题，但一份完整的数据说明应当覆盖它们。

如果隐私承诺只强调“不训练”或“不保存”，用户仍可能无法判断一次操作究竟会发生什么。

Grok Build 曾暴露相似的开关问题

2026 年 7 月，研究者 Cereblab 对马斯克旗下的 AI 编程命令行工具 Grok Build 做过类似排查。他要求工具只回复“OK”，不要打开文件，却截获了包含仓库及 Git 历史的上传数据，并从中重建了仓库。这要比发现一个待上传文件更进了一步。

据 Cereblab 的后续测试，7 月 13 日服务端下发禁止整库上传的配置后，该行为停止；/privacy控制的则是数据保留，并非阻止传输。科技媒体 The Register 随后的报道记录了马斯克删除此前上传数据的承诺，同时明确表示无法独立验证删除结果。

两起事件的具体实现和证据强度不同，都提示我们关注后台功能如何扩大数据使用范围，以及隐私设置究竟控制哪个环节。选择编程助手时，厂商的品牌声誉只能提供有限的判断依据，还需要核对数据流程、默认设置和撤回授权后的实际效果。

附带功能不应自动继承更大的授权

Hacker News 讨论里，用户 ThouYS 用反讽表达了一种观点：既然已经让 AI 工具把代码发送到云端、在机器上执行命令，发现它上传代码又有什么意外？

这个反问触及了技术现实，却省略了授权范围。让工具读取某个函数以修复错误，与让另一个后台模块整理项目历史并上传，在目的和数据量上都有区别。前一次许可，不能自动替后一次作决定。

从产品设计上看，问题可能出现在功能相互依赖的地方。为了支持恢复，系统先生成快照；为了生成文档，另一个模块复用这份快照；为了减少操作步骤，上传被设为默认行为。这里描述的是一种可能的设计风险，当然我们无法据此认定 ZCode 内部的开发过程就是如此。

它提示我们检查的，是数据用途发生变化的位置。一份资料为本地恢复而生成，并不意味着它自然获得了上传到外部服务的许可。工程上方便复用的对象，可能需要重新征求用户同意。

也不宜反过来规定，所有 AI 任务只能读取几个代码片段。分析跨模块故障、梳理大型项目或生成文档，确实可能需要较广的上下文。合理范围应由用户选择的任务决定，并说明排除项；涉及历史记录或额外目录时，应当有进一步的理由和选择。

一个清楚的授权界面，应让用户理解此次将发送当前代码还是历史数据，是否包含未提交文件，发送给谁，关闭之后哪些功能会受影响。普通用户不应该先学会分析AI助手的代码，才能知道自己究竟同意了什么。

信任需要能被复核的修复

智谱承诺开源和引入第三方审查，给出了可以继续检验的方向。公开客户端代码，有助于外部人员检查文件筛选、上传触发和开关逻辑。但它还需要与实际分发的软件版本对应；云端留存、访问权限和删除流程，则需要另外的审查证据。

编程助手 OpenCode 的 GitHub 问题记录也提示了审查的重点。用户报告，搜索认证相关字符串触发了安全告警；贡献者建议检查会话，维护者后续则提到已加入代码签名。签名帮助验证软件来源和完整性，却不能说明那次搜索为何发生、是否符合授权，也不限制文件访问范围。该讨论未证实数据外传，但提醒我们，消除告警、约束权限和解释访问行为，需要分别落实。

修复也应覆盖已经排队的数据。如果用户关闭功能，尚未上传的快照是否停止重试？已有云端副本如何处置？发生失败时，临时文件和日志是否遵循同样的清理规则？这些具体行为，决定一个开关能否履行它给用户的承诺。

对处理商业项目的团队，眼下更有用的做法是保留相关日志，核对受影响版本和项目范围，再决定是否继续使用。测试新工具时，可以先使用不含敏感历史的项目副本，并限制它能够读取的目录。员工拥有项目访问权，也不代表他有权决定将企业资料交给新的服务商。

如果排查发现凭据可能外传，应优先撤销或轮换。GitHub 官方清理敏感数据指南也把这一步放在前面：删除当前文件、甚至改写仓库历史，都无法让已经获得副本的人忘掉其中的密码。

ZCode 风波最终要求产品作出回答，这是一件很具体的事：用户按下“开始任务”时，哪些数据会因此离开电脑？

可靠的 AI 助手应当把答案放在用户能够理解、能够选择的位置，并让实际行为经得起检查。便利可以减少重复确认，但涉及新的数据用途和更大的范围时，那一次确认有它不可替代的价值。

2026年9月19日