這次 ZCode 的資料處理爭議，關鍵不只是「使用者選了哪些檔案送進 AI 提示詞」。逆向工程研究者 ferstar 指出，當使用者處於登入狀態時，桌面客戶端可能將加密後的工作區快照打包，並向阿里雲物件儲存服務（OSS）發起傳輸。Z.AI 則承認，問題與其「程式碼庫索引」（Codebase Indexing）功能有關：在早期預設開啟的期間，生成 Repo Wiki 時可能觸發倉庫資料上傳。235

研究者稱：被打包的不只是提示詞附件

依 ferstar 的技術報告，這份快照的範圍可能涵蓋整個工作區，而非少量手動附加給 AI 的檔案。報告列出的可能內容包括：

• 完整的 .git 目錄與提交歷史；
• Git LFS 資產快取與 reflog；
• 工作區檔案；
• 全域應用程式設定。35

其中一份報導描述，加密封存檔案約為 313 MB。另有基於該分析的報導稱，相關 RSA 私鑰由 Z.AI 一方持有，這意味著使用者即使攔截到加密封存檔，也無法自行解密檢視，或僅憑密文驗證資料是否確實遭刪除。4

不過，這些是逆向分析與網路流量觀測所得的報告結果，並不是針對每一台可能受影響裝置的公開、獨立完整清冊。這項區別很重要：觀測到對 OSS 的傳輸嘗試，並不能證明每次傳輸都成功完成，也不能單憑此判定物件傳輸後被保留多久。316

Repo Wiki 為何會牽涉上傳？

Z.AI 表示，問題源自 Codebase Indexing；該功能支援 Repo Wiki 及與版本相關的工作流程。依該公司的說法，生成 Repo Wiki 頁面可能觸發倉庫資料上傳，而這項功能在產品早期發布階段曾預設開啟。2511

這說明了產品功能上的觸發路徑，但不代表它等同於一般有明確確認步驟的「檔案上傳」。真正引發信任危機的是範圍與同意機制：使用者與研究者所描述的情況，是整個工作區被建立成封包，但缺乏清楚且有效的確認程序。36

Z.AI 後續如何處理：下架、開源與稽核

報導曝光後，Z.AI 致歉並停用受影響功能。2 該公司其後表示，ZCode v3.14.0 已移除 Repo Wiki，並關閉產生及上傳本機倉庫快照的工作流程。16

Z.AI 也表示已將 ZCode 開源，邀請外部檢視客戶端程式碼。報導指出，中國信息通信研究院（CAICT）與綠盟科技（NSFOCUS）曾進行評估。1023

依 ZCode 公布的評估說法：

• CAICT 確認阿里雲 OSS 的 zcode-prod 儲存桶在整改後處於零資料狀態；
• NSFOCUS 確認該儲存桶與相關備份儲存中的資料物件已被刪除。16

另外，智譜表示將為其 MaaS 平台推出「不留存資料」選項：輸入與輸出僅用於當次請求，完成後即刪除。這是平台所提出的未來處理政策，不應被視為對早期 ZCode 工作流程的獨立佐證。24

仍未被完整驗證的部分

公司的修復與稽核主張具有意義，但單靠這些資料仍無法回答所有歷史問題。整改後的評估若顯示指定儲存桶已清空，能支持「受檢視的儲存桶當時已被清理」這一說法；但若沒有更廣泛的日誌與完整處理紀錄，就無法獨立證明資料從未被複製到其他位置、在刪除前從未被存取，或從未被用於其他用途。

Z.AI 表示，社群所提及的程式碼及相關資料未被保留，也未用於模型訓練。41 然而，本文所整理的公開資訊，尚未提供可由外部端到端稽核的完整紀錄，來逐一證實每份被報告的快照都符合這項否定性主張。因此較精確的結論是：公司否認用於訓練，但公開驗證仍不完整。

承明科技為何要求「資料處理清單」？

太原承明科技在指控公司資料與商業秘密遭未授權上傳後，向智譜發出法律函。其要求不只限於刪除資料，還包括揭露儲存位置、是否涉及跨境傳輸、是否與第三方分享、是否可能用於模型訓練、存取或匯出日誌，以及伺服器、快取、備份與災難復原系統中的刪除證明。172126

這項要求點出了 AI 程式開發工具使用者愈來愈重視的實務標準：不只是供應商口頭表示「已刪除」，而是要有可追溯的說明——蒐集了什麼、資料去了哪裡、誰有權處理，以及如何驗證刪除。

股價反應即時，但不能直接推論長期影響

報導稱，爭議爆發後 Z.AI 股價在盤中一度下跌最多約 5%。35 其他收市報價頁面則顯示較晚的報價曾上升 1.79%，另有市場報導稱當日收市走低。3438 這些相互不一的市場快照，只能支持較保守的結論：事件帶來短期市場疑慮，不能據此可靠推斷對長期估值的影響。

給開發團隊的提醒

這起事件凸顯評估 AI 程式工具時的一項基本標準：必須清楚區分 本機索引、提示詞上下文傳輸 與 完整工作區快照上傳。產品應讓每種行為可理解、可分別控制，並能透過文件、網路流量檢查或原始碼檢視加以驗證。

對於處理專有程式碼、機密資訊或受監管資料的團隊，較穩妥的作法是：要求明確的上傳同意、最小化工作區範圍、檢查對外網路目的地，並要求供應商明示保存期限、次處理商、刪除程序與稽核證據。就本案而言，Z.AI 移除快照上傳流程，處理了被報告的技術機制；但歷史資料曾如何被處理的更大問題，正是修補後爭議仍未完全平息的原因。1617

