人机协作：什么问题必须留给人拍板

企业引入 AI 后，争论常落在「能不能全自动」。更有用的问题是：哪些节点必须人签字。合同承诺、对外口径、安全操作、财务放行，这些节点若被模型悄悄越过，系统越能干，风险越大。

人机协作不是口号，是流程上的强制停顿：模型可以起草，人可以一键确认或驳回，驳回原因能回到题集与文档。

三类必须留给人的问题

第一，法律与承诺：对客报价、合同解释、赔偿责任。第二，安全与合规：可能造成人身或重大资产损失的步骤。第三，伦理与舆情：公开声明、人事处分相关表述。三类默认人工，不开放自动发送。

可以交给 AI 的，是草稿、检索、对照表、检查清单。人的时间应用在判断，而不是从零查找。

确认界面要展示依据与风险点，而不是只给一个巨大的「同意」。必要时强制打开引用。人对明显错误仍要点同意，说明界面设计失败或考核在逼速度。

人机协作的关键是人仍在负责任的位置上，而不是成为系统的点击器。

泛友设计流程时，会先问「出事谁签字」。签不清字的节点，不强行自动化。若业务希望全自动，先从低责任场景证明稳定。

若考核只看处理量，员工会盲确认。应把差错与抽检纳入，而不是只奖励更快。协作系统改的是组织，不只是模型。

定期复盘被驳回最多的问题类型，往往指向文档冲突或提示不当。这是改进清单，不是员工态度问题。

系统用服务账号调用业务接口时，仍要映射到发起人。出了事能追到人，而不是追到「机器人」。映射关系写入审计。

人对 AI 建议的修改要可统计。修改率过高，说明草稿无用；过低且差错高，说明盲确认。两个极端都要干预。

将「必须人工」清单贴进培训首周，而不是藏在长篇制度第十八章。清单越短越好记，越好执行。

围绕「人机协作：什么问题必须留给人拍板」，建议先写一页落地清单：目标用户、入口位置、冻结题数量、红线问题、周会指标与负责人。清单进项目章程后，讨论才不会反复回到功能点罗列。AI 科普类文章尤其要把「不做什么」写进清单，避免范围在实施中膨胀。

内容治理与系统治理分开。页面、制度或案例更新后，题集与检索同步更新；只改提示词，解决不了结构问题。建议建立双周变更窗：窗口内集中更新，窗口外保持稳定，便于对比「人机协作：什么问题必须留给人拍板」相关指标是否真的变好。

试点宁小勿大。先在一个团队证明指标可改善，再复制到下一团队。复制时连同红线、题集和负责人一起复制，而不是只复制界面。若第一队都跑不通，加模型规格很少能拯救「人机协作：什么问题必须留给人拍板」所描述的那类问题。

与供应商沟通时固定题集。题可以难，但必须可重复。用同一批题看版本差异，比每次换新题刷分更能反映真实进度。合同附件里写明题集保管人与及格线，能减少上线后的扯皮。

上线前四周把失败样例当成主要输入。平均分好看但同一类失败重复出现时，优先改文档、入口或权限。把失败样例归类为：内容缺失、权限过严、入口不便、模型越界。四类对应不同负责人，避免所有问题都甩给算法。

对外表述保持可验证。能写成「在某某条件下完成某某检查」的句子，就不要写成「全面赋能」。宣传与验收用语分离后，「人机协作：什么问题必须留给人拍板」才不会在客户处被理解成无限承诺。

安全、法务或合规同事应在方案阶段介入，而不是上线前一天。涉及对外口径或数据驻留时，早期否决比事后补救便宜。介入产出应是一页约束，而不是一本看完即搁置的手册。

为关键资产指定主责与备责。文档、题集、索引、话术都要有第二负责人，避免请假或离职后「人机协作：什么问题必须留给人拍板」相关能力停摆。名单贴在周报抬头，比放在通讯录深处更有效。