ZCode静默上传完整Git历史,AI编程助手先学会了越过权限边界

开发者把一个代码目录交给AI助手，通常理解的是：它可以读取当前项目，帮助补全、解释或修改代码。

但有开发者逆向分析智谱ZCode后发现，客户端在构建代码库索引时，会打包上传工作区内容，其中可能包括.git目录里的提交历史、分支、reflog、Git LFS信息和仓库配置。调查还称，即使关闭部分同步选项，本地打包行为仍可能发生。

智谱随后回应，这与代码库索引和Repo Wiki功能有关，云端生成完成后相关数据会立即销毁；早期版本默认开启了相关功能，目前问题已经修复，并承诺推进开源和第三方安全审计。

这件事最值得讨论的，不是“AI到底能不能读代码”，而是用户授权它读到哪里、为什么要上传，以及这些边界有没有被说清楚。

.git不是一个可以顺手忽略的隐藏文件夹

很多普通用户只看到项目里当前版本的源代码，但.git保存的是仓库历史。被删除的旧文件、尚未合并的分支、远程仓库地址、开发者身份信息，甚至曾经误提交后又删掉的密钥，都可能继续留在历史对象中。

这意味着上传完整.git和上传当前工作目录，不是同一个风险等级。当前目录可能只有准备交付的一版代码，Git历史却可能包含公司几年的研发轨迹。对企业项目来说，它不仅是文件集合，还是产品路线、人员协作和安全失误的档案。

即使服务方没有主动查看，传输范围扩大本身也增加了暴露面。访问凭证、临时存储、日志、对象存储权限和数据销毁流程，任何一环出现问题，影响都会比“上传一段正在编辑的代码”更大。

功能需要数据，不代表默认可以拿走全部数据

代码库问答、全局索引和自动生成Wiki，确实需要理解跨文件关系。服务方为此上传部分项目内容，在技术上不难解释。问题在于，技术必要性不能替代明确同意。

一个合格的授权至少应该回答四件事：哪些文件会离开本机，上传到哪里，用于什么功能，保存多久。对.git、环境变量、密钥文件和构建产物等高风险内容，还应默认排除，或者在首次启用时单独提示。

如果用户只是打开编辑器，就自动启用云端索引；如果界面里的关闭选项与后台实际行为不一致；如果隐私说明只写“用于提升体验”，那么用户就无法做出有效选择。

“数据之后会销毁”可以降低长期存储风险，却不能补上事前授权。隐私边界首先发生在上传之前，而不是删除之后。

官方回应解决了一部分问题，也留下了验证需求

智谱表示相关数据在云端生成Wiki后立即销毁，并称问题已修复，还计划通过开源和第三方安全评估提高透明度。这比否认问题更有建设性，但用户真正需要的是可以验证的结果。

例如：默认开关是否已经调整；关闭云端功能后是否完全停止打包和上传；忽略规则能否覆盖子目录和历史对象；服务端是否保留日志、缓存和备份；旧版本曾上传的数据如何确认已经销毁。

开源客户端可以帮助外界检查本地逻辑，第三方审计可以核对流程，但两者都需要明确范围。只开源界面层，无法证明服务端如何处理数据；只发布一页审计结论，也很难让企业安全团队复核。

因此，这次回应应该被视为整改的开始，不是风险已经自动归零的证明。

使用AI编程工具，先做最小权限隔离

对个人开发者，最直接的做法是不要把密钥、证书和生产配置放进仓库，即使后来删除也要轮换凭证；使用工具前检查隐私设置、网络请求和项目忽略规则；不需要全库理解时，只开放必要目录。

企业则不该只靠员工“注意一点”。涉密仓库可以使用独立环境、网络出口审计和允许清单，明确哪些AI服务能接触哪些代码。采购时也要询问数据驻留、训练使用、保留周期和删除验证，而不是只看模型效果。

AI编程助手越强，读取上下文的欲望就越大。可“理解更多”不是天然正确的产品目标，尤其当更多意味着完整历史、凭证痕迹和企业资产。

ZCode事件真正敲响的警钟是：代码助手还没学会替你写完所有代码，产品就可能先越过你以为存在的权限边界。以后评价一款AI编程工具，除了好不好用，还必须多问一句——它为了好用，究竟拿走了什么