延误货运自动检测与改线审批

原文要点

这是一个免费n8n模板：每30分钟定时从Google Sheets的Active Shipments表读取在途货运，比对承诺送达时间与当前ETA（或delayed状态）找出延误件并计算延误小时数，发现延误即发Telegram汇总告警。对每个延误件调用路由HTTP接口取备选路线，连同运单信息发给OpenAI的gpt-4o-mini生成结构化改线建议；AI标记需要审批时在Slack发交互式审批并等待批准或拒绝。批准（或自动通过）后调用承运商TMS HTTP接口更新路线、回写表格、用Gmail邮件通知客户并在Slack确认；拒绝则在表格标记升级人工复核并通知运营频道。路由与TMS地址为占位需替换。

这次做成什么

搭建一条延误货运处置流水线：定时扫描表格→延误检测→Telegram告警→AI生成改线建议→Slack审批→执行改线与通知。按来源说明手工在n8n逐节点搭建（不提供可导入JSON），用合成运单表验证批准与拒绝两条分支都走通。

准备什么

• n8n实例及OpenAI API密钥（模板指定gpt-4o-mini）
• Google Sheets OAuth2凭据和一个含Active Shipments表的文档
• Telegram Bot凭据与目标chat ID
• Slack OAuth2凭据，支持交互式按钮消息，以及审批频道与运营频道ID
• Gmail OAuth2凭据，用于按运单的客户邮箱发通知
• 路由API与承运商TMS API的真实地址和header认证（模板中是占位URL）
• 含合成运单的测试表格，勿先用真实客户数据调试

具体怎么做

1. 准备运单表并设定时读取

   在Google Sheets建Active Shipments表，列包含Shipment ID、Customer、Customer Email、Carrier、Origin、Destination、Promised Delivery、Current ETA、Status、Priority，填入至少三条合成运单（其中一条Current ETA晚于Promised Delivery）。n8n里添加Schedule Trigger设为每30分钟，接Google Sheets读取节点并绑定文档ID。

2. 延误判定与Telegram汇总告警

   用Code或IF节点比较Promised Delivery与Current ETA（或Status为delayed），计算延误小时数=两时间差。聚合所有延误件生成一段汇总文本，Telegram节点发送到指定chat ID；仅当延误件数≥1时才发送，空结果直接结束本轮。

3. 取备选路线并让gpt-4o-mini出建议

   对每个延误件循环执行：HTTP Request节点调用路由API取备选路线，然后把运单字段与路线列表一起发给OpenAI节点（模型gpt-4o-mini），使用本站的结构化提示词，要求输出JSON：推荐路线、理由、新增成本估计、needsApproval布尔值。

4. Slack交互式审批分支

   IF节点判断needsApproval：为真时Slack节点向审批频道发带批准/拒绝按钮的交互消息并启用等待响应；为假视为自动通过直接进入执行分支。被拒绝时走另一条分支：更新表格Status为escalated人工复核，并发消息到运营Slack频道。

5. 执行改线、通知与回写

   批准或自动通过后：HTTP节点调用承运商TMS接口更新路线；Google Sheets节点回写该运单的新ETA与Status；Gmail节点向该运单的Customer Email发送改线通知（替换模板占位收件逻辑，按每行客户邮箱发送）；最后Slack发确认消息收尾。

可直接复制的材料

你是物流调度助手。下面是一件延误运单的信息和路由API返回的备选路线列表。请选择一条最优替代路线并评估是否需要人工审批。

运单信息：{"shipmentId":"{{$json.shipmentId}}","customer":"{{$json.customer}}","carrier":"{{$json.carrier}}","origin":"{{$json.origin}}","destination":"{{$json.destination}}","promisedDelivery":"{{$json.promisedDelivery}}","currentEta":"{{$json.currentEta}}","delayHours":{{$json.delayHours}},"priority":"{{$json.priority}}"}
备选路线列表：{{$json.routeOptions}}

只输出JSON：{"recommendedRouteId":"所选路线ID","reason":"不超过50字的理由","estimatedExtraCost":数字（人民币元）,"newEta":"ISO格式时间","needsApproval":true或false}
审批规则：新增成本超过500元、或新ETA比承诺送达时间晚24小时以上、或运单Priority为high时，needsApproval必须为true。

Shipment ID,Customer,Customer Email,Carrier,Origin,Destination,Promised Delivery,Current ETA,Status,Priority
SH-9001,云杉贸易,ops-test-a@example.com,迅达物流,上海,北京,2026-09-10T18:00:00+08:00,2026-09-10T14:00:00+08:00,in_transit,normal
SH-9002,青禾生鲜,ops-test-b@example.com,安达冷链,广州,成都,2026-09-10T12:00:00+08:00,2026-09-11T20:00:00+08:00,delayed,high
SH-9003,北辰制造,ops-test-c@example.com,迅达物流,天津,西安,2026-09-12T09:00:00+08:00,2026-09-12T09:30:00+08:00,in_transit,normal

输入与输出示例

本站虚构演示，未实际运行模板；AI输出为按提示词规则的示意，非模型真实调用结果。

输入

读取上表：SH-9002承诺2026-09-10 12:00送达，当前ETA为2026-09-11 20:00，状态delayed，优先级high；路由API返回两条备选路线R-A（新增成本300元，ETA 2026-09-11 08:00）与R-B（新增成本80元，ETA 2026-09-12 06:00）。

对应输出

延误检测算出delayHours=32，Telegram发送“检测到1件延误运单：SH-9002（青禾生鲜），延误32小时”。gpt-4o-mini输出{"recommendedRouteId":"R-A","reason":"比R-B早22小时到达，成本可接受","estimatedExtraCost":300,"newEta":"2026-09-11T08:00:00+08:00","needsApproval":true}。因Priority为high触发Slack审批；点击批准后TMS更新为R-A，表格Status回写为rerouted、Current ETA更新为2026-09-11T08:00:00+08:00，Gmail向ops-test-b@example.com发通知，Slack发确认。

做完检查这些

• SH-9002被判定延误且delayHours计算为32，SH-9001和SH-9003不触发告警
• Telegram汇总消息只在存在延误件时发送，全部正常时本轮静默结束
• AI输出的JSON能通过解析且needsApproval在high优先级运单上为true
• 在Slack点击批准后，TMS更新、表格回写、Gmail通知、Slack确认四步全部执行且对应同一运单号
• 在Slack点击拒绝后，表格Status变为升级人工复核标记，运营频道收到通知，不调用TMS

容易卡住的地方

• 路由API与承运商TMS的base URL是占位符，必须替换为真实端点并配好header认证，否则HTTP节点失败
• Google Sheets文档ID与Active Shipments表名、列名要和模板读取节点完全一致，列名错位会导致延误判定失灵
• Gmail节点原模板用占位收件人，必须改为按每行Customer Email动态发送，否则邮件发给固定假地址
• Slack审批依赖交互式消息与等待响应配置，凭据缺少交互权限会卡在等待节点
• 时间比较涉及时区，Promised Delivery与Current ETA格式不统一会算出错误的延误小时数
• 模板指定gpt-4o-mini，模型调用会产生OpenAI费用；30分钟轮询频率可按业务量调低