一、緣起
為什麼想做這個 App
我們家對「娛樂費」有一套自己的規則。
除了每月預算，還有獎勵(例如有運動就+300元😃），原本使用共用記事本軟體條列式記帳，每月人工結算，覺得步驟有些繁瑣，而市面上的記帳 APP 功能較複雜，也不符合我們自訂規則，我只是想要單純看我們有多少娛樂費用還沒花！剛好今年在實作 Vibe Coding，這種規則明確規模又小的案子很適合當起步的專案，沒想到我和 Claude Code 搗鼓不到一天 APP 就做出來啦！
🎉先來張成果照！
功能：月份導覽、預算摘要、費用記錄、運動記錄、超支警示、跨年到期提醒
二、規格驅動開發：先想清楚再動手
什麼是規格驅動開發（SDD）？
先把「要做什麼」寫清楚，確認沒問題，再開始動手。 就像蓋房子先畫藍圖，不是拿起鐵鎚就開始敲。AI 因為有上下文窗口限制，以及分段作業，可能做了後面忘了前面，先把需求與規格寫好，就像路線圖，讓 AI 每個步驟都照著計劃走。
我的工作流程（OpenSpec 工具）
OpenSpec 就像是給 AI 用、關於 SDD 的 SOP，安裝後，要求 AI 開啟 OpenSpec 專案，它就會"盡量"依照 OpenSpec 規定的文件流程進行。
AI 執行 OpenSpec 的流程 (重複迭代、逐步加入新功能)
- 提案：這個功能要解決什麼問題？不做什麼？(可以重複討論確認設計方向)
- 設計：依據提案劃定本次變更邊界(Goals & Non-goals)、重要決策與風險
- 規格：依照設計文件，用情境（Scenario）描述系統行為
- 任務：按規格寫展開具體的工作任務，讓AI照著做不跑偏
- 實作與驗證：AI開始實作，做完自己檢查，再來人工檢查
- 歸檔：記錄這次的設計決策，寫入這個APP的規格書中
具體安裝與使用方式，我是參考這份教學：OpenSpec 讓 SDD 變簡單的三個指令
除了使用OpenSpec管理新增與變更，我這次另外用兩個文件管理整個開發過程，這兩份文件是由人類和 AI 共同維護。
execution-plan.md：
這其實是最一開始的文件，先跟AI聊專案需求、可行性，請它寫計劃書，到了實作階段這份文件就變成進度追蹤清單，哪步驟由誰負責(人或AI)、每完成一個任務就打勾。對新手來說，進度清單和設計文件分開更清楚，不容易混淆。ToDoList.md：
把途中的想法、靈感、疑問先寫下來，等AI做到一段落，再跟它討論，值得併入規格的就開啟新的一輪 OpenSpec 專案。
為什麼值得這樣做
- 早點發現設計漏洞，比程式碼寫了一半再改便宜 (再次提醒，每次變更完一個功能，記得Git commit 備份)。
- 讓 AI 有共同的設計基礎，每次重新啟動時可以讓AI先讀文件，不用從頭解釋。
- 每個環節與 AI 討論的過程中，強迫自己說清楚「不做什麼」，避免範圍無限擴張。
三、邊做邊學：跟 AI 說「我是新手」
新手怎麼跟 AI 協作
專案一開始，我明確說：「我是沒有網頁APP開發經驗，請做每個技術決定時詳細說明並提出優缺點比較」、「我想要紀錄這次開發中，可以遷移到其他專案的經驗或步驟，請幫我記錄」。這些要求，請 AI 寫到系統提示詞(Claude.md)中。
此專案中，Claude.md 中的協作原則：
- 先討論再動手：前端架構、後端選型、任何新模組或檔案，都需先與使用者討論並取得同意後才實作
- Git 提交時機：功能更新且驗證 OK 後，進行 `git commit`（需使用者確認）
- 開發經驗記錄：遇到可遷移至其他專案的軟體開發經驗，記錄至 `dev_exp.md`
- 使用者為網頁 APP 開發新手，說明技術選型時需解釋前後端概念與取捨理由
人類和AI共同寫學習記錄：dev_exp.md
這份文件記錄三種內容：我問AI學到的概念、值得遷移的決定或步驟、採過的坑
我會把 AI 協作經驗沉澱成可重複使用的流程。很多經驗只有在實作中才會學到，也會發展出自己適合的工作流程，雖然是野路子(不是專業工程師)，但這也是我花時間磨出來的，如果幾個月後要開啟新專案，流程又要從頭想，就太不值得了。
例如，ToDoList.md 管理我途中冒出的問題與靈感，等AI工作到一段落時再讀取此文件跟我討論，這個與AI的協作文件，就是我上個專案中帶過來的方法。
另外一個例子是我這次專案中的經驗，我發現開發完、APP 做出來之後，動作就停在這了，其實有很多收尾工作要做。我與AI討論寫了一個Check List，下次專案做完，記得要根據這個SOP收尾，有始有終。
四、程式架構長什麼樣
來聊聊這個 APP 的架構：
技術選型
在開始這個專案前，我大概知道一個軟體會包含前端、後端、資料庫、部署平台等部分，但工具很多，不知道怎麼選，所以要求 AI 逐一跟我討論。比較特別的是，我卡在「後端」選擇，我問 AI 後端是用 Python 嗎？才發現原來可以不需要單獨寫後端！這時才知道 BaaS（後端即服務 Backend as a Service）的概念，一般的網頁 App 需要「前端 + 後端伺服器 + 資料庫」三層。BaaS 是把後端和資料庫外包給現成的服務（如 Supabase、Firebase），登入驗證、資料庫 API、權限控制都由平台提供，自己只需要寫前端。
資料庫設計
如果有些資料庫、excel資料抓取概念，可以和 AI 討論並檢查AI設計的合理性。這次協作中，我有發現 AI 設計不符合我的需求，提前阻止，避免之後再回來修改浪費時間。這個經驗讓我很有成就感，我之前花時間學的SQL基礎沒有白費。
資料庫中有五張表：
expenses：費用記錄（日期、分類、金額、記錄者）exercises：運動記錄（含加碼金額快照）categories：費用分類（美食、電影、展覽、遊戲）app_settings：全域設定（月預算、加碼金額）yearly_balance_cache：年度結餘快取（加速計算）
UI 設計
我對設計很沒有想法，但又覺得直接讓 AI 寫出來的外觀很醜，所以每次都是先跟AI討論外觀，但結果不一定每次都滿意，這是我之後有新專案要持續優化的部分，或許之後可以找到風格我喜歡的設計 Skill。
在這次專案中，AI 給了幾個市面上的記帳APP給我參考，討論出以下設計原則：
- 行動裝置優先，參考台灣記帳 App「記帳城市」的圓角卡片風格。
- 品牌色：強調色朱赭
#d94f2a，搭配暖米白#f7f3f0背景。 - 多使用 emoji：這是家人喜歡的風格，特別加入的要求！
- 請AI跟我討論 Logo 設計提示詞，然後分別貼給 Gemini 和 ChatGPT，擇優使用。
驚喜：真的變成手機APP！
我一開始預設目標就是網頁 APP，所以我想像中的使用方式是：開啟瀏覽器→輸入網址(或加入書籤) → 進入 APP 記帳。讓我驚喜的是，手機的 Google 瀏覽器，竟然有把網頁 APP 變成手機中 APP 的功能！有興趣的人可以去搜尋：PWA (Progressive Web Apps，漸進式網路應用程式)。
五、結語：你不需要先學完才開始
你不需要先學完才開始。
用 AI 做工具這件事，現在的確變得很可行。我沒有網頁開發的背景，但最終做出了一個有 Google 登入、資料庫、跨裝置同步的 App，部署在正式網址上。我是邊做邊學，要求 Claude 解釋「為什麼這樣設計」、「有什麼取捨」，每個概念都是在需要的時候才了解的，帶著真正存在的需求去學，比看完教學課程，再動手快很多。只有真正去做，才知道自己需要學什麼。
最重要的習慣
- 先討論設計，再動手實作。AI 在執行層面的效率很高，但它無法替你想清楚「你到底要什麼」
- AI也會算錯(這次就有遇到)，重要的邏輯，要自己驗算。特別是牽涉到自訂規則的複雜計算，一定要自己舉例走一遍。
- 記錄學習過程，寫給未來的自己。做完一個專案，帶走的不只是這個 App，而是下次可以用的 checklist。這才是讓每次嘗試有意義的方式。
Vibe Coding，重點已經不是提示詞怎麼寫，而是怎麼管理整個工作流。利用文件結構，讓 AI 按照計劃把整個流程跑完，把步驟遷移到下一個專案。
AI 讓「做一個只給自己用的小工具」這件事變得真的可行。不需要先學完才開始，只要有不怕折騰的耐心。放心，電腦不會被你用壞，壞了問 AI 就好（好啦，也有可能不小心整個專案被 AI 刪掉，再次強調版本控制與備份很重要）。
後記：家人看到成果後說：「你好厲害喔！」，下一秒：「那你可以寫記錄追蹤水電費的APP嗎？」🤣🤣
