托特進入 Vibe Coding 時代：告別微服務，寫給一人開發者的 AI 架構指南

最近，我把托特幾乎整個砍掉重練了。

聽起來很瘋狂？工程師的大忌就是「重寫」，但如果你了解之前的架構有多像一隻拼裝科學怪人，就會理解為什麼這件事非做不可。而且在 2026 年的今天，靠著「一個人＋AI」就能活著把這件事做完。

之前的架構：四個 Repo，滿地找牙的微服務

先來瞻仰一下改版前的「火力展示」。

托特的服務原本散落在四個獨立的 Repo 裡，每個都有自己的技術棧、部署流程和基礎設施：

• thoth (Gatsby + Strapi CMS)：Landing page thoth.tw。為了對付邪惡的 SEO 而生。
• kyogre (Next.js 13 + GraphQL)：Web app app.thoth.tw。
• snorlax (NestJS + GraphQL + REST)：API Server，要伺候 GraphQL 也要處理 REST。
• togepi (Flutter)：手機 App 端。

眼尖的你可能已經發現了，後面這幾個 Repo 的名字...對，就是寶可夢的英文。身為一個工程師，當你被各種技術選型搞得心力交瘁時，「命名」絕對是壓垮理智的最後一根稻草。於是當年我果斷放棄治療，直接翻開寶可夢圖鑑抓幾隻來當微服務的名字。現在回想起來，把 API Server 叫 Snorlax（卡比獸），某種程度上也算是一種對效能又肥又慢的精準預言吧。

為什麼光前端就有兩個？這完全是歷史共業。app.thoth.tw 一開始是用純 React 寫的 SPA，寫起來是很爽，但 SEO 爛到笑。所以後來又硬幹了一個 Gatsby 產靜態網頁來扛 thoth.tw。這也是為什麼「交換技能」這個關鍵字能長期霸佔 Google 搜尋第一名的原因（當然，也可能單純是這領域太小眾）。

但這還沒完。後面還接了 Strapi 當 CMS 後台寫部落格；為了撐住登入和 Cache 加了 Redis；搜尋引擎更是折騰，先是上了 Elasticsearch，後來嫌它太肥又換成 MeiliSearch。

全部加起來，一個 Side Project 背後跑著：Gatsby + Strapi + Next.js + NestJS + Redis + MeiliSearch + Firebase + Flutter。而且為了過濾 Bug，這整套上古神獸還要再 Clone 一份給 Staging 環境。

光是跨平台管理那些 Credentials 和 API keys，就讓我懷疑自己到底是 Founder，還是兼職的 DevOps 水電工。更別提當初為了省錢，還開了幾台 VM 自己管 Docker Swarm。

永無止境的 Context Switch 與自我懷疑

這些年來，這套系統幾乎每個角落都被翻修過。但好不容易重構完 A 區，轉頭發現 B 區已經變成技術負債了。

開發 Side Project 最可怕的不是寫 Code，而是時間破碎。有時候忙完本業，隔了幾個月再把專案打開，看著 IDE 裡的程式碼，心裡只想怒吼：「這坨義大利麵到底是哪個白痴寫的？」

...然後默默敲了 git blame，哦，是我本人。

這次改版：少即是多（化繁為簡）

這次改版，表面上只是換了前端、上了幾個新功能。但骨子裡，除了 Flutter App 之外，我幾乎把所有東西都核平了。

核心戰略只有一個：極致縮減服務數量。

Before 拼裝車時代

thoth.tw (Gatsby + Strapi CMS)
app.thoth.tw (Next.js 13 + GraphQL)
api.thoth.tw (NestJS + GraphQL + REST)
Firebase (Auth + Firestore + Storage + FCM)
Redis (Session Cache)
MeiliSearch (搜尋引擎)
2 台 VM (DigitalOcean + Vultr 跑 Docker Swarm + Traefik)

After 極簡時代

thoth.tw + app.thoth.tw (Next.js 15，終於統一了！)
Supabase (PostgreSQL + Auth + Realtime + Storage)
Vercel (推上去就部署，零管理)

沒了。就這樣。

不用再 SSH 進 VM、不用管 Docker、踢掉 Redis、也不用額外維護搜尋引擎。前端直接對接 Supabase；權限控管交給 PostgreSQL 的 Row Level Security (RLS)；搜尋直接用 pg_trgm 的 ILIKE 硬扛；即時訊息？Supabase Realtime 直接取代以前搞死人的 Socket.io。

給前任的一封信：再見了 Firebase 與 CMS

從 Firebase 逃難到 Supabase

