下午的工位上有一种很常见的停顿：屏幕上已经躺着一份由模型起草的回复，措辞完整，语气也挑不出毛病。操作的人却没有直接点发送，而是把其中两句删掉，又补了一句只有老客户才看得懂的解释。系统随后弹出一个很小的输入框，问修改原因。这个动作很轻，却把问题摆到了桌面上——如果人只是在最后按一下确认，这还算不算真正的人机协作？
很多团队在引入AI时，习惯把工作切成“机器做前半段，人做后半段”。听上去清楚，实际使用时却常常卡在交接处。模型交出的是一份看起来能用的结果，人接过来的却是一堆隐形判断：这句话能不能发，那个承诺有没有越界，上下文里缺的那块信息要不要追问。交接越顺滑，人越容易跳过这些判断；交接越粗糙，人又得从头返工。
任务交出去，判断不能一起消失
人机协作里最容易被忽略的，不是模型能不能生成，而是人还能不能生成判断。把草稿交给模型，不等于把判断也交出去。真正需要设计的是：哪些环节允许模型先走一步，哪些环节必须停下来等人。比如对外沟通、承诺时间、解释原因，这些地方一旦只追求“快”，后面往往要用更多沟通去补。
我倾向于把AI放在“提出选项”的位置，而不是“替人决定”的位置。它可以给出几种回复方向，标出各自依赖的信息；人可以选，也可以不选。这个动作看起来笨，却保留了人的解释空间。工具越像同事，越要防止人把它当成挡箭牌。
让不确定的地方显形
有些系统喜欢把不确定藏起来，用流畅的句子盖过去。可人机协作的质量，往往取决于不确定有没有被看见。模型不知道某条需求已经变过，就应该把这个缺口标出来；它对某个条款没有把握，就不该用肯定语气写完。人可以接受“这里需要你确认”，但很难接受“看起来都对，出了问题才发现少了一环”。
可回退也很重要。草稿能不能一键回到原始信息，修改记录能不能被后来的人看懂，异常能不能转给另一个人接手。这些不是附属功能，而是协作能否持续的基础。没有回退，人就会被迫在第一次判断上过度用力；没有记录，下一次协作又得重新猜。
责任要落在能解释的人身上
责任这件事，不能因为多了模型就变模糊。模型可以生成理由，但它不承担后果；人可以借助模型，但最后签字的仍然是人。所以流程里要留下“为什么这样改”的位置，而不是只留下“已确认”。能解释的人，才适合做最后的判断。解释不必很长，哪怕只是一句“这次要保留交付节奏”，也比一个空白勾选更有价值。
这也是我对人机协作保持谨慎的原因。它不只是界面问题，也不只是模型能力问题，而是把原本藏在个人经验里的判断摊开，重新分配。摊开之后，有人会不习惯，因为以前靠手感就能过去的地方，现在要写下理由；也有人会松一口气，因为不用再假装所有事情都由自己独立完成。
回到那个下午的工位。回复最后还是发出去了，只是多了两句人写的解释。模型没有被关掉，人也没有被替代。真正改变的是中间那几秒钟：人停了一下，知道自己为什么停。人机协作要的可能就是这几秒钟——不让机器替人假装确定，也不让人替机器承担全部沉默。