自架記帳工具 ezBookkeeping，把帳本收進自己的樹莓派

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

記帳這件事，多數人交給手機上的雲端 App：條碼一刷、發票一存，帳就記好了，代價是每一筆消費紀錄都躺在別人的伺服器上。不想把帳本繼續放在別人伺服器上的人，開源圈其實有幾個選擇，其中把「輕」做得最徹底的一個是 ezBookkeeping。這個專案從 2020 年 10 月開源到現在，用 Go 寫成一個執行檔，MIT 授權，官方說明一句 Docker 指令就能把它架起來，丟在樹莓派或 NAS 上也跑得動。我實際登入它的官方示範站操作過：繁體中文介面完整，示範資料甚至是台灣情境，中國信託與玉山銀行的帳戶、新台幣計價的交易明細都在。先講結論：它給你的是一本完全放在自己機器上的帳本，功能扎實但要自己動手；它不做預算、不接銀行自動抓帳單，這兩條邊界決定了你該不該選它。

自架真正換到的：帳本位置與資源帳

換到的頭一樣東西很單純：資料的位置。官方常見問答寫得直接，所有使用者資料都存放在你自己部署的伺服器或個人電腦上。資料庫用 SQLite、MySQL 或 PostgreSQL 都行，SQLite 是單檔案資料庫，停機後複製檔案就是完整備份。跟著換到的是資源帳。這個專案對外的賣點就是輕：依官方比較頁自己在樹莓派 4 上測的數字（2026 年 1 月基準），Docker 映像檔 57.7 MiB、首次啟動約 1.36 秒、閒置記憶體約 25 MiB。這些是專案自家的測試結果，方向跟它的架構一致：一支 Go 執行檔加一個前端，沒有龐大的執行時環境。對照組很具體，同一頁列出 Firefly III 的映像檔是 795 MiB，足足十三倍大。

帳本放到網路上，門鎖就得自己管，這部分它的設計比想像中完整。兩步驟驗證（2FA）有了；應用程式鎖有了，PIN 碼或 WebAuthn 指紋晶片都行；登入有速率限制防爆破；API 權杖可以設 IP 白名單，只允許特定來源呼叫；外部登入走 OIDC，可以接 GitHub、Gitea 或 Nextcloud 當身分來源，家裡已有一套帳號體系的人不用再多記一組密碼。你把它架在區網內自用，這些是保險；你把它開到外部網路讓手機記帳，這些就是必要的門檻，而它都給了。

專案的體質也值得看一眼。到 2026 年 8 月中旬，GitHub 上累積 5,405 顆星、640 次 fork，最新版 v1.6.1 在 2026 年 7 月 20 日發布，repo 到 8 月 15 日還有推送，六年來維持穩定的版本節奏，2026 年 3 月到 7 月就走了 v1.4.0 到 v1.6.1 五個版本。Docker Hub 上的官方映像累積下載超過 66 萬次。不過貢獻結構要攤開看：第一作者 mayswind 一個人有 3,321 次 commit，第二名貢獻者只有 10 次。這是一個實質上由單人維護的專案，翻譯與小功能有社群參與，核心開發的公車因子是一。帳本是要用十年的資產，這一點該放進你的考量，而不是假裝看不見。

繁中介面能用嗎？我在官方示範站實際看到的

講自架工具很多人第一個擔心翻譯品質。這部分我實際驗證過：用官方示範站的示範帳號登入（帳號 demo，密碼 ezbookkeeping），介面偵測到瀏覽器語系後整站切換成繁體中文，時區自動抓 Asia/Taipei，不需要另外設定。

Pin

交易列表頁是標準的桌面版面：左側導覽列是統計與分析、交易列表、新增交易、帳戶、交易分類這些功能，主畫面從上而下的錢包總覽，示範資料裡有現金、中國信託、玉山銀行三個帳戶，各自顯示餘額，下面的交易明細逐筆列出日期、類別、描述與金額。統計頁同樣是繁中完整：總支出、總收入、結餘三張數字卡片，配上當月每日支出的長條圖與分類圓餅圖。

Pin

