泳道图能看出哪个角色负责哪个动作，却不一定说明角色之间交了什么。一根从撰稿人连到审校人的箭头，可能代表材料送达，也可能代表请求决定。若不说清楚，执行者仍会反复确认。本文用虚构的内容审校场景说明交接标注，不涉及任何产品的自动审批或发布权限。
先保持泳道的划分一致
英飞官方泳道图文章介绍了按角色表达责任的方式。本文示例采用撰稿、审校和发布准备三类角色，不把人名、部门和系统混成同一层。角色名称服务于实际分工；若同一人兼任多个角色，也应按动作责任说明，而不是因为人员重合就省略必要的确认过程。
给跨线动作写出交付对象
从撰稿到审校，不只写“转交”，而要说明送出待审稿及必要依据，并注明使用版本。接收者需要什么输入，发送者就应在交接前核对什么。不能把缺失资料留给接收者临时寻找，也不要把整段聊天原样扔过去，让对方猜哪条才是当前要求。材料不齐时应有补充路径。
决定和材料可以分别交接
审校结束后，后续角色需要的不只是一个文档，还需要知道确认范围、仍存在的问题以及哪些修改尚未通过。虚构案例中，可以交付确认稿和审校结论，不能仅用“看过了”表示所有内容都可使用。具体通过条件由团队约定，本文不把示例当成统一审批制度。
退回时说明回到哪一步
发现事实依据缺失，可能需要补资料；仅有措辞问题，可能只需修改指定段落。退回箭头应对应具体接收动作，不把所有情况都送回最初起点。重新提交时说明改动位置与采用版本，接收者才能判断需要复核哪部分。若新增内容改变了原结论，也应重新确认受影响范围。
用接收者视角验收箭头
请每条泳道的负责人回答：我在什么条件下接到工作，会收到什么，做到什么程度交给下一位。相邻角色的答案应相互匹配。若发送者说已交付而接收者说无法开始，先找输入条件差异，不只争论谁回复得慢。没有明确去向的交接，应保留为待确认问题继续处理。
不要让图代替实际确认
泳道里的动作属于责任约定，箭头画出来不等于消息已送达、材料已接收或决定已批准。实际执行仍应留下可回查结果。本文配图是方法示意，不是产品界面，也不展示自动发布流程。建议优先标注跨角色的关键交付，再检查每个内部小动作；责任边界最容易暴露在交接处，而不是框的数量上。