1. 为什么“人类嵌入AI工作流”不是把AI当工具而是把自己变成节点大多数人第一次接触AI工作流脑子里想的都是“怎么让AI帮我干活”。这个思路本身没错但它有个隐藏前提你是发号施令的人AI是执行的人。实际跑过几轮之后你会发现这个前提根本不成立。AI执行到一半卡住了你得进去补上下文AI输出格式不对你得手动调AI把两个步骤的顺序搞反了你得重新编排。你以为自己在指挥其实你在给AI擦屁股。“人类嵌入AI工作流”这个说法核心翻转就在这里不是AI嵌入你的工作而是你嵌入AI的工作流。你不再是那个站在流水线外面按按钮的人你是流水线上的一个工位。这个工位有明确的输入、明确的输出、明确的触发条件以及明确的超时处理逻辑。听起来有点反直觉但恰恰是这种视角转换决定了你搭出来的工作流是能跑三天还是能跑三年。我最早做AI工作流的时候犯过一个特别典型的错误把所有环节都交给AI自己只在最后验收。结果就是前面AI生成的内容一旦有偏差后面所有步骤全部跟着歪等到我发现的时候已经积累了十几步的垃圾数据。后来我把自己的角色重新定义了一下——不是“验收员”而是“关键路径上的一个处理节点”。哪些节点必须由人来判断哪些节点可以完全交给AI哪些节点需要人机交替这个分工想清楚了工作流才真正稳定下来。这篇文章适合两类人看。一类是已经在用Dify、Coze或者类似平台搭工作流但总觉得“跑起来容易、跑稳定难”的实践者另一类是有开发背景想把AI工作流从原型推进到生产环境但不确定人的介入点应该放在哪里的工程师。我会从节点设计、触发机制、异常处理、代码落地几个角度把“人类嵌入”这件事拆开讲清楚。2. 人类节点的四种嵌入模式从审批到共创的粒度选择2.1 审批型嵌入最轻但最容易设计错的模式审批型嵌入是最直觉的一种——AI跑完一个步骤人看一眼点个“通过”或者“驳回”。听起来简单但实际设计的时候大部分人会把审批点放错位置。我见过一个很典型的案例有人搭了一个内容生成工作流流程是“选题→大纲→初稿→润色→发布”他在“发布”前面加了一个人工审批。这个设计的问题在于如果初稿方向就偏了等到发布前才审批前面四步全部白跑。审批点应该放在“不可逆决策”之前而不是“最终输出”之前。什么叫不可逆决策选题定了之后后面所有内容都围绕它展开这就是不可逆的。大纲定了之后初稿的结构就锁死了这也是不可逆的。发布本身反而是可逆的——发错了可以删可以改。所以审批型嵌入的正确姿势是找到工作流中那些“一旦确定就很难回头”的节点把人的判断放在那里。具体操作上你可以在Dify的工作流里插入一个“人工审核”节点配置好上游传来的上下文让人在审批的时候能看到足够的信息来做判断。不要只给一个“通过/驳回”的按钮要给审批人看到上游AI的推理过程、置信度、以及如果驳回的话建议的修改方向。注意审批型嵌入最大的坑是“审批疲劳”。如果工作流里塞了太多审批点人会开始无脑点通过审批就失去了意义。我的经验是一条工作流里的人工审批点不要超过三个而且每个审批点都必须有明确的判断标准不能是“你觉得行就行”。2.2 补全型嵌入AI卡住的时候人进去填坑补全型嵌入解决的是一个很现实的问题AI不是万能的有些信息它拿不到有些判断它做不了。比如你让AI根据客户邮件生成回复但客户邮件里提到了一个只有你们内部系统才有的订单号AI查不到这个订单的状态它就卡住了。这时候需要人进去把订单状态查出来填进工作流的上下文里然后让AI继续跑。这种嵌入模式的关键在于“上下文传递”。人填进去的信息必须以结构化的形式注入到工作流的状态里而不是以一段自然语言的形式丢进去。我见过有人直接在对话框里打一段话“这个订单已经发货了”然后让AI继续。这样做的问题是AI对这段自然语言的理解是不稳定的它可能理解成“已发货”也可能理解成“需要发货”。正确的做法是在工作流里定义一个字段叫order_status人填的时候选择枚举值已发货/未发货/已签收然后AI在后续步骤里直接引用这个字段。在Dify里你可以用“变量赋值”节点来实现这个逻辑。上游AI节点输出一个“需要人工补全”的信号工作流暂停人在界面上填写变量值工作流恢复后续节点读取这个变量。整个链路是确定的不依赖AI对自然语言的二次理解。2.3 校验型嵌入人作为质量守门员校验型嵌入和审批型嵌入的区别在于审批是“决定要不要继续”校验是“检查输出是否符合规格”。审批关注的是方向校验关注的是质量。举个例子你让AI从一份合同里提取关键条款输出格式是JSON。AI确实输出了JSON但字段名可能不对日期格式可能不对金额单位可能不对。这些错误AI自己检查不出来因为它不知道自己错了。这时候需要人来做校验——不是逐字逐句看而是用一套检查清单快速过一遍。校验型嵌入的设计要点是“检查清单前置”。你不能让人凭感觉去校验你得给他一个明确的清单字段名是否匹配日期格式是否为YYYY-MM-DD金额是否包含货币单位每个检查项都是二值的通过/不通过这样校验效率才高而且不同的人来做校验结果是一致的。我自己的做法是在工作流里维护一个“校验规则表”每个规则对应一个校验函数。人做校验的时候系统自动跑一遍规则把不通过的项高亮出来人只需要看不通过的那些。这样能把校验时间从几分钟压缩到几秒钟。2.4 共创型嵌入人和AI交替输出的模式共创型嵌入是四种模式里最复杂的一种但也是价值最高的一种。它不是“AI做完人改”也不是“人做完AI改”而是人和AI在一个步骤里交替输出互相激发。典型的场景是方案设计。AI先出一个初版方案人看了之后不是直接改而是给AI一个反馈——“第二部分的逻辑不对应该先讲成本再讲收益”AI根据这个反馈重新生成第二部分人再看再给反馈。如此交替几轮直到方案成熟。这种模式对工作流引擎的要求比较高因为它是“循环”而不是“线性”的。在Dify里你可以用“循环”节点来实现设置一个最大循环次数比如5次每次循环里包含一个AI生成节点和一个“人工反馈”节点。人工反馈节点接收人的输入作为下一轮AI生成的上下文。提示共创型嵌入最容易失控的地方是“循环终止条件”。如果不设最大次数人和AI可能会无限交替下去。我的经验是最多5轮5轮之后如果还没达成一致说明问题不在方案本身而在目标定义上应该退回去重新对齐目标。3. 触发时机比触发方式更重要人类节点该在什么时候亮起来3.1 基于置信度的触发让AI自己说“我不确定”AI模型有一个很有用的特性它可以输出置信度。虽然这个置信度不是严格统计学意义上的概率但在实际使用中它确实能反映AI对某个输出的“把握程度”。你可以利用这个特性让AI在置信度低于某个阈值的时候自动触发人工介入。具体怎么做在AI节点的提示词里加一句“对于每个输出字段给出一个0到1之间的置信度分数。如果某个字段的置信度低于0.7在输出中标记needs_human_review: true。”然后工作流里加一个条件判断节点检查这个标记如果为true就暂停并通知人。这个方法的坑在于AI有时候会“过度自信”——它明明在瞎编但置信度给得很高。所以你不能完全依赖AI自报的置信度还得结合其他信号。比如如果AI的输出和上游输入之间存在明显的逻辑断裂或者AI在输出里用了“可能”“大概”“据我所知”这类模糊词即使置信度很高也应该触发人工审核。3.2 基于规则引擎的触发用确定性逻辑兜底置信度触发是概率性的规则引擎触发是确定性的。两者应该配合使用。规则引擎负责处理那些“明确知道会出问题”的场景置信度负责处理那些“不确定会不会出问题”的场景。规则引擎的规则怎么写举几个我实际用过的例子如果AI输出的JSON解析失败触发人工介入如果AI输出的文本长度超过上游输入长度的3倍触发人工介入可能是AI在胡编如果AI输出中包含预设的敏感词列表中的任何一个词触发人工介入如果AI连续两次输出相同的内容触发人工介入可能是陷入了循环这些规则不需要很复杂但必须覆盖那些“一旦发生就会导致严重后果”的场景。规则引擎的好处是它的行为是完全可预测的不会像AI那样偶尔抽风。3.3 基于时间窗口的触发什么时候该让人看一眼有些工作流是定时跑的比如每天早上生成一份日报。这种场景下人工介入的触发时机应该是“生成完成之后、发送之前”。但如果是实时工作流比如客服自动回复人工介入的触发时机就应该是“AI生成回复之后、发送之前”而且时间窗口要很短最好在几秒之内。时间窗口的设计要点是“给人工介入留出足够的时间但不影响整体流程的时效性”。我的做法是对于实时性要求高的场景人工介入采用“异步通知超时自动通过”的策略。也就是说AI生成回复后系统通知人工审核但如果30秒内没有人审核就自动发送或者自动转人工客服。这样既保证了时效性又给了人介入的机会。4. 把人类节点写进代码从Dify工作流到Spring AI的落地路径4.1 Dify工作流里的人工节点配置细节Dify的工作流引擎支持“人工审核”节点但这个节点的默认配置比较简陋只有“通过/驳回”两个选项。实际用的时候你需要做几件事来增强它。第一配置上游上下文。在人工审核节点的“输入变量”里把上游AI节点的输出、上游输入、以及任何相关的上下文都传进来。这样审批人看到的不只是一个孤零零的输出而是完整的决策上下文。第二配置审批选项。Dify允许你自定义审批选项不要只用“通过/驳回”可以加“通过但修改”“驳回并附修改建议”等选项。每个选项对应不同的下游分支。第三配置超时处理。人工审核节点可以设置超时时间超时后自动走某个分支。这个功能很重要否则工作流会一直卡在那里等人。第四配置通知渠道。Dify支持通过Webhook发送通知你可以把通知发到企业微信、钉钉或者邮件里让审批人及时知道有东西需要处理。4.2 从Dify工作流导出到Spring AI Java代码的映射逻辑Dify工作流可以导出为JSON但JSON不是可执行的代码。如果你想把工作流迁移到自己的Java应用里需要把JSON里的节点映射成Spring AI的组件。映射关系大致是这样的Dify节点类型Spring AI对应组件说明LLM节点ChatClient调用用ChatClient.prompt()构建请求知识库检索节点VectorStore.similaritySearch()检索增强生成条件判断节点自定义Router根据条件选择下游分支人工审核节点自定义HumanInTheLoop组件暂停工作流等待人工输入变量赋值节点上下文对象赋值把值写入工作流上下文循环节点递归或循环调用注意设置最大循环次数人工审核节点在Spring AI里没有现成的组件需要自己实现。我的做法是定义一个HumanApprovalService它接收一个ApprovalRequest对象包含上下文、选项、超时时间返回一个ApprovalResult对象包含选择、修改内容、审批人。工作流引擎在需要人工审核的时候调用这个ServiceService负责发送通知、等待响应、处理超时。public interface HumanApprovalService { ApprovalResult requestApproval(ApprovalRequest request); } public class ApprovalRequest { private String workflowId; private String nodeId; private MapString, Object context; private ListString options; private Duration timeout; } public class ApprovalResult { private String selectedOption; private String modifiedContent; private String approver; private boolean timedOut; }4.3 人工节点的状态持久化工作流暂停之后怎么恢复工作流暂停等人审批的时候状态必须持久化。否则如果服务重启工作流就丢了。Dify自己会处理状态持久化但如果你自己用Spring AI实现就需要自己处理。我的做法是用一张workflow_pause_state表来存暂停状态CREATE TABLE workflow_pause_state ( id BIGINT PRIMARY KEY AUTO_INCREMENT, workflow_id VARCHAR(64) NOT NULL, node_id VARCHAR(64) NOT NULL, context_json TEXT NOT NULL, options_json TEXT NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, expires_at TIMESTAMP, status VARCHAR(16) DEFAULT PENDING );工作流暂停时把上下文序列化成JSON存进去。人工审批完成后根据workflow_id和node_id把状态读出来恢复工作流。超时的话用一个定时任务扫描expires_at过期的记录自动走超时分支。注意上下文序列化的时候要注意版本兼容性。如果工作流定义变了旧的暂停状态可能无法恢复。我的经验是在上下文里加一个workflow_version字段恢复的时候检查版本是否匹配不匹配就走异常处理流程。5. 人类嵌入工作流之后那些没人告诉你的坑5.1 人的响应时间是不确定的工作流设计必须容忍这一点AI节点的执行时间是毫秒级的人的响应时间是分钟级甚至小时级的。这个时间差会导致一个很隐蔽的问题工作流的上游数据可能已经过期了。举个例子你有一个工作流是“监控库存→生成补货建议→人工审批→下单”。AI监控到库存低于阈值生成补货建议然后等人审批。如果人过了两个小时才审批这两个小时里库存可能已经被人手动补了或者销售出去更多了。审批的时候看到的库存数据已经不准了。解决这个问题有两种思路。一种是在人工审批节点重新拉取最新数据确保审批人看到的是当前状态。另一种是在审批通过之后、执行下单之前再做一次校验如果数据变化超过阈值就重新走一遍流程。我倾向于两种都用审批时展示最新数据执行前再做一次快速校验。5.2 人工节点的输出格式必须严格约束人不像AIAI你可以用提示词约束它的输出格式人你只能用界面约束。如果人工节点的输出是一段自由文本下游AI节点解析起来会很痛苦。我的做法是人工节点的输出尽量用结构化控件下拉选择、单选按钮、复选框、数字输入框。如果确实需要自由文本也要给它一个模板让人按照模板填。比如修改建议的模板可以是“问题描述修改方向参考示例___”。这样下游AI节点解析的时候可以按字段提取而不是猜。5.3 审批人的权限和审计日志不能省人工节点涉及到“人做决策”那就必须回答两个问题谁有权限做这个决策决策过程有没有记录权限控制方面不同的人工节点应该有不同的权限要求。比如“内容发布审批”可能只需要普通编辑权限“金额超过10万的付款审批”就需要财务主管权限。在Spring AI里你可以用Spring Security来做节点级别的权限控制。审计日志方面每次人工审批都应该记录谁审批的、什么时候审批的、审批时的上下文是什么、选择了什么选项、有没有修改内容。这些日志不仅是合规要求更是后续优化工作流的依据。你会发现某些审批人总是驳回某类内容那说明上游AI的提示词需要调整。5.4 人工节点的“假通过”问题这是我最想强调的一个坑。人工审批节点用久了审批人会开始“假通过”——不看内容直接点通过。这个问题在审批量大的时候特别严重。解决“假通过”不能靠自觉要靠机制。我试过几种方法比较有效的是这几种第一种是“随机抽检”。系统随机抽取一定比例的审批记录由另一个人复核。如果发现假通过要有反馈机制。第二种是“审批质量评分”。定期统计每个审批人的驳回率、修改率如果某个审批人的驳回率长期为零要么说明上游AI质量确实好要么说明他在假通过。结合上游AI的质量指标一起看就能判断出来。第三种是“关键节点强制阅读”。对于特别重要的审批节点可以设置一个最短阅读时间比如审批界面打开后至少10秒才能点通过。这个时间足够人扫一眼关键信息。6. 一个完整案例内容生产工作流中的人类嵌入设计6.1 工作流全貌与人工节点的位置选择我拿一个实际跑过的内容生产工作流来拆解。这个工作流的任务是根据热点话题生成一篇行业分析文章发布到公司博客。工作流的步骤是热点抓取AI自动选题筛选AI生成候选人工选择大纲生成AI自动大纲审核人工审核初稿生成AI自动事实核查AI自动人工校验润色AI自动终审人工审批发布自动这里面有三个人工节点选题筛选、大纲审核、终审。事实核查是AI自动加人工校验的混合节点。为什么选这三个位置选题筛选是“方向性决策”一旦选定后面所有内容都围绕它展开不可逆。大纲审核是“结构性决策”大纲定了初稿的结构就锁死了。终审是“合规性决策”发布之前必须有人确认内容没有问题。6.2 每个节点的输入输出规格定义选题筛选节点的输入是AI生成的10个候选选题每个选题包含标题、热度分数、关联关键词。输出是选中的1个选题以及选择理由可选。这个节点的界面是一个列表每个选题旁边有“选择”按钮选中后可以填写理由。大纲审核节点的输入是AI生成的大纲包含三级标题和每部分的要点。输出是“通过”或“修改”如果修改需要填写修改意见。这个节点的界面是大纲的树形展示每个节点旁边有“编辑”按钮可以直接修改。终审节点的输入是润色后的终稿以及前面所有步骤的上下文选题、大纲、事实核查结果。输出是“发布”或“退回”如果退回需要选择退回步骤。这个节点的界面是文章的预览旁边有上下文面板。6.3 异常情况的处理AI跑偏了人怎么拉回来这个工作流跑的过程中最常见的异常是“AI跑偏”。比如大纲审核通过了但初稿生成的时候AI理解错了大纲的意思写出来的内容和大纲对不上。处理这种情况的机制是“事实核查节点”的双重检查。AI先自动核查一遍检查初稿中的事实性陈述是否和大纲一致、是否有明显错误。如果AI核查发现不一致自动触发人工校验。人工校验的时候界面会并排展示大纲和初稿不一致的地方高亮显示人可以选择“以大纲为准”或“以初稿为准”或“手动修改”。这个机制的关键是“并排展示”。如果只给人看初稿人很难发现它和大纲不一致。并排展示之后不一致的地方一目了然。6.4 运行三个月后的数据反馈与调整这个工作流跑了三个月之后我统计了一下数据选题筛选节点平均耗时2分钟大纲审核节点平均耗时8分钟终审节点平均耗时5分钟。人工节点的总耗时占整个工作流耗时的90%以上。这个数据说明什么说明人工节点是瓶颈。但你不能简单地“去掉人工节点”因为去掉之后质量会下降。正确的做法是优化人工节点的效率。我做了两件事。第一把大纲审核节点的界面从“树形展示”改成“逐段展示”每次只展示一个部分审核完一个再展示下一个。这样审核人的注意力更集中平均耗时从8分钟降到了5分钟。第二把终审节点的上下文面板做了折叠默认只展示关键信息需要的时候再展开。这样终审的平均耗时从5分钟降到了3分钟。这两个调整看起来很小但效果很明显。人工节点的效率提升直接拉高了整个工作流的吞吐量。7. 关于人类嵌入AI工作流我踩过的最值钱的两个教训第一个教训是不要试图用AI来替代人的判断要用AI来放大人的判断。我早期做过一个工作流试图让AI自动决定选题结果AI选出来的选题要么太泛要么太偏阅读量一直上不去。后来改成AI生成候选、人来选阅读量立刻翻了一倍。AI擅长的是“生成可能性”人擅长的是“在可能性中做选择”。把这两件事混在一起做两边都做不好。第二个教训是人工节点的设计要“反人性”。什么意思人的天性是偷懒的如果审批界面做得很复杂人就会草草了事。所以人工节点的设计要尽量降低认知负荷——该折叠的折叠该高亮的的高亮该给默认值的给默认值。我见过一个审批界面把所有上下文都平铺展示结果审批人根本不知道看哪里。后来改成“关键信息置顶次要信息折叠”审批质量立刻上去了。这两个教训归结成一句话人类嵌入AI工作流不是技术问题是设计问题。技术上的实现方式有很多种Dify、Spring AI、自己写引擎都可以。但设计上的核心只有一个——让人在正确的时间、以正确的方式、看到正确的信息然后做一个正确的决定。这件事想清楚了工作流就稳了。