generating-flow

目标

运行必需的 3 步 MCP 流水线（fetchGroundedObjectMetadata → flowElementSelection → flowElementGeneration），生成 Salesforce Flow 元数据并返回 Flow XML。

何时使用此技能

在需要以下操作时使用此技能：

• 创建任何类型的 Flow（Screen、Autolaunched、Record-Triggered、Scheduled）
• 生成 Flow 元数据 XML
• 无需编写代码即可自动化业务流程
• 构建由用户引导的工作流或后台自动化
• 排查与 Flow 相关的部署错误

规范

Flow 元数据规范

概述

Salesforce Flow 是功能强大的自动化工具，可在无需编写代码的情况下实现复杂的业务流程自动化。Flow 可以通过交互式屏幕收集和处理数据、执行逻辑和计算、操作记录、调用外部服务，并根据各种事件触发。Flow 类型包括 Screen Flow（由用户引导）、Autolaunched Flow（后台处理）、Record-Triggered Flow（数据库事件）和 Scheduled Flow（基于时间）。

用途

• 通过声明式逻辑和分支自动化复杂的业务流程
• 通过 Screen Flow 引导用户完成多步骤的数据收集和决策工作流
• 自动对 Salesforce 记录执行 CRUD 操作
• 通过 Autolaunched Flow 执行后台处理和集成
• 通过 Record-Triggered Flow 实时响应记录变更
• 通过 Scheduled Flow 安排重复任务和批处理操作
• 创建可复用、易维护的自动化，让管理员无需编写代码即可修改

Flow 生成流水线

强制要求：必须严格遵循以下 3 步流水线。不得例外，不得走捷径，不得跳过步骤。不得手动创建 Flow 元数据 XML，也不得尝试在此流水线之外生成 Flow 元数据。不得尝试使用任何其他工具、API 或方法生成 Flow 元数据。此流水线是生成 Flow 的唯一受支持方式。任何偏离都会导致元数据无效或损坏。

MCP 连接详情

所有 3 个流水线步骤都必须通过此 MCP 工具调用：

• MCP 工具名称： execute_metadata_action
• action 参数用于选择要运行的流水线步骤："fetchGroundedObjectMetadata"、"flowElementSelection" 或 "flowElementGeneration"

Flow 生成是一个严格的 3 步流水线。必须按顺序调用所有步骤。每个步骤都是必需的。没有其他可行方式——这是生成 Flow 元数据的唯一方法：

步骤 1（必需）：获取基于实际环境的对象元数据（fetchGroundedObjectMetadata）

获取与 Flow 生成请求相关的组织架构元数据。此步骤必不可少，且必须始终作为第一步调用。

输入（均为必需）：

• userPrompt（STRING，必需）：用户的自然语言请求
• inflightMetadata（ARRAY，必需）：本地 sfdx 项目中的自定义对象/字段。如果不需要，使用空数组 []。

输出：

• groundingMetadata（STRING）：与请求相关的组织架构元数据，以 JSON 字符串形式返回。必须将其直接传递给步骤 2——它已经是字符串，无需再次序列化。

步骤 2（必需）：Flow 元素选择（flowElementSelection）

根据用户提示和基于实际环境的元数据，选择 Flow 元素（赋值、决策、记录操作等）及其连接。此步骤必不可少，且必须在步骤 1 之后调用。

输入（均为必需）：

• userPrompt（STRING，必需）：用户的自然语言请求（必须与步骤 1 中的值相同）
• groundingMetadata（STRING，必需）：组织架构元数据（必须与步骤 1 输出中返回的字符串完全相同——直接传递，不要再次序列化）
• operationId（STRING，必需）：操作 ID（首次调用时使用空字符串 ""）

输出：

• operationId（STRING）：操作 ID。必须将其传递给步骤 3。
• userOutput（STRING）：后续步骤的推理过程。可以向用户展示。

Step 3（必需）：流元素生成（flowElementGeneration）

逐个生成流元数据元素。此步骤必须执行，并且必须在 Step 2 之后调用。必须循环重复调用，直到 isComplete 为 true。

输入（均为必需）：

• operationId（STRING，必需）：来自 Step 2 输出的操作 ID
• requestSource（STRING，必需）：请求来源。使用 "A4V" 获取 XML 格式的流元数据。

输出：

• isComplete（BOOLEAN）：指示流生成是否已完成。必须检查此值。
• result（STRING）：流元素生成的结果。仅当 isComplete 为 true 时，才包含最终流元数据。

必需：循环直到完成。绝不要暂停或询问用户是否继续。

