[知識庫 1] 當新人第一天，就能答出只有資深工程師才知道的答案

不是把檔案丟進 AI，而是把公司的經驗，煉成一座問得到、信得過、不外洩的知識庫。

那個只有王小明知道的答案

凌晨三點，客戶的主機服務掛了。運維工程師王小明趕到現場，翻日誌、發現是記憶體被批次作業吃光，調整排程後重開機，恢復。整件事處理得漂亮——然後解法被寫進他自己的筆記本裡。

三個月後，同樣的問題在另一個客戶端重演。這次值班的是剛報到兩週的新人。他查不到任何東西，只能打電話把王小明從床上挖起來。

這不是誰的錯。這是絕大多數企業的日常：公司最值錢的知識，存放的位置叫「某個資深員工的腦袋」。它不會出現在任何資產清單上，但它會離職、會請假、會在凌晨三點關機。

你其實不缺知識，你缺的是「找得到、敢用、敢信」

多數公司不是沒有累積知識，而是知識散在四個找不回來的地方。

一個 90 分鐘的客戶需求訪談錄音躺在硬碟裡，會後沒人想重聽；三週後大家對「客戶到底要不要那個匯出功能」各說各話。安裝 SOP 存在共用資料夾的第七層目錄，新人得靠運氣或爬 Line 群組的樓才翻得到。客戶的維護合約、SLA、報價單在業務的信箱裡，工程師想查「這個客戶保固到什麼時候」只能四處問人。

而那些真正重要的文件，往往含個資、含客戶 IP、含帳號密碼——所以乾脆不分享，或是人工塗黑，塗到自己也不確定乾不乾淨。就算現在把它們丟給 AI 工具，得到的答案也沒有依據，你不知道它從哪裡讀來的、對不對、能不能拿去跟客戶講。至於「誰能看什麼」，靠的是資料夾權限硬切，設錯一次就是一次外洩。

這四件事——找不到、不敢共享、不敢信、權限難維護——才是知識管理真正卡住的地方。

一段錄音，變成一個新人問得到的答案

以下用「鼎峰系統整合股份有限公司」第一系統開發部（示範情境）走一遍。這是王小明那次凌晨故障的現場交接錄音，逐字稿長這樣：

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

雜亂、口語、而且含著三樣絕對不該外流的東西：客戶 IP、帳號、密碼。

系統把它送進清洗程序——去重、遮罩、分類、摘要——出來的是這樣：

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

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

再蒸餾一次，它變成一頁可被互相連結的知識概念頁：

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

於是三個月後的那個新人，不用再打電話。他在知識庫問答頁打一句話：

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

系統回答：

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

注意兩件事。第一，答案附出處，點下去可以一路鑽回當初匯入的原始檔——這是「敢信」的前提。第二，帳號、密碼、客戶 IP 一個都沒出現——它們在進入知識庫之前就被遮掉了。

為什麼你敢把合約也放進去

大部分企業卡在「不敢丟進去」，所以這套系統把安全做成兩條不可違反的鐵則。

第一條：遮罩失敗，整筆清洗就算失敗。 不是「盡量遮」，而是遮不乾淨就整筆退回重跑。寧可多跑一次，也不讓沒遮乾淨的內容流向下游。

第二條：你無權看的，問答絕不會吐給你。 權限不是綁在資料夾上，而是綁在「團隊」上，而且在每一次查詢當下即時驗證。實際跑起來是這樣的：王小明（運維組）問「客戶主機半夜服務中斷怎麼處理」，拿到附出處的完整答案；李四（開發組）問一模一樣的問題，系統回覆查無相關資料——因為那批運維知識不在他的可見範圍內，檢索階段就沒被撈出來。

同一個機制也延伸到公司外。當工程師想在自己慣用的 AI 工具（Claude、Codex 等）裡直接查公司知識時，系統開放一個標準端點；換一組憑證，就換成那個人能看的範圍，與網頁上完全一致。合約與 SLA 這種只有業務該看的東西，開發人員即使透過外部 AI Agent 也查不到、甚至查不出它存不存在。

那知識會過期，會不會變成一座檔案墳場？

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

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

你只要從「更新原料」開始，下游會自己刷新。

導入之後，具體會變成什麼樣子

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

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

但比數字更重要的是：這些品質是可以被量出來的，不是喊口號。 系統內建兩道評測——一道量「清洗到底乾不乾淨」（該遮的有沒有遮掉、該保留的重點有沒有被誤刪），一道量「檢索找不找得到、準不準，以及越權洩漏是不是等於 0」。你可以把它們當成知識庫的回歸測試：每次餵入新素材、每次調整設定，跑一次就知道品質有沒有退步。

知識管理最常見的失敗，是導入之後沒人知道它到底有沒有用。能被量測，才有辦法被改善。

如果你也有一個「只有某某某才知道」的答案

老手經驗難傳承、新人上手慢、敏感資料不敢共享——如果這三句話有一句戳中你，那你要的可能不是另一套文件管理系統，而是一條把散落素材煉成可信知識的產線。