周三下午，我盯着一份自己署名的稿子看了很久。句子挑不出错，逻辑也通，读起来却像谁把几段说明书拼在了一起。改到第二遍我才想起来，骨架是模型给的，我只是在给它换衣服。
这种时刻多了以后，我逐渐意识到，人机协作里最费劲的部分往往不在机器做不好的地方，而在它做得「看起来还行」的地方。
成本从写挪到了看
把初稿交给模型，产出速度确实变了。但省下来的时间并没有原样还给你，它换了个形式回来：变成阅读、比对、判断「这句到底成不成立」的时间。写的时候人是在创造，看的时候人是在防守，两者疲劳的位置不一样。
更麻烦的是，防守很难量化。写了两千字，你知道自己干了两千字的活；审了两千字，你说不清自己做了什么，只觉得眼睛发涩，还想再确认一遍。
有些判断没法外包
模型能给出一段通顺的话，但它不承担这段话被读错之后的后果。署名的是人，这意味着最后那层「我确认过」的责任只能留在人这边。这不是对模型的贬低，而是分工本身的性质：责任没法随着任务一起交出去。
还有一层是上下文。一个需求背后的来龙去脉、哪位同事在意什么、上一版为什么被推翻，这些散落在日常里，很少被写进任何文档。人带着这些隐性信息，模型没有。所以在人机协作里，人的位置更像一个带着背景资料的审稿人，而不是一个等着收货的下单者。
交接处值得设计
见过不少用法，是把任务整块丢进去，再整块捞出来。这样用，摩擦全堆在最后。把顺序稍微改一改，会舒服很多：
- 先写清楚「这段要解决什么问题」，再让模型动笔。问题描述比指令措辞更要紧。
- 检查点往前挪，写一小段就停下来读一次，别等全文铺完再回头。
- 让它多给几个方向，由人来选。选择通常比修改便宜。
- 留一份记录，写下哪里改过、为什么改，下次能省掉一次解释。
这些做法都不新鲜，也不依赖多强的模型。它们指向同一件事：把人和机器之间的接触面做得窄一点、清楚一点。
一连串动作
人机协作听起来像一个状态，其实更像一连串具体动作：交付、检查、退回、再交付。这些动作顺不顺，决定了它到底省事还是添事。工具会一直换，交接处那些小麻烦，大概还会陪我们很久。