晚上十点，一份文档改到第四版。第一版自己写，读起来发干；第二版丢给模型，回来一段四平八稳的说明文；第三版把要求拆成几句具体的话，才勉强能用。问题既不在自己写得多差，也不在模型多笨，而是卡在中间那几轮来回。人机协作里最费力的一段，往往就发生在这里。
机器善于展开，人负责收口
多数人第一次把任务交给模型时，默认它是个执行者：给指令、等结果、不满意再改。实际用起来更像和一个反应很快、但不知道前情的同事搭班。它不知道这份文档上周被谁否过，也不知道客户在意哪句措辞。这些背景不写进去，输出就会往平均的方向走，平是平了，但没有针对性。
所以决定结果的，常常不是提示词写得多花，而是交接时带了多少上下文。一段需求里，三类东西最好分开写：
- 硬约束，不能动的，比如篇幅、口径、必须保留的说法；
- 可以商量的，比如结构顺序、举例方式；
- 纯属个人偏好的，比如语气偏冷还是偏软。
分清这三类，来回次数通常会明显下降。
谁先动手，是个流程问题
见过一些团队把模型接进工单处理，最初的设想是人不用看，机器直接分流。跑一阵发现不行：分类准了，但优先级依赖客户情绪和历史往来，机器读不出来。后来改成机器先归类、先起草回复，人再看一遍改两句，整体反而顺了。这里的顺序不是小事——机器先动、人做二次判断，通常比人先写一半再让机器续写省力。
写作、代码审查、资料整理也类似。适合机器先动的环节，往往是起点模糊、需要铺开可能性的；适合人先动的，是目标清楚但取舍微妙的部分。顺序摆错，人机协作就变成互相等。
有些活儿，叫上机器反而更慢
也有反过来的情况。任务本身很短，或者判断标准只在自己脑子里，把要求讲清楚的成本高于自己动手。这类活儿硬塞给模型，省下的时间会以另一种方式还回去——反复解释、反复核对，最后还得自己重写。
判断标准可以很朴素：如果解释这件事的成本低于执行它的成本，就交给机器；反之自己做。这条线会随熟练度移动，但不会消失。
判断留在人这边，位置却在变
讨论人机分工时，话题容易滑向“人会不会被替掉”。从日常使用看，更实际的变化是人的判断位置在前后移动。以前判断在中间——审稿、验收；现在常常要提前到任务定义阶段，把标准说清楚；有时又要挪到最后，检查整体是否成立。中间那些重复搬运的环节，确实在变少。
这也解释了为什么同一套工具，不同人用起来差别不小。差别不在操作速度，而在能不能把模糊需求拆成可以交接的几段。
回到那个改文档的晚上。第四版能用的原因很简单：把“写得自然一点”换成“删掉形容词，保留两个具体例子，句子控制在二十字以内”。模型没变，人机协作的方式变了。这类调整琐碎，也不够戏剧性，但它就是目前大部分实际工作本来的样子。