用Gemini整理Google共用雲端硬碟

簡而言之： Gemini非常擅長找出並摘要你共用雲端硬碟裡已有的東西，也很樂意給你提一套更清爽的結構方案。但它不會替你搬移和重新命名成千上萬個檔案——那部分是Apps Script或Drive API的工作，在規模化執行時幾乎不可逆，而且在沒有試跑和真實備份兜底之前，絕不該跑起來。

凡是用了三年以上Google Workspace的公司，共用雲端硬碟長得都差不多：四十個頂層資料夾，其中六個都叫某種形式的「行政」，一個名為「新資料夾(2)」的目錄裡躺著某份合約唯一的簽署版，而命名規範在發明它的人離職後又改過兩次。誰也找不到東西，於是大家各自重新上傳一份，混亂繼續複利。Gemini確實幫得上忙——但它幫的是哪一部分，才是這篇文章的全部重點。

共用雲端硬碟為什麼會退化成搜不到東西的一團亂

沒有人對分類體系負責。 資料夾結構是一項需要維護者的共同決定，而它幾乎從來沒有維護者。每個新專案都會在啟動者當時剛好停留的那一層建立資料夾。

檔名裡編碼的是只在那一週說得通的脈絡。 十八個月後，「最終版_v3_JL_已更新」什麼都告訴不了你，而這樣的檔案有一萬個。

只有當你還記得文件裡的某個詞時，搜尋才管用。 Drive的關鍵字搜尋不錯，但它回答不了一個你只能用概念表述的問題——「我們給新加坡那家零售客戶用的定價思路」——除非這些字剛好出現在檔案裡。

重複是對糟糕搜尋的理性反應。 當找到目前版本比重做一份還慢時，人就會重做一份。這不是馬虎，而是一個合理的局部決策，製造出一個糟糕的整體結果。

離職會留下無主的結構。 在個人「我的雲端硬碟」裡建立再分享出去的檔案，會在帳號刪除時一起消失。共用雲端硬碟解決了這個問題，所以在這份清單裡的其他事情之前，先把檔案從個人所有權遷出來是值得的。

Gemini在Drive上能做什麼

語意搜尋與摘要，對比「真的去搬移檔案」

真正強的能力——在具備相應授權的Google Workspace裡今天就可用——是檢索與綜合。你可以在Gemini側邊欄或Gemini應用裡問「我們今年在客戶合約裡通常約定的付款條件是什麼」，引用具體檔案，並拿到一份帶有回連至原文件引註的綜合答案。你可以請它摘要一整個提案資料夾、抽取一批檔案裡提到的所有截止日期，或告訴你四份相似文件中哪一份才是最新的實質版本。當你需要的是針對一組固定來源的持久化、有據可依的工作區，而不是臨時提問時，NotebookLM覆蓋的是同一塊地。

關鍵在於，這一切都運行在你既有的權限模型之內。Gemini只會呈現提問者本來就有權存取的檔案，所以它自己不會製造出新的曝險路徑——不過它確實會讓既有的過度分享變得顯眼得多，這通常是好事，偶爾會讓人有點尷尬。

Gemini做不到的，是大量檔案操作。它不會把九百個檔案搬進新的資料夾樹，也不會按某個規範把它們改名。你請它做，它給你的是一份方案，不是一次執行。開工之前，這個區分是最值得先弄明白的一件事。

用Apps Script或Drive API做腳本化整理——以及為什麼必須先試跑

真正的整理動作意味著寫程式：要快且留在租戶內就用Apps Script，量大就用正式服務呼叫Drive API。有用的分工是：模型負責分類與提議，確定性程式碼負責執行。給Gemini一份清單——檔名、路徑、擁有者、MIME類型、最後修改時間、最後開啟時間、大小，可選再加一小段摘錄——請它為每一列提出目標資料夾和正規化後的檔名，並附上信心分數與理由。要結構化資料回來，不要散文。

然後把這份提議當成一個待審查的變更集，而不是一條待執行的指令。把它寫進試算表。按信心分數排序。讓真正負責那塊業務的人去看低信心的那些列，因為它們恰恰是模糊地帶，一次猜錯就會把重要東西埋掉。到那時再執行——分批進行，把每一列的來源路徑和目的路徑都記下來，好讓這次操作能逐列回退。

一套安全的整理流程：盤點、提議、試跑、執行

