下午四点，屏幕右边是生成工具刚吐出的第三版方案，左边是上午已经改过两轮的文档。光标在两个窗口之间来回跳，人没有停下来，却也没真正往前走。原本期待省下来的时间，被另一种动作填满：看一眼，想一想，再确认一次。
这种停顿很难写进效率表。它既不是技术故障，也不是人的犹豫，而是人机协作里常见的确认成本。工具越主动，确认动作越密集；输出越快，判断越容易堆积在人的一侧。
从“发指令”到“接结果”
很多关于AI的讨论停留在指令怎么写。实际使用中，更消耗精力的是接住结果之后的那几分钟：这段内容能不能直接进入下一环节，哪些地方需要改，改了会不会牵动别处。指令可以复制，确认却必须由人完成。
于是，人机协作的第一道边界出现了。工具可以生成多个选项，但选择哪一个、为什么选，仍然要由人给出理由。把这一步全部推给工具，表面上是自动化，实际上是把判断往后挪，挪到某个更晚、更难改的时刻。
停顿不是浪费
有些团队把停顿视为流程里的摩擦，想尽量删掉。删掉之后，人与AI之间确实连贯了，但错误也更容易一路滑到终点。确认成本并不是越低越好。适度的停顿像检查点，让输出在进入下一步之前有机会被看一眼。
问题在于停顿的位置。如果每一次细小的输出都要人确认，人会很快疲惫；如果只在关键节点确认，工具又可能沿着错误方向走很远。人机协作的节奏设计，某种程度上就是决定哪些确认不能省、哪些可以合并。
- 先确认目标，再确认措辞，避免在细节里反复推翻方向。
- 把重复的确认动作集中处理，而不是每生成一段就打断一次。
- 给不确定的输出留标记，让人一眼看到需要判断的位置。
这些做法不复杂，却要求工具承认自己的不确定，也要求人接受自己仍是流程里的一部分。人机协作不是把任务交出去就结束，而是重新分配注意力的过程。
谁承担最后一眼
确认成本背后是一个更具体的问题：最后一眼由谁来看。只要结果要进入公开页面、客户沟通或正式流程，最后一眼就很难完全交给工具。这不是对模型能力的否定，而是责任归属的问题。工具可以加速生成，却无法替人承担确认后的后果。
所以，讨论人机协作时，比起问“AI能替代多少工作”，更实际的问题是“哪些确认必须留在人这一侧”。把这个问题想清楚，工具才不会变成新的待办清单。人也不必因为多看了几眼就自责，那些停顿本来就是协作的一部分。