平行執行、迴圈步驟與條件判斷：真正重要的 Workflow 模式

只是將 recipe 線性串接的 workflow——步驟 1 傳遞給步驟 2 再傳遞給步驟 3——能處理許多使用場景。但真實的業務流程會分支、迴圈、同時執行多項任務、需要人工簽核,並與外部系統互動。JieGou 的八種步驟類型讓你能模擬這些模式。

Recipe 步驟:基本構建單元

Recipe 步驟執行單一 AI recipe,輸入經過映射並產生結構化輸出。這是任何 workflow 中的基本工作單元。

何時使用: 每當你需要 AI 執行任務時——提取資料、生成內容、分析輸入、分類項目。

關鍵設計選擇: 輸入映射。每個輸入欄位映射到一個來源:靜態值、workflow 層級的輸入、前一個步驟的輸出,或迴圈項目。映射 step_1.company_overview 表示「從步驟 1 的輸出中取得 company_overview 欄位」。這就是資料在步驟之間流動的方式。

提示: 使用最便宜且能產生可接受輸出的模型。不要在簡單的格式化步驟使用 Opus,因為 Haiku 就能處理得很好。

條件步驟:分支邏輯

條件步驟評估一個值與比較條件,並分支到 thenSteps 或 elseSteps。

提供八種運算子:equals、not_equals、contains、not_contains、greater_than、less_than、is_empty、is_not_empty。

何時使用:

• 將合格與不合格的潛在客戶導向不同路徑
• 根據嚴重程度以不同方式處理錯誤
• 當資料缺失時跳過步驟
• 在昂貴的步驟前加上品質檢查關卡

範例——發票處理:

步驟 1:提取發票資料
步驟 2:檢查差異
步驟 3:條件 (discrepancy_count > 0)
  Then:送交主管審批
  Else:自動歸檔發票

條件使用 greater_than 檢查 step_2.discrepancy_count 是否大於 0。不需要 AI 呼叫——這是純邏輯運算。

提示: 在提取步驟後使用條件來驗證 AI 是否確實找到你需要的資料。檢查關鍵欄位的 is_not_empty 可防止下游步驟在資料不完整時執行。

迴圈步驟:處理集合

迴圈步驟遍歷一個集合,對每個項目執行其巢狀的 loopSteps。集合來源是前一個步驟輸出的欄位——通常是陣列。

何時使用:

• 處理招聘批次中的每位候選人
• 分析發票中的每個項目
• 從內容計劃為每個頻道生成內容
• 審查合約中的每個條款

範例——批次候選人篩選:

步驟 1:解析候選人清單 → 輸出 candidates[]
步驟 2:迴圈遍歷 candidates
  步驟 2.1:篩選履歷(輸入映射到 loop_item)
  步驟 2.2:生成面試問題(如果合格)

每次迭代透過 loop_item 映射獲得當前項目。迴圈將所有迭代輸出聚合成單一結果。

提示: 保持迴圈主體精簡。如果你執行 50 次迭代,每次有 3 個 recipe 步驟,那就是 150 次 AI 呼叫。在迴圈內使用最便宜且有效的模型。

平行步驟:並發執行

平行步驟使用 Promise.allSettled() 同時執行多個分支。每個分支是獨立的步驟序列。所有分支同時開始;當所有分支完成(或失敗)時,平行步驟完成。

何時使用:

• 同時為多個頻道生成內容
• 執行彼此不依賴的獨立分析
• 同時處理多個資料來源
• 加速步驟之間沒有依賴關係的 workflow

範例——多頻道內容生成:

步驟 1:分析部落格文章
步驟 2:平行
  分支 A:生成 LinkedIn 貼文
  分支 B:生成 Twitter 串文
  分支 C:生成電子報內容
  分支 D:生成電子郵件行銷文案

分支 A 到 D 並發執行。每個分支在平行步驟開始時獲得輸出映射的快照——它們可以讀取前一個步驟的資料,但在執行期間看不到彼此的輸出。

關鍵行為: 如果分支 B 失敗,分支 A、C 和 D 繼續執行並正常完成。Promise.allSettled 意味著一個失敗不會終止其他分支。平行步驟後,你可以檢查哪些分支成功了。

提示: 平行步驟非常適合需要以多種方式處理相同輸入的情況。速度提升顯著——四個並發分支完成的時間與一個順序步驟大致相同。

審批步驟:人工檢查點

審批步驟暫停 workflow 並向審批者發送通知(通常是電子郵件)。只有當審批者採取行動時,workflow 才會繼續:批准、拒絕或提供輸入。

何時使用:

• 在發送面向客戶的內容之前
• 在執行金融交易之前
• 在 AI 生成的分析影響業務決策之後
• 任何需要人工判斷才能繼續的時間點

範例——內容發布流程:

步驟 1:生成部落格草稿
步驟 2:審批(內容經理審查)
步驟 3:從已批准的草稿生成社群媒體貼文
步驟 4:審批(行銷主管審查最終套件)

兩個審批關卡:一個在草稿生成後,一個在發布前。內容經理可能拒絕草稿並提供回饋,導致 workflow 停止。或者他們批准,workflow 繼續生成衍生內容。

限制: 審批步驟不能巢狀在迴圈或條件步驟內。它們在 workflow 的頂層或平行分支內運作。這是刻意的設計選擇——在迴圈迭代中途暫停會產生狀態管理複雜性,很少有使用場景能證明這種複雜性是合理的。

