智譜，被上了一課

這不是他手動做的備份，而是ZCode在後臺悄悄把項目打包，並多次嘗試發出去，只是暫時沒有成功。

開發者發現ZCode存在異常行爲

於是，ferstar把ZCode的安裝包拆開，順着線索往下查，發現只要自己一登錄，ZCode就會在後臺整理打開的項目，先跳過一些不太重要的文件夾，再把剩下的內容打包、加密，最後傳到阿裏雲的雲存儲裏。更關鍵的是，打包進去的大部分內容，都不是自己正在寫的代碼，是這個項目過去的歷史記錄。

也就是說，如果這份“包裹”真被傳上去，能解密的一方看到的內容包括這個項目從開始到現在的修改記錄、後來被刪掉的方案、還沒正式提交的草稿，以及一些大文件和本地操作記錄。嚴重的話，還可能把以前刪掉過的配置、密鑰和沒公開過的分支也一起帶出去。

更讓他覺得“諷刺”的是，這個包裹雖然加密了，但他手裏只有“上鎖”的工具，真正能打開的鑰匙在智譜服務器上。就算在電腦裏發現了這個被打包的項目，也無法直接解開看看裏面到底裝了什麼。他是因爲順着客戶端做了逆向，復原了整條打包與上傳的邏輯，從本地狀態文件、快照清單裏才看到了文件構成，這位開發者還發現，即便把軟件裏和隱私、優化相關的開關關掉，後臺仍然留下了上傳記錄。

9月18日下午，智譜在ZCode官方社羣發布情況說明並致歉。官方稱，這次爭議與“代碼庫索引”功能有關，該功能本來是爲了在本地建立項目索引，支持恢復現場、回看歷史和生成項目知識庫，其中項目知識庫在雲端生成頁面時會觸發數據上傳，頁面生成後相關數據會立即銷毀、不會保存。由於功能上線初期默認開啓，部分用戶在沒充分感知的情況下被上傳了數據。

大體意思是，確實存在上傳用戶代碼的現象，但這是由於其正常功能導致的意外觸發，而且數據上傳後會自動銷毀，用戶不用擔心數據泄露。官方也表示目前該問題已經修復。

但開發者並沒有全部買賬，ferstar隨後對照新舊版本發現，新版確實已經拆掉這條上傳鏈路，相關入口也打不開了，但智譜並沒有解釋“立即銷毀”如何從外部證明等關鍵問題，因此他還存在質疑。

一波未平，一波又起。9月20日，太原承明科技有限公司（承明科技）向ZCode的開發運營方北京智譜華章科技股份有限公司（智譜）發函的內容在網絡流傳。承明科技稱，通過自行技術取證，發現自8月28日到9月14日期間，公司有6個以上工作區被ZCode上傳雲端，其中最大一個達到391.94MB。

承明科技指出，被上傳的內容並非官方所稱的“代碼片段”，而是包含項目完整源代碼、系統架構、版本控制歷史、數據庫口令、雲服務憑證及員工個人信息等完整歸檔文件，超出了ZCode官方說明裏寫明的收集範圍。函件還追問了兩個關鍵問題，上傳數據是否徹底刪除，以及數據是否可能傳到境外。截至發稿前，智譜暫未對此作出公開回應。

至此，爭議已經從個人開發者的質疑，升級爲公司對數據資產和商業祕密的正式指控。目前能夠明確的是，舊版ZCode確實會在後臺打包項目並嘗試上傳，但不能確定的是，這些行爲究竟是工程失控還是刻意爲之，以及實際被上傳的數據規模到底有多大。

PART 02

BUG可以修，邊界過不去

綜合技術從業者的判斷，這件事更像“代碼庫索引功能在實現和安全過濾上失控”，還不能直接定性爲刻意竊取用戶數據。這一結論主要來自兩方面。

首先是商業上，智譜用戶規模大，又處在融資和拓展企業客戶的關鍵階段，主動冒這種會嚴重傷害信譽的風險，動機並不強。“就算不談合規和道德，單從利益計算看，偷偷打包上傳用戶核心代碼，一旦被曝光，代價也很高。”一位從業者表示。

其次是從技術上看，“代碼庫索引”本身也確實復雜。

AI軟件工程師覃相表示，爲了讓AI理解整個項目，工程上往往需要先建立一份完整的項目底稿，再在這份底稿基礎上做後續更新。這個流程一長，就容易寫成一種“粗糙實現”：先在本地把項目完整打包，再判斷要不要上傳、怎麼上傳。

目前這起事件中呈現出的部分現象也確實更像BUG。覃相分析稱，從開發者的公開取證看，開關關閉仍會觸發，說明設置開關、後臺打包、上傳隊列之間沒有真正聯動；刪除本地包後又重新生成，說明系統沒有正確理解“用戶已經拒絕”；開發者取證發現失敗564次還繼續重試，也說明失敗提示、體積限制、重試機制都不夠完善。

而且，“代碼索引”本身並非智譜一家的選擇，這是AI編程工具的通行做法。Cursor的Codebase Indexing、GitHub Copilot的代碼庫索引，本質上都試圖讓模型理解整個項目，而非只補全幾行代碼；Trae、Windsurf等同類工具也都提供類似的代碼庫理解能力。

