本文来自微信公众号： 氪研社 ，编辑：小八，作者：佳佳
9月18日以前，ferstar还是智谱的付费用户。就在事情发生前一晚，他还在技术群里向别人推荐这个产品。
不到半天后，他成了那个把ZCode推上风口浪尖的人。
ferstar使用的是一台256GB的MacBook Air，因为硬盘空间紧张，他在清理磁盘时发现，~/.zcode目录已经占用了700多MB。继续往下查，他找到了一份313MB的加密文件，以及一份状态记录：ZCode扫描了他正在使用的商业项目，将345MB内容打包成一份全量快照，并尝试上传564次。
那份313MB文件最终没有上传成功。但ferstar随后换了一个小型公开仓库测试，一份包含538个文件、压缩加密后约15KB的快照，被服务器成功接收。
他继续拆解ZCode客户端。
按照其公布的技术分析，旧版ZCode生成的快照不只是用户正在编辑的几段代码，还可能包括.git历史、LFS缓存、reflog以及部分配置。在他检查的一份42411个文件的快照清单中，.git相关内容占到了86.6%。
9月18日，ferstar把调查过程发到了网上。标题很直接：《扒一扒ZCode静默上传全量Git历史的骚操作》。
事情从这里失控。
开发者开始检查自己的电脑，有人抓包，有人翻日志，有人卸载ZCode。企业用户也加入进来，开始检查自己的私有仓库究竟发生过什么。
《中国新闻周刊》随后报道，近400名开发者已经进入多个维权群。企业开始固定证据、发函追责，一些个人开发者则要求退款。
400个人，400笔说不清的帐
维权群里的人，诉求并不完全一样。
有人只想退款，有人想知道自己的代码究竟有没有上传成功。企业用户担心的则是另一件事：商业源码、Git历史、服务器凭据以及工程配置等敏感信息，是否曾经在他们不知情的情况下离开企业内部。
《中国新闻周刊》采访到的企业用户“张楠”就是其中之一。
按照他的说法，公司长期使用ZCode，涉及9个私有仓库和4个已经上线的项目，相关项目代码及服务器凭据曾被打包上传。事件发生后，他与公司法务开始固定相关证据，并向智谱发函，同时考虑通过诉讼进一步追责。
至于智谱后续的一系列整改，张楠的态度很直接：“当然不认可。”
另一家公司太原承明科技也在追问。
据公司相关负责人介绍，涉及此次争议的共有6个工作区，其中最大的一个数据量达到410MB。承明科技做的是企业办公系统，项目里既有自研引擎，也涉及知识产权。
ZCode风波发生后，压力很快沿着业务链条传了过来——承明科技需要向自己的客户解释，那些原本应该留在企业内部的数据，究竟有没有离开过。
这也是为什么，承明科技向智谱索要的不只是一句道歉。公司要求智谱进一步说明相关数据的处理主体和处理方式，并提供访问日志以及数据删除证明。
目前，对于具体的数据上传范围以及可能造成的影响，各方说法仍存在需要进一步核实之处。
但企业的压力并不会等到最终结论出来之后才出现。
一旦商业源码、工程配置乃至服务器凭据被卷入争议，问题就会从开发部门迅速进入安全、法务和客户关系。尤其对于承明科技这样的企业服务公司，它还需要回答客户一个更现实的问题：那些原本交给它保管的数据，是否始终留在应该留在的地方。
到了这一步，退掉一份几百元的Coding Plan已经没有太大意义。
这场维权也因此呈现出一个不同于普通消费纠纷的细节：最早寻找证据的，恰恰是用户自己。
图源：ferstar原始调查全文：扒一扒ZCode静默上传全量Git历史的骚操作
ferstar发现313MB加密文件后，没有停留在怀疑上。他继续检查状态文件、拆解客户端，又找来一个公开仓库重新测试，最终把整个排查过程写成文章公开。文章发出后，更多开发者开始检查自己的电脑：有人翻本地目录，有人查看日志和网络请求，也有人重新测试新版客户端。
智谱的每一次回应，很快都会进入下一轮验证。
公司称相关上传链路已经关闭，有人重新抓包；新版客户端发布后，有人重新跑了一遍此前的流程；ZCode宣布开源后，开发者又开始检查公开出来的代码。
这让智谱面对的，不再是传统意义上一群等待公司解释的投诉者。
近400名开发者中的一些人，正在用自己最熟悉的方式，核对智谱给出的答案。
一次“设计疏漏”，智谱用了五步收场
智谱的第一轮处理来得很快。
9月18日，ferstar的文章引发关注后，智谱当天公开致歉，将问题归因于“代码库索引”相关功能存在设计疏漏。
按照智谱的解释，Repo Wiki需要在云端生成页面，因此可能触发仓库数据上传；相关数据在Wiki生成后会立即销毁，不做保存。真正引发争议的是，这项功能上线初期被默认开启。
新版客户端随后移除了相关上传链路。
如果争议只停留在一个产品功能是否应该默认开启，这次更新原本足以解决大部分问题。但随着越来越多开发者开始检查自己的使用记录，问题很快从“ZCode以后还会不会上传”，转向了另一件更难回答的事：过去已经发生了什么。
智谱的整改也随之一步步加码。
在修复客户端之后，公司引入中国信通院、绿盟科技等第三方机构参与检查；随后宣布开源ZCode，把客户端代码交给社区监督。此后，智谱又宣布MaaS平台上线“数据内容不留存”等措施，并建立漏洞反馈和奖励机制。
从9月18日到21日，三天时间里，智谱的应对已经从一次客户端更新，扩展到第三方检查、产品开源以及公司层面的数据政策调整。《中国新闻周刊》后来将这一系列动作归纳为五步：公开致歉、修复机制、第三方审计、开源ZCode和调整数据政策。
这条越来越长的整改清单，也反映出事情已经超出了一个普通产品Bug的范畴。
根据智谱公布的信息，相关OSS中的数据对象已经清除，存储桶及其中的对象被删除，新版客户端也移除了相关快照生成和外发路径。
ferstar后来重新测试新版客户端时，同样没有再观察到此前的全仓扫描、加密包生成和上传行为。
从目前公开的信息看，最初引发争议的技术链路已经被切断。但这只能回答“现在”。
对于已经使用过旧版本ZCode的开发者和企业，更难回答的是“过去”：哪些账户曾经触发上传，哪些数据真正到达过服务器，保存过多长时间，是否存在访问记录，以及企业能否获得与自己账户对应的完整处理记录。
这也是为什么，智谱不断增加整改措施之后，维权并没有立即结束。
修复一个功能，可以通过更新版本完成。要让近400名开发者重新相信过去发生过什么，只能靠证据。
400人的另一笔账
近400人，对于一家互联网公司来说并不是一个很大的用户数字。放在智谱身上，却有另一层意义。
他们中的很多人，恰好属于过去一年大模型公司争夺最激烈的一群用户：开发者。
随着基础模型的价格不断下降，编程正在成为大模型公司寻找高频付费场景的重要入口。模型厂商不再满足于提供一个API，而是开始进入IDE、读取代码库、调用终端，让模型逐渐参与完整的软件开发流程。
OpenAI、Anthropic以及国内大模型公司相继加码AI Coding，背后争夺的都是程序员每天几个小时的工作流。
智谱也没有缺席。从GLM模型的代码能力，到Coding Plan，再到ZCode，智谱持续把产品往开发者的日常工作里推进。对它来说，一个开发者的价值也不只是一份Coding Plan的订阅收入。
个人开发者可能是API的使用者；创业公司的工程师可能影响团队选择哪一个模型；到了更大的企业，技术人员还可能参与模型、云服务乃至Agent产品的采购和技术评估。
这是大模型公司为什么愿意花大量资源争夺开发者，也是这次近400人维权真正麻烦的地方。
其中一些人原本已经完成了最困难的一步：他们愿意付费，也愿意把真实项目放进ZCode。
现在，智谱需要重新说服他们。而且这不是今年第一次出现类似的开发者摩擦。
今年2月，GLM-5上线之后，Coding Plan曾因套餐规则、模型灰度和老用户升级机制引发争议。智谱随后公开致歉，承认规则透明度、GLM-5灰度节奏以及老用户升级机制存在问题，并向部分用户开放退款。
那次争议主要围绕套餐和使用权益。到了9月，争议进入了代码和数据。
两件事的性质并不相同，但都发生在智谱试图长期经营的开发者用户中。套餐争议可以通过退款处理，产品问题可以通过更新解决，安全问题也可以引入第三方检查；更难通过一次整改恢复的，是这些用户下一次还愿不愿意把真实项目交进来。
这也是智谱连续加码整改的商业背景。它需要解决的已经不只是那条上传链路，还要让开发者相信，ZCode仍然可以进入他们的代码库。
9月17日晚上，ferstar还在技术群里向别人推荐ZCode。第二天，他开始检查这个自己正在付费使用的软件。几天之后，近400名开发者进入维权群，智谱则从修复客户端一路做到第三方检查、产品开源和数据政策调整。
对智谱而言，更难处理的问题已经出现了。过去，它需要说服开发者把代码交给AI。
现在，它还需要说服他们，下一次依然可以这么做。
