文章摘要

醒來後刷卡進辦公室的那刻，心裡反覆盤旋著前幾天的四個關鍵：場景就是功能的起點、用摘要穿越文字森林、把時間軸倒回去看上下文，以及把成果帶回到團隊的日常工作流。

今天輪到第五法則登場，我們會聊到的是先「框選知識的領域」，只要把知識邊界劃對 Copilot 回答就會像專屬顧問一樣貼著你的業務脈絡遊走。

為什麼要先框選知識的領域？

Microsoft 365 Copilot 的腦袋不是空的，它是用你的工作內容與情境當作地基來思考的，例如郵件、行事曆、文件、聊天、會議紀錄，全都透過 Microsoft Graph 連起來，並且遵守每個人的權限與敏感度標籤。

也就是說，資料在哪、權限就在哪、答案的邊界就在哪。

但單靠「有資料」還不夠，要讓 Copilot 更懂行話與脈絡，得把外部或分散的系統資料也帶進 Graph，例如知識庫、工單、產品手冊等。

這正是 Copilot 連接器（Connectors）與Copilot 擴充模式存在的理由，把非 M365 的內容索引進來，讓語意搜尋與 Copilot 能「看見」並據此推理。

從「檔案堆」到「知識庫」：用 SharePoint 打造可被 Copilot 理解的結構

不只是在某個應用裡試功能，而是要把企業既有檔案升級成可組織、可檢索、可推理的知識庫，在 SharePoint Online 中的資訊架構（Information Architecture）有幾個核心積木如下：

1. 欄位與內容類型（Content Types）：先定義有哪些文件型別?每種需要哪些欄位？，像是〈安裝指南〉、〈故障排除〉、〈維護紀錄〉，

=> 內容類型讓你把模板、必要欄位、命名規則一次打包、全站共用。

2. 受管控中繼資料（Managed Metadata/Term Store）：把專有名詞變成可治理的詞彙集（Term Set），例如「產品線／版本」、「地區」、「合約方案」，之後標記與搜尋全都靠這些詞彙統一語言。

3. 跨站發布與治理：將內容類型集中發布到所有團隊站台，讓每個文件不只是放進資料夾，而是被清楚的宣告它是什麼。

為什麼這樣做能幫到 Copilot？ 因為語意搜尋與Copilot 的grounding會利用你的中繼資料與一致的結構來理解「你到底在找什麼」，換句話說，框得越清楚，Copilot 越像懂行的同事。

Copilot × SharePoint：把「框選」變成能互動的入口

• 站台級 Copilot：每個 SharePoint 站現在都能開啟站台專屬的 Copilot，讓使用者用自然語言與該站內容互動；也能把它共享到其他 M365 體驗中。
  => 這就是把「知識域」直接變成對話入口的做法。

• Copilot in SharePoint 的著作體驗：不只查找內容，還能從提示建立頁面、重寫段落、套用設計建議，把零散知識快速編成可讀、可用的頁面。

• Copilot Pages：把會話中的精華一鍵收斂成可編輯、可分享的頁面，讓「對話產物」直接長成知識庫的一部分。

參考來源

五步驟，把「文件堆」升級成「可對話的知識域」

Step 1：選定業務域
從最痛的業務流程開始，例如「售後維運」。定義此域的邊界：涉及的產品、地區、合約、SLA、常見異常代碼。

Step 2：建站與雛型
在 SharePoint 建立「售後知識庫」站台，先行規畫文件庫與頁面類型；用 內容類型定義〈安裝指南〉、〈維修手冊〉、〈RCA 報告〉等，欄位包含「產品線」「版本」「故障代碼」「環境」「SLA 等級」。

Step 3：語彙治理
在 Term Store 建立產品樹、地區、版本與故障代碼的詞彙集；導入同義詞（例如「FW=韌體」「PSU=電源模組」），讓搜尋與 Copilot 都懂你的口語。

Step 4：內容轉製與著作
把零散檔案搬進來並補齊欄位；用 Copilot in SharePoint 快速把舊版 Word/PDF 摘要為知識頁，並產生導覽卡與內鏈。

Step 5：讓 Copilot「看見」與「守規」
若有外部系統（如 CRM/工單），用 Copilot 連接器把資料帶進 Microsoft Graph；同時檢查站台擁有者、分享設定與過度開放的內容，確保 Copilot 回答遵守最小權限。

把第五法則投射回前四法則：一個「售後維運」的日常

• 法則一（場景為起點）：在 Teams 的維運群組直接對 Copilot 說：「只限『售後知識庫』站台的內容，把昨晚 P1 事件相關〈RCA〉與〈維修手冊〉找出來，整理成客服話術。」此時 Copilot 的 grounding 就落在你框好的站台與詞彙。([TECHCOMMUNITY.MICROSOFT.COM][6])
• 法則二（摘要穿越森林）：請 Copilot 針對同一故障代碼，對 5 份舊 RCA 做異常根因比較與解法差異摘要，生成 QA 清單與危害矩陣，再貼回知識頁。([Microsoft Support][7])
• 法則三（時光倒轉）：讓 Copilot 回顧半年內同型號的 P1/P2 事件，列出回溯趨勢與平均修復時間，並標注涉及的版本與區域。這些關鍵欄位都來自你在內容類型與 term store 裡的設計。
• 把成果沉澱：把對話產出轉成 Copilot Pages 或 SharePoint 站內頁，指派站台擁有者每週巡檢，確保知識持續新鮮。

做到「可對話」還不夠：做一個「可委派」的專屬代理

當把知識域框清楚後，就可以用 Copilot Studio 做「售後助理」：

• 直接把「售後知識庫」站台或清單當成知識來源接上去。
• 若需要跨系統（例如取訂單／序號），再串預建或自訂外掛/連線器。
• 讓代理在 Teams、Web、甚至外部入口都能回答一致的話。
  這種客製代理既沿用你剛才的資訊架構，又能以企業的流程語言回應。

安全與治理：把邊界畫在「正確的地方」

別忘了「框選」也包含權限與治理：Copilot 天生就繼承身分、權限與敏感度標籤，所以該看的才看得到；而在 SharePoint 端，請落實站台擁有者、分享清理與存取審查，降低不小心分享太多的風險，這些治理步驟是讓 AI 安全落地的關鍵。

總結

第五法則的精髓，是把 Copilot 從「萬事問的百科全書」變成懂你行話的業務顧問，先劃出知識域，再讓 Copilot 在這個邊界盡情發揮能力 ，資訊架構（內容類型＋中繼資料＋治理）就是它的路網，而站台與自訂代理就是它的交通工具。

當這些拼圖扣上，前四法則不再只是技巧，而是每天都能複用的知識生產線。