一句「上傳後立即銷毀」，先被讀成了介面：ZCode 的道歉，是一場被排版過的信任修復

先從一句話看起。「數據上傳後會立即銷毀」。這是智譜AI旗下編程工具ZCode被曝靜默打包上傳用戶代碼後，官方給出的解釋裡最關鍵的一句。它在語意上想完成的事情很明確：把「上傳」這個動作的時間軸切開，讓破壞發生在損害成立之前。但這句話被用戶讀到的方式，恰好相反。用戶看到的是一個已經發生的、未被告知的上傳行為，以及一個無法被驗證的銷毀承諾。承諾出現在事後，就永遠晚於信任的斷裂點。

這次被曝出的行為，按照貼吧與飛書羣流傳的說法，涉及將用戶工作區檔案與Git歷史記錄加密打包後上傳。討論在 deepseek 吧與智譝清言吧迅速發酵，熱榜話題的即時討論量超過十一萬。程式設計師族羣的反應特別值得看：有人立刻盤點自己放進工作區的東西有多敏感，有人開始問剛付費的 Pro 能不能退，也有人注意到，出事之後免費額度的「雞蛋」變得好領了。這些反應共同構成一幅畫面：一款開發者工具的信任，是按專案層級計價的，一旦工作區被視為可能的外流範圍，整個工具的可用性就歸零。

「滑跪開源」這四個字，是怎麼被髮明出來的

輿論給這次官方回應起了一個極精準的標籤：「滑跪開源」。官方宣布將開源代碼庫、引入第三方審查，動作快、姿態低。但這四個字本身就帶着解讀：它暗示開源在這裡的功能是止血，而非治理。

開源作爲一種修復手段，邏輯上是成立的。原始碼公開之後，「上傳了什麼、何時上傳、傳到哪裡」從宣稱變成可查驗的事實，第三方審查則把查驗的責任部分外包給了不受官方控制的眼睛。這正是閉源工具長期以來的結構性問題：用戶對資料流向的認知，完全依賴介面上的文字。而介面上的文字，是廠商自己寫的。

貼吧裡有一則留言把這件事的歷史座標拉了出來：有人拿馬斯克當年面對類似質疑時的回應作對比，同樣是「上傳到自家伺服器、會立刻刪除」，同樣隨後走向開源。這個對比未必完全公平，但它說明用戶已經形成了一種辨識模式：先否認或輕描淡寫，被抓住細節，再以開源作爲最後的誠意證明。當這套劇本被重復太多次，開源的修復力就會遞減。ZCode 趕在輿論高峯期打出這張牌，時機上是對的，但用戶手裡已經有了劇本，牌面的驚喜感所剩無幾。

信任介面：開發者工具的特殊難題

一般消費級 App 的隱私爭議，用戶多數時候只能憤怒，無法查證。開發者工具的用戶剛好相反，他們有抓包的能力，有讀取日誌的習慣，有把可疑行爲寫成時間線的職業本能。這次事件最初就是從「疑似私自上傳」的技術觀察開始擴散的，飛書羣裡的討論先於官方聲明完成了事實的初步拼裝。

這意味着 AI 編程工具的隱私設計，不能只做合規層面的最低配置。一款 agent 類工具天然需要讀取專案檔案、存取版本歷史，它的權限邊界本身就是產品設計的一部分。理想的設計裡，任何離開本機的資料動作，都應該在介面上被明確標示，可以關閉，可以審計。這與我們先前談過的AI 產品如何把計費語言設計成介面的第一印象是同一個道理：用戶對一款工具的信任，建立在你願意把多少內部邏輯攤開在介面上。計費要透明，資料流向更要透明。

對照來看，開源 agent 如 DSH 與 codex 之所以在這類討論中被反覆點名爲「相對可信」，原因並非它們的工程品質更好，而在於它們把查證的門檻降到了最低。閉源工具則把用戶放在一個尷尬的位置：你必須相信一份你自己無法驗證的隱私政策。這次 ZCode 事件裡最刺眼的一點是，「加密打包上傳」如果是靜默進行的，那麼加密反而成了一種對用戶隱瞞的技術手段，因爲加密的對象是流向外部的資料，而鑰匙不在用戶手裡。

道歉聲明的排版，也在傳遞訊息

一場公關危機的介面，除了產品本身，還包括那篇致歉聲明的結構。解釋在前還是道歉在前，開源承諾放在第幾段，第三方審查有沒有具體時程，這些排版決策決定了聲明被讀成誠意還是話術。「上傳後立即銷毀」這句話的問題，就在於它把解釋的力道放在了技術細節，而用戶真正想聽的是：爲什麼事先不說。一個未被事先告知的資料動作，事後任何技術性的正當化，都會被讀成辯護。

這與 Switch 2 誤封事件中公告措辭如何被設計成可傳播的社羣敘事的結構類似：官方的每一句話都會被截圖、拆解、轉發，措辭的輕重緩急本身就是一種可被閱讀的設計。貼吧裡那則「當你發現屋裏有一隻蟑螂的時候」的留言之所以被頂起來，是因爲它替整個族羣說出了擴散式的懷疑：ZCode 被抓到了，其他閉源工具在做什麼，沒有人知道。這種懷疑不會被一篇聲明消除，只會被下一個被抓到的案例確認或者暫時擱置。

開源是終點，還是起點

ZCode 事件收在一個還沒有答案的位置。開源代碼庫、引入第三方審查，這兩個承諾的價值取決於執行深度：是全量開源還是部分開源，審查是一次性鑑定還是持續機制，第三方是誰、報告是否公開。歷史經驗是，以危機回應形式做出的開源承諾，往往在輿論退燒後面臨維護動能不足的問題。

但對整個 AI 工具賽道而言，這次事件留下的東西比一家公司的公關得失更大。它把一個原本只在技術社羣內部討論的問題推上了熱榜：本地優先究竟該是產品的預設值，還是用戶需要自己去爭取的選項。對 to B 場景來說這尤其成立，商業代碼的工作區被靜默上傳，無論事後如何銷毀，合規風險在點擊上傳的那一刻就已經成立。開發者工具的下一輪競爭，規格表上的模型能力差異會越來越小，而「資料在哪裡被處理」會成爲採購決策裡權重越來越高的那一欄。

一個好的開始是把資料流向做成介面上看得見的東西。在哪個環節離開本機、去了哪個域名、能否一鍵關閉，這些資訊的呈現方式，最終會比任何一句「立即銷毀」更有說服力。信任修復的起點從來不是承諾的措辭，而是讓用戶不需要相信承諾。