前段时间帮朋友改一份稿子。他把初稿发过来，说自己只写了提纲，剩下的是模型补的。我读了两段就发现问题：句子都对，逻辑也顺，但没有一句是他会说的话。他承认，改的时候不知不觉顺着模型的语气走了——本来想说的是A，模型写成B，读着也挺顺，就留下了。
这大概是「人机协作」里最容易被忽略的一层。讨论通常停在工具层面：提示词怎么写、接口怎么接、流程怎么嵌。这些当然要解决，但真正决定协作质量的，往往是更难量化的部分——人跟系统来回几轮之后，还剩下多少自己的判断。
当外包用，还是当同事用
两种用法的差别比想象中大。当下属用，人给指令、验收结果，责任清楚，但人的角色只剩下审稿，久了就退化成检查员。当同事用，就得接受它会提出你没想过的方向，也要接受它在你没注意的地方出错。前者省事，后者费神，而费神的那部分，恰恰是协作产生价值的地方。
还有第三种，我觉得更接近日常：当草稿纸用。草稿纸上写错了划掉就是，不必讲道理。模型能承担这个角色，因为它不会累、不会不耐烦，可以陪你把一个念头翻来覆去试十遍。这时人机协作的重心不在产出，而在试探——把模糊的想法逼成清楚的句子。
它给的是常见答案，你要的往往不是
语言模型的输出有个特点：倾向于落在训练分布里最常见的那一侧。这在多数场景下没问题，写得四平八稳，不容易出错。麻烦在于，很多工作真正的价值偏偏在少数一侧——一个不那么顺口但更准确的表述，一个不那么常规但更贴合实际的方案。
所以我会刻意保留一道工序：先自己写，再让模型改，然后逐句比对，凡是它改得更通顺但意思偏了的地方，全部退回。这一步很慢，也枯燥，但它守住的是一条界线——判断标准由谁定。
该交的交出去，不该交的留住
我大致会这样分：格式转换、信息归并、初筛、把散乱记录整理成条理，这些交出去，省下的时间很实在。而判断标准、最终确认、对外承诺，这三样留在人手里。不是因为机器做不好，而是因为出了问题，得有人能说清楚当初为什么这么做。
有个实操细节值得说：流程里最好明确标出复核点在哪里，谁在这个点上签字。不是为了追责，而是让「人」在环节里有一个具体位置。没有这个位置，人机协作很容易滑向另一种状态——人负责点确认，机器负责所有内容，表面上是配合，实际是空转。
回到开头那篇稿子。后来他重写了一版，只把模型当查漏的：写完让它挑逻辑断层，挑完自己改。慢了半天，但句子终于是他的了。这算不上什么方法论，只是一个普通使用者摸索出来的分寸：让工具靠近，但不让它替你做主。