周会开始前，一份由模型整理的会议纪要发到群里，末尾停着一句“请确认”。这个动作很小，却把问题摊开了：生成内容可以很快，确认责任却不会自动转移。人机协作真正落地时，经常卡在这类交接处，而不是卡在模型能不能写出完整句子。
不是把任务切两半
很多关于人机协作的讨论，习惯把工作分成“人做的部分”和“机器做的部分”。听上去清楚，做起来容易失真。模型擅长从已有材料里提取线索、改写语气、生成备选，但它不知道哪条信息在今天已经失效，也不知道一份对外文档里哪个措辞会引发误解。人需要提供的，往往不是收尾润色，而是任务背景、判断标准和停止条件。把这些说清楚，协作才开始有形状。
反过来，人也不必把所有思考都外包给模型。一个可操作的做法是，把工作拆成“可撤回的草稿”和“需负责的结论”：前者可以多轮生成，后者必须由人核对来源和影响。这样既利用了生成速度，也保留了判断的重量。
提示词之外，还有交接单
提示词常被当成协作入口，但真实流程里，交接单同样关键。它不一定是一张正式表格，可能只是几句备注：这份材料给谁看，哪些信息不能改动，遇到不确定内容时是留空、标注，还是停下来询问。缺少这些约束，模型会倾向于把空白填满，人则要花时间做反向检查。把约束前置，反而减少了来回。
- 输入来源要可追溯：哪些段落来自原始材料，哪些是模型补充的转述。
- 不确定项要显式保留：允许出现“待核”，不要为了通顺把疑点抹平。
- 责任点要写清楚：谁发出、谁复核、谁对定稿版本负责。
这些做法并不复杂，却决定了这套流程是节省时间，还是把时间挪到返工上。
边界感来自可解释的停顿
模型不会天然知道何时该停。它往往继续生成，给出一个看起来完整的答案。对使用者来说，重要的能力是识别“该停”的信号：材料不足、口径冲突、影响范围超出预期，或者任务本身需要承担后果。此时让人介入，不是对技术不信任，而是流程设计的一部分。
也可以把这种停顿做成习惯。比如在让模型起草对外说明前，先约定一个复核清单；在让模型整理数据前，先确认口径和截止时间；在把生成内容放进正式流程前，先问一句“如果这条信息错了，谁会先受影响”。这些问题不解决，人机协作就容易停留在演示阶段；解决之后，它才可能变成日常工作中安静的一环。
回到那份会议纪要。确认按钮留给谁，答案并不神秘：留给能够补充上下文、判断影响并承担结果的人。人机协作的成熟，大概不是让机器更像人，而是让人更清楚自己在流程里的位置。