[知識庫 2] 他交接了十五頁文件，卻帶走了三年的答案

資深員工離職那一天，公司損失的不是一個人力，而是一整座從未被寫下來的知識庫。

交接完成的那一天

陳志遠在鼎峰系統整合（示範情境）待了 12 年，是第一系統開發部的資深項目經理。從公司只有八個人的時候就在，一路帶過的客戶案子超過三十個。

離職流程走得非常漂亮。一個月預告期，三場交接會議，十五頁的交接文件，附上專案清單、客戶聯絡窗口、系統帳號一覽、待辦事項移交表。人資核對完交接單，簽名，結案。同事在會議室切了蛋糕，拍了照。所有流程都對，沒有任何人犯錯。

三個月後，公司才開始意識到一件事：「交接完成」和「知識已經移轉」，是完全不同的兩件事。

三個月後陸續送到的帳單

第一張帳單在第五週送到。老客戶打來問，去年那個案子的維護報價為什麼是這個數字，能不能比照今年續約。接手的專案經理翻遍了報價單、合約、往來信件，找得到「報價多少」，但找不到「為什麼」——當初那個數字是陳志遠評估過客戶機房的特殊環境、加上一段口頭承諾的到場時效後算出來的。這段推算，只在一場沒有錄音的會議裡發生過。最後公司選擇照舊價續約，少賺的部分沒人算得出來。

第二張帳單在第八週。團隊在新案子上選了一套中介軟體，做到一半才發現與客戶端既有系統相衝，回頭重做兩週。而三年前，鼎峰在另一個客戶身上踩過一模一樣的雷——那次是陳志遠處理的，記錄在一封當時的內部信裡，沒有人知道要去哪裡找那封信。

第三張帳單在第十一週的凌晨三點。客戶主機服務中斷，值班工程師翻共用資料夾翻了四十分鐘，最後還是打電話給已經離職的陳志遠，對方在電話裡花了兩分鐘講完處理方式。

還有一些帳單沒有金額，但更難處理。客戶開始問「你們公司是不是換人了」。新的專案經理不敢對客戶承諾任何事，因為不確定過去答應過什麼。這些成本不會出現在任何一張財報上，但每一筆都是真的。

為什麼交接一定會漏，而且不是誰的錯

這裡要講一件對經營者最重要的事：問題不在陳志遠不肯寫，也不在交接文件寫得不夠認真。是因為交接文件本來就裝不下那些東西。

十五頁的交接文件，能裝得下的是流程——這個案子做到哪、誰負責什麼、帳號密碼在哪。而真正值錢的，是判斷：

為什麼那家客戶的報價要多加一成？為什麼那條線路不能碰？為什麼這個錯誤訊息看起來像 A 問題，其實通常是 B 造成的？哪個客戶的窗口一定要先發信再打電話？這些沒有一條寫得成 SOP，它們是三年、五年、十二年一次一次踩出來的。

而且它們並不是不存在，只是存放的位置很尷尬：一場 90 分鐘的客戶訪談錄音（會後沒人想重聽）、一封三年前的內部信、一張現場拍的機房照片、一段隨手記在筆記本上的處理步驟、一份被改到 v7 的簡報。它們散落在錄音檔、硬碟、信箱、聊天群組裡，理論上都還在公司，實際上等於不存在——因為沒有人找得到，也沒有人有時間去找。

要一個人在離職前一個月，把 12 年的判斷寫成文件，這件事在物理上就做不到。所以正確的問法不是「怎麼把交接做得更完整」，而是「怎麼讓知識在他還在職的每一天，就持續被留下來」。

如果這些素材，當初有被煉成知識

這就是知識庫系統要解決的事。它不是雲端硬碟，也不是把檔案丟給 AI 就算了——而是一條把「原料」煉成「可查詢知識」的產線。

看一個實際的例子。這是一段客戶現場交接的口語錄音逐字稿，雜亂、口語，而且含著三樣絕對不該外流的東西：

嗯…就是那個客戶 192.168.10.5 那台主機啊，帳號 admin 密碼 P@ssw0rd 那個，
半夜三點服務就掛掉，啊我看 log 是記憶體不夠，就…就先把那個排程改一下，
然後重開機就好了啦，啊王先生你記得跟李小姐講一下喔，下個月要去複查。

系統把它送進清洗程序——去除贅字、遮蔽敏感資訊、分類、摘要——出來是這樣：

## 客戶主機服務半夜中斷處理

- **問題**：客戶主機（IP 已遮罩）每日凌晨服務中斷。
- **原因**：記憶體不足。
- **解法**：調整排程後重新開機即恢復。
- **待辦**：下個月安排複查。

