描述它
一句话输入，一个工作流输出
构建自动化的最难之处从来不是构建本身。而是空白画布、搜索框里的四百个集成，以及那种隐隐的疑虑：你正要为一个本该十分钟搞定的事情耗掉一个下午。这部分在这里被去掉了。
你输入什么
用你自己的语言、平实的文字描述你想完成的任务。无需挑选模板。无需猜测关键词。人们实际写出的句子是这样的：
“订单付款后，开具发票，扣减库存，并在发货时立即给客户发送带追踪链接的短信。”
“每周一早上七点，提取上周的预订数据，算出哪些场地预订不足一半，并给我发一封按最差排前的列表邮件。”
“如果任何有我们团队作业的地方出现恶劣天气预警，就给各队队长发短信——哪怕在深夜——并为值班经理创建一条备注。”
长比短好，具体比整洁好。如果等待应该是两天而不是一天，就写明。如果消息必须用波兰语发出，就写明。你漏掉的任何内容都会变成一个你日后要修改的默认值——这不是灾难，只是多花了一分钟本可省去的时间。
这两分钟里发生了什么
你的句子会被解析成一个意图：什么触发它、必须发生什么、按什么顺序、每个节点上什么条件必须成立。然后这个意图会对照实际存在的步骤目录进行解析——你已连接的账户、你套餐内的 castomAPI 服务，以及用于其余一切的普通 HTTP。
接着工作流被组装起来。步骤按顺序排列。在真正需要决策的地方设置分支。在句子暗示需要等待的地方设置延时。字段映射根据相关数据结构推测得出，并在推测不够确定时标记为猜测。
最后进行检查：每个步骤的必填输入都有来源，每个分支的两条路径都已定义，每个连接要么已存在，要么被标记为你仍需完成的。最终呈现在你面前的工作流是一个可以运行的工作流，而不是一张示意图。
你会得到什么
一个可编辑的工作流，处于关闭状态，并附有一份待办清单：它需要的连接、它做出的猜测，以及它无法推断的值。逐项完成清单，它就准备就绪了。
- ⚡已选择触发器Webhook ·
order.paid。签名验证默认开启。 - 2步骤根据参考数据校验收货地址。
- 3步骤开具发票。字段从订单映射而来。
- 4步骤扣减库存。幂等键设为订单 ID。
- 5等待直到发货 webhook 到达，或 5 天，以先到者为准。
- 6步骤发送带短链接的短信，并统计重定向次数。
- !需要你处理两个连接需要授权。一个猜测的字段需要确认：增值税率。
在你另行指示前保持关闭尚未运行任何内容
两分钟后，这就是一个可运行的流程。
然后由你接管
按你想要的方式精确设置它
这是最重要的部分，也正是那两分钟为你争取到时间来做的部分。
随意修改
添加步骤、删除步骤、重新排序、拆分分支，或者把 AI 步骤换成确定性步骤——因为你发现规则其实很简单。
用你自己的话表达
工作流发送的每条消息都是你可以编辑的文字。草稿只是一个起点，读起来也像起点；真正发出的版本应该听起来像你。
模拟运行
推送一条真实记录进去，读回确切的路径、每个值、以及它本会发出的每一条消息。模拟期间不会有任何东西离开系统。
自己动手搭建仍然是常规做法
很多人从不输入一句话。他们打开一个空白工作流，放入触发器，添加步骤，然后继续干活——对于三步的小任务，这往往比描述它更快。描述真正发挥价值的地方，是那种十二步、四个分支还带一个等待的任务——也就是你一直拖着没做的那一个。
你也可以描述对已有工作流的修改：“订单超过一千兹罗提时，也给仓库发一条通知”会以拟议修改的形式到达，以差异对比的方式展示给你，由你接受或拒绝。未经你确认，任何内容都不会应用到正在运行的工作流上。
关于那两分钟：这是对常见情况的描述，而不是保证。短工作流更快；连接不熟悉的长工作流则更久。固定不变的是这笔交易的形式——你写下一段文字，你拿回一个能用的东西，而你的注意力只花在只有你能决定的部分上。