大家好，我建立了一套包含 15 個工作流程的工具包，涵蓋了 Shopify 商店營運中重複性高的一半工作，例如客服回覆、訂單通知、庫存不足警告、棄單挽回以及每日銷售報告。設計上的一個特殊限制，即使用者不寫表達式也不讀 JSON，塑造了整個開發過程。我將分享這個限制帶給我的教訓，因為大部分內容在官方文件中都找不到。

這套工具的技術堆疊包括 Shopify Trigger、Shopify 節點、HTTP Request、Slack、Gmail、SMTP、Schedule Trigger、Code、IF，以及用於 AI 步驟的 Basic LLM Chain 和 OpenAI Chat Model。

我刻意只使用原生節點，不使用社群節點，這樣可以確保在 n8n Cloud 和自架環境中行為一致。有五個關鍵點讓這些工作流程對非開發者來說更容易上手。

首先，每個工作流程只使用一個 CONFIG 節點。所有使用者可編輯的值，例如頻道名稱、閾值、商店名稱和語氣，都集中在一個名為「CONFIG - Edit Me First」的 Set 節點中，並附帶一個便利貼。這樣使用者永遠不需要接觸表達式。

其次，CONFIG 節點中不能包含機密資訊。這是一個硬性規定，API 金鑰只能儲存在 Credentials 中，絕不能放在會隨工作流程匯出的 Set 節點裡。

第三，Schedule Trigger 的設定不能來自 CONFIG 節點。事後看來這很明顯，因為觸發器在 CONFIG 執行之前就會啟動，所以「早上八點執行」這樣的設定必須直接在觸發器節點上編輯。我會明確地記錄這一點，而不是假裝它是可配置的。

第四，「總是輸出資料」的設定會改變你的計算方式。每日銷售報告即使在沒有訂單的日子也必須發送，因為沉默會讓人誤以為系統故障。將查詢設定為「總是輸出資料」可以解決這個問題，但預留項目會污染計數，導致零銷售日報告一個訂單而不是零，直到聚合步驟將其過濾掉。值得注意的是，這是一個節點層級的設定，而非參數。

第五，如果沒有固定第二個查詢，它會使資料量倍增。報告會比較昨天和前一天的銷售數據。如果第二個查詢沒有設定「Execute Once」，它會針對每個傳入項目執行，導致前一天的計數被昨天的訂單數乘以。這會產生無聲、看似合理卻錯誤的數字，是最糟糕的錯誤類型。

第六，訪客結帳會破壞天真的個人化設定。透過 POS 和 API 建立的訂單，其客戶物件的姓氏和名字欄位通常是空字串，因此僅僅檢查 null 值是不夠的，否則你會寄出「嗨 undefined undefined」的訊息。每個模板都需要一個防禦性的備用方案。我是在針對真實開發商店進行端到端測試時才發現這個問題的，在建構過程中從未出現。

還有一個是產品決策而非技術技巧：針對每個工作流程，決定「沉默」是否代表成功。例如，低庫存警報在沒有低庫存商品時保持靜默，而每日報告則總是發送。這兩種情況都是「沒有新聞」，但正確的行為卻是相反的。

我提供了四個免費的工作流程，包含 JSON 檔案和每個的設定指南，採用 MIT 授權，無需註冊，可在 GitHub 上取得。這些免費工作流程包括 AI 驅動的訂單通知、低庫存警報、棄單挽回和每日銷售報告。

這些免費工作流程是付費 15 個工作流程套件的一部分。免費的四個是完整的，並包含 AI 層級；付費套件則提供更廣泛的功能（額外 11 個工作流程）、PDF 指南和支援，而非殘缺的試用版。我很樂意回答任何關於建構過程的問題，特別是第三點和第四點中的聚合邊緣案例，這兩個問題各花了我一個晚上的時間。