1. 这场风波到底在吵什么1.1 从一条爆料说起ZCode 被指偷传代码前段时间开发者圈子里炸了锅起因是有用户在社区发帖说自己用智谱的 ZCode 写代码时抓包发现编辑器在后台往外发数据怀疑自己的项目源码被偷传了。帖子一出评论区瞬间分成两派一派说早就觉得不对劲AI 编辑器哪有不看你代码的另一派说你用的是云端模型不传代码它怎么给你补全这不是废话吗。我第一时间去翻了原始爆料和后续的官方回应也自己装了一遍 ZCode 做验证。先把结论摆前面这件事的核心争议不在于传没传而在于传了什么、传去哪、用户知不知情、能不能关。这四点里前两点是技术问题后两点是产品设计和信任问题。而恰恰是后两点在最初的回应里说得比较含糊这才是风波越滚越大的真正原因。ZCode 是智谱推出的一款 AI 编程工具定位类似 Cursor、Trae 这类AI 原生编辑器底层接的是智谱自家的 GLM 系列模型。它的卖点很直接中文语境好、接入智谱 API 方便、对国内开发者友好。你可以在里面用自然语言让它写函数、改 bug、生成单元测试甚至直接对话式地重构整个模块。对天天和代码打交道的人来说这类工具一旦用顺手效率提升是实打实的。但效率的另一面就是数据边界。当你的编辑器同时是一个能读懂你全部代码的助手它和你的代码仓库之间就存在一条数据通道。这条通道怎么走、走多少、加密没有、能不能断直接决定了你敢不敢把公司的核心项目放进去。这次风波本质上是开发者对这条通道的一次集体体检。1.2 为什么开发者对代码外传这么敏感要理解为什么一个抓包截图能引爆舆论得先理解代码对开发者意味着什么。代码不是普通文本。一个成熟项目的源码里藏着业务逻辑、算法实现、密钥配置、内部接口地址、数据库结构、甚至一些没来得及修的漏洞。这些东西一旦泄露轻则被人抄走核心逻辑重则被人顺着接口摸到你的服务器。我见过太多团队对外防得滴水不漏结果栽在一个随手用的第三方工具上。更关键的是心理预期。你用 GitHub 托管代码你清楚代码在云端你用云端 AI 补全你也大致知道请求会发出去。但很多人对本地编辑器有一种天然的信任——觉得它就是个 IDE跟 VSCode 一样代码在本地跑。当这个预期被打破哪怕技术上完全合理情绪上的反弹也会非常大。这不是开发者矫情而是安全直觉在起作用。所以这次风波里真正值得讨论的问题其实是这几个ZCode 到底把哪些数据发给了服务器是整份文件还是光标附近的片段有没有做脱敏传输过程加密了吗用户能不能看到、能不能控制下面我逐个拆。1.3 本文适合谁看能带走什么这篇不是来站队的也不是来洗地或者带节奏的。我想做的是把这件事拆成可验证的技术问题让每个用 AI 编程工具的人都能自己判断风险。如果你是企业里的技术负责人正在评估要不要让团队用 ZCode 或类似工具这篇能帮你理清该问供应商哪些问题、该做哪些验证。如果你是个人开发者担心自己的 side project 被传出去这篇会告诉你怎么抓包、怎么看、怎么关。如果你只是好奇AI 编辑器到底怎么工作的那更好我会用生活化的类比把原理讲清楚。一句话别听别人说安不安全自己会看才最踏实。2. AI 编辑器的工作原理它为什么必须看你的代码2.1 补全、对话、Agent三种模式的数据流完全不同很多人把AI 编辑器当成一个东西其实它内部至少有三套不同的工作机制数据流向差别很大。搞清楚这个你才能判断传代码到底传的是什么。第一种是行内补全Inline Completion。就是你打字打到一半它给你灰字提示后面该写啥。这种模式下编辑器通常只把光标前后的几十到几百行发出去而不是整个文件。为什么因为补全是个高频操作你每敲几个字符它就触发一次如果每次都传整个项目带宽和延迟都受不了成本也爆炸。所以它必须做裁剪只传当前上下文。第二种是对话式问答Chat。你在侧边栏问这个函数为什么报错它需要理解你的问题可能还要读一下相关文件。这种模式下传出去的内容取决于工具的实现有的只传你选中的代码片段有的会做检索增强自动把相关文件也带上。这里就是风险分水岭——如果它自动把整个项目索引后上传那性质就完全不一样了。第三种是 Agent 模式。这是最近最火也最敏感的。Agent 不只是回答问题它会自己规划步骤、自己读写文件、自己执行命令。比如你说帮我把这个模块重构成异步的它会自己打开文件、改代码、跑测试。这种模式下它读取的文件范围可能非常大因为它要理解整个项目。ZCode 这次被质疑的主要就是 Agent 模式下的数据行为。用个类比补全像是你写作业时同桌瞄一眼你写到哪了对话像是你拿一道题去问老师Agent 则像是你把整个书包交给一个助教让他帮你整理。三者对隐私的侵入程度完全不是一个量级。2.2 云端模型 vs 本地模型数据出不出你的机器判断风险的第一性问题永远是模型跑在哪如果模型跑在你本地比如你用 Ollama 跑个量化后的小模型那数据根本不出你的机器理论上最安全代价是效果通常打折扣、吃硬件。如果模型跑在云端智谱 GLM 就是云端 API那你的输入必然要经过网络发到服务器这是物理事实没有例外。所以当有人说ZCode 偷传代码从技术上讲只要它用的是云端模型传数据是设计使然不是偷。真正该追问的是传的范围合不合理有没有超出必要有没有告知有没有开关我实测下来ZCode 在补全场景下确实只发上下文片段但在 Agent 执行复杂任务时读取和发送的范围会明显扩大。这符合它的功能定位但对用户来说这个扩大如果没有清晰的提示就容易产生被欺骗的感觉。2.3 一次请求的完整旅程从你的键盘到服务器我们把一次典型的 AI 请求拆开看你就知道数据在哪几个环节可能失控。触发你在编辑器里打字或发指令客户端决定这次要发什么内容。组装客户端把上下文、指令、可能的文件内容打包成一个请求体。传输请求体通过网络发往 API 服务器这一步是否加密HTTPS/TLS至关重要。服务端处理服务器收到后可能记录日志、可能用于训练、可能只做推理后丢弃。返回结果回传给你同时可能被缓存。风险点集中在第 2、4 步。第 2 步是发多少第 4 步是存多久、用来干嘛。这两点恰恰是普通用户最难直接看到的也是这次风波里官方回应最需要说清楚的地方。抓包能帮你看清第 2、3 步但第 4 步只能靠厂商的隐私政策和你的信任。3. 自己动手验证抓包看清 ZCode 到底发了什么3.1 准备工作抓包工具怎么选想验证传没传、传了啥最直接的办法就是抓包。我常用的组合是mitmproxy或Charles前者免费开源、命令行友好后者图形界面更直观。如果你只是想快速看Fiddler 也行。选 mitmproxy 的理由很简单它能解密 HTTPS 流量需要你信任它的根证书并且可以用脚本过滤、导出请求体方便我批量分析。Charles 的优势是界面好看适合不熟悉命令行的朋友。注意抓包会解密你自己的网络流量请只在自己的设备和自己的账号上操作不要用于分析他人流量。另外务必在测试环境或非敏感项目上做验证别拿公司核心代码去试。安装 mitmproxy 很简单pip install mitmproxy mitmproxy # 启动交互式界面 # 或者用 mitmweb 启动网页版界面 mitmweb启动后默认监听 8080 端口你需要把系统或编辑器的代理指向127.0.0.1:8080然后安装并信任 mitmproxy 的根证书才能解密 HTTPS。3.2 关键操作过滤出真正相关的请求一开抓包你会发现流量多得吓人大部分是遥测、更新检查、CDN 请求跟代码无关。所以第一步是过滤。我的做法是先按域名过滤找到 ZCode 实际调用的 API 域名通常是智谱的 API 端点然后只看发往这个域名的 POST 请求。在 mitmproxy 里可以按~u 域名关键词过滤或者直接在界面上搜。找到目标请求后重点看三样东西请求体Request Body里面到底有没有你的代码有多少是片段还是整文件。请求头Headers有没有带 token、有没有标识用户身份。传输协议是不是 HTTPS证书正不正常。我实测时发现补全请求的 body 里主要是光标附近的代码片段加上一些元信息符合预期。但在触发 Agent 任务时body 明显变大包含的文件内容更多。这个差异就是判断是否超出必要的关键依据。3.3 怎么判断传得合不合理抓到数据后别急着下结论先问自己三个问题第一传的内容是不是完成这个功能所必需的如果我只是让它补全一行它却把我的整个文件甚至多个文件都传了那就不合理。如果我在用 Agent 做全项目重构它读多个文件就是合理的。第二有没有传和功能无关的敏感信息比如.env文件、密钥、内部 IP、数据库连接串。这些如果出现在请求体里就是严重问题因为补全或重构根本不需要它们。第三传输和存储有没有保护HTTPS 是底线如果发现是明文 HTTP那直接一票否决。我个人的判断标准是功能必要 最小范围 加密传输 可关闭四条都满足我才会放心用。缺任何一条我都会谨慎尤其是涉及公司项目时。3.4 一个容易被忽略的点遥测数据很多人只盯着代码有没有传却忽略了遥测Telemetry。编辑器为了改进产品通常会收集你的使用行为你点了哪些按钮、用了什么功能、报了什么错、甚至你的操作系统和硬件信息。这些数据单看不算敏感但组合起来能勾勒出你的工作习惯甚至推断出你在做什么类型的项目。抓包时记得把这类请求也翻一翻。如果发现遥测里夹带了文件路径、项目名这类信息那就值得警惕了。好消息是大部分正规工具都提供了关闭遥测的选项你可以在设置里找找或者用抓包确认关闭后是否真的不再发送。4. 官方回应里没回答的事逐条拆解4.1 回应说了什么又回避了什么风波起来后官方发了说明大意是数据传输是加密的、是为了提供服务的必要环节、不会滥用用户数据。这些话本身没毛病但信息量偏低几个开发者最关心的问题没有正面回答具体传了哪些字段是片段还是整文件数据在服务端存多久用完即删还是留档会不会用于模型训练如果会能不能 opt-outAgent 模式下读取文件的范围边界在哪有没有提供完全本地/离线模式这些不是刁难而是任何一个要接入企业开发流程的工具都必须回答的问题。我见过太多团队在选型时就因为供应商答不上这几个问题而直接放弃。含糊的回应在安全这件事上等于负面信号。4.2 加密传输不等于数据安全这是最容易被误解的一点。官方强调传输加密很多人就放心了。但传输加密HTTPS只保证数据在路上不被第三方偷看它管不了数据到了服务器之后发生什么。打个比方你把信装进保险箱寄出去路上确实没人能打开。但收信的人拿到保险箱后是看完就烧还是复印一份存档还是拿去当教材这跟保险箱没关系。传输加密解决的是路上的问题解决不了终点的问题。所以当厂商只强调加密时你应该追问的是服务端的数据处理策略日志保留多久、是否脱敏、是否用于训练、有没有第三方共享。这些才是决定你代码安不安全的核心。4.3 用户知情权和选择权才是关键说到底这次风波最伤的不是传了代码而是用户事先不知道。如果 ZCode 在首次使用时弹一个清晰的说明为了让 AI 理解你的项目Agent 模式会读取相关文件并发送到云端处理你可以在设置里限制范围或关闭那大部分争议根本不会发生。安全领域有个基本原则叫知情同意。用户不怕你收集数据怕的是你偷偷收集。一旦用户觉得我被蒙在鼓里信任就崩了而且很难修复。这也是为什么我在评估任何 AI 工具时第一件事就是翻它的隐私设置和文档看它敢不敢把数据行为写清楚。5. 给不同角色的实操建议5.1 个人开发者怎么用才不慌如果你是自己写 side project风险相对可控但也不能完全放飞。我的建议是敏感项目隔离涉及密钥、支付、用户数据的项目别用云端 AI 工具或者至少别开 Agent 模式。善用.gitignore思维把.env、密钥文件、配置文件排除在 AI 可读范围外如果工具支持配置忽略规则。定期抓包自查换版本、换配置后抓一次确认行为没变。关掉不必要的遥测能关就关减少数据面。我自己的习惯是学习、写 demo、写工具脚本时随便用一旦涉及真实业务逻辑就切回本地模型或者干脆手写。这不是不信任某个工具而是风险分级管理。5.2 企业团队接入前必须问清的清单企业场景下代码就是资产必须更严格。我整理了一份接入前的核查清单可以直接拿去问供应商核查项要问的问题合格标准数据范围Agent 模式读取哪些文件有明确边界可配置传输安全是否全程 HTTPS/TLS必须是存储策略服务端保留多久明确期限最好用完即删训练用途是否用于模型训练可 opt-out最好默认不用于训练部署方式是否支持私有化/本地部署敏感团队必须有此选项审计能力能否查看数据流向日志有则加分合规资质有无相关安全认证有则加分这份清单不是走形式每一条都对应真实的风险。尤其是私有化部署和训练用途这两条往往是企业能不能用的决定性因素。5.3 选型对比ZCode、Trae、WorkBuddy 怎么选热词里有人问zcode、workbuddy、trae work 开发软件哪个更好用。我的看法是没有绝对最好只有适不适合你的场景。ZCode中文语境和智谱生态是优势接入 GLM 方便适合已经在用智谱 API 的团队。但这次风波说明它的数据策略需要你额外确认。Trae字节系产品界面和交互做得比较顺适合追求开箱即用的开发者。WorkBuddy 类工具更偏团队协作和任务管理方向适合需要把 AI 嵌入工作流的团队。选型的核心不是比功能列表而是比数据策略是否透明、是否匹配你的敏感度。功能再强如果数据行为说不清对企业来说就是不可用。6. 常见问题与避坑心得6.1 高频疑问速查问AI 编辑器传代码是不是违法的答只要在用户协议里告知并获得同意通常不违法。争议点在于告知是否充分、范围是否合理。这是产品伦理和信任问题不只是法律问题。问我关了 Agent 模式就安全了吗答不一定。补全和对话模式也会传数据只是范围小。要彻底安全得用本地模型或完全离线的方案。问抓包看到代码片段被传是不是就说明它偷答要看是否超出功能必要范围。补全传光标附近片段是合理的传整个项目就不合理。关键看边界。问企业能不能用这类工具答能但前提是数据策略透明、支持私有化或可配置忽略规则、有合规资质。否则建议只用于非核心项目。问怎么知道数据有没有被用于训练答看隐私政策找 opt-out 选项必要时直接问供应商要书面说明。含糊其辞的默认按会用于训练来防范。6.2 我踩过的坑和总结的经验第一个坑以为关了某个开关就万事大吉。有次我关了改进产品的选项抓包发现还有另一路遥测在跑。后来才明白很多工具有多个数据开关得逐个确认。教训是别信开关的名字信抓包的结果。第二个坑在敏感项目上偷懒。有次赶进度直接在一个含密钥的项目里开了 Agent 重构事后想想后背发凉。虽然没出事但这个习惯很危险。现在我给自己定了死规矩含密钥、含用户数据的项目一律不用云端 AI 的 Agent 模式。第三个坑只看官方文档就下结论。文档写的是理想情况实际行为可能因为版本、配置、网络环境而不同。验证永远大于相信尤其是安全相关的事。6.3 一个实用的自查流程最后分享一套我常用的自查流程五步走装工具mitmproxy 或 Charles配好证书。跑场景分别测试补全、对话、Agent 三种模式。抓请求过滤出 API 域名导出请求体。看内容检查有没有敏感信息、范围是否合理。做决策根据结果决定用不用、怎么用、要不要隔离。这套流程花不了半小时但能让你对自己的数据流向心里有数。在这个 AI 工具满天飞的时代会验证的人才不会被工具牵着走。说到底ZCode 这次风波给整个行业提了个醒AI 编程工具的能力越强数据边界就越需要被认真对待。厂商要把话说清楚用户要把工具用明白。工具本身没有原罪但透明和选择权一个都不能少。