智譜旗下AI程式設計工具ZCode近日陷入一場圍繞程式碼資產安全的信任爭議。一位開發者在清理磁碟時發現，使用者目錄下的ZCode資料夾佔用超過700MB，其中包含一個313MB的加密檔案，記錄顯示它來自某個商業專案，狀態檔案顯示其已失敗重試564次。該開發者隨後對客戶端進行逆向分析，復原了整條打包與上傳邏輯，發現只要登入ZCode，軟體就會在後台整理開啟的專案，跳過部分資料夾後將剩餘內容打包、加密，並嘗試上傳至阿里雲的雲端儲存。

據其描述，被打包的內容大部分並非當前正在編寫的程式碼，而是專案的歷史記錄，包括從專案開始到現在的修改記錄、後來被刪掉的方案、尚未正式提交的草稿，以及大檔案和本地操作記錄。更令開發者不安的是，雖然包裹經過加密，但解金鑰匙掌握在智譜伺服器上，使用者即使發現本地打包檔案也無法檢視其中內容。他還發現，即便關閉軟體中與隱私、最佳化相關的開關，後台仍會留下上傳記錄。

9月18日下午，智譜在ZCode官方社群釋出情況說明並致歉。官方將爭議歸因於程式碼庫索引功能，稱該功能本意是在本地建立專案索引以支援恢復現場、回看歷史和生成專案知識庫，其中專案知識庫在雲端生成頁面時會觸發資料上傳，頁面生成後相關資料會立即銷燬、不會儲存。由於功能上線初期預設開啟，部分使用者在未充分感知的情況下被上傳了資料。官方表示問題已經修復。

但開發者並未完全接受這一解釋。上述開發者對照新舊版本發現，新版確實已拆除上傳鏈路，相關入口也無法開啟，但智譜並未說明立即銷燬如何從外部證明等關鍵問題。

爭議隨後升級。9月20日，太原承明科技有限公司向ZCode開發運營方北京智譜華章科技股份有限公司發函，內容在網路流傳。承明科技稱，通過自行技術取證，發現自8月28日至9月14日期間，公司有6個以上工作區被ZCode上傳雲端，其中最大一個達到391.94MB。承明科技指出，被上傳的內容並非官方所稱的程式碼片段，而是包含專案完整原始碼、系統架構、版本控制歷史、資料庫口令、雲服務憑證及員工個人資訊等完整歸檔檔案，超出了ZCode官方說明中寫明的收集範圍。函件還追問上傳資料是否徹底刪除，以及資料是否可能傳到境外。截至發稿前，智譜暫未對此作出公開回應。

目前能夠明確的是，舊版ZCode確實會在後台打包專案並嘗試上傳，但尚不能確定這些行為究竟是工程失控還是刻意為之，以及實際被上傳的資料規模到底有多大。

綜合技術從業者的判斷，此事更像程式碼庫索引功能在實現和安全過濾上失控，還不能直接定性為刻意竊取使用者資料。從商業動機看，智譜使用者規模較大，又處在融資和拓展企業客戶的關鍵階段，主動冒嚴重傷害信譽的風險動機並不強。從技術角度看，程式碼庫索引本身確實複雜，為了讓AI理解整個專案，工程上往往需要先建立一份完整的專案底稿，再在此基礎上做後續更新，流程一長就容易寫成粗糙實現。

從業者分析稱，從公開取證看，開關關閉仍會觸發，說明設定開關、後台打包、上傳佇列之間沒有真正聯動；刪除本地包後又重新生成，說明系統沒有正確理解使用者已經拒絕；失敗564次還繼續重試，也說明失敗提示、體積限制、重試機制都不夠完善。而且程式碼索引並非智譜一家的選擇，Cursor的Codebase Indexing、GitHub Copilot的程式碼庫索引，本質上都試圖讓模型理解整個專案，Trae、Windsurf等同類工具也提供類似能力。

