企业官网建设流程全解析

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的组件。

映射关系大致是这样的：

人工审核节点在Spring AI里没有现成的组件，需要自己实现。我的做法是定义一个HumanApprovalService，它接收一个ApprovalRequest对象（包含上下文、选项、超时时间），返回一个ApprovalResult对象（包含选择、修改内容、审批人）。工作流引擎在需要人工审核的时候调用这个Service，Service负责发送通知、等待响应、处理超时。

public interface HumanApprovalService { ApprovalResult requestApproval(ApprovalRequest request); } public class ApprovalRequest { private String workflowId; private String nodeId; private Map<String, Object> context; private List<String> 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 人工节点的输出格式必须严格约束

人不像AI，AI你可以用提示词约束它的输出格式，人你只能用界面约束。如果人工节点的输出是一段自由文本，下游AI节点解析起来会很痛苦。

我的做法是，人工节点的输出尽量用结构化控件：下拉选择、单选按钮、复选框、数字输入框。如果确实需要自由文本，也要给它一个模板，让人按照模板填。比如修改建议的模板可以是“问题描述：；修改方向：；参考示例：___”。这样下游AI节点解析的时候，可以按字段提取，而不是猜。

5.3 审批人的权限和审计日志不能省

人工节点涉及到“人做决策”，那就必须回答两个问题：谁有权限做这个决策？决策过程有没有记录？

权限控制方面，不同的人工节点应该有不同的权限要求。比如“内容发布审批”可能只需要普通编辑权限，“金额超过10万的付款审批”就需要财务主管权限。在Spring AI里，你可以用Spring Security来做节点级别的权限控制。

审计日志方面，每次人工审批都应该记录：谁审批的、什么时候审批的、审批时的上下文是什么、选择了什么选项、有没有修改内容。这些日志不仅是合规要求，更是后续优化工作流的依据。你会发现某些审批人总是驳回某类内容，那说明上游AI的提示词需要调整。

5.4 人工节点的“假通过”问题

这是我最想强调的一个坑。人工审批节点用久了，审批人会开始“假通过”——不看内容直接点通过。这个问题在审批量大的时候特别严重。

解决“假通过”不能靠自觉，要靠机制。我试过几种方法，比较有效的是这几种：

第一种是“随机抽检”。系统随机抽取一定比例的审批记录，由另一个人复核。如果发现假通过，要有反馈机制。

第二种是“审批质量评分”。定期统计每个审批人的驳回率、修改率，如果某个审批人的驳回率长期为零，要么说明上游AI质量确实好，要么说明他在假通过。结合上游AI的质量指标一起看，就能判断出来。

第三种是“关键节点强制阅读”。对于特别重要的审批节点，可以设置一个最短阅读时间，比如审批界面打开后至少10秒才能点通过。这个时间足够人扫一眼关键信息。

6. 一个完整案例：内容生产工作流中的人类嵌入设计

6.1 工作流全貌与人工节点的位置选择

我拿一个实际跑过的内容生产工作流来拆解。这个工作流的任务是：根据热点话题生成一篇行业分析文章，发布到公司博客。

工作流的步骤是：

1. 热点抓取（AI自动）
2. 选题筛选（AI生成候选，人工选择）
3. 大纲生成（AI自动）
4. 大纲审核（人工审核）
5. 初稿生成（AI自动）
6. 事实核查（AI自动+人工校验）
7. 润色（AI自动）
8. 终审（人工审批）
9. 发布（自动）

这里面有三个人工节点：选题筛选、大纲审核、终审。事实核查是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、自己写引擎都可以。但设计上的核心只有一个——让人在正确的时间、以正确的方式、看到正确的信息，然后做一个正确的决定。这件事想清楚了，工作流就稳了。