前幾天把 Hermes 的記憶、Company Brain 與 QMD 分層後,我遇到一個更實際的問題:網路上看到的文章、X 貼文、官方文件與 Google Drive 文件,怎麼進入公司知識庫,才不會變成一堆沒人敢用的複製貼上?
答案不是「看到好文章就存下來」,而是一條可追溯的 ingest 流程:先判斷來源,再查重、建關聯,最後才轉成可以執行的知識。
先把外部內容分成四類
我目前會先判斷來源類型,因為不同來源的可信度、保存方式與後續驗證方法不同。
| 來源 | 主要用途 | 必留資料 |
|---|---|---|
| 官方文件與產品文件 | 查 API、設定與限制 | URL、文件標題、發布或更新日期 |
| 技術文章與研究報告 | 理解方法與設計取捨 | 作者、來源網站、原文連結、擷取日期 |
| X、社群與討論串 | 發現問題、案例與趨勢 | 原始貼文 URL、作者、貼文日期、上下文 |
| Google Drive 文件 | 公司內部規則與實際紀錄 | 文件 ID、公司帳號、權限範圍、讀取日期 |
這個分類的重點,不是替來源打分數,而是避免把「別人的推測」誤寫成「公司的正式制度」。外部內容通常是參考資料;只有經過公司內部確認與核准,才可以成為 SOP 或正式規則。
第一關:先保留來源,再處理內容
我不會一開始就把全文搬進 Obsidian。先建立最小 metadata,讓未來任何人都能回答三個問題:這段話從哪裡來?什麼時候讀到?當時為什麼值得保存?
最小欄位可以長這樣:
其中 retrieved 不能省略。網頁會改版、貼文可能刪除、文件權限也可能改變;沒有讀取時間,就很難判斷筆記反映的是哪一個版本。
第二關:查重不是只比標題
同一個主題可能同時出現在官方文件、部落格文章與社群轉貼。只用標題查重,很容易留下三份看似不同、實際上重複的筆記。
我的查重順序是:先比原始 URL 或文件 ID,再比標題與作者,最後比內容摘要與關鍵實體。若是社群轉貼,保留原始貼文,不把轉貼內容當成第二個獨立證據。
查重的結果不一定是刪除。比較好的做法是保留多個來源,並在主筆記中標示它們的角色:哪一份是規格依據、哪一份是實作案例、哪一份只是觀察。這樣做比把所有內容揉成一篇「看起來完整」的文章更容易維護。
第三關:建立關聯,讓知識能被找到
一份孤立的文章摘要,即使內容正確,下一次遇到問題時也可能找不到。因此 ingest 的輸出不應該只有一個 Markdown 檔,還要建立它與現有知識的關聯。
例如一篇關於認證自動修復的文章,可以關聯到:
這裡有一個重要界線:關聯是索引,不是授權。文章提到「建議每小時檢查一次」,不代表公司就已經採用這個頻率。筆記中要把現況、推論、建議與待核准分開寫。
第四關:從摘要轉成可執行知識
外部研究真正有價值的地方,不是保存了多少文字,而是能否轉成下一次可重複使用的判斷。
我會把內容整理成四段:
如果讀不到正文,就只保存可確認的 metadata 與缺口,不補寫內容。這個規則看似保守,卻能避免知識庫充滿模型「合理猜出來」的段落。
PDF 與敏感文件的特殊處理
PDF 先擷取文字層,再檢查頁碼、表格與圖片中的重要資訊。擷取失敗時要留下失敗狀態,而不是假裝已完成。對 Google Drive 或公司內部文件,保留文件 ID 與權限來源即可,不任意複製敏感全文到其他位置。
公司資料還要明確標示使用哪個帳號讀取。之前遇到過個人帳號讀取公司文件得到 403 的情況;這不只是登入問題,也是資料邊界問題。來源 metadata 寫清楚帳號與權限範圍,未來才不會把「目前讀不到」誤判成「文件不存在」。
今天的驗證清單
完成一筆 ingest 後,我至少會檢查:
這套流程的產物不是「一篇漂亮摘要」,而是一筆之後查得到、驗得回、能繼續更新的知識。對 Agent 來說,來源保留與 metadata 就像資料庫的主鍵;沒有主鍵,再好的內容也會慢慢失去可信度。
下一篇會進一步談 Skills:如何把已經驗證過的工作流程保存成下次不用重想的能力。