周三下午，一份周报被贴进群里。内容不算差，结构清楚，措辞也挑不出毛病，但半小时过去，没有人认领它。起草的人说，初稿是模型给的，自己只改了几个数字；审的人说，既然大部分不是人写的，签字就有点像替别人担保。文件躺在那里，工作其实做完了，流程却卡住了。
这类卡顿，在人机协作里出现得比想象中频繁。讨论通常集中在能力上——模型能不能写、写得像不像、错得多不多。但真正让事情停住的，往往是交接：谁在哪个环节接手，接手时能改到什么程度，出了问题由谁说明。
交接点比分工表更值得看
把任务拆开，人做一段、机器做一段，这种分法看起来清楚，实际操作里常常失效。因为工作的连续性并不按段落划分。一份材料里的判断，藏在它对读者是谁、对上一版为什么被退回的理解里；这些理解很难写进提示词，也很难从一段生成的文字里读回来。
于是人机协作的损耗大多发生在交接点上，大致有三种：
- 语境丢失。上一轮的讨论、被否掉的理由、真正被关心的那一句，在传递时被压缩成一句简短指令。
- 判断被提前固化。模型给出一个看起来完整的框架，人接手时更倾向于在框架里修补，而不是重新想一遍。
- 责任悬空。参与方变多，但每个环节都只做了“一部分”，最终没有人对整体负责。
把人放在最后一步，是最省事也最危险的做法
很多流程的设计是：机器先做，人最后审。听上去稳妥，实际上把最重的负担压给了最疲惫的一环。审核者面对的是一份成形的东西，改动意味着推翻，不推翻意味着背书。时间紧的时候，人往往选择后者，然后就出现了开头那一幕。
另一种做法是把人的介入往前挪：动笔之前先确定目标读者和判断标准，让机器做检索、做初稿、做一致性检查，人则在中途几次短暂介入。这样做看起来更麻烦，但它把判断留在了还有余地的时刻。人机协作的质量，很多时候取决于人在什么时候说话，而不只是说了多少。
有些事，不适合交给协作
也需要承认边界。涉及对外承诺、涉及需要当面解释的判断、涉及只有内部人才清楚的权衡，勉强让模型参与，反而增加了解释成本。一个团队如果为了用上工具而把简单任务复杂化，那不是在协作，是在给自己加流程。
判断标准其实朴素：这件事出错之后，能不能说清楚是谁在哪个环节做的决定。如果不能，就先别急着把机器拉进来。
回到那份周报。后来他们的处理方式很平淡——起草的人在文件头写清楚哪些段落来自初稿、哪些经过改写，审核的人只在改动处签字。流程没有变快多少，但文件终于有人认领了。人机协作要解决的，大概就是这种不起眼的问题。