用AI起草一份内部通知，大概是最日常的协作场景。人把背景、语气、忌讳一股脑塞进提示框，机器吐出一版看着像模像样的稿子。然后呢？多数人不会直接发出去，而是从头读一遍，改掉三处措辞，删掉一句过度承诺，再把称谓统一。这几分钟里发生的事，恰恰是人机协作最真实的部分。
有意思的是，讨论往往跳过这段。人们更爱谈模型能写多长、能读多少文档、能识别几种格式。可真正决定一次协作是否成立的，是稿件从机器交回人手里之后的那段时间——人是全盘接受，还是逐条核对，还是干脆推翻重来。
工具越顺手，核对越容易被省略
顺畅的交互会制造一种错觉：既然读起来通顺、逻辑也说得过去，那大概就是对的。问题在于，语言模型的输出是概率性的，它擅长的是“像”，而不是“是”。
这就带出一个不太被重视的变量：人的停留时长。同一份草稿，花三十秒扫一眼和花三分钟逐句过，得到的结论可能完全不同。而工具设计如果一味追求“一键完成”，其实是在压缩这段停留。人机协作出问题的地方，常常不是机器答错了，而是人没来得及发现它答错了。
机器不知道的，是上下文之外的东西
目前多数系统的工作方式，是围绕一次请求给出一段回应。它看不到上周的会议结论，也读不懂团队里那个只可意会的分寸。人却相反，人的判断里塞满了没写进文档的东西：这句话上次说过被否了，这个数字对外口径要保守，这个客户不喜欢被称作“用户”。
所谓人机协作，很大程度上就是把这些隐含信息补上去的过程。但补的方式很关键。有的人选择在提示里尽可能说清楚，有的人选择让机器先出一版粗糙的，自己再动手改。前者省事，后者省心，各有代价。比较危险的是第三种：既不说明，也不检查，把机器当成了一个懂行的同事。
哪些活不该交出去
并不是所有环节都适合交给机器。有些工作看起来是重复劳动，实际上每一次都在做一个细小判断。比如把一段技术描述改写成人能看懂的说明，字面上是改写，内核是理解——理解哪些概念可以省略，哪些必须保留。这类环节交出去之后，人往往需要花更多时间回头补。
可以列几条粗略的分界，供参考：
- 信息搬运、格式转换、初稿铺陈，适合交出去；
- 涉及承诺、边界、对外口径的表述，人应该握着最后一道；
- 需要理解组织内部默契的部分，机器目前接不住；
- 流程中最容易被跳过的人工确认环节，恰恰要保留。
这些分界不是固定的，会随着工具能力变化而移动。但移动的节奏需要人来把握，而不是由工具的便利程度决定。
把“等一下”留出来
一个值得注意的细节是，好的协作流程里通常存在某种停顿。编辑在发送前会重读标题，工程师在合并代码前会看一眼改动，设计师在交付前会核对一遍字号。这些动作看似低效，其实是人在把判断重新接回流程。
人机协作要变得可靠，恐怕也要靠这种停顿。不是把机器调得更慢，而是在流程里保留一个明确的、不可跳过的确认点。工具方可以做的是让这个确认点更清晰——比如标出哪些内容是生成的、哪些地方依据不足；使用方要做的是别把这个点当成形式。
回到开头那份通知。真正让稿子能发出去的，不是模型写得多好，而是有人在最后那几分钟里认真看了一遍。机器负责把空白填满，人负责决定哪一句能留下。这个分工听起来朴素，却也是人机协作里最难自动化的部分。