starter 细页：approval_flow
适合在高风险动作前挂审批骨架的 starter。
approval_flow 最适合拿来解决一个很具体的问题：
“我需要先准备结果，再让人决定要不要继续。”
它更像审批骨架，不是复杂业务模板。
适合谁
- 需要在发布、发送、写回、提交前先审批的人
- 已经知道高风险动作在哪里的人
- 想把审批位置先放对的人
不适合谁
- 只是做只读分析或本地交付的人
- 还没想清楚审批到底要拦什么动作的人
- 需要复杂多分支业务逻辑的人
最安全的改法
最安全的是只改：
- collect / prepare 这一段
- 审批人要看的上下文
- 审批后的真正动作
但不要先乱动“审批在中间”这个骨架。
最容易改坏的地方
- 把审批放到动作后面
- 审批节点不给足够上下文
- 把多个后果完全不同的动作塞进同一个审批
第一次试跑建议
先确认你到底要拦住哪一个高风险动作。
第一轮先用测试目标验证审批是否停在正确位置。
确认审批通过后流程能继续，再接真实外部动作。
更适合什么时候换 starter
如果你已经需要：
- 批准 / 返工双分支
- 浏览器提交证据链
- 失败进入 Inbox
那可以考虑换成 review_publish、browser_desktop_submission_audit 或 failure_inbox。
字段映射示例
approval_flow 更接近审批骨架，所以它的固定输入很少，重点在审批前后数据怎么流。
| 你填写的输入 / 运行中产出 | starter 里怎么用 | 常见产出 |
|---|---|---|
topic | 进入 read-source-data 节点，先把待审批内容收集出来 | sourceData |
sourceData（节点产出） | 进入 manual-review 节点，作为审批材料 draft | approvalDecision |
approvalDecision（审批产出） | 进入 prepare-approved-result 节点，决定后续交付内容 | deliverable |
deliverable（节点产出） | 进入 choose-delivery 节点 | delivery artifact |
推荐输入模板
当前这条 starter 的默认固定输入很克制，通常先从一个明确主题开始：
{
"topic": "整理待发布版本的变更说明，并生成给审批人查看的交付草稿"
}更推荐你在节点配置里补齐审批上下文，而不是一开始就往运行输入里塞很多字段。第一轮先确认“收集 → 审批 → 交付”这条骨架成立，再扩展输入结构。