我們公司怎麼跑出 20+ AI 流程？系列第 5 篇：內部週報 dashboard 自動生成 SOP，4 個資料來源、3 條品質規則、2 個 human-in-the-loop 節點

週五下午五點半，老闆的 Slack 出現了：「週報什麼時候好？」

這個訊息，我們公司以前每週固定出現一次。一個人拉 GA4 截圖，一個人整理工單系統，另一個人手動從 GitHub 數 commit 數，最後拼到七點，PDF 傳過去，老闆看了三秒說「謝謝」。整個流程大約耗掉三個人共 4 小時，每週。

這半年，我們公司內部已經跑到 22 條 AI 自動化流程。週報 dashboard 自動生成是最新上線的第 22 條，也是我們這個系列要拆解的第 5 篇 SOP。前幾篇分別處理了報價自動化、排程治理、客服分流與寫稿自動化，這一篇我們要說的是：怎麼把週報整理時數從「人人都在拼」壓縮到只剩 2 個人工審核節點。

本系列已完成篇次：系列第 1 篇：內部報價自動化 SOP ／ 系列第 2 篇：排程治理 SOP ／ 系列第 3 篇：客服分流自動化 SOP ／ 系列第 4 篇：每日寫稿自動化 SOP ／ 系列第 4 篇：客戶意向與 CRM 同步 SOP。

為什麼老闆的週報永遠是「拼湊到週五晚上」

週報這件事，幾乎每家 10 人到 100 人規模的企業都在做，但幾乎每家都做得很累。原因很結構性：週報需要的數據通常分散在 4 到 8 個來源，沒有一個工具能一鍵拉齊。每個人負責自己熟悉的那一塊，最後再由一個人「整合」，這個整合動作本身就是週五最大的瓶頸。

更大的問題是「數字對不回去」。老闆看到週報說本週網站流量 +12%，但他打開 GA4 自己查，數字差了一截，因為報表用的是「工作階段」，GA4 看的是「使用者」。這種小誤差每週都在發生，最後每個人都對週報失去信任，週報淪為形式。

根據 Gartner 2024 年對中小企業資料治理的調查，超過 67% 的企業主管表示每週花在核對數據的時間超過 2 小時，而這些時間大部分用在確認「數字是否一致」而非分析趨勢本身。自動化週報的核心價值，就是把「核對」這個動作從人工程序變成系統保證。

我們公司踩過的經驗是：週報自動化最大的坑不在 LLM 怎麼寫摘要，而在資料源從一開始就沒對齊指標定義。流量是 session 還是 user？轉換是點擊 CTA 還是送出表單？這些定義沒有在最前面統一，LLM 後面再怎麼摘要都是垃圾進、垃圾出。

我們公司內部週報 dashboard 的 4 個資料來源

設計任何自動化流程，第一步永遠是把「資料從哪來」說清楚。我們的週報 dashboard 整合了 4 個來源，彼此之間的資料類型、更新頻率、存取方式都不同，這就是為什麼需要一套 SOP 而不是一個 API 串接腳本。

4 個來源分別是：

為什麼是這 4 個？因為它們分別對應公司每週最核心的 4 個維度：對外曝光（GA4）、業務數字（PG）、系統健康（N8N 日誌）、工程產出（GitHub）。少了任何一個，老闆看到的週報都是片面的。

技術上，GA4 的資料拉取是最麻煩的，因為 GA4 Data API 有每日配額限制，加上欄位命名邏輯跟 GA Universal 完全不同。我們用一個獨立的 N8N workflow 每週一早上 06:00 UTC 觸發，把上週的資料先快取到 Zeabur PG，後面的摘要流程直接讀 PG，不再重複打 GA4 API。

這個設計原則在我們的排程治理 SOP（系列第 2 篇）裡有完整說明：「每個外部 API 存取都要有本地快取層，不讓 LLM 直接打外部服務」。週報流程完全遵守這條規則。

GA4 Data API 的使用限制與最佳實踐，可以參考 Google 官方文件GA4 Data API 配額管理。我們的快取設計就是為了繞開這個限制，同時確保數字一致性。

