一句话核心：9 月 18 日，智谱就旗下编程产品 ZCode 的代码库数据上传争议向受影响用户致歉，并给出官方说明：问题源于「代码库索引」功能，其中 Repo Wiki 在生成 Wiki 页面时可能触发仓库数据上传；页面在云端生成后，上传数据会立即销毁、不会保存；官方称已第一时间自查并修复，同时将开源代码库、接受第三方审查。但请注意区分口径——「默认开启」「313MB 快照」「关掉开关仍上传」这些细节属用户侧分析，与官方承认的范围不是一回事。
背景脉络：一次由社区推动的回应
这条的传播路径很典型：先由开发者在社区发现并讨论（知乎上相关问题迅速聚集了大量回答，其中包含对上传链路的逆向分析），随后官方在 ZCode 官方群组内回应并致歉，中文科技媒体在同日跟进报道——官方口径与用户侧分析在同一天并行出现，这也是本条最需要分清层次的地方。
官方口径（可直接引用）
- 问题来源：ZCode 的「代码库索引」功能。官方说明该功能的用途是在本地生成仓库索引，以支持会话检查点恢复（含历史版本）、历史版本回退与 Repo Wiki 等能力。
- 触发上传的环节：Repo Wiki 在生成 Wiki 页面时，可能触发仓库数据上传。
- 数据处置声明：Wiki 页面在云端生成后，相关上传数据会立即销毁、不会保存。
- 处置与整改：官方称已第一时间完成自查、相关问题目前已经修复；并将开源代码库以接受第三方审查。
- 另据新浪财经报道：官方回应中提到，问题根源在于该功能上线初期为默认开启状态，在用户未充分感知的情况下触发了上传行为，波及部分使用者，目前该漏洞已完成修复。
用户侧分析（与官方口径范围不同，须分别标注）
社区里有开发者给出了更细的技术描述，这些内容未获官方确认，也未看到官方否认：
- 上传链路：客户端申请快照上传 → 服务端下发对象存储上传凭证 → 服务端下发 RSA 公钥 → 客户端上传加密快照 → 服务端持有对应的解密能力。
- 涉及范围：讨论中提及
.git/objects/、.git/lfs/、.git/logs/等路径，以及「全量 Git 操作」的说法；亦有对**快照体积（如 313MB）**的具体测量。 - 持续性问题：有开发者提出，即便删除相关数据，历史会话中的打包内容仍可能被一并带出。
两套口径的对照
| 维度 | 官方口径 | 用户侧分析 |
|---|---|---|
| 触发原因 | 「代码库索引」功能中的 Repo Wiki 环节可能触发上传 | 认为涉及全量 Git 操作与仓库快照 |
| 默认状态 | 该功能上线初期为默认开启（据媒体引述官方回应） | 认为用户难以感知开关与上传的关联 |
| 数据处置 | 云端页面生成后立即销毁、不保存 | 对「立即销毁」提出疑问；指出服务端持有解密能力 |
| 整改 | 已修复；将开源代码库、接受第三方审查 | 等待开源与审查结果，作为可验证依据 |
价格与成本
本条不涉及定价。可量化的成本是信任与治理成本：对使用编码助手的团队而言，私有仓库的代码是核心资产，一旦出现未经预期的外发，代价不在账单上，而在合规审计与客户信任上。官方给出的「开源 + 第三方审查」正是针对这一点，但在代码开放之前，它仍是一个承诺而非可核查的事实。
辩证评估
- 值得肯定的部分：回应速度快（社区讨论当天即致歉并给说明）、给出了明确的整改路径（修复 + 开源 + 第三方审查），并且把「可核查」这个动作放进了整改里——比单纯声明「不会保存数据」更可验证。
- 反向视角：
- 其一，「立即销毁、不会保存」目前无法被外部独立验证，只能依赖官方陈述；真正的验证载体是它承诺开源的代码。
- 其二，默认开启才是问题的关键。即便上传本身出于功能设计，把可能外发仓库数据的功能默认打开，属于产品默认值的决策问题，而不只是一次代码缺陷——修复「漏洞」未必等于修复了默认值设计。
- 其三，「将开源代码库」的范围未说明（客户端还是服务端、索引功能还是全链路），这决定了第三方审查能覆盖多少。
- 其四，传播中容易出现两极化：一边把它说成「官方承认全量上传代码」，另一边说成「技术讨论被夸大」——两者都不准确，官方承认的是功能链路触发上传，用户侧分析的是范围与机制，二者的交集比任一方论断都小。
- 与本周其他事件的区分：这条是产品数据处置问题，与 155 篇的插件供应链漏洞（代码被替换）、156 篇的模型越界（自主入侵）机制完全不同，不应合并叙述。
已知 vs 待验证
已证实（官方回应经多家媒体报道）：9 月 18 日官方致歉；问题源于「代码库索引」功能；Repo Wiki 生成页面时可能触发仓库数据上传；页面云端生成后数据立即销毁、不会保存；已修复；将开源代码库并接受第三方审查；据媒体引述官方回应，该功能上线初期为默认开启。
待验证：上传数据的真实范围与体积（用户侧测量，未获官方确认）；「立即销毁」的技术实现与可验证性；开源的具体范围与时间；第三方审查的主体与结论；是否存在仍在使用旧版本客户端的用户。
给读者的建议
- 正在使用编码助手（任何厂商）的团队：今天就能做的一件事是审计本地代理/索引功能的出网行为——检查默认开关、检查是否有仓库快照上传路径、对私有仓库做出口流量审计；不要只看产品说明，以实际流量为准。
- 对私有仓库有强合规要求的团队：把「代码索引/知识库生成类功能」列入供应商尽调清单，要求厂商给出数据流向与留存证明。
- 产品与研发负责人：这条最该带走的是默认值的教训——任何可能外发源码或会话内容的能力，默认应关闭，开启需用户显式知情。
- 关注这条后续的读者：等它承诺的开源代码与第三方审查结果——那才是可核对的部分。
来源
官方口径（经媒体转述）
- 凤凰网科技《智谱 ZCode 就代码库数据上传致歉：已修复，将开源代码库接受第三方审查》（2026-09-18）：https://tech.ifeng.com/c/8WkqtwNNZd
- 新浪财经《智谱 ZCode 回应数据上传争议：功能默认开启致数据上传，将开源代码》（2026-09-19）：智谱ZCode回应数据上传争议：功能默认开启致数据上传，将开源代码_新浪财经_新浪网
- 腾讯新闻（转载同日报道，2026-09-18）：https://news.qq.com/rain/a/20260918A0ASOH00
用户侧分析（未经官方确认）
- 知乎相关讨论（含对上传链路与范围的逆向分析，2026-09-18 起）：https://www.zhihu.com/question/2084291380302574171