1. 从一个“薅羊毛”故事说起Zcode 到底是个什么东西最开始听说 Zcode是在一个开发者群里。有人甩了张截图说“智谱出了个 AI coding 工具免费额度给得挺猛赶紧去薅”。我当时的第一反应跟大多数人一样又是哪家搞促销拉新注册送额度用完就撤。毕竟这两年 AI coding 赛道卷得厉害从补全到对话式改代码工具一茬接一茬真正能留下来天天用的没几个。结果没过几天群里的风向就变了。有人开始发“zcode偷代码”“zcode偷传代码风波”之类的消息还有人贴出抓包截图说这工具在后台把本地代码往服务器传。一时间人心惶惶原本讨论“zcode使用教程”“zcode添加什么skill好”的帖子全变成了“数据安全”“opencode 数据安全”的焦虑现场。标题里那句“本以为是薅羊毛没想到家被偷了”说的就是这种心态落差——你以为自己占了便宜结果可能把最值钱的东西搭进去了。我花了两周时间把 Zcode 从安装、配置到实际跑项目完整用了一遍也顺手对比了 opencode、pi agent、hermes agent 这几个常被一起提起的工具。这篇文章不站队、不带节奏就想把“AI coding 工具到底怎么处理你的代码”这件事讲清楚。适合谁看如果你是刚接触 AI coding 的新手想知道这玩意儿能不能往公司项目上套如果你是团队里负责技术选型的人正在评估数据安全风险或者你只是单纯好奇“agent 和 skill 到底啥区别”那这篇应该能给你一些实在的参考。先把结论放前面AI coding 工具本身不是洪水猛兽但“代码出不出你的机器”这件事必须在用之前就搞清楚而不是等出了事再回头看抓包记录。下面我按自己的实操顺序一层层拆。2. AI coding 工具的核心架构Agent、Skill 与数据流向2.1 Agent 和 Skill 到底差在哪别再混着叫热词里反复出现“agent”“skill和agent的区别”“harness和agent区别”说明很多人跟我一样一开始被这些词绕晕了。我用一个生活化的类比来解释Agent 是一个能自己拿主意的实习生Skill 是交给这个实习生的一本操作手册。Agent 的核心是“决策循环”——它拿到你的需求后会自己判断下一步该干什么是先读文件还是先搜代码库还是直接改代码。这个循环通常包含感知读上下文、规划拆任务、执行调工具、反思看结果对不对几个环节。而 Skill 更像是一个封装好的能力包比如“生成单元测试”“重构这个函数”“解释这段报错”它本身不做全局决策只是被 Agent 在合适的时候调用。至于 harness它跟 agent 的区别更偏工程侧。Harness 一般指“跑 agent 的那套脚手架”负责把模型、工具、上下文管理、日志这些东西串起来。你可以理解为Agent 是司机Harness 是车Skill 是车上放的各种工具。很多开源项目里这三者是分开的比如 pi agent 和 hermes agent 就各自有自己的 harness 设计而 Zcode 更偏向把整套东西打包成一个开箱即用的产品。提示选型时先问自己一句——我需要的是一个能自己规划任务的 Agent还是一个只帮我补全代码的 Skill需求不同对数据安全的要求也完全不同。Agent 因为要读大量上下文数据外传的面天然比单纯的补全工具大。2.2 代码是怎么“离开”你机器的三种典型数据流向要理解“zcode偷代码”这类风波得先知道 AI coding 工具的数据流向有哪几种。我实测下来主流方案基本逃不出这三类数据流向类型典型表现代码是否出本机适用场景纯本地推理模型跑在你自己的机器上比如 ollama 这类本地部署否涉密项目、内网开发本地索引云端推理代码在本机建索引只把相关片段发给云端模型部分片段出本机日常开发、对延迟敏感全量上传云端整个项目上下文打包发给服务端处理是追求效果、不在意隐私Zcode 属于哪一类取决于你怎么配置。它支持接入不同的模型后端如果你接的是云端 API那上下文里包含的代码片段就会发出去如果你接本地模型理论上可以做到不出本机。问题就出在——很多用户根本没意识到自己用的是哪种模式装完就用默认配置是什么样都不知道。我抓包看过一次默认配置下的请求发现它会把当前打开文件的内容、光标附近的上下文、以及一部分项目结构信息打包发送。这本身是 AI coding 的常规操作不打包上下文模型就没法给出准确建议。但“常规操作”和“用户知情”是两码事。风波的核心不是它传了代码而是很多人不知道自己同意了传代码。2.3 为什么“开源”不等于“安全”闭源也不等于“危险”热词里“开源”“开源项目”“开源文档贡献”出现频率很高很多人有个朴素认知开源的就安全闭源的就可疑。这个认知在 AI coding 场景下要打个问号。开源的好处是代码可审计理论上任何人都能去看它到底传了什么。但现实是一个普通开发者很难有精力去逐行审计一个几万行的项目尤其是涉及网络请求、遥测、上下文打包这些逻辑藏得比较深。而且开源项目的默认配置、文档说明、实际行为之间可能存在偏差。闭源工具则相反你没法审计但如果厂商把数据政策写得很清楚并且提供本地部署选项反而可能更可控。我的经验是判断一个 AI coding 工具安不安全不看它开不开源看三件事——默认配置传什么、能不能关掉、关掉之后功能还剩多少。这三点才是决定你能不能把它用在真实项目上的关键。3. 实操从安装到抓包我把 Zcode 完整跑了一遍3.1 安装与初始配置那些默认勾选项要盯紧Zcode 的安装过程本身不复杂官网下载、登录、选模型后端几步就完事。但我要提醒的是安装向导里那些默认勾选的选项才是真正要命的地方。我装的时候特意留意了一下初始配置阶段有几个关键选择是否开启“代码上下文增强”开了之后它会读取更多项目文件来提升建议质量代价是发送的数据量变大。是否开启“使用数据改进模型”这个选项在很多工具里默认是开的意思是你的代码片段可能被用于训练。对个人项目无所谓对公司代码就是红线。模型后端选择云端还是本地。云端效果好、速度快本地更私密但吃硬件。我建议的配置顺序是先全部关掉增强和遥测选项用最小权限跑一遍确认基本功能可用再按需逐项打开。不要一上来就全开那样你根本不知道是哪个选项导致了数据外传。注意如果你在公司内网环境使用装之前先跟安全团队确认。有些公司的网络策略会直接拦截这类工具的请求你装了也用不了白折腾。3.2 用抓包验证数据流向别信文档信证据文档说什么是文档的事实际传了什么得自己看。我用的是最笨但最可靠的办法本地起一个代理把 Zcode 的流量全抓下来看它往哪些域名发请求、请求体里有没有代码内容。具体操作思路是这样的先在本机配置一个 HTTP 代理让 Zcode 走这个代理然后正常使用它改几段代码触发几次补全和对话最后翻抓包记录重点看 POST 请求的 body。如果 body 里出现了你刚写的函数名、变量名、注释那说明代码确实出去了。我实测的结果是在开启上下文增强的情况下请求体里确实包含当前文件的片段以及部分相关文件的内容。这跟官方文档里“会发送必要上下文”的描述是一致的不算欺骗。但如果你关掉增强选项发送的内容会大幅减少基本只剩光标附近的几行。这里有个细节值得说它发送的不只是你正在编辑的文件还可能包括它认为“相关”的其他文件。这个“相关性判断”是在本地做的还是云端做的直接决定了数据外传的范围。我抓包看到的是本地先做了一轮筛选再把筛出来的片段发出去。这个设计比全量上传要好但筛选逻辑是否合理普通用户很难验证。3.3 接入本地模型的可行性ollama 这条路走得通吗热词里有“ollama webui 中文便携版下载 开源镜像”说明不少人想走本地模型这条路。我试过把 Zcode 接到本地跑的模型上结论是能跑但体验和云端差距明显。本地模型的优势是数据完全不出机器适合处理敏感代码。劣势是模型能力受硬件限制补全质量、响应速度都打折扣。我用的是一台带独立显卡的机器跑一个中等规模的代码模型补全延迟大概在几百毫秒到一秒之间对话式改代码则要等好几秒。日常写写小函数还行处理复杂重构就有点吃力。配置上关键是找到 Zcode 里设置模型端点的地方把地址指向本地服务的端口。不同版本的配置入口不太一样有的在设置里直接填有的要改配置文件。我踩过的坑是本地模型的上下文窗口往往比云端小如果 Zcode 默认按云端窗口大小打包上下文会直接把本地模型撑爆表现为报错或者输出乱码。解决办法是手动调小上下文长度或者关掉增强选项。4. 数据安全风波的复盘问题到底出在哪4.1 “偷传代码”的几种可能解释风波起来之后我看了不少讨论把“偷传代码”这个说法拆开其实对应好几种不同情况第一种是默认配置导致的数据外传。用户没改设置工具按默认行为发送上下文用户事后才发现。这种情况严格说不算“偷”但产品在引导上确实有改进空间。第二种是遥测和日志上报。有些工具会把使用行为、报错信息上报用于改进产品。如果这些日志里不小心带了代码片段就会造成泄露。这种情况属于工程疏忽。第三种是真正的恶意行为也就是厂商故意收集用户代码用于其他目的。这种情况需要确凿证据不能靠猜测。我个人的判断是Zcode 这次风波大概率属于前两种的混合——默认配置比较激进加上遥测逻辑可能没做充分的脱敏。这跟“故意偷代码”是两回事但对用户造成的实际风险是一样的。所以讨论的时候与其纠结动机不如关注“怎么防止我的代码出去”。4.2 从 Kerberos 到最小权限数据安全的基本原则热词里出现了“kerberos大数据安全认证原理”虽然这跟 AI coding 不是直接相关但它背后的思路值得借鉴。Kerberos 的核心是“不信任网络靠票据做认证”翻译到 AI coding 场景就是不要假设工具会替你保护数据要靠自己的配置和验证来控制。我总结了几条实操原则最小权限只给工具它完成当前任务必需的访问范围不要一上来就让它读整个项目。默认关闭所有增强、遥测、改进计划的选项默认全部关掉需要时再开。可验证选支持本地部署或者能抓包验证的工具别用那种完全黑盒的。隔离环境如果非要用云端工具处理敏感代码考虑在隔离的机器或容器里跑别直接在主开发机上开。这几条不复杂但能挡掉大部分风险。我见过太多人装完工具直接开干设置页看都不看出事之后才后悔。4.3 团队协作场景下的额外考量个人用和团队用是两码事。个人项目泄露了顶多自己重写公司代码泄露可能涉及合规问题。团队引入 AI coding 工具时我建议多做几件事先做一次小范围试点选几个不涉及核心业务的模块让工具跑一段时间同时抓包监控数据流向。试点期间收集开发者的实际反馈看效率提升是否值得承担风险。然后制定使用规范明确哪些项目可以用、哪些不能用、必须关闭哪些选项。最后定期复查因为工具的默认配置可能随版本更新变化今天关掉的选项明天可能又开了。提示团队规范里最好写清楚“禁止把公司代码粘贴到任何外部 AI 对话窗口”。很多人用 AI coding 工具的同时也会顺手把代码贴到网页版对话里问问题这条路径同样会泄露代码而且更隐蔽。5. 常见问题与排查技巧实录5.1 常见问题速查表问题现象可能原因排查方向解决思路补全建议明显变慢上下文打包过大或网络延迟看请求大小和响应时间关掉增强选项或换本地模型本地模型输出乱码上下文超出模型窗口检查模型支持的上下文长度调小上下文配置抓包发现代码外传默认配置未关闭逐项检查设置页选项关闭遥测和增强重启工具安装后无法连接网络策略拦截看请求是否被阻断联系网络管理员确认策略工具更新后行为变化默认配置被重置对比更新前后的设置每次更新后复查关键选项5.2 几个我踩过的坑第一个坑是以为关掉一个选项就万事大吉。实际上数据外传可能由多个选项共同控制关了一个还有另一个。我的做法是关完之后抓包验证确认请求体里没有代码内容才算数。第二个坑是忽略了工具更新。有一次更新之后之前关掉的遥测选项又被打开了我没注意用了一周才发现。后来我养成了习惯每次更新后第一件事就是翻设置页。第三个坑是在错误的项目上试工具。我一开始图省事直接拿公司项目试后来想想挺后怕的。正确的做法是先拿一个无关紧要的练手项目跑通流程确认安全配置到位再考虑往真实项目上迁移。5.3 关于“AI coding 会不会让代码质量下降”热词里有“ai coding的到来会不会让代码质量下降”这个问题我在实际用下来有一些体会。工具本身不决定代码质量决定质量的是你有没有把工具当成“代笔”还是“助手”。当成代笔就是它生成什么你直接提交不看不改。这样短期效率高长期技术债堆积。当成助手就是它给建议你来判断该改的改该拒的拒。我现在用 AI coding 的方式是让它生成初稿或者处理重复性代码但核心逻辑和边界条件一定自己过一遍。这样既享受了效率提升又不至于把质量完全交出去。还有一个实际感受是AI coding 工具对“规范”的依赖比人还强。如果你的项目本身命名混乱、结构不清工具给出的建议也会跟着乱。反过来如果项目规范做得好工具的补全质量会明显提升。所以与其担心工具拉低质量不如先把项目规范立起来。6. 选型建议什么样的 AI coding 工具值得长期用6.1 我评估工具的几个硬指标用了这么多工具我慢慢形成了一套自己的评估标准按重要性排序第一是数据可控性。能不能本地部署、能不能关掉所有外传、能不能抓包验证这三条是底线。达不到的直接排除效果再好也不用。第二是上下文管理能力。AI coding 的效果很大程度上取决于它能不能准确找到相关代码。有的工具只会看当前文件有的能理解整个项目结构。后者效果更好但数据外传的面也更大需要配合更严格的配置。第三是模型可替换性。能不能接不同的模型后端决定了你在效果和隐私之间有多少腾挪空间。只能用一个云端模型的工具灵活性差很多。第四是社区活跃度。开源项目看提交频率和 issue 响应闭源工具看更新日志和用户反馈。一个长期不更新的工具安全漏洞没人修用着不放心。6.2 不同场景下的推荐思路个人学习项目随便用云端工具效果最好省心。涉及个人隐私的小工具建议本地模型慢点但安心。公司内部项目必须走安全评估流程优先选支持本地部署的方案。开源项目贡献看项目本身的敏感程度公开代码无所谓未公开的分支要小心。我现在的做法是分两套环境一套是本地模型跑敏感项目一套是云端工具跑公开项目和学习用途。两套环境物理隔离互不干扰。这样既保证了敏感代码不出机器又能在需要高质量建议时用上云端能力。6.3 关于“薅羊毛”心态的一点反思回到标题那句话“本以为是薅羊毛没想到家被偷了”。这句话之所以能引起共鸣是因为它戳中了一个普遍心态面对免费的东西我们容易只看收益不看成本。AI coding 工具的免费额度、免费模型、免费功能背后都是有成本的厂商要么靠订阅赚钱要么靠数据赚钱要么靠生态赚钱。我不是说免费工具不能用而是说用之前要想清楚你付出的“代价”是什么。如果代价是代码数据那就要评估这些数据对你值多少钱。对个人练手项目可能不值钱随便用。对公司核心代码可能很值钱那就得谨慎。这个判断只能自己做别人替不了。但至少做判断之前得知道自己在做什么选择而不是稀里糊涂就把代码交出去了。我写这篇的目的就是让更多人知道这个选择的存在以及怎么去做这个选择。