建立 AI 自動化流程不應該需要理解 JSON schema、prompt 工程或 workflow DAG。使用者知道他們想要自動化什麼——他們應該能夠用簡單的文字描述它。
JieGou 的自然語言建立系統讓你輸入像是「摘要客服工單並標記緊急的」這樣的描述,就能得到一個可用的 recipe 或 workflow。但有趣的部分不是生成——而是生成之前發生的事。
先建議,只有在沒有符合時才生成
這是關鍵的設計決策。當你輸入描述並點擊建立時,系統不會立即呼叫 LLM 從頭生成新的 recipe。相反,它會先檢查 JieGou 的 132 個經過測試的範本庫。
如果找到強力符合(分數 > 0.6),會出現一個建議面板,顯示符合的範本和符合百分比標記。你可以立即採用經過測試的範本,或關閉它並繼續進行生成。
理念:JieGou 的 132 個經過測試的範本是一個護城河。每個範本都經過生成、使用合成輸入測試、LLM-as-judge 評估,以及人工審查。自然語言建立應該擴大這個護城河,而不是繞過它。
這意味著大多數使用者在幾秒內就能得到一個經過實戰測試的範本,而不是等待一個尚未驗證的新生成 recipe。
範本建議引擎
比對系統使用兩個階段。沒有向量 embedding——對於 132 個項目來說,快速關鍵字評分加上條件式 LLM 重新排序就足夠了。
階段 1:關鍵字評分
引擎計算使用者意圖 token 和範本中繼資料 token 之間類似 Jaccard 的重疊:
- 分詞會去除非字母數字字元、將所有字母轉為小寫,並移除 48 個常見停用詞
- 意圖涵蓋率(70% 權重)——使用者意圖 token 中有多少比例出現在範本中繼資料中
- 範本涵蓋率(30% 權重)——範本中繼資料 token 中有多少比例出現在使用者意圖中
- 部分 token 符合(子字串重疊)的分數是 0.5 而不是 1.0
部門加權:來自使用者目前啟用部門的範本會獲得 20% 的分數加成,上限為 1.0。如果你在銷售部門工作並描述與銷售相關的事物,銷售範本的排名會更高。
階段 2:LLM 重新排序
LLM 重新排序是條件式的——只有在滿足兩個條件時才會觸發:
- 最高關鍵字分數低於 0.8(高信心關鍵字符合不需要 LLM 驗證)
- 至少有 2 個候選範本的分數高於最小閾值
觸發時,前 10 個候選會被發送到 Claude Haiku 進行快速重新排序並產生結構化輸出。LLM 會看到使用者的意圖和每個候選的中繼資料,然後返回一個帶分數的重新排序列表。
如果 LLM 呼叫因任何原因失敗,系統會退回到僅使用關鍵字的排序。優雅降級——建議引擎永遠不會在 LLM 失敗時阻塞。
強力符合閾值:任何在兩個階段後分數高於 0.6 的範本都會觸發建議面板。
Recipe 建立精靈
Recipe 精靈會逐步完成 4 個步驟,範本比對會在步驟 1 和 2 之間攔截。
步驟 1:意圖
一個文字區域,你可以在其中描述 recipe 應該做什麼。六個範例意圖選項提供起點(「摘要文件」、「從電子郵件中提取關鍵資料」等)。如果你之前建立過 recipe,精靈會根據你之前的建立顯示帳戶歷史模式提示。
提交意圖後,範本建議引擎會執行。如果找到強力符合,會出現一個綠色建議面板,顯示範本名稱和符合百分比標記。你可以採用它(直接跳到預先建立、經過測試的 recipe)或關閉它並繼續生成。
步驟 2:草稿
如果沒有符合的範本——或者你關閉了建議——系統會將你的意圖發送給 LLM。草稿回應包括:
- Recipe 名稱和描述
- 建議的標籤
- Recipe 將執行什麼的純文字說明
- 2-3 個釐清問題,用於在完整生成前細化 recipe
模糊意圖偵測內建於此步驟。如果 LLM 判斷意圖過於模糊而無法產生有用的 recipe(例如「用資料做些什麼」),API 會返回 HTTP 422 並顯示友善訊息,要求你更具體。這從源頭防止低品質生成。
步驟 3:提案
你回答步驟 2 的釐清問題。答案使用選項風格選項——你可以點擊而不是輸入的預定義選項。這讓互動保持快速,並將輸出限制在明確定義的路徑上。
步驟 4:生成
系統產生完整的 recipe 規格:
- inputSchema——recipe 預期的型別欄位
- outputSchema——recipe 產生的結構化輸出
- promptTemplate——具有變數佔位符的完整 prompt
- sampleInput——你可以立即執行的真實測試資料
即時預覽會在你儲存前渲染 recipe。你可以檢視 prompt、使用範例輸入測試它,並在提交前迭代。
Workflow 建立精靈
Workflow 遵循相同的 4 步驟模式(意圖、草稿、提案、生成),但產生更豐富的輸出。
草稿差異
Workflow 草稿產生 2-10 個步驟,每個步驟分配 8 種步驟類型之一:
| 步驟類型 | 目的 |
|---|---|
recipe | 執行可重複使用的 prompt 範本 |
llm | 直接 LLM 呼叫,無需儲存的 recipe |
eval | 使用 LLM-as-judge 評估輸出品質 |
router | 根據輸入路由到不同分支 |
aggregator | 合併多個步驟的輸出 |
condition | 根據布林表達式分支執行 |
loop | 迭代集合 |
approval | 暫停等待人工審查後繼續 |
LLM 決定執行模式——循序或 DAG(有向無環圖)——並提供選擇的理由。簡單的管線獲得循序模式。具有可並行執行的獨立分支的 workflow 獲得 DAG 模式。
多代理模式提示
草稿 LLM 可以存取 4 個多代理模式提示,它可以在適當時應用:
- Critic-refiner——一個代理生成,另一個批評,第一個修訂
- Specialist-router——路由代理分派給特定領域的專家代理
- Debate-consensus——多個代理爭論立場,合成器提取共識
- Plan-execute-verify——規劃者分解任務,執行者執行每個部分,驗證者檢查結果
這些模式產生遵循既定多代理架構的 4-8 步驟 workflow。
「從 Recipe 建議」按鈕
如果你的帳戶中已經有 recipe,從 Recipe 建議按鈕會生成一個將你現有 recipe 串連在一起的 workflow。系統會檢查你的 recipe 庫,並提出一個以邏輯順序連接它們的 workflow——無需從頭描述 workflow。
兩階段儲存
Workflow 儲存使用兩階段流程:
- 階段 1——建立 workflow 引用的任何新 recipe。每個 recipe 都儲存到 Firestore 並分配一個真實的文件 ID。
- 階段 2——建立 workflow,將佔位符 recipe 引用對應到階段 1 的真實 ID。
這確保了參照完整性。Workflow 永遠不會指向不存在的 recipe。
部門上下文注入
Recipe 和 workflow 草稿都會解析部門上下文作為非阻塞側通道。當你在部門內工作時,系統會獲取:
- 部門套件的名稱和描述
- 部門入門套件中最多 15 個可用 recipe slug
- 與部門相關的建議整合
此上下文會注入到 LLM prompt 中,指示它優先重複使用經過測試的套件 recipe 作為 workflow 步驟,而不是從頭生成新的。銷售 workflow 草稿會引用銷售套件中現有的「潛在客戶豐富化」和「競爭對手分析」recipe,而不是建立重複的。
如果部門解析失敗(網路錯誤、缺少資料),生成會在沒有它的情況下繼續。不會硬性依賴上下文可用性。
關鍵技術決策
**不使用向量 embedding 進行範本比對。**對於 132 個範本,關鍵字評分加上條件式 LLM 重新排序既快速又準確,且不需要任何基礎設施。無需託管 embedding 模型、無需維護向量資料庫、無需擔心 embedding 漂移。如果範本庫成長到 1,000+,將重新審視此決策。
**透過 Zod schema 進行結構化 LLM 輸出。**建立管線中的每個 LLM 呼叫都使用 Zod schema 來驗證回應。草稿回應、釐清問題、recipe 規格、workflow 步驟定義——全部經過型別化和驗證。格式錯誤的 LLM 輸出會立即被捕獲,而不是在下游產生細微錯誤。
**模糊意圖偵測。**與其從模糊描述生成平庸的 recipe,系統會返回 422 並要求釐清。這是一個刻意的品質關卡。一個做「用資料做些什麼」的 recipe 對任何人都沒有幫助。
**條件式 LLM 重新排序。**當關鍵字引擎產生高信心符合(分數 >= 0.8)時,會完全跳過 LLM 重新排序步驟。這讓明顯符合的建議延遲保持低,同時為模糊情況保留 LLM 智慧。
**每層優雅降級。**LLM 重新排序失敗?退回到關鍵字排序。部門上下文失敗?在沒有它的情況下生成。範本比對找不到任何東西?繼續生成。沒有單一失敗點會阻塞建立流程。
可用性
自然語言 recipe 和 workflow 建立適用於所有方案——Free、Pro 和 Enterprise。探索所有功能或開始免費試用。