昨天存進 Confluence 的五頁日誌裡，有幾個詞是順手打進去的，但卻還沒真的搞懂像是 MCP 跟 Copilot Studio 到底整合到什麼程度？Copilot Studio 內建的知識來源跟自己建的檢索差在哪，日誌上把這些歸在「待驗證事項」，用比較白話一點的敘述就是：其實知道根本自己不知道。

遇到這種事，一般的下一步是打開搜尋框去做搜尋的行為，但是今天換一個起點我們改從日誌開始。

分工：日誌負責出題，查詢負責填空

這件事情說穿了是「把日誌裡不懂的詞查清楚」，但人跟 AI 怎麼分工，決定了查出來的東西有沒有地方放。

人負責的部分昨天就做完了：這週在做什麼、目標是什麼、有哪些限制、哪些前提在自己的環境不成立，還有一串「待驗證事項」跟「明日規劃」，這些只有寫日誌的人知道

AI 查不到。

AI 負責的部分是往外查，例如每一條待驗證事項，官方怎麼說、別人怎麼做、往下還牽出哪些概念。這些是公開資訊，它查得比人快。

所以整體的順序事可以這樣，先有日誌查回來的東西才有地方掛，如果是反過來先查，反而會抱著一堆資料不知道該放在哪。（然後會有一種好像已經把事情做完的幻覺...）

關鍵資訊鏈是從日誌裡抽出來的，查的動作只是負責把資訊鏈上的空格填滿。

從終點往回拆：一棵樹長什麼樣

那今天要產出的東西想成一棵樹，分三層：

• 根：日誌裡已經寫好的東西。這週的目標、限制、在自己環境不成立的前提。這一層不用查，昨天寫完了。
• 枝幹：日誌裡的「待驗證事項」跟「明日規劃」，每一條都是一個還沒有答案的問題，也是一段可以繼續往外延伸的枝幹。五頁日誌抽出來是七條。
• 葉：從外面查回來的東西，每一片葉子都要掛在某一根枝上，而且要寫清楚從哪裡摘的，掛不上去的葉子內容再好也不屬於這棵樹。

來源至少分兩種

往外查的時候，網路搜尋跟官方文件回答的問題不一樣。網路搜尋回答的是「別人怎麼做」，官方文件回答的是「這個東西本來怎麼運作」。前者是別人踩過的坑，後者是設計上的邊界。

麻煩的是兩邊說法不一致的時候。部落格寫著某個功能可以這樣接，官方文件寫著這條路徑不支援。這時候最不該做的事，就是讓 AI 自己選一邊講給你聽，因為講出來的答案會非常順，順到看不出中間曾經有過衝突。所以每一片葉子都要標來源，目的是讓衝突浮出來。

四站流程

把上面的想法排成順序，整條流程是四站：

1. 從日誌抽出根與枝幹
2. 接官方來源逐條驗證，往下長一層
3. 把整棵樹交回去，要可行性方案
4. 把樹寫回日誌

每一站只放一個目標，每一站的產出是下一站的輸入。

順便講一下 Microsoft Learn MCP server

日誌裡一半的待驗證事項都是微軟生態的東西，所以官方文件這一路直接接 Microsoft Learn 的 MCP server，不再靠搜尋引擎撈。

它是一個遠端的 MCP server，端點是 https://learn.microsoft.com/api/mcp，不需要驗證也不收費，內容是公開的 Learn 文件，底層知識庫每天做一次完整更新。提供三個工具：microsoft_docs_search 做語意搜尋、microsoft_docs_fetch 把整頁抓成 markdown、microsoft_code_sample_search 找範例程式。官方也明講，這不是傳統意義的 API，工具清單會變，用的時候要透過 agent 框架或 MCP client 接，不要自己打端點。

跟昨天接 Atlassian 的差別在於，這條線不牽涉個人權限，它只讀公開文件，所以裝起來比 Rovo 那組簡單很多。對話介面如果支援遠端 MCP server，填那個 URL 就接上了；如果不支援，退一步用網路搜尋加上 site:learn.microsoft.com 也能走完今天的練習，只是每一條要自己點進去確認。

接上之後，日誌裡的每一條待驗證事項都可以指回一個官方頁面。這件事對後面很重要，因為可行性評估要站得住，靠的是每一個技術宣稱後面有沒有一個查得到的來源，而不是個人的理解。

今天的收束：把不知道，變成下一次接得回來的問題

回頭看今天做的事，並不是把幾個不懂的名詞查完而已，而是替「不知道」安排一個能繼續工作的結構。
1.日誌先留下目標、限制與現場脈絡，成為知識樹的根
2.待驗證事項與明日規劃把空白變成一段段可以追查的枝幹
3.官方文件、實作經驗與內部紀錄則帶著各自的來源，補成往外生長的葉。

這也是為什麼查詢不能單獨存在，從日誌抽出根與枝幹、用官方來源逐條驗證、根據整棵樹提出可行方案，再把查到的事實、仍有衝突的說法與下一步寫回去，四站走完之後，資料才不會停在搜尋結果裡。

Microsoft Learn MCP 只是讓官方文件這條路走得更直接，更重要的是每一個技術宣稱都保留來源，每一個找不到答案的地方也留在原位，等待後續實驗。

到這裡我們已經知道這棵樹應該怎麼長，但還沒有真的把它種進每天工作的地方。下一篇會直接拿前幾天累積的日誌動手做：先在 Confluence 建立「個人工作脈絡」，再用官方來源擴充尚未確認的項目，最後比較互相排斥的實作方案，並把結果寫回原本的脈絡。原本的四站也會在實際操作裡收成三站，看看從日誌長出來的知識樹，能不能開始支撐下一次工作的技能樹。

今天先替空白找到位置與來源；明天讓它變成可以反覆使用的工作脈絡。