用Claude自動標記整理SharePoint文件庫

簡而言之： Claude可以透過Microsoft Graph API讀取文件並給出中繼資料建議，速度遠超任何人工填寫——但要先定好欄位結構，把應用程式註冊的權限收斂到Sites.Selected而不是整個租戶，並且明白：讓一個文件庫變得可檢索，就改變了誰真正能找到什麼。打標籤只是容易的那一半。

任何有些年頭的SharePoint租戶裡，都有那樣一個文件庫：四萬個檔案、一棵沒人記得是誰設計的資料夾樹、「Proposal_v3_FINAL_updated(2).docx」這樣的檔名，以及一個回傳一切也等於什麼都沒回傳的搜尋框。中繼資料欄位是有的——移轉時有人建過——但它們是空的，因為填寫這件事永遠是別人的工作。一個能讀懂文件並推斷它是什麼的AI，看上去正是對症的工具，而它確實基本對症。以下講的是：怎樣做才不至於白費力氣，也不至於製造出你本來沒有的問題。

為什麼SharePoint文件庫會變得搜不到東西

用資料夾取代了中繼資料。 SharePoint本質上是一個假裝成檔案共用的資料庫，而組織只用了「檔案共用」那一半。一棵很深的資料夾樹只編碼了一種分類方式——通常按團隊或年份——並讓其他所有問題都無從回答。

中繼資料欄位存在，但是空的。 非必填欄位在趕工期時一律被跳過。一旦它們只填了20%，按它們篩選就比不篩選更糟，因為它會悄悄把剩下的80%藏起來。

真正的中繼資料寫在檔名裡。 版本、客戶、狀態與日期，都活在各團隊各自發明、執行還不一致的檔名規範裡。這些資訊其實存在——只是無法被查詢。

沒有人對這個文件庫負責。 當初建結構的人已經轉調了。關於「某個內容類型到底意味著什麼」這類決策沒有歸屬者，於是結構固化，而內容還在源源不斷地進來。

搜尋本身很少是元凶。Microsoft 365的搜尋能力還算可以，它只是沒有任何可用的東西可以依據。

Claude如何讀取、分類並標記文件庫內容

工作形態很直白：列舉一個文件庫裡的文件，取出每一份的文字，連同描述你分類方案的提示一起送給Claude，拿回結構化的取值，再把這些值寫進項目的中繼資料欄位供人複核。Claude負責閱讀與判斷——「這是一份工作說明書，面向X類客戶，日期為Y，已被更晚的版本取代」——而這正是靠加人加不上去的那部分。

有兩件事決定輸出值不值得要，而它們都不是模型本身。

先定中繼資料策略，再談自動化

在產生第一個標籤之前，先想清楚你到底要向這個文件庫提哪些問題。多數文件庫需要的欄位比團隊提出來的少——通常是文件類型、歸屬團隊或業務領域、狀態（草稿、生效、已作廢）、日期，以及在相關情境下的客戶或專案編號。五個填得滿的欄位，任何時候都勝過十五個稀稀落落的欄位。

用SharePoint自己的結構，而不是自由文字。封閉取值用選擇欄位，讓取值保持一致。當分類法需要跨網站共用並集中治理時，用詞彙庫中的受管理中繼資料。當不同文件類型確實需要不同欄位時，用內容類型。並且把每個取值的定義寫下來——如果兩個人對某份東西該算「報告」還是「審查」意見相左，模型也會在完全相同的地方搖擺，因為含混出在你的方案裡，不在模型裡。

Graph API存取、應用程式註冊與最小權限

以程式方式存取SharePoint要經過Microsoft Graph API，而這需要在Microsoft Entra ID中做應用程式註冊。這一步值得認真對待，因為預設路徑的權限過大。

一個使用應用程式權限、擁有Sites.Read.All的註冊，可以讀取租戶內的每一個SharePoint網站。幾乎沒有哪個打標籤專案需要這個。Sites.Selected正是為這種情境存在的：應用程式預設不取得任何網站存取權，由管理員按網站集合明確授予。從這裡起步，只授予試點文件庫所在的網站，再有意識地擴大。

還要理解應用程式權限對「管線能看到什麼」意味著什麼：應用程式是以自己的身分讀取，而不是以某個使用者的身分，因此在被授予的範圍內，無論誰對什麼有權限，它都能讀到每一份文件。這不是缺陷，但它確實意味著這條管線是一個特權元件，應當按特權元件對待——專用身分、憑證存入金鑰庫、盡可能用憑證驗證而非用戶端密碼、活動留存記錄並定期複核。

