跳到主要内容

人在回路不是妥协，而是系统设计的一部分

· 阅读需 4 分钟
一介布衣
一介布衣
全栈开发者 / 技术写作者

补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-10-24 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。

很多团队一开始做 AI 系统时，会把“人在回路”理解成一种过渡方案：

  • 现在模型还不够好，所以先让人兜着
  • 等以后模型更强，就把人拿掉

我以前也有点这样想。后来做的系统越来越多，反而越来越不这么看了。
我现在更倾向于认为：人在回路不是妥协，而是很多 AI 系统天然就该有的一层设计。

因为很多业务问题本来就不是“把人替掉”才算成功，而是“把人的注意力放到真正值得判断的地方”才算成功。

为什么它不该被理解成临时补丁​

因为很多场景里，人本来就在承担三种机器很难完全替代的职责：

1. 风险兜底​

例如：

  • 审核中的边界判断
  • 高价值工单升级
  • 影响业务责任的最终确认

2. 规则更新来源​

很多系统后面的改进，不是来自模型自己变聪明，而是来自人不断纠正：

  • 哪些样本错了
  • 为什么错
  • 哪类情况应该转人工
  • 哪些规则需要改写

3. 责任归属锚点​

当系统输出开始影响真实业务动作时，组织通常需要一个明确的责任落点。
人在回路，很多时候也是治理结构的一部分。

真正该设计的，不是“要不要人”，而是“人出现在哪”​

这件事我现在会分得很清楚。
人不该到处出现，否则系统只是把自动化改成了半自动化体力活；
但人也不该彻底消失，否则系统会在关键边界上失去治理能力。

我更常用的做法是把节点分成三类：

第一类：机器直出即可​

例如：

  • 低风险摘要
  • 样板生成
  • 普通分类打标

第二类：机器先做，人做抽样或边界复核​

例如：

  • 内容审核初筛
  • 知识问答候选生成
  • 客服建议回复

第三类：机器只能给建议，人必须做最终决策​

例如：

  • 高风险升级
  • 合规审批
  • 对外发布
  • 影响财务或法律责任的动作

这样“人在回路”就不再是一句口号，而是一张责任分层图。

一个我现在很看重的设计原则​

人审节点的目标，不该是把机器做过的事再做一遍。
它应该尽量让人只看：

  • 高风险样本
  • 模型不确定样本
  • 明显冲突样本
  • 价值特别高的样本

也就是说，人应该被放在“判断最值钱的地方”，而不是“系统哪里不自信就全塞给人”。

怎么让人在回路不变成人在背锅​

这是另一层很重要的问题。
很多系统虽然加了人工节点，但设计得并不好：

  • 没有给出结构化理由
  • 没有展示关键证据
  • 没有标出模型不确定点
  • 最后只是把一大段文本扔给审核人

这时候人工节点不是治理，而是把复杂度转移给人。

我现在更喜欢让模型给出：

{
  "decision": "needs_human_review",
  "riskLevel": "high",
  "reasonCodes": [
    "policy_boundary_case",
    "confidence_low"
  ],
  "evidence": [
    "contains financial promise",
    "matches sensitive phrase pattern"
  ]
}

这样人接手时，不是从零开始判断，而是在一个被结构化后的上下文里判断。

人在回路还有一个常被低估的价值：数据闭环​

人工节点如果设计得好，后面会变成系统最宝贵的数据来源之一。
因为你可以从中沉淀：

  • 被纠正最多的错误类型
  • 最常见的边界情况
  • 哪些规则总在人工阶段被推翻

这些信息会反过来决定：

  • 评测集怎么扩
  • Prompt 怎么改
  • 路由怎么调
  • 哪些场景以后可以更自动化

所以人审不是只在“兜错”，它也在“喂回系统”。

总结​

人在回路不是妥协，而是系统设计的一部分。因为很多 AI 系统真正要优化的，不是把人完全拿掉，而是把人从低价值重复劳动里解放出来，放到高风险、高价值、需要责任判断的节点上。

只要这层想清楚了，人机协作就不是一个尴尬的过渡状态，而是一种更成熟、更现实的产品结构。