你把一份代码交给 AI 帮忙，通常会默认它只处理眼前需要的内容。可如果软件在后台把整个工作区打包，连修改历史也可能带走，问题就不只是“功能有没有说明”，而是用户还能不能掌握自己的数据。
9 月 20 日，本刊报道了 ZCode 遭遇的这场质疑：开发者 ferstar 清理磁盘时发现，~/.zcode 目录已超过 700MB。他继续逆向分析，找到一个约 313MB 的加密工作区包和 564 次失败上传记录。据其取证报告，包内不只有当前代码，还包括 .git 对象、reflog 和 Git LFS 缓存——也就是项目的修改历史及相关大文件缓存。当时，尚无厂商或独立安全机构公开复核。
现在，ZCode 给出了后续回应：道歉、公开源码，并宣称完成安全整改。不过，现有信息全部来自一则 Reddit 帖文转载的官方声明；原帖末尾还有截断，因此不能把它称作一份可独立验证的“完整回应”。
从本地到云端，代码公开了什么？
ZCode 宣布在 github.com/zai-org/ZCode 开源。官方称，仓库包含 desktop app、web workspace、backend、Agent CLI 和 runtime。简单说，desktop app 是用户在电脑上操作的应用；backend 是远程处理数据和计算的系统；Agent CLI 是在终端里让 AI 执行任务的工具；runtime 则承担程序实际运行所需的支持。
这份组件清单覆盖了从本机界面到服务端执行的主要链路。公开源码的意义也正在这里：外部开发者可以检查软件怎样收集、处理和传输数据，不必只依赖界面上的开关或厂商说明。
但“仓库已经公开”不等于“安全已经得到证明”。现有材料没有逐项核验代码是否完整，也没有说明提交历史是否开放、许可证是否符合通常意义上的开源。它首先提高了可核查性，真正的审计才刚有了入口。
官方说改掉了什么？
据 ZCode 官方声明，v3.14.0 客户端已经完成安全整改。Repo Wiki 功能或入口及其关联生成流程被移除，本地仓库快照的生成和上传流程也已禁用。
“仓库快照”可以理解为给整个工作区拍下一份可传输的副本。此前争议的关键，正是这份副本可能包含哪些内容、何时生成，以及用户关闭相关设置后流程是否仍会运行。另一名 Windows 用户曾沿公开线索复核，称开关为 false 时仍生成了约 256MB 的加密包；其本地状态文件还显示，部分工作区曾收到服务端“已接收”回执。
针对整改后的版本，官方转述 NSFOCUS 的评估结论称，没有发现能够触发本地仓库快照生成、或把本地文件传到外部的功能路径。这比一句笼统的“问题已经解决”更具体，因为它直接回应了此前受到质疑的触发与传输链路。不过，材料没有附上 NSFOCUS 的原始报告或独立公告，目前仍只能把它视为 ZCode 对评估结果的转述。
已经上传的数据去了哪里？
这是回应中更难核实的一部分。ZCode 称，争议涉及的代码数据没有被保留，也从未用于模型训练。官方还称，已邀请中国信息通信研究院（CAICT）和绿盟科技（NSFOCUS）进行安全评估。
据官方转述，CAICT 确认 zcode-prod Alibaba Cloud OSS bucket 处于“zero-data state”，即检查时没有数据；NSFOCUS 则确认其中全部数据对象以及 bucket 本身均已删除。OSS bucket 可以理解为云端存放文件的容器。两种说法可能来自不同检查时间，也可能使用了不同技术口径，并不必然冲突。
但它们能支持的结论有限。当前存储空间为空或已经删除，可以说明检查时的状态，却不能单独证明数据过去从未被保留，更不能推出它从未被用于模型训练。要验证后一个说法，还需要现有材料没有提供的独立审计证据。
为什么这次回应仍值得关注？
这次变化把争议从“只能靠逆向分析猜测软件做了什么”，推进到“社区可以直接检查公开代码”。ZCode 也表示，将建立持续的安全漏洞报告和响应机制，并按照漏洞严重程度提供奖励。若机制真正运行，它会让问题发现从偶然取证变成常态审查。
更重要的是，这件事划出了一条清楚的数据边界：编码 Agent 既能读取本地项目，也可能连接远程服务。用户需要知道它读了什么、为何读取、是否上传，以及上传后如何查询和删除。开源能帮助回答前几个问题；对于已经传走的数据，仍需要可由用户或第三方验证的记录。
局限与未知
- 所有整改与数据处置结论目前都来自同一份官方声明的转载，材料未附 CAICT、NSFOCUS 的原始评估报告或独立公告。
- 仓库虽列出主要组件，但现有材料不足以确认代码完整性、提交历史和许可证情况。
- “数据未保留、从未用于模型训练”尚无独立审计支撑；公开源码和当前 bucket 状态也无法单独证明全部历史风险已经消除。