先盤點，而且在做任何別的事之前先把它看一遍。 透過Drive API把整個雲端硬碟列舉進一張試算表。光是這份清單通常就能定下策略：如果四成檔案兩年沒被開啟過，答案是一個封存資料夾，而不是一套分類法。

目標結構要由人來定。 完全可以請Gemini依清單提出一套結構，但最終的目錄樹是一個業務決定。六到十個貼合公司實際運作方式的頂層資料夾，勝過一套邏輯漂亮卻沒人認得的結構。

先封存，再整理。 把兩年以上沒動過的東西，一次性移進一個帶日期的封存資料夾。風險低、可逆，而且通常在難的部分開始之前就消掉了一半問題。

把提議產生為資料。 每個檔案一列：目前路徑、建議路徑、建議名稱、信心分數、理由。這個階段什麼都不執行。

試跑並審查。 產出差異清單——什麼移到哪裡、什麼會被改名、每個新資料夾會落進多少檔案。抽查低信心的列，以及任何涉及合約、財務、人事的內容。找第二個人複核。

分批執行，全程留痕。 先從一棵資料夾樹開始，驗證無誤再繼續。把每次搬移的檔案ID、舊上層目錄、新上層目錄都記錄下來，這樣你的回退路徑就不依賴任何人的記憶。

提前溝通，而不是事後通知。 告訴大家日期、會變什麼，以及如果他們要用的東西挪了位置該怎麼辦。整理的痛苦大部分不在技術上。

在習慣根深蒂固的地方留下捷徑。 Drive的捷徑讓檔案只存在於一個標準位置，同時仍出現在團隊習慣去找的地方。節制地使用，能換來不少善意。

AI輔助清理 vs 人工分類專案

規模上的速度 — AI以巨大優勢勝出。人工給兩萬個檔案分類是一個沒人做得完的專案；產生兩萬條分類建議只要一個下午和一筆不大的API帳單。
命名一致性 — AI明顯勝出。模型對第一萬八千個檔案和第一個檔案套用的是同一套規範，而輪班做這件事的人做不到。
理解業務真正在乎什麼 — 人勝出，而且差距不小。模型不知道某個名字取得很爛的資料夾裡，裝著一樁進行中爭議的唯一證據。這類知識長在人身上，必須被注入到審查環節裡。
處理模糊地帶 — 人勝出。對一個真正說不清的檔案，正確的反應是去問人，而一個被要求分類的模型永遠會給出一個分類。
成本 — AI輔助在人力上便宜一個數量級，但並不免費：審查環節是實打實的工作，而跳過它，正是讓這件事從清理變成事故的原因。
風險輪廓 — 人工慢而安全；腳本快，且在沒有試跑的情況下是災難性的。上面那套流程存在的意義，就是拿到前者的風險輪廓和後者的速度。
可持續性 — 兩種做法沒有維護都撐不住。一個沒有主人的乾淨雲端硬碟，一年之內就會退化回去，所以命名規範和負責人比這次一次性清理更重要。

不可逆錯誤這個問題

這個專案真正危險的地方在於：Google Drive是一個沒有交易邊界的活系統。一萬次搬移就是一萬次獨立操作，沒有回復按鈕。

檔案搬移時權限會變，儘管連結不會。 這一點常讓人意外，所以值得說準確：Drive檔案在被搬移或改名後仍保留原有ID，所以既有連結依然有效。變的是繼承來的存取權。把檔案從個人「我的雲端硬碟」移進共用雲端硬碟，擁有權會轉給該共用雲端硬碟並套用其成員權限；在共用雲端硬碟之間搬移，可能悄悄取消某些人原本透過舊上層目錄獲得的存取權，也可能把存取權給到不該有的人。因此，一次大量搬移就是一次大量權限變更，必須按權限變更來審查。

垃圾桶不是復原。 刪除的項目在垃圾桶裡存30天然後永久消失，而垃圾桶根本不記錄「搬移」這個動作。如果腳本把九百個檔案放錯了地方，什麼都沒被刪除——所以垃圾桶裡也沒有任何東西可以還原。

版本記錄不是備份。 它保存的是文件內容的歷次修訂。它不保存資料夾結構、檔案位置、擁有權或分享狀態，而這些恰恰是一次整理會改變的東西。Google Vault是保存與電子蒐證工具，不是「幫我還原結構」的工具。

跑到一半的執行是最糟的結果。 一個在第六千個檔案（共一萬個）掛掉的腳本，會把雲端硬碟留在一個既不是舊結構、也不是新結構的狀態裡。分批和完整留痕，正是讓這種情況可復原的原因。

