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

不是把檔案丟進 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」。你可以把它們當成知識庫的回歸測試：每次餵入新素材、每次調整設定，跑一次就知道品質有沒有退步。

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

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

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

[知識庫 5] 當場答不出來的那一句，就是丟單的那一句

「我回去確認一下再回覆您」——這句話說出口的那一刻，你已經把案子的主導權交出去了。

會議室裡那三秒鐘

黃振傑在鼎峰系統整合（示範情境）做業務六年，那天下午帶著售前工程師去客戶端做第二次簡報。

簡報講得很順。到了 Q&A，客戶的 IT 主管翻著手上的資料問了三個問題。

第一個：「你們這套跟我們現在用的門禁系統，之前有整合過嗎？」

有。三年前有一個案子做過幾乎一樣的整合。但黃振傑不確定是哪個客戶、也不確定當初用什麼方式接的，更不敢貿然說出客戶名稱。他說：「這個我回去確認一下。」

第二個：「同規模的案子，你們大概報多少？」

他心裡有個範圍，但不確定上一個類似規模的案子最後成交價是多少、有沒有含第一年維護。報高了對方會覺得貴，報低了回公司要被主管檢討。他說：「我整理一份給您。」

第三個最傷：「上次貴公司來提案的那位，說可以支援我們現有的資料格式，這個還算數嗎？」

上次來的不是他。他完全不知道同事答應了什麼。他說：「這個我要跟同事確認。」

三個問題，三次「回去確認」。

會議結束前，客戶的 IT 主管講了一句很客氣的話：「好，那你們整理好再給我，我們也還在看其他家。」

在提案現場，客戶問的不只是問題，還在量一件事：這家公司到底熟不熟。而你每說一次「回去確認」，那個刻度就往下掉一格。

你不是準備不足，是公司的經驗沒有站在你這一邊

如果你是業務或售前，你大概很清楚：這三個問題的答案，公司裡百分之百是有的。

第一個問題的答案，在三年前那個案子的結案報告裡，或是在當時售前工程師的信箱裡。

第二個問題的答案，在報價系統或某個人的 Excel 裡，但你不知道要比對哪一筆才算「同規模」。

第三個問題的答案，在上一次那場會議的錄音裡——如果有錄的話——或是在提案簡報 v5 的第 12 頁備註。

它們理論上都在公司，實際上等於不存在。因為你在客戶會議室，你有三秒鐘，而不是三小時。

更麻煩的是，這些經驗大部分綁在人身上。做過那個整合案的工程師去年離職了；知道成交底價的主管在開會；上次來提案的同事調去別的部門。你能問到誰、問得多快，決定了你這一單的勝率——而這件事完全靠運氣。

所以真正該問的不是「業務要怎麼準備得更充分」，而是「公司六年的專案經驗，能不能在會議室裡那三秒鐘被你叫出來」。

一場沒人聽第二次的售前錄音，變成你當場答得出的一句話

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

三年前那個門禁整合案，其實留下了一場售前技術會議的錄音。逐字稿裡有一段是這樣的：

…他們那個門禁是舊的那套，資料庫直接讀不到，所以我們最後是走
他們內部的 10.20.30.40 那台中介機，用排程每十五分鐘同步一次啦。
本來想接 API，但他們原廠不給。啊這個案子最後折到七九折成交，
含第一年維護，這個底價不要往外講喔。

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

## 舊版門禁系統整合方式

- **限制**：舊版門禁系統原廠不開放 API，資料庫無法直接存取。
- **採用方案**：透過客戶內部中介主機（位址已遮罩），以排程每 15 分鐘同步一次。
- **適用情境**：客戶既有門禁系統為舊版、且原廠不提供介接介面時。

再進一步蒸餾，它變成一頁可以互相連結的概念頁：

# 原廠不開放 API 時的整合路徑
當既有系統無法直接介接時，優先評估中介主機＋排程同步。
需向客戶說明資料非即時、同步間隔可調。
相關做法參見 [[排程同步間隔設定]] 與 [[整合可行性評估清單]]。

於是下一次有業務在客戶會議室被問到同一件事，手機或筆電上打一句話進系統：

「舊版門禁系統原廠不給 API，有做過嗎？」

當場得到的是：

有。做法是透過客戶內部中介主機、以排程每 15 分鐘同步，適用於原廠不開放介接的舊系統。需向客戶說明資料非即時。
〔出處：售前技術會議錄音 → 原始逐字稿〕