• 流可以包含任意数量的元素（10 个、15 个或更多）。每次调用只生成一个元素，因此可能需要进行多次迭代。这是预期且正常的。
• 使用 Step 2 中的 operationId 和 requestSource 调用 flowElementGeneration（XML 输出使用 "A4V"，JSON 输出使用空字符串或其他值）。
• 每次调用后检查 isComplete 输出和 result 字段。
• 如果 isComplete 为 false 且未返回错误，则必须使用 Step 2 中的同一个 operationId 再次调用 flowElementGeneration。不要询问用户是否要继续。不要暂停。不要在循环过程中总结进度。只需继续调用。
• 除非 isComplete 为 true 或可调用操作返回错误，否则不要停止。迭代次数没有上限——无论需要调用多少次，都要继续。
• 当 isComplete 为 true 时，从 result 字段提取流元数据。
• 如果返回错误，则停止循环并向用户显示错误。

严格约束（关键）——这些规则适用于生成管道返回的 XML：

• 不要修改任何块内部的内容、值或子节点。
• 不要添加新节点、标签、属性或文本（不要添加缺失的标签、X/Y 坐标等）。
• 不要删除任何现有节点。

inflightMetadata 格式

数据类型：数组（不是字符串）

严格命名约定——必须完全遵守：

属性	正确名称	不要使用
对象 API 名称	apiName	objectApiName、name、objectName
字段 API 名称	apiName	fieldApiName、name、fieldName
字段类型	type	fieldType、dataType
查找目标	referenceTo	relatedTo、lookupTo、reference

需要自定义对象时（显示多种字段数据类型的示例格式）：

[
  {
    "type": "CustomObject",
    "apiName": "CustomerRequest__c",
    "label": "Customer Request",
    "fields": [
      {
        "apiName": "Status__c",
        "type": "Picklist",
        "label": "Status",
        "values": ["New", "In Progress", "Completed"]
      },
      {
        "apiName": "Priority__c",
        "type": "Number",
        "label": "Priority"
      },
      {
        "apiName": "AssignedTo__c",
        "type": "Lookup",
        "label": "Assigned To",
        "referenceTo": "User"
      },
      {
        "apiName": "Description__c",
        "type": "Textarea",
        "label": "Description"
      },
      {
        "apiName": "Email__c",
        "type": "Email",
        "label": "Contact Email"
      },
      {
        "apiName": "DueDate__c",
        "type": "Date",
        "label": "Due Date"
      },
      {
        "apiName": "IsUrgent__c",
        "type": "Boolean",
        "label": "Is Urgent"
      },
      {
        "apiName": "Amount__c",
        "type": "Currency",
        "label": "Amount"
      }
    ],
    "relationships": []
  }
]

支持的字段类型：Text、Textarea、Number、Picklist、Lookup、Email、Phone、URL、Date、Datetime、Boolean、Checkbox、Currency、Percent

不需要自定义对象时：

[]

inflightMetadata 的强制决策逻辑（数据类型：ARRAY）

1. 必须 - 首先：扫描本地 sfdx 项目，查找与用户的流请求相关的自定义对象和字段。
2. 如果找到相关的自定义对象：你必须提取这些对象，并将其作为结构化对象数组传递（参见上方格式）。
3. 如果未找到相关的自定义对象：你必须传递空数组 []（不能是字符串 "[]"）。
4. 绝不能：在 inflightMetadata 中传递文本描述、指令或字符串形式的内容。
5. 必须：数据类型必须是 ARRAY，而不是 STRING。

当自定义对象相关时，Vibes 的操作说明：

• 提取对象元数据，并映射到 JSON 属性：
  • apiName：对象的 API 名称（自定义对象带 __c 后缀）
  • label：对象的显示标签
  • type：设为 "CustomObject"
  • fields：字段对象数组，每个对象包含：
    • apiName：字段的 API 名称（自定义字段带 __c 后缀）
    • type：字段类型（Text、Number、Picklist、Lookup 等）
    • label：字段的显示标签
    • values：（仅限 Picklist）选项值数组
    • referenceTo：（仅限 Lookup）目标对象的 API 名称
• 仅包含与正在生成的流相关的对象和字段

🎯 强制增强规则

• userPrompt：必填。
  • 如果用户请求单个流：按原样使用用户的提示词。
  • 如果用户请求多个流：你必须拆分请求，为每个独立的流编写单独且具体的 userPrompt。每个 userPrompt 只能描述一个流。不要将整个多流请求作为单个 userPrompt 传递。请参阅下方的多流部分，了解示例。
• inflightMetadata：必填。始终使用 ARRAY 数据类型。
  • 不需要自定义对象时，必须使用 []（空数组）
  • 相关自定义对象时，必须使用结构化对象数组
  • 绝不能使用字符串 "[]"——这是错误的
  • 绝不能使用文本描述——只能使用结构化对象元数据

强制要求：多个流程 = 多条独立流水线