LLM 分工設計：Claude Opus 拉數據、Sonnet 摘要、Haiku 排版

我們公司自己每天跑 20+ 個 AI 流程，技術棧是 Claude Code agent + n8n + Zeabur PG + N8N execution log webhook。週報流程的 LLM 分工設計，是基於三個月來踩坑累積出來的原則：用對的模型做對的事，不要讓貴的模型做便宜的事。

具體分工如下：

這套分工最重要的設計決定是：Opus 只做「判斷」，不做「生成」。我們把 Opus 的任務範圍嚴格限定在「這組數字是否異常」「資料源之間有沒有衝突」，輸出只有 JSON（正常/異常/需確認）。如果讓 Opus 也負責寫摘要，成本會是現在的 3 到 5 倍，但品質提升幅度根本感受不到。

Sonnet 的摘要 prompt 裡有一條硬規則：「每一個數字後面必須帶來源標記，格式為 [source:ga4_cache] 或 [source:pg_orders]」。這個標記在最終輸出時會被 Haiku 的排版 prompt 轉換成 tooltip，讓閱讀週報的人可以 hover 看到數字來源。

更多關於 AI Agent 框架選型的思考，可以參考我們整理的AI Agent 框架選型完整指南，其中關於 task decomposition 的部分跟這個分工設計思路一致。

3 條品質規則：來源 traceability、數字對得回原始表、沒把握就標「需人工確認」

自動化週報如果沒有品質規則，很快就會變成「沒有人信任但又沒有人停用」的殭屍系統。我們設計了 3 條明確的品質規則，每次生成週報時都會跑一遍檢查，不過才輸出。

品質規則一：來源 traceability

每一個數字都必須能追溯到原始資料表和查詢時間戳。我們在 Zeabur PG 裡建了一張 `report_audit_log` 表，記錄每次週報生成時每個數字的來源 SQL、執行時間、返回值。如果有人事後質疑「上週訂單數是怎麼算的」，直接查這張表，10 秒以內可以重現。

品質規則二：數字對得回原始表

Opus 模型在生成完摘要之後，還要跑一遍「交叉驗證」步驟：把摘要裡出現的每一個關鍵數字，跟原始 PG 查詢結果逐一比對。如果差異超過 0.5%（浮點數四捨五入誤差以外），就標記為異常，進入 human-in-the-loop 節點。這個步驟聽起來繁瑣，但上線後已經抓出 3 次因為時區換算錯誤導致的數字偏差。

品質規則三：沒把握就標「需人工確認」

這條規則的靈感來自我們在客服分流 SOP（系列第 3 篇）設計的「信心分數」機制。LLM 在輸出任何分析段落時，如果信心分數低於 0.75，或者涉及的資料點樣本數小於某個閾值，就在該段落後面加一個 `[需人工確認]` 標記，並附上信心分數和原因。這個機制讓週報閱讀者知道哪些部分是「系統有把握」，哪些部分需要自己再查一下。

這 3 條規則的共同邏輯是：自動化系統要比人工流程更誠實。手工整理週報的時候，人很容易因為時間壓力而「四捨五入」掉不確定性。自動化系統應該反過來，把不確定性明確標示出來，而不是隱藏掉。

關於 AI 系統的 traceability 設計，可以參考 MIT Technology Review 的報導企業 AI 透明度的核心挑戰，其中提到的「解釋性缺口」正是我們設計這 3 條規則想要解決的問題。

2 個 human-in-the-loop 節點：每週三數據冷檢、每週五文字終校

自動化不等於去人化。我們設計了 2 個 human-in-the-loop 節點，把人工介入的時機和範圍明確化，讓參與者知道「我在這個流程裡要做什麼」而不是「我要檢查所有東西」。

節點一：每週三 10:00 數據冷檢（30 分鐘）

週三早上，N8N 會把當週截至週二的數據摘要寄給指定的「數據負責人」（通常是專案經理或資深同事）。這份摘要只有數字，沒有分析文字，格式是標準表格。

