TaxHacker 自架記帳：用 LLM 讀收據，先搞清楚它把資料丟去哪裡
Self-hosted AI accounting app. LLM analyzer for receipts, invoices, transactions with custom prompts and categories
秒懂
- 它是什麼？
- TaxHacker 是 MIT 授權的 TypeScript 自架記帳應用，把收據、發票、PDF 交給 LLM 抽取欄位後存成結構化資料庫，並附帶多幣別歷史匯率換算。它的價值取決於你願不願意接受一個前提：文件內容會離開你的機器。
- 適合誰用？
- 如果你是自己報稅的自由工作者或小型團隊，願意維護一個 Node 服務與資料庫，而且能接受把單據內容送進第三方 LLM API，TaxHacker 的欄位抽取與自訂 prompt 設計省下的手動輸入時間是實質的。反過來說，若你的單據涉及客戶保密條款、或你不想為模型品質波動負責，這個專案在 README 裡就明說了「results are not guaranteed」，那不是可以靠調設定解決的問題。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是輸入端，不是記帳本身
多數自架記帳工具的瓶頸不在分類，而在把紙本收據變成一筆可查詢的紀錄。TaxHacker 把力氣全放在這一段：上傳收據照片、發票 PDF，由 LLM 抽出日期、金額、商家、稅額與明細項目，寫進一個可以用篩選與全文檢索操作的資料庫。README 對目標族群的描述很明確，freelancers、indie-hackers 與 small businesses，也就是沒有專職會計、每年報稅前要自己翻箱倒櫃的那種規模。
要注意它並不是一套會計系統。README 沒有提到複式簿記、科目表、借貸平衡或財務報表產出。它產出的是交易清單與可匯出的 CSV，加上附件檔案，讓你把資料交給會計師或匯入其他工具。把它當成「單據數位化與初步歸類的前處理層」比當成帳務系統準確。這個定位差異決定了後面所有取捨：它不需要正確到分毫，但必須讓你事後能查核與修正。
LLM 抽取的資料流：從 unsorted 到結構化欄位
README 描述的工作流程分成兩段。文件先進入一個 unsorted 狀態，你可以選擇手動處理，或交給 AI 批次分析。分析時，系統把文件內容與你在設定裡的 prompt 一起送給 LLM，取回結構化結果後寫入資料庫。所謂「自訂欄位」就是這個機制的延伸：每個欄位可以掛自己的 prompt，等於在 Excel 上加一欄，只是填值的是模型。
真正影響準確率的設計在 prompt 的可控性。README 說連 system prompt 都能改，欄位與專案層級也能各自帶 prompt。這對產業特定單據有用，例如你需要從發票裡穩定抽出專案代號或統一編號，通用抽取規則常常抓不到，寫一條針對性的 prompt 成功率會好很多。代價是你得自己調，調不好就是欄位空白，而空白不會報錯。
另一條資料流是幣別。系統偵測文件上的幣別，再用交易日當天的歷史匯率換算成你的基準幣別，README 稱支援 170 多種法幣與 14 種加密貨幣。用交易日匯率而不是入帳日匯率，對報稅情境是合理的選擇，因為稅務認定通常看交易發生時點。
自架與模型選擇：同一個介面，兩種隱私結果
README 把模型選擇列為功能之一：OpenAI、Google Gemini、Mistral，或本地 LLM。本地路徑走的是 OpenAI-compatible API endpoint，點名可搭配 Ollama、LM Studio、vLLM、LocalAI。
這裡有個容易被行銷語言蓋掉的區別。自架解決的是資料存放位置，不必然解決資料傳輸路徑。如果你把 endpoint 指向雲端供應商，單據內容一樣會離開你的網路。README 自己的措辭是「Only you're responsible for the quality and privacy of your data」，這句話等於把責任完整交回使用者。想讓「自架」真的等於「資料不出門」，你必須把 endpoint 指向本地模型，而這又立刻撞上下一段的限制。
反過來，若你選本地模型，README 對結果的態度相當坦白：「Just make sure that your local model is good in OCR tasks, results are not guaranteed」。OCR 是這條 pipeline 最脆弱的一環，手寫收據、反光照片、低解析度掃描都會直接反映在抽取品質上，而這個品質差異不會有任何提示告訴你哪一筆抽錯了。
部署前要確認的設定與環境
README 沒有在提供的內容裡給出完整的安裝指令，只提到 self-hosted 版本與 docs/screenshots 目錄下的截圖，因此具體的安裝步驟、環境變數名稱與資料庫連線設定，必須回到 repository 的 docs 與 .env 範例確認，這篇不代為推測。能確定的是技術棧為 TypeScript，並需要一個持久化的資料庫來存放交易與附件。
從功能反推，部署時至少要處理三類設定：LLM 供應商與 API 金鑰（或本地 endpoint 位址）、基準幣別與匯率來源、以及檔案儲存位置。第三項常被忽略，但匯出功能聲稱會把附件文件一併打包，代表檔案不是存在資料庫欄位裡，而是落在檔案系統或物件儲存，備份策略必須涵蓋這一塊，否則資料庫備份還原後會出現有紀錄沒附件的狀態。
版本節奏值得納入評估。近期釋出為 v0.8.5（2026-07-20）、v0.8.2 與 v0.8.1（皆為 2026-07-07），兩週內三個版本，README 也自述「still in early development」。0.x 階段的資料庫 schema 變動是常態，升級前先確認 migration 路徑。
什麼情況下它會是錯的工具
第一種情況是單據量太少。整套系統的價值來自省下的人工輸入時間，如果你一年只有二、三十張收據，架設服務、設定模型、逐筆核對抽取結果的總成本很可能高於直接手動輸入。它適合的是單據量已經讓你不想開 Excel 的那個區間。
第二種情況是模型抽錯的後果很嚴重。LLM 抽取是機率性的，金額欄位可能把 1,250 讀成 1,250 也可能讀成 1250，看起來一樣，但小數點、幣別符號、負號都可能出錯。系統沒有在 README 中描述任何自動對帳或異常值偵測機制，也就是說錯誤會安靜地進到資料庫。若你的用途是正式帳務而非報稅前的整理，人工複核的比例不會因為用了 AI 而降低太多。
第三種情況是合規限制。若你的單據包含受保密協議約束的客戶資訊，或所在地區對財務資料出境有規範，把文件送進第三方 API 就是一個需要先解決的前提，不是可以事後補救的細節。本地模型能繞開這點，但同時接受 OCR 品質下降。
與純 OCR 工具及雲端記帳服務的差異
和 Tesseract 這類純 OCR 方案相比，差別在抽取的目標層級。OCR 給你文字，TaxHacker 給你欄位。文字轉欄位那一段通常才是真正花時間的地方，尤其是格式各異的發票，每家的欄位排列都不一樣，寫死規則的解析器很快就會失效。用 LLM 做這一段的好處是對版面變化的容忍度較高，代價是結果不確定，而且每次呼叫都有成本。
和雲端記帳服務相比，差別在資料控制權與可調整性。雲端服務通常幫你把模型調好、把類別定義好，你換來的是省事，失去的是 prompt 與欄位的控制權，也無法選擇本地模型。TaxHacker 把這些全部開放，包含 system prompt，代價是預設狀態下沒有任何人幫你調到好，README 的「100% adaptable and tunable」同時意味著「預設不一定適合你」。
如果你要的只是把 PDF 轉成可搜尋的文字，純 OCR 工具更輕。如果你要的是有人幫你處理好分類與報表，雲端服務更省事。TaxHacker 的位置在中間：願意自己調，換取欄位定義的自由與資料存放位置的選擇權。
維護成本與授權的實際邊界
維護成本主要來自三處。模型端，若用雲端 API，抽取成本隨單據量線性成長，且供應商定價與模型版本會變動，換模型可能連帶改變抽取品質，需要重新驗證 prompt。服務端，0.x 版本的升級需要留意 schema 變更，README 的早期開發聲明也提醒了這一點。資料端，附件檔案與資料庫要一起備份，匯出功能可以產生完整資料壓縮檔，這件事本身就適合當成定期備份手段。
授權是 MIT，這代表你可以自由使用、修改、再散布，包含商業用途，條件是保留著作權聲明與授權條款。但授權涵蓋的是程式碼，不涵蓋你送進 LLM 的單據內容，也不涵蓋你使用的模型供應商條款。把單據送到第三方 API 時，適用的規範是那家供應商的資料處理政策，不是 MIT。這一層需要你自己判斷，本文不提供法律意見。
最後一個具體的判斷點：TaxHacker 的 README 明確標示仍在早期開發、並要求使用者自行承擔風險。如果你的報稅流程不能承受工具在申報季出問題，那就先別把它放進關鍵路徑，而是先用一批歷史單據跑過一遍，比對抽取結果與你手上的原始資料，確認誤差範圍之後再決定要不要正式採用。
編輯結論
如果你是自己報稅的自由工作者或小型團隊，願意維護一個 Node 服務與資料庫，而且能接受把單據內容送進第三方 LLM API，TaxHacker 的欄位抽取與自訂 prompt 設計省下的手動輸入時間是實質的。反過來說，若你的單據涉及客戶保密條款、或你不想為模型品質波動負責，這個專案在 README 裡就明說了「results are not guaranteed」，那不是可以靠調設定解決的問題。採用前先確認三件事：你的部署環境能不能只連到本地模型的 OpenAI-compatible endpoint、你選的模型在自家單據上的 OCR 表現、以及升級時資料庫遷移的處理方式。授權是 MIT，但程式碼授權不涵蓋你送出去的單據內容，這一層得由你自己決定。
社群筆記