防回流设备检测合规自动分级处理

原文要点

这是n8n上的免费模板：每天06:00定时运行，读取Google Sheets「Device Registry」设备台账，逐台计算距上次检测天数、逾期天数、下次到期日与基于危险等级的风险分；缺device_id或owner_email的行发Slack到#cross-connection-data-quality；OpenAI把完整行分类为Critical Overdue/Due Soon/Compliant三档；严重逾期向州电子上报门户API提交不合规记录、Gmail发停水警告信、Slack提醒#cross-connection-alerts；即将到期发Gmail检测提醒；合规只写审计；每台设备向「Audit Log」追加一行审计。配置需替换REPLACE_WITH_SHEET_ID、准备五个凭据、替换门户占位URL并按辖区调整检测周期逻辑。

这次做成什么

照模板结构在自有n8n里搭出一条可测试的「定时读取台账→算逾期风险→OpenAI三档分级→分支处置→写审计日志」流水线，并用本站合成的3行测试设备数据走通三个分支各一次。

准备什么

• 可登录的n8n实例（自托管或n8n Cloud）
• Google账号并能建一张含Device Registry与Audit Log两个标签页的测试表格
• OpenAI API Key、Gmail发送权限、两个测试用Slack频道
• 一个占位HTTP接口（练习期可用webhook.site之类的接收端代替州门户，绝不对真实政务接口发测试数据）

具体怎么做

1. 准备测试台账

   新建Google Sheets，建「Device Registry」和「Audit Log」两个标签页，把材料一的合成CSV内容粘入Device Registry作为表头与数据，其中第3行故意留空owner_email用于触发数据质量分支。复制浏览器地址栏中的表格ID备用。

2. 导入并配置模板

   在n8n的Workflows页面通过模板URL(workflows/19760)导入该工作流。依次替换两个Google Sheets节点里的REPLACE_WITH_SHEET_ID为你的表格ID，标签页分别选Device Registry（读）和Audit Log（追加）。

3. 配置五个凭据

   在Credentials里新建并绑定：Google Sheets OAuth2、Gmail OAuth2、Slack（Bot Token或OAuth）、OpenAI API Key、以及HTTP节点的认证方式（练习期选None并指向webhook.site生成的测试URL，替换模板中的州门户占位地址）。

4. 核对字段映射

   打开计算代码节点，确认读取字段为device_id、owner_email、last_test_date、hazard_level；它输出days_since_last_test、days_overdue、next_due_date、risk_score。检查OpenAI节点的system提示词（可参考材料二改写）以及Switch节点按Critical Overdue/Due Soon/Compliant三路分流的条件与OpenAI输出字段一致。

5. 手动执行走通三分支

   先点Execute workflow手动跑一次（不必等06:00定时）：预期第1行走Critical Overdue分支（HTTP请求+Gmail警告信+Slack警报），第2行走Due Soon分支（提醒邮件），第3行因缺owner_email只发数据质量Slack。最后打开Audit Log标签页核对每台设备各追加了一行审计记录，再启用Schedule Trigger正式每天06:00跑。

可直接复制的材料

device_id,owner_email,last_test_date,hazard_level,location
BF-1001,ops-a@example.com,2025-08-10,high,12 River Rd
BF-1002,ops-b@example.com,2026-08-25,medium,4 Elm St
BF-1003,,2026-09-01,low,9 Oak Ave

你是供水防回流设备合规分级助手。输入是一台设备的JSON：{"device_id":"BF-1001","days_since_last_test":406,"days_overdue":41,"next_due_date":"2026-08-10","risk_score":87,"hazard_level":"high"}。规则：days_overdue>0判Critical Overdue；days_overdue<=0且距next_due_date不足30天判Due Soon；其余判Compliant。只输出JSON：{"classification":"Critical Overdue|Due Soon|Compliant","reason":"20字内中文理由"}，不要输出任何其他文字。

输入与输出示例

本站虚构演示结果，未实际运行模板；具体邮件文案与字段名以你导入的模板为准。

输入

Device Registry三行：BF-1001距上次检测406天、逾期41天、高风险；BF-1002还剩约5天到期；BF-1003缺owner_email。手动执行一次工作流。

对应输出

BF-1001走Critical分支：HTTP节点向测试URL POST一条{"device_id":"BF-1001","status":"non-compliant"}记录，Gmail发出停水警告信，Slack #cross-connection-alerts收到警报；BF-1002收到检测提醒邮件；BF-1003在#cross-connection-data-quality出现「缺owner_email」提醒；Audit Log新增3行，每行含device_id、classification、processed_at。

做完检查这些

• Schedule Trigger显示每天06:00，且手动执行能完整跑完无红色报错节点
• 两个Google Sheets节点的REPLACE_WITH_SHEET_ID已全部替换，Device Registry能被读出3行
• 三条测试数据分别命中Critical/Due Soon/数据质量三个出口，无一漏判
• Audit Log标签页每台设备恰好追加一行，字段与读取字段对应

容易卡住的地方

• 模板中的州上报门户URL是占位符，练习期必须换成测试接收端，切勿向真实合规接口发送虚构数据
• OpenAI调用按token计费，模板本身免费但模型服务另收费
• 作者说明需按辖区调整检测周期代码，直接使用默认阈值可能不符合本地法规
• Gmail凭据需有发送权限，否则警告信与提醒邮件两路会在发送节点报错
• Slack频道名#cross-connection-data-quality与#cross-connection-alerts需在工作区预先存在或在节点里改成你的频道
• 本站未获得该工作流的实际JSON文件，节点内部字段名以你导入后的模板为准，本文不提供可导入JSON