這就是為什麼一份真實、獨立、能把某個時間點狀態（含結構與分享關係）還原回來的Drive資料備份，對這個專案來說不是可選的保險。它是讓這個專案根本值得一試的前提。

把這件事做對：備份、分享權限，以及何時該讓IT介入

第一個腳本跑起來之前，有三件事要先定。第一，備份：確認你有一份在變更之前取得、且可還原的副本，並且透過真的從中還原一樣東西來確認它。沒測試過的備份是一種信念，不是一項控制措施。第二，權限：把分享稽核納入盤點環節，因為一次清理是你能拿到的最好機會，去修掉那些「知道連結就能存取」的檔案，和兩年前就離職的外部帳號。第三，事後歸屬：指定命名規範和結構的負責人，否則十八個月後你還得再來一遍。

如果你把檔案內容——而不只是中繼資料——送去給模型做分類，還有一個資料處理問題。在Google Workspace內部，Gemini處理你的資料適用的是你的Workspace條款，而不是把它當作公開的消費級輸入；但如果你是從自己的腳本呼叫API，就要核對適用的是哪套條款，並把這個決定記錄下來。如果你受香港《個人資料（私隱）條例》、新加坡PDPA或中國《個人信息保護法》約束，共用雲端硬碟裡幾乎必然含有個人資料，這項分析和其他任何處理活動一樣受約束。

Brocent的雲端託管備份服務正是為這個情境存在的——一份獨立、可還原的Workspace資料副本，包含Drive自帶垃圾桶與版本記錄保護不了的結構和分享狀態。我們的AI+支援服務負責建置盤點、分類與試跑工具，託管IT支援負責權限稽核和執行時段。如果貴公司用的是微軟而不是Google，對應的工作可以看我們那篇用Claude自動標記並整理SharePoint文件庫的指南。Brocent自2007年在北京創立以來一直在亞洲提供託管IT服務，總部位於新加坡，並自2016年起設有香港辦公室。

常見問題

AI大量整理檔案之後能復原嗎？

只有你事先做了準備才行。Drive裡沒有回復按鈕，垃圾桶也不記錄搬移。讓一次整理變得可逆的只有兩件東西：一份記錄了每個檔案ID及其新舊上層目錄的完整日誌，以及一份在執行前剛取得的獨立備份。兩者都有，回退就是一個腳本。兩者都沒有，那就是靠記憶做人工重建。

搬移檔案會讓既有的分享連結失效嗎？

不會——這是最常見的誤解。Drive檔案保留其ID，所以連結在搬移和改名之後依然有效。真正會變的是繼承權限：檔案會套用新上層目錄的存取規則。原本透過舊位置能開啟它的人可能失去存取權，不該看到它的人也可能獲得存取權。請把大量搬移當作大量權限變更來稽核。

Gemini能看到使用者看不到的檔案嗎？

不能。Gemini在提問使用者既有的Drive權限範圍內運作，不會呈現那個人本來打不開的文件。它真正會做的，是讓過度分享變得顯眼——那些技術上可存取、實際上被埋起來的內容，現在會出現在答案裡。這正是在推行任何AI能力時同步做一次分享稽核的好理由。

Drive的版本記錄算備份嗎？

不算。版本記錄保存的是檔案內容的早期修訂。它不保存檔案曾經在哪裡、歸誰所有、分享給了誰——而這些恰恰是一次整理會改變的東西。Google Vault是保存與法律保留工具，不是結構還原工具。如果你需要回到昨天那個雲端硬碟，你需要的是一個備份產品。

該讓AI自動重新命名檔案嗎？

重新命名比搬移安全，因為檔案ID和連結都不受影響，但它仍然會銷毀資訊——舊名字往往編碼了某些東西。一個不錯的折衷，是在套用新規範的同時，把原始名稱保留到檔案說明欄位裡，這樣什麼都沒丟，搜尋也仍然找得到舊字串。

從哪裡開始

這週就做盤點，而且除此之外什麼都別做。把檔案清單匯出到試算表，看看年齡分布、重名情況和分享曝險面。在大多數組織裡，光是這一張表就會重新定義問題——答案往往是「封存掉大部分、修好分享、統一一套命名規範」，而AI分類做的是中間那段枯燥活。然後，在任何腳本寫入任何東西之前，先確認你能把雲端硬碟還原回今天的狀態。如果你更希望把備份、稽核和整理當作一整件受控的工作來推進，歡迎與我們聯絡。