你以为 AI 编程工具只读它完成当前任务需要的那几段代码。但在你电脑某个 700MB 的隐藏目录里躺着一个你自己都解不开的加密包——里面 86.6% 是你仓库从第一天起的全部历史。9 月 18 日开发者 ferstar 的一次普通磁盘清理把智谱旗下的 AI 编程工具 ZCode 推上了风口浪尖。这件事在技术圈传了几天有公司直接内部停用有企业发了律师函智谱三次回应、开源代码、请第三方审计。我们就把整件事拆开看到底发生了什么、真正危险的是什么、以及今晚你能做什么。01 一个 313MB 的待上传包裹事情的起点很普通。ferstar 清理磁盘时发现ZCode 在用户目录下的本地文件夹~/.zcode已经占了700 多 MB。其中v2/checkpoints/目录约 303MB里面有一个313MB 的加密文件。随附的状态文件写明了几件事它来自一个商业项目类型是全量快照项目总容量约 10GB排除依赖文件后仍有约345MB 内容被打包“几乎全是核心资产”这份快照此前已经上传失败了 564 次一直滞留在本地客户端还在不停重试。一个 313MB、重试了 564 次的包任何一个对系统有点敏感的人看到这里都会问一句这是什么要发到哪去ferstar 把客户端的app.asar拆开、核对网络连接还原出了一条完整链路步骤发生了什么① 申请凭证客户端向zcode.z.ai请求拿到阿里云 OSS 的表单签名、存储路径、大小限制以及本轮 RSA 公钥② 本地打包在本地把工作区打成 tar.gz③ 本地加密AES-256-CTR 对称加密内容再用 RSA-OAEP-SHA256 封装对称密钥标准信封加密④ 直传 OSS绕过智谱自己的业务服务器把密文直接传到阿里云 OSS⑤ 回调登记上传成功后由 OSS 回调智谱后端登记注意这个直传设计——数据不经过厂商业务服务器中转而是用户客户端拿着临时凭证直接丢进对象存储。从工程角度这很常见、也更省带宽但从用户视角这意味着这件事可以做得非常安静。而它真正引爆舆论的是下一节——打包的范围。02 被带走的不是代码是从第一天起的全部历史密文打不开但客户端生成快照时留下了一份明文文件清单。ferstar 对清单里的42,411 个文件做了统计结果是这样的内容占快照比例.git/lfs/大文件缓存56.8%.git/objects/完整 Git 对象库29.6%.git/logs/reflog 等0.2%.git目录合计86.6%当前源码与业务文档约 13.4%也就是说这个包里 86.6% 是版本控制历史真正的当前代码只占一成多。很多人对.git目录没有概念觉得不就是些版本记录吗。恰恰相反一个仓库最不该被外人拿走的往往就是它的历史。因为里面可能有你已经删掉的密钥、口令、数据库连接串——文件在工作区里删了但在历史提交里永远留着.git/config里记录的内网 GitLab 域名、仓库路径、甚至带凭证的 remote 地址还没推送的本地分支名、被 reset 抹掉的提交记录——它们会暴露你正在做什么、做到了哪一步LFS 缓存里的大文件历史版本设计稿、数据导出、内部文档。做测试和做安全的人都懂一句话代码泄露暴露的是现状Git 历史泄露暴露的是演进。你三年间改过哪些接口、密钥轮换过几次、哪个模块反复返工、内部系统怎么命名——全在里面。这是整件事第一个、也是最实质的争议点用户对AI 工具读代码上下文是有预期的但对它把整个仓库连同全部历史静默打包完全没有预期。03 两个开关都关不掉上传如果说全量历史是范围问题那接下来这个是控制权问题。ZCode 的设置里有两个看起来很让人安心的开关「优化体验」「仓库快照索引」名字听着都该能关掉上传。但 ferstar 对照客户端代码后发现——没有一个开关在管上不上传这件事开关它实际控制的优化体验数据能不能被授权用于模型训练仓库快照索引服务端要不要给已经传上去的快照建立索引即使两个都关掉本地快照照样生成、照样进入上传流程。快照组件在客户端启动时被无条件加载唯一前提是你处于登录状态触发点在每次发送提示词前、任务结束后一个活跃会话的日志里最多出现过62 次捕获记录。手动删掉待传包也没用——半小时内它重新生成上传计数从 564 变成 565。这是我觉得整件事里最值得每个产品人和管理者警惕的一点不是没给你选择而是给你的选择和你真正需要选择的东西不是同一件事。一个开关如果说不清自己掐断的是哪一段执行路径那它关掉的就只是你的警惕心。我自己做变更管控时有条土规矩任何标着可关闭的能力都得能讲清楚它断的是哪根线讲不出来的就当它关不掉。最后真正能挡住它的是一个系统级操作把检查点目录设为不可写macOS 的chflags uchg、Linux 的chattr i让捕获逻辑在写盘这一步直接被内核拦住——没有本地产物上传链路自然就断了。隐私政策是声明界面开关是声明提示词也是声明只有落在执行点的边界才算边界。04 密钥在谁手里决定它是备份还是采集还有一个细节技术博主们反复提到我认为是定性的关键。ZCode 用的是标准信封加密本地内容用临时对称密钥 AES-256-CTR 加密对称密钥再用 RSA-OAEP-SHA256 封装。加密本身没问题甚至可以说做得很规范。问题在于——RSA 公钥是服务端动态下发的私钥从不下发只存在云端。结果就是你本地这几百 MB 的密文你自己解不开ZCode 客户端也解不开只有云端能解。ferstar 用本机所有私钥都没能打开。这就引出一个很朴素的判断标准一个功能的加密密钥归谁直接决定它的性质是备份还是采集。如果这个快照真是为了本地检查点回滚“跨设备同步”那它应该像 macOS 的 Time Machine 一样——密钥握在用户手里数据是你的工具只是帮你存。现在的架构却是数据在你电脑上生成但只有厂商的云端能读。加密保护了传输过程不被第三方偷看但它没有回答数据最终能被谁看。这两件事很多时候被混为一谈了。05 这不是孤例Grok、Claude、三星都翻过车如果你觉得这是某一家的问题那可能要失望了。约两个月前2026 年 7 月xAI 的编程工具 Grok Build 被发现将用户的整个 Git 仓库打包上传到谷歌云存储在开发者社区引发过几乎一模一样的抗议更早Claude也卷入过代码数据上传的争议2023 年 3 月三星半导体开放 ChatGPT 仅 20 天就发生三起泄密——员工把测量源码、良率代码、内部会议录音贴进对话框机密直传境外无法收回三星随后禁用并自研工具。但要注意区分性质三星是员工主动粘贴的误用ZCode 和 Grok 是客户端在后台自动、批量上传。后者更隐蔽因为它不依赖任何人犯错——只要你登录它就自己跑。这说明这不是某个团队使坏而是一类结构性问题当 AI 编程工具都在卷理解整个仓库“跨会话记忆”一键生成 Wiki这些能力时把数据搬到云端去处理是最直接的工程路径。于是读取范围和上传范围的边界就在一次次功能迭代中悄悄外扩。06 法律视角“默认不用于训练” ≠ “默认不上传”事件里有个表述特别值得拿出来讲因为它骗到了很多人。智谱的隐私政策里写着优化计划默认关闭“在您主动选择加入前我们不会将您的输入信息、生成内容或产品使用数据用于产品及模型训练与优化”。很多用户看到这句就放心了。但这里藏着一个关键的偷换“默认不用于训练” 不等于 “默认不上传”。训练授权和收集授权本来就是两个独立的同意。我可以不拿你的数据训练模型但我依然可以把它传到云端、生成一个 Wiki 页面、然后删掉。上传行为本身是一个需要单独告知、单独征得同意的动作。对照现行《个人信息保护法》条款要求这件事的疑点第十七条处理前以显著方式、清晰语言完整告知目的、方式、种类、保存期限隐私政策只说收集对话中提交的文本、文件和代码未提及整库快照和 Git 历史第六条目的明确、直接相关、影响最小的最小必要原则AI 推理通常只需发送任务相关片段全量仓库连历史一起传是否最小范围存疑第十四条同意须在充分知情前提下自愿、明确作出默认开启、无关闭入口难以构成明确同意此外快照落地到阿里云 OSS 属于委托第三方处理隐私政策也应当清晰披露这一层。作为一个用户我觉得最朴素的标准就一句话如果它要在你不知情时默认开启那它就应该在隐私政策里用最直白的话写明——而不是让用户靠逆向工程去发现。07 智谱的三次回应公允地说补救动作不慢这一节我想尽量客观。因为骂一家公司容易但看清危机响应做得怎么样对我们判断整件事、以及对自己做产品都更有价值。时间线时间动作9/18 凌晨ferstar 发布逆向分析9/18 傍晚智谱在官方用户群首次致歉问题源于代码库索引的 Repo Wiki上线初期默认开启称数据云端用完即销毁承诺开源、第三方审计全员补偿一次周额度重置9/19推送v3.14.0更新日志写明修复仓库百科异常上传的问题9/19太原承明科技有限公司发函追责提出 12 项答复要求销毁证明、私钥保管、是否跨境等保留诉讼权利9/21第三次回应已开源github.com/zai-org/ZCode信通院、绿盟完成首轮核查第三方核查的结论是中国信通院技术评测确认涉事的zcode-prod阿里云 OSS 存储桶当前云端零数据绿盟科技审查确认桶内全部数据对象及存储桶本身已删除v3.14.0 已移除 Repo Wiki 入口和生成链路未发现可触发本地快照或文件外发的功能路径。此外智谱 MaaS 平台还上线了数据内容不留存功能提示词和返回结果只在内存中参与当次计算请求结束即释放并承诺每月公布安全审计报告、建立漏洞报告机制。受事件影响其港股当日一度跌超 4%。ferstar 本人也做了对比验证v3.14.0 实测上传链路代码确已彻底移除、sidecar 已拆除。这一点质疑者本人是认可的。公允地说从披露到修复、开源、引入两家权威机构审计三天内完成这一整套动作响应速度和补救力度在同类事件里算快的。但他也指出了几个至今无法从外部证实、依然成立的问题我认为这些追问不过分立即销毁如何从外部证明此前已上传的快照是否被物理清除、谁曾持有解密权检查点回滚与立即销毁在工程逻辑上存在张力——云端到底留过什么开源的版本是否覆盖问题版本的上传组件还是只开源最新一次提交技术博主披露的是代码、文件、日志反映出的行为官方说明的是功能目的、处理方式、补救措施——两部分信息要分开看最终答案仍取决于开源代码和持续审计。肯定补救的诚意也保留合理的质疑这不矛盾。08 今晚就能动手的三件事说了这么多落到你我自己身上不管你用的是 ZCode、Grok、Claude 还是别的 AI 编程工具有三件事今晚就能做。第一件翻一遍 AI 工具的本地数据目录。这类工具一般在用户目录下有同名隐藏目录ZCode 是~/.zcode。按体积排序看有没有几十到几百 MB 的密文包或快照。发现后确认三件事密钥在谁手里开关能不能真的关掉它手动删掉后它会不会重新生成如果你就是想彻底断了某个工具的快照上传在确认会牺牲该工具检查点/时间线功能的前提下可以对其检查点目录加不可写属性从内核层面拒绝写入。第二件给自己的仓库做一次历史体检。翻一翻历史里有没有早已删除的密钥、内网域名、未发布的分支名# 查看历史改动重点找密钥、连接串、口令gitlog-p如果发现历史里真有泄露过的密钥立刻轮换那批密钥——这是第一位的改历史删文件都不如换密钥来得实在确有需要再用git filter-repo之类工具清理历史并知会所有协作者重新 clone。记住能被整包带走的仓库暴露的不是当前代码是它从第一天起的全部历史。密钥别想着我后来删了就没事。第三件把 AI 编程工具纳入正式的准入评估尤其是公司。如果你是团队负责人别等出了事才临时停用。引入这类工具前就问供应商四个问题读取范围是否与当前任务相符上传前是否充分告知用户能否真正一键关闭注意要问清开关断的是哪段路径服务商如何证明数据已经删除在拿到满意答案前商业和涉密项目不要在这类客户端登录、不要纳入工作区企业可将其纳入第三方安全评估和白名单管理。写在最后边界要按还剩哪些能出去的路来审计这件事让我反复想起做安全时的一条原则边界要按可达通道审计而不是按禁止清单审计。你列了多少条禁令不重要重要的是系统里还剩哪些能出去的路。隐私政策写了不收集但客户端留着一条登录即触发的上传通道开关摆在那里但它们不控制上传。真正的边界最后是由文件系统的一个权限位、内核的一次拒绝写入来兑现的。过去很长一段时间我们谈 AI 安全谈的都是怎么防止坏人从外面攻击 AI。但 ZCode、Grok、ChatGPT 唤起豆包、以及最近 OpenAI 把协作 Agent 之间未经授权的文件共享列为不当行为——这些事指向同一个新的十字路口我们也到了必须为 AI 自身的行为划定清晰边界的时候了。AI 可以读多少、可以传多远、在什么情况下必须先问你、数据最终能被谁解密——这些边界不该由逆向工程师一个个挖出来而应该在产品设计的第一天就被想清楚、写明白、做进执行点里。工具能提效但代码库就是我们这行的核心资产。选 AI 开发工具数据安全这根弦得自己绷紧。