一套可落地的流程：先試點一個文件庫，複核，再擴大

挑一個既重要又有邊界的文件庫。 某個業務領域內的幾千份文件，並且有人真的在乎它好不好用。一上來就全租戶鋪開的嘗試之所以失敗，原因往往與技術無關。

先跑「建議模式」。 把建議值寫進一份報告——或者寫進暫存欄位——而不是直接寫進正式中繼資料。找兩位熟悉內容的人抽查一百份。你要找的是系統性錯誤，不是個別偏差：如果它一貫把已作廢的草稿判成生效，那需要修的是你的狀態定義，而不是提示詞。

先改方案，再重跑。 這個階段的絕大多數修正，應該落在分類定義上，而不是模型指令上。在這裡迭代，因為此時成本最低。

寫回時帶上稽核軌跡。 正式提交取值時，記錄寫了什麼、什麼時候寫的、由哪個流程寫的。SharePoint版本歷程會顯示這次修改由你的應用程式身分完成，這足以追溯，但不足以解釋——把執行記錄留著。

接著處理新文件，而不只是舊文件。 一次性清理會在一年內衰減。真正持久的做法是文件一進來就打標籤，這比所有人一開始都想做的歷史回填要小得多，也有價值得多。

AI自動標記 vs SharePoint Syntex vs 人工填中繼資料

應對雜亂、不一致的內容 — Claude在這裡很強：它像人一樣讀文件，也不要求固定版面。Syntex的結構化文件處理是圍繞可辨識的表單與版面設計的；人工填寫準確，但在量上根本跑不起來。
保持在Microsoft 365內部 — Syntex明顯勝出。它在租戶內原生執行，不需要外部API呼叫，文件內容不出租戶。任何外部模型都意味著內容跨越了一道邊界，這是一個應當明確作出、而不是事後才發現的治理決策。
投入成本 — 人工是零建置成本，加上無限的持續成本。Syntex需要授權與模型訓練，但不需要寫程式。Claude管線需要應用程式註冊、程式碼，以及有人執行它——當內容非結構化到Syntex吃力，或者你需要的是對內容的推理而不是擷取時，它才算合理。
成本結構 — 人工的成本是人力工時。Syntex按使用者或按量計費。API管線按token計費，處理幾萬份文件很便宜，但在全租戶執行之前值得先算一遍。
長期一致性 — 自動化方案完勝。文件庫之所以退化，不是因為第一次標錯了，而是因為沒有任何東西去標第40001份。無論選哪條路，持續執行的那一環都比歷史回填更重要。
可解釋性 — 人工標註可以直接問當事人。Syntex會給出模型信心度。外部模型的判斷在三者中最難檢視，這正是「凡涉及保留或法律後果的，都必須人工複核」的理由。

沒人提的那個風險：繼承權限與過度共用

這裡是常被跳過的部分。打標籤不改變權限——但它改變了人們能找到什麼。

一個成熟的文件庫通常有十幾處被中斷的權限繼承、幾年前建的「任何人有連結即可存取」的共用連結，以及少數幾份技術上對遠超預期人數可見的文件。沒人察覺，是因為沒人能找到任何東西。等你把中繼資料填滿、搜尋開始生效——那份一直躺在繼承權限缺口裡的薪酬審查，現在會乾淨俐落地出現在任何按「HR / 2024」篩選的人面前。

這不是反對打標籤的論據，而是關於順序的論據：在讓試點文件庫變得可檢索之前，先看一遍它的權限圖景。 哪些地方繼承被中斷、為什麼。存在哪些共用連結、是誰建的。「除外部使用者外的所有人」這個群組是否掛在了不該掛的地方。如果一個文件庫即將變得可搜尋，這次複核應該發生在之前，而不是事後作為一次事件回應。

保留原則同理。如果文件從未被分類，那保留原則也從未被正確套用過。打標籤給了你讓Purview保留標籤真正有意義的那份分類——這是機會，但也意味著刪除決策從此處在你的標註準確度的下游。在把兩者接起來之前，先複核。

把這件事做對：權限治理、API金鑰，以及何時該讓IT介入

先稽核，再照亮。 上文那次權限複核就是全部關鍵，而且它是一件定義清晰的工作：被中斷的繼承、共用連結、來賓存取、權限過寬的群組，以及負責人已離職的孤兒網站。多數組織從未跑過它，而查出來的東西總是比預期更有意思。

