见过一种很典型的工作现场：运营同事对着屏幕，等模型把一份活动方案生成出来，然后从头到尾读一遍，改几个字，点发送。问她哪里不满意，她说“说不上来，感觉有点空”。再问她自己原本想解决什么问题，她停顿了几秒。
这不是人机协作，这是人给机器做校对。表面上人还在流程里，实际上判断权已经悄悄交了出去。
把活派出去，不等于协作
很多团队引入模型的第一步，是找那些“最烦、最重复”的活。写周报、整理会议记录、起草邮件、做初步调研，这些确实适合交出去。问题出在第二步：交出去之后，人往往只保留了一个“检查错别字”的位置。
真正的分工不该这么划。机器擅长的是在给定框架内快速铺开可能性，把空白迅速填满；人擅长的是判断这个框架本身对不对，值不值得填。如果人只做后置的审核，就永远在机器设定的框架里打转，改来改去也跳不出去。前面那位同事说的“空”，其实是她自己失去了定义问题的位置。
所以人机协作的关键，不在于任务怎么切分，而在于判断权放在哪一段。问题定义、取舍标准、什么算完成，这些如果先由人说清楚，模型的表现会明显不一样。
先写清楚“不要什么”
实践中一个有用的调整，是把提示词的重心从“要什么”挪一部分到“不要什么”。要什么，模型很擅长补全；不要什么，它往往意识不到。比如不要行业套话、不要三段式排比、不要用“赋能”“闭环”这类词、不要给没有依据的结论。这些约束写得越具体，产出越接近能用的状态。
这背后其实是个分工问题：人负责划边界，机器负责在边界内跑。边界模糊的时候，模型会用最省力的方式填满空间，结果就是那种看起来完整、读起来没劲的文本。边界清晰的时候，它反而能腾出力气处理细节。
保留一段不能省的手工时间
另一个容易忽略的点是节奏。模型几秒钟给出初稿，人会不自觉地缩短思考时间，觉得既然这么快，就没必要慢慢想。可判断恰恰是慢的。
有些团队开始刻意保留一段“不用工具”的时间：先自己写三五行，说清楚这次要解决什么、读者是谁、最怕出现什么偏差，然后再打开模型。这几行字不交给机器，它花的时间不长，但决定了后面所有产出有没有方向。这段手工时间看着低效，实际上是给判断力留的锚点。
还有一种做法是反过来用：让模型先给三个差异很大的方向，人只做一件事——指出哪个方向最不像自己想要的那个，并说出理由。理由说得出来，说明判断还在自己手里；说不出来，就说明还没想清楚。
协作的质量取决于人愿不愿意先想
工具越顺手，越容易掩盖一个问题：很多工作本来就没想清楚，只是以前靠手动执行拖长了时间，看起来像在思考。模型把这个过程压缩之后，空白就暴露出来了。
从这个角度看，人机协作不是一个技术配置问题，更像一种工作纪律。它要求人在打开工具之前，先把问题、标准、禁区写下来；在拿到产出之后，能说出自己为什么改这一处、不改那一处。做不到这两点，协作就退化成接单。
这也解释了为什么同样一套工具，在不同的人手里效果差得很远。差别不在提示词技巧，而在有没有人愿意在动手之前多花那几分钟。机器不会替人想清楚要什么，它只会把没想清楚的部分放大。