MapleCheng

在浩瀚的網路世界中無限潛水欸少年郎!

0%

Side Project 週末開發心法:EmberBooks 記帳系統的誕生

每個工程師都有一堆「有一天要做」的 side project。手機備忘錄裡躺了十幾個 idea,每個都覺得「這個週末來做好了」,然後週末就在耍廢中度過。EmberBooks 是我少數真的做出來、而且每天在用的 side project,今天來聊聊它的誕生過程。

動機:一切始於「沒有 API」

我有記帳的習慣,已經持續好幾年了。用的是一個還不錯的記帳 App,介面漂亮、操作順手,但有一個致命的問題 — 它沒有 API。

為什麼我需要 API?因為我有一個 AI 助理,它幫我處理很多日常事務。我希望它也能讀取我的帳務資料,每個月自動生成消費分析和月報。但沒有 API,AI 就像一個瞎了眼的財務顧問 — 什麼數據都看不到,只能嘴砲。

我曾經想過用爬蟲去抓那個 App 的資料,但想想還是算了,太髒了。然後我想過等它開放 API,但看了看它的更新頻率… 算了,不等了。

與其等別人,不如自己寫一個。

這就是 EmberBooks 的誕生動機。不是要做一個打敗市面上所有記帳 App 的產品,只是要做一個「有 API、能讓 AI 讀的記帳系統」。目標非常明確,這也是它最終能完成的關鍵原因之一。

EmberBooks 登入畫面

技術選型:選自己熟的,不要選最潮的

Side project 的技術選型和公司專案不一樣。公司專案要考慮團隊能力、長期維護、生態成熟度;side project 只要考慮一件事 — 你能不能在週末把它做出來

Monorepo(pnpm workspace)

前後端加上共用型別,全部放在一個 repo 裡。用 pnpm workspace 管理。為什麼選 monorepo?因為一個人開發的時候,跳來跳去切 repo 超煩的。改一個型別,前後端都要同步更新,放在一起就不會忘記。

TypeScript 全套

前端 TypeScript、後端 TypeScript、共用型別也是 TypeScript。同一個語言寫到底,型別定義一次就能前後端共用。

有人可能會說「後端用 Go 或 Rust 效能比較好」。說得對,但這是記帳系統,不是高頻交易平台。我一個人用的東西,TypeScript 的效能綽綽有餘,而且開發速度快很多。

後端:Node.js + Express

最無聊的選擇,但也是最實際的選擇。Express 生態豐富到什麼 middleware 都找得到,遇到問題 Google 一下一定有答案。我不需要在 side project 裡探索新框架,我只需要把功能做出來。

前端:React + Vite

同樣是選了最保守的組合。React 我最熟,Vite 開發體驗好、build 速度快。有人可能會問「為什麼不用 Next.js」— 因為我不需要 SSR,記帳系統純粹是 SPA 就夠了。少一個框架,少一堆要學的概念。

資料庫:MongoDB

記帳資料的結構其實蠻複雜的。支出、收入、轉帳、退款、分期、循環扣款… 每種類型的欄位都不太一樣。用關聯式資料庫的話,要嘛設計一大堆 table,要嘛搞一個很醜的 single table。MongoDB 的文檔型結構就很適合這種「基本上是同一類東西,但細節差很多」的場景。

認證:JWT + API Key 雙模式

人類用 JWT 登入前端介面,AI 助理用 API Key 打 API。兩種認證方式各走各的,互不干擾。API Key 可以設定權限範圍,例如只給讀取權限、或是只開放特定 endpoint。

開發過程:AI 是最好的 Pair Programming Partner

EmberBooks 的開發過程中,AI Coding Agent 幫了大忙。

AI 負責的部分

骨架搭建、CRUD endpoint、認證系統、錯誤處理… 這些幾乎全部由 AI 生成。我描述需求,它寫 code,我 review 後調整。一個完整的 CRUD API(包含 validation、error handling、TypeScript 型別)大概 10 分鐘就能產出,以前自己手寫至少要半小時到一小時。

人工負責的部分

UI 設計決策是 AI 做不好的。「這個按鈕放左邊還是右邊」「月報的圖表要用折線還是長條」— 這些需要審美和使用者體驗的判斷,還是要人來。

業務邏輯也是。信用卡的帳單計算、分期付款的利息計算、轉帳時兩邊帳戶的配對邏輯… 這些東西有很多 edge case,AI 的初稿通常能涵蓋 70% 的情況,剩下 30% 要靠人腦補完。

資料遷移:最大的坑

從舊 App 匯出 CSV,然後寫 importer 自動匯入到 EmberBooks。聽起來很簡單,做起來想哭。

首先是金額的正負號問題。舊 App 把支出存成正數(因為「花了 500 元」對使用者來說是正的),但我的系統把支出存成負數(因為帳戶餘額減少了)。一個轉換沒做好,整個報表數字就全部反了。

然後是轉帳配對。從 A 帳戶轉到 B 帳戶,在舊 App 裡是兩筆獨立的紀錄(A 扣款、B 入帳)。在我的系統裡,轉帳是一筆紀錄,同時記錄來源和目標帳戶。怎麼把兩筆配對成一筆?金額相同、時間接近、一正一負 → 大概可以配。但如果同一天有兩筆一樣金額的轉帳呢?那就只能手動處理了。