再進一步蒸餾，它變成一頁可以互相連結的知識概念頁，跟其他相關知識串在一起：

# 記憶體不足導致服務中斷
當主機記憶體耗盡時，服務會被作業系統終止。常見於凌晨批次作業疊加。
處理方式參見 [[重新開機標準程序]] 與 [[排程調整]]。

於是第十一週凌晨三點的那位值班工程師，不需要打電話給已經離職的人。他打一句話進系統：

「客戶主機半夜服務掛掉怎麼辦？」

得到的回答是：

通常是記憶體不足造成。建議調整批次排程後重新開機即可恢復；並安排後續複查。
〔出處：客戶現場維運交接錄音 → 原始逐字稿〕

請注意兩件事。第一，答案附著出處，點下去可以一路追回當初那份原始錄音——所以他敢照著做，主管也查得到依據。第二，客戶 IP、帳號、密碼一個都沒有出現——它們在進入知識庫之前就被遮掉了。

關鍵不在於「離職前趕快把東西丟進系統」，而是這些素材在陳志遠還在職的每一天，就已經被持續煉成可查詢的知識。離職那天，只是換一個人來問同一座知識庫而已。

老闆真正會擔心的兩件事

聽到「把公司資料集中起來、還讓 AI 能查」，經營者第一個反應通常不是興奮，是緊張。這很合理，所以這套系統把安全做成兩條不能違反的鐵則。

第一條：遮蔽失敗，整筆就算失敗。 不是「盡量遮」，而是只要沒遮乾淨，整筆內容直接退回重跑，絕不放行到下游。寧可多跑一次，也不讓客戶的帳號密碼流進誰都查得到的地方。

第二條：你無權看的，系統絕不會答給你。 權限不綁在資料夾上，而是綁在「團隊」上，而且在每一次查詢的當下驗證。合約與 SLA 標成業務團隊的內容，工程師查不到，甚至查不出它存不存在；運維團隊的故障知識，開發人員問一模一樣的問題也會得到「查無資料」。同樣的規則也延伸到公司外——工程師若想在自己慣用的 AI 工具裡查公司知識，換一組帳號，就換成那個人能看的範圍，一模一樣。

這代表你可以把合約、報價、客戶資料都放進去，而不是只敢放那些本來就無所謂的東西。 而知識庫的價值，恰恰就藏在那些「本來不敢放」的內容裡。

那它會不會變成另一座檔案墳場

會，如果沒有更新機制的話。所以更新被設計成一條可以重跑的產線。

合約續約了、SOP 改版了，承辦人對原檔案按「上傳新版本」，系統自動建立版本鏈：新版標成 v2，舊版標示「已被取代」，版本歷史可回溯稽核。接著自動重新清洗、重新蒸餾、重建索引。下次有人問，答到的就是新版內容，出處指向 v2。

你只要從「更新原料」開始，下游會自己刷新。 知識庫不會因為沒人維護就悄悄過期成一堆謊話。

能被量測，才能被改善

以一般知識管理導入經驗為基準，這是合理的導入目標與期望值（並非實測保證值，實際成效取決於餵入多少素材、清洗品質與團隊使用習慣）：

• 找答案的時間：從「半小時翻檔案＋問人」縮短到「1 分鐘問知識庫」，查詢效率約提升 10 倍。
• 新人上手週期：從 1～2 個月縮短到 2～3 週，約縮短 50%。
• 重複求助與重複犯錯：同類問題重複發問下降 60% 以上。
• 敏感資料外洩風險：因強制遮蔽且「遮蔽失敗＝整筆失敗」，外洩風險趨近於 0。

但對經營者來說，比數字更重要的是一件事：這些品質是可以被量出來的。 系統內建兩道評測——一道量「該遮的有沒有遮掉、該留的重點有沒有被誤刪」，一道量「問題找不找得到、答得準不準，以及有沒有任何一筆越權洩漏」。它們可以像回歸測試一樣定期跑，讓你知道這項投資的品質是在進步還是退步。

知識管理最常見的死法，不是導入失敗，是導入之後三年沒人說得清楚它到底有沒有用。

下一個遞辭呈的人，會是誰？

陳志遠的故事不特別。每一家有十年以上歷史的公司，都有兩三個「不能走的人」——不是因為他們的職位不能取代，而是因為只有他們知道那些從來沒被寫下來的答案。

你沒辦法保證他們不走。但你可以決定：他們走的時候，帶走的是一份工作，還是一整座公司的記憶。