讓團隊知識找得到、用得上

多數團隊說「知識管理」，做出來的是一個越堆越深的共用資料夾，或一套沒人更新的內部 wiki。我們也走過類似的路。AiTOM 源點的工作每天都在產生決策、規格、研究筆記和交接說明，而且不只人在寫，Claude 與 Codex 這幾個 AI 助理也在寫。如果這些內容留在某個人的腦袋、某一段聊天紀錄，或某個 AI 的私人對話裡，下一次接手的人就得從頭問起。所以在對外談如何協助企業之前，我們先把這件事在自己身上做了一遍。

起點

我們一開始遇到的是很務實的問題：資料散在不同地方，同一件事有好幾個版本，沒有人能確定哪一份才算數。AI 助理加入之後，問題更明顯。AI 很會把話說得流暢，但早期它寫出來的段落常常沒有出處，讀起來像是對的，卻無法回頭驗證。再加上聊天視窗一關，上下文就消失，工作無法順利接續。

我們把問題拆成三件事：第一，知識存在哪裡，才不會因為換工具而消失；第二，怎麼知道一筆內容是事實、觀察還是假設；第三，AI 給出答案時，能不能讓人看到依據。這三個問題的答案，後來變成我們整個知識做法的骨架。

我們怎麼做

核心原則只有一句：檔案是事實的來源。聊天紀錄只能當輔助，真正的專案事實、決策、成果與待辦，都寫進人類可以直接閱讀、可以放進版本控制的檔案裡。具體做了這幾件事：

• 知識一律存成與模型無關的可讀檔案，並放進版本控制，改動留得下紀錄，不靠任何單一 AI 的記憶。
• 每筆知識與決策都有穩定的識別碼，引用時指向識別碼，而不是模糊的「上次那份文件」。
• 內容區分事實、觀察與假設，並標註來源與日期。接手的人可以按日期核對，不需要猜測缺漏的記憶。
• 在資料夾之上建一層治理索引，我們稱為「DB infra」，記錄各資料夾的用途與變更事件，讓人和 AI 都能先查索引，再找內容。
• 規則與事實分開存放。規則說明「應該怎麼做」，事實記錄「實際發生了什麼」，兩者不混在同一份文件裡。
• 要求 AI 回答時引用來源。沒有來源的說法，只能標示為待查，不能當成結論。

這些做法看起來像是文書規矩，但它們真正解決的是接續性。任何一位 AI 助理或同事，在重新啟動之後，只要讀索引與相關檔案，就能知道目前進行到哪裡、為什麼這樣決定、下一步是什麼。

遇到的問題與調整

最先修正的是「流暢但沒有出處」。早期 AI 代寫的文字讀起來很順，卻很難查證。我們因此補上來源與證據規則：每個結論要附出處，找不到出處的內容降級為假設，並明確標示。這讓 AI 的文字從「看起來可信」變成「可以被檢查」。

第二個調整是範圍。當我們讓 AI 一次重新整理大量內容時，曾發現無關的頁面被悄悄改寫。後來我們改成限定每次變更的範圍，並在送出前檢查差異，確認只有預期的檔案被動到。

第三個調整是不覆寫。整理資料最容易出事的，就是以為自己在清理，實際卻把舊版本蓋掉。我們因此規定：保留版本，需要退回時用還原，而不是刪除。這個規矩後來也救過幾次場，因為歷史都還在，回頭比對才有依據。

改變了什麼

這件事帶來的改變多半是質的，而不是漂亮的數字，所以我們不編造任何百分比。我們能誠實說的是：接手一條工作線的成本變低了，因為索引、決策紀錄與工作樹都在檔案裡；AI 的回答可以追到來源，檢查的人知道該看哪裡；換用不同的 AI 助理時，知識不必重新建立，因為它本來就不屬於任何一個模型。

同樣重要的是，知識變成了可以逐步累積的資產。每一次決策、每一份研究都有識別碼和日期，之後的新判斷可以建立在舊紀錄上，而不是每次從零開始。

可以帶走的做法

• 先決定「事實放在哪裡」，再談工具。檔案加版本控制，通常是最耐用的起點。
• 替重要的知識取穩定的識別碼，讓引用不會因為改名或搬家而失效。
• 要求每個結論附來源與日期，並區分事實、觀察與假設。
• 為資料夾建立簡單的索引與變更紀錄，讓新來的人先查索引。
• 規則與事實分開寫，並且保留版本，需要時用還原代替刪除。
• 要求 AI 引用來源，沒有出處的內容標示為待查。

知識不是存起來就算數，而是下次有人需要時，找得到、信得過、接得上。