這次 ZCode 的資料處理爭議，關鍵不只是「使用者選了哪些檔案送進 AI 提示詞」。逆向工程研究者 ferstar 指出，當使用者處於登入狀態時，桌面客戶端可能將加密後的工作區快照打包，並向阿里雲物件儲存服務（OSS）發起傳輸。Z.AI 則承認，問題與其「程式碼庫索引」（Codebase Indexing）功能有關：在早期預設開啟的期間，生成 Repo Wiki 時可能觸發倉庫資料上傳。235

研究者稱：被打包的不只是提示詞附件

依 ferstar 的技術報告，這份快照的範圍可能涵蓋整個工作區，而非少量手動附加給 AI 的檔案。報告列出的可能內容包括：

• 完整的 .git 目錄與提交歷史；
• Git LFS 資產快取與 reflog；
• 工作區檔案；
• 全域應用程式設定。35

其中一份報導描述，加密封存檔案約為 313 MB。另有基於該分析的報導稱，相關 RSA 私鑰由 Z.AI 一方持有，這意味著使用者即使攔截到加密封存檔，也無法自行解密檢視，或僅憑密文驗證資料是否確實遭刪除。4

不過，這些是逆向分析與網路流量觀測所得的報告結果，並不是針對每一台可能受影響裝置的公開、獨立完整清冊。這項區別很重要：觀測到對 OSS 的傳輸嘗試，並不能證明每次傳輸都成功完成，也不能單憑此判定物件傳輸後被保留多久。316

Repo Wiki 為何會牽涉上傳？

Z.AI 表示，問題源自 Codebase Indexing；該功能支援 Repo Wiki 及與版本相關的工作流程。依該公司的說法，生成 Repo Wiki 頁面可能觸發倉庫資料上傳，而這項功能在產品早期發布階段曾預設開啟。2511

這說明了產品功能上的觸發路徑，但不代表它等同於一般有明確確認步驟的「檔案上傳」。真正引發信任危機的是範圍與同意機制：使用者與研究者所描述的情況，是整個工作區被建立成封包，但缺乏清楚且有效的確認程序。36

Z.AI 後續如何處理：下架、開源與稽核

報導曝光後，Z.AI 致歉並停用受影響功能。2 該公司其後表示，ZCode v3.14.0 已移除 Repo Wiki，並關閉產生及上傳本機倉庫快照的工作流程。16

Z.AI 也表示已將 ZCode 開源，邀請外部檢視客戶端程式碼。報導指出，中國信息通信研究院（CAICT）與綠盟科技（NSFOCUS）曾進行評估。1023

依 ZCode 公布的評估說法：

• CAICT 確認阿里雲 OSS 的 zcode-prod 儲存桶在整改後處於零資料狀態；
• NSFOCUS 確認該儲存桶與相關備份儲存中的資料物件已被刪除。16

另外，智譜表示將為其 MaaS 平台推出「不留存資料」選項：輸入與輸出僅用於當次請求，完成後即刪除。這是平台所提出的未來處理政策，不應被視為對早期 ZCode 工作流程的獨立佐證。24

仍未被完整驗證的部分

公司的修復與稽核主張具有意義，但單靠這些資料仍無法回答所有歷史問題。整改後的評估若顯示指定儲存桶已清空，能支持「受檢視的儲存桶當時已被清理」這一說法；但若沒有更廣泛的日誌與完整處理紀錄，就無法獨立證明資料從未被複製到其他位置、在刪除前從未被存取，或從未被用於其他用途。

Z.AI 表示，社群所提及的程式碼及相關資料未被保留，也未用於模型訓練。41 然而，本文所整理的公開資訊，尚未提供可由外部端到端稽核的完整紀錄，來逐一證實每份被報告的快照都符合這項否定性主張。因此較精確的結論是：公司否認用於訓練，但公開驗證仍不完整。

承明科技為何要求「資料處理清單」？

太原承明科技在指控公司資料與商業秘密遭未授權上傳後，向智譜發出法律函。其要求不只限於刪除資料，還包括揭露儲存位置、是否涉及跨境傳輸、是否與第三方分享、是否可能用於模型訓練、存取或匯出日誌，以及伺服器、快取、備份與災難復原系統中的刪除證明。172126

這項要求點出了 AI 程式開發工具使用者愈來愈重視的實務標準：不只是供應商口頭表示「已刪除」，而是要有可追溯的說明——蒐集了什麼、資料去了哪裡、誰有權處理，以及如何驗證刪除。

股價反應即時，但不能直接推論長期影響

報導稱，爭議爆發後 Z.AI 股價在盤中一度下跌最多約 5%。35 其他收市報價頁面則顯示較晚的報價曾上升 1.79%，另有市場報導稱當日收市走低。3438 這些相互不一的市場快照，只能支持較保守的結論：事件帶來短期市場疑慮，不能據此可靠推斷對長期估值的影響。

給開發團隊的提醒

這起事件凸顯評估 AI 程式工具時的一項基本標準：必須清楚區分 本機索引、提示詞上下文傳輸 與 完整工作區快照上傳。產品應讓每種行為可理解、可分別控制，並能透過文件、網路流量檢查或原始碼檢視加以驗證。

對於處理專有程式碼、機密資訊或受監管資料的團隊，較穩妥的作法是：要求明確的上傳同意、最小化工作區範圍、檢查對外網路目的地，並要求供應商明示保存期限、次處理商、刪除程序與稽核證據。就本案而言，Z.AI 移除快照上傳流程，處理了被報告的技術機制；但歷史資料曾如何被處理的更大問題，正是修補後爭議仍未完全平息的原因。1617