達人實戰 · 產品與營運
會計達人：哪些帳該讓 AI 先跑，哪些非你不可
月結對帳、費用稽核、財報產出，哪些機械勞動該讓 AI 先跑一輪，哪些非得靠人不可？這篇拆 4 個真實案例，看會計人怎麼用 Claude Code 做資料分析、串接 QuickBooks、蓋腳本自動化流水線，順便對照 Codex CLI 能不能做到一樣的事。
這行的痛點
會計每個月要重複做的機械工作份量驚人：銀行對帳單逐筆配對總帳、期末調整分錄要對到科目代碼、費用報告要按政策逐項稽核、財報排版要抓比較期間的變動。這些工作規則清楚、格式固定、但量大到吃掉真正需要判斷力的時間——像是差異歸因、政策灰色地帶認定、GAAP 判斷這種只有人能拍板的事。
這正是 CLI 型 AI 的甜蜜點：規則明確、可重複、需要留稽核軌跡的工作，Claude Code 能寫腳本跑、能留執行紀錄、能被 hook 攔下來檢查，比純聊天介面更適合放進正式流程。連 Anthropic 自家財務團隊都在用這套——官方部落格提到財務同仁把「查儀表板 → 取數 → 跑查詢 → 產出 Excel」寫成純文字工作流檔案，丟給 Claude Code 全自動跑，執行中缺什麼輸入它會主動問。
但這行也有 AI 最容易摔跤的地方：語言模型不會做算術，叫它「看著 Excel 心算」遲早出包。研究裡有個真實案例，某分析把「每封 email 帶來的營收」算成 $155.62，但真值只有 $0.14，分母算錯超過 1,100 倍，而且這份錯誤已經送到決策者手上——這也是這章會反覆強調「AI 起草、人類拍板」與「數字要來自跑過的程式碼」的原因。
動手前的準備
- 先看 Claude Code 教學第 1 章（安裝與登入），把終端機跟 CLI 裝好；如果要對照 Codex CLI，先看 Codex CLI 教學第 1 章。
- 準備一份真實但可以犯錯的小規模測試資料（例如某一季的匯出 CSV），不要一開始就拿正式帳本試手氣。
- 在專案根目錄建一份
CLAUDE.md，把科目代碼、公司內規、政策文件（差旅費用政策、折舊方法、殘值算法）寫進去或連結進references/——AI 查得到公開的 GAAP 準則，查不到你們公司的內規。 - 如果要接 QuickBooks、freee 這類雲端會計系統的 API 或 MCP server，先申請好 API 憑證，並且從「唯讀」權限開始測，穩定之後再考慮開放寫入。
- 心裡先接受一件事：任何會寫入正式帳本的操作，最終都要有人工覆核這一關，AI 只負責把草稿做到接近成品。
場景一：CSV 資料分析勾稽
情境很日常：手上有一批交易匯出檔要清理、跨檔勾稽、抓出對不上的項目，可能是客戶清單去重、Salesforce 匯出跟帳務系統勾稽，或是抓某個月份、某個區域的營收樞紐表。這類工作交給人工做沒問題，但慢，而且容易漏；直接丟給語言模型「幫我看這個檔案算一下」則會出事——上面提到的 $155.62 對 $0.14 的分母算錯案例，就是「叫 AI 心算」的活教材。
Claude Code 怎麼做
核心方法論只有一句話：讓 Claude 寫 Python／pandas 腳本並且真的執行，所有數字都來自跑出來的程式碼，不是模型自己算出來的。實際下指令時，習慣在每一步都要求它回報筆數，讓整條轉換鏈可以逐步勾稽：
去重：讀 customers.csv，以 email 去重，保留 signup_date 最新那筆，
寫到 customers_deduped.csv。告訴我起始幾筆、移除幾筆，
並秀出 5 筆被移除的例子。
跨檔勾稽：把 salesforce_export.csv 和 billing_export.csv 用 email join，
email 視為不分大小寫、先去頭尾空白再配對。存成 accounts_merged.csv，
另存一份配不上的清單。
樞紐：只留 2026 年註冊的，做各月 × 各區域營收樞紐，
存 revenue_pivot.csv，並印出過濾後筆數。發數字之前，建議照一套五步驗證協議走一輪：(1) 一開始就下「每個數字都要來自執行過的程式碼」這條護欄；(2) 每一步轉換都要回報筆數，讓鏈條能勾稽回去；(3) 手動抽驗至少一個彙總數字，回頭對一次原始資料；(4) 用常識判斷一下——這個數字合理嗎；(5) 大數字背後要留一份可以往下鑽的明細檔。原始匯出檔只讀不改，每次轉換都存新檔，不要讓 AI 用文字編輯的方式直接改 CSV（逗號數量算錯會靜默毀掉整份檔案）。
換成 Codex CLI
研究筆記裡目前找不到 Codex CLI 做這種 CSV 去重／跨檔勾稽案例的第一手報導——這部分目前查到的案例大多集中在 Claude Code 這邊。Codex 官方把自己定位在「複雜試算表與財務模型」，codex exec 一樣可以做非互動批次處理，理論上套用同一套「讓它寫程式、不要心算」的原則應該也能做到類似效果，但這屬於延伸自通用用法的推測，不是實測對照，實際要用之前建議自己先小規模驗證。
場景二：月結做成 Skill
情境是每個月都要重來一次的月結循環：銀行對帳、期末調整分錄、費用報告合規稽核、產出 GAAP 格式財報。Claude Code Playbooks Blog（2026-06-08）記錄了一套做法：把這四件事各自包成一個 Skill（一包預先寫好的指令集），需要時用固定的結構化指令叫出來跑。
Claude Code 怎麼做
四個 Skill 各自對應一段結構化 prompt（以下為原文中譯）：
對帳 Skill：
把 Q4 銀行對帳單與總帳對帳。逐筆配對交易、找出每一筆差異，並分類：
時間差、總帳漏記、金額不符、重複入帳、未兌現項目。
傳票 Skill：
準備 Q4 期末結帳傳票……每筆要有：正確借貸格式、對照我們會計科目表的
科目代碼、附上佐證計算、外加一份覆核清單。
費用稽核 Skill：
用我們的差旅費用政策稽核本季 340 份費用報告。逐項標出違規並按嚴重度
分級……另外標出連續出現超過 2 個月的重複扣款。
財報 Skill：
從試算表（trial balance）產出 Q4 財務報表……附期間比較……
任何科目變動超過 10% 要點名說明。每個 Skill 內建覆核清單、優先級標記、分類標籤，把會計師的時間從機械核對轉到例外處理與最終判斷。實測成效：1,200 筆交易的對帳從原本 2–3 天壓到單次跑完；340 份費用報告一次跑出按嚴重度排序、附金額曝險合計的違規清單；財報排版原本要花的 4 小時，被大幅壓縮。要注意的是，Skill 只處理機械層，差異歸因、政策灰色地帶、GAAP 判斷仍要人做最終認定，而且科目表、政策文件一定要先餵進 Skill 的 references/，不然 Claude 會用通用假設亂猜。
換成 Codex CLI
這段有實際的 Codex 對照案例，不是空推測：Nexairi 的財務從業者指南記錄了 Codex CLI 那邊的五大生產工作流，其中「差異驅動橋（variance bridge）」跟這裡的對帳 Skill 目標相同（全科目預算對實際勾稽、標出無佐證缺口）、「財務模型清理」跟費用稽核 Skill 一樣是抓異常抓違規、「CFO 報告包」跟財報 Skill 一樣，是產出可以直接拿去做決策的報表。差別在於 Codex 這邊沒有「Skill 資料夾」這種封裝，做法是用 codex exec 把固定流程做成非互動批次，規則寫進 /init 產生的 AGENTS.md（相當於 Claude Code 的 CLAUDE.md）。量化成效方面，Codex 這邊報的是一家中型公司「月度經營檢討（MBR）準備從 30 小時壓到不到 5 小時」，量級跟 Claude Code 這邊的月結案例相近。
場景三：接上 QuickBooks
這是一個具名的第一手案例：Alex Altman，科技公司財務人員，原本對「用 AI 寫程式」抱持懷疑態度，長期靠 Power Query 手工維護兩套 QuickBooks 帳本的合併損益表，做得很痛苦。
Claude Code 怎麼做
他的路徑分幾步：先因為 token 用量變大升級到 Claude Pro；用 Cowork（Claude 的瀏覽器代理）代填 Intuit 開發者的 production 存取申請表單——這張表單本身要填約 45 分鐘；拿到 API 憑證後直接貼進 Claude Code 終端機接通 QuickBooks API；在 Claude 引導下架了一個 Supabase 資料庫存放財務資料。他自己的原話描述當時怎麼下指令：
我一邊開著申請頁，一邊跟 Cowork 說：把這份申請填完。最後建成的自動化包括：同時接兩套 QuickBooks 的合併損益表、每日自動同步六萬多筆總帳交易、產品線別營收拆分、COGS 分類、部門別 OpEx，以及報表與 QuickBooks 之間的勾稽檢查（自動標出不符項）。他自己給的警告也很直接：「它會照你說的做」——一旦接上寫入權限，Claude 能大規模改動交易紀錄，任何寫入類的提案都要先人工覆核再放行。
換成 Codex CLI
研究筆記裡沒有找到 Codex CLI 串接 QuickBooks 的具名第一手案例。整體來看，Claude 這邊的會計 MCP 生態（QuickBooks、freee、Numeric 都有 MCP server）明顯比 Codex 那邊成熟；Codex 官方目前主打的重點放在試算表與財務模型本身，如果真的要做類似整合，大概只能自己套用 Codex 官方文件的 codex exec 批次模式與 AGENTS.md 規則檔去手動兜 API，沒有現成案例可以照抄。
場景四：腳本全自動化
一家服務大約 10 家客戶規模的日本會計顧問事務所，要把銀行 CSV 轉成會計軟體格式、驗證傳票、留稽核軌跡，同時控制 API 成本與資料外洩風險。AQUA テックブログ（2026-03-05）記錄了目前研究裡最完整的一套架構，核心思想是：Claude Code 不是「代做會計的工具」，是「蓋一台永久機器的平台」。
Claude Code 怎麼做
架構分幾層：專案根目錄的 CLAUDE.md 放事務所規則、科目代碼、傳票 pattern 對應邏輯、歷來錯誤修正紀錄；用幾輪對話讓 Claude 生成一支可重複執行的腳本，之後每月執行幾乎零 token：
產一支 Python 腳本，把瑞穗銀行 CSV（Shift-JIS→UTF-8）
轉成 freee 匯入格式，套用 CLAUDE.md 的傳票 pattern。再往上疊兩層機關：PreToolUse hook 當驗證閘門（例如 validate_journal.py 攔截寫檔動作，檢查借貸是否平衡、稅率是否一致），PostToolUse hook 觸發自動備份與 Git commit；接著用 cron 每天早上 6 點跑 daily_journal.sh，新的 CSV 進來就自動處理，寫日誌、發 Slack 通知，結果留給人工覆核。進階版本還可以叫 Claude Code 生成一個 TypeScript MCP server 接 freee／MoneyForward API，之後直接用自然語言下指令查試算表、比對去年同期。
10 家客戶事務所的實算成效：傳票輸入每家從 30 分鐘壓到 5 分鐘（每月省約 25 小時）、月報每家從 1 小時壓到 10 分鐘（每月省約 8 小時）、電子帳簿保存法的檔案整理從 5 小時壓到 0.5 小時、稅務查找從 8 小時壓到 3 小時，合計每月省下約 37.5 小時（以時薪日幣 3,000 元計，約合日幣 112,500 元／月）。要提醒的是資料量門檻：這篇作者的經驗是管道處理（cat file | claude -p）只適合原型測試、資料量在 100 筆以內才實用，正式環境要靠腳本法，可以處理到約 1 萬筆規模，再大就要分批。
換成 Codex CLI
這段目前找不到 Codex CLI 版本的「事務所級 hooks＋cron 全自動化」第一手案例，屬於研究缺口，不是實測對照。可以確定的是 Codex CLI 官方文件裡有對應的零件：codex exec 對應 Claude Code 的非互動批次模式、/init 產生的 AGENTS.md 對應 CLAUDE.md 規則檔、/permissions 對應沙箱寫入邊界控制。但 PreToolUse／PostToolUse 這種掛勾機制要怎麼跟 cron 排程整合，目前沒有查到 Codex 官方或社群的公開案例佐證，這部分只能算延伸類比，實際要做建議自己先抓小規模資料試水溫。
常踩的坑
AI 永遠不會做算術
語言模型心算數字會出錯，正式流程一定要靠「執行過的程式碼」產出數字，並且每一步轉換都回報筆數勾稽。研究裡的真實反例：某分析把「每封 email 帶來的營收」算成 $155.62，真值其實是 $0.14，分母錯了超過 1,100 倍，而且已經送到決策者手上（可信度：達人實測案例）。
把管道處理當正式方法
cat file | claude -p 這種寫法只適合原型測試，正式環境輸出會有微差、成本也會線性爆炸；資料量門檻大概是管道法 100 筆以內可用、腳本法可以撐到約 1 萬筆，再大要分批（可信度：日本會計事務所達人實測，來源 AQUA テックブログ）。
AI 對科目歸類、稅率、跨期攤提容易系統性誤判
像交際費跟會議費這種容易混淆的科目分類，hooks 可以靠關鍵字與門檻做部分攔截，但一定要留人工覆寫機制，不能完全信任自動分類（可信度：日本會計事務所達人實測）。
接上寫入權限之後要假設它會照你說的做
一旦 Claude Code 能直接寫入 QuickBooks 之類的正式帳本，任何會動到交易紀錄的操作都要先經過人工覆核才能放行，不能因為前面幾次跑對就放鬆稽核（可信度：第一手作者自述原話警告）。