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

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

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

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

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

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

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

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

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

「有紀錄嗎？」

「應該在錄音裡吧。」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

得到的是：

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

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

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

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

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

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

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

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

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

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

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

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

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

第一週應該長什麼樣子

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

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

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

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

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

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

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