差別有多大？原本你會說「這個我回去確認一下」，現在你可以說：「有，我們做過。原廠不給 API 的狀況我們走中介機排程同步，十五分鐘一次，非即時這點要先跟您說清楚。」

同一個問題，第一種回答讓你變成傳話的人，第二種回答讓你變成懂的人。而客戶只買後面那一種。

底價、折扣、承諾過的話，敢不敢放進去

看到這裡你可能會想：整合做法可以放，但成交底價、折扣權限、上次答應客戶什麼——這些也放進去嗎？

這正是這套系統最關鍵的設計，兩條不能違反的鐵則。

一條是遮蔽失敗，整筆就算失敗。客戶內部主機位址、窗口私人號碼這類東西，不是「盡量遮」，而是只要沒遮乾淨，整筆內容直接退回重跑，絕不放行到下游。

另一條是權限綁團隊、每次查詢當下驗證。成交價、折扣底線這類商務資訊標成業務團隊可見，工程師查不到；反過來，工程師團隊的維運細節，業務問一模一樣的問題也會得到「查無資料」——不會出現「有資料但你無權查看」這種等於洩漏的提示。同一套規則也延伸到公司外：你想在自己慣用的 AI 工具裡查公司知識，換一組帳號就換成那個人能看的範圍，一模一樣。

這代表你可以在客戶面前，安全地帶著公司六年的成交經驗上談判桌。而業務最值錢的那些資訊，恰恰全部都在「本來不敢放」的那一區。

那三年前的做法，現在還算數嗎

好問題，而且是業務最不能出錯的地方——照著一個過期的答案對客戶承諾，比答不出來還糟。

所以更新被設計成一條可以重跑的產線。原廠後來開放 API 了、報價政策調整了、標準做法換了，承辦人對原檔案按「上傳新版本」，系統自動建立版本鏈：新版標成 v2，舊版標示「已被取代」，版本歷史可回溯稽核，接著自動重新清洗、重新蒸餾、重建索引。

下次你在客戶面前查到的，是現在有效的做法，不是三年前有效的做法。

三次「回去確認」的真正代價

以一般知識管理導入經驗為基準，找答案的時間可以從半小時翻檔案加問人，壓到一分鐘內問到，效率約提升十倍。這是合理的導入目標與期望值，並非實測保證值，實際成效取決於餵進多少素材與團隊的使用習慣。

但業務算的從來不是這種帳。你算的是這個：

三次「回去確認」，換來的是提案週期多拖一週，客戶在這一週裡又見了兩家；換來的是你回公司要追三個人、寫一封信、等一份報價；換來的是下次會議你得先花十分鐘把上次沒答的補完，而不是直接談合約條件。

最貴的那一項還沒算：客戶心裡把你歸類成「窗口」，而不是「顧問」。 窗口只能比價，顧問才能談價。

黃振傑那個案子最後沒有輸在價格，是輸在對方選了一家「感覺比較熟這塊」的廠商。

你的公司做過的每一個案子，本來都該站在你身後

你們公司做過的案子不會比對手少。差別只在於，對手的業務可能在會議室裡叫得出那些經驗，而你叫不出來。

這不是誰比較認真的問題，是公司有沒有把六年的經驗煉成一個問得到的地方。

[知識庫 4] 別再說「我幫您查一下，稍後回覆」

客戶要的從來不是你查得認真，是你答得出來。

一個上午，這句話說了九次

林郁婷在鼎峰系統整合（示範情境）的客戶服務部，做技術支援第三年。她的工作台上開著五個視窗：工單系統、客戶名單、共用資料夾、公司內部群組，還有一份自己整理的 Excel，裡面是她這三年來慢慢抄下來的「常見狀況與處理方式」。

那份 Excel 是她最重要的資產，也是她最大的焦慮來源——因為它只有 137 列，而客戶的問題有無限多種。

那天上午九點到十二點，她說了九次「我幫您查一下，稍後回覆您」。

第一次，客戶問去年買的模組能不能相容新版系統。她翻工單，翻不到；問群組，沒人回；最後找到當初的售前工程師，對方在客戶端出差，晚上七點才回訊息。

第三次，客戶說設備顯示某個錯誤代碼。她印象中兩年前有人處理過一模一樣的，但那是在一個已經沒人用的舊聊天群組裡，往上滑了二十分鐘沒滑到。