這條管線的身分是特權身分。 它能讀遍授權範圍內的一切。給它專用的應用程式註冊、Sites.Selected範圍、基於憑證的驗證、放在金鑰庫而不是設定檔裡的憑證，以及一個真的有人執行的定期活動複核。

把內容邊界問題明確定下來。 把文件文字送給外部API，意味著內容離開了租戶。對一個裝行銷素材的文件庫來說無關緊要；對裝員工檔案、客戶機密、或在你經營市場中受監管內容的文件庫來說，這是一個需要留痕的決策——請查閱模型供應商針對你所用方案的當前資料處理條款，並在試點之前就讓負責資料保護的人參與進來，而不是之後。

指定一位負責人。 這個文件庫需要有人來決定某個內容類型意味著什麼，並裁決邊界情況。沒有這個角色，方案會漂移，標註也會跟著漂移。

Brocent的IT評估與稽核服務，做的正是本文建議你先做的那次Microsoft 365複核——身分、存取、端點與權限結構，並按經營市場把發現對應到PDPO、PDPA、PIPL與ISO 27001；當同一個租戶同時服務香港、新加坡與中國大陸主體、適用不同規則時，這一點尤其重要。我們的AI+支援服務涵蓋API與RAG整合工作，適合你希望把管線交給別人建置和運行而不是內部配人的情況；託管IT支援則負責應用程式註冊、憑證管理與日常維運，讓它在建成之後依然安全。如果你對用Claude做Microsoft 365自動化有更廣的興趣，我們那篇Claude與Microsoft 365郵件自動化的指南，在郵件側講的是同一套治理邏輯。Brocent自2007年在北京創立以來一直在亞洲提供託管IT與資安服務，總部位於新加坡，並自2016年起設有香港辦公室。

常見問題

Claude會看到使用者本不該存取的文件嗎？

如果你使用應用程式權限，這條管線就是以它自己的身分讀取被授予範圍內的一切——所以是的，它看到的比大多數個別使用者都多。這正是Sites.Selected範圍之所以重要的原因，也是這條管線應當被當作特權系統元件對待的原因。它不會給使用者新增存取權；但它確實意味著這個整合本身是一項敏感資產。

可以先只在一個文件庫上跑嗎？

可以，而且應該這樣做。Sites.Selected正是為此設計的：只把某一個網站集合的存取權授予應用程式，在真實內容上驗證分類方案，等到修正不再是系統性的之後再擴大。一上來全租戶執行，只會產出大量自信而錯誤的中繼資料。

已有的中繼資料會怎樣？

請有意識地決定，因為兩種答案都站得住。只往空欄位裡寫最穩妥，也保住了人工成果。當已有取值已知不一致時，覆寫有時才是對的——但要基於一份你已複核過的報告來做，絕不盲寫，並保留覆寫前的狀態。SharePoint版本歷程會記錄這次變更，但從中重建四萬筆歷史取值，不是你會想接的工作。

這需要Microsoft Graph應用程式註冊嗎？

只要是自動化管線，就需要——以程式方式存取SharePoint要經過Graph，而那需要在Entra ID裡做應用程式註冊並由管理員同意其權限。對規模較小的互動式用途，使用者委派方式也可行，而且它把管線限制在該使用者的存取權範圍內，有時這恰恰是你想要的。

這和Microsoft Syntex有什麼區別？

Syntex是微軟原生的文件處理能力：在租戶內執行，內容不外流，對版面可辨識的結構化與半結構化文件很強。外部模型更擅長非結構化內容，以及對「這份文件意味著什麼」進行推理。如果你的文件庫主要是版面一致的表單與合約，請先評估Syntex——光是那道邊界的價值就已經不小。

怎樣避免這個文件庫再次退化？

在文件進來時就打標籤，不要只做歷史回填。在流程允許的地方把關鍵欄位設為上傳必填，按計畫對新文件執行分類任務，並給這個文件庫指定一位負責人。回填是看得見的專案；而持續執行的那一環，才真正決定十八個月後你會不會又回到這裡。

從哪裡開始

在做任何其他事情之前，先對一個文件庫執行一次權限複核——無論你最終是否部署標註管線，它都值得做，而且它會改變之後所有事情的順序。然後定義五個欄位及其含義，在同一個文件庫上以建議模式試點，等到你的修正從系統性變為個別性時再擴大。如果那次Microsoft 365稽核正是貴司團隊一直騰不出時間做的事，歡迎聯絡我們——它是一段邊界清晰的工作，而且是最該先做的那一件。