一段文字生成出来，编辑删掉一个逗号，又加回去。这个动作没有任何产出，却实实在在占掉了时间。人机协作的很多摩擦就藏在这种地方：不在模型能不能写出来，而在人要不要改、改哪里、改完敢不敢用。
把注意力全放在能力上，容易得出一个过于简单的结论：模型再强一点就好了。可实际用起来，卡点常常在交接的那一刻。
摩擦发生在任务被切开的地方
一份工作交出去，先要拆成“机器做的部分”和“人做的部分”。这个动作看着自然，做起来却很难干净。写方案，前半段是找资料、搭骨架，后半段是取舍和语气，中间并没有一条清晰的线。切得太细，人要不停喂上下文，比自己写还慢；切得太粗，返回来的东西要整段推翻。多数人的做法是边做边调，慢慢摸出一个自己能接受的切法，这个过程很难写进任何操作手册。
还有一层是验证。判断一段输出靠不靠谱，成本并不一样：事实可以查，逻辑可以顺，语气和分寸只能靠经验去感觉。当验证的成本接近甚至超过自己动手的成本，协作就失去了意义——这也是不少人在试过之后又退回去的原因，未必是东西不好用，而是核对太累。
有些知识，写不进提示词
车间里靠听声音判断设备状态的师傅，把经验描述成文字时会发现，那些词一旦落到纸上就走了样。这类知识的特点是模糊、依赖情境、和具体的人绑在一起。人机协作在这类场景里最容易露怯：能说清的部分机器接得住，说不清的部分仍然留在人身上，而往往正是后者决定了一件事做得好不好。
所以更现实的做法，可能不是想办法把隐性经验全部显性化，而是承认有一部分交不出去，然后把它安排在流程的末端，让人在最后一道关口上保留否决权。
判断力没有全部留在人这边
“人负责决策、机器负责执行”这个说法听着清楚，实际用起来要含混得多。人经常在两种状态间摇摆：一开始过于信任，看到格式工整的段落就默认内容可靠；吃过一次亏之后又变得过度怀疑，逐字逐句重写。校准这种信任需要时间，也需要系统给出可追溯的线索——这句话是从哪来的，这段改动动了什么。
我更愿意把成熟的人机协作理解成一种低成本的怀疑：人不必全盘复核，但能快速定位到该复核的位置，并且有底气说出“这里不对”。这既取决于模型的稳定程度，也取决于界面是否把依据摆在了人眼前。
从这个角度看，协作的质量不完全是技术指标能衡量的。它更像一种被反复磨合出来的默契，需要人愿意把自己的工作方式说清楚一点，也需要工具在给出结果时，顺手留下让人可以反驳的余地。