第七次最傷。客戶在電話裡說：「你們上個月有另一位同事跟我講的不是這樣。」她當下答不出來，也查不到上個月那通電話的內容。掛掉電話之後她坐了三十秒，那三十秒她想的不是問題怎麼解，而是客戶剛剛是不是覺得這家公司不專業。

十二點的時候，她真正解決的問題是三個。其餘六個變成待辦，帶到下午，有兩個帶到明天。

在第一線工作的人都知道，最消耗人的從來不是難的問題，是那些「公司裡明明有人知道，但你就是問不到」的問題。

這不是你不夠努力，是答案根本沒被放在你找得到的地方

如果你也是客服或技術支援，你大概很熟悉這種感覺：明明是自己份內的事，卻總覺得自己在猜。

但問題真的不在你。你可以把公司裡「那個問題的答案」在哪裡，列出來看看：

它可能在一張三年前的工單裡，只是當初結案時只填了「已處理完成」四個字；可能在一封資深工程師寄給客戶的信裡，而那封信在他的個人信箱；可能在一場售前會議的錄音檔裡，檔名叫「錄音_20240311.m4a」；可能在一個已經沒人用的群組訊息裡；也可能誰都沒寫下來，只在某個人的腦袋裡，而那個人今天請假。

這些東西理論上都還在公司，實際上等於不存在——因為找不到、或是找到的成本高過重問一次。於是最有效率的做法變成「問人」，而問人這件事，會塞住兩個人的時間，還會隨著資深同事離職而斷掉。

你不缺資料，你缺的是一個問得到答案的地方。

第一線最需要的不是更完整的知識庫，是更快的那一句回答。

一張三年前的工單，變成一個你三秒查得到的答案

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

看一個實際的例子。這是一段客服電話的口語紀錄，雜亂、口語，而且夾著幾樣絕對不能外流的東西：

喂您好，那個…宏泰的張淑芬張小姐是不是，電話 0912-345-678 這支對嗎，
訂單編號 SO-2023-1147 那筆。啊她說那台設備一開機就跳 E-207，
我跟她講那個通常是韌體版本太舊，跟新的控制模組對不起來啦，
就先降回舊版韌體，然後排時間現場更新模組。她說好，那就下週三。

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

## 設備開機顯示 E-207 錯誤

- **現象**：設備開機後顯示錯誤代碼 E-207。
- **原因**：韌體版本過舊，與新版控制模組不相容。
- **緊急處置**：暫時降回舊版韌體，可恢復運作。
- **根本解法**：安排現場更新控制模組。

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

# E-207 韌體與控制模組版本不相容
當韌體版本低於控制模組要求時，開機自檢會中止並回報 E-207。
處置流程參見 [[韌體降版操作]] 與 [[控制模組現場更新排程]]。

於是下一次——不管是林郁婷，還是上週才報到的新同事——遇到同一個客戶問同一件事，只要打一句話進系統：

「客戶設備開機跳 E-207 怎麼處理？」

得到的是：

通常是韌體版本過舊，與新版控制模組不相容。可先降回舊版韌體讓設備恢復運作，再安排現場更新控制模組。
〔出處：客戶服務通話紀錄 → 原始逐字稿〕

請注意兩件事。第一，答案後面附著出處，點下去可以一路追回當初那通電話。這很重要——第一線敢不敢照著回客戶，差別就在這裡；主管事後要查你憑什麼這樣講，也查得到。第二，客戶姓名、電話、訂單編號一個都沒有出現，它們在進入知識庫之前就被遮掉了。

你不需要再記住 137 列 Excel。你只需要問得出問題。

那些「不敢放進系統」的內容，其實才是你最需要的

第一線的人最常遇到的狀況是：真正有用的資訊，剛好都是敏感的。客戶的報價邏輯、合約裡答應過的到場時效、上一次為什麼願意給那個折扣——這些才是客戶會追問的，偏偏也是最不敢隨便放的。

所以這套系統把安全做成兩條不能違反的鐵則。

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

另一條是你無權看的，系統絕不會答給你。權限綁在「團隊」上，而且在每一次查詢的當下驗證。標成業務團隊的合約條款，客服查不到，甚至查不出它存不存在——不會出現「有這筆資料但你沒有權限」這種等於洩漏的提示。

這代表什麼？代表你的公司可以把合約、報價、客戶往來紀錄都煉進來，而不是只敢放那些本來就無所謂的東西。而對第一線來說，能不能答得出客戶的追問，決勝點恰恰就在那些「本來不敢放」的內容裡。

