ZCode 开源首日：把安装包拆开，和 GitHub 源码做了逐行对照

发布于 2026-09-21 · 约 8 分钟

9 月 18 日，ZCode 被曝出「代码库索引」功能在默认开启的情况下静默上传用户全量代码仓库（连 Git 历史一起）；9 月 19 日官方致歉并承诺修复、开源；9 月 20 日新版 App 构建；9 月 21 日——也就是今天——代码仓库正式公开。

开源承诺兑现了，但一个更实际的问题摆在每个用户面前：这份开源代码，和你电脑上跑的这个 App，真的是同一份东西吗？偷传代码的功能，现在真的没了吗？光看 GitHub 仓库回答不了这两个问题，所以我把安装包完整拆开做了对照，又抓包实测了一遍。

1 · 结论先行

① 代码确实同源：App 就是由这套代码库构建的，证据是压倒性的（有字节级一致）。
② 但开源的不等于 App 的全部：App 比仓库领先一个小版本，还多出 5 大块没有开源的功能；仓库公开前也被「打扫」过。
③ 偷传代码的功能确实已经不在了：静态分析找不到痕迹，真机抓包也只看到 3 个正常出口。

flowchart TB
    APP["你装的 ZCode App 3.14.1 完整版"]
    REPO["GitHub 开源仓库 3.14.0 公开版"]
    SAME["同一棵代码树：图标、界面文案、命令库逐字节一致"]
    APP --> SAME
    REPO --> SAME
    EXTRA["App 多出 5 大私有功能"]
    CLEAN["仓库公开前被打扫过，且比 App 旧一个小版本"]
    APP --> EXTRA
    REPO --> CLEAN
    VER["结论：代码同源成立，但开源的不等于 App 全部"]
    EXTRA --> VER
    CLEAN --> VER
    style APP fill:#e3f2fd,stroke:#1565c0
    style REPO fill:#e8f5e9,stroke:#2e7d32
    style VER fill:#263238,color:#ffffff

2 · 「同源」的证据有多硬

App 的主程序是个加密压缩包，解开后是几十 MB 的压缩 JS——它不可能和 TypeScript 源码逐字相同。判断同源靠的是那些构建过程动不掉的东西：界面文案、图标、数据清单、版本常量。结果：

更关键的一个反方向证据：App 的构建元数据里记录了构建自内部 commit cead36fd（9 月 20 日），而这个 commit 不存在于开源仓库仅有的 2 个提交中。时间线完全对得上——App 先构建，仓库第二天被压缩成一个「初始开源提交」。

3 · 开源的不是全部

App 里有大量功能，在开源仓库里找不到任何对应代码：

合计约 529 个界面词条在仓库里没有对应物——这个规模远超一个小版本号能解释的范围。另外仓库侧还有清洗痕迹：随 App 分发的插件在仓库里只剩「种子声明」没有源码，且仓库版本的插件做过品牌名清理。也就是说，开源仓库是发布前筛选过的切片，用它无法独立审计当初偷传功能的实现。

mindmap
  root((未开源功能))
    机器人平台
      飞书
      微信
      Telegram
      Webhook
    积分中心
    手机远程控制
    多智能体权限模式
    电脑操作助手 CUA

4 · 大家最关心的：现在还会传代码吗

timeline
    title ZCode 事件 2026 年 9 月
    9月18日 : 曝光偷传代码 : 默认开启的代码库索引上传全量仓库与 Git 历史
    9月19日 : 官方道歉 : 承诺修复、开源、第三方审查
    9月20日 : 新版构建 : 偷传功能移除
    9月21日 : 代码开源 : 精简版，且落后一个小版本

两层验证，结论一致。

第一层：静态分析

在解包产物的全部界面文案、主程序、后台进程和 14MB 的 CLI 运行时里，搜「代码库索引」「RepoWiki」「codeIndex」等功能标识——零命中。搜索外部 API 路径，只找到遥测、OAuth 和文档地址，没有任何代码或索引上传端点。

