vibe coding 打造跨平台自用小工具
以下記錄我如何和 AI 助手一起，在 4 天內做出一個「拖曳檔案、自動分類上傳」的桌面程式。
整個開發與寫作過程由 1 人（我） 與 1 個 AI agent（Claude Code） 協作完成（以下可能會簡稱為「我們」）
使用流程：把檔案拖進視窗後，LLM 會自動判斷要上傳的 Google Drive 目錄。LLM 要用免費、免掛信用卡的方案！
為什麼想做這個程式？
主要的動機，還是想要玩 AI 的 Vibe Coding；不過，總是要找一個自己真正需要的題目，才會覺得好玩、想完成；另外，也是想要試試現在要寫一個「在 Windows 上或 Mac 桌面上跑的程式」，是不是變得很簡單？再來，也要用到 LLM，尤其是想知道「免費的額度」可以做多少事？綜合起來就變成這個自己平常用得到的工具了。
雖然說是自動歸檔 Google drive，不過其實我的 Google drive 非常亂，所以 LLM 要歸的目的地只有一個限縮過的清單，至少清單上的分類是講得出邏輯的，而且被免費 LLM 知道內容也沒有關係的狀況；也就是說這個程式或 LLM 並沒有讀取我整個 Google drive 來建議怎麼分類，而是讀了一份只有 8 個目的地的用途說明的清單，來決定「八選一」。
計畫模式：事先搞清楚 AI 想怎麼做
就算自己沒寫過，也聽過網路上很多人用 Vibe Coding 的時候無法控制 AI，所以開始使用之後發現它有個「計畫模式（Plan Mode）」：可以把自己的需求，讓 AI 展開成非常詳細的計劃，而且可以對計劃討論很久、修修改改、一直到很滿意很充實很有結構的一份計劃書完成後，才開始寫程式。（當然我猜想這可能是我這 20 年來工作的職業病，畢竟做 PM 就是在程式實作之前「規劃」，所以看很詳細的上千字 Plan，並不會覺得吃力反而覺得安心。）
💡 這就像是動工前的工程圖，與其一邊挖地基一邊想水管怎麼接，計畫模式更像是在圖紙上先把水管走線、電線管道畫清楚；等方向確認後，再開始動手組裝。
計畫模式的工作流大致如下：
- 我拋出想法：告訴 AI 我的功能需求。
- AI 展開研究：AI 自主讀取需要的資料，分析潛在衝突。
- AI 遞交計畫：寫出一份明確列出需要實作哪些程式的步驟。
- 我審核批准：我仔細閱讀計畫，確認設計取捨（這時有可能會一直倒回前幾步），最後批准計劃可以開始實作。
- AI 開始執行：AI 轉入執行模式，依計劃開始做每個步驟。
免費私有倉庫：安心的版本時光機
對於非工程師來說，版本控制好像很難、遙不可及。實際上，GitHub 就能提供免費的私有程式碼倉庫（Repo, Repository 的簡稱），當作「只有自己（與自己的 AI）能存取」的備份空間。
所有的備份與版本控制動作，都可以交給 AI 代勞，不必擔心自己不會指令。我的習慣是從計劃書剛完成的時候，就會要求 AI 開始做版控。第一件事就是把計劃書存好，畢竟之後還可能會修修改改。再來在每一階段完成的時候，也會叫它備份到 GitHub，這樣我就會覺得很安心，因為隨時都有備份。
版本控制帶來 2 種安全感：
- 無壓力嘗試：就算 AI 做了幅度比較大的修改，也可以「一鍵時光倒流」。
- 雲端雙向同步：進度與文件都有雲端備份，即使本機出狀況也不怕。
勤寫文件：AI 不健忘的祕訣
很多人和 AI 聊久了都遇過同一件事：對話一拉長、或換了新 session，先前說過的規則就開始遺失。可能也是來自於這 20 年做 PM 的職業病，覺得寫文件很重要，我就會一直提醒 AI「把這寫進文件！」這等於替 AI 準備了一堆可隨插即用的「外接記憶卡」。
這次的專案中，我一邊叫它寫的文件有 4 個：
| 檔案名稱 | 它在專案中扮演的角色 |
|---|---|
CLAUDE.md | 指令與快速索引。集中記錄測試與打包語法，方便 AI 在開局快速對齊本機指令。 |
PLAN.md | milestone 計畫表。記錄了每一個開發階段的詳細藍圖、已完成事項與待辦事項。 |
learning-notes.md | 中間有那種「我自己不懂，但是 AI 懂」的東西，或是我們一起「踩雷」之後搞懂該怎麼做的事情，這一類的就會叫它寫在這裡。雖然雜七雜八，但是之後可以從這個文件再整理出也許可以分享的東西 -- 例如這個網頁囉～ |
next-version-wishes.md | 下一版的 Wish。這個不用說，「先放進 wish」就是 PM 的大絕招 XDD 現在的版本還是要先完成，中間突然想到可以加做的規格，下一版再做！ |
測試？當然叫 AI 自動化做阿！必要的再手動做
一開始，AI 很詳細列出所有需要 QA 的 case，但我看了很頭痛，測試不是就是應該 AI 來做嗎？ All I need to do is "Ask!" 後來它一共寫了 32 個自動化測試 & 不用我說一句話就會自己做完；不過它還是說有一些必須要由我來測試，幸好只有 4 項，就勉為其難地一步步照指示做了⋯⋯
作業系統底層的「檔案拖放」手勢，是由系統的視窗管理器在底層負責傳遞與對接，自動化測試不容易達成。
大驚喜～ 雲端自動化編譯
測試都過了之後，接下來最麻煩的關卡是：怎麼把這套程式打包成一般直接點兩下就能用的執行檔？
我的筆記型電腦硬碟容量相當有限，不想為了偶爾編譯程式在本地下載好幾十 G 的軟體編譯工具，而且我在 Mac 上玩 vibe coding，想打包出 Windows 執行檔，可以嗎？
萬事通 AI 的協助下，採用 GitHub Actions。它是一個跑在雲端的自動編譯流程，步驟大致如下：
- 我將程式碼推送到私有的雲端倉庫。
- 雲端 Actions 自動觸發，啟動一台乾淨的虛擬電腦。
- 它在雲端下載所需環境套件並開始封裝。
- 短短幾分鐘後，它就把 Mac 的軟體安裝包、以及 Windows 的可攜式資料夾封裝完畢。
這個做法幾乎不佔用本機硬碟與運算資源，而且雲端編譯本身也不需要額外付費。把打包交給雲端處理後，本機負擔會小很多。
☁️ 雲端編譯工廠就像是：不必在客廳自己開一間工廠、也不用搬來一堆重型機具；把設計圖交給雲端工廠後，它就會協助產出跨平台的成品。
免費 LLM 額度比想像中的大 & 實測數據大公開
把大語言模型拿來做檔案分類時，第一個常見疑問是：「每次分析檔名都要呼叫一次 API，成本會不會很高？」
以這個專案的實作方式來看，目前整體仍在免費額度內運作，而且開發與使用過程中沒有綁信用卡。下面是實際量測到的數據：
| 量測項目 | 官方免費限額 | 我會上傳的檔案的實際消耗狀況 |
|---|---|---|
| 單次輸入消耗 | 大約數十萬 tokens / 次 | 平均每次 ~1,000 tokens（包含檔名與預覽內容） |
| 單次輸出消耗 | 大約數萬 tokens / 次 | 平均每次 ~1,240 tokens（其中約 1,100 tokens 是大腦推理時自己想的思考單位） |
| 每日額度消耗比例 ⚠️這個才是比較容易碰到的限制 | 每日限額約 250 次呼叫 | 我平均每天會上傳的檔案才「幾個」，就算測試期間也只佔了每日上限的 2% |
從數據可以看出：回傳的分類 JSON 本身不長，但推理階段的消耗相對明顯。即便如此，以個人自用的情境來看，每日免費額度目前仍然夠用。
小結：如果是個人很簡單的少量使用 LLM 來做日常輔助，可能真的用 Google AI 的 free tier 是完全足夠的！
回顧 4 天開發過程
| 開發階段 | 具體進展與關鍵轉折 |
|---|---|
| Day 1 (8.5 hr 含卡關 5 hr)： 撞牆與果斷停損 |
原本選用新穎的介面建構工具，但跨平台封裝測試時，連續失敗 8 次耗了幾小時。分析後確認是套件生態與環境相容性問題，於是改成切換到老牌、較穩健的經典視窗工具。因為 AI 的程式架構設計得不錯，介面更換只重寫了 3 個檔案。 |
| Day 2 (3.5 hr)： 新介面與架構對接 |
用新的視窗工具重構介面，並把它與既有的硬碟上傳、AI 分類邏輯接起來；接著在本機跑通基本流程，並補上必要的測試環境。 |
| Day 3 (3 hr)： 測試網建立與邏輯穩固 |
這一天把重點放在穩定度：在 AI 協助下撰寫自動化測試，涵蓋網路斷線、API 回傳無效格式等情境，並確認本機測試能順利通過，確定可以進入最後的打包。 |
| Day 4 (3.5 hr)： 雲端打包與雙平台綠燈 |
進入最後封裝階段：捨棄會導致 Windows 首次啟動過慢的單一檔案封裝模式，改用可攜式資料夾封裝；同時把 GitHub Actions 的雲端編譯流程設定好，產出 Mac 安裝包與 Windows 可攜式封裝。 |
That's all! 原來 vibe coding 不過就是這麼回事：先打開 AI 助手跟它聊你想做什麼、讓它幫你規劃。你不需要事先學會所有艱深的軟體工程知識，有個目標、有個 AI 夥伴、有時間，人人都能輕鬆 ship 屬於你自己的跨平台桌面小工具！ 🛠️