智谱这次的风波，始于一次清理磁盘。
按ferstar的自述，他的那台256GB的MacBook Air空间吃紧，清理磁盘时，发现ZCode的本地数据目录占了700多MB。直觉不对劲的他，继续往里找，发现了一份313MB的加密包。
9月18日，智谱ZCode用户ferstar在x上发布了一条推文。推文中写到（译文）：
嘿@Zai_org，为什么ZCode在登录时会悄悄地把整个工作区加上完整的.git历史打包上传到阿里云OSS？
服务器持有唯一的解密密钥，
没有UI开关可以禁用，
隐私政策中零披露。
ferstar在推文中@了智谱的X账号Zai_org，并附上完整取证文章的链接。（https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/）
这个大包没有上传成功。ferstar后来补充，它在本地反复失败，而另一个小型公开仓库的快照，则留下了服务端已接收的记录。
两者不能混为一谈，但都指向同一件事：软件在用户没有主动提交整个仓库的情况下，另行准备了上传包。
9月18日，另一位用户luwanglin也在智谱官方反馈仓库提交报告，质疑“仓库快照索引”开关无法阻止上传。
当日傍晚，智谱致歉。智谱的回应中，将上传与云端生成Repo Wiki联系起来，并承认相关功能上线初期默认开启。
Repo Wiki，可以简单理解为一份项目说明书。AI要在项目里干活，读说明书并不奇怪。但这份说明书怎样写，需要读哪些材料，又为什么会把版本历史也装进上传包？
写一份“说明书”，到底需要带走什么
智谱在致歉声明中写道：
此次问题源于 ZCode 的“代码库索引”功能。该功能旨在帮助用户在本地生成仓库索引，以支持包括历史版本在内的会话检查点恢复、历史版本回退及 Repo Wiki 等功能。
Repo Wiki 功能在生成 Wiki 页面时可能会触发仓库数据上传。Wiki 页面在云端生成后，相关上传数据会立即销毁，不会保存。
声明中解释列出了几种用途，其中与云端上传直接相连的是生成Wiki。至于它为什么有用，得从AI接手一个现成项目时遇到的问题说起。
现在，假设，你交给AI一个任务：修复“密码正确，却登不上去”的故障。模型会写登录代码，却未必知道你的项目把登录功能写在哪些文件里。动手之前，它得先找到相关代码，弄清这些代码如何配合。
为方便理解，假设这个项目把登录逻辑分在三个文件里：文件A接收账号和密码，交给文件B核验；核验通过后，文件C发放登录凭证，供后续请求证明用户已经登录。另外还有测试，检查成功响应里是否包含这份凭证。
AI得先找到这些文件，弄清结果从哪里传到哪里，才能判断应该检查密码核验，还是凭证发放。只给它一句“修好登录”，这些项目细节不会随之自动出现。
下次若要调整登录凭证的有效期，或者修改密码错误时的提示，又会遇到这几处实现。如果能把已经梳理出的关系写下来，就多了一份可以复用的材料。
智谱声明中提到的Repo Wiki做的，正是这类整理。
Repo是repository的简称，指代码仓库。另一款AI编程工具Qoder在官方文档中，将Wiki的产物称为“structured project knowledge”，即“结构化的项目知识”。简单来说，就是把分散在几个文件中的逻辑，写成一段能顺着读下来的说明。
“分散的登录代码如何整理成Repo Wiki”图 *图为简化示意，不代表ZCode实际生成的文档。*
有了这个“说明书”，接下来就是让模型用上它。
依旧还是这个登录故障的任务。
产品可以先取出Wiki中介绍登录流程的段落，交给模型。模型看到A、B、C的关系后，再要求读取相关源码。工具读出的当前代码、测试报错，连同用户的需求，一起进入下一次模型调用。
而这一轮实际交给模型的材料，就是我们常说的“上下文”。
Wiki是可供取用的文档，上下文则是本次调用实际收到的内容。文档存在电脑里，还需要被读取或加载，才会参与模型这一次判断。Claude Code的官方说明中，也把对话历史、文件内容、命令输出及项目指令文件列为上下文的组成部分。
这类文档怎样自动生成和维护，也早有研究。
发表于EMNLP 2024的RepoAgent论文，将流程分为“全局结构分析、文档生成和文档更新”（原文译）。系统先识别代码中的函数、类及其引用关系，再把源码和相关信息交给模型，生成文档。
代码改了，说明也要跟着改。
论文写道：“RepoAgent only updates the documentation of affected objects.”翻译过来就是“RepoAgent只更新受影响对象的文档。”这里的对象包括函数、类等代码单元。RepoAgent利用Git记录的代码变化，识别哪些说明需要重写。
但“说明书”的作用，并没有规定原料必须收集到什么程度。
按ferstar对该商业项目本地快照文件清单的统计，.git目录下的文件占所统计文件总体积的86.6%。其中，Git LFS大文件缓存占总体积的56.8%，Git对象库占29.6%，Git引用变更日志占0.2%。这些比例来自那个上传失败的样本，不是已经外传的数据量。
这里提到的Git用于管理版本，保存的东西可能比项目当前显示的文件更多。Git官方教程做过一个直观演示：先后保存一个文件的两个版本，再删除当前文件，两版内容仍可从对象库取回。而文件在眼前消失，不等于它的旧内容已经从版本库消失。
旧版本当然可能还有用。
沿用前文登录的任务，如果故障出现在一次修改后，对照修改前后的代码，就可能提供线索。但追查这次修改，与打包本地历史对象和大文件缓存，涉及的范围显然不同。
在智谱的回应中，它解释了Wiki的用途，却没有进一步交代，这些历史材料和缓存分别怎样参与Wiki生成。
理解项目，不止这一条路
要修好这个登录故障，AI需要拿到相关代码和项目约定。
如何拿到？
先看这些材料怎样准备：遇到任务再查，还是提前整理好？
AI完成这个任务，需要的是足以定位问题、完成修改的信息。而智谱声明中提及的预先生成Wiki，只是办法之一。
Claude Code的官方文档恰好举过修复身份验证故障的例子。
它描述的动作是：“搜索相关文件，读取多个文件以理解上下文，并对这些文件进行协调修改”（原文节译），随后运行测试验证，用户要求时再提交改动。
放进那个登录故障中，就可能变成了这样：先搜索登录报错或函数名，找到文件A；读到A调用B，再打开B；发现核验结果交给C，继续检查C。查找、读取和判断交替进行，不需要先为整个项目写好说明书。
这种做法省去了预先整理全部文档的步骤，相关的查找工作也留在任务发生时完成。但问题是，线索没找对，就得换关键词；调用关系跨了几个文件，就要继续往下读。Wiki则把部分梳理提前做了，但代码改动后，说明也得更新。很多时候，两者承担工作的时间不同，可以相互补充。
除了直接读代码，开发者还可以把项目约定预先写给AI。
Claude Code对CLAUDE.md的建议很直接：“Treat CLAUDE.md as the place you write down what you’d otherwise re-explain.”翻译过来就是：把CLAUDE.md当作一个地方，写下那些否则还得重新解释的内容。这里，文档列举了构建命令、项目布局和团队约定。
开发者可以在说明里写清这些信息，比如登录接口放在哪个目录，改完应运行哪个测试，旧接口是否还要保留。这些说明侧重告诉AI项目的约定，而Wiki侧重整理代码已经怎样实现。两者可能重叠，也都需要在项目变化后维护。
这些材料可以配合使用。但准备好材料之后，还要决定一点——这一次究竟取哪些？
2024年发表于国际机器学习大会（ICML）的论文《Repoformer: Selective Retrieval for Repository-Level Code Completion》，研究了一个具体问题：模型补写代码时，是否每次都需要从同一仓库的其他文件里检索材料？
在论文测试的模型和任务中，相当一部分检索内容没有改善补全表现，有些反而使表现下降。摘要称其“unhelpful or harmful”，即无助于补全，甚至拉低补全质量。因此，研究者让模型先判断额外检索是否可能有帮助，再决定要不要检索。
继续登录故障的例子。我们可以把这种选择理解为：先判断手头的信息是否足够，再决定要不要查找其他文件。同样，一个文件被装进上传包，只说明它被纳入传输范围；它是否进入模型这一轮的上下文、能否帮助定位故障，还要分别判断。
选什么之外，还有一个与上传直接相关的选择：搜索是在用户电脑上完成，还是把材料送到云端再查？
Cursor是一款AI编程工具，它内置的Instant Grep，是在项目中查找函数名、变量名、报错文字等内容的搜索工具。官方文档写道：“Instant Grep builds and queries its index on your machine.”意思是，Instant Grep在用户自己的电脑上建立并查询索引。
索引可以理解为一份帮助定位内容的记录。要找核验密码的函数，先借助这份记录圈出可能包含它的文件，再打开文件确认。它帮助AI更快找到代码；Wiki则把代码之间的关系写成说明。
这也意味着，为建立这份搜索索引，不必先把代码传到服务器。但找到文件之后，如果要让云端模型分析其中的代码，相关内容仍可能进入模型请求。本地搜索减少的是搜索环节所需的数据传输，并不代表整个产品都在本地运行。
本地处理也有代价。2026年3月23日，Cursor在技术文章《Fast regex search: indexing text for agent tools》中解释，索引需要先建立，文件改动后还得及时更新。否则，AI刚写下的代码，可能在下一次搜索时找不到。
简单来说，就是可以把它理解为维护一份随时变化的文件目录：文件改了，记录也得跟着改，而记录本身还要占用电脑的存储和内存。Cursor采用的办法包括把记录候选文件的索引数据存到磁盘上，查询时按需读取。把搜索留在本地，省去了相应的源码同步和网络往返，却增加了客户端维护索引的工作。
即使仍然选择生成Wiki，上传范围和启用方式也可以另作安排。
Qoder的Repo Wiki官方文档列出两项设计：“No full-codebase upload”和“Off by default”，即不上传完整代码库、功能默认关闭。按文档说明，生成工作由本地客户端组织多个AI助手完成，只读取任务需要的文件；结果存回本地仓库，自动更新也由用户控制。
这些提供了几种不同安排：可以边做边查，也可以提前生成Wiki；生成Wiki，又可以选择不整库上传、由用户主动开启。
用户关掉的，究竟是什么
如果用户在对话里要求AI“不要读文件”，能不能阻止文件离开电脑？
2026年7月，独立研究者cereblab测试了xAI旗下的编程工具Grok Build 0.2.93。他要区分两件事：文件是模型为了完成任务主动读取的，还是电脑上的软件另有一套上传程序？
他在自己的仓库里放入一个带有独特标记的文件。这个标记相当于给文件做了记号，便于检查它是否出现在传输内容中。随后，他输入：
“Reply with exactly: OK. Do not read or open any files.”
即：“只回复‘OK’。不要读取或打开任何文件。”
按他的记录，模型没有打开标记文件。但客户端仍上传了包含Git已跟踪文件及其历史的仓库包，服务器返回接收成功的响应。他又从捕获的上传包中还原出仓库，找回了标记文件和Git历史。
按cereblab公布的7月13日复测记录，服务器下发的配置已将代码库上传设为关闭；在他当日进行的6次测试中，没有再出现仓库包上传。
研究者在7月14日更新中还称，马斯克已公开承诺删除此前上传的数据，但他当时尚未确认删除完成。7月15日，xAI宣布开源Grok Build的编程助手框架和终端界面，让外界能够检查客户端如何工作。
不让文件进入处理过程，和处理后不再保存，也是两件事。
Cursor曾遇到过这样的争议。
2025年3月6日，用户SomeUser123在Cursor官方论坛报告，自己已通过`.cursorignore`排除了`.env`文件，编辑之后，其中的敏感内容仍能出现在代码补全中。这类文件常用来存放程序配置，也可能含有访问密钥。
3月13日，官方社区回应者Dan确认，近期编辑过的被忽略文件可能使Tab补全建议包含敏感内容，并称问题已在v0.47修复。他形容这个漏洞时用了“it could slip into Tab suggestions”：内容可能溜进Tab建议。
在同一回复中，Dan还强调，开启Privacy Mode后，代码不会在具体请求处理之外被保存。
回到ZCode，第707号反馈把问题落在了一个明确的开关上。
luwanglin报告使用的是macOS端3.12.3。他提供的本地状态中，“仓库快照索引”设为关闭，同时存在快照被远端接收的记录。需要区分的是，接收记录本身说明曾经上传成功；判断关闭之后是否又发生上传，还要结合时间和运行过程。
ferstar对3.12.3版本代码的检查，则给出了另一层解释。按他的分析，这个开关控制的是服务器收到快照后是否建立索引，并不控制客户端打包和上传。
至此，问题已经不只是说明书写得好不好。
撤掉Wiki之后
事件并没有停留在ferstar的推文和智谱的回应。
InfoQ在9月20日报道，太原承明科技要求智谱说明数据流向、删除情况和操作日志。报道称，InfoQ联系了承明科技发言人，确认发函属实。另据红星资本局同日报道，针对承明科技函件的内容和诉求，智谱相关人员回应称“不实消息”。
9月21日，承明科技相关负责人向第一财经表示，公司正在进行二次信息验证，并与智谱沟通处理方案，具体细节不便透露。
当日，智谱宣布开源ZCode，并公布相关数据删除和第三方评测的进展。按公司通报，v3.14.0移除了涉事Repo Wiki及快照生成、上传路径，而公开评测摘要涉及指定云端存储空间的清空、删除情况。
企业方面也有了后续。
财新9月22日报道，承明科技于9月21日晚间发布声明，称此前针对ZCode发函及接受媒体采访时，“有举证错误、表述不严谨及措辞过度等问题”。据封面新闻9月23日报道，该公司已撤回函件所列主张，其技术人员在接受采访时表示，此前指出的问题在更新后的版本中已无法复现。
长宏网配资提示：文章来自网络，不代表本站观点。
