早上打开文档，模型已经写好三段产品说明。人读了一遍，删掉一句空话，补上两个限制条件。看上去只改了几分钟，真正的时间却花在后面：为什么删那句，为什么补这两个条件，下一轮还要不要沿用同样的判断。生成很快，交接很慢。很多所谓的人机协作，卡住的地方并不在模型会不会写，而在人接手时能不能迅速还原上下文。
如果把模型只当搜索框，问题简单：给关键词，拿结果，不合适就重来。但一旦它进入日常流程，输出物就不只是答案，而是一份需要被继续加工的半成品。半成品里藏着模型没有说出的假设：它为什么选这个结构，忽略了哪些约束，哪里可能自信过头。人如果看不到这些，就只能靠重读和猜测把上下文补回来。交接成本因此出现，而且往往比一次生成更隐蔽。
问题不在模型会不会写，而在人愿不愿意接
这里的“接”不是接过一段文字，而是接过判断。一个可用的交接，至少要让接手的人知道边界：哪些是事实，哪些是推测，哪些需要回到原始材料核对。提示词可以写得像交接单，不必长，但要包含目标、已知限制、验收标准，以及“不确定时请标出来”。这样做不会让模型突然可靠，却能让人更快发现哪里不可靠。
这也是人机协作容易被低估的部分。人们常把注意力放在模型能力上，看它能否写得更长、答得更快，却很少问：它留下的工作，别人能不能接着做。一个回答如果无法被复核，就算看起来完整，也可能只是把成本推给下一位编辑、下一位运营或下一个环节。工具越顺手，这种转移越不容易被察觉。
边界不是划出来的，是用出来的
有些团队喜欢先写一张分工表：模型负责初稿，人负责修改；模型负责整理，人负责判断。表格当然有用，但真实边界往往更细。某个环节能不能交给模型，不取决于任务名称，而取决于三个信号：结果是否可验证，错误会落到谁身上，上下文能否被复述。可验证、错误成本可控、上下文清楚的部分，更适合先交出去；反过来，宁可让人多做一步。
- 可验证：输出能否回到原始材料逐条核对，而不是只看语气是否顺畅。
- 错误成本：一旦出错，是改一句话，还是要推翻整条流程。
- 上下文：换一个人接手时，能否在短时间内明白模型做过什么、没做什么。
这三个信号不提供标准答案，只帮助团队把争论具体化。它们也解释了一个现象：同一个模型，在不同流程里的体验可能完全不同。差别不只在提示词，还在交接方式。人机协作不是把任务丢给模型再等人收尾，而是把可复述的上下文、可检查的中间结果和明确的责任一起设计进去。
所以，更实际的做法也许不是追问“模型能不能替代这一步”，而是先看“这一步交出去之后，人还能不能接得住”。如果接不住，生成得再快也只是把问题往后挪。真正省时间的，不是让模型多写一段，而是让人少猜一次。模型可以扩张草稿，人可以保留判断；两者之间那条不显眼的交接线，才决定了协作能不能长久。