浏览器提交型 workflow
适合网页填写、上传、提交、取证和审批控制。
这类 workflow 的关键不是“会不会点按钮”，而是“怎么避免误提交、重复提交、无证据提交”。
最典型的主干结构
- Goal / input
- Browser navigate
- Browser type / upload
- Review / approval
- Browser submit
- Screenshot / evidence
- Delivery
推荐节点顺序
| 步骤 | 推荐节点 | 作用 |
|---|---|---|
| 输入准备 | Goal / brief / input | 定义 URL、账号、标题、正文、附件 |
| 进入页面 | browser.navigate | 打开目标站点 |
| 填写与上传 | browser.type / browser.upload_file | 完成可预备内容 |
| 人工复核 | Review / Approval | 确认这次提交真的该发出 |
| 正式提交 | browser.submit_form | 触发真正的外部后果 |
| 取证 | browser.screenshot / observe | 留下提交证据 |
| 输出 | Delivery | 保存 proof、receipt、截图等交付物 |
审批为什么一定要放在提交前
因为浏览器提交型 workflow 的后果是立刻发生的：
- 表单一旦提交，外部状态就变了；
- 文件一旦上传，可能已经进入别人系统；
- 某些提交无法撤回。
所以审批放在提交后，基本就失去意义了。
最常见的错误搭法
- 先 submit，再 review；
- review 太模糊，批准的人不知道自己在批什么；
- 提交后不取证，后面根本说不清到底发没发出去。
更好的使用方法
- 所有提交字段都前置显式化；
- review 节点里只看该看的人类判断，不要再临时补字段；
- submit 后尽量立刻接 screenshot / evidence；
- 如果还有桌面侧校验，浏览器证据和桌面证据要分开保留。
想直接照着搭
如果你想从空白画布开始照着做一遍，可以继续看：
适用示例
- 官网表单投递
- 后台内容发布前提交流程
- 上传文件并提交审核
截图占位
后续建议补 3 张图：提交前 review 节点、submit 节点后取证、最终 delivery 里的证据包。