[心得] 因為找不到完美的記帳工具，我讓 AI 幫我寫了一個：TallyLite 開發心得

TallyLite 是我根據自己的記帳需求打造的一款網頁應用程式，也是我第一個公開部署的 Vibe Coding 作品。

在這篇文章裡，我想分享我初次使用 AI IDE 工具 Google Antigravity 打造產品的經驗，以及在構思、優化 TallyLite 的過程中的思考過程、踩過的坑、和學到的經驗與好用工具。

Why - 為什麼是記帳？

俗話說：「你不理財，財不理你」。

「記帳」一直以來都是非常熱門的新手開發主題，從市面上有各種不同的記帳工具和流派就知道。

從「功能面」上，有的工具只有基本的加減乘除，有的進階到會自動對帳、AI判斷掃描。 有的工具在「介面」上做出了差異化，無論是精美的筆記手帳，或是硬派的Excel 表格都有。甚至還分成多種「流派」，有著不同的管理哲學和對帳方法論。

這些面向都很重要，不過對我而言像是「基本需求」，但不是讓人覺得 Wow，或是「是少了這個工具會很困擾」的層級。

關鍵，我認為是要深度符合個人的習慣。

對於想快速開始、還沒有基礎概念的使用者，提供基礎知識架構和快速上手模板是幾乎是必備功能。

對開始用一段時間的用戶，會開始思考如何讓每天記帳變得更輕鬆，或者是想看資料時能更好閱讀、美觀、有好的精神回饋，才能讓這個習慣持續下去。

再用得更深入一點，也許有些人和我一樣，會開始覺得「好像少了一些些方便」，這時有兩種路：一種是學著讓自己去適應工具的框架，另一種就是轉頭離開，尋找下一個機緣。

作為深度使用者，我自己本身就有足夠的動機與使用場景。而 AI工具又讓開發的成本大幅降低，使高度個人化的解決方案成為了可行的選項。

What - 我想建立什麼？

在構思這個產品時，我最初的目標包含：

1. 我希望可以延續我過去記帳的資料以及使用習慣，也就是說資料要能夠匯入、匯出，結構上以及操作方式不會和我過去習慣差太多。
2. 我希望 App 能降低使用的摩擦力，也是我過去碰到、希望優化的問題，例如：無廣告、開啟速度要快、資訊能依照我的習慣最佳化的顯示。
3. 我希望能夠快速、甚至免費的打造 MVP，後續再根據我的使用狀況逐步優化。我不希望把時間放在管理 infra 和程式碼。

除了以上核心需求之外，在過程中我還思考了這些面向：

1. 「我」會是這個產品最重要的 End User，因為這是要解決我的問題，所以勢必會有些使用情境的取捨和優先順序。
2. 這個 App 也許哪天會有公開註冊、多人使用的場景，所以需要有基本的帳號權限管理、Onboarding、以及Demo 體驗功能，架構上也需要做到可擴充性。
3. 在使用平台上，最後選擇了最方便可以跨裝置使用的 Web App，省去 Android 與 iOS 平台的開發、上架、維護工作。而事實上在使用體驗上並沒有掉分太多，而顯著的節省開發過程中的許多麻煩。

How - 工具與方法

整個 App 的開發核心都是「Antigravity」，從一開始還只有 Gemini 2.5 pro 到後來 Gemini 3、Opus 4.6 等模型出現，我一行程式碼都沒寫，全部是透過 Prompt 的方式請 AI 進行開發以及除錯。

當然，作為人類與核心使用者，我的角色包含：盡可能清楚完整的提供需求資訊、進行測試驗證、回報具體的錯誤內容與位置、版本管理與上架部署。

infra 與 部署的部分，我使用的是「Firestore」與「Vercel」。最初曾一度想過 GCP 服務，但因為設定實在太複雜了，上述兩個 PaaS 服務相較之下簡直省力到不行。所有的工具操作步驟也是透過與 Gemini 討論時慢慢摸索出來的。

Lesson Learned

開發過程雖然是透過 Vibe Coding，但免不了會需要不只弄髒手，還會因為不斷地 bug 而弄髒一段時間的心情。

