下午三点，屏幕上是第三版文案。我把一段话交给助手改，它改得通顺，却把我原本想保留的棱角磨掉了。我退回去，自己重写。来回几次，时间花在“它不懂我为什么要这样写”上。
这不是能力问题。多数时候，机器给出的结果不差，差的是交接。人机协作最费劲的地方，往往不在执行，而在把意图从一个人脑子里搬到另一个系统里。
交接处最容易掉棒
接力赛里，掉棒很少发生在跑得慢的人身上，而是发生在交棒的那几秒。人把任务交出去时，默认对方知道背景、轻重、不能碰的底线。但模型只看到你写下的那几句话。你没写的，它不会问。于是出现一种奇怪的循环：人嫌机器不懂，机器等人说清楚，人又觉得说清楚的时间够自己做完。
一个细节是：很多工具把“确认”做成一个按钮，点一下就开始生成。但真正需要确认的是那些没说出口的约束。界面不问你“这段文字能不能改语气”，它只问你“要不要继续”。这种摩擦，常常就藏在这种默认里。
让机器说“我不确定”比让它更聪明更难
模型输出带有概率性，它倾向于给出完整、流畅的答案，而不是停下来指出哪里没把握。对人来说，流畅容易被当成可靠。这是协作中的隐性风险：不是机器做错，而是它错的时候看起来和做对时一样。
所以有些团队在流程里加一道人工复核，不是为了挑错，而是为了在关键节点保留判断。判断这件事很难外包，因为它绑定责任。谁签字，谁承担后果。机器可以给建议，但不能替人承担。
边界不是能力线，是责任线
哪些交给机器？重复的、可逆的、有明确验收标准的。哪些留给人？涉及取舍、对外承诺，以及“这句话说出去会不会被误解”的场合。这不是说机器做不了，而是做错了之后，修正成本由谁承担。
一种不太好的倾向，是把人机协作理解成尽量少动手。结果是人在流程里越来越靠后，等到发现问题时，改动已经扩散。反过来，另一种做法是把人放在每个交接点旁边，不是盯着，而是随时能接住。这两种体验差别很大。
好的协作让人少解释几次
如果非要给一个判断标准：看这套协作有没有减少“来回解释”的次数。好的设计会把意图拆成可勾选的约束，会在不确定时停下来问一句，会把机器的建议和人修改的痕迹并排放在一起。这些都不新，但比单纯追求生成速度更接近真实工作。
那天最后，我没有再让助手改第四版。我把要求写成三行：保留哪句、删掉哪句、语气不能变。它一次就改对了。问题从来不是它不够聪明，而是我一开始没把“你再改改”翻译成它能接住的话。人机协作的进步，可能就藏在这种翻译里。