反向移交同样需要设计，人交回系统时须说明自己改变了什么

概念解释

人把控制拿回来处理完，还要还回去。反向移交不是按一个「继续」就结束。系统接着跑时，必须知道人改了哪几个对象、哪条约束作废了、哪一步不要再做。交回须声明人的改动（reverse handoff must declare human changes）把人当成交出方，承担和系统交出时对称的义务：说清自己动过什么。

人默默改了收件人再按继续，系统按旧计划发出去，这不是系统不听话，是交回协议是空的。

机制

自动化在人接管期间并没有自动获得人的意图。它看见的若只是「控制又回来了」，会从自己上次的计划或过期状态接着走。人的改动有的写在界面上（改了字段），有的只存在于人的决定里（跳过某步、作废某封）。后者若不被说出来，系统无法区分「没动」和「故意不让动」。监督控制的经典问题是自动化不了解操作者刚做的补偿动作，于是把补偿当噪声盖掉。

正向移交要状态和因果；反向同样要。差别是交出方换成了人，人不会自发写摘要，所以界面必须把「你改了什么」收成一份可确认的交回单，而不是指望人记得口述。

怎么研究

任务：人接管 → 改若干处（含一处只存在于决定、未改字段）→ 交回。比较无交回单、自动列出字段改动、列出字段改动并强制声明跳过的步骤。因变量：系统交回后是否撤销人的改动、是否重复被跳过的步、人是否意识到系统不知道那一处决定。

用日志对齐：人的意图列表 vs. 系统交回后实际执行路径。对不上的每一处都是反向协议缺口。

边界

人只看了、完全没改，交回单可以是空确认，但仍要走过「没有改动」这一拍，避免系统把「看过」误读成「改过」。人一直共同控制、没有明确交回点的，需要持续同步，而不是一份单。正向移交的摘要内容不在这里展开。

怎么落地

• 交回前自动列出可观测改动（字段、对象、权限），并提供「我还跳过了 / 作废了」的声明槽。不经过这张单，系统不得从人手里把执行权拿回去。
• 系统接回后必须按交回单覆盖自己的旧计划，而不是把人的改动当冲突再「修正」回去。
• 验证：让人改一处字段、再口头决定跳过一步，然后交回。系统若发出被跳过的那一步，或改回字段，反向移交就还没设计。把交回单拿掉再跑一次，看缺口是否全部出现——用来证明这张单不是装饰。

延伸

• 同组：L4.04.1 移交需要充分的情境重建时间 · L4.04.2 移交时的系统状态需完整交代 · L4.04.3 突然移交是最危险的形式 · L4.04.4 移交质量取决于交出方是否交代了为什么会走到当前状态 · L4.04.5 人重建情境所需的时间是硬约束，不能被压缩为零 · L4.04.6 系统在失去把握时才移交，而那正是情境最复杂的时刻 · L4.04.7 移交后责任立即转移，这一转移应由接管者确认而非默认成立
• 相邻：L4.14 多步任务的计划可见与修改 · L3.12 生成内容的编辑与接管 · L4.05 可中断与可回退
• 站内检索：reverse handoff · handback · operator compensation