01 系統架構
Brain 不是 demo，是我每天用的東西。為了維持 daily-driven，它必須做到三件事：多入口（手機、桌機、Claude Code session 都能進）、單一真相（vault + SQLite 是 source of truth，其他都是 view）、以及不會壞（cron + GitHub Actions 是 backbone，real-time push 是奢侈品）。
三個入口都直連 core layer，不經過彼此。這是設計選擇，不是巧合——任何一個入口掛了，其他兩個還能用。Daily-driven 的 system 最怕單點失敗，因為單點失敗會逼你開電腦修，而開電腦修這件事本身就是 daily-driven 的反義詞。
02 5 個關鍵設計選擇
這 5 個選擇是 Brain 跟「另一個 RAG demo」差最多的地方。每一個都是 trade-off，每一個都在 14 個月的 daily-driven 中真的被驗證過。
為什麼 SQLite + FTS5 而非 vector DB？
啟動 cost 低、樹莓派跑得動、不用 docker compose 起 4 個 service。FTS5 解 80% 搜尋場景。剩下 20% 才接 Gemini embeddings 做 hybrid。決策原則：start with the simplest thing that works。如果有一天 SQLite 撐不住了，那是個好問題——但還沒到那一天。
為什麼 熱度衰減 + 三層儲存 而非無限保留？
Brain 跑 14 個月，舊筆記變 noise。RAG 撈到 2024 年的舊草稿打斷正在做的事。L1（熱）/ L2（溫）/ L3（歸檔）不刪除舊資料，只是讓 RAG 預設只看 L1+L2。能不能搜到 L3 是用戶顯式選擇。Production knowledge system 的合理 default 是「最近的最重要」，不是「全部都重要」。這個 module 後來抽出來變成 forget-rag。
為什麼 TG Bot 是主入口而非 Web UI？
我在哪、Bot 在哪。手機上、辦公室、家裡——同一個 chat。Web UI 要設計 UX、處理 session、做 auth；Bot 直接用 Telegram 的 infra，省 90% 工。trade-off 是一次只能服務我一個人——但 Brain 本來就是私人系統。當需求是 daily-driven 的個人 productivity，從工程量回推入口設計才對。
為什麼 daily-driven cron 而非 real-time push？
日報 / 週報 / 維護任務全是 cron。實時 push 要處理 backpressure / retry / dead letter queue，cron 只要 retry-on-fail 就好。錯誤面積差一個數量級。trade-off 是 latency——但個人知識系統不需要 sub-second，需要的是不會壞。Brain 上線 14 個月，cron 任務的恢復成本接近零；real-time push 一壞就要花一整個下午查 queue。
為什麼 ship MCP 監控但 14 天後砍計畫？
Phase 0 上線後 audit 發現 instrumentation 只抓到 0.22% 流量。沒救了——剩下 99.78% 走 Bot/REST 直呼核心，根本不過 MCP。當下我有兩個選擇：花一個月修 instrumentation 架構，或承認假設錯、砍掉 Phase 1 的 BQML benchmark 計畫，把這次經驗寫成 retrospective。我選後者。Sunk cost 是最危險的 anti-pattern，14 天後的 audit 就是設計來破除它的。
完整故事看 MCP Monitoring Retrospective →03 這個系統證明我能在 AI 新創做什麼
Portfolio 不是「給你看程式碼有多漂亮」，是把抽象能力翻譯成可驗證的 claim。Brain 跑了 14 個月，下面三條是它證明的東西——每一條都有 evidence，不是 buzzword：
start small。