把一份材料丢给模型，让它整理成几条要点。几秒后结果返回，读起来通顺，格式也齐整，你扫了两眼就转给了同事。过了一会儿才发现，其中一条把否定的意思写反了。
这种失误很难归咎于哪一方。模型确实完成了“整理要点”这个动作，人也确实“看过一遍”。问题出在两者之间那段没有写下来的约定：什么算整理好，哪些表述不能动，谁负责最后一遍核对。
摩擦几乎都发生在交接处
聊起人机协作，注意力通常落在模型能做什么上，却很少有人关心任务是怎么交出去的。而真正消耗时间的地方，往往就在这个交接的环节。
- 描述损耗。人脑里的任务带着大量背景，说出口时只剩一句指令，模型只能按字面去补全那些没说出口的部分。
- 验收漂移。结果足够通顺，“读起来对”就被当成了“确实对”，核对这一步悄悄被跳过。
- 责任悬空。流程里多了一个参与者，却没有相应地多出一个明确的确认动作。
这三样不会因为模型变强就自动消失。能力提升往往把错误推得更靠后、更隐蔽：粗糙的错误一眼能看出，措辞得体、逻辑自洽的错误才最难查。
人从动手的人变成定标准的人
比较务实的做法，是在把任务交出去之前先回答几个问题：哪些部分不许改，什么情况下必须回头问人，产出要满足哪几条才能用。这些答案写在前面，比事后反复重试省力得多。
人的位置也随之移动。从前是自己做完再检查一遍，现在是先想清楚边界，再判断产出有没有越界。前者靠熟练，后者靠对业务的理解，而这份理解恰恰是最难直接写成提示词的东西。人机协作的质量，很大程度上取决于这一步做得够不够扎实。
另一个常被忽略的细节是，给出反例往往比给出要求更有效。告诉模型“不要这样写”，比描述“要写成什么样”更容易被执行，因为反面样本具体，正面描述容易空泛。
有些环节不该交出去
一个简单的判断标准：错误能不能在事后被低成本地发现。能复核的，交出去风险有限；一旦错误会混进最终结果、又难以追溯来源，那一段判断就该留在人手里。
还有一种情况是需求本身在变。边做边改的任务，来回沟通的成本可能超过自己动手，这时候分工反而不划算。
所以不必执着于全自动。人机协作更像一次分工设计：把重复的、可核对的环节交出去，把定标准和担责任留在自己这边。省下来的注意力用在别处，这大概是现阶段比较稳妥的用法。