上周末我照例在睡前刷了一遍开发者社区发现一个帖子被顶到了首页有人用抓包工具监控了智谱 ZCode 的网络请求发现这个 AI 编程插件在未弹窗、未提示的情况下把当前仓库的 Git 历史打包上传了。评论区从是不是看错了迅速滑向偷代码实锤紧接着zcode 偷传代码zcode 被曝出重大漏洞这类关键词开始霸榜。整个事件从发酵到官方侧面回应大约持续了 48 小时。我一开始觉得这事有点夸张——毕竟 ZCode 是智谱旗下主打免费的 AI 编程助手官方宣传里写的是代码补全、对话式问答、Skill 扩展这类常规功能按理说不应该去碰 Git 历史这种敏感数据。但当我花了一个通宵把社区帖子、流量截图、复现步骤挨个看下来又在自己机器上做了同样的实验之后我发现问题比偷不偷代码更值得讨论AI 编程插件的权限边界在哪里一个看似正常的替你分析项目的功能为什么会变成静默上传 Git 历史的信任危机这篇文章我不打算做情绪输出而是围绕这次事件做个完整复盘——还原 ZCode 是什么、技术上是如何触发静默上传的、作为普通开发者该怎么自检、以及往后选型和配置 AI 编程工具时怎么避开同类风险。整个过程会带上我从实际排查中拿到的细节和踩过的坑希望能给你一套能直接落地的判断方法。1. 事件全貌从抓到一条上传记录到偷代码标签的 48 小时1.1 先搞清楚 ZCode 是谁智谱 ZCode社区里一般叫 zcode是智谱 AI 推出的编程助手以 VS Code 插件的形式存在也支持部分国内主流的 IDE 客户端。它的核心卖点有三个一是基于 GLM 大模型做行级补全和自然语言对话二是免费开放三是允许你通过Skill给助手挂载自定义指令让它按照团队规范生成代码。这类工具的逻辑其实和 GitHub Copilot、通义灵码、CodeGeeX 差不多插件在本地读取当前打开的文件内容作为上下文发送到云端模型做推理然后把补全候选返回编辑器。问题是读取当前文件和读取整个仓库的 Git 历史之间隔着一条绝大多数开发者默认存在、但产品文档里往往不会写清楚的线。ZCode 这次翻车就是因为用户发现它越过了这条线。1.2 爆料起点一次抓包引出的上传记录事件最早可追溯到某位开发者在更新插件后顺手开了一个 HTTP 调试代理想看插件到底在跑什么。结果他发现ZCode 在正常代码补全之外额外往智谱的接口发送了一批包含git log、git remote -v、git config输出内容的请求。请求体里不仅有仓库名、远程仓库 URL还有一串提交历史记录——包括每个提交的 hash、作者名、作者邮箱、提交时间、提交说明。这个发现之所以引爆社区在于两个细节第一整个上传过程没有任何 UI 弹窗或授权提示用户在 IDE 里只看到插件照常工作第二即便从功能角度解释Git 历史也明显超出了补全当前代码所需要的最小上下文。于是各路帖子迅速汇集有人贴出了复现步骤有人统计了数据包里的字段zcode 偷代码这个标签就这么被焊死了。1.3 舆论发酵与官方回应的 48 小时窗口从社区爆料到智谱方面发布说明前后大约 48 小时。这 48 小时里热搜词从zcode 偷传代码风波再起一路覆盖到zcode 偷代码zcode 使用教程不少原本准备下载插件的新用户直接被劝退已经在用的老用户则开始翻日志、查权限。官方回应的大意是该行为与数据分析、个性化服务相关会调整默认策略并后续提供开关。但如果你认真观察评论区会发现开发者真正在意的已经不是这次传了什么而是你凭什么不问我就传、以及你以后还会传什么。这里我说句公道话把静默上传 Git 历史直接等同于偷代码在措辞上有些滑向情绪化。代码内容本身是否被上传、上传后如何使用目前没有足够证据做定论。但未经明确授权就收集远超功能需求的敏感数据这件事无论从隐私合规还是产品伦理角度都站不住脚。这也是整个事件最核心的争议点。2. 技术拆解一个 IDE 插件是怎么把 Git 历史带出去的2.1 权限模型插件能碰到的东西比你想象的多要理解静默上传为什么能发生得先看 IDE 插件的能力边界。以 VS Code 为例一个扩展只要被安装并激活就天然拥有以下权限读取工作区内的文件内容、执行任意子进程包括调用git、监听编辑器事件、发起任意 HTTP 请求。这些都被封装在扩展 API 里目的是让插件实现各种自动化功能但也意味着插件本质上等同于一个拿到你仓库钥匙的临时员工。用个生活类比你在正规软件里点允许访问相册系统会弹窗问你同不同意但 IDE 插件没有这种细粒度授权弹窗它更像是一个入职当天就拿到你电脑所有文件的实习生——工作规定上说他只能看项目文档但技术上他完全能打开你的聊天记录备份而且这件事可能在很长一段时间里都没人发现。ZCode 上传 Git 历史走的就是这条技术允许、制度模糊的路径。2.2 关键动作还原git log、git remote、git config根据多方帖子和技术推测ZCode 触发 Git 历史收集的动作大致包含三类命令git log --format...拿提交列表。输出里带 commit id、作者、邮箱、提交时间、提交说明。git remote -v拿远程仓库地址。这一步能暴露你用的是 GitHub、GitLab 还是自建 Git 服务甚至包括私有服务的域名。git config --list拿用户配置。真实姓名、邮箱、以及可能存在的代理配置信息。这些命令的产物被拼装成 JSON在某个生命周期钩子触发时随普通补全请求一起发出。由于请求体和正常的 AI 推理请求共用一个接口域名如果不去逐个字段检查很容易被当成常规遥测忽略掉。我复现了一个简易版本的流程逻辑大致如下git log --prettyformat:{%n commit: %H,%n author: %an,%n email: %ae,%n date: %aI,%n message: %s%n}, -n 200 git remote -v git config --list然后把三个命令的标准输出拼接为 JSON 数组POST 到服务端。整个过程只在内存里完成字符串拼接不需要落盘因此常规的本地文件监控很难察觉你只会看到一条看起来人畜无害的 HTTPS 请求。2.3 为什么 Git 历史比源码本身更值钱很多不写代码的朋友可能不理解代码被上传固然严重但 Git 历史里到底藏了什么值得开发者如此紧张答案藏在元数据里。源码是一个项目的成品表象而 Git 历史是项目的完整病例档案。举个例子一次 commit 可能写着修复凌晨促销链路崩溃的临时方案这个提交说明会暴露你们的业务节奏和应急水平作者邮箱能定位到具体员工频繁的深夜提交能推测团队作息分支命名里的内部代号能反向推断产品规划。这些信息单独拿出来都不算出格拼在一起却足以形成一张精确的团队画像。更要命的是很多人在代码里能做好脱敏却习惯性忽略 Git 历史测试服务器地址、误提交的密钥、临时代码里写死的内部接口——他们可能后来在源码里删了但历史记录永远保留。换句话说Git 历史是一种删除不掉的敏感数据。正因如此一旦开发者发现插件在碰 Git 历史第一反应一定是拒绝而不是等你去解释我们只用来做仓库理解。3. 自查指南我怎么确认自己有没有被静默上传事到如今与其争论到底传了什么不如先花半小时确认自己的机器上有没有同类行为。下面是我实际用过的三条排查路径按成本从低到高排列。3.1 流量层验证让调试代理当你的第三只眼最直观的方式是在 IDE 和后端服务之间架一个 HTTP 调试代理。这类工具有很多常见的有 mitmproxy开源跨平台、Whistle国内开发者常用、CharlesmacOS/Windows 都支持。它们的原理都一样在本地起一个代理端口把 IDE 的 HTTP 请求引流过来然后用自签证书做 HTTPS 解密就能看到明文请求体。我以 mitmproxy 为例说一下步骤安装并启动代理pip install mitmproxy mitmproxy -p 8888设置系统代理指向127.0.0.1:8888。安装并信任 mitmproxy 的 CA 证书确保 HTTPS 能被解密。在 VS Code 配置里把代理指过来{ http.proxy: http://127.0.0.1:8888, http.proxyStrictSSL: false }重启 IDE随便打开一个仓库文件触发一次自动补全或对话然后回到 mitmproxy 的交互界面按i过滤请求域名把包含 ZCode 接口域的流量挑出来看。重点看请求 Body 里有没有git_log、commits、authors、remote_url、git_config这类字段。如果看到就说明插件确实在做 Git 元数据收集。无论它后面接的是不是智谱服务器这种行为本身已经超出了补全当前文件的最小范围。3.2 进程层验证跟踪到底是谁在执行 git 命令网络层只能证明数据出去了要定位是谁把数据装进去的还得看进程行为。在一些操作系统上你可以用进程监控工具直接观察子进程创建记录。Windows 用 Process Monitor微软官方工具设置过滤条件为Process Namecode.exe再附加OperationProcess Create就能看到 IDE 启动的每一个子进程。如果发现git.exe被频繁调用且参数里带着all这种大范围选项就很可疑。macOS 用fs_usage不太方便按进程名筛选我推荐一个更普适的办法写一个临时的git包装脚本把它放到PATH最前面脚本里把收到的全部参数写入日志再调用真正的 git。#!/bin/bash echo $(date %Y-%m-%d %H:%M:%S) $ /tmp/git-audit.log /usr/bin/git $然后打开 IDE 正常使用半小时去翻/tmp/git-audit.log。如果 ZCode 真的触发了 Git 历史采集你会在日志里看到大量非用户手动发起的log、remote、config调用而且通常发生在打开仓库、切换分支、触发补全这些时间点附近。这个方案不依赖特定操作系统哪个平台都能用。3.3 插件层验证别忽略 VS Code 自己的日志很多人不知道VS Code 对扩展的输出日志有比较完整的管理。你可以通过帮助 - 切换开发人员工具 - Console打开开发者面板在Network标签页直接看到扩展发出的所有网络请求字段比调试代理更细。如果你不想装复杂的抓包工具这一招是最快的清空网络记录执行一次补全然后过滤 XHR/fetch 请求找出 POST 类型且域名指向智谱服务端的请求点击 Preview 展开请求体即可。另外VS Code 会把扩展的日志写到本地目录Windows 一般在%APPDATA%\Code\logsmacOS 在~/Library/Application Support/Code/logs。插件的console.log输出会被记录在对应的窗口日志文件里。搜索关键词git、upload、telemetry多少能看出些端倪。3.4 排查中的常见误判别把遥测当成罪证这里要泼一盆冷水不是所有出网请求都等于偷代码。很多 IDE 插件默认开启崩溃上报、匿名使用统计这些遥测数据通常只有事件名和设备 ID不包含仓库内容。如果你在抓包里看到请求去向但字段里只有eventactivation、duration123那大概率是常规遥测不属于静默上传 Git 历史。真正需要警惕的组合是三件事同时出现请求包含 Git 历史字段触发时机不是用户主动操作没有任何 UI 提示或开关说明。三者都满足才值得上升到信任危机的高度去处理。我在排查中就遇到过把接口名看岔、把别家插件的遥测误算到 ZCode 头上的情况所以建议你在下结论前务必把请求体完整展开逐字段核对。4. 边界与责任AI 编程工具的隐私底线在哪里4.1 工具方应该有的合规姿势知情、最小化、可控事件发酵后很多做 AI 工具的朋友问我对产品有什么建议。我的答案包含三个原则。第一知情。如果插件要读取 Git 历史、文件树、系统用户名应当在首次安装或激活时弹窗说明而不是藏在几千字的隐私政策里。很多产品怕多一步弹窗会降低转化率但事实是开发者对 IDE 插件的信任敏感度极高一次未经说明的收集行为造成的信任损失远大于弹窗带来的转化损失。第二最小化。要把当前打开文件的代码上下文和整个仓库的 Git 历史元数据严格区分。前者属于 AI 补全的合理上下文后者通常是仓库分析、成员画像类的功能需求不应该在补全场景里悄悄捎带。第三可控。至少要提供一个显眼的开关让用户关闭仓库分析类功能并且开关状态要真正生效。有些产品嘴上说关了但实际流量里还在传这种情况一旦被用户抓包抓到性质就从产品设计失误变成欺骗了。4.2 用户端自救方案在插件权限失控之前拦住它在工具厂商改进之前你可以先在本地把失控风险兜住。我试过几种方案按推荐程度排序代理黑白名单。在调试代理或系统代理里配置规则屏蔽特定请求域名。比如抓包发现 ZCode 上传接口是*.zhipuai.cn/api/xxx直接加一条规则让该域名请求返回空响应或超时。缺点是插件可能因此报错或功能异常适合你只想临时禁用某个接口时使用。最小权限工作区。把敏感仓库放在一个单独的目录里用 VS Code 的workspaceTrust机制对不被信任的文件夹禁用扩展。配合extensions配置可以把 ZCode 从该工作区的激活列表中剔除。网络沙箱。如果你对隐私要求非常高可以在 Docker 容器里跑 VS Code Server 或直接把整个 IDE 套一层沙箱用--netnone或仅允许白名单域名出网。这个方案对普通用户有点重但对处理客户源码的开发者来说很实用。对于企业环境我强烈建议把AI 编程插件选型纳入安全评审流程而不是让每个开发者自己装。因为一旦某个插件在全员机器上跑满一周Git 历史、源码主干、内部 API 域名这些核心资产就已经在外部服务器上存在过了。4.3 免费模式的代价羊毛出在谁身上还有一个绕不开的问题是这类插件为什么免费算力成本、研发成本都不是小数如果完全靠补贴商业模型很难持续。行业里的常见路数是用免费产品积累开发者数据反哺大模型训练或者通过数据分析优化体验后向企业端卖团队版收费。这两种模式本身不违法但问题的关键在于用户是否有知情权是否同意用自己的代码与元数据作为交换我个人的观点是开发者和 AI 工具之间可以存在用数据换便利的隐性交易但前提是交易条款必须摆在明面上。类似 ZCode 这次的做法——把交易藏在后台流量里被发现后才解释——哪怕数据的实际去向完全合法合规给人的观感也等同于背叛。别指望靠舆论平息来挽回信任信任这个东西在开发者社区里是有一次性和强记忆性的。5. 我踩过坑之后的实操配置可以直接抄作业5.1 选型时先问三个问题经历了这次事件我在给团队推荐任何 AI 编程工具之前都会先做一个小问卷三分钟就能完成这个插件有没有公开的数据收集说明里面是否明确写了会收集哪些信息、传到哪里、保留多久凡是答不上来的直接淘汰。它是开源的吗调用的模型 API 是否支持替换成自建或本地模型支持替换意味着你可以把流量导向自己控制的端点便于审计。能不能在不影响补全的情况下关闭仓库级分析如果产品设置里连禁用上传 Git 元数据这种开关都没有那它离翻车只差一次用户抓包。这三个问题能过滤掉大部分浑身埋雷的免费工具。我甚至建议把回答内容沉淀成表格发到团队文档里让每个人都清楚自己用的东西边界在哪。5.2 我目前在 VS Code 里的安全配置下面是我现在实机环境里的一部分配置针对隐私敏感型工作场景{ telemetry.telemetryLevel: off, extensions.ignoreRecommendations: true, workbench.trustedDomains: [], http.proxy: http://127.0.0.1:7890, http.proxyStrictSSL: false }这里解释一下每个字段的意图关闭遥测是基础操作很多插件会借口匿名统计夹带额外数据忽略推荐扩展是为了避免 IDE 悄悄安装未经评审的插件代理配置则让所有出网流量经过我自己的调试代理方便随时抽查。配合前文提到的 mitmproxy 过滤规则我现在能在 30 秒内回答刚才那个插件到底往外面发了什么。如果你不想全局走代理也可以在插件启动后单独抓包确认一轮确认无异常再把代理关掉。我建议至少每个月抽查一次尤其当插件更新大版本之后——很多行为变更恰恰是跟着版本更新来的。5.3 如果团队已经全员中招怎么紧急处理最后说一个很多人会遇到的现实场景公司已经全员安装了某款插件现在爆出静默上传作为负责人你怎么处理我的建议是分三步走。第一步立刻通知全员暂停使用但不要强制卸载避免开发者加班时找不到工具产生抵触情绪。第二步抽一台机器做流量审计把抓包结果和插件更新日志、官方回应放在一起比对快速判断问题的严重等级。这里的重点不是纠结是否恶意而是确认在当前版本、当前配置下是否还在上传。第三步给出替代方案。如果只是要代码补全可以切到开源方案或本地模型方案如果是冲着对话能力来的可以先用 Web 端来代替把 IDE 插件的权限先收回来。处理过程中有一个容易踩的坑不要只看官方最新声明要自己去抓一次包。因为很多插件存在灰度更新声明里说新版本已关闭可能你的机器还是旧版本或者配置没生效就被覆盖了。我见过不止一次团队因为过度信任官方公告结果审计时发现流量根本没断的案例。写在最后这次智谱 ZCode 事件我最大的收获不是学会了怎么抓包而是重新审视了自己对工具的态度。以前我总觉得插件装在 IDE 里就像笔放在桌上没想过笔尖会不会自己写字并寄出去。现在我的习惯是任何新工具进环境先花十分钟观察它的出网行为任何大版本更新翻一遍变更日志所有关键仓库要么走沙箱、要么走可控代理。我自己现在仍然在用 AI 编程工具毕竟补全和对话带来的效率提升是实打实的。但我会把默认不可信当成使用前提而不是等到热搜出现才知道自己机器上多了一条看不见的链路。也建议你下次准备安装某个免费 AI 插件之前先把它对 Git 历史的处理方式查清楚——这一分钟或许能帮你省掉一整个通宵的排查。
