把AI退款决策打上标签存成可检索的执行记录

原文要点

n8n官方Production AI Playbook审计章节的第二个练习：Webhook接收orderId、customerTier、message，Order Lookup返回虚构订单，Policy Decision（Edit Fields节点）算出refund_approved、refund_declined或needs_human_review，If节点检查标签超过255字符即走Stop and Error，Execution Data节点把案例与最终决定存为自定义执行数据，OpenRouter的openai/gpt-4.1-mini（可换任意聊天模型）生成解释。三条测试单ORD-1001/1002/9999分别对应三种结果。按自定义数据筛选执行列表需n8n Cloud Pro或Enterprise，订单全为合成数据不涉真实支付。

这次做成什么

在n8n里搭一个可回查的AI退款判定练习流：外部POST进单，工作流给出三选一结论，把结论作为自定义执行数据写入，日后打开某次执行就能看到当时的判定依据。下方政策映射和回复文案是本站独立设计的练习方案，可整体替换。

准备什么

• n8n Cloud账号或可登录的自托管n8n实例
• 一个OpenRouter API密钥（在n8n中新建OpenRouter凭据）
• 能向Webhook测试URL发送POST请求的工具，如curl或Postman
• （可选）n8n Cloud Pro或Enterprise，用于按自定义数据筛选执行列表

具体怎么做

1. 导入模板并挂接凭据

   从n8n模板库打开该工作流并导入，找到OpenRouter - Support凭据位，填入你的OpenRouter API Key；模型默认openai/gpt-4.1-mini，预算紧可换成OpenRouter上其他便宜聊天模型。

2. 确认政策映射

   打开Policy Decision（Edit Fields节点），它按订单记录输出refund_approved、refund_declined或needs_human_review。理解映射逻辑后，决定是沿用演示政策还是改成本站下方给的政策配置。

3. 用三条测试单各跑一次

   点Execute workflow，向Webhook测试URL分别POST ORD-1001、ORD-1002、ORD-9999三条数据，每次发送前先重新点Execute workflow。预期三次结论依次为通过、拒绝、转人工。

4. 检查超长标签拦截

   按模板中Check Tag Length节点实际检查的字段，构造一条使标签值超过255字符的请求，确认If节点把流程导到Reject Oversized Tag（Stop and Error），执行记录显示为错误而不是继续判定。

5. 打开执行记录核对自定义数据

   进入Executions列表，逐条打开刚才的执行，查看Tag Execution与Record Decision写入的自定义数据是否包含订单号、客户等级和最终结论；若你在Pro/Enterprise套餐，可尝试按自定义数据筛选列表。

6. 替换为自己的查单与政策

   把Order Lookup换成你的订单API节点，把Policy Decision的表达式改为你真实退款政策的判断条件，再重复步骤三验证。

可直接复制的材料

{"orderId":"ORD-1001","customerTier":"gold","message":"Please refund this order."}
{"orderId":"ORD-1002","customerTier":"silver","message":"Item arrived damaged, want a refund."}
{"orderId":"ORD-9999","customerTier":"bronze","message":"Refund request for an unknown order."}

{
  "policyName": "demo-refund-policy-v1",
  "rules": [
    {"condition": "订单存在 且 customerTier为gold 且 签收未满30天", "decision": "refund_approved"},
    {"condition": "订单存在 且 该订单已有退款记录", "decision": "refund_declined"},
    {"condition": "订单不存在 或 金额超过500元", "decision": "needs_human_review"}
  ],
  "tagMaxLength": 255,
  "customDataKeys": ["orderId", "customerTier", "decision", "decisionReason"]
}

你是一名退款客服说明助手。已知本次退款判定结果为：{{ $json.decision }}，订单号：{{ $json.orderId }}，客户等级：{{ $json.customerTier }}，客户留言：{{ $json.message }}。请用不超过80字的中文向客户说明这个决定：若通过，告知退款将在3至5个工作日原路退回；若拒绝，简述拒绝原因并给出申诉邮箱；若需人工复核，告知客服将在24小时内联系。语气礼貌，不承诺政策外的内容，不透露内部规则细节。

输入与输出示例

本站虚构演示输出，回复文案来自上方提示词方案，非原作者运行结果

输入

POST {"orderId":"ORD-1002","customerTier":"silver","message":"收到货时包装破损，商品有划痕，想申请退款。"}

对应输出

工作流回复：{"decision":"refund_declined","reply":"很抱歉，订单ORD-1002此前已有退款记录，本次申请无法通过。如有异议请邮件联系appeal@example.com申诉。"}；本次执行的自定义数据含 orderId=ORD-1002、customerTier=silver、decision=refund_declined。

做完检查这些

• 三条测试订单依次返回refund_approved、refund_declined、needs_human_review
• 标签值超过255字符时执行以Stop and Error结束而非继续判定
• 每次执行的自定义数据里能看到orderId与最终decision
• Refund Support Agent的回复与decision一致且不含内部政策细节

容易卡住的地方

• 每发一条测试请求前必须重新点Execute workflow，否则Webhook测试URL不监听
• 按自定义数据筛选执行列表是n8n Cloud Pro/Enterprise功能，免费版和自托管看不到筛选入口
• 更换OpenRouter模型名时必须在OpenRouter - Support凭据对应节点里改，只在提示词里写模型名无效
• 替换真实订单API后记得回归跑一遍三条测试单，旧映射未必适用新数据结构