但這一問題的波及範圍很大。單包體積達到數百MB，說明可能把整個專案一起打包；連已刪除的歷史提交也被帶上，說明打包的不只是當前程式碼；金鑰、憑證、個人資訊未被過濾，更是企業最核心的資料資產。再加上行為持續多日、跨多個工作區反覆出現，很難看成一次性故障。從業者判斷，這大機率不是故意洩露，而是上傳範圍定義過大、敏感資訊過濾缺失、工程實現粗糙共同導致的嚴重事故。

這一事件之所以在開發者圈之外也引發關注，是因為它觸到了AI程式設計工具最敏感的一根神經——程式碼資產。程式碼中藏著企業最不願外流的金鑰、憑證、歷史記錄和未公開方案。而智譜恰恰是一家絕大部分收入來自企業與開發者客戶的公司。2026年中報顯示，其上半年總收入9.54億元，其中開放平台及API服務收入8.25億元、佔比86.5%，本地化部署佔13.5%。B端客戶對資料安全的敏感度，決定了這次事件對智譜的殺傷力。

9月20日，智譜對外宣佈，其MaaS開放平台將於近期正式推出資料內容不留存功能，稱這是截至目前國內大模型服務領域約束標準最高的隱私保護機制。

對智譜來說，這道難題尤其難解，因為其商業化基本盤幾乎全部押在B端，而政企和大廠在採購AI程式設計工具時，安全是重要考量因素。綜合從業者說法，智譜要重新證明自己，至少需要過三關。第一關是說清楚，不是釋出一份宣告或寫常規條款，而是要把關鍵邊界交代完整，比如哪些內容會被讀取、儲存、上傳，預設狀態下會發生什麼，使用者關閉後是否真正停止。在ZCode現有隱私政策中，雖整體上有常規的資料收集說明，但還未明確告知會預設打包整個專案，也未清楚說明歷史提交、未推送草稿、大檔案快取等內容是否會一併進入上傳範圍。

第二關是關得掉。使用者選擇關閉，系統就應當真正停止，不能出現介面上有開關、後台卻仍然繼續的情況。公開取證已顯示，舊版本中最佳化體驗、倉庫快照索引兩個開關都無法阻止本地打包與上傳。如果一款工具連不上傳這一基礎指令都無法穩定執行，企業很難相信它在更復雜、更高風險的使用場景中能守住資料邊界。

第三關也是最難的一關，是證明已刪除。這次事件真正引發不安的，不只是曾經上傳，還有上傳之後如何處置。已經傳至雲端的資料是否被徹底刪除，所謂立即銷燬是否有可驗證證據，是外界關注的核心。承明科技在函件中明確要求智譜在10月10日前書面答覆，徹底刪除資料並出具證明、說明資料去向與是否用於訓練、公開私鑰保管方式與訪問日誌。智譜承諾引入第三方審查，方向是積極的，但尚不足以完全回應這一關切。第三方審查能增強對後續流程的監督，卻不能直接證明歷史資料已被妥善處理。若審查範圍未覆蓋存量資料處置、訪問日誌、金鑰許可權及刪除證明，那麼證明收回這一環節仍不能視為完整完成。

如果智譜無法妥善解決這一問題，受影響的不只是智譜一家，行業也會相應提高准入門檻。有軟體開發者表示，未來企業採購AI程式設計工具時，評估標準將不再侷限於模型能力、程式碼生成速度或功能豐富度，而會更加關注資料安全與可控性，這些要求過去或許只是加分項，但經過此次事件，很可能轉化為企業選型的基礎門檻。這也意味著，AI程式設計工具的競爭將從過去偏重功能與體驗的競賽，進一步轉向安全、透明與信任能力的競賽。從行業角度看，這種變化並非壞事，只有當能看什麼、能記什麼、能帶走什麼被明確告知、被有效約束、被持續證明，企業才可能將真正的核心專案交給AI工具。而本次ZCode事件對智譜而言，既是一次面向B端市場的信任壓力測試，也是一次能力體檢。