ZCode 说只是做索引，可它翻开的不止当前代码
ZCode 被曝在代码库索引过程中上传工作区快照、Git 历史与 LFS 等数据。官方说问题已经修好，但公开逆向证据留下了更多没被回答的问题。
你把 AI 编程工具叫醒，通常只是想让它改几行代码、跑一遍测试。你不会想到，它顺手把项目的“旧账”也翻了出来。
ZCode 的争议，正是从这里冒出来的。社区开发者披露，ZCode 在执行代码库索引时，可能把工作区打成加密包上传到云端。被讨论的东西不只是当前打开的文件，还包括 Git 历史、LFS 缓存和部分本地配置。
真正扎人的地方不是“代码能不能上云”，而是：谁替你决定了上传多少，你有没有看见这个决定，以及这些东西是不是完成任务真的需要。
9 月 18 日，多家媒体转述了这起争议。ZCode 官方随后回应称，问题源于“代码库索引”功能，相关问题已经修复，并就代码库数据上传问题致歉。官方还表示，近期将开源 ZCode 代码库，引入第三方评估人员审查系统运行情况，并持续公开审查进展。
现在还不能说每个用户都被上传了完整仓库。但问题已经够严重：一个工具能不能拿“这样效果更好”，替自己扩大用户的数据权限？
更麻烦的是，官方解释和公开证据没有完全接上。官方当然最了解自己的产品，但也正因为是当事人，不能只靠一纸公告给自己盖章。社区逆向未必能看到服务器里的全部故事，却能看见客户端到底动了哪些手脚。
公告说得很轻，证据却没有这么轻
官方公告把事情归到“代码库索引”上，说问题已经修好。听起来像是某个开关接错了、某段代码写歪了。但它没有回答最要命的几件事：索引为什么要碰完整 Git 对象、LFS 缓存和历史元数据？为什么要先打成加密包？为什么要传到第三方对象存储？用户又是在什么时候同意的？
公开的逆向材料比公告具体得多。研究者展示了本地生成的加密归档，指出归档里出现 Git 历史和 LFS 相关数据，并追到了客户端向阿里云 OSS 发起上传的链路。媒体转述的独立复核还给出两个刺眼的数字：一次上传失败后，客户端重试了 564 次；本机 Git 清单达到 2196 条。
这两个数字不能证明所有用户都遇到了同样的事，但至少说明“只是读几个当前文件”解释不通。一个只想查代码的索引器，为什么要翻这么厚的历史账本？如果官方认为这些文件从未离开本机，就应该拿出文件清单和可复现测试，而不是把问题塞进“索引功能”四个字里。
所以，“加密”也不能当免责词。加密归档至少说明数据被集中收拾过；OSS 上传链路至少说明数据离开过客户端。它们都不能自动说明服务器会马上删除，更不能说明用户已经同意。
官方承诺开源代码、引入第三方评估，这些当然比沉默好。但它们是补救，不是给旧公告自动盖章。在代码、版本差异、构建产物和审查报告出来之前，“问题已修复”仍然只是当事人的一句话。用户至少应该能看到：修复前后请求有什么不同，归档里还装不装 Git，上传域名有没有变，客户端到底删掉了哪段逻辑。
所以，现阶段不能说官方已经把事情讲清楚。更接近事实的说法是：公告承认了问题，却把问题说得比公开证据小。它没有正面解释 Git 历史、LFS、加密归档和 OSS 上传，也没有交代影响版本和数据去向。对已经被观察到的客户端行为避而不谈，再用“索引问题”把整件事包起来，这至少是一种误导性的说法。
争议不在于“上传”，而在于上传超出了用户预期
AI 编程工具要完成复杂任务，很多时候确实需要把代码发送到云端。这本身并不奇怪。
用户通常也能接受几种明确的情况：主动选中一段代码，让模型解释；提交一个文件，请模型修改；在设置中开启云端索引，并看到它处理了哪些目录；或者选择远程 Agent，让它在云端环境中运行项目。
问题在于，代码库索引功能很容易变成一个用户没有明确感知的后台行为。
当用户登录、打开项目或启用某项智能功能时，如果客户端自动打包工作区并上传，用户面对的就不是一次清晰的“提交代码”操作，而是一种默认授权。
前者是用户知道自己把什么交给了谁；后者是用户只知道自己打开了一个工具，却不知道工具在后台复制了多少内容。
这也是社区反应激烈的原因：争议的重点不是 AI 工具能否处理代码，而是工具是否在用户没有充分知情的情况下扩大了数据处理范围。
Git 历史比当前代码更敏感
很多人会问：“代码上传了就上传了，Git 历史有什么特别？”
Git 历史往往比当前工作区更敏感。
当前代码可能已经经过清理，旧版本却可能保留：
- 曾经提交过的 API Key；
- 已删除但仍可用的服务地址；
- 废弃的数据库连接串；
- 内部项目名称和客户需求；
- 尚未公开的功能分支；
- 已删除但仍能从历史提交中恢复的敏感文件。
即使开发者后来执行了 git rm，敏感内容也可能继续存在于历史提交、reflog、对象库或 LFS 缓存中。
上传当前文件，暴露的是“现在的项目”；上传完整 Git 历史，暴露的可能是“这个项目从出生到今天的全部过程”。这不是同一个风险等级。
因此，“我们只是做代码索引”不能自动解释完整 Git 历史的上传范围。索引当前代码，通常不需要把所有历史提交、LFS 缓存和本地仓库元数据一并打包。如果产品确实需要这些数据，就必须说明具体用途，并让用户主动选择；否则，“索引”只是一个掩盖采集范围的产品名词。
加密上传不能替代用户授权
围绕这起事件，一个可能出现的辩护是：“上传的数据是加密的。”
这句话只能回答传输过程中的一个问题：数据是否容易被中途截获。它回答不了另外三个问题：谁能解密、数据会保存多久、为什么用户没有明确选择就被上传。
加密不是授权。
一个产品完全可以把用户不知情上传的数据加密后保存，但这不代表行为就合理。加密解决的是保密性，无法替代透明度、最小化采集和明确同意。
用户真正需要知道的不是“文件在路上是否加密”，而是：
- 哪些目录被读取了；
- 是否包含
.git、LFS 和未跟踪文件； - 是否包含环境变量和本地配置；
- 数据被传到哪个服务商；
- 保存多久；
- 是否用于模型训练或产品改进；
- 如何删除；
- 关闭功能后是否还会上传。
如果这些问题没有清楚答案，用户就只能凭信任把整个开发环境交出去。对处理源代码的产品来说，“请相信我们”本身不能构成安全机制。
这不是普通 Bug，而是产品边界设计出了问题
ZCode 官方将问题归因于代码库索引功能，并表示相关问题已经修复。
从实现角度看，这可能是索引范围过大的问题：索引器为了提高检索效果读取了更大的工作区，客户端为了减少重复分析把项目打包上传，开发团队则可能把这些数据视为已经获得授权的代码上下文。
但这仍然不只是普通 Bug。
因为它涉及产品的默认边界：默认读取多大范围，默认上传哪些文件，默认是否包含历史数据，默认是否允许第三方云存储，默认保存多长时间，以及默认是否参与模型改进。
这些都是产品决策，而不是只能由工程实现细节决定的副作用。
AI 产品普遍存在一种危险倾向：为了让模型更聪明，默认拿更多数据；为了让 Agent 更自动，默认给更多权限；为了减少操作步骤，默认替用户做更多决定。
这会让产品短期看起来更顺滑，却把不可逆的泄露风险集中到用户身上。产品获得了更完整的上下文，用户承担了更大的暴露面，这个交换不能由默认设置替用户完成。
修复还需要什么证据
ZCode 已公开的后续动作包括修复相关功能、致歉、计划开源代码库、引入第三方评估人员，以及公开审查进展。这些动作中，开源和第三方审查最重要。
但用户还需要看到更具体的技术信息：
- 哪个版本引入了问题；
- 哪些版本受到影响；
- 具体上传了哪些数据；
- 数据上传到哪里；
- 是否包含
.git和 LFS； - 服务端保存了多久；
- 是否存在下载、解密或二次使用；
- 如何确认历史数据已经删除；
- 修复后的客户端是否仍会执行类似行为。
如果只能看到“问题已修复”，却看不到技术细节，用户仍然无法判断风险是否真正结束。
“开源代码库”也不等于自动完成审计。用户还需要关注开源的范围、发布版本、构建过程，以及公开代码是否和实际客户端一致。
开源是修复信任的起点，不是问题已经结束的证明。
开发者现在应该怎么做
在类似工具完成审查之前，开发者可以先采取几项低成本措施。
第一，不要直接让 AI 工具打开包含生产密钥的真实仓库。可以先复制一个脱敏项目，删除 .env 文件、云服务凭证、SSH 私钥、数据库连接串、客户数据和不需要参与任务的历史分支。
第二，检查项目里是否存在 .git、.gitignore、LFS 缓存和构建产物。“我没有选中这个文件”不代表工具不会读取它。索引类功能往往按目录扫描，而不是按编辑器当前选区工作。
第三，观察网络请求和本地临时文件。如果客户端会在登录、索引或启动阶段生成较大的压缩包，可以检查文件生成时间、文件大小、是否包含 Git 对象、上传目标域名，以及关闭功能后是否仍然上传。
第四，把 AI 编程工具当成第三方代码处理服务，而不是普通编辑器。编辑器通常只修改本地文件；AI Agent 可能会读取、执行、压缩、上传并调用外部服务。两者的权限模型完全不同。
结论：AI 编程工具必须默认最小权限
这起事件最值得行业记住的一句话是：
用户让 AI 修改代码，不等于用户同意 AI 复制整个项目的历史。
AI 编程工具当然需要代码上下文，但上下文应该具备边界。
更合理的设计应该是：
- 默认只处理当前任务需要的文件；
.git、密钥文件和隐藏目录默认排除；- 全仓库索引必须单独授权；
- 上传前展示文件清单和数据大小；
- 每次上传都能被用户取消；
- 提供本地索引模式；
- 清楚展示云端保存期限；
- 提供历史数据删除入口；
- 将“用于当前任务”和“用于模型改进”分开授权。
这会牺牲一点产品的自动化程度，也会增加几个确认步骤。但这正是隐私保护的真实成本。
一个工具如果要求用户交出整个仓库，至少应该让用户清楚知道自己交出了什么。否则，它提供的不是智能，而是未经充分说明的权限扩张。
ZCode 事件表面上是一次代码上传争议，深层却是 AI 编程工具行业必须面对的信任问题：当 Agent 越来越能代表用户行动时，产品的默认行为就不能再藏在后台。
开发者需要的不是一句“相信我们”，而是可见的权限、可审计的代码、可撤销的数据处理，以及足够具体的证据。
AI 编程工具真正的专业，不是能读懂多少代码，而是知道哪些代码不该擅自读取。
相关来源
本文根据社区技术披露、独立复核文章、公开媒体报道和 ZCode 官方回应整理。文中对官方公告的批评，针对的是公告对已披露客户端行为的解释缺口；关于服务端最终保存、解密和删除数据的范围，仍应以可复现的第三方审计、公开代码和日志证据为准。
更多文章
