前一篇談到，Cron 不是把指令放進時間表就結束，而是一份有輸入、處理、輸出與驗收標準的工作契約。今天用 ZoneTech 的財務日報來看，這個契約如何落地。

財務日報不是單純把幾個數字加起來

在公司營運中，最容易被低估的工作之一，就是每天回答「今天收了多少錢」「這個月累計多少」「距離目標還差多少」。看起來只是加總，實際上卻包含資料來源、付款狀態、重複紀錄、借款排除與報告交付等問題。

如果只讓 Agent 自由閱讀幾份表格，再要求它回答一個總額，結果可能每次都不一樣。問題未必是模型算錯，而是「什麼算收入」根本沒有被定義清楚。

我把財務日報當成一個每天自動交付的小型產品，而不是一段臨時 prompt。它固定在每天 10:00 與 17:00 執行，讀取指定的 Google Sheets 與 Gmail 資訊，依固定口徑整理當日收入、當月累計、目標達成率與差額，再交付到指定渠道。

先定義唯一收入口徑

目前財務資料的唯一收入口徑，是指定 Google 文件中的「完成區」。欄位規則固定如下：

日期：A 欄

收入：K 欄

處理狀態：Q 欄

只有 Q 欄是「已完成」，或包含實際完成日期並明確出現「匯」或「匯入」的紀錄，才列入收入。計算時直接加總 K 欄，不扣成本、不改算利潤，也不把預計匯款當成已收款。

這個規則看似保守，卻能避免管理報告把「預計會收到」誤報成「已經收到」。另外，華實顧問的入帳屬於借款，必須排除，不能因為銀行或表格中出現金額，就自動歸類為營收。

這裡最重要的不是欄位名稱，而是每個判斷都能被追溯。日後如果有人問「為什麼這筆沒有算進去」，可以回到日期、金額與處理狀態，而不是重新請模型猜一次。

七份資料來源不等於七種自由解讀

財務日報會整合多份 Google Sheets，分別涵蓋收入、支出、花費與相關營運資料。資料來源越多，越不能把判斷責任全部交給模型。

流程先把資料讀回本機，再進行欄位整理與去重。每份來源都要保留名稱、讀取時間與資料筆數。若其中一份讀不到，應標記資料不完整並停止產出正式結論，而不是拿前一天的快取補上去。

模型可以協助辨識欄位、整理例外與產生繁中報告，但核心計算規則應該由程式或明確的資料處理邏輯執行。模型適合做歸納，不適合在沒有規則的情況下自行決定哪一筆算收入。

報告固定回答四個問題

每天的財務報告不追求把所有原始資料貼出來，而是固定回答管理上最需要的四件事：

今日收入：依完成區口徑，計算當日實際完成的收入。

當月累計：從當月第一天起，累加符合規則的已完成收入。

目標達成率：以 2,000,000 元作為當月目標，計算目前累計占比。

目標差額：目標金額扣除當月已完成收入，顯示還需要多少金額。

固定格式的好處，是可以快速比較每天的變化，也能讓異常更容易被看見。若今天的數字突然變成零，系統應該進一步檢查是確實沒有入帳，還是資料來源失敗，而不是只把零當成正常結果。

實際踩雷：有資料不代表資料可用

財務自動化最危險的錯誤，不一定是明顯的程式例外。有一次資料來源雖然成功回傳，但內容不完整；如果流程只檢查 API 是否回應 200，就可能產生一份格式正常、數字卻不完整的報告。

因此現在的驗證不只看程序 exit code，還要檢查：

來源是否全部讀取成功。

每份資料的筆數是否落在合理範圍。

必要欄位是否存在。

金額欄位是否能轉成數字。

同一筆交易是否被重複計算。

狀態欄位是否真的符合收入口徑。

若檢查失敗，報告應該明確標示阻塞原因，並保留原始輸入與錯誤紀錄。寧可晚一點交付一份「資料不完整」的通知，也不要準時交付一份看似精準的錯誤總額。

認證與交付也是產品的一部分

Google 服務的認證不能被當成永遠有效。正式工作前，先測試公司帳號能否讀取必要的 Sheets 與 Gmail；認證失效時，依既定流程修復並重新測試，仍失敗就停止後續分析。

公司資料固定使用公司帳號 gask.huang@zonetech.tw。個人帳號即使看起來也能登入 Google，並不代表它有正確的公司資料權限。曾經遇到的 403，正是因為帳號邊界沒有被當成流程的一部分。

報告寫入本機檔案，也不等於財務團隊已經收到。若流程還要傳到 Telegram 或其他平台，必須把交付列為另一個驗收階段：確認目標對象、確認送出結果，再讀回實際訊息。只有看到外部結果，才算完成。

每天兩次的執行契約

目前這個財務日報 job 的執行順序可以簡化成以下流程：

1. 執行認證 preflight，確認公司 Google 服務可讀取。
2. 讀取指定的七份資料來源與必要的 Gmail 資訊。
3. 驗證來源筆數、欄位與資料新鮮度。
4. 依「完成區」規則篩選已完成收入，排除借款、預計款與不完整紀錄。
5. 計算今日收入、當月累計、2,000,000 元目標達成率與差額。
6. 產生固定格式的繁中報告，保存到 Vault 的 reports 目錄。
7. 送到指定渠道，讀回外部結果並記錄驗證證據。

這個順序的價值，在於每一步都有停止條件。某一份 Sheet 讀不到時，不會直接跳到第 5 步；外部交付沒有讀回證據時，也不會因為腳本結束就把狀態標成成功。

今天的驗證

本篇的完成標準不是「寫了一個每天跑兩次的排程」，而是確認整條交付鏈：

本機：報告依固定規則產生，並保存於 Vault 的 reports 目錄。

資料：收入只採用完成區中符合狀態規則的紀錄，借款與預計匯款不列入。

服務：job 固定在每天 10:00 與 17:00 執行，並在正式工作前做認證與來源檢查。

外部：送出後讀回指定平台的實際訊息，確認對象、內容與時間。

如果只有本機檔案，沒有資料來源證據或外部交付證據，正確狀態仍然是部分完成，不能把它包裝成完整的財務產品。

結語

財務日報讓我更清楚看到，AI 自動化的難點通常不是把數字加起來，而是建立一套不容易被誤解的資料契約。收入定義、資料權限、例外處理、交付驗證，任何一項模糊，都可能讓報告在形式上成功、在決策上失真。

當規則被固定下來後，模型才有適合的位置：協助整理多來源資訊、說明異常與產生可讀報告；而關鍵計算與驗收，則交給明確且可重跑的流程。

下一篇會談社群雷達，看看如何把每週人工巡一圈 X、Reddit、Facebook 與其他社群來源，變成每天有健康檢查、去重與防幻覺規則的自動報告。