記錄本身的細緻度超出我對輕量工具的預期。交易時間精確到秒，這對記帳表面看似過頭，但對帳時就是排序依據；帳戶與分類都是兩層結構，支出底下再分餐飲、交通、住宿，示範資料裡的運費、住宿、早餐的分類就是這樣掛的。依官方功能頁與版本日誌，一筆交易可以附圖片（官方比較頁寫到最多九張）、記地理座標、掛標籤，定期支出像房租跟訂閱可以設排程自動入帳，常用交易能存成範本一鍵帶入，v1.5.0 之後統計探索器多了樹狀圖、日曆熱圖、年增率這些進階圖表。這些細節對照示範站呈現的介面完成度，宣稱與實際版面是一致的。

行動端沒有原生 App，這是官方明講的：它不提供獨立的桌面或行動應用程式，手機上靠瀏覽器加到主畫面，用 PWA 的方式跑成接近原生 App 的體驗。習慣原生 App 手感的人要先接受這條路。另外 v1.6.0 的更新日誌提醒，這一版改了 PWA 的頁面渲染方式，舊的 PWA 要先移除後重新加入，不然會有樣式問題，已經在用的人升級時會踩到。

AI 記帳會把帳本送出去嗎？

AI 記帳在這個工具不是新鮮事，收據圖片辨識自 v1.1.0 就有，2026 年 7 月的 v1.6.0 再補上從剪貼簿與文字檔萃取交易、批次圖片匯入，拍照記帳、貼一段帳單文字自動建交易都通。但這個工具對 AI 的處理方式，跟多數產品反著來：預設全部關閉。設定檔裡兩個開關，文字辨識與圖片辨識，預設值都是 false，你要用，得自己改設定檔並且填上模型服務的金鑰。這是自帶金鑰（BYOK）的設計：支援 OpenAI、Anthropic、OpenRouter、Google AI，也支援任何 OpenAI 或 Anthropic 相容的端點，接自家的代理或中繼都行。

更關鍵的是它留了一條不出門的路：接 Ollama 或 LM Studio 這類本機模型服務，金鑰不用填，收據照片與帳單文字就送到同一台機器上的模型處理，帳本與辨識都留在你的主機上處理。官方文件自己也寫了警語：使用第三方大型語言模型服務要謹慎，你的私密資料會被送到外部模型提供商。一個把警語寫在自己文件裡的專案，比把 AI 寫在行銷首頁的產品可信。圖片辨識有單張 10 MB 的上限預設值，收據照片夠用。

它同時把帳本開放給 AI agent 讀寫：內建 MCP 伺服器（Model Context Protocol，一種讓 AI 工具連接外部系統的開放協定），讓 AI 助手能查交易、記交易、查匯率，一樣預設關閉，並有 IP 白名單限制；也有現成的 agent skill，裝在 OpenClaw 這類個人 AI 助手上就能用自然語言記帳。想了解這條路的讀者可以參考我們先前寫過的 OpenClaw 部署指南。這整層 AI 能力的共同前提是：你的帳本在你自己的機器上，金鑰自己出，送哪個模型自己選。

順帶一提伺服器自己會打的對外連線，自架的人應該知道：匯率資料預設向歐洲央行抓，地圖圖磚可以設成由伺服器代理轉發，供應商有 OpenStreetMap、TomTom 或自訂來源，部分需要金鑰。官方常見問答也明講：專案本身不收集任何使用者資訊，自架伺服器不會把任何資料送往專案那端。要留意的是瀏覽器端的兩個例外，電子郵件會以 MD5 雜湊送往 Gravatar 抓大頭貼，地圖供應商會收到瀏覽器與位置資訊；伺服器側的對外連線就上面這幾條，在設定檔裡都看得到、關得掉。

跟 Firefly III、Actual Budget 比，該選哪一個？

自架記帳這個品類裡，常被一起討論的是 Firefly III 與 Actual Budget。官方比較頁（2026 年 1 月基準）給了一個好起點，關鍵欄位整理如下，數字皆是專案自行測試發布：

這張表其實就是選型答案。ezBookkeeping 的強項是資源足跡與部署簡單，一支執行檔、預設 SQLite，塞在樹莓派或 NAS 的角落裡跑，對本來就在自架各種小工具的人負擔很低；它的交易紀錄做到秒級精度、支援時區與多幣別，帳戶與分類都是兩層結構。Firefly III 走的是功能全開的路：預算、規則引擎、分割交易、銀行連線、34 種語言，代價是映像檔與維護複雜度都高一個量級。Actual Budget 則以信封預算法為核心，還有端對端加密與無伺服器模式，但它解的是「怎麼分配錢」，跟「怎麼記錄錢」是兩個問題。

