下午改稿，让助手重写一段开头。它回了一句“我建议这样改”，后面跟着新版本。多数时候人的反应是直接看新版本，觉得顺就留下，别扭就删掉。被跳过的是那半句话——为什么这么改。这半句不写在界面上，却决定了这次协作到底算不算协作。
一个措辞，改变了谁做决定
“答案是”和“我建议”是两种东西。前一种把工具摆在查询台后面，后一种把判断的最后一公里交回给人。听上去只是措辞客气，实际上换了角色：人从执行者变成裁决者。麻烦在于，很多流程只接住了前半句的建议，没接住后半句的裁决——界面上没有地方让人真正行使那个“裁决”。
于是就出现了名义上的人机协作：机器产出，人签字。
三种常见的错位
- 橡皮章式复核。人在最后点一下通过，几分钟扫一遍。时间预算不够，注意力也不够，签字变成形式。
- 追问无门。模型给了结论，但界面上没有地方让人问“这个改动牵连哪几段”“换个前提会怎样”。人只能凭手感决定，或者干脆放弃追问。
- 职责悬浮。出了问题，说不清是提示词的问题、模型的问题，还是复核的问题，因为中间过程没留下痕迹。
这些毛病并不新鲜，只是被生成式能力放大了。过去的工具输出相对可预期，复核成本低；现在每次结果都不一样，复核成了实打实的劳动，而劳动需要时间，时间需要被排进流程里。
给反驳留一个入口
等模型把理由讲清楚，可能要等很久，而且讲出来的理由未必是它真实的推理路径。流程层面可以先放几个具体的钩子：
- 置信度分层。模型的自评不一定准，但它至少能提示哪一段它也在猜，人的注意力就可以往那里挪。
- 改动可追溯。每一次变更能对着原文看，而不是只看到一个焕然一新的结果。
- 可撤销。一键退回上一版，人才敢大胆否决。否决的成本越低，否决就越可能真的发生。
这几件事都不高级，但它们把人机协作从一句口号变成可以检验的动作：人有没有真的看过、改过、退回过。没有这些动作，协作只是并排放着。
判断力是用出来的
一个不太被讨论的隐忧：如果人长期只在最后按回车，判断的肌肉会松。起初还能看出哪里不对，半年后可能连“哪里不对”都说不清，只剩下一种模糊的信任或不信任。
反过来，如果流程设计得让人无法否决，所谓协作就是把人的名字挂在机器产出上。适当地让机器交出不完美的初稿，留出人动手的空间，未必是效率上的浪费——人的那部分能力需要练习才留得住。
回到那半句话。“我建议”后面本该跟着理由，理由不一定由机器给全。人可以先问一句为什么，再决定接不接受。这一问落地了，人机协作才算开始。