光标停在段落末尾。屏幕上那段文字读起来通顺，前后也接得上，但你就是不肯按下回车。不是因为它明显有错，而是你说不清它为什么对。这个停顿只有几秒，却是人机协作里最容易被忽略的部分。
讨论工具时，人们习惯问它能不能做对。每天真正用它的人，问的是另一件事：从它交出的初稿，到我敢签字的成品，中间那段路怎么走。
提问可以练，验收很难练
提问是有手感的。多写几遍，把格式、约束、示例说清楚，多数人几周就能摸到门道。真正卡住人的在后面：一段生成内容摆在眼前，你需要判断它站不站得住。这个判断没法外包，也没法用一句“你再检查一下”打发过去。
于是就出现一种别扭的分工：机器负责把空白填满，人负责把填满的东西重新怀疑一遍。后一件事更消耗人，也更不显眼——它不产出新内容，只产出“这里不行”。
那些说不清的判断，交接时最容易掉
写东西的人知道某句话为什么不能那么写。不是语法错，是语感不对，是前面的铺垫撑不住这个结论，是读者读到这里会以为你在许诺什么。这类理由很难写进提示词，也很难写进验收清单，可它恰恰决定了一段内容能不能用。
机器拿不到这些隐性前提，只能照着字面执行。它给出的东西往往在字面上挑不出毛病，问题都藏在“这句放在这里合不合适”上。所以人机协作真正的摩擦点，很少发生在生成阶段，多半发生在生成之后那几分钟的犹豫里。
流畅会伪装成正确
语言模型有个显著特点：它写出来的东西通常是像样的。句子干净，结构完整。这种像样本身会带来信任感，让人放松警惕。读得顺，就容易默认它是对的；而真正需要核查的地方——某个前提是否成立、某个说法有没有出处——并不会因为读起来顺就变得可靠。
对抗这一点，靠的不是更小心，而是把检查变成具体动作：把不确定的地方标出来而不是抹平，把“这里我没把握”留在稿子里，让下一个看的人知道该看哪儿。抹平是一种很自然的冲动，谁都不想交出一份带批注的东西，但抹平恰好把风险藏了起来。
谁签字，谁负责
责任这件事没有模糊空间。工具不会因为给出了错误建议而承担后果，签字的人会。所以这条分工线其实很清楚：机器可以提出方案，可以并行给出几种可能，但最后一句话必须由人来说，而且说的人要能解释为什么。
麻烦在于，解释的能力会退化。长期不自己写、不自己推演，判断力就像不常用的肌肉。有人把这种状态形容成“审稿人失忆”：稿子看得越多，越说不清好稿子长什么样。这并非夸张，只是提醒一件事——把工具当成省事的办法，省掉的可能正是判断本身。
一点具体的做法
- 先写验收标准，再动手生成。标准可以很粗糙，但得在开始之前写下来，否则会被生成结果带着走。
- 把任务切成小段，每段都能独立判断对错，避免最后面对一大坨无从下嘴的东西。
- 保留“我不知道”的余地。不确定就标不确定，别让流畅的句子替你做决定。
回到开头那个停顿。它不舒服，但它是必要的。人机协作不是把活交出去然后验收，而是在每一个交接点上重新确认：这一步我懂了没有。懂了就往下走，没懂就停一下——这几秒钟，大概是整套流程里最像人的部分。