Add ZCode computing freedom journal

1 files changed, 43 insertions, 0 deletions

diff --git a/content/journal/2026/09/zcode-and-computing-freedom/index.md b/content/journal/2026/09/zcode-and-computing-freedom/index.md
new file mode 100644
index 0000000..e458271
--- /dev/null
+++ b/content/journal/2026/09/zcode-and-computing-freedom/index.md
@@ -0,0 +1,43 @@
+---
+title: "ZCode 与被夺走的计算自由"
+slug: "zcode-and-computing-freedom"
+lang: zh-Hans
+created: 2026-09-18
+updated: 2026-09-18
+description: "关于 ZCode 工作区快照、数据控制权与计算自由的记录。"
+license: CC-BY-SA-4.0
+---
+
+2026 年 9 月 18 日，围绕 AI 编程工具 ZCode 的一场风波在开发者社区迅速发酵。起因并不复杂：一名开发者在排查本地磁盘占用时，发现 `~/.zcode/v2/checkpoints/` 目录下堆积了异常庞大的仓库快照（repository snapshot）。随着社区对 ZCode 的 Electron 客户端进行逆向反编译，以及对本地 manifest、状态数据库和网络请求逻辑的层层排查，一套隐秘的工作区快照机制浮出水面：客户端会在本地静默扫描项目目录并打包快照，随后向服务端申请凭据，把数据送往远程对象存储。公开样本显示，单次快照就包含了 42,411 个文件，其中 `.git/objects`、`.git/logs`、`.git/refs` 以及 Git LFS 等底层内部数据占据了绝大部分体积。紧接着，GitHub feedback 仓库的 Issue #707 补上了关键一刀：即便用户已在设置里将 `repoSnapshotIndexingEnabled` 手动置为 `false`，本地状态中依然生成了记录大量 `.git` 内部对象的快照清单。面对确凿证据，官方随后承认 Repo Wiki 功能曾触发仓库数据上传且上线初期默认开启，承诺已完成修复，后续将开源相关代码并引入第三方审查。
+
+从逆向还原的数据流来看，这套机制在工程上直白地展示了控制权的单向流动。客户端在本地抓取快照后，向云端申请上传凭据和 RSA 公钥；快照数据经临时生成的 AES 密钥加密，该密钥再由服务端的 RSA 公钥封装，最终把密文推入远程对象存储。这种信封加密（envelope encryption）能够防范网络链路上的中间人窃听与存储侧的直接泄露，但解密私钥自始至终保存在服务商的机房里，用户本地根本没有对应密钥。更严重的是，快照抓取的边界完全不受控制，本该被严密防护的 `.git` 目录成了上传的主体——这里面不仅包含已从当前工作树删除的历史代码、废弃配置和私有仓库地址，甚至可能夹杂过往 commit 中手滑带上的 API 凭据、未脱敏的临时环境变量、未推送分支上的试验性原型，以及由 reflog 完整记录的操作痕迹。一个常驻开发者本地、握有工作区最高读写权限的进程，在用户毫无感知的情况下，架设了一条通向远端服务器的单向传输管道；而作为机器的法定所有者，开发者对手指底下的数据流向一无所知，更缺乏在本地硬性阻断它的有效手段。
+
+这起事件最根本的矛盾，不在于偶发的数据外溢，而在于本地控制权在架构层面的结构性让渡。
+
+硬件算力由开发者承担，磁盘里的代码属于受保护的私有资产。但 ZCode 作为本地常驻进程，在后台静默遍历目录、打包 Git 历史并向外部端点推流。作为计算环境的所有者，开发者既无法从系统交互中获知其实际行为，也无法在运行时施加制衡，最终只能依赖社区逆向分析安装包与本地状态文件，才勉强拼凑出真实的数据走向。
+
+专有软件的问题从不在于商业厂商的姿态是否友善，而在于这种架构天然就是反客为主的。代码运行在本地，并不意味着代码受你调遣。一旦用户失去了审查实现、修改逻辑和自主构建的权利，软件就必然沦为厂商部署在宿主系统内的远程代理。ZCode 只是把这个技术现实推到了台前：代码在你的 SSD 上，Git 仓库在你的本地终端里，但决定数据流向的核心裁决权，却握在远端的云端后台。
+
+最讽刺的，莫过于被全量扫描并上传的偏偏是 `.git` 本身。
+
+Git 本身是分布式架构与本地控制权的典范：全量历史存放在本地，何时 commit、开什么分支、推哪些 refs、推向哪个 remote，全凭开发者一人裁决。然而，ZCode 却在这套严密的体系之上，横插了一个闭源黑盒 Agent，轻而易举地击穿了本地防护边界。Git 历史里记录着工程演进的全部细节，也沉淀着未公开的技术探索与私密足迹。
+
+面对这种越界，自由软件赋予开发者的从不是虚无的道德姿态，而是实打实的技术制衡权——如果发现代码逻辑越界，可以直接从源码中把上传模块彻底剥离，或者在编译期把 `.git/**` 强行列入路径黑名单，甚至自己构建并向团队分发经过安全审计的版本。但在专有闭源体系下，开发者手里没有任何技术反制筹码，只能被动面对设置面板里的几个布尔开关，单方面寄希望于闭源二进制会忠实遵守配置。
+
+官方所谓“全程加密上传”的公关话术，同样经不起工程推敲。用 AES 加密快照、再用服务端公钥封装密钥，这种设计只解决了一个问题：防止链路上的第三方窥探。但密码学的核心问题从来是：钥匙握在谁手里？最终的解密能力在服务商机房，而不在开发者手里。数据产自本地工作区，凝结着开发者的劳动，但远端副本如何留存、衍生索引如何派生，完全处于单向不可控状态。
+
+这正是“服务替代软件”（SaaSS）最根本的弊端：当你把本可在本地完成的分析任务拱手交给远端黑盒时，本地客户端就退化成了一根数据输送管道。即便 ZCode 日后公开客户端源码，只要核心的语义索引与分析逻辑依然强绑定在私有云端服务上，用户依然无法审查远端实际执行的代码，更无法对数据处理链路施加约束。专有客户端与私有云端协同运作，其底层逻辑始终是一致的：把本该属于本地的计算主权，牢牢留在厂商的数据中心。
+
+再看 ZCode 官方的事后公关，几乎完全符合商业软件应对信任危机的标准路径：宣称数据在处理后“即刻销毁”，保证“新版本已完成修复”，并许诺未来“开放源码并引入第三方审查”。
+
+但只要具备基础的系统工程常识就会明白，这些承诺在技术架构上是无法自证的。所谓的“即刻销毁”属于不可验证的单方面声明，外界无法核验远端是否驻留有预热缓存、派生向量索引或冷备快照；在缺乏可重现构建（reproducible builds）的前提下，“已经修复”依然完全依赖对闭源分发版本的盲信。至于未来计划中的开源，如果仅仅是将前端交互层开放，而核心逻辑依然强依赖于私有后端、剥夺用户的本地独立部署权，那么这种“开源”充其量只是把协议界面做成了一扇单向橱窗：代码可以供人围观，但决定系统如何运行、数据如何解密并参与生成的私钥与模型后端，自始至终掌握在服务商手里。
+
+今天许多讨论倾向于把视线局限在“隐私协议是否合规”、“数据是否用于训练”、“日志保留了多少天”，却避开了最底层的系统矛盾：我们究竟是从什么时候开始，心安理得地把整个开发环境的最高执行权，让渡给了一个不可审计的专有黑盒？
+
+当下的 AI Coding Agent 已经不是传统的文本补全插件，它在本地拥有接近开发者的系统特权——遍历代码库、执行终端命令、读写配置文件、调度 Git、调用外置工具，并在后台建立网络连接。当一个常驻进程具备这种级别的系统访问深度时，自由软件所主张的权利就成了最基础的防御工事：开发者必须能够确切获知代码在本地执行了哪些系统调用，必须有能力在源码层面阻断非必要的外部通信，也必须拥有让核心分析任务离线运行的技术选项。
+
+放弃了这些基于代码与架构的制衡手段，所谓的“安全”便彻底退化为一种建立在单向承诺上的黑盒盲信：把工作区的核心资产，全盘押注在客户端配置项里的一个布尔开关、一份随时可以单方面解释的免责条款，以及公关稿里那句轻描淡写的“数据已删”之上。
+
+不要把这次事件轻描淡写地归结为“AI IDE 的配置项 Bug”。它暴露了一个更深层的技术困境：当开发者放弃了对本地可执行文件的审查与构建能力，本地计算环境的防御边界就会在事实上瓦解；而一旦关键计算强依赖于远端黑盒，用户就失去了任何对等的质询筹码。这次被发现的是 `.git` 快照，下一次就可能是私有配置文件、未提交的分支代码或本地服务凭据。
+
+解决这个问题的技术路径其实非常清晰：计算应当尽可能收敛在机器主人的掌控之内；即便确实需要协同远端算力，其接口协议、数据管线与服务后端也必须支持透明审查与自由替换。归根结底，开发工具的使命是协助工程师理解并构建系统，而不是在本地操作系统内划出一块不受宿主管辖的特权盲区。如果一套工具在架构设计上连“本地资产由本地掌控”这种最底线的确定性都无法提供，那么无论它的辅助特性多么高效，其底层的信任模型都是不成立的。