以上的共同點在於，它們更像是工程實現層面的失控，而不是一上來就能證明“主觀故意”。

但這個BUG波及的範圍很大，足以讓任何一家B端廠商坐立不安。

單包體積達到數百MB，說明它不是誤傳了幾個小文件，有可能是把整個項目一起打包；連已經刪除的歷史提交也被帶上，說明它打包的不只是當前代碼，還有項目過去的大量記錄；更敏感的是，密鑰、憑證、個人信息沒有被過濾，這都是企業最核心的數據資產。

再加上這種行爲持續多日、跨多個工作區反復出現，就很難看成是一次性故障，因此，覃相的判斷是，這次事件大概率不是故意泄露，而是“上傳範圍定義過大、敏感信息過濾缺失、工程實現粗糙”共同導致的嚴重事故。

這個定性不是免責的理由。正因爲出問題的是邊界、不是某一行代碼，它碰到的才會是源代碼、歷史記錄、密鑰、憑證、個人信息這些最敏感的數據，這些內容本來就在設計上本不該被打包，卻被一起裝進了上傳隊列。這不是一次能用“BUG”收場的軟件事故。

PART 03

這道難題，智譜怎麼解？

那ZCode要怎樣才能重新證明自己值得企業信任？這道題難在，它本身就不是單靠技術能解的。

AI編程工具要想真正好用，就必須深入理解項目。它不只要看用戶正在寫的那幾行代碼，還要理解文件之間的關系、項目的歷史修改、依賴結構，甚至一些業務邏輯。否則，它就只能做點代碼補全，很難承擔更復雜的開發任務。但問題在於，企業最值錢的東西，偏偏也藏在這些地方。

所以這道難題天然存在，AI工具越聰明，就越要靠近代碼；企業越讓它靠近代碼，就越擔心它會泄露自家的核心資產。

對智譜來說，這道題尤其難，因爲它的商業化基本盤，幾乎全部押在B端。而B端客戶，尤其是政企和大廠，在採購AI編程工具時，安全是重要的考量因素。

綜合從業者的說法，智譜要證明自己，至少得過三關。

第一關是說清楚。

不是發布一份聲明，也不是只寫“收集用戶通過對話提交的文本、文件和代碼”這類常規條款，而是要把關鍵邊界交代完整，比如哪些內容會被讀取，哪些會被保存，哪些會上傳，默認狀態下會發生什麼，用戶關閉後是否真正停止。

在ZCode現有的隱私政策中，雖整體上有常規的數據收集說明，但還未明確告知會默認打包整個項目，也未清楚說明歷史提交、未推送草稿、大文件緩存等內容是否會一並進入上傳範圍這類細節。對企業客戶而言，這種關鍵信息不應靠用戶自行拆解安裝包才能發現。充分、準確、前置的告知，才是建立信任的基本前提。

第二，是關得掉。

用戶選擇關閉，系統就應當真正停止。不能出現界面上有開關，後臺卻仍然繼續的情況。ferstar的取證已經證明，ZCode舊版本裏“優化體驗”“倉庫快照索引”兩個開關都無法阻止本地打包與上傳。如果一款工具連“不上傳”這一基礎指令都無法穩定執行，企業也就很難相信它在更復雜、更高風險的使用場景中，能夠守住數據邊界。

第三關也是最難的一關，是證明“已刪除”。

這次事件真正引發開發者和企業用戶不安的，不只是“曾經上傳”，還有“上傳之後如何處置”。已經傳至雲端的數據是否被徹底刪除，所謂“立即銷毀”是否有可驗證證據，是外界關注的核心。承明科技的函件也明確要求智譜在10月10日前書面答復，徹底刪除數據並出具證明、說明數據去向與是否用於訓練、公開私鑰保管方式與訪問日志。

智譜承諾引入第三方審查，方向是積極的，但尚不足以完全回應這一關切。第三方審查能夠增強對後續流程的監督，卻不能直接證明歷史數據已經被妥善處理。若審查範圍未覆蓋存量數據處置、訪問日志、密鑰權限及刪除證明，那麼“證明收回”這一環節仍然不能視爲完整完成。

如果智譜無法妥善解決這一問題，受影響的不只是智譜一家，行業也會相應提高準入門檻。

“未來，企業採購AI編程工具時，評估標準將不再局限於模型能力、代碼生成速度或功能豐富度，而會更加關注數據安全與可控性。這些要求過去或許只是加分項，但經過此次事件，很可能轉化爲企業選型的基礎門檻。”一位軟件開發者表示。這也意味着，AI編程工具的競爭，將從過去偏重功能與體驗的競賽，進一步轉向安全、透明與信任能力的競賽。

相關閱讀

• 原創 比亞迪的天，變了2026-09-22
• 從谷歌到位元組，每個大廠，終將擁有一家藥廠2026-09-22
• 五年繳稅約536億！黃仁勳：我不怕繳稅 只怕窮2026-09-22
• AI 正在製造 App 過剩時代2026-09-22