重複偵測也很頭痛。匯入過程中如果程式中斷重跑,怎麼確保不會產生重複資料?最後我的做法是用舊 App 的 ID + 交易時間做 unique key,匯入前先檢查有沒有重複。

800 多筆交易,最後花了我一整個週末才搞定。其中大概 95% 是自動匯入的,剩下 5% 手動處理。

功能亮點

做完之後回頭看,EmberBooks 的功能還蠻完整的:

10 種記錄類型。 支出、收入、轉帳、退款、分期付款、循環扣款、信用卡帳單、預付款、調整、手續費。基本上日常會遇到的金流類型都有了。

信用卡帳單管理。 設定帳單日和繳款日,系統自動把期間內的刷卡記錄歸到對應帳單。每期帳單有獨立的對帳頁面,可以和銀行帳單核對。

分期付款用 Project + Tasks 的概念。 一筆分期付款就是一個 Project,每一期就是一個 Task。建立的時候自動產生所有期數,每期到期時自動提醒。這個設計讓分期的管理變得超直覺。

報表 API。 月報、年報、分類趨勢、預算追蹤 — 全部透過 API 提供。這就是為什麼我要自己寫的原因 — 有了 API,AI 助理就能自動拉數據、生成分析報告。

AI 助理整合。 這是最爽的部分。我跟 AI 說「午餐 120 元」,它就自動在 EmberBooks 建立一筆支出記錄,類別是「餐飲」,帳戶是我的預設付款帳戶。不用打開 App、不用選類別、不用輸入金額 — 說一句話就搞定。

現金流預測。 看未來三到六個月的預測:固定收入(薪水)扣掉固定支出(房租、帳單、分期)之後還剩多少。這個功能幫我做財務規劃的時候非常有用。

EmberBooks Dashboard — 月概覽與支出分類

EmberBooks 月報 — 圓餅圖與每日趨勢

Side Project 心法

做了 EmberBooks 之後,我整理出五個 side project 能做出來的心法:

1. MVP 先行

第一版的 EmberBooks 超陽春。沒有前端,只有 API。我用 Postman 測完所有 endpoint,確認能跑之後,才開始做前端。前端第一版也醜得要命,但能用就好。

很多 side project 死在「我要先把架構設計完美」。不要。先做一個能用的最小版本,用了之後你才知道什麼功能重要、什麼功能根本不需要。

2. 善用 AI

Boilerplate 讓 AI 寫就好了。把你的精力留給核心邏輯 — 那些 AI 搞不定、需要人腦思考的部分。一個 CRUD endpoint 讓 AI 寫 10 分鐘搞定,你省下來的時間可以去想「分期付款的利息怎麼算」這種真正有價值的問題。

3. 自己當用戶

EmberBooks 能做出來,最大的原因是我自己每天都在用。自己當用戶的好處是:你知道什麼功能真的需要、什麼 bug 真的很煩。而且因為自己用的東西,做起來有動力。

那些「我覺得別人會需要」的 side project,通常活不過第三週。

4. 不要怕技術債

Side project 不是公司產品,不需要寫得像教科書。有些地方我知道設計不好,但先這樣用著,等真的痛了再重構。Side project 的目的是解決問題,不是拿去面試。

5. 記錄過程

這個很重要。我在 EmberBooks 的 repo 裡維護了一份詳細的專案文檔,記錄了架構設計、API 規格、資料模型、開發紀錄。這份文檔不只是給自己看的,更是給 AI Coding Agent 看的 — 它讀完文檔之後,就能理解整個 codebase,之後要加功能或修 bug 都很快。

和 AI Coding Agent 協作的心得

最後分享幾個和 AI Coding Agent 協作的心得:

給 Agent 完整的專案文檔。 不要假設 Agent 知道你的專案結構。寫一份好的 README 或 CLAUDE.md,描述清楚架構、慣例、技術棧。Agent 讀完之後產出的 code 品質會好很多。

把需求寫成具體的 spec。 「幫我做一個記帳功能」和「新增 POST /api/transactions endpoint,接受以下欄位:amount (number, required), category (string, required), description (string, optional),回傳 201 + 建立的記錄」— 後者的產出品質直接翻倍。

複雜的商業邏輯還是要人想。 Agent 很擅長實作,但它不擅長「想」。信用卡帳單的計算邏輯、分期付款到期日遇到假日怎麼辦、同一張卡兩筆分期的帳單怎麼合併 — 這些問題你想清楚之後告訴 Agent,它就能完美實作。但如果你叫它自己想,它通常會漏掉一堆 edge case。

結語

Side project 不需要改變世界。解決自己的問題就夠了。

EmberBooks 讓我的記帳從「每天手動打開 App、選類別、輸入金額」變成「跟 AI 說一句話」。一年下來,我多記了好幾百筆以前懶得記的小額消費,對自己的財務狀況也掌握得更清楚了。

如果你也有一個一直想做的 side project,我的建議是:不要再想了,這個週末就開始。第一版醜一點沒關係,能用就好。有 AI 幫忙的話,一個週末能做出來的東西比你想像的多很多。