負責人要做的事只有一件：確認有沒有「明顯不合理」的數字。不需要解釋為什麼，不需要提出建議，只需要在 Slack 裡回覆「ok」或者標記出可疑的欄位。如果有標記，系統會自動把該欄位的原始查詢 SQL 和資料抽樣發給負責人做二次確認。

這個節點的設計原則是「最小認知負擔」。我們踩過的坑是：一開始要求負責人「確認所有數字並簽名」，結果大家都草草看過沒有真正確認。縮窄到「只找明顯異常」之後，確認品質反而大幅提升。

節點二：每週五 14:00 文字終校（45 分鐘）

週五下午，Sonnet 生成的週報摘要文字會透過 N8N webhook 傳到一個簡單的內部校稿介面（我們用 Notion 頁面加上一個 N8N 觸發按鈕搭出來的）。文字負責人要做的事：讀一遍，確認摘要邏輯通順，修改措辭讓它聽起來像「人寫的」而不是「AI 生成的」。

修改完成後按下確認按鈕，N8N 把最終版本自動發送到老闆的 Slack 頻道、寫進 Notion 週報資料庫、同時存一份 PDF 到 Google Drive。整個流程從週五 14:00 確認到發送完成，通常不超過 5 分鐘。

原本這個流程需要 3 個人共 4 小時，現在壓縮成 2 個人各 30-45 分鐘。節省的不只是時數，更重要的是「週五下午人人焦慮趕週報」這個情緒成本消失了。

如果你想了解更完整的 AI 流程 POC 到落地方法論，可以參考我們寫的中小企業 AI PoC 30 天執行框架，裡面的 human-in-the-loop 設計原則跟本篇一致。

中小企業老闆想跟進怎麼做：4 個技術決策、3 個報價區間

這一段寫給的讀者是：公司有週報需求、對 AI 自動化有興趣、但不確定從哪裡切入的中小企業老闆或營運主管。

4 個技術決策

決策一：資料快取策略。如果你的週報資料來自 3 個以上的外部 API，建議先建一個本地資料庫快取層（Supabase 或 Zeabur PG 都可以），讓所有分析流程讀本地資料，不直接打外部 API。這個決策影響的不只是穩定性，還有成本：重複打 GA4 API 很快就會超配額。

決策二：LLM 任務拆分粒度。建議把「數據驗證」和「摘要生成」拆成兩個獨立 workflow，分別跑、分別紀錄 log。合在一起的 workflow 很難 debug，出問題的時候不知道是哪一步壞掉。

決策三：human-in-the-loop 節點的觸發條件。不要設計成「每次都要人工確認」，要設計成「只有異常才觸發」。具體來說，就是把品質規則寫成明確的數值條件（例如：數字差異超過 2%、某個欄位連續 3 週為 0），只有觸發條件成立時才推送確認請求。

決策四：輸出格式多元化。週報不一定只有一份。建議設計 3 個輸出版本：老闆版（1 頁摘要，重點數字）、主管版（3 頁含趨勢分析）、工程師版（完整原始數據 + 查詢 SQL）。N8N 的條件路由節點可以依照收件人身份自動切換版本。

3 個報價區間

報價範圍差距大的原因主要在：資料源的整合複雜度、是否需要自訂前端 dashboard、以及 human-in-the-loop 節點的介面開發工時。建議在詢價前先確認「你的週報資料目前存在哪裡、格式是什麼」，這個問題的答案會大幅影響報價方向。

想了解更多關於 N8N 和自動化工具選型的判斷邏輯，可以參考N8N vs Make vs Zapier 完整比較，對剛開始評估自動化工具的老闆很有參考價值。

我們怎麼看：週報自動化真正的槓桿在哪

如果你的公司目前的週報流程讓你覺得「這件事不應該這麼費力」，那大概率是可以自動化的。歡迎透過AI 顧問服務告訴我們你的狀況，我們會幫你評估資料源整合的複雜度和建議的起步方式。如果有更完整的系統開發需求，也可以直接看客製化網站 & 系統開發的服務說明。

常見問題