傍晚六点，同事把一份初稿发过来，附言「你先看看，差不多能用」。打开一看，骨架完整，小标题齐全，几乎每一段都差那么一口气：话说得没错，但不像对着这个客户说的。
这种时刻，问题很少出在生成质量上。空隙在交接处——从「差不多」到「可以发出去」之间还有一段路，而这段路通常没人写进流程里。
接力棒掉在哪里，往往没人记账
我们习惯把人机协作描述成下指令与执行：人说清楚，机器做出来。实际用起来更像接力，而且是一根没人负责清点的接力棒。模型给出一版能读的文字，人接过来改两句，再让它扩写，再改。来回几次之后，稿子里哪句是原始判断、哪句是模型补的、哪句被谁顺手改了，已经说不清。
说不清本身不致命，致命的是出问题时找不到那个能说「这里是我定的」的人。
它可以写得很顺，但不知道哪句话会得罪人
模型输出的是它在大量文本里学到的中间值，稳妥、通顺、不冒犯。它不知道这位客户上个月刚换过负责人，也不知道这个数字对外不能说、对内必须说。这些判断不在语料里，只在具体的人脑子里。
于是有人试图用规范补上：写提示词模板、建术语表、把背景交代清楚。这些做法有用，但只能覆盖可以复述的部分。真正难的是那些说不出口的分寸——什么场合该直说，什么场合该绕一下。这部分至今仍留在人这边，也只能留在人这边。
把它放在草稿位，而不是决策位
一个更实用的做法，是先确定它坐在哪个位置。让模型负责铺开、列举、改写、找反例，这些它做得又快又稳；让人负责定调、取舍、签字。位置定下来，返工的归属也就清楚了。
反过来也要承认边界。有些环节并不适合人机协作，比如需要连续上下文的判断——前面三句话的分量决定了第四句能不能这么说，而模型每次接话都要重新理解一遍。这类工作交给它，改的时间往往比自己写还长。
所以我不太认同「所有环节都该接入」的说法。协作的价值不在于覆盖面，而在于把机械的、可以并行的部分挪出去，把需要负责的部分留下来。
一个可以立刻做的小动作
判断协作是否成熟，我倾向于看一件很小的事：出问题时，有没有人能立刻指出「这部分是我改的」。如果答案是肯定的，说明交接处有主；如果大家都要回头翻记录，那这套流程其实还没有真正跑起来。
具体做法也不复杂，比如在流程文档里加一列「最后修改责任人」，或者在稿子末尾留一行简短的改动说明。听起来琐碎，但人机协作真正的成本，常常就藏在这些琐碎里。