电商退换货决策流需先明确用户输入、外部数据源及结构化输出字段，再通过dify工作流配置llm初判、知识库兜底、http调用与条件分支节点，确保变量流转完整、安全合规并覆盖异常场景。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让AI自动判断买家提交的退换货请求是否符合规则、该走哪个处理通道、要不要人工介入——而不是每次都要客服翻手册查政策、手动比对订单状态、再复制粘贴回复话术。
梳理退换货业务逻辑并拆解为节点任务
先打开Dify工作流画布，新建一个Workflow类型应用，名称设为“电商退换货决策流”。不要直接拖节点，先在纸上或文档里写下三件事：用户输入是什么（如“衣服洗后缩水，要退货”）、系统能拿到哪些外部数据（订单状态、商品类目、下单时间、物流签收时间）、最终必须输出哪几项（是否可退、原因编码、预计退款金额、是否转人工）。这一步漏掉任何一个字段，后面变量流转就会断掉。
对照你写的清单，在Dify左侧节点栏里勾选可用能力：开始节点（接收用户原始消息）、LLM节点（做意图+规则判断）、知识库检索节点（查《退换货政策V3.2》文档）、HTTP节点（调用订单中心API查status字段）、条件分支节点（判断“签收时间＞7天”是否成立）、结束节点（输出JSON结构化结果）。【知识库文档必须提前上传并完成向量化，否则检索节点永远返回空】
配置关键节点与变量流转路径
方法一：用LLM节点做主判断
拖入一个LLM节点，命名为“规则解析与初判”。在提示词中明确写死判断维度：“仅根据以下四点输出JSON：1.是否满足退货基础条件（已签收且未超7天）；2.是否属于禁退类目（内衣、定制类、拆封影响二次销售）；3.用户描述是否含‘质量问题’关键词；4.订单支付方式是否支持原路退回”。输入变量设为{{sys.input}}，输出变量绑定为{{judgement_result}}。这一步不能依赖模型自由发挥，必须用强约束格式锁定输出结构。
方法二：用条件分支+知识库组合兜底
当LLM节点输出的“原因编码”为“POLICY_AMBIGUOUS”时，触发条件分支跳转到知识库检索节点。检索关键词固定为“{{judgement_result.reason_code}}+执行细则”，知识库切片需提前标注段落ID，比如“#RETURN_7DAY_WINDOW”“#CATEGORY_EXCLUSION_LIST”。检索后接另一个LLM节点做摘要生成，只提取条款原文中的时间、类目、例外情形三类信息，避免模型编造。
注意：HTTP节点调订单API时，务必在Headers里填入Authorization: Bearer {{env.ORDER_API_TOKEN}}，这个环境变量要在Dify后台→设置→环境变量中预先配置好，【明文写在提示词里会导致Token泄露】。
联调验证与异常分支注入
第一步：用测试输入模拟边界场景
在画布右上角点击“调试”，输入三组典型case：①“刚收到就发现破洞，申请退货”（应走极速退款通道）；②“下单15天后说尺码不合适”（应拒退并提示超期）；③“没拆封但要求换同款颜色”（需查库存API再决定）。观察每个节点右侧的实时输出面板，确认{{judgement_result.is_eligible}}布尔值、{{judgement_result.refund_amount}}数字、{{judgement_result.handover_to_human}}开关量是否与预期一致。
第二步：强制触发失败路径
在HTTP节点设置“超时=3s→重试次数=1→失败后跳转至‘人工兜底’分支”。该分支连接一个固定回复节点，内容为“当前订单状态查询异常，请稍后重试或联系在线客服”，并自动记录日志字段{"error_type":"ORDER_API_TIMEOUT","order_id":"{{sys.input.order_id}}"}。这一步不做，线上遇到网络抖动就会卡死整个流程。
第三步：发布前关闭调试模式
进入发布设置页，取消勾选“启用调试日志”，将工作流状态从“草稿”切换为“已发布”。此时Dify会生成唯一Workflow ID和调用密钥，供订单系统通过POST /v1/workflows/{id}/run 接口传入JSON载荷。
