400人维权，智谱吞下苦果

在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发现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。

现在，它还需要说服他们，下一次依然可以这么做。

本文来自微信公众号“氪研社”，作者：佳佳，编辑：小八，36氪经授权发布。