上周有个下午，我把同一段提示词改了七遍。每次模型都给出一个不算错、但也不算对的结果。改到第七遍时我才意识到，问题不在它理解得差，而在我从头到尾没把「做完」的标准说清楚——我要的是初稿、是清单，还是一个能直接发出去的版本，我自己也没想明白。
说不清的任务，交不出去
这类摩擦在人机协作里出现得比想象中频繁。人们习惯把协作理解成「把活儿分出去」，但分出去的前提是能描述清楚。写需求文档给同事，同事可以反问；对着一个输入框，反问的机会被压缩成你愿不愿意再补一句。多数时候人不愿意，于是拿到一个模糊的结果，再花时间抱怨模糊。
一个实用的做法是把任务拆成两半：目标是什么，以及什么样的结果算完成。前者决定方向，后者决定能不能收工。很多提示词只写了前一半。
上下文在谁手里
模型的短板往往不在推理，而在它不知道你上周跟谁争论过、这个方案为什么砍掉了第三版、对方看到什么词会皱眉。这些信息藏在人脑子里，不在训练数据里。所以人机协作里真正需要人做的，常常是把脑子里那部分隐性的东西翻译成可读的文字。这件事很笨，很花时间，但省不掉。
反过来，模型有它擅长的地方：不厌其烦地把同一段文字改成五种语气，把一份长文档里的重复项挑出来，在你卡住的时候给出一个不一定合适、但能打破僵局的选项。它不疲倦，也不需要被鼓励。
责任没法一起承担
协作里有一件事不能平分：结果的对错归谁。模型可以起草，可以检查，可以提出质疑，但签字的人仍然是人。这意味着交付前那道关必须自己过，哪怕前面九成的工作已经交出去了。见过不少人把「模型说的」当作一种免责理由，这种心态在协作里是比较危险的部分——不是因为模型会出错，而是因为它出错时看起来同样自信。
几个可以自查的问题
- 这个任务如果交给一个刚入职三天的人，我需要交代什么？
- 我能说清楚「什么样算完成」吗？说不清楚就先别交。
- 结果出来之后，我有能力判断它对不对吗？没有的话，先把范围缩小。
- 出错的时候谁承担后果？如果答案含糊，说明这一步还不该交出去。
那天下午最后我做的事很简单：把想要的东西写成三条，每条后面加一句「不要什么」。第八遍的时候结果能用了。不是模型突然变聪明，是我终于把话说明白了。人机协作听起来像技术问题，做起来更像表达问题——而表达这件事，暂时还没法外包出去。