先說結(jié)論這一周國內(nèi) AI 編程圈最熱的話題不是哪個模型跑分又漲了而是智譜的 ZCode 被曝出在用戶不知情的情況下靜默上傳 Git 歷史。從第一個扒出網(wǎng)絡(luò)請求的帖子開始到官方給出正式回應(yīng)前后大約 48 小時。這 48 小時里ZCode 偷代碼沖上熱詞大量開發(fā)者連夜卸載、查日志、改 token甚至有人把 .git 目錄都刪了重新初始化。作為一個從 Copilot 早期版本就開始重度使用 AI 編程助手的開發(fā)者我覺得這件事值得認(rèn)真復(fù)盤一下——既給同行留一份排查參考也讓還在觀望的朋友知道怎么保護(hù)自己的代碼。1. 事件還原ZCode 到底做了什么才會被叫偷代碼1.1 ZCode 是什么為什么它能拿到這么多數(shù)據(jù)ZCode 是智譜在 2025 年下半年重點推的 AI 編程助手主打 GLM 模型驅(qū)動的代碼補全和對話式編程官方放了不少免費 token吸引了一大批想在編輯器里直接體驗國產(chǎn)大模型的開發(fā)者。和同類工具一樣它既有 IDE 插件也有命令行客戶端安裝完會引導(dǎo)用戶登錄賬號、授權(quán)讀取工作區(qū)。這里有個關(guān)鍵點AI 編程助手要發(fā)揮作用就必須讀取項目文件、理解代碼結(jié)構(gòu)、拿 Git 變更當(dāng)上下文。這是所有同類工具的共性單獨看并不越界。真正讓用戶炸鍋的不是讀取而是讀取之后在后臺靜默上傳而且上傳的內(nèi)容里包含了 Git 歷史的完整或部分?jǐn)?shù)據(jù)。同一時間熱詞里還出現(xiàn)了zcode重新連接中zcode偷傳代碼風(fēng)波再起這類搜索聯(lián)想說明這不是第一次有人提出質(zhì)疑只是這一次大家拿到了足夠多的證據(jù)。1.2 引爆點一條抓包記錄引發(fā)的連鎖反應(yīng)根據(jù)社區(qū)陸續(xù)公開的排查記錄最早引起注意的是一位開發(fā)者在本地用流量調(diào)試工具觀察 ZCode 的網(wǎng)絡(luò)行為時發(fā)現(xiàn)客戶端在沒有任何提問、沒有觸發(fā)代碼分析的情況下也會周期性向外發(fā)送請求。請求體里能看到項目文件名、源碼片段甚至有 .git 目錄下對象文件的痕跡。這不是孤例。后續(xù)十幾個小時內(nèi)不少開發(fā)者用同樣的方法復(fù)現(xiàn)了類似現(xiàn)象并且有人指出請求目標(biāo)是阿里云 OSS 的某個 Bucket 域名。于是zcode有打包用戶代碼上傳到阿里oss行為這個描述開始在多個平臺流傳。注意這里的關(guān)鍵詞是打包和上傳到對象存儲這意味著數(shù)據(jù)可能不是臨時的請求上下文而是被持久化到了遠(yuǎn)程儲存空間——這正是偷傳代碼風(fēng)波最讓人警惕的地方。1.3 為什么 Git 歷史比源碼本身更敏感很多人不理解為什么一個上傳代碼的事件能讓整個開發(fā)者社區(qū)反應(yīng)這么激烈。答案藏在 Git 歷史里。早期的 commit 很可能包含數(shù)據(jù)庫連接串、內(nèi)部倉庫地址、臨時寫死在代碼里的密鑰commit message 會暴露業(yè)務(wù)線、內(nèi)部代號、人員實名信息作者字段和時間戳組合可以還原團(tuán)隊規(guī)模、開發(fā)節(jié)奏、組織架構(gòu)即使文件在后續(xù)提交中被刪除完整歷史版本里依然可以還原出來。上傳一份當(dāng)前工作區(qū)文件的快照和上傳整個 .git 目錄的倉庫歷史性質(zhì)完全不在一個量級。前者尚可解釋為模型上下文需要后者基本可以被理解為企業(yè)核心資產(chǎn)被完整復(fù)制。這就是為什么大家在討論里反復(fù)提醒如果想用這類工具第一件事不是看功能多強而是先搞清楚它碰不碰你的 Git 倉庫。2. 技術(shù)拆解靜默上傳的行為特征、數(shù)據(jù)去向與識別方法2.1 社區(qū)復(fù)現(xiàn)出來的可疑行為特征綜合幾個論壇和公開討論帖里貼出的復(fù)現(xiàn)證據(jù)我整理了一張?zhí)卣鞅矸奖隳銓φ兆约菏诸^工具的行為特征現(xiàn)象說明空閑也發(fā)包IDE 掛機(jī)時客戶端仍有周期性外呼一般工具只在用戶操作時才發(fā)請求請求體含源碼抓包解包后能看到項目文件內(nèi)容關(guān)鍵看是普通明文還是打包壓縮出現(xiàn) .git 路徑請求列表里有 objects/pack 或 git 相關(guān)參數(shù)疑似在拉取倉庫歷史目的域名是對象存儲請求指向阿里云 OSS 的 Bucket 域名更像上傳歸檔而非實時推理與功能觸發(fā)無關(guān)聯(lián)未提問、未構(gòu)建、未打開文件時也發(fā)生用戶無法通過操作推斷上傳時機(jī)單看一行每一條都可能有正常的工程解釋。但五條合在一起確實不能用誤報簡單帶過。這是這次危機(jī)能在輿論場上站住腳的根本原因——它不是某個用戶的主觀猜測而是一批開發(fā)者用同類方法復(fù)現(xiàn)出來的客觀流量特征。2.2 普通開發(fā)者怎么發(fā)現(xiàn)這類行為關(guān)鍵詞觸達(dá)法對沒有網(wǎng)絡(luò)排障經(jīng)驗的開發(fā)者我給你一套最簡單可行的自查思路不需要太高深的技能。在本機(jī)安裝一個流量抓包工具。Windows 上常見的有 FiddlermacOS 上常用 Charles命令行用戶可以選用具備 HTTPS 解密能力的同類調(diào)試工具。配置抓包工具解密 HTTPS 流量然后重啟目標(biāo)軟件讓它后續(xù)的請求都經(jīng)過抓包工具。在抓包工具的過濾條件里搜一個只有你才知道的隨機(jī)串——比如你項目里某個類名、README 里某句獨一無二的話、一個不對外暴露的路徑名。如果請求體的內(nèi)容里出現(xiàn)了這些隨機(jī)串說明該軟件確實在把本地文件內(nèi)容外發(fā)。接下來再進(jìn)行解包看完整字段。這套方法的本質(zhì)和我們用搜索引擎驗證信息是不是泄露了是一樣的用一個外人不可能知道的標(biāo)記去追蹤未知鏈路。它有兩個前提一是要確認(rèn)抓包工具本身可信二是在公司合規(guī)環(huán)境里先確認(rèn)這種行為是否被允許。2.3 從傳到 OSS看數(shù)據(jù)流向的三種可能性關(guān)于為什么傳到 OSS這個問題社區(qū)里吵得很兇。我傾向于用工程思維把可能性分三層。第一層產(chǎn)品功能需要。比如某些 AI 助手為了支持多端協(xié)作、遠(yuǎn)程索引或者異步分析會把項目快照傳到對象存儲做暫存。這種設(shè)計在技術(shù)上常見問題在于是否告知用戶是否設(shè)置了過期刪除如果沒有就是工程和管理上的雙重失職。第二層模型推理通道的副產(chǎn)品。一些產(chǎn)品把上下文交給模型時會先在云端做預(yù)處理預(yù)處理的結(jié)果落在對象存儲里再轉(zhuǎn)發(fā)給模型。這種情況如果數(shù)據(jù)被完整落盤隱私風(fēng)險同樣存在。第三層脫離產(chǎn)品功能的主動上傳。也就是用戶疑心最重的那種在用戶無感的前提下把同倉庫完整歷史推送到云存儲用于產(chǎn)品改進(jìn)或其他目的。哪怕不是惡意出售代碼這種行為也已經(jīng)嚴(yán)重越權(quán)。我們可以根據(jù)后續(xù)官方公布的細(xì)節(jié)來確認(rèn)屬于哪一層。但在官方給出完整數(shù)據(jù)字段清單之前用戶的質(zhì)疑是合理的不應(yīng)該被簡單地扣上反應(yīng)過度的帽子。這也是整個 48 小時里雙方最核心的對抗點一方要證明清白一方要求先交出日志清單。3. 48小時信任危機(jī)從發(fā)現(xiàn)、發(fā)酵到口碑反轉(zhuǎn)的時間線復(fù)盤3.1 前 12 小時從單點爆料到批量復(fù)現(xiàn)第一階段是典型的孤證階段。最初發(fā)帖的人只是描述自己抓包看到的現(xiàn)象附幾張截圖、一段日志。這種帖子在國內(nèi)開發(fā)者社區(qū)每天都有本來不會掀起浪花。但接下來的十幾個小時里陸續(xù)有開發(fā)者用同樣的方法在自己的機(jī)器上復(fù)現(xiàn)出類似請求有人還放出了不同項目、不同操作系統(tǒng)的對比結(jié)果。當(dāng)一個安全質(zhì)疑從一個人說變成一批人可復(fù)現(xiàn)性質(zhì)就變了。到第一階段結(jié)束時ZCode 靜默上傳 Git 歷史已經(jīng)從論壇熱帖進(jìn)入技術(shù)媒體視野zcode偷代碼成為搜索聯(lián)想詞一些企業(yè)的運維團(tuán)隊甚至開始內(nèi)部排查員工是否安裝過這款工具。3.2 中間 24 小時官方回應(yīng)的節(jié)奏與缺口第二階段官方開始回應(yīng)。先是客服渠道的機(jī)械答復(fù)再是社區(qū)管理員表示已經(jīng)反饋技術(shù)團(tuán)隊最后是正式聲明。聲明的大方向是不存在偷取用戶代碼的行為相關(guān)數(shù)據(jù)用于模型上下文理解與功能優(yōu)化后續(xù)版本會增加透明開關(guān)?；貞?yīng)的節(jié)奏本身沒問題但缺口也很明顯沒有第一時間公布到底上傳了什么字段、存多久、誰能訪問這些核心事實。在輿論最高峰信息真空會被憤怒和猜測填滿。信任一旦進(jìn)入下行螺旋再拿我們不會惡意濫用這種話術(shù)去澄清作用是有限的。開發(fā)者要的不是承諾是一份可核驗的說明。3.3 最后 12 小時卸載潮、自查潮與有限修復(fù)第 36 到 48 小時是真正的硬核自救階段。開發(fā)者社區(qū)里出現(xiàn)了大量自查腳本幫忙掃描本機(jī)日志、提取疑似外發(fā)地址也有人發(fā)布了AI 編程助手流量監(jiān)控模板方便零基礎(chǔ)的同事快速套用。與此同時官方在 48 小時內(nèi)發(fā)布了帶有數(shù)據(jù)開關(guān)的新版本并在文檔里補充了客戶端會上傳的內(nèi)容類型清單。雖然部分用戶依然不買賬但至少技術(shù)爭議回到了可以驗證、可以審計的軌道上。從口碑修復(fù)的角度看這 48 小時并不是一個完美案例但它確實展示了開發(fā)者社區(qū)的一種成熟姿態(tài)先自己動手排查再等官方給說法。3.4 這 48 小時里最值錢的三條教訓(xùn)復(fù)盤整條時間線我認(rèn)為任何一個做 AI 工具的產(chǎn)品團(tuán)隊都應(yīng)該把這三條刻在墻上默認(rèn)關(guān)、最小化、可審計是隱私設(shè)計的鐵律。任何默認(rèn)打開但藏得很深的數(shù)據(jù)上報在互聯(lián)網(wǎng)時代大概率會被翻出來而且越翻越難看。危機(jī)回應(yīng)的黃金窗口不是用來安撫情緒的而是用來公布可核驗事實的。晚一步公布謠言就多占領(lǐng)一小時心智。用戶從疑似泄露到確認(rèn)泄露的心理轉(zhuǎn)變是不可逆的修復(fù)成本隨小時數(shù)指數(shù)上升。這一點做安全的人比做增長的人體會更深。4. 為什么 AI 編程助手會反復(fù)踩中越權(quán)讀取這條線4.1 產(chǎn)品邏輯上的必然張力所有 AI 編程助手的核心賣點都是更懂你的項目。但懂需要數(shù)據(jù)數(shù)據(jù)最小化原則又要求只取完成任務(wù)必需的部分這兩者天然矛盾。理想的數(shù)據(jù)獲取方式應(yīng)該是用戶選中代碼或報錯時才讀取相關(guān)上下文自動補全只讀取當(dāng)前文件的鄰近區(qū)域倉庫級問答必須由用戶明確觸發(fā)并提示會讀取哪些范圍請求結(jié)束后不保留副本云端不留多余數(shù)據(jù)。但在實際產(chǎn)品里為了追求懂你團(tuán)隊往往會悄悄擴(kuò)大讀取邊界從當(dāng)前文件到整個工作區(qū)從工作區(qū)到 Git 歷史從 Git 歷史到云端。每擴(kuò)大一步都能自圓其說——為了更好的補全為了加速索引但用戶感知永遠(yuǎn)滯后直到某一天被爆破。4.2 和 Copilot 們的對比遙測與越界的邊界在哪很多人在爭論里拿 GitHub Copilot 做參照。Copilot 也一直被詬病數(shù)據(jù)問題但它至少在產(chǎn)品層做了幾件事企業(yè)版明確承諾不把用戶代碼用于模型訓(xùn)練插件設(shè)置里區(qū)分了代碼上下文和遙測數(shù)據(jù)的開關(guān)文檔里寫清楚了數(shù)據(jù)留存期限。這些條款未必完美但給了用戶可預(yù)期性。ZCode 這次的爭議核心是未經(jīng)明確同意就上傳了超出功能需求的敏感數(shù)據(jù)。尤其是企業(yè)私有倉庫的 Git 歷史被傳到公共云對象存儲哪怕只有一次也會瞬間摧毀用戶對工具的信任。這里的關(guān)鍵不是上傳是否合法而是用戶是否知情。熱詞里那條trea claude插件配置智譜glm和union alpha 怎么配置到zcode中的搜索說明很多用戶是拿 ZCode 當(dāng)網(wǎng)關(guān)接其他模型用的這類場景下數(shù)據(jù)流更復(fù)雜越權(quán)讀取的風(fēng)險被進(jìn)一步放大。4.3 廠商的兩難與可能的出路客觀說AI 編程助手廠商確實面臨兩難。不讀足夠的上下文補全質(zhì)量上不去讀得越多隱私風(fēng)險越大。這個兩難不能靠用戶可以選擇不用來消解因為工具一旦成為日常生產(chǎn)力普通用戶不會逐條審計自己的數(shù)據(jù)流。我更傾向的解法是分層授權(quán) 本地優(yōu)先能用本地模型處理的不傳云端必須傳云端的先在本地做脫敏自動過濾 .env、密鑰文件以及包含 password/token 的字符串每一項上傳在界面里可見默認(rèn)關(guān)閉或默認(rèn)匿名化給用戶提供數(shù)據(jù)導(dǎo)出與刪除能力做到數(shù)據(jù)生命周期可控。這套方案會增加工程成本但它是信任的入場券。這次事件之后凡是做不到以上四點的工具在嚴(yán)肅團(tuán)隊里基本都會被一票否決。說到底編程工具領(lǐng)域的競爭已經(jīng)不只是模型能力之爭更是隱私承諾的信用之爭。5. 開發(fā)者自救手冊如何判斷自己的代碼是否被外傳過5.1 第一步翻本機(jī)客戶端日志找外發(fā)痕跡不管你現(xiàn)在還用不用 ZCode只要曾經(jīng)安裝過第一件事都是看本機(jī)日志。Windows 下通常在%APPDATA%和%LOCALAPPDATA%下找?guī)?zcode 或 zhipu 字樣的目錄macOS 下通常在~/Library/Application Support和~/Library/Logs下找。日志關(guān)鍵字先看這幾個upload、git、repository、commitHistory、oss以及任何不是你自己的服務(wù)域名。如果日志里有明顯的外發(fā)地址用文本工具全部提取出來逐一核對。我在實際幫朋友排查時發(fā)現(xiàn)很多人安裝完 ZCode 就再也沒看過日志目錄里面可能躺著幾個月的請求記錄——這也是這次事件里最有價值的線索來源。5.2 第二步用抓包工具做一次十分鐘的可控實驗如果你想徹底搞清某個工具到底外發(fā)什么最穩(wěn)妥的辦法是自己做一次可控實驗流程如下準(zhǔn)備一個臨時項目放幾個文件其中寫一個只有你能識別的隨機(jī)字符串啟動抓包工具讓目標(biāo)軟件的所有 HTTPS 流量經(jīng)過它正常使用軟件 10 分鐘再掛機(jī)觀察 10 分鐘過濾包含隨機(jī)字符串的請求導(dǎo)出請求體用 JSON 格式化工具逐字段查看看哪些文件內(nèi)容被攜帶。需要注意抓包會解密本地 HTTPS 流量只建議在你自己完全可控的測試機(jī)器上進(jìn)行不要在共享機(jī)器和公司嚴(yán)格合規(guī)的環(huán)境里隨意操作。別小看這個實驗它用一個下午的時間就能回答這工具到底上傳什么這個問題比看十頁隱私政策都直觀。5.3 第三步給 Git 歷史做一次排雷無論是否查出問題長期來看都建議對重要倉庫做一次 Git 歷史排雷。重點排查那些早期傳過密鑰后來又刪掉的倉庫——文件刪了歷史里還有舊版本。如果確實發(fā)現(xiàn)敏感提交處理方法如下只改最近一次提交信息可以用git commit --amend批量重寫歷史推薦git filter-repo不推薦舊的git filter-branch慢且容易留垃圾引用改寫完成后需要強制推送git push --force并通知所有協(xié)作者重新克隆如果密鑰真的泄露過一定要在對應(yīng)平臺輪換新密鑰。重寫歷史只能清倉庫不能讓已經(jīng)泄露的密鑰作廢。這里必須提醒改寫歷史有副作用。只要倉庫有多個協(xié)作者或開放中的 PR就要先在非工作時間操作、提前通知所有人、準(zhǔn)備好回滾方案。否則你只是把代碼泄露危機(jī)換成了倉庫沖突事故。熱詞里高頻出現(xiàn)的git commit --amend怎么使用git分支合并這類搜索說明很多開發(fā)者其實并不熟悉歷史改寫操作越是這種時候越要謹(jǐn)慎先備份再動手。5.4 第四步重新審視工具選型與團(tuán)隊規(guī)則最后是工具選型的建議。如果你對國產(chǎn) AI 編程助手的隱私政策還沒建立信任可以從這幾個方向過渡先用本地運行的模型兜底比如通過 Ollama 這類工具部署本地模型代價是硬件要求高、理解精度略有下降使用 IDE 自帶的本地補全能力讓補全完全留在本機(jī)必須用云服務(wù)時優(yōu)先選企業(yè)版或簽了明確數(shù)據(jù)處理協(xié)議的服務(wù)別用免費的公共隊列版本在公司項目里使用任何 AI 工具前先確認(rèn)公司是否已有合規(guī)要求。配合選型團(tuán)隊層面可以立一條規(guī)矩任何新引入的 AI 編程工具先由一個人做一次隨機(jī)字符串觸達(dá)檢測再決定是否全員推廣。這個動作的成本大約一個下午但它能擋掉絕大多數(shù)數(shù)據(jù)外泄風(fēng)險。像zcode添加什么skill好zcode怎么修改現(xiàn)有的項目代碼這類問題都是工具已經(jīng)被深度使用之后才會出現(xiàn)的——等團(tuán)隊已經(jīng)依賴上某一個工具再去查隱私風(fēng)險切換成本就高得多了。6. 關(guān)于信任我想說的最后幾句48 小時過去ZCode 依然能正常下載開發(fā)者社區(qū)的憤怒也從喊打喊殺慢慢變成盯著官方改。但這件事留下的陰影不會那么快散去。我個人的體會是做 AI 編程助手的技術(shù)團(tuán)隊在隱私安全機(jī)制上最怕的就是用善意假定代替工程驗證。你覺得自己是為了用戶體驗在采集數(shù)據(jù)用戶感受到的卻是被監(jiān)控。產(chǎn)品文檔里寫一萬字隱私條款不如用戶打開設(shè)置能看到一個清晰的上傳開關(guān)來得實在。這次事件里最諷刺的一點是很多人是在刪除 ZCode 之后才第一次認(rèn)真打開它的設(shè)置頁面去看那些開關(guān)到底默認(rèn)是什么狀態(tài)。最后分享兩個我實測覺得有用的小習(xí)慣。第一任何 AI 工具第一次安裝后先把設(shè)置里的數(shù)據(jù)上傳遙測崩潰上報全部點開看一遍優(yōu)先關(guān)掉與核心功能無關(guān)的項再開始用它干活。這個動作只需要五分鐘但能擋住大部分風(fēng)險。我現(xiàn)在的同事都知道我每裝一個插件都會先去設(shè)置里逛一圈這已經(jīng)成了團(tuán)隊新人的默認(rèn)動作。第二在團(tuán)隊里立一條規(guī)矩新工具引入前先花一個下午做隨機(jī)字符串觸達(dá)檢測再決定要不要全員推廣。別等代碼真的上了別人的服務(wù)器才想起來做這件事。根據(jù)我個人經(jīng)驗這個測試不需要特別高深的技術(shù)一個抓包工具加一個隨機(jī)字符串就夠用但它能幫你和團(tuán)隊省下未來無數(shù)個失眠夜。信任這個東西一旦裂過再怎么修復(fù)都會有痕跡。工具如此人和團(tuán)隊之間也一樣。