會不會過幾個月，又變成一堆沒人信的舊答案

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

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

對第一線來說，這件事的意義只有一句話：你查到的答案，是現在有效的答案，不是三年前有效的答案。

「稍後回覆」的成本，其實比你想的高

以一般知識管理導入經驗為基準，找答案的時間可以從「翻半小時檔案再問人」壓到「一分鐘內問到」，同類問題的重複發問下降六成以上。這是合理的導入目標與期望值，不是實測保證值，實際成效取決於餵進多少素材、清洗品質，以及團隊的使用習慣。

但如果你自己就在第一線，你其實不太需要看這些數字。你更清楚的是另一組帳：

一次「我幫您查一下」，是你多花二十分鐘，加上另一位同事被打斷的十分鐘，加上客戶多等的四個小時，加上他心裡多打的一個問號。乘以一天九次，乘以一年兩百多個工作天。

林郁婷那天下午收到客戶回信，只有一句：「所以到底可不可以？」

你不會希望這句話，是客戶對你們公司的最後印象。

如果你也有一份 137 列的 Excel

那份 Excel 不是問題，它是證據——證明你們公司真的累積了很多經驗，只是這些經驗現在得靠某幾個人用手抄、用記憶力、用「剛好我知道」來支撐。

這撐得住今天，撐不住那個人請假、離職，或是團隊要再進三個新人的時候。

[知識庫 3] 你接的是專案，不是考古

接手第一週，你應該在推進度，不是在解讀前任留下來的資料夾。

資料夾裡有兩百個檔案，沒有一個叫「這個案子到底怎麼回事」

週一早上九點，主管把一個共用資料夾的權限開給了周佩璇。

「宏泰那個案子交給你，小李下週五就走了，有問題趕快問他。」

她點進去。兩百多個檔案。命名大概是這樣：宏泰_需求確認_final.docx、宏泰_需求確認_final_v2.docx、宏泰_需求確認_最新版(客戶確認過).docx、會議_0311.m4a、會議_0325(補錄).m4a、報價_勿外流.xlsx、新增資料夾/。

她花了兩天，拼出了一個大概的輪廓：這個案子做了十四個月，換過一次客戶窗口，中間有一段改了規格，目前進度大約七成。

然後客戶打電話來了，問的是：「上次講好的那個報表格式，你們是照哪一版做？」

她答不出來。她知道有三份規格文件，但不知道哪一份是「講好的那一版」，也不知道那次是在哪一場會議「講好」的。她去問小李，小李想了五秒說：「喔那個啊，好像是三月的時候客戶口頭改的，我印象中有跟他們確認過。」

「有紀錄嗎？」

「應該在錄音裡吧。」

兩百個檔案，其實只回答得了一個問題：這個案子做過什麼。它回答不了那個真正要命的問題——為什麼要這樣做。

接手為什麼一定會卡，而且不是你或前任的錯

這件事值得說清楚，因為接手的人常常會覺得是自己不夠用心，或是前任交接不負責。兩個都不是。

一個專案交接得出來的，是狀態：做到哪、誰負責、檔案在哪、還欠什麼。

交接不出來的，是脈絡：為什麼這個功能後來被砍掉？為什麼報價要多加一成？為什麼這個客戶的窗口一定要先發信再打電話？為什麼那條整合方式明明比較快，我們卻沒有用？

這些沒有一條寫得成文件。它們是十四個月裡，一次一次的會議、電話、現場、爭執累積出來的判斷。要一個人在離職前一週把它們寫下來，物理上就做不到——他甚至不知道哪些是「你會需要知道的」。

而且脈絡並不是不存在，只是存放的位置很尷尬：一場 90 分鐘的客戶訪談錄音（會後沒人想重聽）、一封三月的往來信、一張現場拍的照片、一段記在筆記本上的口頭承諾、一份被改到 v7 的簡報。

所以問題不是「交接怎麼做得更完整」，而是「這個案子的脈絡，有沒有在它發生的當下就被留下來」。

一場沒人想重聽的會議錄音，變成一頁你查得到的決議

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

回到那個報表格式的問題。那場三月的會議其實有錄音，長度 87 分鐘，沒有人聽過第二次。逐字稿的其中一小段長這樣：

