ZCode上传代码争议后承诺开源

智谱旗下 AI 编程产品 ZCode 因默认开启相关功能、可能将代码仓库数据上传至云端而陷入信任危机。

9 月 18 日，智谱在官方群组向受影响用户致歉并表示，问题源于“代码库索引”链路中的 Repo Wiki 功能，目前已经修复；接下来将开源 ZCode 相关代码库，引入第三方评估人员审查系统运行情况，并持续公开审查进展。

这次争议的重点并不是 ZCode 有没有代码理解能力，而是一个需要处理仓库数据的云端功能，为何在上线初期默认开启，以及用户是否在数据离开本地之前获得了足够明确的提示和选择权。

ZCode承认：Repo Wiki可能触发仓库数据上传

代码库索引是将仓库中的文件、符号、依赖和版本关系整理成可检索结构的技术，用于帮助 AI 快速理解大型项目。 对编程智能体来说，索引类似于给仓库制作一张地图：模型不必每次从头阅读数万个文件，而是先定位相关模块，再调取需要的上下文。

智谱在回应中表示，ZCode 的代码库索引原本用于支持会话检查点恢复、历史版本回退和 Repo Wiki 等能力，索引本身的设计目标是在本地生成。问题出现在 Repo Wiki 生成环节：当用户生成 Wiki 页面时，功能可能触发仓库数据上传，并在云端完成知识库页面生成。

Repo Wiki 是自动分析代码仓库并生成架构说明、模块关系和项目文档的知识库功能。 这类功能要输出跨文件、跨目录甚至跨版本的结构化说明，通常需要读取比普通代码补全更多的上下文，因此其数据权限天然高于单文件补全或局部问答。

智谱称，上传的数据会在 Wiki 页面生成后立即销毁，不会继续保存，但该功能在上线初期默认开启，因此部分用户在未主动配置的情况下可能受到影响。官方没有在本次回应中公布受影响用户数量、上传数据总量、问题持续时间和具体版本范围。

目前可以确认的信息如下：

| 关键维度 | 智谱公开口径 | 仍待说明的问题 | | --- | --- | --- | | 涉及功能 | 代码库索引链路中的 Repo Wiki | 是否还有其他功能复用同一上传链路 | | 数据用途 | 在云端生成 Wiki 页面 | 实际上传了完整文件、代码片段、索引还是 Git 对象 | | 默认状态 | 上线初期默认开启 | 哪些版本默认开启、何时调整配置 | | 数据留存 | 生成完成后立即销毁，不会保存 | 销毁机制、日志留存和备份策略如何验证 | | 当前进展 | 官方称问题已经修复 | 修复版本号、发布时间和变更记录尚未完整披露 | | 后续措施 | 承诺开源并接受第三方审查 | 开源范围、审查机构和审计报告形式尚未确定 | | 用户补偿 | 额外提供一次周额度重置 | 补偿自 9 月 18 日起发放 |

真正的问题不是“保存多久”，而是“是否先获得同意”

默认开启是指用户没有主动操作时，产品自动采用某项预设配置。 对主题颜色、快捷键和界面布局而言，默认开启通常只是体验问题；对源代码、Git 历史和项目文档上传而言，默认开启则直接涉及数据控制权。

智谱强调相关数据不会保存，这可以降低长期留存风险，但无法完全回答开发者最关心的问题。只要仓库内容离开本地设备并进入服务端处理链路，就会产生传输、临时缓存、任务日志、故障快照、访问控制和内部权限等一系列安全问题。

“处理后销毁”和“从未上传”也不是同一个安全等级。前者要求用户信任服务商的服务端实现、运维制度和销毁机制，后者则可以通过抓包、进程监控或源代码审计直接验证，二者的信任成本存在本质差异。

Git 历史还可能比当前工作区包含更多敏感信息。开发者即使已经从最新版本中删除密码、令牌、内部域名或客户数据，这些内容仍可能存在于历史提交中；如果相关功能读取历史版本，风险边界就不能只按当前文件计算。

