包装印刷稿版本不一致自动告警

原文要点

原模板为免费n8n工作流：每30分钟轮询Airtable的PrintJobs表（上限100条，出现分页offset即失败关闭），与Google Sheets中Snapshot页release-register行的旧快照比对已批准版次、已发布版次与上机状态组成的签名。发现已批准与已发布版次不一致时先等60秒重新拉取确认防抖；稳定不一致且状态为plated或printing的标记紧急，由OpenAI生成简短JSON差异说明，紧急发Slack、非紧急建Gmail草稿，确认投递成功后才更新快照。OpenAI超时时用确定性行摘要兜底，处理内容不含个人身份信息。

这次做成什么

复刻一条版本不一致告警线：定时比对工单当前状态与快照，防抖确认后按紧急度分流到Slack或Gmail草稿，投递成功才推进快照，避免漏报和重复报警。

准备什么

• n8n实例及模板导入权限
• Airtable账号与API token（Bearer方式），含PrintJobs表
• Google账号并授权Google Sheets与Gmail
• Slack incoming webhook或可发消息的Slack应用凭据
• OpenAI API密钥（仅用于生成差异说明，缺失时可退回确定性摘要）

具体怎么做

1. 准备Airtable表与Sheets快照页

   Airtable表需含字段：JobId、ApprovedRevision、ReleasedRevision、PressState（取值queued/plated/printing）、ReprintExposure（数字）、ChangeNotes。Google Sheets建名为Snapshot的标签页，两列Key与Snapshot，插入一行Key=release-register、Snapshot={}。在模板配置节点填入Airtable base ID、表名、Sheets文档ID、Slack频道与审核邮箱。

2. 绑定五套凭据

   在n8n分别创建：Airtable用HTTP Header Auth（Authorization: Bearer token）、Google Sheets与Gmail用OAuth2、Slack用webhook或应用token、OpenAI用API密钥。逐节点绑定后用各节点的测试功能确认能拉表、能读快照页。

3. 核对签名比对与防抖

   打开比对节点确认签名由ApprovedRevision、ReleasedRevision、PressState组成。手动触发一次，把某工单的ReleasedRevision改一个值，应在控制台看到检测到差异→等待60秒→重新拉取Airtable→差异仍在才进入后续分支；若60秒内数据被改回一致，则本次不告警。

4. 核对紧急分流与AI说明

   确认Route Press Exposure分支：PressState为plated或printing→critical→Slack节点；其余→Gmail草稿节点。OpenAI节点只接收版次差异与ChangeNotes，输出简短JSON说明；把OpenAI密钥临时移除再跑一次，应自动退回确定性行摘要作为兜底brief。

5. 验证投递守卫的快照更新

   观察最后一环：Slack返回ok:true或Gmail草稿返回id之后，Sheets的Snapshot行才被更新。临时把Slack频道改错让投递失败，确认快照不更新、下一轮会再次告警同一差异，这就是防漏报设计。

可直接复制的材料

[{"JobId":"PJ-2001","ApprovedRevision":"R4","ReleasedRevision":"R4","PressState":"queued","ReprintExposure":0,"ChangeNotes":""},{"JobId":"PJ-2002","ApprovedRevision":"R5","ReleasedRevision":"R3","PressState":"printing","ReprintExposure":12000,"ChangeNotes":"客户改logo配色"},{"JobId":"PJ-2003","ApprovedRevision":"R2","ReleasedRevision":"R1","PressState":"queued","ReprintExposure":800,"ChangeNotes":"文案修订"}]

你是印刷工单审核助手。输入一个JSON对象，含JobId、ApprovedRevision、ReleasedRevision、PressState、ReprintExposure、ChangeNotes。仅当ApprovedRevision与ReleasedRevision不同时，输出不超过60字的中文JSON：{"summary":"差异一句话","risk":"上机风险一句话","suggest":"建议动作一句话"}。两个版本相同则输出{"summary":"无差异"}。不要使用输入之外的任何信息。输入如下：{"JobId":"PJ-2002","ApprovedRevision":"R5","ReleasedRevision":"R3","PressState":"printing","ReprintExposure":12000,"ChangeNotes":"客户改logo配色"}

输入与输出示例

本站虚构演示输出，未实际运行模板；AI措辞每次生成会有差异，仅结构与分流结果应稳定。

输入

使用上表三行数据，快照中PJ-2002与PJ-2003的旧签名均为ApprovedRevision=ReleasedRevision，当前Airtable为合成数据所示

对应输出

PJ-2002输出{"summary":"已批准R5但上机稿件仍为R3","risk":"printing状态用错版，返工敞口约12000","suggest":"立即停机换R5并复核"}并投递Slack；PJ-2003生成非紧急Gmail草稿；快照在两处投递确认后更新

做完检查这些

• PJ-2001不触发任何告警，PJ-2002走Slack，PJ-2003走Gmail草稿
• 60秒防抖期间把数据改回一致则本轮不产生告警
• Slack投递失败后Snapshot行的内容保持旧值不变
• 移除OpenAI凭据后仍能发出确定性摘要兜底而不是流程报错
• Airtable返回分页offset时工作流按失败关闭处理并提示需要加分页

容易卡住的地方

• 超过100条在制工单必须自行实现分页，否则出现offset即停止
• 防抖60秒加运行耗时要远小于30分钟轮询间隔，且应为单写者执行模式避免快照竞争
• OpenAI调用另行计费且可能超时，兜底摘要必须保留
• Airtable缺少任一必需字段或Snapshot首行不是合法JSON会在校验节点报错
• Gmail草稿不会自动发送，需人工审核后点发，这点要在班组流程里说明