Google Antigravity 實戰：我如何用 Vibe Coding 打造記帳軟體一鍵匯入工具
228 連假，我沒有只是「玩 AI」，而是真的拿它來解決生活中的麻煩事
這幾天是 228 連假。
連假對很多人來說，也許是休息、追劇、出門走走的時間；但對我來說，這次反而是一個很適合拿來做點實驗、把生活中一些長期卡著的小痛點真正解掉的空檔。
所以這次連假，我做了一件我自己覺得很有意思的事：
我試著用 Google Antigravity，打造一個可以讓我的記帳軟體一鍵匯入資料的小工具。
這不是什麼很炫的大型專案，也不是什麼要拿來創業的產品。
它其實就是一個非常生活化、非常個人化，但又真的困擾我很久的小問題：
我想把平常隨手記下來的記帳文字，快速整理後，直接匯入我用了很多年的本地端記帳軟體。
如果這件事做得成，後面每一次整理記帳資料，我就不需要再土法煉鋼、一筆一筆慢慢手動輸入。
而我這次最想分享的，也不只是「我做出了一個工具」這件事本身。
我更想講的是：在現在這個 AI 時代，所謂的 Vibe Coding，真的已經開始從「看起來很潮的名詞」，慢慢變成一般人也能拿來解決自己生活問題的實用能力。
尤其像我這樣並不是本科系出身、也不是職業工程師的人，過去如果聽到「自己做一個小工具」，第一時間大概會想到很難、很多語法、很多環境設定、很多除錯，然後就先退三步。
但這次我反而更強烈地感受到：
現在真正最重要的，已經不再只是你會不會寫 code，而是你能不能清楚知道自己的問題是什麼，並且把你要的結果講清楚。
工具，AI 會幫你做。
但方向，還是要你自己來定。
這也是我這篇文章真正想談的主軸。
我為什麼會想做這個工具？不是因為想炫技，而是因為記帳這件事真的太花時間了
先講結論：
我這次會想做這個工具，真的不是為了炫技，也不是因為突然想學寫程式，而是因為 我真的受夠了每隔一兩週就要花很多時間把記帳資料重新整理一次。
我自己已經記帳記了非常多年，差不多快 20 年。
我長期使用的記帳軟體叫做 MoneyAssistant (2.27版)。這套軟體其實已經是將近20年很老的工具了，作者也早就沒有在維護，但因為我真的已經用得非常習慣，而且資料也累積很多年，所以我完全沒有想要換掉它、也沒有想重新搬移資料庫。
它的優點其實很明確：
-
完全本地端
-
免費
-
分析功能很完整
-
可以把收入、支出、資產、負債整理得很清楚
-
視覺化圖表做得也不差
對我來說，像財務、帳戶、信用卡、支出這種比較敏感的個人資料，本地端工具其實反而比較讓人安心。現在市面上當然有很多雲端記帳 App，也有很多介面更漂亮的新服務，但只要資料是上雲的，我心裡多少還是會有一些顧慮。所以這麼多年下來，我還是一直留在 MoneyAssistant。
問題不是它不能用。
問題是：它很好分析，但輸入真的很古典。
它畢竟是 20 年前的軟體，所以很多資料都要自己手動輸入。
日期、支出類別、來源帳戶、目的帳戶、金額、交易明細……這些欄位都要一筆一筆自己填。
如果每天當下就很勤勞地輸入，當然還好。
但現實生活通常不是這樣。
我平常在外面如果突然有一筆支出，或臨時想到要先記一下，我不可能每次都立刻打開電腦端的記帳軟體慢慢選欄位。我比較常做的方式，是先用自己最熟悉、同步也最快的筆記工具，把資料簡單記下來。對我來說，這個工具當然就是 Evernote。
所以我平常的記錄方式其實非常簡單，甚至可以說很口語。
例如我可能只會這樣寫：
-
2/14 ChatGPT 630 富邦銀行卡
-
2/16 理髮 200 現金
-
2/20 高鐵 1490 中國信託卡
這樣的好處是很快，我在手機上、辦公室、家裡，任何地方都可以隨手記。
但壞處就是：這只是原始資料(無格式化的純文字)，並不是可以直接匯入記帳軟體的格式。
所以每隔一段時間，我就得重新把這些資料整理一次，再手動輸入到 MoneyAssistant 裡面。
如果我每週整理一次，大概至少要花半小時到一小時。
如果忙一點，拖到兩三週甚至一個月才整理，那很容易就變成上百筆資料，到時候往往得花上兩三個小時以上。
這種時間，說多不多，說少不少。
最煩的地方在於：它不是高難度工作，它只是很重複、很機械、很瑣碎，但偏偏又不能不做。
而且更麻煩的是，這裡面還不是單純複製貼上就能完成。
因為我在輸入記帳軟體時，還要做很多人為判斷。
例如：
-
這筆支出到底該歸到哪個分類？
-
是生活用品？還是數位工具？還是交通？
-
來源帳戶是現金、信用卡，還是哪個銀行帳戶？
-
明細欄位要不要補充更完整的說明？
也就是說，這不是單純的資料搬運而已，它其實還包含一層「理解」跟「對應」。
也正因為這樣，我才開始認真思考一件事：
既然源頭只是純文字，目標又只是把資料正確寫進資料庫，那中間這段重複的判斷流程，有沒有可能交給 AI 幫我處理？
如果做得到，那我未來記帳這件事，整個工作流就會輕鬆非常多。
這不是我第一次玩 Vibe Coding：過去這一年，我其實已經默默做了不少小工具
老實說，這次會想挑戰用 Antigravity 做這個記帳匯入工具，也不是憑空突然起意。
因為從去年開始，我其實就已經陸續在嘗試很多次 Vibe Coding 了。
而且我不是那種一開始就設定要做什麼很厲害的大專案，我大多數時候，都是從自己生活中一個很具體、很煩、很想省時間的小問題開始。
例如，最早我做過一個很簡單但很實用的小工具：
AI 語音轉文字格式太亂？獨創免安裝小工具『Remove Text Extra Spaces』幫你一鍵搞定！
這算是我當時很早期第一次嘗試 vibe coding，主要是把例如 NotebookLM 語音轉出來後始終夾雜一堆空格的文字排版，做快速整理與優化。
後來第二個比較有代表性的工具，是：
讓多格講義 PDF 瞬間變身好閱讀的逐頁投影片！— 免安裝小工具『Split pdf handout to image slide』讓你無痛轉換！
這個工具就是把傳統那種講師提供的一頁多格(實則難以閱讀)的講義 PDF，轉成更容易閱讀、也更方便投影或複習的逐頁投影片形式。
接著我又改良了網路上的開源工具做了第三款：
《Video to PDF with Transcription：免網路、快速轉影片成投影片+語音轉文字的免費工具！》
這個工具我自己也很喜歡，因為它結合了教學影片轉投影片，以及語音轉文字，對整理課程、會議或影片內容都非常實用，而且還可以純本地端離線處理。
再來，我也曾經部署過：
打造數位分身：F5-TTS 本地部署教學與語音克隆應用分享
這次就不是單純的文書整理了，而是進一步走到本地端 AI python 工具的部署，甚至做到語音克隆。這個工具對我來說不只是技術上的嘗試，也帶有很強烈的個人情感意義。
另外還有：
PDF文件翻譯神器！PDFMathTranslate 用 AI 打造你的專屬PDF全文雙語翻譯工具
這則是另一種很典型的例子：原本看起來很麻煩、很技術導向的需求，只要找到對的方法，其實也能一步一步變成一般人可以上手的本地工具。
除了 Python 類的小工具之外，我後來也慢慢把這種 Vibe Coding 的概念，延伸到自己常用的 Office 工作流裡。像是我後來整理分享過一些 PowerPoint 的 VBA 全自動化方法，例如：
這些其實本質上都很像：
不是因為我想「為寫程式而寫程式」，而是因為我每次都遇到同樣的麻煩，然後我開始思考，這種重複性高、規則明確、但很浪費時間的事，有沒有辦法交給 AI 或程式幫我做掉。
甚至到了今年年初，我也開始不只做 Python，還開始做 HTML 型的小工具。
像我在今年1 月下旬做的：
Blogger 轉 FB 貼文神器：純文字也能有層級排版，一鍵轉換教學＋工具分享
這就是一個非常典型的生活型應用：我自己在部落格發文後，常常還要再轉貼到 Facebook，但 Blogger 的格式跟 FB 的純文字格式差很多，所以我乾脆做了一個工具，讓自己可以快速把部落格文章整理成適合 Facebook 發佈的版本。
一路這樣回頭看，其實我慢慢越來越確定一件事：
AI 最有價值的地方，不是讓你一直問它問題，而是讓你把那些原本一直重複、一直消耗時間的小事，真正變成一個可以重複使用的系統。
而這次想做記帳資料一鍵匯入工具，只是把這條路再往前推進一步而已。
為什麼這次我不想再只靠雲端聊天機器人，而想改用本地端 AI coding 工具
如果你過去也曾經用過 ChatGPT、Gemini 網頁版，或者其他雲端聊天機器人來幫你寫程式，你應該會懂我接下來要說的這種感覺：
不是不能用，而是做到後面真的很累。
先說清楚，我完全不是要否定這類工具。
事實上，我過去很多次小工具的雛形、需求討論、邏輯梳理，最早都是先從這些雲端聊天工具開始的。因為它們很方便、很直覺，也很適合拿來做初步腦力激盪。你只要把問題丟上去，它就可以先陪你討論方向，甚至幫你寫出第一版程式。
但問題是，一旦你真的開始做專案，尤其是 Python 類型的本地小工具，事情通常就不會只有一個檔案這麼單純。
你會開始碰到：
不只一支主程式，還有其他模組檔案
套件安裝與環境設定 (甚至很多時候需要虛擬環境避免套件版本衝突)
讀取本地資料夾
執行後跳出的錯誤訊息
某個欄位顯示不對
某個資料格式沒有吃進去
修改一小段後，又牽動別的地方
到了這個階段，如果你還是完全靠雲端聊天機器人處理，你就會進入一種很熟悉的輪迴：
複製 → 貼上 → 截圖 → 上傳 → 解釋錯誤 → 等它回覆 → 再自己手動改 → 再執行 → 再截圖。
而且很多時候，AI 回你一段建議之後，你還是得自己把那段 code 複製到本地端、自己覆蓋檔案、自己測試。
如果只是改一兩行還好；但如果今天是跨好幾個檔案，或者它需要看你的整個專案結構、判斷哪個檔案該改、哪些地方要一起動，那這種來回搬運的成本就會非常高。
更麻煩的是，雲端聊天工具本質上並不是活在你的工作資料夾裡。
它只能看到你當下上傳給它的那一小塊資訊。你如果沒有重新上傳，它就不知道；你如果換了一個新對話，它通常也不會自動認得你之前那個專案的最新狀態。這種情況下，你就會很容易一直重複做同一件事：把已經講過、上傳過、修過的東西，再重講一次。
也就是說，它只能根據你提供的僅有片段資訊瞎子摸象，如果你提供的資訊不完整或根本不是核心問題，它可能就只能憑空亂猜試錯。
這不只浪費時間，也很浪費上下文的 token 和算力。
所以我後來越來越明確的感覺是：
ChatGPT 或 Gemini 網頁版，很適合拿來諮詢、發想、討論、問觀念。
但如果真的要把一個工具從無到有做出來，本地端的 agent 型工具，效率真的會差非常多。
因為本地端工具的最大優勢就在於：
它可以直接讀你的工作資料夾
可以直接看到專案裡有哪些檔案
可以直接修改
可以直接執行測試
出錯後也可以直接根據錯誤訊息繼續 debug
也就是說，你不再需要一直扮演「人肉搬運工」，把 code 跟錯誤訊息在雲端與本地之間來回搬來搬去。
這也是我這次真正想跨出去嘗試的原因：
如果現在已經有更適合做專案的 Vibe Coding 工具，那我就不想再一直停留在“用聊天機器人硬做專案”的階段。
為什麼是 Google Antigravity：我怎麼評估它跟其他工具的差別
這幾個月，其實市面上所謂的 Vibe Coding、Agent Coding、AI Coding 工具真的很多。
如果只是隨便看一輪，很容易眼花撩亂。
有些工具偏向傳統 IDE (Integrated Development Environment) 外掛延伸；
有些工具偏向命令列；
有些工具主打多模型切換；
有些工具則主打 agent 幫你直接規劃、修改、執行與驗證。
而我這次最後會優先選擇 Google Antigravity，老實說，不是因為它一定在所有場景都最強，而是因為它剛好最符合我這次這個專案的需求。
首先，Google 是把 Antigravity 當成一個新的 agent-first development platform 來推出的，而且是在 Gemini 3 發表時一起帶出來。Google 官方也明講，Gemini 3 已經可用在 Google AI Studio、Vertex AI、Gemini CLI 與 Google Antigravity；Antigravity 本身則是主打讓 agent 可以在更高層次的任務目標下，自主規劃、寫碼、測試與驗證。
再來，對我來說很重要的一點是：它目前是 public preview，而且個人版是免費的。
官方頁面列出的目前狀態，是 public preview、Individual plan 為 0 美元/月，而且主打可直接用 Google 帳號登入使用；官方公開頁面同時提到它支援 Gemini 3 Pro、Claude Sonnet 4.5 與 GPT-OSS，並提供 unlimited tab completions、unlimited command requests 與相對寬鬆的 rate limits。
但真正讓我心動的，還不是「免費」這件事本身。
而是它的使用邏輯，對我這種 不是工程背景、但想把事情做出來的人 來說，心理門檻低很多。
因為如果今天你把市面上的工具攤開來看，你會發現一個很大的分水嶺：
CLI 與 GUI，差很多
CLI，也就是 Command Line Interface，中文常講命令列介面。
它的操作方式比較像是你對著一個黑底視窗打指令，告訴系統你要做什麼。
優點是：
很快
很彈性
很適合熟悉開發流程的人
可以很自然地接在 shell、script、自動化流程裡面
但缺點也很明顯：
對一般人來說很有壓迫感
你如果不熟指令、環境、工作目錄、權限概念，很容易怕
出錯時也比較容易覺得「我是不是弄壞了什麼」
而 GUI，也就是 Graphical User Interface，圖形化使用者介面。
簡單講，就是你看得到面板、按鈕、欄位、檔案總管、對話框這些東西。
它比較像你平常在用一般桌面軟體。
優點是：
視覺化
容易理解
對第一次接觸的人比較友善
你比較容易知道自己現在在哪裡、正在看什麼、改了什麼
所以如果今天你本來就很熟 terminal，那像 Claude Code 這種 terminal-first 工具，當然會很有吸引力。Anthropic 的官方文件也很清楚：Claude Code 的起點就是在 terminal / command prompt 裡安裝、登入、進入專案目錄後使用，雖然它可以整合進 IDE，但核心仍然是終端機工作流。
可是對我來說，我這次要做的不是每天都在寫大型專案，也不是要追求最硬核、最高效率的 terminal workflow。
我比較在意的是：
我能不能快速打開就上手
我能不能用比較低壓力的方式看懂它在做什麼
我能不能把我的需求直接講給它聽，然後一步一步完成
我能不能在必要的時候，仍然保有確認與控制權
而在這個前提下，Antigravity 這種偏 GUI 的 agent 工具，對我來說就很合理。
它的邏輯不是要你先變成一個很會下指令的工程師，才有資格使用它；
它更像是把「agent 幫你處理本地專案」這件事，包進一個一般人比較有機會接受的桌面介面裡。
再加上它可以利用外掛套件中文化，這點其實對很多第一次接觸的人來說差很多。
因為很多時候，真正阻礙一般人的，不一定是技術本身，而是 陌生感。
只要把那層陌生感先拿掉，你就會發現它其實沒有想像中那麼可怕。
目前市面上比較有名的 Vibe Coding 工具，我怎麼看？
如果你是第一次接觸這類工具，我覺得最容易卡住的地方就是：
工具太多，不知道差在哪裡。
所以我這邊先整理一個我自己看下來，比較常被拿來討論、也比較有代表性的 Vibe Coding / Agent Coding 工具對照表。
這不是什麼絕對權威排名，而是我從「一般使用者實際要上手做東西」的角度，整理出來的一版。
常見 Vibe Coding 工具比較表
工具 個人入門價格 主要介面型態 模型 / 來源 常見用途 適合族群 我的觀察 Google Antigravity Public preview 免費 GUI 為主的 agent-first IDE Gemini 3 Pro、Claude Sonnet 4.5、GPT-OSS 本地專案開發、規劃、改檔、執行、驗證、瀏覽器測試 想做真正專案、但又不想一開始就陷入 CLI 壓力的人 我這次最終選它，最大的原因不是「最強」，而是對一般人最容易跨出第一步。 Cursor Free / Pro US$20 / Pro+ US$60 / Ultra US$200 GUI 編輯器為主，也有 CLI、Web、Mobile agent 可用 OpenAI、Claude、Gemini 等多模型 寫碼、重構、專案理解、背景 agent 協作 已經常寫程式、希望在熟悉 IDE 中大幅加速的人 功能很強，也很熱門，但介面與概念對初學者還是比較容易有壓力。 Claude Code Claude Pro 約 US$20/月起；Max US$100 / US$200；或 API 用量計費 CLI / Terminal 為主，可整合 IDE Claude 模型系統 終端機導向開發、專案巡覽、改檔、命令執行、除錯 熟悉 terminal、shell、開發流程的使用者 如果你本來就不怕命令列，它很俐落；但對一般人來說，第一眼門檻相對高。 Windsurf Free / Pro US$15 / Teams US$30 每人每月 GUI 編輯器為主 支援多家主流模型，並有自家 agent / credit 機制 AI editor、agent 協作、預覽、部署、日常開發 想要介面現代、功能完整、又不想太 CLI 的開發者 它也是很多人會拿來和 Cursor 比的熱門選項，定位很接近。 GitHub Copilot Free / Pro US$10 / Pro+ US$39 IDE + GitHub + CLI 多平台 可存取 Anthropic、Google、OpenAI 等模型 程式補全、agent mode、code review、issue 到 PR 流程 已經在 GitHub / VS Code 生態裡工作的人 優勢是整合 GitHub 生態很深；如果你本來就黏在 GitHub 裡，會很順。 Cline 工具本身免費；依 Provider / API 用量計費，也可 BYOK 或接本地模型 VS Code / JetBrains 擴充為主，也有 CLI Anthropic、OpenAI、Gemini、OpenRouter、Ollama、LM Studio 等 本地專案 agent 協作、跨檔修改、命令執行、模型彈性切換 想保有高度模型自由度、喜歡自己控管 API / 成本的人 彈性很高，也很適合進階玩家；但設定與選型相對需要多一點理解。 Roo Code VS Code Extension 免費 + inference；Cloud Free 為 US$0 + credits VS Code 擴充 / 本地 agent 為主 BYOM，可接 OpenAI、Anthropic、Gemini、local LLM 等 本地開發、雲端 agent、路由多模型、成本彈性管理 想走開源 / 本地化 / 高自訂彈性路線的人 很適合喜歡自己掌控模型與成本的人，但也比較偏進階玩家取向。
如果要用一句話講我自己的結論，那就是：
如果你本來就很熟寫程式、很熟 terminal： Claude Code、Cline 這類工具很有吸引力
如果你已經深度使用 VS Code / GitHub： Cursor、Windsurf、GitHub Copilot 都很值得考慮
如果你跟我一樣，比較在意上手門檻、視覺介面、本地資料夾操作、中文化與「先做出成果」： Antigravity 對一般人來說，真的會是一個比較容易開始的入口
給第一次接觸的人先釐清：Antigravity 到底是什麼？它危不危險？
我猜很多人看到這裡，第一個冒出來的問題不是「好不好用」，而是：
等一下，它可以讀我本地檔案？
那這樣會不會很危險？
這個擔心其實非常合理。
而且說真的，我一開始也有一樣的疑慮。
所以在我正式把它拿來做專案之前，我沒有一開始就直接衝。我反而是先花了一點時間，把它的基本邏輯、權限概念、工作模式先弄清楚，確認自己知道它在做什麼，我才開始真正把專案丟進去跑。
我自己的理解是：
Antigravity 可怕的地方不在於它很危險，而在於它很有行動力。
所以重點不是怕它，而是要知道怎麼正確地用它。
先講一個最重要的觀念：
1. 它不是無限權限亂跑，它看到的是你開給它的工作區
一般來說，你在 Antigravity 裡是以「專案資料夾」為單位開啟工作區。
也就是說，它的視野主要是綁定在你目前打開的那個 workspace，以及其底下的檔案與子資料夾。
這一點非常重要。
因為這代表它不是一打開就自動可以橫掃你整台電腦，而是你要先明確讓它進入哪一個專案，它才會在那個範圍裡工作。
所以我自己的做法，是一開始就先建立一個乾淨的專案資料夾，把需要測試的檔案副本放進去。
這樣就算真的有任何修改，也不會影響到原始資料。
2. Workspace 跟 Playground 不一樣
這點我自己覺得很值得在文章裡講清楚，因為它會直接影響很多人的安心程度。
Workspace：可以把它想成正式工作區。它綁定的是實體資料夾，所以 agent 在這個模式下，是真的會看到、讀取、修改那個專案裡面的檔案。
Playground：比較像沙盒、草稿區。你可以把一些小想法、小測試、無關緊要的腳本先丟進去試，這樣它就不會直接碰到你正式專案的檔案。
如果你只是剛開始摸索、還很怕，真的可以先從 Playground 開始。
這樣心理壓力會低很多。
3. Planning 模式跟 Fast 模式，差別其實就是「你想管多細」
這也是我覺得 Antigravity 對一般人比較友善的地方。
如果你選的是 Planning 模式，那它在真正動手做很多事之前，通常會先告訴你它打算做什麼，列出步驟、規劃與任務清單，很多操作也會先等你確認。
這很像你在帶一個做事很積極的助手，但你要求他每一步先報告、先核准再做。
如果你選的是 Fast 模式，那它就會更接近「你交代完，它就直接往下衝」。
速度當然比較快，但相對也比較適合你已經很熟流程、知道自己在做什麼的時候。
以我自己的個性，我第一次正式拿它來做這種會碰到資料庫、檔案、副本的專案時，我當然是偏向先用 Planning。
因為這樣比較安心，也比較容易理解整個過程。
4. 臨時腳本其實可以集中管理，也可以做完就清掉
這也是很多人一開始沒想到，但其實很好用的一點。
因為 agent 在完成任務的過程中，常常會自己臨時寫一些小腳本、測試檔、環境檔來輔助任務。
如果你沒有規範，它有可能就散落在專案裡不同地方。
但其實你可以直接在規則裡先講清楚，例如要求它把所有任務過程中臨時產生的腳本，統一放到像是 _TempScripts 這樣的資料夾。
這樣一來，整個工作區會乾淨很多；未來如果你確認這些東西不再需要，也可以統一刪掉。
我自己這次實際跑專案時，就是這樣做。
老實說，這種小細節真的很加分，因為它會讓你感覺不是在跟一個亂寫亂塞的 AI 合作，而是在管理一個相對有秩序的工作流程。
5. 真正的安全感，來自你知道它怎麼運作
所以回到一開始那個問題：Antigravity 危不危險？
我的答案是：
它不是不能有風險，但它不是那種你一打開就會失控亂刪檔的工具。
真正比較重要的是，你要不要先建立正確的使用習慣。
例如：
先用副本測試，不直接動原始檔
先開乾淨的專案資料夾
剛開始先用 Planning 模式
先從比較小的任務試起
臨時腳本集中放
必要時用 Playground 先測
任務完成後再決定哪些東西保留、哪些清掉
當你掌握了這些原則之後，你就會發現：
它其實沒有你想像中那麼可怕，反而是很有秩序、很有執行力的一個本地端助手。
而且對我來說，這也剛好是它跟純雲端聊天機器人最大的差別之一：
雲端聊天工具比較像顧問，告訴你「可以怎麼做」；
Antigravity 這類 agent 工具，比較像真的進到現場，幫你把事情做起來。
也正因為如此，它才值得我花時間認真研究，甚至真正拿來解決我這次記帳流程的問題。
正式進入專案：我這次想解決的記帳流程，到底長什麼樣子？
前面講了很多工具、觀念、介面、工作流，但如果要把這整件事講清楚，最重要的還是要先把問題本身具體化。
因為很多時候，我們以為自己是在學 AI、學 Vibe Coding、學寫小工具，但其實真正決定成敗的，從來都不是工具本身，而是：你有沒有把你要解決的問題講清楚。
我這次的需求，其實可以拆得很清楚。
第一個，是源頭資料
我的源頭資料，不是什麼很工整的 Excel，也不是什麼 API 回傳的 JSON。
它就是我平常在 Evernote 裡，隨手記下來的簡短純文字。
而且這個純文字，通常都很口語、很隨意，也不一定有固定格式。
例如我平常真的很可能會這樣寫：
2/14 ChatGPT 630 富邦銀行卡
2/16 理髮 200 現金
2/28 中餐 1309 富邦銀行卡
2/28 悠遊卡加值 500 現金
2/28 公司尾牙獎金 3000 現金
你看，這裡面有些是支出，有些是收入，有些是轉帳，有些甚至會有銀行名稱、信用卡名稱、中文英文混寫，格式都不完全一樣。
但對我自己來說，這種記法有一個很大的優點：
夠快。
我人在外面，突然有一筆開銷，我可以先快速記下來，不需要打開正式記帳軟體慢慢選欄位。這個階段，我要的是「先把資訊留下來」，不是當下就做完整分類。
第二個，是目標資料
我最終真正要寫進去的地方，是 MoneyAssistant 2.27 背後的 Access 資料庫，也就是 .mdb 檔。
這一點很重要。
因為我後來想通了一件事：我這次真正要處理的，並不是 MoneyAssistant 的視窗介面，而是它背後的資料本體。
換句話說，如果我能夠直接把正確資料寫進 .mdb 的資料庫副本裡，那麼 MoneyAssistant 之後只要再去讀這個資料庫，理論上就能正確顯示、正確分析。
所以這次的核心目標，不是做一個模擬鍵盤滑鼠、自動幫我在舊軟體視窗裡狂點選單的工具；
而是做一個更乾淨、更穩定的流程：
把我在 Evernote 裡的純文字，轉成可以安全寫入 MoneyAssistant 資料庫的結構化資料。
第三個，是中間那一大段最麻煩、也最值得自動化的流程
而這裡，才是整個專案真正的靈魂。
因為從「純文字」到「可寫入資料庫」，中間其實不是單純轉格式而已。
它至少要經過下面這幾個步驟：
1. 日期判斷
像我平常可能只寫 2/14、2/28，有些日期例如休假日可能根本沒開銷。
工具需要有能力把這些日期辨識出來，並且對應成正確的年月日。
2. 金額擷取
像 630、1309、+1,480、500元.... 這些寫法格式都不完全一樣。
(因為都是隨興依照當下直觀感覺口說或打字)
工具要能把真正的數字抓出來，而且最好能分辨這是支出、收入，還是轉帳。
3. 付款方式判斷
像是：
富邦銀行卡
付現金
中國信託銀行
悠遊卡
這些其實都在暗示「來源帳戶」或「付款工具」。
以前我都要自己一筆一筆從下拉選單找，這次我希望 AI 可以先幫我判斷一輪。
4. 目的帳戶 / 分類對應
這也是最麻煩的一步。
例如：
ChatGPT 訂閱費，到底要算哪一類？
理髮要放在哪一個支出分類？
停車費、餐費、加油、房貸、本息、水費，各自應該對到哪個帳戶或分類？
這些不是單純把字抄過去，而是要做「語意上的對應」。
5. mapping 記憶
我很清楚，很多分類規則其實是我的個人習慣，不一定是通用標準。
所以我從一開始就希望它不是每次都重新猜，而是能夠有一個 mapping.json 的本地記憶機制。
也就是說，如果我第一次告訴它：
ChatGPT → 某個數位工具 / 訂閱類分類
理髮 → 個人支出
停車 → 交通費
那未來它看到類似詞，就能優先沿用我自己的判斷邏輯。
這樣工具會越用越順，而不是每次都像第一次見面。
6. 預覽後再寫入資料庫
這點我也非常堅持。
因為這是財務資料，不是隨便可以亂寫的東西。
所以我的需求從一開始就不是「AI 自動無腦直接寫入」，而是：
先由 AI 幫我解析、對應、整理好，再在 GUI 介面裡讓我人工預覽確認，最後才安全寫入資料庫副本。
這樣就算有少數欄位抓錯，我也還有最後一道把關機制。
我覺得這才是真正適合日常使用的做法：
不是完全放飛 AI，而是讓它幫我處理 80% 最繁瑣的工作，最後 20% 關鍵確認，還是由我自己掌握。
講到這裡，你就會發現，這整個專案其實很像一條很清楚的資料流水線：
Evernote 純文字 → AI 解析 → 分類 / 帳戶對應 → mapping 記憶 → GUI 預覽 → 寫入 .mdb 副本
(而想清楚這個流程，其實才是 vibe coding 做自動化的關鍵重點，而不是程式碼本身)
一旦這個邏輯想清楚了，後面要讓 Antigravity 幫我把工具做出來，反而就沒有那麼抽象。
我怎麼開始做：先探勘資料庫，再讓 AI 幫我規劃實作
當我把需求想清楚之後，我其實沒有一開始就急著叫 AI 直接「幫我做出成品」。
因為我很清楚，這種事情如果一開始就跳過基礎調查，直接硬做，很容易後面一堆 bug，然後越修越亂。
所以我第一步做的事情，其實是：
先把 MoneyAssistant 的 .mdb 資料庫複製一份當測試檔，再讓 agent 去探勘它的資料表結構。
這一步非常重要，因為我不可能直接拿正式在用的原始資料庫去試。
所以我先把資料庫副本放進專案資料夾裡，讓後續所有測試都在副本上進行。這樣就算中間哪裡出錯，也不會傷到原始資料。
接下來，我才把任務交給 Antigravity，請它先幫我處理第一個技術關卡：
用 Pyodbc 去連線這個 .mdb 測試檔，印出所有資料表名稱，並且特別檢查哪些表可能跟帳戶、分類、交易紀錄有關。
也就是說，我這次不是先叫它幫我做漂亮 GUI，
而是先叫它像一個很認真的助理一樣，先去「摸清楚地形」。
這也是我覺得本地端 agent 很好用的地方：
你可以很自然地跟它說，「先不要急著做大功能，我們先偵查環境。」
而它也真的就是照這個邏輯往下做。
它先在專案底下幫我建立探勘用的臨時腳本，而且有依照我自己的規則，把這類臨時程式統一放在 _TempScripts 資料夾裡。像這次第一步就先出現了一支類似 explore_mdb.py 的腳本，專門拿來做資料表探勘。
然後接下來，它會一步一步：
安裝需要的套件
嘗試連線 Access 資料庫
印出 table 名稱
檢查欄位結構
回頭再根據結果幫我判斷，哪些表最可能跟帳戶、支出紀錄、分類有關
這整個過程，其實就很像你在帶一個新人做案子。
你不是一開始就叫他直接交成品，而是先讓他去做資料蒐集、環境確認、基礎盤點。
而我覺得 Antigravity 很加分的一點是，它在進一步開發之前，還會先自動產生兩份我覺得非常實用的 Markdown 文件：
1. implementation_plan.md
這個比較像實作架構計畫書。
它會把這個工具的整體系統怎麼拆、有哪些核心模組、資料怎麼流動、可能需要什麼環境與設定，都先整理成一份看得懂的規劃文件。
你不需要先懂所有 Python 細節。
你只要先看懂它的邏輯：
喔，原來這一層是 GUI，這一層是 AI parser，這一層是 category mapping，這一層是資料庫管理，最後再由主程式整合。
這樣其實就已經足夠讓你掌握全局。
2. task.md
這個則比較像開發任務清單。
它會把待辦項目一條一條列出來，做完的會打勾。
對我來說，這超級有感，因為它讓整個專案不再只是「AI 正在神祕地做些什麼」，而是你可以很清楚知道：
現在做到哪裡
還剩哪些步驟
哪些功能已經完成
哪些地方還在測試
我很喜歡這種感覺。
因為這代表即使你不是工程背景，你也不是站在旁邊看天書，而是真正知道整個專案是怎麼一步一步被做出來的。
而在資料庫探勘告一段落之後，後面的實作骨架也就開始慢慢長出來了。
例如像：
core/ai_parser.pycore/category_mapper.pycore/db_manager.pymain.py.envmapping.jsonGUI 相關模組與資料夾結構
也就是說，Antigravity 並不是一次吐給你一大包你看不懂的東西，
而是很像一個會自己規劃工作、逐步交付模組的開發助理。
這也是為什麼我會一直覺得，這類工具真正厲害的地方，不只是會寫 code，而是它把原本很零碎、很混亂的專案過程，變成一個一般人也看得懂、跟得上的流程。
我當時下的第一版 Prompt，大概長這樣
這邊我也順便把當時的核心指令整理一下。
(你也可以先跟 Gemini 討論你白話文的想法之後，由AI建議後在放入對話框)
我自己後來回頭看，會覺得這段 prompt 其實沒有什麼神奇魔法。
真正重要的地方，不是你用了多厲害的關鍵字，而是你有沒有把下面幾件事講清楚：
目標是什麼
資料來源是什麼
目標輸出是什麼
安全原則是什麼
第一階段要先做什麼，不要跳步
只要這幾件事講清楚，AI 通常就會比你想像中更能接住你的需求。
實作過程中，我真正感受到本地端 agent 好用的地方
如果要我用一句話總結這次做下來的感受，我會說：
本地端 agent 真正厲害的地方，不是它會寫程式，而是它讓你不用再一直當「人肉傳話筒」跟「人肉搬運工」。
以前如果我用雲端聊天機器人做這件事，大概會是這樣：
我先描述需求 → 它給我一段 code → 我自己複製到本地 → 執行 → 發現錯誤 → 截圖 → 再貼回去 → 它再改一版 → 我再覆蓋 → 再跑 → 又出新錯誤。
如果中間還牽涉到多個檔案、多個模組，那真的很容易做到後面很煩。
但這次用 Antigravity 的感覺就差很多。
因為它就在我的本地專案資料夾裡工作，所以遇到 bug 的時候，它不只是「口頭告訴我可能哪裡錯」，而是可以真的去看錯誤訊息、回頭改檔、再跑一次，然後繼續測。
這種感覺，真的很像你旁邊坐著一個會做事的助理。
你不需要每次都把事情重新解釋一次，也不需要把錯誤畫面搬來搬去。
很多時候，我其實不是在跟它討論 code 細節，而是在描述我的感覺。
例如：
這個欄位太窄了
這個下拉選單如果能更好選會更方便
這個 mapping 應該要能記住我上次選過的結果
這個解析出來的店家名稱可以抓得更完整嗎？
這個介面如果顏色柔和一點，閱讀會更舒服
也就是說，我在整個過程中扮演的角色，越來越不像一個要親手寫每一行 code 的工程師，
反而比較像是一個負責定義需求、確認方向、驗收結果的人。
換句話說：
我像主管，agent 像員工。
這種角色轉變，其實很重要。
因為它代表 Vibe Coding 最核心的改變，不是讓每個人都要變成資深工程師，而是讓更多人開始有能力把自己的需求真正落地。
Learning without applying is literally useless.
你如果只是一直看教學、一直看別人分享、一直收藏文章、一直研究工具名字，卻從來沒有真的拿一個自己的問題來做，那很多東西最後都只是「看過」，不會真的變成你的能力。
反過來說，哪怕你只是做一個很小很小的專案，
例如：
自己的記帳整理
檔名批次處理
會議逐字稿清理
Blogger 轉 FB 純文字
PDF 講義轉成逐頁投影片
只要那真的是你生活中會反覆遇到的問題，你就會在做的過程中學得非常快，而且印象非常深。
不要只是一直光看教學。真正有用的，是趕快開始做一個自己的小專案。
因為只有當你真的開始做，你才會知道：
你真正需要的是什麼
哪些流程值得自動化
哪些地方要保留人工確認
哪些工具適合你
哪些功能其實不用做那麼複雜
這些東西，不是光看影片、看文章、看別人的 code，就能完全學會的。
你一定要親手做過，才會真的變成你自己的東西。
而這次的 MoneyAssistant 記帳軟體自動匯入資料的工具，對我來說就是這樣的一個例子。
它不是什麼很華麗的大專案，
但它非常真實、非常個人，也非常有用。
而這種「真的能解決自己生活問題」的成就感，我覺得比單純學了多少語法還更有價值。
這個工具最後做到了什麼？實際成果與價值是什麼？
講了這麼多，最後最重要的還是要回到一個很實際的問題：
所以這個工具最後到底做到了什麼？
答案是，它真的成功把我原本那些散落在 Evernote 裡、口語化、格式不固定、平常只能靠我自己慢慢整理的記帳文字，轉成了一套可以全自動批次處理、可以預覽確認、最後再安全寫入 MoneyAssistant 資料庫副本的工作流程。
而且它不是只能吃那種很漂亮、很制式的輸入。
它處理的是我平常真的會寫的那種簡短筆記，像是：
2/14 ChatGPT 630 富邦銀行卡
2/16 理髮 200 現金
2/28 中餐 1309 Apple Pay
2/28 停車費 30 悠遊卡
也就是說，它面對的不是理想化資料，而是現實生活裡本來就會長得有點亂、有點口語、有時候還夾雜縮寫與個人習慣的原始文字。
而這個工具最後完成的，不只是單純「把字拆開」而已。
它實際上做到了幾件對我來說很有感的事：
第一，它可以一口氣吃進多筆資料，而不是一筆一筆慢慢處理
以前我如果累積一兩週沒整理，Evernote 裡很容易就是數十筆，甚至上百筆資料。
以前這些都要我一筆一筆自己看、自己判斷、自己輸。
現在則是可以把這批資料一次貼進去，讓工具先做第一輪整理。
這對我來說，光是心理負擔就差很多。
第二，它可以把口語化、格式不固定的文字，轉成較固定的結構
這件事很關鍵。
因為真正花時間的，不是把「630」搬到另一個欄位而已，而是要判斷：
這是日期還是明細的一部分？
這是支出還是收入？
付款方式是哪個帳戶？
這筆支出比較接近哪個分類？
有沒有需要保留原始明細文字？
而它現在可以先把這些欄位整理成比較像正式資料的樣子，讓整件事從「一堆人眼才看得懂的碎片」，變成「可供確認的結構化資料」。
第三，它不是直接暴衝寫入，而是先讓我預覽確認
這點我真的非常在意，也很慶幸當初有把這一點列進需求裡。
因為財務資料不是可以隨便讓 AI 愛怎麼寫就怎麼寫的東西。
真正適合長期使用的流程，一定是：
先幫我節省 80% 重複勞動，再把最後的 20% 關鍵確認權留給我。
所以這個工具的設計，不是完全黑箱式自動化。
而是先把解析結果呈現在 GUI 裡，讓我人工檢查一次。
如果哪一筆分類不太對、來源帳戶猜錯、明細想改得更精準，我都還可以在最後一步前修正。
這種感覺非常重要。
因為它不是剝奪控制權，而是把控制權放在更有效率的位置。
第四，它寫入的是 MDB 副本，而不是直接去動原始資料
這也是我很重視的安全設計。
因為只要流程是先寫到資料庫副本，再讓 MoneyAssistant 去讀取這個副本，那整個測試、驗證、調整的風險就會低很多。
這樣我就不會因為一次測試失敗，就把自己多年累積的資料搞壞。
第五，它有 mapping 記憶，所以會越用越順
這一點我覺得是整個工具從「一次性 demo」走向「真的能長期用」的關鍵。
因為我的分類方式、本地帳戶命名、信用卡簡稱、交易習慣，本來就很個人。
如果每次都要從零開始猜，那再聰明的 AI 也還是會有很多不穩定的地方。
但當它有了 mapping.json 這種本地記憶之後，很多我已經確認過的對應關係，未來就可以被保留下來。
也就是說，它不是每次都在重新猜我，而是會慢慢學會我的習慣。
這樣一來，後面每一次整理，理論上都會比前一次更快、更順、更少需要手動修。
而如果把這整件事拉高一點來看，我最在意的價值其實很單純：
我花一天，建立一個系統。
後面每一週、每一個月，我都在回收這一天的投資。
這才是我最有感的地方。
因為以前那種記帳整理時間，不是什麼驚天動地的大浪費，但它就是會反覆出現、默默吃掉你的時間與耐心。
現在我等於是用一次比較集中的投入，去換掉後面無數次零零碎碎的小消耗。
這種感覺，很值得。
從這次經驗，我對 AI 學習方式的真正想法
做到這裡，我其實最大的感觸，已經不只是「我又做出一個工具」而已。
我更強烈的想法是：
現在這個時代，我們學新技術的方法，真的已經跟以前不太一樣了。
以前如果你想學一個新東西，大家很自然會先想到：
去報名上課
找一套完整課程
從第一章開始按部就班學
先把基礎打完再說
這種方式當然不是錯。
但如果放在現在這個 AI 時代，我會越來越覺得，它不一定是最有效率、也不一定是最適合多數人的方式。
因為現在我們手上已經有一個非常強大的東西：
AI 本身就同時是老師，也是助手。
你不懂語法，它可以解釋給你聽。
你不懂資料流，它可以幫你一起拆。
你不懂怎麼規劃專案，它可以先列步驟給你看。
你不懂哪裡出錯，它甚至可以直接幫你 debug。
所以問題已經不再是「有沒有人可以教你」。
問題反而比較像是：
你有沒有一個真實的問題，值得你真的動手去做。
這也是我這次最深的體會之一。
我真的越來越相信，現在學新技術最好的方式，未必是先花很多時間把所有知識看完，而是先找到一個你生活中真正想解決的痛點，然後直接開始做。
那個專案不需要很大。
真的不用。
它可以只是：
想把會議逐字稿整理得更快
想把固定格式的檔名自動改好
想把部落格文章快速轉成 Facebook 可貼版本
想把記帳資料從純文字變成可匯入格式
想把某個很煩的重複動作自動化
只要那是你自己的真實問題，你在做的過程中就會非常有感。
因為你不是在學一個抽象知識，
你是在替自己的生活省時間、替自己的工作減少摩擦、替自己的流程建立系統。
而且做到這裡，我也更確定一件事：
真正難的，很多時候根本不是寫程式。
真正難的反而是：
1. 釐清需求
你到底要解決什麼問題？
你要的是快，還是準？
你要全自動，還是半自動？
你要讓 AI 做到哪裡，人又要保留哪裡的判斷權？
2. 把問題流程化
你得能把原本腦中那種很模糊的「這件事很麻煩」，拆成一個一個步驟。
例如我這次就是把它拆成：
純文字輸入
日期 / 金額 / 付款方式辨識
分類對應
mapping 記憶
GUI 預覽
資料庫寫入
當你拆不開、講不清楚，AI 也很難真的幫到你。
3. 做選擇與判斷
同樣一件事，往往有很多不同做法。
你可以選雲端，也可以選本地。
你可以選完全自動，也可以選半自動。
你可以選 CLI，也可以選 GUI。
你可以串 API，也可以先用免費額度。
你可以做最強版本，也可以先做夠用版本。
而這些選擇，只有你自己最知道什麼最適合你，AI無法幫你選擇。
所以我現在對 AI 的看法，越來越不是「它會不會取代人」，而是：
它會讓人類的角色重新聚焦。
聚焦到什麼？
聚焦到：
想清楚目標
做對判斷
拆清楚流程
給出明確方向
驗收真正有價值的結果
我們不一定要親手寫每一行 code，
但我們一定要知道自己想做出什麼。
這一點，我覺得反而比以前更重要。
思考：從《鋼鐵人》的賈維斯，到今天我們手上的 AI agent
做到這一步，我其實一直想到一個很有趣的畫面。
我開始認真記帳，大概也是在 2008 年左右。
而差不多也就是同一年，《鋼鐵人》第一集上映。
那時候電影裡的小勞勃道尼飾演 Tony Stark，坐在工作室裡，對著賈維斯下指令，一邊討論、一邊調整、一邊把腦中的概念變成真正可運作的東西。當年看那個畫面時，說真的，會覺得那就是科幻，就是電影，就是離現實很遠的想像。
沒想到，將近 20 年後，我們雖然沒有在地下室打造鋼鐵裝甲，
但我們真的已經開始在自己的電腦前，跟 AI agent 一起把腦中的想法慢慢做成工具、做成流程、做成結果。
當然，我們現在手上的工具，跟賈維斯還差得很遠。
它們還不完美，也不會永遠一次到位。
但那種「你描述需求，AI 幫你一起規劃、嘗試、修正、產出」的感覺，其實已經很接近了。
而這次做完這個記帳自動匯入工具後，我最大的感覺反而不是「哇，我好像學會了某個很厲害的技術」。
而是：
原來很多以前你以為只能忍受的生活痛點，現在真的有機會被你親手解掉。
這種感覺，我覺得很暢快。
因為你會開始發現，AI 最有價值的地方，不只是幫你回答問題，
而是幫你把原本那些一直存在、但你總覺得「算了啦，先將就一下」的小摩擦，慢慢變成可以優化、可以重複利用、可以持續節省時間的系統。
而這也讓我更相信一件事：
你現在不一定需要再先看很多很多教學，
也不一定要等自己「準備好了」才開始。
有時候真正最有效的學習，反而就是從一個很小、很真實、很個人的專案開始。
因為當你真的做出成果之後，
你學到的東西，才會真正變成你的。
Start before you’re ready. Don’t prepare, begin.
附錄：如果你也想試試看 Antigravity，這幾個觀念先記住就好
1. Planning / Fast 怎麼選？
我的建議很簡單：
第一次接觸、會碰到重要資料、怕出錯：選 Planning
已經很熟流程、只是做小任務或快速調整：再考慮 Fast
Planning 比較像「每一步先講清楚、你確認後再做」。
Fast 則比較像「交代完，它就直接往下跑」。
如果你本身比較謹慎，或者這次專案會碰到資料庫、原始檔、副本、環境安裝這些東西，我真的會建議先從 Planning 開始。
2. Workspace / Playground 怎麼分？
你可以把它這樣理解：
Workspace：正式工作區，真的會看到並操作你打開的專案資料夾
Playground：沙盒測試區，比較適合先試小腳本、小想法、小功能
如果你還不熟、只是想先玩一下，先從 Playground 開始會比較安心。
真的要進入正式專案，再切到 Workspace。
3. 我自己的 Antigravity 通用型規則 (system prompt)，大概會長什麼方向？
我自己後來會希望它平常優先扮演的是：
文書處理助理
專案整理助理
需要時才進入寫程式模式
也就是說，不是每次都一上來就寫一堆程式。
而是先閱讀、先整理、先理解需求；真的需要程式或腳本時，再開始動手。
- 平常優先以閱讀、整理、分析文件為主，不要每次都直接寫程式。
- 只有在明確需要自動化、資料處理、格式轉換或我明確要求時，才進入寫腳本模式。
- 涉及原始資料時，先建立副本再操作，不直接修改唯一原檔。
- 所有任務中臨時產生的腳本，盡量集中存放於指定資料夾，例如
_TempScripts。 - 處理複雜任務時，優先先提出 implementation plan 與 task checklist，再逐步執行。
- 若任務牽涉重要檔案或資料庫，優先使用較保守、可確認步驟的模式。
📌 您可能也會有興趣的其他文章:
- AI 語音轉文字格式太亂？獨創免安裝小工具『Remove Text Extra Spaces』幫你一鍵搞定！
- 讓多格講義 PDF 瞬間變身好閱讀的逐頁投影片！— 免安裝小工具『Split pdf handout to image slide』讓你無痛轉換！
- 《Video to PDF with Transcription：免網路、快速轉影片成投影片+語音轉文字的免費工具！》
- 打造數位分身：F5-TTS 本地部署教學與語音克隆應用分享
- PDF文件翻譯神器！PDFMathTranslate 用 AI 打造你的專屬PDF全文雙語翻譯工具
- 收到被拆成多個 PPT 的大型簡報檔怎麼辦？5 種快速合併 PowerPoint 的方法（附 VBA 一鍵整合教學）
- PPT 含隱藏投影片怎麼刪？4 種方法快速產生乾淨版簡報（含 VBA 一鍵清除教學）
- PPT 備忘稿怎麼刪？4 種方法快速清除 Notes（含 VBA 一鍵移除教學）
- PPT 註解怎麼刪？4 種方法快速清除 Comments（含 VBA 一鍵移除教學）
- Blogger 轉 FB 貼文神器：純文字也能有層級排版，一鍵轉換教學＋工具分享
似乎超級神奇（當過很多次搬運工的我感同身受）
回覆刪除