不过，现有公开信息尚不足以证明 ZCode 上传了每个仓库的完整 Git 历史。官方仅确认 Repo Wiki 可能触发仓库数据上传，却没有给出实际字段、文件过滤规则、忽略列表和网络请求格式，因此将事件直接描述为“完整仓库全部外传”同样缺乏充分证据。

更准确的判断是：ZCode 已经承认默认开启的功能可能让仓库数据进入云端，但实际上传范围和受影响规模仍未透明披露。

本地索引与云端生成，不应该藏在同一个开关后面

本地索引和云端知识库生成是两种安全边界完全不同的处理方式。 本地索引只在用户设备上读取和整理代码，而云端生成意味着至少部分仓库内容需要通过网络发送至服务端。

如果产品界面只使用“代码库索引”这一概念，用户很容易把它理解为纯本地能力。Repo Wiki 即使依赖索引，也不代表其云端处理行为可以被自动包含在用户对本地索引的授权中。

成熟的产品设计应当把“建立本地索引”和“上传内容生成云端 Wiki”拆成两个独立权限。用户可以允许 ZCode 在本地理解代码，同时拒绝任何仓库内容离开设备；只有在主动使用 Repo Wiki 时，产品才应展示上传范围、处理位置和数据保留规则。

不同实现方式的风险差异可以概括为：

| 实现方式 | 数据是否离开本地 | 合理的默认策略 | 主要风险 | | --- | --- | --- | --- | | 纯本地代码索引 | 否 | 可默认开启，但应允许关闭 | 本地缓存泄露、索引文件权限配置不当 | | 按需上传选定文件 | 是 | 默认关闭，操作前确认 | 用户可能误选敏感文件 | | 云端生成仓库知识库 | 是 | 默认关闭，并明确说明处理范围 | 大范围源码、配置和历史信息进入服务端 | | 默认上传仓库数据 | 是 | 不应作为无提示默认项 | 用户无法提前判断数据边界，企业合规风险最高 |

这也是本次事件比一般产品 Bug 更严重的原因。一个按钮失效可以通过版本更新修好，但一次未经充分告知的数据传输，会让用户重新审视整个产品的权限模型。

承诺开源是正确方向，但“开源”不等于问题自动解决

开源审计是指公开客户端或相关组件的源代码，让外部开发者能够检查数据采集、网络请求和权限控制逻辑。 对 ZCode 来说，开源至少可以帮助社区确认哪些操作会读取仓库、哪些条件会触发上传，以及客户端是否存在未披露的网络行为。

智谱承诺近期开放 ZCode 相关代码库，这是目前回应中最有价值的一项措施。相比只发布一份文字声明，代码可以被复现、比对和持续跟踪，也更符合开发者工具建立信任的方式。

但开源范围将决定这项承诺究竟有多少含金量。如果公开的只是界面层、插件协议或无关组件，而数据上传逻辑、遥测模块和服务端接口仍然不可见，社区能够验证的内容依然有限。

真正有效的开源至少需要回答以下问题：

1. 客户端哪些模块负责扫描文件、读取 Git 历史和生成索引；
2. 哪些用户操作或后台任务会触发网络请求；
3. 请求中包含文件原文、摘要、向量、路径还是提交记录；
4. .gitignore、用户排除规则和敏感文件过滤是否生效；
5. 官方发行版能否与公开源代码进行可复现构建比对；
6. 遥测、错误日志和崩溃报告是否可能携带代码片段；
7. 功能关闭后，后台任务和历史索引是否同步停止或删除。

如果官方安装包无法与开源仓库对应，用户仍然只能相信“发布出来的代码”和“实际运行的程序”完全一致。因此，版本标签、构建脚本、哈希值和可复现构建机制，比单纯把代码放进公开仓库更重要。

第三方审查需要公开标准，而不是只公布结论

