智譜ZCode遭質疑「偷傳代碼」：官方稱源於索引功能已修復，將開源代碼庫並引入第三方審查

9月18日，智譜旗下AI編程產品ZCode透過官方羣組向受影響用戶致歉，回應近兩日在開發者社羣流傳的「ZCode靜默上傳全量Git歷史」質疑。官方聲明稱，公司已第一時間完成自查，相關問題目前已修復；作為後續措施，ZCode近期將開源其代碼庫，並邀請第三方評估人員審查系統運行情況。事件的核心爭議在於：一款標榜本地作業的AI編程助手，是否在用戶未充分知情的情況下，將私有代碼倉庫的歷史資料上傳至雲端。

質疑的起點：一篇部落格文章與社羣擴散

本次風波可追溯至一篇標題為《扒一扒ZCode靜默上傳全量Git歷史的騷操作》的獨立部落格文章。文章作者主張，ZCode在未明確提示的情況下，將用戶本機Git倉庫的完整操作歷史上傳至伺服器。該文隨後被轉貼至知乎、飛書用戶羣組與多個開發者社羣。

知乎上「有消息傳智譜ZCode會上傳用戶的全量Git操作，這是否屬實」的提問頁，成為討論的主要聚集地之一。有用戶表示，已將該文章連結直接丟給ZCode內建的GLM模型進行分析，並稱模型「自己也承認了」。此一說法屬於用戶單方面描述，模型對自身產品行為的「回答」並不構成證據，只能視為社羣情緒的一個切面。IT之家等媒體隨後跟進報導，事件進入公共視野。

官方回應的技術解釋：代碼庫索引與Repo Wiki

根據IT之家取得的官方回應全文，此次問題源於ZCode的「代碼庫索引」功能。官方對該功能的定位是：在本地生成倉庫索引，以支援包括歷史版本在內的會話檢查點恢復、歷史版本回退，以及Repo Wiki（代碼倉庫知識庫）等功能。

爭議的關鍵環節在於Repo Wiki。官方承認，該功能在生成Wiki頁面時可能觸發倉庫資料上傳；Wiki頁面在雲端生成完畢後，相關上傳資料會「立即銷毀，不會儲存」。官方同時承認，這一功能在上線初期「預設開啟」，導致部分用戶在未主動使用的情況下受到影響。

換言之，官方的立場是：資料上傳行為確實存在，但屬於特定功能的設計而非隱蔽收集；問題出在預設值設定不當與用戶知情不足，而非惡意「偷傳」。這一解釋與原始質疑文章之間存在明顯出入：質疑方使用「靜默上傳全量Git歷史」的表述，暗示全程無提示；官方則將範圍限定於Repo Wiki觸發時的上傳，並強調資料用後即刪。「立即銷毀」的具體機制、是否有日誌留存、銷毀是否可驗證，官方回應中均未提供進一步細節。

補救措施：開源、第三方審查與額度重置

針對資料安全與產品信任的疑慮，官方宣布三項後續行動。其一，近期將開源ZCode代碼庫，讓外部得以檢視其資料處理邏輯。其二，邀請第三方評估人員對系統運行情況進行審查，並持續公開審查進展。其三，為全體用戶額外提供一次周額度重置，自9月18日起發放。

開源代碼庫的承諾，性質上與此前業界對AI工具資料處理透明化的訴求一致。不過截至發稿，開源的具體時間點、範圍（是否涵蓋全部客戶端與服務端元件）以及第三方評估機構的身分，官方均尚未公布。

對照脈絡：AI編程工具的本地與雲端界線

此事件發生的背景，是AI編程助手在開發者工作流中快速普及的階段。此類產品普遍面臨同一個張力：模型能力越強，越需要存取倉庫上下文；而存取範圍越大，用戶對「資料去了哪裡」的疑慮也越深。國際上，GitHub Copilot等產品早年也曾就遙測資料與代碼片段上傳議題做出政策調整，最終以企業級「不保留」承諾與獨立稽核回應質疑。ZCode此次選擇的開源加第三方審查路徑，在方向上與業界慣例相符，但落實程度仍待觀察。

從用戶端看，此次事件再次凸顯「預設開啟」設定的敏感性。涉及資料上傳的功能若預設為關閉、由用戶主動啟用，爭議空間將大幅縮小；反之，即便是為了功能完整性而預設開啟，一旦涉及私有代碼，就容易觸碰開發者的信任底線。這一點與先前微軟系工具因遙測預設值引發的反彈，屬於同類結構性問題。

可核實資訊的邊界

目前可以確認的事實包括：質疑文章存在並在社羣流傳；ZCode官方於9月18日透過官方羣組致歉並發布回應；官方承認Repo Wiki功能曾觸發倉庫資料上傳、該功能初期預設開啟；官方宣布問題已修復，並承諾開源與第三方審查。

尚未能獨立核實的部分包括：原始文章所指「全量Git歷史上傳」與官方所述「Repo Wiki觸發上傳」在範圍上的實際差異；上傳資料「立即銷毀」的技術實現；以及修復後的版本是否已完全移除相關預設行為。第三方審查結果出爐之前，雙方說法的出入仍無法完全裁定。

智譜方面表示，後續審查進展將持續公開。本臺將視開源代碼庫與第三方評估的實際落地情況，追蹤後續發展。