智譜（Zhipu）旗下的 AI 程式開發工具 ZCode，近日被爆出會在登入狀態下，於背景靜默打包使用者整個工作區、包含完整 .git 歷史紀錄，加密後上傳至阿里雲 OSS 物件儲存，且隱私設定開關完全無法阻止。消息 9 月 18 日在開發者社群炸開後，智譜火速發出道歉聲明，坦承問題出在預設開啟的「程式碼庫索引」功能，並承諾近期將開源 ZCode 程式碼、引入第三方審查，同時為所有用戶重置一次使用額度。
靜默打包整個工作區：從 700MB 磁碟佔用開始的調查
事件的起點是一名代號 ferstar 的開發者在清理磁碟空間時，發現 ZCode 的資料根目錄 ~/.zcode 異常佔用超過 700MB 磁碟空間。深入追查後，他在 v2/checkpoints/ 目錄下找到一個 313MB 的加密封存檔（.enc），旁邊的狀態檔案記錄著工作區路徑、加密後大小，以及高達 564 次的上傳失敗重試次數。
🚨 Stop using ZCode on your Mac until you read this.
I’ve had ZCode open on my Mac pretty much all day for a while now. It’s a nice app, and Zhipu gives away a lot of free tokens, so it was easy to like.
But someone when reverse engineering the desktop client, found out that… pic.twitter.com/5eCFe3msMm
— netrunner (@plotarmordev) September 18, 2026
根據狀態檔的記錄，ZCode 掃描了他一個 10GB 的商業專案，排除 node_modules 等依賴目錄後，將剩餘 345MB 的內容（幾乎全是核心程式碼）打包成 313MB 的加密封存，標記為「baseline」（完整快照），並在本地 pending/ 目錄排隊等待上傳。ferstar 表示，刪除這個封存檔後，半小時內 ZCode 就又重新打包了一份新的 313MB 封存，重試計數從 564 跳到 565，刪除檔案只是治標不治本。
他甚至逆向分析了客戶端的 app.asar 封裝檔，重建出完整的上傳流程：ZCode 客戶端先向 zcode.z.ai 請求上傳憑證，伺服器回傳 OSS 表單簽章、物件金鑰、大小限制，以及一組 RSA 公鑰；客戶端在本機將工作區壓縮為 tar.gz、以 AES-256-CTR 加密，再用 RSA-OAEP-SHA256 包裝金鑰，最後直接透過 HTTP POST 表單把加密封存送上阿里雲 OSS，OSS 再回呼智譜後端登記快照。檢查使用中的網路連線時，也確認 ZCode 程式持續與 zcode.z.ai 及兩個阿里雲 OSS 節點保持連線。
最諷刺的一環：加密金鑰只屬於伺服器
這起事件最令人不安的細節是加密設計本身。ferstar 指出，ZCode 採用的是典型的信封加密（envelope encryption）：內容用一次性對稱金鑰以 AES-256-CTR 加密，對稱金鑰再用伺服器即時下發的 RSA 公鑰以 RSA-OAEP-SHA256 包裝。對應的私鑰永遠不會出現在使用者機器上，只有智譜伺服器端持有。
ferstar 嘗試用系統上所有本地私鑰解開封存，全部失敗。那 313MB 躺在使用者自己硬碟上的密文，使用者本人和 ZCode 客戶端都無法開啟，唯一能解密的只有智譜後端。這種設計若真是為了讓使用者回滾或跨裝置同步，金鑰應該存在本地（就像 Git 或 Time Machine 那樣）。金鑰只屬於伺服器，其用途只有一個：確保伺服器隨時能讀取你的程式碼。
而封存內容的組成更是雪上加霜。由於打包清單（manifest）是以明文保存在本地，ferstar 得以拆解一份 42,411 個檔案的快照：.git/lfs/ 佔了 196.1MB（56.8%）、.git/objects/ 佔 102.2MB（29.6%）、.git/logs/ 佔 0.6MB（0.2%），原始碼與文件僅 46.2MB（13.4%）。光是 .git 目錄就佔了封存內容的 86.6%。
這代表上傳到雲端的遠比當前工作樹多得多：包括後來提交中被刪除的歷史 API 金鑰與敏感設定檔、未推送的本地分支名稱（可能洩漏未發布的功能計畫）、以及 .git/config 中記錄的內部 GitLab 主機名稱與儲存庫路徑。對企業用戶而言，這等同於把整個開發歷程與商業機密打包奉上。
隱私開關形同虛設：登入即觸發
ferstar 進一步交叉比對 UI 設定與程式碼，發現兩個與快照上傳相關的開關都無法阻止此行為。「最佳化體驗」（optimizeAgentExperienceEnabled）只控制資料是否授權用於模型訓練，快照打包與上傳照常運作；「儲存庫快照索引」（repoSnapshotIndexingEnabled）只控制伺服器是否索引已上傳的快照，本機打包和上傳流程完全不受影響。
從主程式組合語言來看，快照側車程式在啟動時就無條件實例化，完全沒有以使用者偏好為條件的判斷式，唯一的要求是登入權杖（JWT）有效。也就是說，只要登入，這條背景管線就永久運作，沒有任何 UI 設定能關掉。觸發時機有兩個：每次發問前（captureBeforePrompt），以及任務完成時。單一活躍 session 就產生了 62 次快照事件。
而 ZCode 的隱私政策明文寫著收集「對話中提交的文字、檔案與程式碼」，這在 AI 編程工具中屬常態，但整份政策、FAQ 與更新日誌中，完全找不到任何關於「靜默打包並上傳整個工作區與完整 Git 歷史」的描述，僅有「最佳化程式預設關閉、未經同意不會用於訓練」的範本式聲明。
社群炸鍋：開發者要求交代與全面刪除
事件曝光後迅速在開發者社群發酵。ferstar 的原始調查推文在 13 小時內突破 27.6 萬次觀看，中文圈的警示推文也累積超過 6.3 萬次觀看。開發者 @plotarmordev 直接呼籲大家「在看完這篇之前先停用 ZCode」，並指出他也深受其害。 Hacker News 上的討論串在 20 小時內累積超過 250 分，有開發者酸諷「既然拿了這麼多程式碼，至少希望我們很快能看到開源 AGI」。
也有開發者拿兩個月前的 Grok Build 事件做對比：xAI 的程式開發代理同樣被發現會上傳完整 Git 歷史到 Google Cloud，但 Grok 的上傳行為會寫在自己的日誌裡、事後也提供了關閉開關，屬於「疏於控管的意外」；ZCode 的情況則相反，加密金鑰只握在伺服器端、開關驗證過無法關閉、刪除封存後仍持續重試，觸發條件是登入而非使用，被社群形容為「對自身用戶加密的刻意設計」。
面對排山倒海的質疑，智譜 ZCode 官方團隊在社群發布聲明，坦承問題源於預設開啟的「程式碼庫索引」（Codebase Indexing）功能：該功能設計目的是在本地生成儲存庫索引，支援對話檢查點恢復與 Repo Wiki，但產生 Wiki 頁面時可能觸發儲存庫資料上傳，雲端生成完畢後資料立即銷毀、不會保存，相關問題已修復。官方並承諾近期將開源 ZCode 程式碼、邀請獨立第三方審計系統運作並持續公開進度，同時為所有 ZCode 用戶提供一次使用額度重置作為補償。
結語
這起事件為整個「開源模型 + 封閉開發工具」的組合敲響警鐘。模型權重可以開源下載、在本地執行，但包在模型外面的開發工具（desktop harness）若持續向雲端回傳資料，所謂「本地執行」就只是假象。ferstar 建議的最終防護手段是把 ZCode 的 checkpoints 目錄在檔案系統層級鎖死（macOS 用 chflags、Linux 用 chattr），讓快照根本無法寫入。 AI 編程工具讀取程式碼本就是運作常態，問題是：當你登入的那一刻，工具是否在默默打包你整個開發歷程，而且只有它自己拿得到鑰匙。