第三方审查是由产品团队之外的独立机构或安全研究人员，对系统的数据流、权限模型和运行结果进行验证。 这项措施能够补足普通开发者无法检查云端服务的缺口，尤其适合验证“处理后立即销毁”一类发生在服务端的声明。

智谱目前只表示将邀请第三方评估人员，没有公布机构名称、审查范围、时间表和报告形式。第三方是否具备独立性、能否接触生产环境、是否会公开完整报告，将直接决定审查结果的可信度。

一份有实际价值的审计报告至少应包含四类结论：

• 数据流结论： 仓库数据从客户端到服务端经过哪些组件；
• 最小化结论： 上传内容是否超过生成 Wiki 所必需的范围；
• 留存结论： 临时文件、缓存、任务日志和备份分别保留多久；
• 权限结论： 哪些内部角色能够访问数据，访问行为是否可追踪。

智谱还应公布修复版本号、默认配置变化和旧版本处置方式。如果旧客户端仍可继续运行并触发原有逻辑，那么“问题已经修复”只对升级用户成立，尚不能视为全量风险关闭。

用户协议不能代替产品内的即时告知

ZCode 当前用户协议版本更新于 2026 年 6 月 15 日，其中列出了权限确认、风险等级识别、工具调用限制和项目级允许或拒绝规则等安全护栏。这些条款主要用于降低智能体误操作和越权执行风险，但协议层面的笼统授权不能代替具体功能触发时的清晰提示。

开发者不会在每次版本更新后重新逐条阅读整份协议，因此高风险数据操作必须在产品界面中即时说明。一个合理的确认窗口至少应告诉用户：哪些数据将被读取、是否发送到云端、用于什么目的、保存多久，以及如何撤回授权。

对于企业仓库，问题还不只是用户个人是否愿意。员工可能有权使用代码，却没有权把代码发送给新的外部处理方；一旦仓库包含客户交付物、未公开产品、商业秘密或受许可证限制的第三方代码，默认上传就可能越过组织内部的合规边界。

一次周额度重置，补不了信任缺口

智谱宣布为全体用户额外提供一次周额度重置，并从 9 月 18 日起发放。这项补偿可以弥补部分使用成本，却与此次事件的核心风险并不对等。

开发者真正需要的不是更多调用额度，而是一份可以验证的数据清单。官方应允许用户查看哪些仓库曾触发 Repo Wiki、上传任务发生在什么时间、涉及哪些文件，以及服务端是否已经完成清理。

如果智谱能够提供本地审计日志、历史上传记录和一键删除入口，这次事件反而可能推动 ZCode 建立一套更透明的代码数据治理机制。反过来，如果后续只有开源预告和审查结论，没有范围、版本和证据，争议很可能在下一次网络请求异常时再次出现。

这次事件给AI编程工具划出了一条红线

AI 编程工具正在从“读取当前文件”升级为“理解整个工程”，数据权限也随之从编辑器上下文扩大到仓库、终端、浏览器、Git 历史和远程任务。能力越强，产品越不能用模糊的一次性授权覆盖所有数据行为。

ZCode 的修复、开源承诺和第三方审查方向是正确的，但目前仍处于“承诺建立透明度”，而不是“透明度已经建立”的阶段。是否能够挽回开发者信任，要看智谱接下来公开多少可核验信息，而不是回应写得多快。

对 ZCode 用户而言，现阶段更稳妥的做法是升级至官方最新版本，重新检查 Repo Wiki 和代码库相关配置，并避免在审计结果公布前处理包含生产凭证、客户数据或核心商业秘密的仓库。企业团队则应同步检查网络出口日志和终端策略，确认是否存在未纳入审批的数据处理行为。

这次争议最终留下的行业标准应当很简单：本地功能可以默认便利，云端上传必须默认克制；功能价值可以由厂商解释，数据边界必须由用户决定。

参考来源

• IT之家：智谱 ZCode 被质疑“偷传代码”，官方回应问题已修复——整理了智谱 9 月 18 日回应、Repo Wiki 数据上传机制、开源与第三方审查承诺。