我數了一下，光是三月的前兩週，我在 Get筆記上存了將近兩百篇東西。文章、podcast 摘要、得到 App 的課程筆記、開會錄音的逐字稿。存的時候都覺得「這個之後一定要看」。

然後呢？沒有然後。

打開 App 一看，全擠在同一個時間軸上，課程筆記跟買菜清單混在一起，三週前存的那篇關於 AI Agent 架構的深度文章，被後來存的二十篇東西蓋到不知道哪裡去了。

這個場景你一定不陌生。我身邊的朋友也有同樣的困擾：建了漂亮的資料庫，寫了三天之後就再也沒維護過。用其他工具的人也辛苦，光是糾結要用什麼 plugin、tag 要怎麼設計，就把整理的力氣用完了。

問題很清楚：不是收集難，是整理難。而整理之所以難，是因為我們把它當成一個需要「自律」來維持的習慣。

但自律是世界上最不可靠的資源。

換個思路：如果整理不需要人參與呢？

一個人加 AI 能完成的工程量，的體悟之一是：凡是需要人類持續手動介入的流程，最後都會崩壞。不是因為不夠自律，是因為手動流程的維護成本會隨著資料量線性增長，而我們的注意力不會指數成長。

軟體工程裡有個概念叫 pipeline——資料從 A 流到 B 流到 C，每個環節自動觸發下一步，不需要人站在旁邊盯。CI/CD 是 pipeline，ETL 是 pipeline，家裡的洗碗機也是一種 pipeline：髒盤子進去，乾淨盤子出來，你不用站在旁邊一個一個洗。

知識管理也變成一條 pipeline，可行嗎？不知道，先試著做看看。

四階段：收集 → 同步 → 分類 → 使用

整條管線拆開來看，就四個階段。（想看全貌的可以打開這張互動式流程圖。）

收集，在手機端完成。Get筆記是我的統一入口：看到好文章，存；podcast 聽到一段有感覺的，存；得到 App 上的課程筆記自動同步過來，不用另外操作；開會錄音丟進去，AI 自動轉寫加摘要。這一層的關鍵是「只有一個入口」。所有東西都進 Get筆記，不分散。

同步到本機，靠一支 Python 腳本。Get筆記有 OpenAPI，我寫了 sync_notes.py，crontab 設定每天晚上 23:00 自動跑一次。它只拉新增的筆記（增量同步），轉成 Markdown 格式存到本機的 notes/ 資料夾。每天醒來，前一天存的東西已經安安靜靜躺在電腦裡了。

自動分類，這是整條管線最花心思的部分——也是我最得意的部分。

使用，分類完的筆記可以直接全文搜尋，也可以透過 Cowork Skill 用自然語言查。「幫我找那篇關於龍蝦的文章」，它就會去 API 搜，把結果拉回來。不用記檔名，不用記存在哪個資料夾。

三層分類引擎：讓每篇筆記自動找到家

分類引擎是三層 fallback 架構，每篇筆記從上往下跑，第一層命中就不往下走。

第一層是錄音卡偵測。Get筆記的錄音筆記會自帶「錄音卡筆記」的 tag，腳本偵測到這個 tag 就把它歸到會議錄音資料夾。裡面再按關鍵字分成八個專案子資料夾——SDTI 的、CircleFlow 的、投資人會議的，各歸各位。

第二層是課程系列偵測，這是我最滿意的設計。得到 App 的課程文章，URL 裡藏著一個 courseArticleId 參數。同一門課的所有文章共用同一個 courseArticleId。我的腳本解析這個 ID，去比對一個叫 _course_registry.json 的動態登錄檔。

這個 registry 的巧妙之處在於：它會自動擴展。如果腳本遇到一個從沒見過的 courseArticleId，它不會傻在那裡不知道怎麼辦，而是自動建一個新資料夾、把這門課登記進 registry、然後開始歸檔。下次遇到同一門課的其他文章，就知道往哪送了。

我不需要每次開新課就去改程式碼。系統自己認識新課程。

第三層是關鍵字分類，最樸素但也最穩的兜底策略。腳本掃描筆記標題加內文前 300 字，比對一組關鍵字庫，分到對應的主題資料夾：AI 與科技、醫療健康、投資理財、個人成長、生活雜記⋯⋯。分不到任何類別的就進「其他」，至少不會消失在虛空中。

三層的優先順序很重要：錄音卡是最確定的（有明確 tag），課程系列是次確定的（有結構化 ID），關鍵字是模糊匹配但覆蓋面最廣。每篇筆記一定有歸處。

為什麼不用手動標籤？

建管線的過程中，我反覆試著用手動建立標籤。結論是：行不通。

不是技術上行不通，是人性上行不通。你存一篇文章的時候腦子裡想的是「這個好有用」，不是「這個應該歸到哪個標籤體系的第幾層」。要求使用者在收集的當下就做分類決策，也是消耗認知資源的操作。

第二個問題是標籤會飄移。你一月設的標籤體系，到三月就覺得不對了，但前兩個月的幾百篇筆記不可能回頭重新標。標籤系統的維護成本跟內容量成正比，而且是回溯性的——改一次規則就要重新處理所有歷史資料。

自動分類的好處是：規則改了，重跑一次腳本就好。一百篇跟一萬篇的成本一樣。

從「整理」到「取用」

管線建好之後，改變我工作方式的不只「整理」變快，「取用」也變得更友善。我可以直接在Claude的視窗調取資料，輸出我要的內容。

以前存的東西等於沒存，因為不方便查找。現在我可以在 Cowork 裡直接說「最近有沒有存過關於循環經濟的文章」，Skill 會去 API 搜尋，把符合的筆記列出來，連摘要都有。我可以說「幫我看一下萬維鋼那門課我上到哪了」，它就去讀 _series_meta.json 的進度索引。

知識管理的目標不是「存好」，是「用得到」。管線解決的不只是整理問題，是把收集和使用之間那道鴻溝填起來。

這跟我在 paulkuo.tw 做 AI-Ready 持續優化的邏輯是一樣的：不要讓人去適應系統，讓系統去適應人。網站優化交給自動迴圈，知識整理交給自動管線。人的精力留給真正需要判斷力的事。

一條管線，一種態度

回頭看，這條管線技術上其實不複雜。一支 Python 腳本、一個 crontab 排程、一份 JSON registry、一個 Cowork Skill。沒有機器學習，沒有向量資料庫，沒有什麼高深的 NLP。

但它解決了一個糾結我的問題。

以前每次看到知識管理的文章，都會被那套「建立第二大腦」的論述吸引，然後花一個週末搭 Notion 模板、設計 tag 體系、寫使用守則——然後兩週後又回到原點。不是工具不好，是那套方法本質上在跟人性對賭：它賭你每天都有力氣手動整理。但我不可能每天都有足夠的專注力。

管線思維不賭人性。它賭的是 API 穩定、cron 準時、程式邏輯正確。這三件事的可靠度，比任何人的自律都高。

如果你也在為知識管理焦慮，我的建議不是去找更好的 App 或更漂亮的模板。而是可以跟AI協作，放掉傳統SOP，問自己一個問題：流程裡，有哪些步驟其實不需要我？哪些是可以委出去？把不需要你的步驟交給管線與AI。把「閱讀、思考、連結、創造」留給自己。

我想，那是知識管理該有的樣子。當然，這是我個人的版本，你可以發展自己的。

管線產出範例

  • AI 龍蝦十日談 — 得到 App 共同創辦人快刀青衣的十場直播對談，經知識管線同步、AI 結構化整理後的總覽頁面。