一份活动方案，AI 三分钟给出初稿。编辑打开，读了两段，删掉一半，索性从头自己写。事后问他为什么不用，他说：改它比自己写还慢。
这类场景常被解释成“模型还不够好”。但慢的地方其实不在生成那一下，而在两次点击之间的那段空白：机器交出来的东西，人得先读懂，才能判断要不要。
卡住的往往不是能力，是交付形态
把一项工作切成“机器做前半段、人做后半段”，听起来顺理成章，中间那道缝却很少被认真设计。机器一次给一整篇，人只能整篇读；机器给三个方向、每个方向附一句取舍理由，人的判断成本立刻不同。同样的模型，换个交付形态，用起来的手感差别很大。
所以讨论人机协作时，注意力容易全放在模型那一侧，而真正决定效率的是接口：任务在哪里断开，人从哪里接手，接手时看到的是什么。
通顺会伪装成确定
语言模型输出的是连贯的文本，读起来总是像样子的。像样子容易被当成靠谱，这是协作里一个隐蔽的陷阱：它不会主动说“这句我拿不准”，除非有人要求它说。
于是有个被低估的设计动作：把不确定显性化。做法并不复杂。
- 输出后面附上依据与假设，分开写清楚；
- 关键数字宁可留空、标成待确认，而不是填一个看着合理的；
- 给两三个方向及各自代价，而不是只给一个结论。
代价是麻烦。写标注要花时间，读标注也要花时间，不是每个场景都值得。一份内部备忘，差不多就行；一份对外材料，多花的这几分钟，可能省下后面几个小时。
该不该交出去，算的是另一笔账
判断某个环节能不能委托，习惯性的问法是“AI 做不做得了”。更实际的问法是“我能不能低成本地知道它做对了没有”。核对一段输出的时间如果超过自己从头做的时间，委托就不成立，哪怕它写得挺好。
这条线会移动。工具变好、格式变规范、检查项变清楚，线就往外挪一点。但它不会消失，总有需要人拍板的地方。
人的注意力放在哪里
好的协作设计，是让人把注意力集中在少数需要判断的节点上，而不是让人充当逐字审阅的质检员。前者花五分钟，后者花五十分钟，产出未必差多少，人的状态差很多。人机协作往前走，未必是人用得更多，而可能是人看得更少、看得更准。
下次试用一套新工具，可以先问一句：它把需要我确认的东西，放在了我容易看见的地方吗？