ZCode 開源滿 24 小時，噓聲反而更大了：一份沒有歷史的帳本，還有螢幕前需要喘口氣的你

這起事件發生在 2026 年 9 月中下旬，雖然熱度最高峯已過，但後續討論還在技術社羣裡發酵，值得用回顧的角度再把它說清楚一次。時間軸很短：9 月 18 日，開發者 ferstar 發布一篇取證分析，指出智譜旗下的 AI 編程工具 ZCode 在登入狀態下，會把整個工作區，包括完整的 .git 提交歷史、LFS 快取和 reflog（一種記錄 Git 內部操作痕跡的日誌），全部打包加密後直接上傳到阿裏雲 OSS 儲存，而解密私鑰只存在雲端，介面上找不到有效的關閉開關。三天之內，智譜走完了致歉、整改、第三方審計、宣布開源的整套流程。9 月 21 日，倉庫 zai-org/ZCode 在 GitHub 上線，一天內拿到近 5000 顆 star。

從危機處理的速度看，這幾乎是教科書等級的回應。但開源滿 24 小時後，社羣的反應不是鬆一口氣，而是更大的質疑聲。這中間的落差，剛好是一堂健康資訊識讀的課，只是這次的主角換成了程式碼。

我們先前也從身心照顧的角度聊過這件事的開頭，智譜 ZCode 道歉並開源的那場隱私風波，這次把焦點放在開源之後大家到底在吵什麼。

社羣真正想問的，是三個關於過去的問題

先把爭議還原清楚。這件事的性質，從一開始就不是產品出了一個 bug，而是使用者懷疑自己的程式碼資產被悄悄拿走了。由此產生的核心疑問有三個。

第一，上傳機制從哪個版本開始存在，影響面有多大。第二，被打包上傳的資料在刪除之前，有沒有人讀過、有沒有被拿去做過什麼。第三，官方第一輪回應裡說「上傳是為了會話檢查點回滾」，這個說法是否屬實。

注意這三個問題的共同點：它們全部是關於過去的問題。而開源這個動作，天然只能交付現在的快照。想用一份現在的快照回答過去的問題，前提是你得把歷史提交記錄一起公開。

開源倉庫裡，實際交付了什麼

打開倉庫，技術社羣的失望非常具體。

整個倉庫只有兩個 commit：一個空的 Initial commit，加上一個名為 feat: open source 的巨型提交，一次性倒入 6973 個檔案、約 103 萬行程式碼。內部開發歷史被整體壓平，無法追溯上傳功能是什麼時候寫進去的，也看不到它是怎麼被移除的。這裡有個讓人哭笑不得的對照：一個因為打包使用者全量 .git 歷史而翻車的產品，自己開源時的 git 歷史是零。更有意思的是提交時間，程式碼落地的時刻換算成北京時間是 9 月 21 日凌晨五點多，不難想像那是一個連夜清理的現場。

倉庫的 Issues 功能處於關閉狀態，PR 也被鎖定。官方口徑是把程式碼交給社羣監督，但社羣連提一個 issue 的入口都沒有，於是有開發者把監督熱情轉移到了 commit 評論區。

程式碼裡還留著兩處讓人心裡發涼的痕跡。README 專門解釋了一句「CLI 源碼作為普通目錄隨倉庫一起克隆，無需初始化 submodule」，把子模組攤平成裸目錄，恰好抹掉了 CLI 的獨立提交歷史。另一處是 CodingPlanStatusActions.tsx 裡的注釋：「開源版不享受額度活動權益」。也就是說，你在官網下載的閉源版和倉庫裡的開源版並不是同一個東西，服務端靠某種方式區分它們。而截至原文章撰寫時，有使用者回饋官網下載頁的歷史版本已經拿不到了，如果屬實，對舊版本做逆向取證的路也基本被封上。

至於大家最關心的核心能力，例如 Computer Use，開源版裡只有被挖空的佔位符。據社羣分析，閉源版的大量核心邏輯封裝在 native 動態庫 build/Release/ax_native.node 裡，這部分完全沒有隨源碼放出，而 native 庫逆向分析的難度遠高於 TypeScript。換句話說，開放出來的 103 萬行，主要是外圍的綁定和界面層。