首先：调用任何流水线步骤之前，先检查用户的请求是否包含多个流程。如果包含，你必须将其拆分为多个仅包含单个流程的提示词。每个流程都要使用各自的 userPrompt 运行一条独立的 3 步流水线，且该 userPrompt 只能描述这一个流程。

绝不要将包含多个流程的请求作为单个 userPrompt 字段传入。绝不要将多个流程的描述合并到一个 userPrompt 中。

当用户请求多个流程时（例如：“为我的应用创建以下流程：1) ... 2) ... 3) ...”），你必须：

1. 拆分请求，将其拆分为各个独立的流程描述。
2. 为每个流程运行一条独立的 3 步流水线，使用的 userPrompt 只能描述该流程。
3. 按顺序执行所有流水线——一条接一条，绝不能并行。第一个流程完成后不要停止。不要等用户要求你继续。不要总结后停止。继续执行，直到所有请求的流程都已完整生成。

错误示例——将多个流程合并到一个 userPrompt 中：

{
  "userPrompt": "Create flows for the app: 1) Record-Triggered Flow on ResourceAllocation__c to update Resource__c. 2) Screen Flow to allocate resources. 3) Record-Triggered Flow on Supply__c to auto-flag Low_Stock__c.",
  ...
}

正确示例——每个流程分别调用：

流程 1 - 步骤 1（fetchGroundedObjectMetadata）：

{
  "userPrompt": "Create a Screen Flow named Tenant_Onboarding that captures tenant details, selects a Unit__c with Status__c = 'Vacant', creates Lease__c...",
  "inflightMetadata": [...]
}

然后使用步骤 1 中的 groundingMetadata 调用步骤 2（flowElementSelection），再使用步骤 2 中的 operationId 调用步骤 3（flowElementGeneration）。

流程 2 - 步骤 1（fetchGroundedObjectMetadata）：

{
  "userPrompt": "Create an Autolaunched Flow named Generate_Onboarding_Checklist that given a Lease__c Id input, queries OnboardingTask__c...",
  "inflightMetadata": [...]
}

然后为此流程调用步骤 2 和步骤 3。

流程 3 - 步骤 1（fetchGroundedObjectMetadata）：

{
  "userPrompt": "Create a Record-Triggered Flow named Sync_Unit_On_Lease_Changes that on insert and update of Lease__c...",
  "inflightMetadata": [...]
}

然后为此流程调用步骤 2 和步骤 3。

强制规则：

• 如果要生成 N 个流程，就必须运行 N 条独立的 3 步流水线，并且必须执行全部 N 条流水线。没有例外。生成一个流程后不要停止。
• 必须先完整完成当前流程的 3 步流水线（包括循环调用步骤 3，直到 isComplete 为 true 或返回错误），再开始下一个流程的流水线。 不要交错执行不同流程的流水线，也不要并行执行。所有操作都必须按顺序执行——绝不能并行。
• 完成一个流程的流水线后，立即开始下一个流程的流水线。在不同流程之间不要暂停、总结或等待用户确认。
• 对于每个流程，都必须扫描本地 sfdx 项目，并根据该流程的提示词将对应的自定义对象/字段填入 inflightMetadata。
• 每条流程流水线都必须有自己的 inflightMetadata，且其中只能包含与该流程相关的对象/字段。

工具调用示例

示例 1：仅使用标准对象（无自定义对象）

步骤 1 - fetchGroundedObjectMetadata：

{
  "userPrompt": "Create a scheduled-triggered Flow named Daily_Good_Morning that runs daily at 6:00 AM and sends an email to the running user saying good morning.",
  "inflightMetadata": []
}

步骤 2 - flowElementSelection：

{
  "userPrompt": "Create a scheduled-triggered Flow named Daily_Good_Morning that runs daily at 6:00 AM and sends an email to the running user saying good morning.",
  "groundingMetadata": "<groundingMetadata string from Step 1 — pass directly, do not serialize again>",
  "operationId": ""
}

步骤 3 - flowElementGeneration（循环调用）：

{
  "operationId": "<operationId from Step 2>",
  "requestSource": "A4V"
}

使用同一个 operationId 重复调用，直到 isComplete 为 true 或返回错误。一个流程可以包含任意数量的元素，因此需要预期多次迭代。当 isComplete 为 true 时，从 result 字段中提取流程元数据。使用 "requestSource": "A4V" 以获取 XML 格式的流程元数据。

示例 2：使用本地 sfdx 项目中的自定义对象

步骤 1 - fetchGroundedObjectMetadata：

{
  "userPrompt": "Create a flow that updates the status of a Customer Request when it's assigned",
  "inflightMetadata": [
    {
      "type": "CustomObject",
      "apiName": "CustomerRequest__c",
      "label": "Customer Request",
      "fields": [
        {
          "apiName": "Status__c",
          "type": "Picklist",
          "label": "Status",
          "values": ["New", "In Progress", "Completed"]
        },
        {
          "apiName": "AssignedTo__c",
          "type": "Lookup",
          "label": "Assigned To",
          "referenceTo": "User"
        }
      ],
      "relationships": []
    }
  ]
}