第二层：真机抓包

让 App 在本机实际运行 3.5 分钟（网络层日志 + 每 8 秒一轮的连接采样，共 24 轮）：

24 轮采样里没有发现任何常驻回传连接——如果存在持续上传通道，一定会被采到。结论：当前版本在运行时行为层面，也验证了偷传功能确实不在了。

但要说清局限：这是空闲态窗口，没覆盖登录后跑 Agent 对话的场景（那会产生正常的模型 API 流量）；HTTPS 载荷未解密，判定依据是「目标端点集合」而非报文内容；要 100% 封死还需要代理级全量抓包。另外，「仓库是清洗过的切片」这一点意味着：第三方无法用开源代码独立复核当初偷传功能到底是怎么实现的——这仍要靠官方承诺的第三方审查。

flowchart LR
    APP["ZCode App 当前版"]
    CFG["配置服务器"]
    UPD["更新服务器"]
    TEL["遥测服务器"]
    CODE["你的代码仓库"]
    APP -->|拉配置| CFG
    APP -->|查更新| UPD
    APP -->|遥测| TEL
    APP -.->|实测零上传| CODE
    style CODE fill:#ffebee,stroke:#c62828

5 · 这个结论怎么得出的

flowchart LR
    A["安装包完整解包"] --> B["16 路并行逐模块审计"]
    B --> C["22 个疑点逐条复核"]
    C --> D["真机抓包实测"]
    style A fill:#eceff1,stroke:#455a64
    style B fill:#eceff1,stroke:#455a64
    style C fill:#eceff1,stroke:#455a64
    style D fill:#eceff1,stroke:#455a64

拆包后先用 16 路并行审计逐模块对照（覆盖全部 14 个源码包），产生 22 个疑点，每个疑点再派独立复核去双方文件里重查证据：17 个确认、1 个被推翻。随后又做了一轮 16 区域穷举式全量对照——把每一个可枚举单元（每个源码文件、每条协议频道、每个模型 ID、每组 i18n 键）逐项比对，共 595 个对照单元；这轮被 API 限流打断两次，最终改成串行逐区域补齐。每条结论都保留了具体文件路径和命中片段，理论上可以逐条复查。

6 · 写在最后

对这次事件本身，我的看法是：响应速度和开源兑现值得肯定，但「开源」不等于「可审计」。公开一份清洗过、滞后于线上产品的切片，能证明诚意，不能证明线上版本的安全。对用户真正有价值的下一步，是官方承诺的第三方审查报告，以及构建过程可复现（让大家能自己从源码构建出和官方一致的 App）。

至于普通用户要不要继续用：当前版本的两层验证都干净；如果你敏感于遥测，它至少是明面上的、小体量的。但请保持一个习惯——对任何 AI 编程工具，把它当成一个「会读你全部代码的外部服务」来对待，再决定给它什么权限。

附 · 全量对照数字（16 区域穷举审计）

这一节把前文所有定性结论背后的定量底账摊开：16 个区域、595 个对照单元，每一条都能在两侧产物里复查；逐行矩阵（含全部证据路径）见完整对照矩阵页。

支撑「同源成立」的关键全量数字：

「仅 App」的 126 条集中在 11 大类私有功能——Bots 平台接入、Web 远程控制、积分中心、营销触达、多智能体权限模式、CUA 安装管线、云内容等，与第 3 节的定性清单一一对应。13 条未决也不是含糊带过：每条都记录了试过的检索词，多为编译后不留运行时痕迹的类型声明文件，属于方法边界而非功能疑点。

分析工具：自建 16 路并行审计流水线 + Electron net-log；本文图表由 Mermaid 渲染。仓库侧对照矩阵（16 区域全量 · 595 单元）已发布为本站附录页，技术版流程图见个人工作区归档。