一開始用 Firestore 確實有種「哇，都不用想 Schema 耶」的爽感，但當平台充滿了「用戶」、「技能」、「文章」這些高度關聯的資料時，NoSQL 的每一次 Query 都像是在懲罰你的架構設計。

換到 Supabase 的感覺，就像是繞了一大圈又回到初戀的懷抱，30 多年歷史的 PostgreSQL。重點是：所有 AI 都對 SQL 熟到不行。AI 寫關聯查詢的準確率極高，踩坑率極低。

Compatible API：騙過 Flutter App 的過渡期橋樑

雖然架構移除了 API Server，但手機上的 Flutter App 總不能說斷就斷。所以，我用 Hono（一個超輕量、寫起來手感極像 FastAPI 的 Edge 框架）快速嚕了一套「相容 API」。

它負責攔截 Firebase ID token，映射到 Supabase session，然後當個稱職的 Proxy 把請求倒給新資料庫。就這樣，App 端在完全沒有感覺的情況下，被我偷天換日完成了後端轉移。

拔掉 CMS 管式呼吸器

以前用 Strapi 這套 Headless CMS，聽起來很潮，有後台、有編輯器、有 API。但對一個開發者來說，它就是「另一個需要餵養的寵物」。

這次我直接把它砍了。部落格全面改用純 MDX 檔案放在 Repo 裡，前端直接讀。Metadata 寫在 Frontmatter，並用一個 JSON manifest 檔當索引。

你可能會問：「那每次發文不就要手動刻 JSON、寫 Frontmatter？很煩欸。」

沒錯，以前很煩。但現在我有 AI。我只要丟一句：「幫我加一篇新的 Blog」，AI 就會光速建好 MDX、填好 Frontmatter、更新 Manifest。

說白了，CMS 的價值是「讓不懂技術的人能發文」。當你本來就是個碼農，又配備了 AI 助手時，CMS 就只是一個拖慢速度的多餘中間層。

所以，Vibe Coding 到底是什麼感覺？

Andrej Karpathy 提出了 Vibe Coding 這個概念：你動嘴給方向，AI 動手寫 Code，你負責 Code Review 和架構。

聽起來很浪漫，但實際下海後，我有幾個非常血淋淋的心得：

AI 是個手速封頂，但沒有商業邏輯的實習生。 如果你很清楚架構、知道 Trade-off、甚至連 Schema 都想好了，AI 可以幫你省下 80% 的鍵盤敲擊。但如果你連自己要什麼都不知道，AI 只會用光速幫你產出一座難以維護的屎山。

選 AI 懂的技術棧，不要鐵齒。 Supabase, Next.js, Tailwind... 這些在 AI 訓練資料庫裡多到滿出來的主流技術，用起來就是順。如果你硬要挑一個冷門、剛出半年的潮框架來 Vibe Coding，AI 的幻覺會多到讓你懷疑人生。

架構，終究是人類的工作。 AI 可以幫你實作 RLS，但不會幫你拍板「把四個 Repo 合併」或「捨棄 NoSQL」。化繁為簡，是讓 AI 能順利接手的最大前提。服務越少、架構越單純，AI 越不容易「通靈」失敗。

這次順手加了什麼？

除了底層大換血，靠著 AI 的開發紅利，我順手把以前「很想做但想到要寫 Migration 就發懶」的功能一天內幹完了：

• 熱門 Feed — 導入 Hacker News 風格的時間衰減演算法，不再只能看最新文章。
• 技能 Tokenization — 透過 AI，把過去 4000 多篇文章裡五花八門的自由文字，精準抽取、收斂成 200 多個標準化的技能標籤。這在以前光寫腳本就會要了我的命。
• 推薦 Feed 與興趣系統 — 基於標準化後的標籤，自動配對互補的技能與文章。

總結

砍掉重練一直都是痛苦的。但在「化繁為簡」與「Vibe Coding」的組合拳下，把複雜的自建基礎設施換成 Managed Service，然後把繁瑣精確的苦力活丟給 AI，這件事突然變得可行了。

以前每次打開這個 Side Project，都有一種「天哪，我到底欠了多少技術債」的無力感。現在，看著乾淨的單一 Repo 和輕量化的架構，我終於覺得，身為一個獨立開發者，我又能在這個平台上繼續快樂地寫扣了。

如果你也有一個被複雜度壓垮、已經長滿蜘蛛網的 Side Project，我的建議是：先別急著加功能，先想想怎麼減少服務。 架構越簡單，你跟你的 AI 夥伴，才越有活路。