380 行 Python 做出公司知識庫：不聯網、帶出處、能管權限，難的從來不是程式碼

公司制度文件散落在網盤、羣聊和個人電腦裡，新人問、老人答，答案還未必是現行版本。10 月下旬，一位開發者在 V2EX 的「分享創造」板發文，描述了這個幾乎每間公司都有的痛點，並給出自己的解法：一個只用 380 行 Python 寫成的離線知識庫，把 Markdown 文件丟進 docs/ 目錄就能提問，回答附上《文件》與章節出處，還能按角色控制可見範圍。

他沒有選市面上現成的 SaaS 知識庫，理由有兩個：資料不能出內網，以及按人頭收費的商業模式對小團隊不劃算。這兩個理由，正好框出了企業知識管理工具最常見的採購障礙。

這個工具實際上做了什麼

用日常一點的比喻：它像是一位讀過公司所有制度的總機小姐，你問「出差住宿報銷上限多少」，她不會憑印象回答，而是翻到《員工報銷制度》的報銷標準那一頁，指給你看原句。所謂的「出處」，就是把文件路徑和章節名跟著答案一起端出來，讓提問的人可以點開核對原文。

實作上有幾個值得留意的設計。文件先分塊，每塊約 420 字，並維護一個「標題棧」，讓每塊自帶《員工報銷制度》/ 報銷標準這樣的路徑。中文分詞不用外部套件，用二元組切分，英文和數字按詞處理。召回採用 BM25 加 TF-IDF 雙路加權，開發者自述第一版問「出差住宿報銷上限」，第一條結果卻是「差旅餐補」，加入「查詢詞覆蓋率」加權後才穩定命中正確段落。

最關鍵的一個取捨：回答預設是抽取式的，只回傳原文，不生成新句子。開發者給的理由很直接，制度類問題最怕編造。這個判斷與目前許多企業導入大型語言模型時遇到的痛點一致，模型越會說話，越需要機制保證它說的是文件裡真正寫過的話。

權限是另一條主線。文件可以設定可見範圍，普通員工查不到財務制度，被賦予財務角色的人才看得到。全程不聯網、零第三方依賴，部署只要兩條命令：一條建索引，一條起服務，整個目錄拷到內網機器就能用。

380 行能解決的，和不能解決的

把鏡頭拉近一點，這個專案最有價值的部分，可能不是程式碼本身，而是它驗證了一件事：對「找制度條文」這類查詢需求，傳統關鍵字檢索加上好的分塊與引用設計，已經能解決八成的問題，不一定需要向量資料庫或付費 API。

這也回應了近期工程師社羣的另一個討論。當工具門檻降低，「會寫 Python 還會做 Agent 為什麼連一面都換不到」這類提問反覆出現，會Python還會做Agent的求職困境 指出的現象是：把套件串起來已經不構成稀缺性。這位開發者的做法恰恰相反，他不是在展示技術堆疊，而是在展示對問題的理解，知道制度查詢怕編造、知道 SaaS 卡在哪、知道檢索排序要靠覆蓋率加權修正。這種判斷力比 380 行程式碼本身更難複製。

當然，限制也很明顯。抽取式回答只能找到文件裡已有的句子，遇到需要跨文件綜合、或文件根本沒寫的問題就無能為力。二元組分詞和 BM25 在中文長尾查詢上的召回率，也還有待更多真實使用驗證。權限控制做到角色層級，但文件本身的權限維護，誰來標、何時更新、離職交接，這些流程問題程式碼解決不了。

對正在評估知識庫的團隊，值得先問的三件事

第一，資料能不能出內網。法規、客戶合約或內部財務資料若有保密要求，SaaS 方案的第一道關就過不了，這正是此類自建方案存在的理由。第二，答案需不需要可核對。凡是涉及制度、金額、流程的問答，抽取式加出處的設計，比流暢的生成式回答更適合放上內部公告。第三，誰維護。工具再輕量，文件版本混亂的源頭問題不解決，知識庫只會變成另一個堆舊文件的地方。

發文者自己在文末也坦承想聽回饋，特別是檢索排序和文件權限兩塊還有哪些坑。帖子的回應裡也有人質疑文內給的 GitHub 帳號上找不到對應的 repo，程式碼是否完整公開仍有待確認。這一點提醒得對：展示與可驗證之間的距離，向來是社羣分享的第一道檢驗。

制度找不到這個問題，每間公司都有自己的土法煉鋼。380 行 Python 不會是終極答案，但它示範了一條務實路線：先圈定一個明確的查詢場景，把出處和權限做成預設值，再用最少的依賴把它放進內網。想解決同樣問題的團隊，不妨從這三個設計取捨開始評估，而不是從挑選哪個平臺開始。