Your Knowledge Base Should Be a Pipeline, Not a Wiki

你有冇試過建立一個 wiki，然後三個月之後發現佢已經死咗？我試過，而且唔止一次。每次我都會怪自己唔夠勤力，唔夠自律，冇定時更新。但後來我先明白，問題根本唔喺我身上——問題係 wiki 呢個概念本身就係反人性嘅。

知識管理嘅本質係一種持續性嘅行為，但 wiki 嘅設計邏輯係「靜態儲存」。你儲咗嘢入去，然後希望有人會去睇、去整理、去分類。呢個假设喺公司內部有專人負責嘅情況下或者成立，但對於獨立開發者或者小型團隊嚟講，根本唔現實。我哋每日面對嘅資訊量已經超負荷，仲要人手整理？呢個係一個無底深潭。

Pipeline 嘅邏輯：處理，而唔係儲存

我最近嘅做法完全唔同。我唔再建立一個「知識庫」，我建立嘅係一條 pipeline。每日自動 ingest 大約 30 條 URL——可能係 GitHub repo、技術文章、產品更新、或者 Twitter thread。呢啲 URL 會經過幾個階段：首先係去重，我發現大約 70% 嘅內容其實係重複嘅，或者同已有知識高度重疊；然後係分類，用 LLM 自動判斷呢條內容屬於邊個領域、同邊啲現有知識相關；最後係歸檔，自動添加到對應嘅 wiki page 入面。

關鍵係，我唔需要人手做任何嘢。Pipeline 自己會運作，我自己只需要偶爾去睇吓個 output。呢個先係可持續嘅知識管理方式。

當 Pipeline 本身就係產品

慢慢我發現，呢條 pipeline 嘅價值唔止於「幫我整理知識」。佢本身已經係一個產品。原因好簡單：佢解決嘅問題係普遍性嘅。每個開發者、每個創業者，每日都喺度 consume 大量資訊，但大部份人都冇一個系統化嘅方式去處理呢啲資訊。佢哋會 bookmark 一堆 link，然後永遠唔會再睇。

我嘅 pipeline 唔同之處在於，佢唔止係儲存，佢係主動處理。每日 30 條 URL 入嚟，經過過濾、分類、歸檔，最後產出嘅係一個持續更新嘅知識圖譜。而呢個圖譜嘅每一個 entry——例如 developer-utilities 或者 AI Agent Frameworks wiki——都係自動生成同更新嘅。呢個就係 pipeline-as-product 嘅核心邏輯。

實作上嘅幾個關鍵 decision

建立呢條 pipeline 嘅過程中，有幾個 decision 係關鍵嘅。第一係 ingest 嘅來源。我選擇咗 RSS + webhook + manual input 三種方式並行，確保唔會漏掉重要資訊。第二係去重嘅策略。單純用 URL 去重係唔夠嘅，因為同一個內容可能喺唔同平台出現。我用咗 embedding similarity 做 semantic 去重，threshold 設喺 0.85，呢個數字係經過多次測試得出嘅。第三係分類嘅 taxonomy。我冇用一個固定嘅分類系統，而係用 LLM 根據內容動態生成分類，然後定期 review 同 merge 相似嘅 category。

呢啲 decision 聽落好似好技術性，但其實佢哋反映嘅係一個更深層嘅哲學：知識管理應該係一個活嘅系統，而唔係一個靜態嘅儲存庫。

你應該點做

如果你都想建立類似嘅系統，我嘅建議係：唔好一開始就追求完美。先從最簡單嘅版本開始——可能只係一個 Python script，每日 fetch 幾個 RSS feed，然後用 LLM 做基本嘅分類。重點係令佢跑起嚟，然後持續迭代。記住，pipeline 嘅價值唔在於佢有幾複雜，而在於佢能夠持續運作。一個簡單但穩定嘅 pipeline，遠勝過一個複雜但時常出錯嘅系統。