AI 辅助 Workflow 设计
01 / 08人机协作：创建 Workflow
把业务目标变成可编辑的 Workflow 草稿，同时保留用户的控制权
项目一览
问题 手动创建 Template 要求企业用户先理解每个 Action。随着 Moxo 服务更多企业，让 Customer Success 参与每次配置并不能持续扩展。
应对 团队增加了自然语言创建入口。AI Copilot 把业务描述变成现有 Builder Canvas 中可编辑的初稿，用户不必先请 Customer Success 代为搭建 Template。
早期信号 上线后六小时内收到 60 多条有效 Prompt。这说明用户愿意尝试，但不能证明长期使用或草稿质量。
背景与问题
把业务意图转成可靠的 Workflow 逻辑
Moxo 已进入成熟阶段，希望让更多企业团队自行创建 Workflow，不必每次配置都依赖 Customer Success。难点在于，Action、Trigger、角色和依赖关系的配置复杂，单靠新手引导或 Help Center 仍不够。
- 用户能说清业务目标，却不一定知道如何把它拆成 Workflow。
- 自然语言降低了开始的门槛，但不会自动补齐角色、Trigger、输入和步骤依赖。
- 团队因此选择让 AI 先生成可编辑草稿。用户确认关键信息，再回到现有 Builder 检查、修改并发布。
研究依据
Customer Success 告诉我们 AI 需要问清什么
Customer Success 团队把真实客户沟通时使用的 SOP 分享给我们。这套 SOP 会先确认目标、角色、Trigger、所需信息、执行顺序和依赖关系，再开始配置 Workflow。
我把这套顺序映射为产品行为。信息缺失时，AI 会在生成前追问可能改变 Workflow 草稿的细节。
这些沟通内容帮助我们定义产品需要问清什么，但不能用来证明用户采用率、草稿质量或节省时间。
设计策略
先分清 AI 和人各自负责什么
我比较了三种人机分工方式，分别查看输入成本、交接点、用户控制和实现复杂度。
Customer Success 提供了真实的需求沟通案例。我与 Product 确定首版边界，再和 Engineering 一起评估每种模式需要处理的状态和交付成本。
评估标准
用四个问题比较不同方案
它们是评估标准，不是用户流程。
输入成本
AI 开始工作前，用户要提供多少信息？
交接点
AI 何时停止、用户何时接手，是否清楚？
用户控制
用户能否查看、修改并确认结果？
实现复杂度
这个模式会增加多少新状态和研发工作？
判断 01
AI 先生成，用户随后检查和修改
AI 与用户同时编辑时，很难看出修改由谁负责、当前又是什么状态。单独建立 AI Mode 可以分开两种状态，但用户需要切换模式，实现成本也更高。
我建议采用 AI-first。AI 生成草稿后，直接在现有 Builder 中打开。用户可以检查、修改，并决定是否发布。
判断 02
先问关键问题，不急着生成
我比较了三种提问方式。直接生成会迫使 AI 猜测缺失的角色和流程逻辑；一次问完所有问题，又会让创建过程变得很长。
最终方案只追问会改变 Workflow 结构的信息，确认后直接进入可编辑的草稿。
判断 03
把 Prompt 变成可编辑的 Workflow，而不是一段对话回复
我把交接设计成三个阶段：描述目标、补齐会影响 Workflow 的信息、检查草稿。
草稿会直接在现有 Builder 中打开。用户可以使用熟悉的控件继续编辑，不需要重新搭建 Workflow。
Phase I · 已上线
先验证完整的创建闭环
从 Prompt 开始，补齐缺失结构，生成草稿，再进入 Builder 继续编辑。
验证重点： 用户能否从业务意图得到完整、可检查的草稿？
Phase II · 已完成设计
让 AI 也能修改已有 Action
用户可以只修改局部，同时保留 Workflow 其他部分的顺序和依赖。
范围说明： 这是下一阶段的设计，不作为已上线结果展示。
Phase I · 已上线
从业务目标到可编辑的 Workflow 草稿
现有 Canvas 已经支持手动添加、编辑和删除 Action。这次改版增加了 AI 创建入口，并定义 AI 与 Action 之间的交接方式，同时保留 Canvas 的结构和原有手动编辑行为。首版覆盖一条完整路径：描述目标、回答关键问题，再到 Builder 中编辑草稿。
步骤 01
描述业务结果
用户先用自然语言说明要建立的流程，不必一开始就配置 Workflow 对象。
步骤 02
确认会改变草稿的信息
生成前，AI 会识别缺失细节，并围绕角色、逻辑或 Integration 提出具体问题。
步骤 03
在 Builder 中检查并继续编辑
生成的 Workflow 会在 Builder 中打开。用户可以检查结构、修正问题，并用熟悉的控件继续编辑。
Phase II · 已完成设计
用同一套审核方式修改已有 Workflow
下一阶段把同样的交接方式用于已有 Workflow。AI 可以准备局部修改，但应用前仍由用户审核。
扩展 01
只改一个 Action，不重新生成整个 Workflow
重新生成可能覆盖用户已经确认的结构。Action-level AI 保留当前上下文，只修改目标 Action。
整个流程分为五步：提出需求、补充信息、修改、检查、确认。
扩展 02
把重复交互整理成复用模式
不同 Action 需要的输入各不相同，但可以使用同一套交互规则：补齐信息、连接所需工具、确认角色或业务规则。
我通过定期设计评审，把这些规则应用到后续 AI 功能，并整理成团队可以直接使用的模式。
扩展 03
让问题看得见，也能恢复
Flow Checker 会标出问题位置、说明缺少什么，并告诉用户下一步可以做什么。
我为输入、确认、处理中、结果、错误和恢复分别定义了页面反馈与可用操作。
结果与衡量
上线数据说明了什么，又没有说明什么
Phase I 在现有 Builder 中上线了从 Prompt 到草稿的完整流程。用户可以从业务目标开始，不必先配置系统对象。
上线六小时内的数据说明用户愿意尝试这个入口，但没有证明重复使用、草稿质量或节省时间。
来自上线后的前六小时。
在现有 Builder 中完成从 Prompt 到草稿的完整流程。
生成后的信心
用户是否理解草稿，并愿意继续？
有效 Prompt 与重复使用
早期兴趣能否延续？
由 AI 开始的 Workflow
用户多常选择 AI 作为创建入口？
再次创建 Workflow
用户之后是否还会使用 Copilot 创建 Workflow？
完成并发布的草稿
用户能否在不过度返工的情况下得到可用 Workflow？
这些数据没有证明什么
Prompt 数量只说明早期兴趣。后续仍需跟踪重复使用、返工量、完成的草稿和已发布 Workflow。
真正难的是划清责任
生成 Workflow 只是问题的一部分。更难的判断是 AI 在哪里停下，用户又在何时接手。
用户需要看见结果、纠正问题，并回到熟悉的工具继续工作。缺少这些环节，再快的草稿也不值得信任。
下一个项目