从ZCode上传争议，看AI编程工具的数据边界

9月21日更新： 已核对到zai-org/ZCode官方公开仓库，仓库说明包含客户端、后端服务、共享界面及Agent运行时源码。因此，下文所述9月18日“承诺开源”是当时的回应；公开仓库本身仍不能证明历史数据处置或已安装版本行为。本文没有进行客户端复现或服务端审计。

9月18日，智谱旗下AI编程工具ZCode卷入工作区数据上传争议。开发者在公开反馈仓库提交了本机调查，媒体随后转载了厂商的致歉和整改说明。争议牵涉一个每个使用AI写代码的人都可能遇到的问题：软件需要理解项目时，究竟会读取和传输多大范围的数据？原始反馈、厂商说明的媒体转载

区分报告、声明与核验结果

先把证据分开。开发者Ferstar在调查文章中，描述了工作区快照打包和上传链路，并指出其样本含有Git历史。官方反馈仓库的Issue #707也报告了本机观察，给出所用版本和相关状态记录。它们是可追踪的技术报告，但本文没有独立复现，不能据此推定所有用户、所有版本都发生了相同情况，更不能证明数据后来被用于训练或其他用途。Ferstar调查

厂商一方如何解释？据媒体转载的用户群说明，问题与代码库索引及Repo Wiki有关；厂商称相关功能初期默认开启，已经修复，并表示上传数据在生成Wiki后销毁，同时承诺近期开源、引入第三方审查。这里必须保留“厂商称”和“承诺”：本文未直接进入原用户群，也未验证服务端删除结果，不能把这份说明写成独立审计结论。

公开报告描述的是具体版本和本机样本。实际上传范围、触发条件、设置开关行为、受影响版本和历史数据处理，需要逐项对应。“代码存在某种机制”和“每台机器都已上传”之间不能直接画等号。

读取当前代码与读取历史的差别

为什么开发者特别在意Git历史？可以用一个不涉及真实客户的例子说明：某项目当前文件已经删除一段配置，但旧提交里仍可能留下它。读取当前选中的代码，和收集完整版本历史，会接触到不同范围的信息。今天看不到的内容，不代表从未保存在仓库里。用户愿意让AI分析一个报错，也不必然意味着理解并同意传输所有历史数据。

这让产品说明里的几个词显得格外重要。“索引”告诉人们软件会建立检索能力，却未必告诉人们工作发生在本机还是云端；“快照”描述某个时刻的状态，也没有自动解释是否含历史目录；“加密”能够描述数据的保护方式，却不能代替对接收方和授权范围的说明。只有把读取、打包、传输、处理、留存分别说清楚，用户才能判断自己允许了什么。

开源为外部检查提供了入口，但还需要把代码与实际发布物、服务端处理对应起来。源代码可以帮助外部理解客户端行为；某个安装版本是否包含相同实现，关闭功能后是否仍有排队任务，以及已经传出的数据怎样处理，则各有不同的核验对象。把这些问题压缩成一句“开源就安全”，反而会错过此次事件真正需要补上的信息。

对企业使用者而言，更有价值的下一步，是获得明确的版本说明与受影响范围，再决定怎样处置相关项目。这里不建议凭热搜就批量删除本地目录或执行网上的锁文件命令：那可能破坏检查点等功能，也不能证明云端数据已清除。核实当前使用方式、保存必要记录、通过正式渠道询问数据处理结果，比把未经验证的操作转发给整个团队更稳妥。

把边界写进产品行为

对AI产品团队，这场争议也给出了具体的设计问题：用户关闭某项功能时，界面反馈和后台行为能否一致？需要上传工作区时，能否在行动发生前展示范围？功能升级后，旧授权是否仍准确覆盖新行为？这些是本文提出的产品判断，并非对ZCode尚未核实实现的结论。

接下来，值得继续追踪的是三类答案：准确的受影响版本与触发条件、可复核的关闭和修复行为、历史数据处理与第三方审查进展。开发者需要的信任，最终来自这些问题被逐一回答，而不是更响亮的功能名，也不是一次额度补偿。