大模型与人类协作的工作流设计，本质是把机器的生成能力和人的判断能力放到合适的环节，用系统化的流程减少彼此的短板。很多团队在接入大模型时，习惯把用户请求直接丢给模型，拿到回答就返回，这种做法在简单问答里可行，一旦涉及业务决策、内容发布或数据处理，就会暴露出幻觉、格式漂移和合规风险。合理的设计思路是先拆任务，再定边界，最后用调度逻辑把人和模型黏起来。
任务切分与角色边界界定
在协作工作流里，第一步不是选模型，而是把目标业务拆成原子任务。原子任务分为三类：生成类、判断类、执行类。生成类如写文案、抽摘要、产代码草稿，这类任务模型完成度高，可交给大模型；判断类如是否合规、是否采纳建议、优先级排序，这类需要领域知识和责任主体，必须由人完成；执行类如写数据库、发消息，需用确定程序做，不能让模型直接操作。
边界界定要用明确规则写下来，而不是靠工程师口头约定。比如客服工单系统，模型可自动生成回复草稿并打上置信度标签，但当置信度低于零点六或命中敏感词时，流程必须挂起转人工。这样人只处理少数难例，大部分常规回复由模型预填，人工只需点确认，效率提升明显。若把边界模糊化，让人去改模型每句话，协作成本反而比纯人工更高。
角色边界还应考虑失败兜底。当模型服务超时或返回空，工作流要有默认分支走人工通道或返回友好提示。我们在设计时要假设模型会出错，把人工作为常驻兜底而不是临时补充。用配置表管理各类任务的负责人与模型职责，后期调整不用改代码，只需改配置。
分层调度与状态机实现
协作流程的调度核心是一个状态机，每个任务实例有状态如待生成、待人工审、已发布、已驳回。大模型节点输出后，根据后处理脚本决定下一状态。下面用 Python 伪代码展示一个最小状态机如何处理模型与人的交接。
class Workflow:
def __init__(self):
self.state = "pending_gen"
def model_generate(self, text):
# 调用大模型得到草稿与置信度
draft = call_llm(text)
score = get_confidence(draft)
if score < 0.6:
self.state = "wait_human"
else:
self.state = "auto_ready"
return draft
def human_review(self, approve):
if self.state != "wait_human":
return
if approve:
self.state = "published"
else:
self.state = "rejected"
def call_llm(t):
return "草稿内容"
def get_confidence(d):
return 0.55
上面的代码把模型生成和人工审核拆成两个方法，状态字段控制流转。实际系统里可把状态存到数据库，用消息队列解耦服务。人工审核界面读取待办，点通过或驳回，回调接口改状态。这种结构让人和模型通过状态间接协作，避免强耦合。
分层调度还包括前置提示模板层。我们用统一模板约束模型输出 JSON 结构，后置用规则引擎校验字段类型和必填项。若校验失败，直接转人工而非重试模型，因为格式错误往往源于需求歧义，人改需求比模型猜更可靠。通过三层拦截，系统稳定性显著提高。
质量校验与持续改进机制
协作工作流上线后，必须采集人工操作日志来反哺提示词和阈值。我们记录每条任务人工是确认还是大改，统计各类任务的模型一次通过率。若某类任务通过率低于五成，说明提示词或边界划分有问题，需重构模板或改为全人工。
质量校验可分自动与人工两部分。自动部分用单元测试式断言，比如输出不能含个人隐私字段、长度在区间内。人工部分用抽检而非全检来降本，抽检比例按风险等级设，高风险全检，低风险抽十 percent。下表给出某内容平台的风险分级与对应策略。
| 风险等级 | 模型职责 | 人工策略 |
|---|---|---|
| 高 | 仅出草稿 | 百分百审核 |
| 中 | 草稿加置信度 | 低于阈值转人工 |
| 低 | 自动发布 | 抽捡百分之十 |
持续改进还要建立反馈回路，把人工驳回的原因写成结构化标签，如格式错、事实错、违规。月度聚合这些标签，针对性改提示词或加校验规则。我们曾因事实错误标签集中，就在前置加检索增强，模型先查知识库再答，人工驳回率降了四成。
最后要注意工作流的可观测性。每个任务留 trace 信息，包含模型版本、提示词哈希、耗时、人工耗时。当效果退化时，能快速定位是模型升级引入还是业务变更。把人和模型的协作当成可度量系统，而非黑盒，才能长期稳定运行。
large_language_modelhuman_in_the_loopworkflow_design修改时间：2026-08-15 23:48:18