WorkSwarm 里的人工确认，经常被写成了口头约定：文档里留一句“关键步骤要人确认”，编排里却是任务节点直连任务节点，流程根本不会停。要让流程在关键步骤前真的停下来等人拍板，通常的做法是先把任务流程画成节点图，找到“产出物已经可用、但下游动作代价高或不可逆”的那一段，在中间插入一个等待确认节点，把确认人、确认条件、等待超时后的默认动作都写成节点字段；然后跑一次测试任务，看流程是否真的停住；最后放宽确认条件再跑一次做对照，确认拦停来自配置而不是偶然。适用场景是审批、发布、对外提交这类需要拍板的环节；具体字段名以平台实际文档为准，通用骨架只是起点。
判断方向：人工确认要落成流程里的一个节点，而不是文档或群里的约定。操作动作：画节点图标出每步输入产出，在需要拍板的两段之间插入等待确认节点，写清确认人、确认条件与超时默认动作，再跑测试与反例两次对照。验证方式：看流程是否停在确认节点、中间结果是否被保留、确认后继续到哪个节点、条件放宽后是否跳过。风险边界：字段名按平台文档替换，超时默认动作本质上等价于自动放行，配置前先和业务确认。
把任务流程画成节点图并标出每步输入输出
不要一上来就打开编排页面填表单，先把流程画出来。节点图里每个节点都要写清三件事：输入是什么、产出是什么、下一步依赖哪个产出。有了这三件事，确认节点该插在哪两段之间就变得很直观——通常插在“上一节点的产出已经可以给人看，但下一节点一旦执行就产生外部影响”的位置。
[采集需求]
输入: 原始请求
产出: 结构化任务草案
依赖: 无
|
v
[生成方案]
输入: 结构化任务草案
产出: 待审方案
依赖: 草案字段齐全
|
v <-- 确认点通常插在这一段
[等待人工确认]
输入: 待审方案
产出: 确认结论(通过/驳回)
依赖: 方案已生成
|
v
[执行落地]
输入: 已确认方案
产出: 执行结果
依赖: 确认结论为通过
|
v
[归档记录]
输入: 执行结果
产出: 归档条目
依赖: 执行结果已生成画图时如果发现某个节点的产出无法用一句话说明，通常意味着这一步被拆得太粗，人的确认点也就无从下手。反过来，如果两个节点之间的依赖是“必须有人看过”，那这里就是确认节点的位置。
在需要人拍板的位置前插入等待确认的步骤
确认节点要写成流程里的一个步骤，而不是备注。通用骨架里需要三个占位信息，先按平台文档替换成真实字段名再落笔：
- 确认人占位：谁有权拍板。可以是固定角色、任务发起人、上一节点产出里带出的负责人字段。同一节点配多个候选人时，建议先确认平台是“任一确认即可”还是“需全部确认”。
- 确认条件占位：什么情况下必须停下来等，什么情况下可以自动放行。条件建议写得窄一些，先只覆盖明确需要拍板的场景。
- 超时默认动作占位：等待超过多久之后怎么办。常见三选一是保持等待、走失败回退、自动放行。自动放行等于把确认节点架空，配置前要先和业务确认这是否可接受。
另外建议在确认节点上开启中间结果保留。人做判断时需要看到上一节点的产出，如果确认节点只收到一句“请确认”，实际使用中往往会被迫回到原始系统里翻数据。
写一段最小编排骨架
下面是一段可以直接改的通用骨架，字段名和节点名都属于示意，必须按平台实际的编排字段说明逐项替换。三类结构分别是任务节点、确认节点、失败回退，缺一类流程就不完整。
# 节点 id、type、字段名均为示意，需按平台文档替换
nodes:
- id: task_step # 任务节点示意
type: task
input: <上一节点产出>
output: draft
next: wait_confirm
- id: wait_confirm # 确认节点示意
type: human_confirm
assignee: "<确认人占位>"
condition: "<需要确认的条件占位>"
keep_context: true
on_timeout:
action: hold # hold / fail / auto_pass，先与业务确认
duration: "<超时占位>"
next_on_approve: exec_step
next_on_reject: fallback_step
- id: fallback_step # 失败回退示意
type: task
input: draft
output: revised_draft
next: wait_confirm
- id: exec_step # 下游执行节点示意
type: task
input: <已确认产出>
output: result写这段骨架的顺序建议是：先写任务节点和它的产出字段，再写确认节点的三个占位，最后把驳回路径接到回退节点上。回退节点通常做成“修改草案后重新进入确认”，而不是直接结束流程，否则一次驳回就等于整条任务作废。
在测试任务上跑一遍验证是否停在确认节点
配置写好之后不要直接上线，先用一个不产生外部影响的测试任务跑一遍，重点记录三件事：
- 停止位置：任务是否停在等待确认节点，下游执行节点是否仍处于未执行状态。可以在编排运行日志里看节点状态流转，也可以在任务页面看当前卡在哪一步。
- 停下时保留的中间结果：上一节点的产出是否还能查到。通常需要确认产出的落盘位置或引用标识，以及确认页面里是否能看到这份产出。
- 确认后流程继续到哪一步：手动点通过之后，是否进入执行节点，执行完成后再到归档节点。驳回一次，看是否进入回退节点并再次回到确认节点。
如果测试任务一路跑到底、没有停在确认节点，先别改条件，而是检查确认节点是否真的被挂在依赖链上，以及确认条件是否被写成了恒真表达式。
放宽确认条件做一次反例验证
为了确认拦停来自配置而不是偶然，把确认条件放宽一次。例如从“任何情况下都需要确认”改成“仅在标记命中时才需要确认”，再用一个不命中标记的测试任务跑一遍。
对照记录建议按下面几项对齐：
- 条件放宽后是否跳过确认节点：正常期待是直接从任务节点走到下游执行节点，时间线中间没有出现确认记录和操作人。
- 两次输出的差异：中间结果本身通常相同，差别在于流程轨迹——第一次在确认节点处有停滞和人工操作记录，第二次轨迹连续、下游节点提前出现。
- 确认失败路径是否仍可用：把条件改回命中标记，驳回一次，看回退节点是否被触发。
如果放宽条件后流程仍然停下，说明停下来自别的地方，可能是平台层面设置了强制人工节点，或者下游节点自身有审批开关，这时需要回到节点图重新确认依赖关系，而不是继续调整确认条件。两次跑完再决定最终条件，通常比一次配置上线更稳妥。