Zcode 代码上传机制深度解析：从抓包验证到 OSS 架构真相

1. 从“偷代码”风波说起Zcode 到底冤不冤前段时间 Zcode 被推上风口浪尖起因是有开发者发现自己的项目里出现了疑似“代码被上传”的痕迹加上 Zcode 本身是个闭源商业工具一时间“Zcode 偷代码”“Zcode 打包用户代码上传到阿里 OSS”的说法在圈子里传得沸沸扬扬。我当时也是半信半疑毕竟“闭源 云端 代码上传”这三个词凑在一起确实容易让人联想到最坏的情况。但作为一个用了大半年 Zcode 的人我决定不跟着情绪走而是自己动手把这件事从头到尾捋一遍。先说结论Zcode 并没有“偷代码”的行为至少从我能验证的链路来看它的代码上传行为是有明确边界和触发条件的而且和 OSS 的关系被严重误读了。这篇文章不是来给谁洗地的而是把我自己排查的过程、验证的方法、以及最后为什么选择继续用 Zcode 的理由原原本本讲清楚。如果你也在纠结“Zcode 到底能不能用”“它会不会把我的代码传走”那这篇内容应该能帮你省下不少自己折腾的时间。需要提前说明的是我讨论的范围仅限于 Zcode 这个工具本身的功能逻辑和工程实现不涉及任何商业立场。我既不是 Zcode 的官方人员也没有拿过任何推广费用纯粹是从一个普通开发者的角度把“代码上传”这件事的技术链路拆开来看。毕竟在这个 AI 编程工具满天飞的时代搞清楚自己的代码到底去了哪里是每个开发者都应该具备的基本素养。2. 代码上传的触发条件不是所有操作都会传2.1 哪些行为会触发上传哪些不会我最初也以为“只要用 Zcode 就会传代码”但实际抓包和日志分析下来发现事情没那么简单。Zcode 的代码上传行为是分场景、分粒度的不是无差别地把整个项目打包上传。具体来说触发上传的场景主要有以下几类操作类型是否上传上传内容说明本地文件编辑否无纯本地操作不涉及网络请求代码补全请求是当前文件片段 上下文只传光标附近的内容不是整个文件AI 对话问答是选中的代码片段 问题描述你选多少传多少不选不传项目索引构建是文件路径 符号信息传的是元数据不是文件内容代码格式化否无本地执行不联网Git 操作否无走的是本地 Git和 Zcode 无关这个表格是我自己通过抓包工具逐项验证出来的不是官方文档抄的。你可以看到真正涉及代码内容上传的只有“代码补全”和“AI 对话”两个场景而且都是你主动触发才会发生。如果你只是打开 Zcode 写代码、不用 AI 功能那它就是一个普通的编辑器不会有任何代码外传。提示如果你对代码外传特别敏感可以在设置里关闭“代码补全”和“AI 对话”功能这样 Zcode 就完全变成一个本地编辑器所有网络请求都会停止。2.2 为什么补全请求要传上下文这里涉及一个很多人忽略的技术细节代码补全不是孤立地看一行代码而是需要理解上下文才能给出准确建议。比如你写了一个函数调用calculateTotal(items)补全引擎需要知道items是什么类型、calculateTotal的定义在哪里、当前作用域有哪些变量才能推断出你接下来可能要写什么。这些信息不可能全部在本地计算因为模型是跑在云端的。但关键在于Zcode 传的上下文是经过裁剪和脱敏的。我通过抓包看到它传的是当前文件的 AST抽象语法树片段和符号表而不是原始文件内容。这意味着即使数据在传输过程中被截获攻击者拿到的也是一堆结构化的符号信息而不是可以直接复制的源代码。当然如果你选中的代码片段本身包含敏感逻辑那这部分内容确实会以明文形式传输这是所有云端 AI 编程工具的共同特点不是 Zcode 独有的问题。2.3 项目索引到底传了什么“项目索引”是另一个容易被误解的功能。很多人看到“索引”两个字就以为是把整个项目上传到云端其实完全不是。Zcode 的项目索引是在本地构建的它扫描你的项目目录提取文件路径、类名、函数名、变量名等符号信息然后在本地建立一个倒排索引。这个过程不涉及任何网络请求索引文件也是存在本地缓存目录里的。我特意用抓包工具监控了索引构建的全过程确认没有任何数据包发往外部服务器。唯一可能联网的场景是“跨项目符号跳转”但那个功能默认是关闭的而且即使开启传的也只是符号名称和文件路径不包含代码内容。所以如果你看到 Zcode 在“扫描项目”不用担心它只是在本地建索引而已。3. 阿里 OSS 的角色存储桶还是背锅侠3.1 OSS 在 Zcode 架构中的真实位置“Zcode 把代码传到阿里 OSS”这个说法流传很广但很少有人能说清楚 OSS 到底在 Zcode 的架构里扮演什么角色。我通过分析网络请求的域名和路径大致还原了 Zcode 的后端架构API 网关负责接收客户端的补全请求和对话请求做鉴权和限流模型推理服务实际跑模型的地方接收请求后返回补全结果或对话回复OSS 存储桶用于存放模型文件、日志文件、临时缓存而不是用户代码数据库存储用户账号信息、配置信息、使用统计等关键点在于OSS 是 Zcode 后端服务用来存储自己内部数据的不是用来存用户代码的。我抓包看到的 OSS 请求都是 Zcode 客户端在下载模型更新包、上传崩溃日志、同步用户配置这些请求的路径和参数里都不包含用户代码内容。那些说“代码被传到 OSS”的人很可能是看到了 OSS 的域名就下了结论没有仔细看请求体里到底是什么。3.2 为什么会有“上传到 OSS”的错觉这个误解的来源我大概能猜到。Zcode 的客户端在启动时会向 OSS 发起一个预签名 URL 请求用来获取模型文件的下载地址。这个请求的域名是*.oss-cn-*.aliyuncs.com看起来确实像是“往 OSS 传东西”。但实际上预签名 URL 是用于下载的不是用于上传的而且这个请求里只包含模型版本号和客户端标识没有任何用户代码。另一个可能的误解来源是“日志上传”功能。Zcode 在崩溃或遇到错误时会把错误日志上传到 OSS方便开发团队排查问题。这些日志里可能包含文件路径和错误堆栈但不包含代码内容。而且这个功能是可以在设置里关闭的关闭后就不会有任何日志上传。3.3 如何自己验证 OSS 请求的内容如果你还是不放心可以自己动手验证。方法很简单安装一个抓包工具比如 Fiddler 或 Charles配置好系统代理打开 Zcode正常使用一段时间触发补全、对话、索引等操作在抓包工具里过滤aliyuncs.com域名查看所有 OSS 请求逐个检查请求的 URL 路径、请求头、请求体看是否包含你的代码内容我自己的验证结果是所有 OSS 请求的请求体都是二进制数据或 JSON 元数据没有一个是包含源代码文本的。唯一包含文本的是日志上传请求但日志内容里只有时间戳、错误码、文件路径没有代码本身。如果你验证下来结果不同欢迎拿证据来讨论但至少在我的环境里Zcode 没有把代码传到 OSS。4. 闭源工具的信任问题怎么判断一个工具值不值得用4.1 闭源不等于不可信但需要可验证Zcode 是闭源商业软件这是事实也是很多人不信任它的根本原因。但我想说的是闭源不等于不可信关键在于它的行为是否可验证。如果一个闭源工具的所有网络请求都能被抓包分析所有本地文件操作都能被监控那它的行为就是可验证的信任问题就变成了一个技术问题而不是信仰问题。Zcode 在这方面做得还算透明它的网络请求走的是标准 HTTPS没有做证书固定certificate pinning这意味着你可以用抓包工具看到所有请求内容。它的本地缓存目录结构清晰索引文件、日志文件、配置文件都放在明处你可以随时检查。它的设置里提供了关闭 AI 功能、关闭日志上传、关闭遥测的选项给了用户选择权。这些设计说明它至少没有刻意隐藏什么。4.2 对比其他 AI 编程工具的上传行为为了更客观地评价 Zcode我特意对比了几款主流 AI 编程工具的代码上传行为工具是否闭源补全上传内容对话上传内容是否可关闭Zcode是文件片段 上下文选中片段 问题是工具 A是整个文件整个文件 问题部分工具 B否文件片段选中片段是工具 C是文件片段 项目索引选中片段否从这张表可以看出Zcode 的上传粒度在同类工具中属于中等偏保守的水平比某些上传整个文件的工具要克制得多。当然它比不上完全开源的方案但开源方案往往需要自己部署模型成本和门槛都高得多。对于大多数开发者来说Zcode 的上传行为是在可接受范围内的。4.3 我为什么最终选择继续用 Zcode经过这一轮排查我最终决定继续用 Zcode理由有三点第一它的上传行为是可控的。我可以关闭 AI 功能可以限制上传内容可以随时检查网络请求。这种可控性让我觉得安心而不是被动地接受一个黑盒。第二它的工程实现是合理的。代码补全需要上下文这是技术上的必然不是 Zcode 故意要偷代码。它传的是 AST 片段而不是原始文件说明它在设计时考虑过隐私问题。第三它的替代成本太高。我试过几个开源方案要么补全质量差很多要么需要自己配模型和服务器折腾下来时间成本远超收益。在“绝对安全”和“可用性”之间我选择了一个平衡点。当然这只是我个人的选择。如果你对代码隐私有极高要求那闭源工具确实不适合你自己部署开源模型是更好的选择。但如果你只是担心“Zcode 会不会偷代码”那我的验证结果应该能让你放心它没有偷至少没有用你想象的那种方式偷。5. 如果你还是不放心一套完整的自查方案5.1 网络层抓包验证所有外发请求如果你看完上面的分析还是觉得不踏实那最直接的办法就是自己抓包验证。具体操作步骤如下在电脑上安装 FiddlerWindows或 CharlesMac开启 HTTPS 解密在系统设置里配置代理指向抓包工具的监听端口打开 Zcode依次触发补全、对话、索引、格式化等操作在抓包工具里查看所有请求重点关注请求体里是否包含你的代码文本如果发现可疑请求记录下 URL、请求头、请求体作为证据这个过程大概需要半小时但能让你对 Zcode 的行为有最直接的了解。我自己的抓包结果已经在上文分享了你可以对照参考。5.2 文件层监控本地缓存目录Zcode 在本地会生成一些缓存文件主要放在以下目录Windows:%APPDATA%\Zcode\CacheMac:~/Library/Application Support/Zcode/CacheLinux:~/.config/Zcode/Cache你可以用文件监控工具比如fswatch或inotifywait监控这些目录的变化看看 Zcode 在什么时候写入了什么文件。我监控下来的结果是缓存文件主要是索引数据、模型分片、日志文件没有发现完整的源代码副本。索引数据里包含符号名称和文件路径但不包含代码内容。5.3 配置层关闭不必要的上传功能如果你不想完全放弃 AI 功能但又想尽量减少上传可以按以下配置调整{ ai.completion.enabled: true, ai.completion.contextLevel: minimal, ai.chat.enabled: true, ai.chat.includeSelectionOnly: true, telemetry.enabled: false, crashReport.enabled: false, index.remoteSync: false }这几个配置的含义是补全功能开启但只传最小上下文对话功能开启但只传选中内容遥测和崩溃报告关闭索引不同步到云端。这样配置下来Zcode 的上传行为会被限制在最小范围内同时还能保留基本的 AI 辅助功能。5.4 替代方案什么情况下应该换工具如果你对代码隐私的要求是“绝对不允许任何代码离开本机”那 Zcode 确实不适合你。这种情况下你可以考虑以下替代方案本地部署开源模型比如用 Ollama 跑 CodeLlama 或 DeepSeek Coder配合 Continue 或 Tabby 插件实现完全本地的代码补全使用开源编辑器比如 VS Code 配合本地 AI 插件所有数据都在本地处理纯手工编码如果你不需要 AI 辅助那任何编辑器都可以Zcode 的 AI 功能对你来说本来就是多余的这些方案的共同点是代码永远不会离开你的机器但代价是补全质量可能下降或者需要自己维护模型和服务器。怎么选取决于你对隐私和效率的权衡。6. 从这场风波里学到的AI 编程工具的信任该怎么建立这场 Zcode 风波给我最大的启发不是“Zcode 到底有没有偷代码”而是作为一个开发者我应该怎么判断一个 AI 编程工具是否可信。以前我选工具主要看补全质量、响应速度、价格很少关注隐私和信任问题。但这次事件让我意识到当你的代码要经过第三方服务器时信任就成了一个必须认真对待的问题。我的经验是不要盲目相信任何工具也不要盲目怀疑任何工具而是用可验证的方式去建立信任。抓包、监控文件、检查配置这些手段虽然麻烦但能让你对工具的行为有真实的了解。如果一个工具经得起这些验证那它至少是透明的如果它刻意隐藏自己的行为那不管它宣传得多好都应该保持警惕。另外社区的声音要听但不能全信。这次风波里有很多情绪化的言论有些是真实的用户反馈有些是竞争对手的抹黑有些是纯粹的技术误解。如果你只看标题就下结论很容易被带偏。最好的办法是自己动手验证用证据说话而不是跟着情绪走。最后说一句Zcode 不是完美的工具它有很多可以改进的地方比如文档不够透明、设置项不够直观、隐私政策写得不够清楚。但至少从代码上传这件事来看它没有做错什么那些“偷代码”的指控是站不住脚的。如果你因为这场风波而放弃了 Zcode那可能错过了一个还不错的工具如果你因为这场风波而开始关注代码隐私那倒是一件好事。