建立 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。探索所有功能或开始免费试用。