開發一個軟體工具，很像在煮一道菜。你可以選擇備齊所有食材，也可以只用幾樣做出同樣好吃的東西。

多數 AI 工具選擇前者。它們的套件清單（package.json）讀起來像一份新創公司的招聘名單——框架、適配器、相容層，還沒寫第一行核心邏輯，已經載入了四十個外部套件。

MeMesh 走了另一條路：只有三個生產依賴。

• better-sqlite3 — 負責把資料存到本機資料庫
• @modelcontextprotocol/sdk — 負責和 Claude Code 溝通的協議
• zod — 負責驗證使用者輸入的資料格式

就這樣。

為什麼依賴數量很重要

「依賴」（dependency）就是你的程式需要借用的別人的程式碼。問題是，每一個依賴都不是免費的：

• 它可能是駭客滲透你系統的入口（這叫供應鏈攻擊）
• 它需要你跟著維護、跟著升級
• 它可能在某次版本更新後和其他套件打架
• 它在宣告「我這個工具，需要這麼複雜」

每次加入新依賴，你都在賭它帶來的好處大於它帶來的麻煩。對多數「用起來方便」的套件而言，這個賭注通常不划算。

向量搜尋是必要的嗎？

聽到 MeMesh 的做法，最常見的反應是：「那語意搜尋呢？AI 不是應該用向量和嵌入模型來搜尋嗎？」

這問題很合理。但答案是：在記憶查詢這個場景，通常不需要。

MeMesh 使用的是 FTS5——SQLite 資料庫內建的全文搜尋功能。它就像一個很快的關鍵字搜尋引擎，不需要 AI 模型也不需要任何額外服務：

• 幾百萬筆資料裡，毫秒就能找到結果
• 查詢結果穩定、可預測、容易除錯
• 不需要安裝任何額外軟體

向量搜尋（Vector Search）擅長的是「找語意相近的內容」，例如你輸入一段話，找出意思類似的文章。但當開發者在找「我上週對這個模組做了什麼決定」，他知道自己在找什麼，直接用關鍵字就夠了。

看得懂才能信任

保持最少依賴，還有一個更根本的理由：你需要能看懂這個工具在做什麼。

想像你在用一個外掛，它可以存取你整個專案的歷史記錄。如果它只有三個依賴，出了問題你可以一個下午就把所有程式碼看完、找出問題。如果它有四十個依賴，你連從哪裡開始查都不知道。

對於長期存取你工作狀態的工具，這種透明度非常重要。

限制是一種選擇

每次想加入新套件前先問「真的需要嗎？」，結果是讓 MeMesh 變得更可靠，而不是更受限。

76 個測試在 1.35 秒內全部通過。在 Mac、Windows、Linux 上安裝都不會遇到套件衝突。上游更新不會帶來意外破壞。

工具的極簡，不是在炫技，而是對使用這個工具的人負責。