北京
出品 | 网易智能
作者 | 小扣
编辑 | 王凤枝
智谱的AI编程工具ZCode，因后台打包、上传用户项目遭到质疑。开发者发现，被打包的不只是当前代码，还有保存历次修改的Git历史。
9月18日，开发者ferstar公开了自己的排查结果：ZCode在本机生成了项目副本，并反复尝试上传。随后，其他用户也提供了复查记录，有人发现项目副本已被服务器接受，也有人质疑仓库索引开关能否阻止上传。用户因此追问：软件为什么要收集这些内容，又该怎样阻止它上传？
ZCode当天道歉，将问题归因于早期默认开启的“代码库索引”相关功能。公司称，Repo Wiki在云端生成仓库百科时可能触发数据上传，生成后相关数据会立即销毁，并承诺开源客户端、引入第三方审查。
9月19日，ZCode发布3.14.0，更新日志写道：“修复仓库百科异常上传的问题。”ferstar也补充复查结果，称新版已移除相关上传代码。
开源后，外界可以检查软件为何上传、这次又改了哪里。但服务器此前收过哪些文件、是否按承诺删除，还需要公司提供接收和处理记录。第三方审查如果只看客户端，就回答不了用户对这批历史数据的疑问。
一、清理磁盘，发现了一份项目副本
ferstar最初并没有在检查上传行为。他是在清理电脑磁盘时，发现ZCode的数据目录占了不少空间，往下查才找到一份313MB的加密文件。它是软件为项目生成的快照，相当于把一批项目文件打包成一个副本。
随快照保存的清单，列出了42411个文件。按文件体积计算，其中约86.6%来自保存版本记录的.git目录，包括Git历史对象、操作日志和LFS大文件缓存。
这些文件准备发往哪里？ferstar继续检查客户端代码，找到了一条上传流程：软件先向ZCode服务器申请上传凭证，再打包、加密，把文件发到阿里云的OSS云存储服务，最后由云端通知ZCode服务器登记接收结果。
不过，那份313MB文件尝试上传564次，次次失败，一直留在本机等待重试。ferstar在9月19日的更新中特意澄清了这一点，同时补充：他的另一个较小的公开仓库快照，状态已经显示服务端接受。
开发者Vonng随后在macOS版ZCode 3.12.3上复查。他找到一份不含.git的普通工作区快照，记录显示已被服务端接受；另外两份快照里，.git占文件总体积的93.9%和98.5%，客户端已取得上传凭证，但公开记录无法确认它们是否完成上传。
ZCode在GitHub上的反馈区也收到了相关报告。Issue #707的提交者称，自己找到一份被服务端接受的快照清单，其中有两千多条.git路径。他还反映，快照会附带用户为AI工具设置的连接信息、自动执行脚本和指令文件等全局配置。他的判断依据是本机记录，还没有服务器端的审计结果可以核对。
二、删过的代码，也可能跟着走
这些清单里反复出现的Git历史，正是用户担心的地方。
Git让开发者能够找回代码的旧版本，也意味着今天删掉的内容，未必已经从仓库中消失。曾经误提交的密钥、配置文件或内部地址，都可能保留在历史对象里。GitHub的安全文档也提醒，只删除最新版代码中的敏感信息，并不会清除Git历史里的副本。
Git里还可能留着尚未推送的本地提交，提交记录里有作者邮箱，大文件缓存则可能留下项目以前使用过的素材。ZCode需要解释，帮用户完成眼前的任务，为什么需要上传这些内容。
上述样本尚不能证明真实密钥已经泄露。对于在ZCode里打开过内部仓库的人，知道哪些版本、哪段时间受影响，才好回头检查可能被打包的历史内容。
ZCode的隐私政策写道，为提供内容生成和AI辅助操作，会收集用户在对话中“提交、指定”的文件和代码。但软件在后台把Git历史也打包时，用户是否知情、是否同意，现有产品说明没有说清楚。即使文件经过加密，用户也有理由要求：上传前先说清楚会传什么，再让自己决定是否同意。
至于文件是否被拿去训练模型，同一份政策称，“优化计划”默认关闭，用户主动加入前，不会把输入、生成内容或产品使用数据用于产品及模型训练与优化。现有公开材料也没有显示这些仓库数据进入了训练流程。
但对企业来说，仅承诺不把代码用于训练，还不足以回应这次质疑。文件上传后的存放、访问和销毁，也需要可供用户核对的处理记录。
三、关闭索引，能不能关掉上传
用户如果不希望这些后台快照离开电脑，光知道“优化计划”默认关闭还不够，还需要一个能控制上传的选项。
按ZCode的介绍，上传行为与“代码库索引”有关。这项功能用于本地生成仓库索引，并支持会话检查点恢复、历史版本回退和Repo Wiki。前两项帮助用户恢复项目状态，仓库百科则负责分析项目结构、生成说明文档。
从开发者还原的流程看，ZCode原本就有仓库上传功能。9月18日的说明将问题归因于早期默认开启的相关功能，但没有展开说明：这次修复究竟调整了上传条件、文件收集范围，还是设置开关的控制逻辑。几项功能分别需要哪些数据，也没有说清楚：哪些文件只用于本地恢复，哪些要传到云端，Git历史、大文件缓存和用户反映的全局配置又为何被纳入？
ferstar称，在他检查的3.12.3版中，关闭“优化体验”和“仓库快照索引”后，后台仍会打包并尝试上传。
Issue #707的提交者则称，关闭仓库快照索引后，自己在本机找到了服务端接受快照的记录。上传发生在关闭开关之前还是之后，还需核对。这个选项到底控制本地建索引，还是也控制云端上传，需要ZCode解释。
社区开发者也给客户端加上了限制。项目zcode-webui在官方运行时外加了四层防护，分别拦截快照凭证申请、上传、读取和保存到本地。这些拦截是为了阻止继续上传，过去传过什么、服务器又做了什么，仍要另查。
ferstar在复查3.14.0版时表示，负责上传的代码和后台组件已被移除，本地检查点仍然保留；申请上传凭证的接口也返回了404。
他检查的是上述版本和接口。其他平台是否也已修复，旧客户端还能不能继续上传，服务器上的修复何时生效，仍需要官方说明。
四、修复之后，还要查清什么
修复版推出后，用户最想确认的是，自己的项目有没有被传走。ZCode的隐私政策已提供查询、删除个人信息的邮箱，希望公司明确，这个渠道能否受理此次异常上传的查询，让用户查到具体受影响的项目。哪些版本、哪段时间受到影响，也应一并说明。
公司已经表示，Wiki生成后会立即销毁上传数据。但如果生成失败、被取消或超时，文件又会怎样处理？已经上传的文件有没有被解密、被谁访问过，删除是否覆盖云端快照和备份，这些还需要进一步交代。希望公司能向受影响的用户提供具体的处理记录，让用户核对自己的文件是否已按承诺删除。
截至9月20日，距离ZCode承诺开源已过去约两天，Z.ai的公开仓库中尚未找到客户端源码。
后续开源时，外界需要看到出事版本或相应的修改记录。只看修复后的代码，查不清此前为什么触发上传、会收集哪些文件。
ZCode还承诺引入第三方审查，审查方、范围和时间安排需要进一步说明。希望这次审查能同时核对客户端代码和服务器记录。相关处理、访问和删除记录可以交给审查方检查，不必公开用户代码；核查的结果，则应告知受影响的用户。