面對這些還沒殺死我的疑難雜症，我學會如何克服；克服不了的，我更學會如何繞開！例如：

1. 驗收還是得靠人類
   要一直提醒 AI 不要自己螢幕錄影就覺得測試完成，很多時候AI 試著模仿使用者操作瀏覽器，反而會加快燒 Token 的速度以及讓回應時間變得太久。最重要的是，最後的品質把關很不可靠，在這個當下，最好還是靠人類來做驗收。
2. 改架構前先鎖 Code
   要進行需求變更、可能更動到架構前，請 AI 不要更改任何程式碼，先進行一是完整的評估報告。AI 的自動執行讓整個操作流程變得絲滑，但太過絲滑有時候他會自己把整個架構毀了最後無法回頭。例如我曾經想過 Web 版完成後要做一份 iOS 版本，結果整個 Code 的架構被大量改寫，不止直接燒光 Token額度，也讓原本可以運行的版本直接壞掉，最後我直接透過 Git 還原上一個版本，並且永遠封印之後改成多平台的想法 （當然也是因為發現 Web App 在手機上用起來也很順暢）。
3. 人類才是專案的瓶頸
   版本控制、資安、UI設計、甚至是 infra、資料庫等概念在 VibeCoding 的過程還是越來越讓我覺得需要慢慢地建構起這些知識。 AI 越聰明，身為人類的我很快或者已經成為整個專案的瓶頸，甚至重要的決策也會因為我的誤判造成輕則浪費時間、重則毀滅 (功能上、專案上、和心態上都是)。
4. 先規劃，再動手
   AI 太習慣一開始就動手開發，然後會告訴你要啟用什麼什麼服務，但很多時候開發跟服務架構一旦定下去，後續要做變更時就會非常麻煩。而且，作為非工程師的人類，對於 UI 和操作體驗的細膩程度的要求更高，把情境和畫面定義好再進入開發，絕對會對於最終品質和開發時間都很有幫助。UI 上最好還能直接提供範本截圖，就算是手繪的草稿也能大幅降低成果與期待的落差。
5. 用不到的功能不要做
   雖然是很典型的 MVP開發的原則，而且自己作為使用者，開發過程難免還是會落入畫大餅給自己、然後花了一堆時間開發、除錯，最後蓋出蚊子館的狀況。除非需求情境很明確，而且最好能將需求和原本的功能獨立乾淨，否則先不要更動，而是作為使用者操作一段時間，還是覺得需要再動手，會是更好的選擇。 當然，如果可以無痛的生出「測試功能」會是更好，因為可以更快的得到反饋，前提還是需求要存在而且不要把其他完整的功能給搞壞。

Next Steps

TallyLite 上線使用已經有快兩個月的時間，目前我需要的功能大致完整，當然也想過有一些更進階的情境，例如和 LINE PAY 或刷卡通知串接、更細的預算管理功能、開放線上註冊、介面優化等等，不過我決定先暫停下來，讓產品穩定一段時間，一方面是累積這段時間的使用心得，如果有些需求夠「癢」、夠「痛」再調整，另一方面把時間心力放在優化生活的其他面向。

Agent 時代來臨，將會有越來越多人和我一樣獲得自己開發小工具的能力，甚至不需要小工具，全部交給 AI 就好。

也許 TallyLite 過不了一年也會被其他工具取代，而那時候我想我會更清楚自己的需求是什麼，或者有更好的能力與工具去打造更適合我的解決方案。當製造成本不斷降低，重複造輪子，而且是因人因地制宜的輪子，未嘗不是一件好事。

如果你對 TallyLite 有興趣，TallyLite 有支援用「訪客模式」登入： https://tally-lite.vercel.app/

1. 免註冊、免登入。
2. 內建自動生成的測試資料，更好想像實際狀況。
3. 每次重新開啟時資料都會重置，不用擔心玩壞！

如果你有興趣成為早期使用者，或是和我分享其他想法與建議，歡迎留言或直接聯繫我！

期待你的訊息。歡迎來信： alfred.mc.hsu@gmail.com