誠實講，這個比較頁是 ezBookkeeping 作者自己整理的，立場免不了偏向自家產品，數字也未經第三方重測。但硬邊界不會騙人：ezBookkeeping 沒有預算功能、沒有銀行自動同步，這兩件事它到 v1.6.1 都沒做。你要的是一本乾淨的帳，選它；你要的是每個月告訴你錢該怎麼分配，選另外兩個之一。

舊帳搬得進來，門檻在哪？

搬家成本通常卡在舊資料。ezBookkeeping 支援的匯入格式相當廣：CSV、Excel、OFX、QFX、QIF、IIF、Camt.052、Camt.053、MT940 這些國際記帳格式，加上 GnuCash、Firefly III、Beancount、隨手記這些工具的直接匯入，還有支付寶、微信支付、京東金融的帳單檔。台灣這邊要留意：清單裡沒有台灣銀行業的專屬模板，玉山或 Richart 的 CSV 帳單要靠它提供的欄位對應（column mapping）功能手動對欄位，或者寫它支援的自訂腳本處理。有跨來源記帳的人（例如同時用支付寶與台灣帳戶）反而是它的甜蜜點。

出口這一側反而要留意：匯入格式一大串，匯出只有 CSV 與 TSV 兩種，而且以交易紀錄為主，帳戶與分類的結構沒有獨立的完整匯出檔。你的資料主權沒問題，SQLite 檔案就是完整的帳本，但想搬去別套工具時，中介格式會是平凡的 CSV，這是搬家前該知道的現實。

多幣別記帳的匯率從哪來？它內建 17 個匯率來源，16 國央行加歐洲央行，台灣央行不在清單上，但新台幣有加拿大央行與挪威央行兩個每日更新的來源可用，另外捷克與波蘭央行也報台幣，頻率是月更與週更。預設來源是歐洲央行，如果你主要的幣別是台幣與美元，把資料來源換成加拿大央行會比較實際。

部署本身是這個專案最不用擔心的部分。一條 docker run -p8080:8080 mayswind/ezbookkeeping 就起來了，預設 SQLite，瀏覽器開 8080 埠註冊第一個帳號就能用；不想用 Docker 也有 Linux、macOS、Windows 的二進位檔，甚至 Kubernetes 與 1Panel 的安裝指引。兩個升級提醒：v1.6.0 起伺服器只信任設定檔指定的代理伺服器送來的 IP 標頭，常見私有網段預設就在信任清單內，執行個體掛在公網網段反向代理後面的人才需要另外設定，否則登入限流會看到不對的來源 IP；v1.6.1 修了一個 Chromium v91 到 v147 瀏覽器的相容問題，用舊版 Edge 或舊核心瀏覽器的人務必升級。

誰該把帳本搬進來，誰不該

適合的人輪廓很清楚：本來就有 NAS、樹莓派或一台小 VPS，在意消費紀錄不要進別人家的雲端，願意花一個下午做初始設定，而且記帳的目的是留下紀錄與分析，不是做預算控制。這些人拿到的是一個六年成熟度、繁中完整、資源佔用極低的帳本系統，跟其他自架小工具一樣變成家用基礎設施的一部分。交易類的應用像 Quantdinger 這類自架量化交易工作台也可以跟它互補，一個管投資決策紀錄，一個管日常收支。

不適合的人也一樣明確：要每個月預算分配與超支提醒的，去用 Actual Budget 或 Firefly III，這個工具不做預算；要銀行帳單自動同步、一鍵對帳的，它同樣不做，手動匯入是它的常態；要原生 App 與雲端便利性、不願意自己備份資料庫的，市面上的雲端記帳 App 仍是省事的路。還有一種人該再想一下：把帳本放在單人維護的專案上，等於接受作者某天停更時你要自己接手的風險，六年活躍是事實，公車因子是一也是事實。

第一步的成本很低：先開官方示範站用 demo 帳號玩十分鐘，介面、統計、繁中程度自己驗收；真的滿意再照文件下一行 Docker 指令，用 SQLite 起一個本機執行個體，匯入一個月的舊 CSV 試試欄位對應。這兩步走完，它適不適合你，答案會比多數評測都清楚。