我將一個在 Make.com 課程中學到的情境在 n8n 中重建，並做了一項關鍵改變：模型絕不執行算術運算。這個流程會從客戶每週的廣告/銷售匯出資料中，為企業主生成一份簡短的月度報告，並檢查報告中沒有虛構的數字。
工作流程如下：首先從客戶表格（狀態為「待分析」）開始，然後循環處理每個客戶。它會讀取客戶的 CSV 匯出資料並進行彙總，接著透過程式碼節點計算各項指標。這些指標包括總計、首週至末週的變化、每次點擊成本（CPC）、轉換率、每潛在客戶成本（CPL）和預訂率；任何週環比增長超過 25% 的數據都會被標記為異常。
計算出的指標會被儲存起來。接著進行三次 LLM 處理：第一次，LLM 會從不同檔案/行銷活動中挑選出三個重要的異常，並連結其跨檔案的成因。第二次，LLM 會提出「如果沒有人採取行動」的後果，並建議一個在七天內驗證的行動。第三次，LLM 會為企業主生成一份淺顯易懂的報告。
最後，一個程式碼節點會進行事實查核：報告中的每個數字都必須存在於計算出的指標中，否則該行會被標記為「需要審閱」而非「準備就緒」。完成後，客戶會被標記為已處理。每一步驟的結果都會儲存到資料表中，確保即使 AI 呼叫失敗，也不會遺失先前的成果。
以虛構數據進行示範：對於一家牙醫診所，這個工作流程發現，在預約量下降 36.7% 的同一週，首次回覆時間從 2.4 小時增加到 9.8 小時。因此，它將「加快首次聯繫速度」列為第一項行動建議，且事實查核也順利通過。
我在實作中遇到了一些限制。事實查核僅驗證數字，不檢查措辭。報告仍可能將某項指標稱為「本月穩定」，卻忽略了某週的飆升，因此仍需要人工閱讀報告內容。
在 CPU 上使用本地 7B 模型（Ollama）雖然可行，但每次呼叫需要 4 到 13 分鐘，有一次甚至達到 15 分鐘的超時限制。因此，實際應用應使用 API 模型。下方的工作流程使用資料表而非 Airtable，本地資料夾而非 Dropbox，以及任何與 OpenAI 相容的模型。匯入後請替換掉您的 ID。我很樂意回答關於事實查核節點或指標程式碼的問題。