最關鍵的概念混淆：開源不等於可審計

ferstar 後續對開源程式碼的複核，確認了上傳鏈路已被徹底清除，也確認檢查點功能確實是純本地的 Git 操作。這一點其實反過來推翻了官方「檢查點回滾需要上傳」的最初解釋。

但要看清楚這個結論的結構：它能證明現在的版本不會上傳，證明不了過去的版本上傳了什麼、從什麼時候開始上傳。原作者那句總結很傳神：你看到的不是帳本，是帳本的封面。

社羣真正要的東西叫做可審計性，它至少需要三樣：完整的提交歷史、可複現構建（也就是用源碼編譯出和官方發布的二進位檔完全一致的結果）、以及公開的問題追蹤入口。這次開源，三樣都沒有給。給的是程式碼本身，一份壓平了歷史、與線上版本存在差異、核心模組缺席的快照。

回到你自己身上：面對信任危機時，判斷力和身體都值得被照顧

如果你這幾天也泡在相關討論串裡，可能有點身心俱疲。這種疲憊有幾個來源值得拆開看。

一個是資訊不對稱帶來的懸置感。核心問題沒有被回答，你拿不到確定結論，大腦會一直掛著這件事。這時候可以做的，是把「我能驗證的」和「我只能等待的」分成兩堆。你能驗證的：檢查自己機器上是否裝過這個工具、工作區裡有沒有敏感內容、網路上流傳的檢測方法是否可靠。你只能等待的：官方是否公布影響版本範圍、是否釋出更完整的審計資料。把後者明確放下，是減少焦慮的實際做法。

一個是熬夜追進展的身體負荷。連夜清理現場的是工程師，連夜追蹤現場的往往是我們自己。凌晨五點的 commit 時間戳提醒我們，這類事件最容易讓人滑手機滑到半夜。如果你真的想知道後續，設一個第二天固定的時段看更新，會比整夜刷新拿到的有效資訊更多。

還有一個，是把憤怒轉成有建設性的動作。對隱私侵害的憤怒是合理的情緒，它代表你重視自己的邊界。但情緒需要出口，也需要停損點。寫一篇分析、整理一份自查清單、把經驗分享給同事，這些都是出口；無止盡地刷評論區找同溫層，往往只會把情緒越滾越大。

幾個現在就能做的自保動作

與其反覆確認別人有沒有偷看，不如把自己的防線先架起來。給經常使用各類 AI 編程工具的你幾個方向。

養成隔離的習慣。把客戶端工具和工作專案分開，敏感程式碼放在工具存取不到的環境裡操作。檢查工具的網路行為，如果你具備能力，用抓包工具看看它到底往外送了什麼，這次事件正是靠開發者的自主取證才曝光的，這種能力值得慢慢累積。

看清版本。任何工具出事後，保留一份你正在使用的安裝包和版本號，是未來追溯的基本材料。這次歷史版本快速下架的情況也說明了，留檔的時間窗口可能很短。

看懂承諾的結構。企業道歉聲明裡，「已整改」和「過去沒做過」是兩句完全不同的話。下次讀類似聲明時，先問自己：它回答的是現在的問題，還是過去的問題？它給的是快照，還是可以追溯的軌跡？這個習慣不只用在資安事件，看健康資訊、看產品宣傳都用得上，和我們之前聊過的AI 直接給答案時代的健康資訊查證方式是同一套思考方式。

最後想說的

開源 24 小時拿到近 5000 顆 star，同時換來更大的噓聲，這件事本身並不矛盾。star 給的是動作的速度，噓聲要的是問題的答案。一款產品因為打包了使用者的全部歷史而翻車，自己交出來的歷史卻是空白，這個對照留在社羣記憶裡的時間，可能比這次危機本身更久。

對照 2026 年 9 月這起事件，值得留下的不只是對某家公司的評價，還有一個可以帶走的判斷框架：當有人用一份現在的快照回答你關於過去的問題時，先別急著安心，也別急著絕望，把「能證明什麼、不能證明什麼」分清楚，再決定自己下一步要做什麼。這套功夫，放在程式碼上是資安意識，放在健康資訊上是識讀能力，放在生活裡，是讓你在各種風波中睡得著覺的本事。