早上打开文档，让模型先列一个提纲；中午把会议记录丢进去，请它整理待办；下午写邮件时，又让它改语气。动作很熟练，但停下来想一想：这算协作吗？还是只是把零散任务递出去，再凭感觉挑结果？
很多讨论把注意力放在模型能做什么，却略过一个日常问题：人和机器之间的“交接”是否清楚。任务从人手里出去时，背景、约束、验收标准有没有一起出去？结果回来时，谁来判断、谁来修改、谁对最终版本负责？这些环节没理顺，工具再顺滑，也只是增加了一次次临时判断。
交接不清，协作就会变成返工
以写一份对外说明为例。人若只说“帮我写清楚”，模型很可能给出结构完整、语气平稳的稿子，却漏掉内部已经确认的限制条件。人再回头补，来回几轮，时间并没有省下来。反过来，如果先把读者、用途、不能承诺的内容、必须保留的措辞列出来，模型输出未必一次到位，但至少进入了可修改的范围。
这里的差别不在生成能力，而在信息是否在交接时被保存下来。人机协作的难点，往往不是生成，而是生成之前的说明和生成之后的验收。
把“我来把关”拆成具体动作
“人来把关”听起来负责，实际常常落空。把关需要动作：核对事实来源，检查语气是否越界，确认数字和专有名词没有变形，判断结论是否超出了给定材料。若这些动作没有写进流程，最后就变成扫一眼、觉得差不多、直接发出。
一种可操作的方式，是把协作拆成几段：
- 人先定义任务边界，说明哪些内容不能碰、哪些必须保留；
- 模型负责扩展、整理、改写或提出备选，不替人做最终承诺；
- 人按清单验收，把不确定的地方标出来，而不是只看整体顺不顺；
- 把反复出现的修改意见沉淀成下一次的交接说明。
这些动作不复杂，却决定了人机协作是省心还是添乱。模型可以快速给出多个版本，但版本之间的取舍仍要有人承担。责任不能外包给一个概率系统，也不能用“它自己写的”来解释。
边界不是限制，是让协作可持续
有些任务适合让模型先走一步，比如资料归类、语气调整、把长文压缩成要点；有些任务适合人先搭骨架，比如涉及判断、承诺和对外表述的内容。把边界说清楚，不是拒绝工具，而是减少每次都要重新谈判的消耗。
也要承认，人的注意力有限。若每个输出都逐字审，协作成本会上升；若完全放手，风险又不可控。可行的做法是按影响范围分层：低风险草稿可以快速过，高影响内容则保留人工复核和明确责任人。这里的“分层”不是给任务贴标签，而是决定审核密度。
回到开头那个场景：让模型列提纲、整理记录、改邮件，本身没有问题。问题在于，我们是否把每一次递出和收回都当成一次真正的交接。人机协作要处理的，不只是“机器能不能做”，还有“人准备怎么接”。当交接说明、验收动作和责任归属都变得具体，工具才不会只是制造额外待办。