測試一下你們公司的知識管理：新人問「報銷的規則是什麼」，答案在哪？
如果答案是「問你隔壁的資深同事」，你們的制度存在員工的腦袋裡；如果答案是「在共用資料夾裡找找看」，你們的制度存在一堆沒人打得開第二次的 Word 檔裡。兩種情況的結局一樣：資深員工一離職，知識跟著蒸發。知識庫要解決的就是這件事——讓組織的知識屬於組織，而不是屬於某個人。
現象：為什麼公司的知識總是找不到
知識找不到的公司，通常不缺文件，缺的是結構。文件散在共用資料夾、Email 附件與個人電腦裡；同一份 SOP 有三個版本在流通；新的規定用公告發布，三個月後沉進訊息海。大家不是不寫，是寫了等於沒寫，因為沒有一個「全公司都知道去那裡查」的地方。
這件事的代價每天都在付：資深同事一天回答十次同樣的問題、新人兩週還在狀況外、跨部門合作前要先花半小時弄清楚對方的流程。更隱蔽的代價在人員流動時爆發：關鍵知識只存在某個人腦中，他一提離職，全公司才發現沒有備份。
這不是個別公司的毛病。McKinsey Global Institute 2012 年的經典研究估計，互動型知識工作者有 19% 的工作時間花在搜尋和蒐集資訊；Atlassian《The State of Teams 2026》訪調 12,035 位知識工作者，87% 表示所有人都埋頭執行、缺乏協調的時間與餘裕。知識不流通，每個人都得自己重新打聽一次，正是這兩筆帳的共同來源之一。
為什麼：知識管理失敗的真正根源
知識管理失敗的根源通常只有兩個：內容放錯了地方，以及沒有人負責維護。
根源一：把倉庫當圖書館。 共用資料夾是檔案的倉庫：內容鎖在一個個要下載的檔案裡、搜尋只找得到檔名、結構靠資料夾命名維持。知識庫是頁面的圖書館：內容點開即讀、內文可搜尋、頁面之間有層級與連結。把「要被反覆查閱」的內容放進倉庫，注定被遺忘。
根源二：沒有人負責。 知識庫的死因從來不是工具，是無人維護：頁面過期沒人更新、新內容沒人整理，半年後大家回去問資深同事。知識管理是持續的運營，不是一次性的搬遷專案。
兩個根源對應的解法，就是下面的五步 SOP。
五步搭建法
知識庫從零搭到能自己運轉，要走五步：定收錄標準、設計第一層結構、規劃權限、搬第一批內容、建立維護機制。
第一步：先決定「不放什麼」
知識庫的頭號殺手是什麼都放：討論過程、會議記錄、專案暫存檔全塞進去，稀釋了真正重要的內容。收錄標準一句話：會被反覆查閱的才進知識庫。實務判斷法：同一個問題被問過三次，就寫成頁面。
第二步：設計第一層結構
第一層目錄決定所有人找東西的直覺，建議不超過六個區塊：公司制度（請假、報銷、差勤規則）、入職指南（新人第一週的一切）、部門 SOP、工具教學、常見問題。結構原則是照讀者找的路徑分，不照組織圖分；新人不知道「行政部」管什麼，但知道自己要找「怎麼請假」。
第三步：規劃權限
用 Lark 知識庫的公開範圍與權限設定分層：全公司規章開放全員閱讀、部門 SOP 限部門成員編輯、管理制度限管理層。知識庫可設定整體的公開範圍與成員權限，個別頁面還能單獨調整協作者權限，比逐份檔案設定省力得多。
第四步：搬第一批內容
從投資報酬最高的兩塊開始：入職指南與最常被問的十個問題。不要追求一次搬完所有文件，知識庫是長出來的，不是搬出來的；舊文件裡真正還有人查的其實不多，被查到再搬進來就好。寫頁面時用文件編輯功能把結構做清楚：標題階層、清單、表格，讓頁面掃一眼就能定位答案；知識庫的實際操作站內有完整教學。
第五步：建立維護機制
三個機制缺一不可：每區有主人（每個區塊指定負責人，有人負責才有人更新）、更新綁進流程（制度改版時，更新知識庫頁面是發布流程的一環，不是事後補做）、每季盤點（掃一次過期內容，更新、標註或封存）。盤點時順手看兩個訊號：同一個問題又開始在群組被問起，代表該補或該修的頁面；打開頁面的檔案資訊查看閱讀人數與次數，長期沒人讀的內容就標註封存。讓實際使用告訴你知識庫該往哪長，比開會討論「大家覺得還缺什麼」快得多，也準得多。
入職指南的黃金結構
入職指南是知識庫裡投資報酬最高的一塊，值得把它的結構直接給出來。一份能讓新人自己走的入職頁面，照這個骨架寫：
第一天：帳號怎麼開、要裝哪些工具、加入哪些群組、位子與設備找誰。這一段的目標是「報到當天下午就能開始工作」，每一項都附負責窗口。
第一週：必讀文件清單（公司制度、部門介紹、進行中專案的背景）、要認識的人（各協作窗口與他們負責什麼）、第一個小任務。小任務是關鍵設計：讓新人在第一週就有產出，比任何歡迎儀式都更能建立歸屬感。
常見問題：請假怎麼請、報銷怎麼跑、會議室怎麼訂、薪資單去哪看。把新人前三個月會問的問題預先答掉。
部門專屬頁：各部門自己維護的工作流程與工具教學，新人依所屬部門延伸閱讀。
寫的時候記得一個原則：入職指南的讀者是「什麼都還不知道的人」，所有內部黑話與縮寫第一次出現都要解釋，連結要直接給、不要寫「去某某資料夾找」。
墳場化的三種路徑與急救法
知識庫失敗的樣子高度雷同，先認識三種常見的死法，再對症急救。
熱情啟動、無人接棒。 導入時大家熱血搬了一堆內容，三個月後沒有人再新增或更新。急救法：回到第五步，指定每區負責人並把更新綁進流程；已過期的內容集中一次大掃除，標註「最後確認日期」讓讀者能判斷新鮮度。
內容太雜、找不到重點。 什麼都放的結果是重要內容被淹沒，搜尋出來一堆過期草稿。急救法：回到第一步的收錄標準，把非「反覆查閱」型的內容移出（會議記錄回歸文件、專案暫存回歸專案空間），知識庫瘦身後可讀性立刻回升。
寫的人和用的人脫節。 制度由總部寫、第一線根本用不上，或寫法太抽象沒有操作步驟。急救法：讓最常被問問題的人來寫答案（他們最知道大家卡在哪），並在每頁開放評論，讓讀者能直接回饋哪裡看不懂。
三種死法的共同解藥其實是同一件事：知識庫要有人「經營」而不只是「存在」。經營的工作量不大（依我們導入輔導的經驗，每區負責人每週半小時足矣），但必須有名有姓。
知識庫與文件、訊息的分工
訊息負責流動、文件負責協作、知識庫負責沉澱，這是三者分工的一句話版本。導入知識庫後常見的困惑正是：那一般文件和群組訊息要幹嘛？
討論在群組訊息裡進行；需要多人共編的工作產出（提案、會議紀錄、專案文件）活在雲端文件；當一份內容從「進行中」變成「定案且會被反覆查閱」，才把它整理進知識庫。方向是單行道：訊息裡的結論寫進文件、文件裡的定案沉澱進知識庫，反過來就亂了。
這個分工也回答了「為什麼不能拿共用資料夾當知識庫」以外的另一個問題：為什麼不能拿知識庫當文件庫。知識庫塞滿進行中的草稿，就回到墳場化的第二種死法。
立即可見的回報
新人上手。入職指南寫得好，新人第一週的問題大多能自己找到答案，資深同事從人肉客服解放出來，這是知識庫最快回本的一塊。遠距或混合團隊的效益加倍：新人沒辦法「順路問隔壁」，寫下來的入職腳本是他唯一的扶手，做法見遠距團隊管理 SOP。
離職不斷層。工作紀錄平時就沉澱在知識庫與文件裡，交接不再依賴前手的記憶；搭配管理後台的離職資源移轉，頁面歸屬轉給接手的人——樹還在，知識就還在。文件與檔案層面的治理，另見資料管理 FAQ。
起步建議：先小後大
依我們協助台灣企業導入的經驗，成功模式高度一致：一個區塊、一位負責人、十個頁面，跑一個月讓「有問題先查知識庫」成為習慣，再擴大到下一個區塊。反過來，一開始就宣示「全公司知識大遷移」的專案，多半撐不了多久就窒息於自己的野心。
養成習慣還有一個實用技巧：當有人在群組問已經寫成頁面的問題時，回覆連結而不是重打一次答案。這並非敷衍，而是在訓練全公司「答案在知識庫」的肌肉記憶；頁面的閱讀次數，也是頁面價值最誠實的投票。
想規劃你們的知識庫結構，找艾瑞特資訊聊聊。身為 Lark 台灣授權代理商，我們可以用你們現有的文件現場示範第一層結構怎麼切、第一批內容怎麼挑。
常見問題
Q1：知識庫和共用資料夾差在哪？
共用資料夾是檔案的倉庫：內容鎖在要下載的檔案裡、搜尋只找得到檔名、結構靠資料夾命名。知識庫是頁面的圖書館：內容點開即讀、內文可搜尋、頁面有層級與連結、更新即生效。放「要被反覆查閱」的內容，知識庫遠比資料夾有效。
Q2：公司知識庫應該放哪些內容？
知識庫最有價值的三類內容：制度規章（請假、報銷、差勤規則）、操作 SOP（各職位的工作流程與工具教學）、入職指南（新人第一週需要的一切）。收錄標準是「會被反覆查閱」：同一個問題被問過三次以上，就值得寫成頁面；討論過程與暫存檔不要放。
Q3：怎麼避免知識庫變成沒人維護的墳場？
避免墳場化靠三個機制：每個區塊指定負責人（頁面有主人才有人更新）、把更新綁進流程（制度改版時同步更新頁面，屬發布流程的一環）、每季盤點過期內容。知識庫的死因從來不是工具，是沒有人負責。
Q4：Lark 知識庫的權限可以分層設定嗎？
可以，Lark 知識庫支援公開範圍與成員權限的分層設定：全公司規章開放全員閱讀、部門 SOP 限部門成員編輯、管理文件限管理層，個別頁面還能單獨調整協作者權限。
Q5：知識庫要花多久才看得到效益？
依我們導入輔導的經驗，最快回本的是入職場景：入職指南上線後，下一位新人的提問量就會明顯下降。整體習慣的養成約需一個月，用「一個區塊、一位負責人、十個頁面」起步，讓「先查知識庫」成為預設動作，再逐步擴大。