步骤 2 - flowElementSelection：

{
  "userPrompt": "Create a flow that updates the status of a Customer Request when it's assigned",
  "groundingMetadata": "<groundingMetadata string from Step 1 — pass directly, do not serialize again>",
  "operationId": ""
}

步骤 3 - flowElementGeneration（循环调用）：

{
  "operationId": "<operationId from Step 2>",
  "requestSource": "A4V"
}

使用同一个 operationId 重复调用，直到 isComplete 为 true 或返回错误。一个流程可以包含任意数量的元素，因此需要预期多次迭代。当 isComplete 为 true 时，从 result 字段中提取流程元数据。使用 "requestSource": "A4V" 以获取 XML 格式的流程元数据。

强制最佳实践

• 始终遵循 3 步流程：fetchGroundedObjectMetadata → flowElementSelection → flowElementGeneration。这是生成流程元数据的唯一方式，没有其他替代方案。
• 不要在此流程之外手动创建流程元数据 XML、JSON 或任何其他格式。
• 如果用户明确要求修复已生成的流程 XML 中的验证或部署错误，则允许对 XML 进行有针对性的手动修改以解决这些错误。这是“禁止手动创建元数据”规则的唯一例外。
• 不要试图通过跳过步骤或合并步骤来“优化”。每个步骤都是独立且必需的。
• 绝不跳过流程中的任何步骤。3 个步骤缺一不可。
• 绝不在未调用全部 3 个步骤的情况下尝试生成流程元数据。
• 绝不在任何情况下偏离此流程，即使你认为自己了解流程结构也不例外。
• 对于单个流程请求：必须将用户提示词用作 userPrompt。
• 对于多个流程请求：必须为每个流程分别**按顺序（依次执行，绝不并行）**运行 3 步流程，并且必须全部执行完毕——不要在第一个流程后停止。
• 必须将流程要求放入 userPrompt，而不是 inflightMetadata。
• inflightMetadata 仅用于来自本地项目的自定义对象/字段元数据（见上文）。没有例外。
• 第 3 步必须通过循环调用，并使用第 2 步中的同一个 operationId，直至 isComplete 为 true 或返回错误。流程可以包含任意数量的元素——不要提前停止，也不要暂停并询问用户是否要继续，无论需要迭代多少次。
• 只有当 isComplete 为 true 时，才能从 result 字段中提取流程元数据。

关键验证清单（每次生成流程前后都必须验证）

未严格遵循此清单将导致流程元数据损坏或缺失。

• 管道：严格按顺序调用全部 3 个步骤（fetchGroundedObjectMetadata → flowElementSelection → flowElementGeneration）。不得跳过任何步骤。
• 不手动创建元数据：不得以任何方式在此管道之外手动创建、修改或生成流程元数据
• 不得偏离流程：不得使用其他工具、API 或方法替代此管道或与其同时使用
• userPrompt 包含一个流程提示词。如果用户请求多个流程，则拆分请求，并为每个管道分别传入仅描述一个流程的 userPrompt
• userPrompt 在步骤 1 和步骤 2 中保持一致（值相同）
• inflightMetadata 的数据类型为数组（不是字符串）
• 无需自定义对象时，inflightMetadata 为 []
• inflightMetadata 包含通过扫描本地 sfdx 项目提取的相关自定义对象/字段结构化对象
• inflightMetadata 不得包含字符串 "[]"，必须是数组 []
• inflightMetadata 不得包含文本说明或指令
• 将步骤 1 输出中的 groundingMetadata 直接传入步骤 2 输入（它已经是字符串，不要再次序列化）
• 将步骤 2 输出中的 operationId 传入步骤 3 输入
• requestSource 始终设为 "A4V"
• 在循环中调用步骤 3，每次都使用步骤 2 返回的同一个 operationId，直到 isComplete 为 true 或返回错误——不得暂停，不得要求用户继续，无论需要迭代多少次
• 多流程：完成每个流程的整个管道后，再开始下一个流程的管道（不得交错执行）
• 仅当 isComplete 为 true 时，才使用 result 字段提取 XML 流程元数据
• 不得向 XML 添加内容：不得添加原始管道输出中不存在的任何元素、属性或特性。不得插入任何内容（例如 <label>、<description> 或其他节点）。最终 XML 必须与管道返回的内容完全一致。
• 错误修复例外：如果用户明确要求修复验证/部署错误，则允许针对性地手动编辑 XML；“不得向 XML 添加内容”和“不得手动创建元数据”限制不适用于这些编辑。