把一项任务交给模型，往往只需要一个接口；让它稳定地参与一段业务流程，麻烦才刚开始。演示时顺畅，进入日常运行后却常卡在几个小问题：输出之后谁来确认，出了问题谁来回退，异常单子怎样重新进入流程。人机协作的难点，通常藏在这些衔接处。
先问谁收尾，再问谁执行
我倾向于把自动化拆成两段：机器承担可重复的生成、提取、分类和初筛；人保留对模糊情境的判断、对后果的确认，以及对流程的收尾。只讨论机器能做什么，容易漏掉一个基本问题——任务完成后，责任落在哪里。如果界面没有标明哪些内容由模型生成、哪些字段需要人工复核，使用者就会在“看起来已经完成”和“其实还没确认”之间摇摆。人机协作不是把按钮做得显眼，而是把交接动作设计清楚。
可操作的做法，是把流程节点分成三类：机器独立处理且可回退的、机器提出建议由人确认的、必须由人发起再交给机器辅助的。分类不必复杂，但要写进操作界面和日志里。它的价值在于让使用者知道什么时候可以往前走，什么时候需要停下来检查。
过程看得见，交接才稳
有些系统喜欢把过程藏起来，只给一个结果。对简单问答也许无妨，对需要协作的业务流程却不够。人需要看到机器做了什么：调用了哪些信息、依据什么规则、哪些地方不确定。可见性不是把技术细节全部摊开，而是让关键判断有迹可循。比如生成对外文字时，标出需要人工核对的实体和承诺性表述；整理记录时，保留原始来源的入口。这样人才能把注意力放在真正需要判断的地方。
这也解释了为什么有些智能功能上线后使用率不高。问题未必在模型能力，而在使用者无法判断结果能不能直接用。人机协作要降低的是反复确认和返工带来的心理负担。界面上多一句“此处建议复核”，日志里多一条“由谁在何时确认”，往往就够用。
边界要写成规则
谈协作，容易停在“各展所长”这类说法上。落到日常，它需要被写成几条朴素规则：哪些操作必须留痕；哪些输出不能直接对外；异常发生时由谁暂停流程；模型更新后哪些环节要重新验证。规则不必一次写全，但要能随流程变化被修订。我的判断是，稳定的人机协作像一套工作制度，而不是一个单独的功能模块。它需要产品、业务和一线使用者共同维护，否则顺滑的演示也会在真实流程里露出缝隙。
- 把机器建议和人工确认在界面上分开，避免把草稿当成终稿。
- 为关键输出保留来源和修改记录，方便回看与交接。
- 给异常处理留一个明确入口，让人可以暂停、退回或转交。
这些做法不新，却常被忽略。人机协作真正考验的，是组织愿不愿意承认机器会出错，也愿不愿意给人留下纠正的空间。把边界谈清楚，机器才能进入流程深处，而不是停在演示屏上。