提示: 審批步驟可以包含可選的輸入 schema。當審批者需要提供資料時使用此功能——修訂註記、批准的預算金額、選定的選項——這些是下游步驟需要的。

寫入知識庫步驟:建立組織知識

寫入知識庫步驟捕獲前一個步驟的輸出並將其寫入知識庫文件。Workflow 立即繼續——這是一個即發即忘的寫入操作,不會阻塞執行。

何時使用:

• 儲存支援工單解決方案,以便未來執行可以透過 RAG 引用它們
• 建立不斷增長的已分析合約、會議摘要或研究簡報庫
• 建立 AI 生成輸出的可搜尋記錄,用於稽核或重複使用

範例——支援解決方案知識庫:

步驟 1:分類工單(recipe)
步驟 2:草擬解決方案(recipe)
步驟 3:審批(支援主管審查)
步驟 4:寫入知識庫(將解決方案儲存到「支援解決方案」知識庫)
步驟 5:向客戶發送回應(recipe)

解決方案獲批准後,會寫入知識庫。未來的分類執行可以透過 RAG 檢索類似的解決方案,使每個解決方案都比上一個更智慧。

提示: 將寫入知識庫步驟與自動情境知識庫配對。當知識庫連結到 recipe 或部門時,其文件會自動包含為未來執行的情境——無需手動連接。

交接步驟:人工通知但不阻塞

交接步驟向目標部門的使用者發送通知(電子郵件和應用程式內)。與審批步驟不同,交接不會暫停 workflow——它們提醒某人並繼續執行。

何時使用:

• 在不停止流程的情況下將問題上報給另一個團隊
• 通知部門工作已準備好供他們處理
• 提醒利害關係人 workflow 發現的事項

範例——事件檢測與工程交接:

步驟 1:分析錯誤日誌(recipe)
步驟 2:分類嚴重程度(recipe)
步驟 3:條件 (severity == "critical")
  Then:
    步驟 3a:交接給工程部(通知)
    步驟 3b:生成事件報告(recipe)
  Else:
    步驟 3c:記錄到監控儀表板(recipe)

交接立即通知工程團隊,但 workflow 不會等待他們回應——它在人工回應的同時繼續生成事件報告。

提示: 對「僅供參考」的通知使用交接,對「請決定」使用審批。如果下游步驟依賴人工判斷,使用審批。如果不依賴,交接能讓事情繼續進行。

瀏覽器操作步驟:與 Web 應用程式互動

瀏覽器操作步驟透過 JieGou 瀏覽器擴充功能執行 MCP 工具呼叫。它可以點擊按鈕、填寫表單、讀取頁面內容、擷取螢幕截圖,並與 Gmail、Slack、Jira 和其他 Web 應用程式中的平台特定功能互動。

何時使用:

• 根據 workflow 資料在內部工具中填寫表單
• 從沒有 API 的網頁讀取資料
• 為報告擷取儀表板的螢幕截圖
• 與只有 Web 介面的舊系統互動

範例——潛在客戶合格後更新 CRM:

步驟 1:研究潛在客戶(recipe)
步驟 2:合格潛在客戶(recipe)
步驟 3:瀏覽器操作(使用合格資料更新 Salesforce 記錄)
步驟 4:瀏覽器操作(在 HubSpot 聯絡人新增註記)

瀏覽器擴充功能在專用的自動化視窗中執行,因此不會干擾你的活動瀏覽器工作階段。範本參數將 workflow 資料映射到工具呼叫——{{step.step_2.qualification_score}} 成為填入 CRM 欄位的值。

提示: 瀏覽器操作步驟最適合最後一哩——將 AI 生成的資料推送到缺乏 API 存取的系統。對於具有 API 整合的系統(透過 MCP server,如 Salesforce、HubSpot、Jira),改用帶有 MCP 工具的 recipe 步驟,因為它們更快且更可靠。

組合模式

最有效的 workflow 結合多種步驟類型:

具有平行外展的潛在客戶處理:

步驟 1:研究潛在客戶(recipe)
步驟 2:合格潛在客戶(recipe)
步驟 3:條件 (qualification_score >= threshold)
  Then:
    步驟 3a:平行
      分支 A:草擬電子郵件(recipe)
      分支 B:草擬 LinkedIn 訊息(recipe)
    步驟 3b:銷售審查(審批)
  Else:
    步驟 3c:封存潛在客戶(recipe)

批次發票處理:

步驟 1:解析發票批次 → invoices[] (recipe)
步驟 2:迴圈遍歷 invoices
  步驟 2.1:提取資料(recipe)
  步驟 2.2:檢查差異(recipe)
  步驟 2.3:條件 (has discrepancies)
    Then:標記為待審查(recipe)
    Else:標記為無問題(recipe)
步驟 3:生成摘要報告(recipe)
步驟 4:財務經理審批(審批)

這些模式自然地組合,因為每種步驟類型都有清晰的語義:recipe 執行 AI 工作,條件分支,迴圈迭代,平行展開,審批暫停。

輸入映射是黏合劑

步驟類型是動詞。輸入映射是連接組織。每個 recipe 步驟的輸入映射到四個來源之一:

• static — 硬編碼值
• workflow_input — 來自 workflow 頂層輸入的值
• step_output — 來自前一個步驟輸出的欄位(例如 step_1.summary)
• loop_item — 迴圈迭代中的當前項目

正確設定輸入映射是 workflow 設計中最重要的部分。JieGou 包含按名稱和類型匹配欄位的自動映射,但手動審查和調整映射可確保資料正確流動。