…那個報表喔，客戶那邊王經理說，他們財務要的是每月一張、
不是每週，然後要含稅未稅分開列。啊他們窗口換成陳先生了，
chen@…那個信箱等下我再貼給你。這樣調的話工時會多，
不過我們這次先吸收啦，報價還是照原本的 168 萬走，不加價。

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

## 報表格式變更決議（客戶口頭確認）

- **變更內容**：報表出表頻率由每週改為每月一張，欄位需含稅、未稅分列。
- **提出方**：客戶財務單位需求，由客戶端主管於會議中提出。
- **商務處理**：本次追加工時由我方吸收，合約金額維持不變。
- **附帶異動**：客戶對接窗口已更換（聯絡資訊已遮罩）。

再進一步蒸餾，它變成一頁可以互相連結的概念頁：

# 宏泰案報表規格（現行版本）
出表頻率：每月一次。欄位需含稅／未稅分列。
本規格於專案期間經客戶口頭確認變更，未走書面變更單。
相關脈絡參見 [[口頭變更的認列原則]] 與 [[專案窗口異動紀錄]]。

於是周佩璇不必去猜哪一份 docx 才是對的。她打一句話進系統：

「宏泰案的報表格式最後是照哪一版？」

得到的是：

每月一張，含稅與未稅分列。此規格於專案期間由客戶口頭提出變更，我方吸收追加工時、合約金額未調整。
〔出處：宏泰案專案會議錄音（三月）→ 原始逐字稿 第 41 分鐘〕

兩件事值得注意。第一，答案附著出處，而且可以跳回錄音的那個時間點——所以她敢直接回客戶，主管要查依據也查得到。第二，客戶窗口的聯絡方式在進入知識庫之前就被遮掉了，而「報價維持 168 萬、我方吸收工時」這種商務資訊，只有具備對應團隊權限的人查得到。

你接手的時候，需要的不是兩百個檔案的存取權，是兩百個檔案裡那三十句真正重要的話。

為什麼敢把報價跟合約也煉進去

接手專案最尷尬的一件事是：你最需要知道的，剛好都是最敏感的。報價怎麼算、合約承諾了什麼、上次為什麼願意讓步——不知道這些，你根本不敢對客戶開口。

這套系統把安全做成兩條不能違反的鐵則。

第一條，遮蔽失敗，整筆就算失敗。不是盡量遮，而是只要沒遮乾淨，整筆內容退回重跑，絕不放行到下游。客戶窗口的手機與信箱不會因為「這次沒抓到」就流進知識庫。

第二條，權限綁在團隊上，而且每一次查詢當下驗證。專案團隊查得到自己案子的商務脈絡，隔壁部門的人問一模一樣的問題，會得到「查無資料」——不是「你沒有權限查看這筆資料」，是連它存不存在都不會透露。

所以你的公司可以把合約、報價、客戶往來一起煉進來。而接手一個案子最需要的東西，恰恰全部都在那裡。

那過一陣子，它會不會又變成另一個「新增資料夾」

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

規格改版了、合約續約了、窗口又換人了，承辦人對原檔案按「上傳新版本」，系統自動建立版本鏈：新版標成 v2，舊版標示「已被取代」，版本歷史可回溯稽核。接著自動重新清洗、重新蒸餾、重建索引。

差別在這裡：final_v2_最新版 這種檔名要靠人記得誰是最新的；版本鏈是系統記得。你只要從更新原料開始，下游會自己刷新，而且答出來的一定是現行版本。

第一週應該長什麼樣子

以一般知識管理導入經驗為基準，接手者的上手週期可以從一到兩個月壓到兩三週，大約縮短一半；同一件事被重複問的次數下降六成以上。這是合理的導入目標與期望值，並非實測保證值，實際成效取決於餵進多少素材與團隊的使用習慣。

不過對接手的人來說，感受最直接的不是這些數字，而是一種姿態的改變。

沒有知識庫的第一週，你在對客戶說：「這個我要跟同事確認一下。」有知識庫的第一週，你在對客戶說：「這個部分我們三月確認過，是每月一張、含稅未稅分列，我先照這樣往下推。」

同樣是第一週，一個像實習生，一個像負責人。

下一個接手你案子的人，會拿到什麼

這件事最後會繞回你自己身上。

你現在正在做的案子，總有一天會交給別人——可能是你升遷、轉調，或只是休了個長假。到那時候，你留給對方的，是兩百個檔案跟一句「有問題再問我」，還是一座他問得到答案的知識庫？

[知識庫 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。

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

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

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

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

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