下午四点，屏幕上是一份看起来已经完整的方案。作者往下读，读到第二段停住了——有个词不对劲。他知道不对劲，却说不出为什么。改，需要理由；不改，又过不去。这三十秒里没有任何技术故障，但人机协作的一部分成本，恰好在这里被结算。
类似的动作每天都在发生：点开、扫一遍、觉得差不多、点通过。看起来人还留在流程里，实际上人只是守在流程外围。
交接处的那点空白
机器给出来的东西通常“像那么回事”。这个“像”很关键，它把人的工作从生产挪到了判断。问题是，判断力不是凭空长出来的。一个人要在改过十几遍稿子之后，才知道哪种说法会让人误解；要在被退回过几次之后，才建立起对“差不多”的警惕。直接拿到一份成品，中间那些坎坷都被省掉了，判断反而失去了可以依靠的练习过程。
于是出现一种奇怪的状态：人对结果不满意，但提不出具体的修改意见。这跟能力无关，问题出在成长路径被截断了。
把“不对劲”翻译成话
带过新人的人都熟悉这种时刻——对方交上来的东西方向偏了，你说不上来哪里错，只能让他再想想；等自己动手改，又觉得其实很清楚。这类标准大多是默会的：语气该紧一点，例子该具体一点，承诺该收着说。它们没有写进任何手册，却决定了成品能不能用。
人机协作的瓶颈多半卡在这里。机器不会因为你皱眉就调整，它需要一句能被执行的指令。所以真正省时间的做法，往往是在开口之前先写下来：这段内容给谁看，要解决他的什么疑问，哪些词不能用。这几行字写起来枯燥，却把模糊的直觉变成了可传递的东西。如果自己都写不清楚，换什么工具都白费。
责任没法一起交出去
交付物出了问题，没人会接受“这是模型写的”作为解释。签字的人负责，这条规矩没有变过，大概也不会变。所以流程里总要留一个人工确认的节点。麻烦的是，节点很容易退化成一次点击——既然前面已经跑过那么多轮，人下意识地认为该检查的都被检查过了。
有个不算复杂的办法：让确认带上内容。改了什么，为什么改，哪一段是自己加的。哪怕只写一行，也会逼着人真的读进去。空白的“通过”按钮不产生任何信息，带内容的确认才留下痕迹，下次回头还能看出当时在犹豫什么。
哪些活儿先交出去
不必一刀切。我的判断依据是两个问题：出错之后能不能被发现，发现之后能不能挽回。整理会议记录、改写措辞、把散乱的想法归拢成条目，这些错了很容易看出来，改回来也快，可以放心先交出去。涉及对外的承诺、涉及他人利益的表述、需要长期担责的决定，慢一点没有坏处。
这条界线也不是固定的。用久了会发现某些原本担心的环节其实很稳，也会发现某些看起来简单的环节反复出岔子。人机协作的成熟，大概就体现在这条线被一次次微调，而非一次划定。
回到那个停住的下午。那天他删掉了那个词，换成一句更笨但更明确的话。改动很小，甚至没人会注意到。但那一刻他做的是判断，不是校对——这两件事的区别，决定了人在这套流程里究竟是参与者，还是流程末端的一道保险。