把多个步骤连接起来之前，可以先问一个简单的问题：如果这一步做错了，谁会受到影响，恢复起来是否容易？这个问题有助于决定哪些环节可以自动完成，哪些环节需要确认。
先区分草稿和真实动作
在页面里整理一段文字，与把这段文字发送给别人，是不同的操作。前者通常还可以随时修改；后者可能已经影响了他人的判断。同样，提出一个更新建议，与修改共享记录，也不应该被当作同一次授权。
示例流程：读取一段记录 → 生成待办草稿 → 展示待变更内容 → 人工确认 → 创建真实任务。
这个设计把“生成建议”和“执行操作”分开。确认的人看到的是即将发生的变化，而不是一句笼统的“是否继续”。
一次确认应该展示什么
- 操作对象：将修改哪条记录，或者把信息发送给谁。
- 具体变化：原内容是什么，新内容是什么，是否还有待确认字段。
- 后续影响：是否会触发通知，或让其他流程继续执行。
- 退回路径：信息不完整时，如何补充，如何取消。
确认只对应当时展示的内容。如果草稿、收件人或关键参数在确认后发生变化，就需要重新检查，不能把之前的同意沿用到一个不同的操作上。
退回也是正常结果
信息不足时，让流程停下来比猜着继续更合适。退回提示要说明缺少什么，例如“请补充负责人和具体完成日期”，而不是仅仅显示“操作失败”。补充完成后，再从合适的步骤继续。
如果操作结果暂时不明确，也不要立即重复执行。先核对原操作是否已经完成，避免同一条消息发出两次，或同一个任务被重复创建。
把边界写在流程里
可以用一个小清单检查设计：哪些步骤只是读取和整理？哪些步骤会改变外部状态？谁可以确认？未确认时是否真的无法继续？取消后还有没有后台动作？
首页的小实验只在浏览器中切换预设状态，不执行真实任务。它展示的重点是：流程能够等待、退回和结束，而不是一直向前运行。