深夜的工位上，一个人盯着屏幕上一封由模型起草的邮件。改了三处措辞，删掉两段话，最后索性自己重写了一遍。前后花了十几分钟，比直接写还慢。
这大概是最常见的人机协作现场，也是最容易被误认成协作的那种：机器出一稿，人修一修。听着顺，做起来常常是返工。
摩擦出在交接的那一步
模型给的是一份中间品，不是成品。定位不先说清楚，人的预期就会错位——以为拿到初稿，实际拿到的是需要重新组织的素材；以为是答案，实际只是一个看起来像答案的句式。
麻烦大多不在生成环节，而在交接环节。机器不知道你手上已经有什么，不知道上一版为什么被否，也不知道这段文字要发给谁。这些信息不在提示词里，就在人的脑子里。人不写出来，机器只能猜；写出来了，往往发现写清楚的时间够自己做完。
于是有个挺实际的结论：人机协作的效率，很大程度取决于你愿不愿意把脑子里的默会知识写下来。这件事本身有价值，只是回报不在这一次，而在下一次。
它不太会说「我不确定」
语言模型有个特点：输出永远完整、流畅、语气笃定。哪怕内容靠不住，形式上也不露破绽。这对协作用处不大，因为人判断要不要复核，靠的正是那些破绽——停顿、迟疑、语气的松动。
- 它分不清「没查到」和「不存在」，两者会以同样的自信写出来。
- 它很少主动标注哪句是自己推的、哪句有出处。
- 长任务里，它可能悄悄换了目标，而过程读起来毫无异样。
所以复核不能靠感觉，得靠流程。哪些环节必须回查原始材料，哪些句子必须有人签字，最好事先定死。定死之后人会累一点，但心里踏实。
另一头也有麻烦：过度怀疑和过度信任一样让协作退化。有人每句话都查一遍，成本高到不如自己写；有人看都不看就转发，出事才发现问题。这两种状态都不是协作，只是把机器当成了负担或者挡箭牌。
把它当工位，而不是当同事
对话式界面容易让人产生错觉，好像对面坐着个人。但它的工作方式更像一台没有记忆、不会累、也不会提醒你的设备。按设备来设计流程，比按同事来期待要靠谱得多。
具体来说：输入端有稳定格式，别每次即兴描述；中间设检查点，让错误尽早暴露；输出端留痕迹，谁改了什么、为什么改，能回溯。听着像老一套的工程管理，用在这里恰好合适。人机协作真正的难点，从来不是模型够不够聪明，而是这个系统里人有没有明确的站位。
有些事还是别交出去。需要有人承担后果的决定、需要到现场看一眼的判断、需要长期关系才能推进的沟通——这些交给机器，省下的是时间，赔进去的是信任。省下来的时间也未必用在更要紧的地方。
回到开头那个深夜。重写一遍不丢人，但每次都重写，说明流程本身有问题，不是人不够快，也不是机器不够强。下一次起草之前，先想清楚哪部分该由谁做、在哪里交接、交接时留下什么。这三件事想明白了，协作才刚开始有点像协作。