這篇文章是「開發工具箱系列」的第一篇，記錄我為什麼決定從零用 Next.js 打造一個專屬的行銷工程內部工具箱，以及技術選型背後的思考。如果你也曾想過「乾脆自己刻一個」，這篇或許能給你一些參考。
有一天下午，我收到同事的訊息，附件是一份從 WordPress 後台複製出來、滿是殘留 class 和 inline style 的 HTML。她已經花了將近半小時手動清格式，但還是沒清乾淨。
這件事，我聽過不止一次。
我們的行銷團隊每天都在做幾件高度重複的事：把文章從草稿站搬到上架站、手動核對各社群帳號的數據、用 Excel 追蹤客戶發票有沒有付款。這些事情不難，但每次都要花時間，而且很容易出錯。
我盤算了一下：如果花幾週把這些流程工具化，之後每個月能省下多少小時？答案讓我開始動手。
問題：手工作業吃掉了多少時間？
在開始動手之前，我先把團隊的重複性工作列了一張清單：
- 每篇文章上架前，要手動清理從 Elementor 複製出來的 HTML 格式——平均每篇花 30 分鐘
- 每週要手動到各帳號查看愛心數、留言數、觀看數，填到試算表
- 客戶發票開立後，要在 Excel 追蹤付款狀態，容易漏催款
- 推薦文需要先搜尋競品、整理關鍵字，再動手寫，人工作業耗時
這些加起來，一週輕易就有 5 到 8 小時消耗在可以自動化的重複工作上。
評估過 SaaS，為什麼最後還是自己做？
市面上有很多工具宣稱能解決這些問題，我確實評估過幾個方向。
HTML 清洗工具
有些線上工具可以移除 HTML 標籤，但無法根據不同客戶套用不同的樣式規則，更無法自動生成目錄、處理 FAQ 區塊、保留 emoji 圖示。這些細節對我們來說很重要，一個都不能少。
社群監控平台
市面上的社群監控 SaaS 動輒每月數千元，功能遠超我們需要的範圍。我們只需要追蹤固定幾個帳號的基本數據，不需要輿情分析、競品比較等進階功能。
發票管理系統
現有的財務 SaaS 介面複雜，台灣電子發票的串接方式每家也不太一樣，用現成工具反而要花更多時間客製化。
最後的決定很簡單：自己做一個，完全符合工作流程，資料也留在自己手上。
技術選型：每個決定背後的理由
我希望這個工具箱能長期維護，所以在開始之前認真想清楚了技術架構。
Next.js 16 App Router
選 Next.js 的原因很直接：前後端放在同一個專案裡。API Route 讓我不需要另外建一個 Express 或 Python 伺服器。HTML 清洗、Webhook 觸發、AI 生成等後端邏輯，全部寫在同個 repo，部署時只要一個服務，維護負擔大幅降低。
App Router 的 Server Component 讓部分資料處理可以直接在伺服器端完成，不用繞到客戶端再發 API，架構更簡潔。
TypeScript
純粹是長期維護的考量。這個工具箱預計會持續增加功能，如果全程用 JavaScript，幾個月後回來修改，函式的輸入輸出全憑記憶。TypeScript 的型別定義等於是免費的文件，省去大量反查程式碼的時間。
Tailwind CSS v4
快速刻 UI 的首選。不需要另外維護一份 CSS 檔，設計一致性也比較容易掌控。Tailwind CSS v4 改用 CSS-native 的設定方式，少了一個設定檔，整體更乾淨。
Zeabur（而非 Vercel）
這個選擇可能比較少人想到，但對我來說是關鍵決定。
Vercel 雖然是部署 Next.js 的主流選擇，但它的免費方案是 Serverless 架構——每次請求是獨立的，沒有持久化的磁碟空間，意味著 SQLite 資料庫完全無法使用。
Zeabur 支援 Volume 掛載，可以把 SQLite 檔案存在持久化磁碟上。加上設定非常簡單，幾乎是把 Vercel 的使用體驗搬到支援真實後端的環境裡。
工具箱現在有哪些功能？
經過幾個月的迭代，工具箱目前包含以下九個功能模組：
模組名稱 | 功能說明 |
|---|---|
文章上架工具 | 四步驟精靈，把草稿 HTML 清洗成符合客戶樣式的上架版本 |
IG 監控報告 | 自動同步追蹤帳號的貼文數據，支援篩選、排序 |
推薦文生成器 | 填入關鍵字與品牌資訊，讓 AI 自動產出推薦文章草稿 |
精選知識文章 | 整理 AI 趨勢與 SEO 新知，方便團隊查閱 |
部落格文章生成器 | 自動抓取站內連結、生成文章初稿 |
財務發票管理 | 建立、開立、追蹤台灣電子發票 |
GSC 排名查詢 | 串接 Google Search Console，直接在工具箱看關鍵字排名 |
社群貼文追蹤 | 追蹤社群貼文的發布與成效 |
AI 聊天機器人 | 浮動聊天視窗，隨時回答工具箱相關問題 |
架構設計的三個原則
整個工具箱在架構上遵守幾個核心原則，讓它在快速迭代的同時保持可維護性。
一、一個功能，一個路由
每個工具有自己的路由，彼此獨立。壞了一個功能，不影響其他工具的正常運作。這樣的設計讓我可以隨時下架或暫停某個功能，不用動到整個應用。
二、資料盡量留在自己手上
除了少數必須串接外部 API 的功能（電子發票、社群數據），其他資料都存在自己的資料庫或 localStorage。不把核心業務資料交給第三方平台，是這個工具箱的基本原則。
三、不過度設計
這是內部工具，不是 SaaS 產品。能用簡單方式解決的，就不引入複雜的架構。等真的需要再優化，不為假設中的未來需求過度設計。
開發過程的實際心得
做工具箱和做產品最大的差異，是使用者就在你旁邊。
每次新功能上線，隔天就有人在用，立刻有真實的使用回饋。「這個步驟可以跳過嗎？」「圖片替換能不能一次全部填？」這些回饋比任何 user research 都直接。這種緊密的回饋循環，讓每次迭代都很有動力。
另一個心得是：完美是進度的敵人。工具箱一開始只有文章上架工具一個功能，設計也很陽春。但因為它解決了一個真實的痛點，大家開始用，才有後來不斷加功能的動力。先做出能用的，再慢慢變好。
常見問題 FAQ
Q1：Next.js 適合用來做內部工具嗎？
非常適合。Next.js 的 API Route 讓前後端整合在同一個專案，不用另外維護一個後端服務。對於中小型的內部工具來說，這種架構的開發和維護成本都很低。如果你已經熟悉 React，上手 Next.js 的內部工具開發幾乎沒有學習曲線。
Q2：為什麼不用 Python + Flask 做後端？
如果團隊成員以 Python 為主，Flask 或 FastAPI 確實是好選擇。我選 Next.js 的原因是：前端 UI 也需要快速迭代，用同一套語言（TypeScript）處理前後端，可以減少切換語境的摩擦。這是個團隊技術棧的選擇，沒有絕對的對錯。
Q3：Zeabur 和 Vercel 部署 Next.js 有什麼實際差異？
最關鍵的差異是資料持久化能力。Vercel 的 Serverless 架構沒有持久磁碟，每次請求結束後檔案系統狀態就消失，無法使用 SQLite。Zeabur 支援 Volume 掛載，可以讓 SQLite 資料庫正常運作。如果你的工具需要本機資料庫，Zeabur 是更適合的選擇。
Q4：自己做內部工具需要多久才能上線？
第一個功能大約花了一週做出可用版本。從有想法到第一個同事開始用，差不多是五個工作天。之後的每個新功能，快的三天、慢的一週。關鍵是先做出能解決痛點的最小版本，而不是一次把所有功能都做完。
Q5：這個工具箱只適合工程師嗎？需要會寫程式才能用嗎？
使用工具箱完全不需要寫程式。工具箱的設計目標就是讓行銷人員、編輯、業務等非技術職能的同事直接上手使用。唯一需要技術背景的部分，是最初的建置與部署，以及日後新增功能的開發。一旦建好之後，日常操作就跟使用一般網頁工具一樣直覺。
總結
自己做工具箱，不是每個團隊都需要走的路。但如果你遇到以下幾個條件同時成立，這條路非常值得考慮：
- 團隊有高度重複的手工作業流程
- 現有 SaaS 工具要嘛太貴、要嘛功能不符需求
- 團隊裡有人能寫程式，或願意學
- 對資料掌控度有要求
用 Next.js + TypeScript + Zeabur 這套組合，從想法到第一個功能上線，一週內可以完成。之後隨著使用回饋持續迭代，工具箱會愈來愈符合你們自己的工作流程。
這個系列接下來幾篇，我會分別深入每個功能模組的技術細節。下一篇是文章上架工具——HTML 清洗精靈是怎麼做的，敬請期待。
