来给 Zcode 道歉了先说结论我之前在社区里跟风骂过 Zcode说它偷偷打包用户代码往阿里 OSS 上传是“偷代码”的流氓软件。后来我自己花了两天时间把网络抓包、日志目录、权限设置翻了个底朝天又拿一个小项目从头到尾实测了一遍才发现事情比我想象的复杂得多——或者说我当初对它的误解比它本身的问题还要多。Zcode 是智谱推出的 AI 编程助手跑在终端里主要靠 GLM 系列模型帮你读代码、改代码、跑命令。它能直接接管你当前的项目目录理解整个工程结构然后按你的指令生成修改方案并落地到文件里。这东西跟 WorkBuddy、Trae 这类图形化的 AI 编辑器完全是两条路更像是一个“住在终端里的结对程序员”。但正因为它的工作方式涉及读取和回写你的真实代码文件才引发了后来那一场“偷传代码”的风波。如果你也在用或者打算用 Zcode或者你只是好奇那个“偷代码”的瓜到底怎么回事这篇就把我踩过的坑、排查的过程、实测的结果和最终的安全配置建议一并写清楚。里面没有任何维护谁的意思就是把我亲眼看、亲手测、亲身体会的东西列出来你自己判断。1. “偷代码”风波到底是怎么闹起来的1.1 最初的传言是怎么来的那段时间各个技术群里都在转发一张截图说是有人在抓包的时候看到 Zcode 把整个项目目录做成了压缩包往阿里云的 OSS 地址上传。再加上“智谱 Zcode 被曝出重大漏洞”这种标题一出来很多人的第一反应就是完了这工具在偷源码。我当时也没细看直接在朋友圈转了相关讨论还补了一句“国产 AI 工具慎用”。现在回想起来这是我犯的第一个错误——看到标题就下结论没有去验证。做技术的最忌讳的就是把“听起来很合理”当成“事实”。而事实上那条传播很广的截图只显示了上传行为没有解释上传的是什么东西、什么时机触发、什么条件允许。信息不完整判断就一定是片面的。1.2 我实测后看到的真实情况为了搞清楚问题我准备了一个只包含公开 demo 项目的测试环境里面放了一些无价值的示例代码。然后我打开 Zcode 的日志目录配合抓包工具开始逐步操作。先说结论Zcode 确实有把代码文件打包上传的行为这一点没得洗。但关键要看触发条件。我新建会话只问“这个项目是干什么的”没有产生上传。我让它“梳理一下整个项目的架构”此时产生了上传。我让它“帮我分析这段代码的依赖关系”同样产生了上传。我如果只是让它“把某个文件的某个函数改一下”有时上传的是单个文件有时是整个目录快照。从触发行为来看只要指令明确涉及“整个项目”“全局梳理”“架构分析”“跨文件排查”工具就需要把相关代码上下文送到云端模型去推理。这和 Cursor、Copilot 之类的 AI 编程工具其实没有本质区别——本地模型跑不动的时候云上处理就必须把上下文发出去。问题在于Zcode 在打包上传时没有给用户足够明显的提示也没有在界面上清楚地说明“你现在这条命令会触发全项目代码上传”这才是引发信任危机的真正原因。1.3 那阿里 OSS 是怎么回事上传目标指向阿里云 OSS这件事也让很多人觉得是“偷偷传到第三方”。我查了一下发现智谱本身使用了阿里云的基础设施服务OSS 其实就是它云端服务的存储层。也就是说数据经过 OSS 中转但服务方是智谱不是某个不知名的第三方。这个解释不能完全消除担心——毕竟代码确实离开了本地——但它至少说明这不是一次恶意散播而是业务架构上的选择。我个人的看法是你可以因为“数据合规”或“代码隐私”的理由不用它这完全合理。但“偷代码”这个指控需要在了解技术细节之后重新审视。工具明确提供的能力是“读取你的代码并基于云端 AI 做分析”用户主动发起相关指令时上传行为是功能的一部分不是常驻后台的窃取。至少在我两天的实测中没有发现任何在空闲状态下主动上传的情况。2. Zcode 到底是个什么东西跟同类工具有什么差别2.1 终端里跑靠 CLI 驱动Zcode 的形态是命令行工具这跟很多人熟悉的 AI 编程工具很不一样。WorkBuddy 是给项目配置一个 AI 工作流面板Trae 是把 AI 能力嵌入编辑器界面而 Zcode 是直接让你在终端里和 Agent 对话。用起来大概是这种感觉你在项目根目录打开终端输入zcode进入交互模式然后像跟人聊天一样说“帮我把config.py里的数据库连接改成从环境变量读取”它会先分析相关文件给出修改方案再直接改文件。如果你允许它执行命令它还能自己跑测试、看报错、再修代码形成闭环。这种形态的优点是你不需要切换工具Git 流程、测试命令、构建脚本全在终端里完成Agent 能看到完整的命令行输出排查问题更直接。缺点也明显上手门槛高一点而且 GUI 里那种“哪里不对点哪里”的直觉操作它没有你得学会用自然语言准确描述需求。2.2 和 WorkBuddy、Trae 怎么选这三个工具我都试过简单说下各自的使用场景方便你判断。Zcode适合已经习惯终端工作流、项目以代码逻辑复杂度为主的人。它能修改现有项目代码能跨文件重构能直接跑命令验证结果自动化程度非常高。缺点是配置项不算少而且涉及全局分析时云端上下文传输量较大。WorkBuddy更像一个项目管理器它把任务拆解成工作流适合团队协作场景比如你给它一个大需求它帮你把任务列表、验收条件、关联文件都拆好。单个文件的编码能力不如 Zcode 直接。Trae编辑器形态的 AI IDE适合从传统 IDE 过渡过来的开发者界面友好调试体验直观但批量重构、终端内自动执行这类能力相对弱一些。我的建议是不要问“哪个更好”而是问“哪个更匹配你当前的工作方式”。你天天在 Vim 和终端里干活选 Zcode 会很顺你习惯 JetBrains 系 IDE 的可视化调试Trae 更自然你做项目规划和任务拆解多WorkBuddy 的场景更对口。三选一之前先把你自己的开发流程画一遍答案就出来了。2.3 它解决的核心问题市面上 AI 编程工具很多但大部分停留在“代码补全”和“代码问答”层面。Zcode 的东西是“代码操作”——它不只是告诉你代码怎么改而是真的去改。我拿一个老项目做过一次测试那是一个三年前写的 Django 项目我想把原来用 Celery 做的异步任务全部迁移到 RQ。Zcode 先是梳理了所有用到 Celery 的地方然后逐个文件生成迁移方案改动跨度涉及十几个文件。这种事如果我自己手动做至少一个下午它把方案跑完并改完第一轮只用了二十多分钟。虽然后续我还需要自己 review 和微调但那种“从我自己动手变成我检查它动手”的体验确实是传统工具给不了的。3. 注册、安装、配置一步步说清楚3.1 注册与获取 API TokenZcode 的账号体系挂在智谱的平台上。你需要先注册一个智谱开放平台的账号然后在控制台里创建 API Key。这个 Key 就是 Zcode 调用模型时的凭证重要性等同于你的密码别提交到 Git 仓库别写在项目成员共享的配置文件里。注册流程不复杂进官网用手机号或邮箱注册登录后到控制台找 API Key 管理生成一个以特定前缀开头的密钥。新用户通常能拿到一些免费额度或 token具体送多少会根据平台活动变动我当时注册时是送了一批体验 token够我下面做测试用。你拿到 Key 之后在终端里执行zcode login或者通过环境变量配置ZHIPU_API_KEY就能把本地工具和云端账号关联起来。3.2 安装 Zcode CLI安装方式非常标准如果你机器上有 Node.js 环境一条命令就能装好npm install -g zhipu/zcode装完执行zcode --version看到版本号就说明安装成功了。如果你用的是 macOS 且之前装过其他全局 Node 包可能有权限问题加sudo就能解决。Windows 用户建议直接用官方提供的安装脚本PowerShell 里跑一遍比手动配环境变量省事。Zcode 对 Node 版本有要求建议用 18 或 20 的 LTS 版本太老的版本可能会报一些奇怪的依赖错误。安装完记得看一下配置文件目录在 Linux 和 macOS 上是~/.zcode/Windows 上在用户目录下的.zcode文件夹。配置文件里可以设置默认模型、API Base、超时时间等。我建议首次使用前先把日志级别调成 debug这样一旦后面出现“重新连接中”的问题你能看到具体的报错原因。3.3 首次连接与常见启动报错首次运行zcode它会先要求你登录然后初始化一个 workspace。这里我遇到过一个常见问题终端卡在“重新连接中”的状态反复重试也进不去。排查方法很简单先看配置里的 Base URL 是不是默认的智谱官方地址再看本机网络环境有没有限制外部 WebSocket 连接。我当时就是因为公司内网把非 80/443 端口的 WebSocket 握手给拦了换成个人网络后秒连。如果你用的是代理工具记得给 Zcode 的进程配置代理环境变量否则可能出现连接不稳定。注意我说的代理是国内网络访问国内服务的常规配置方式不涉及任何特殊工具。另一种常见情况是 API Key 填错了或者 Key 在平台端被重置了这种时候直接重新生成 Key 就能解决。4. 核心功能实操Skill 怎么选、CLI 怎么用、现有代码怎么改4.1 Skill 到底是什么Skill 是 Zcode 里一个很重要但很多人没搞明白的概念。我一开始也困惑“添加什么 skill 好”后来才理解你可以把 Skill 理解成给 Agent 准备的“岗位说明书”——你把某个领域的分析框架、检查清单、输出规范写进 Skill 里以后每次触发相关任务时Agent 就会自动带上这些指令行为方式会明显更专业。举个例子你写一个python-review.md的 Skill里面规定代码审查时必须关注安全漏洞、异常处理、性能热点并强制输出“问题严重程度-建议修复方案-预估影响范围”三段式报告。之后你让 Zcode 审查代码时它就不再只是杂乱地列几条建议而是按你的格式输出结构化的审查结果。网上有些人分享了很多现成的 Skill 文件可以直接导入使用。我自己的经验是最开始不用贪多先加这三个就够日常用了一个通用的代码审查 Skill覆盖安全、性能、可读性三类检查项一个项目梳理 Skill规定它分析项目架构时先输出目录树再标注关键模块职责一个测试生成 Skill规定它生成的单测必须覆盖正常路径、异常路径和边界值Skill 的格式一般是 Markdown里面可以包含指令、案例、输出模板。写好之后放到~/.zcode/skills/目录下在会话里用/skill命令就能切换启用。我踩过的一个坑是Skill 文件里写了太多限制性词汇结果它每次都先拒绝回答问题说“根据我的规则我不能执行这个操作”。后来把规则改成建议性的“请优先考虑”“如果没有特殊情况”情况就好多了。4.2 CLI 高频命令手册Zcode 的 CLI 命令不算多但每个都很重要。抛开login、logout、config这些基础命令我最常用的是下面几个zcode不带参数进入交互式对话模式大部分工作都在这里完成zcode run 自然语言指令直接让 Agent 执行一次性任务适合写进自动化脚本zcode status查看当前会话的连接状态、模型配置、已加载的 Skillzcode chat --continue继续上一次的会话上下文断线或退出后再回来很有用run这个子命令我强烈建议你试试它能让你把 Zcode 接进自己的工具链。比如我有一个脚本专门负责发布前的代码自检里面会调用zcode run 检查 src 目录下所有文件中的调试残留输出风险说明然后脚本再把输出写入审查报告。这就是把 AI 能力封装成流水线节点的玩法熟练之后能省不小的工作量。4.3 如何修改现有项目代码这是 Zcode 最强的能力也是隐私问题最集中的地方。它的工作方式是先分析现有代码再给出修改方案最后直接写入文件。我在实操中总结了一套比较稳的流程分享给你。第一步先让它“只分析不改”。我会明确说“先梳理src/auth目录下的逻辑输出当前实现的问题清单不要修改任何文件。”这样你可以在它动手之前判断它的理解是否准确。如果它的分析方向就错了让它直接改只会越改越乱。第二步确认方案后再让它改。比如我说“按上面第 2、3 条建议修改保持接口签名不变原有注释保留”。加上这些约束条件能极大减少它改动过度的问题。Zcode 对中文指令的理解已经很好了你完全可以用自然语言把边界说清楚。第三步用 Git 兜底。每次让它改动前确保工作区是干净的提交一次“AI 修改前快照”。改完以后git diff快速过一遍所有变化。这一步绝对不能省再聪明的模型也有手滑的时候版本控制就是最后一道防线。4.4 Union Alpha 怎么配置进去有人问 Union Alpha 怎么配到 Zcode 里。Union Alpha 本身是基于 Zhipu 生态的能力集合如果你要在 Zcode 里挂载 Alpha 相关的插件或调用思路其实和配置 Skill 一样。先去 Union Alpha 平台把相应的能力 Key 和配置参数拿下来然后在 Zcode 的配置文件中增加对应的alpha配置段把 Key 填进去最后用/load alpha命令加载验证。坦白说这类第三方能力接入各家平台时的配置方式差异不小我没办法给你一个全网通用的配置代码但排查思路是通用的先确认 Key 是否有效再确认配置文件里的 Key 名是否和文档一致最后看日志里有没有鉴权失败的错误。能走到鉴权失败这一步说明网络通了剩下就是配置项的名称和格式问题。5. 实测“上传行为”什么会被传、怎么控制、怎么避坑5.1 完整实测记录我在一个模拟项目里放了三种文件普通业务代码、包含假密钥的配置文件、包含隐私说明的文档。然后我分四种场景观察上传行为。场景一只聊编程理论不涉及项目内容全程无上传。场景二让它分析单个文件抓包显示只上传了那一个文件的内容。场景三让它分析模块依赖关系上传了相关目录里的多个文件但日志和文档没动。场景四我明确做了排除设置在配置文件里加上.env和private/的忽略规则然后再次让它全项目分析这次私密目录里的文件没有出现在上传清单里。这个实测说明了三件事。第一上传行为跟你的指令意图强相关不是后台常驻扫描。第二忽略规则对控制上传范围是有效的。第三隐私保护这件事工具提供了手段但主动配置的责任在你自己。5.2 配置忽略规则的正确姿势Zcode 支持类似.gitignore的忽略机制在项目根目录创建一个.zcodeignore就能生效。我的建议是至少把下面这些内容加进去所有环境变量文件.env、.env.production等密钥和凭证目录secrets/、keys/构建产物和依赖目录node_modules/、dist/、build/任何你不想离开本机的敏感文件路径关于忽略规则的匹配逻辑我实测下来发现它用的是 glob 语法也就是说*.pem这种后缀匹配是生效的但如果你写private而不是private/效果会有差异。保险起见路径和目录都写一遍再通过抓包确认自己的排除规则确实生效不要盲目相信某个帖子里的配置模板。另外你可以把默认模型切成智谱的本地部署版或者把 API Base 指向私有化部署的服务端。这样代码处理链路完全在你自己的基础设施里从根本上消除数据离场的问题。这个配置方式适合企业客户个人用户直接用默认云端服务加忽略规则就够了。5.3 “重新连接中”反复出现的维修思路这个提示是我被问到最多的问题之一。出现“重新连接中”本质是前端连接被中断或者握手超时。我遇到过的原因有几种一是 API Key 过期重新登录就好。二是网络波动导致 WebSocket 断连一般是隔几秒自动重连如果一直连不上就检查网络。三是配置文件里的模型名写错了导致服务端拒绝建立会话这种会在日志里看到model not found之类的报错。如果重试多次依然卡住执行zcode config --reset重置配置再登录多半能恢复。这个过程不会删除你本地的项目文件只会清掉工具的本地状态所以可以放心操作。真到了这一步还不行就带着 debug 日志去官方仓库提 issue把时间戳和报错贴全维护者一般都能给出准确定位。6. 常见问题与避坑笔记6.1 问题速查表我把这段时间在社区里看到的、以及自己遇到的高频问题整理成一个速查表你可以直接对照处理。问题现象根本原因解决办法安装时报依赖错误Node 版本过低升级到 Node 18 或 20 LTS登录后一直“重新连接中”网络限制或 Key 异常检查网络环境重新生成 Key提示模型不存在配置文件里模型名写错对照官方文档填写精确模型名修改代码时改动范围过大指令约束不够明确指定文件、明确保留条件Skill 不生效Skill 文件放错目录或格式错误放到~/.zcode/skills/确认是 Markdown 文件上传范围超出预期未配置忽略规则创建.zcodeignore抓包验证效果会话上下文丢失会话超时或手动中断用zcode chat --continue恢复免费 token 用完了额度用完控制台查看用量按需充值或等重置6.2 几条独家避坑心得我用了这段时间之后有几个比较深的体会写出来供你参考。第一永远先让 AI 说方案再让它动手。很多翻车案例的共同点是用户直接说“把 XX 改了”然后 Agent 一顿操作结果把无关代码也顺手重构了。让 Agent 先输出分析报告你审核过再执行即便多花一轮对话时间也远比返工划算。第二用 Git 管理 AI 的每一次改动。我见过有人用 Zcode 一晚上改了三个模块第二天发现新需求跟改动冲突了但所有修改都混在一起没法回退。正确做法是每让 AI 完成一个独立任务就本地提交一次commit message 里标注“AI: xxx”这样任何一次改动出问题都能精确回退。第三隐私不能靠工具自觉要靠配置兜底。你把.zcodeignore配好比骂一万句“偷代码”都有用。这就像你不会把保险柜密码贴在墙上然后再怪路过的人偷看你家。工具提供了忽略机制用不用是你自己的选择。我在实测中确认忽略规则有效之后才敢把 Zcode 用在稍微敏感一点的项目里。6.3 免费额度够不够用很多人关心免费 token 的问题。我的实测感受是日常问答和单文件修改额度消耗不快但全项目分析、大仓库梳理这种任务消耗很猛。一次大型重构任务可能烧掉你一周的免费额度。省钱的办法是把大任务拆小或者优先用更小的模型处理简单问题复杂问题再切到强模型。另外团队协作的话建议各人用自己的 Key共用一个 Key 不仅额度分散不明确而且一旦 Key 泄露整个团队的项目都暴露了。7. 最后补一句掏心窝的话写到这里我想认真说一句我之前错了错在没验证就下结论。Zcode 的上传行为确实存在但是否构成“偷”取决于你如何看待“用户在指令中主动触发的云端推理”和“默认上传用户代码”之间的边界。作为用户我仍然希望 Zcode 团队能把这些数据行为在界面上做得更透明比如每次即将上传项目快照前给出明确提示。但在那之前我至少可以做好自己能控制的事——把忽略规则配好把敏感目录隔离好把每次修改纳入 Git 管理。如果你之前也因为“偷代码”的说法把它卸载了我建议你自己花一个小时实测一遍用抓包工具看看到底什么在上传、什么情况下触发、忽略规则是否有效。做完这轮验证你可能也会像我一样对这个工具的信任程度发生改变。那次全项目梳理任务它用二十分钟帮我整理完一个三年前老项目的完整依赖关系图时我是真心觉得差点错过一个趁手的工具。
