下午四点，一间不大的会议室里，编辑把一份合作意向书的摘要交给模型改写。三分钟后返回的版本读起来更顺，但她还是花了将近二十分钟，把其中一句“双方预计在下季度扩大合作范围”改回原样——原文里没有“下季度”，也没有“扩大”，那是模型顺手补上的推测。这二十分钟不会出现在任何效率统计里。
类似的时刻，在用了生成式工具的团队里几乎每天都在发生。它不戏剧化，也不构成事故，只是把一件原本简单的事，变成需要反复确认的事。
分工写在流程图上，判断发生在中途
很多团队在引入工具时会画一张流程图：人定方向，机器铺量，人再审核。图上看是直线，走起来却是来回折返，人机协作真正的难点不在于机器能不能做，而在于分界线在每个具体句子上移动——这句话可以让它写，那句不行；这一段它给的结构更好，那一段它把语气拉平了。
分界线不稳定，是因为它取决于内容而非任务类型。同样一份材料，涉及公开信息的部分可以放手，涉及承诺和数字的部分必须收回来。这条线很难提前写进规范，只能靠在具体文本上一次次划。
被忽略的确认成本
讨论人机协作的效率时，人们习惯计算产出速度：原来两小时，现在四十分钟。但复核要花多久，往往没人记录。一个不算精确但常见的现象是：当模型给出三个候选措辞，人从中挑一个所费的力气，未必低于自己想出一句。选择需要理由，而理由得自己找。
以下三件事在协作里最容易被漏掉：
- 最终版本由谁负责。生成的人和署名的人通常不是同一个角色，责任却只落在后者身上。
- 修改是否留痕。改回去的那一句如果没记原因，下一个人还会再犯一次。
- 边界写在哪。哪些情况必须停下来找人确认，如果没写清楚，就会默认成“看起来没问题就用”。
把“改回去”算进流程
有些团队的做法值得参考：不把机器输出当草稿，而当候选，先过一道删除关——凡是原文没有的事实、数字、时间，一律删，不做润色。处理完这一道，剩下的部分再谈语气和结构。
另一种做法是在指令里明确要求：不确定的地方留白，不要补全。这一点比让它“写得更完整”更实用。留白会暴露缺口，补全则把缺口藏起来，等到核对时才发现。
什么场合不该用
判断标准未必与任务复杂度相关，更可能与“错了以后能不能被发现”有关。可核查的场合，人机协作相对顺畅，因为错误有出口；错误不易被察觉的场合，省下来的时间会以另一种方式还回去，通常是复盘、返工或信任损耗。
这不是说谨慎就该变成拒绝。多数日常工作处在两者之间：错误能被发现，但需要成本。协作的价值就在这里——把人的力气从铺量挪到判断上。
一个朴素的衡量方式
衡量协作是否成立，除了看产出快了多少，也可以看一件事：复核时人是更放松，还是更紧张。如果工具让人对每一句都保持戒备，它省下的只是打字时间；如果它能让人腾出手来处理真正需要判断的部分，协作才算真的发生。
会议室里，那位编辑最后保留了原句，把模型的版本挪进了备选栏。她没有删掉它，只是没让它替自己说话。