采购风险评估编排与Slack人工审批

原文要点

原工作流用带请求头认证的webhook接收采购目标（含目标、优先级、发起人、范围），生成唯一请求ID后由OpenAI解析成结构化计划并校验；随后加载供应商、ERP支出、合同、供应商风险四类数据（当前是模拟数据），归一化为每供应商一条合并记录，逐家送OpenAI做JSON风险分析；确定性规则据结果决定执行供应商风险评估、合同审查或供应商监控三个子流程中的哪些；汇总后OpenAI生成结论与建议，发到Slack等待人工批准或拒绝；批准则路由到相应子流程执行并核验，写审计日志，最后把最终状态回传给原webhook调用方。模板免费，但三个子流程需自备，模拟数据节点要替换成真实数据源。

这次做成什么

在站内练习中复现「webhook接单→AI解析→逐家风险分析→规则路由→Slack人工审批→执行回传」的编排骨架：先用合成数据跑通批准与拒绝两条路径，再逐步把模拟数据换成真实源、把占位子流程换成真实流程。

准备什么

• n8n实例并已导入该免费模板
• OpenAI（或兼容接口）凭据，供目标解析、逐家风险分析、最终建议三处AI步骤使用
• Slack凭据和一个审批频道，且审批人回复方式能被工作流捕获
• 三个已存在的子流程：Supplier Risk Assessment、Contract Review、Supplier Monitoring（练习期可先建只回显输入的占位流程）
• webhook请求头认证凭据，以及一个能发POST请求的测试工具（如curl或Postman）

具体怎么做

1. 建占位子流程

   先建三个极简子流程，各只含一个触发输入节点和一个返回节点，把收到的JSON原样返回并加executed:true、sub_workflow名称字段。在主流程的三个Execute Workflow节点里分别选中它们。这样能在没有真实ERP和合同系统时先验证编排与审批链路，之后再逐个替换为真实流程。

2. 配置凭据与频道

   给webhook节点配Header Auth凭据（如自定义头X-Proc-Token）；给三处OpenAI节点选凭据；Slack节点选好审批频道。把生产webhook URL记下来给调用方，练习期先用测试URL。

3. 核对模拟数据与提示词

   打开模拟数据节点，确认输出字段与归一化节点期望的一致（supplier_id、spend、contract_status、risk_flags等）。用本站提供的两份提示词对照模板内提示词：目标解析必须输出结构化计划字段，风险分析必须输出严格JSON（risk_level、score、reasons），否则下游规则路由拿不到字段。

4. 发测试请求跑批准路径

   用本站artifacts里的测试payload向webhook发POST。观察执行：计划解析→逐家风险分析→至少一家供应商因高风险或合同到期触发子流程→Slack出现审批消息。让审批人回复批准，确认工作流继续执行对应子流程、写审计日志，webhook响应返回status=approved及执行明细。

5. 跑拒绝路径与边界

   再发一次相同请求，这次审批人回复拒绝，确认不执行任何子流程、审计日志记录rejected、webhook响应为拒绝状态。再发一个缺priority字段的畸形请求，确认校验节点直接返回错误而不是进AI步骤浪费调用。

可直接复制的材料

你是采购编排系统的解析器。用户会给出一段采购目标描述。只输出严格JSON，不要任何解释：
{
  "plan_id": "用请求ID",
  "objective": "一句话概括采购目标",
  "suppliers_in_scope": ["供应商ID列表，未知则留空数组表示全部"],
  "analysis_dimensions": ["spend", "contract", "risk"],
  "urgency": "high|medium|low",
  "requires_human_approval": true
}
规则：urgency根据请求里的priority映射；scope中没点名供应商时suppliers_in_scope留空；任何无法解析的输入都返回{"error":"unparseable_goal"}。

请求ID：{{$json.request_id}}
采购目标：{{$json.goal}}
优先级：{{$json.priority}}
范围：{{$json.scope}}

你是采购风险分析师。下面是单个供应商的合并记录（支出、合同、风险数据已归一化）。只输出严格JSON：
{
  "supplier_id": "原样返回",
  "risk_level": "high|medium|low",
  "risk_score": 0到100的整数,
  "reasons": ["每条10到30字的具体原因"],
  "recommended_route": "supplier_risk_assessment|contract_review|supplier_monitoring|none"
}
评分参考：年支出超过200万元且无备选供应商+30分；合同90天内到期+25分；近12个月有交付或合规风险记录+35分；单一来源依赖+10分。reasons必须引用记录里的具体数字。

供应商记录：{{$json}}

supplier_id,name,annual_spend_cny,contract_status,contract_expiry,risk_flags,sole_source
SUP01,华宇精密零件,3200000,active,2027-03-15,,true
SUP02,恒信包装材料,450000,expiring,2026-12-20,delivery_delay_2026-06,false
SUP03,铭创电子元件,1800000,active,2027-08-01,compliance_warning_2026-03,true
SUP04,安达物流,600000,active,2027-01-10,,false

{
  "goal": "评估华南区电子元件供应商的续约风险并给出处置建议",
  "priority": "high",
  "requester": "li.na@example.com",
  "scope": {"region": "华南", "categories": ["电子元件"]},
  "callback_note": "练习请求，请勿触达真实供应商"
}

输入与输出示例

本站虚构演示，未真实运行工作流；分数按本站提示词的参考算法手算，仅说明输入输出字段对应关系。

输入

POST /webhook/procurement-intake，头X-Proc-Token: 测试令牌，body为artifacts中的payload；模拟数据中SUP03年支出180万元、单一来源、带2026年3月合规警示。

对应输出

风险分析行：{"supplier_id":"SUP03","risk_level":"high","risk_score":80,"reasons":["单一来源依赖加10分","存在2026-03合规警示记录加35分","年支出180万元"],"recommended_route":"supplier_risk_assessment"}
审批人在Slack回复批准后，webhook最终响应：{"request_id":"PR-20261013-0042","status":"approved","executed":["supplier_risk_assessment"],"audit_log_id":"AUD-0091","detail":"SUP03已路由供应商风险评估子流程并核验完成"}

做完检查这些

• 三个Execute Workflow节点都已选中存在的子流程，缺一个工作流执行到该步会报错
• 批准路径下webhook响应含status=approved、已执行子流程列表和审计日志ID
• 拒绝路径下无任何子流程被执行，审计日志记录rejected及审批人
• 缺priority或goal的请求被校验节点直接拒绝，不进入OpenAI步骤
• 每家供应商的风险分析输出都是可解析JSON且含risk_level与risk_score，否则规则路由节点会拿不到字段

容易卡住的地方

• 模板内供应商/支出/合同/风险数据是mock，接真实ERP或合同系统前必须替换节点并保持字段映射一致，否则归一化记录会缺字段
• 三个子流程模板不附带，需要自行实现；练习期用占位流程时别忘了最终要换成真流程
• Slack审批的回复格式要与解析节点约定一致（如固定关键词approve/reject），审批人随意措辞会导致解析失败、流程挂起
• OpenAI步骤有三处，每一家供应商都会触发一次风险分析调用，供应商数量大时调用次数与费用会成倍增长，具体费用取决于所用模型与官方定价
• webhook必须保持请求头认证开启，暴露无认证的采购执行入口会让任何人触发审批与执行链路