QA纠正预防措施全流程：表单上报、Gemini定级、邮件追踪闭环

原文要点

这是Asmita Fahim在n8n.io发布的付费模板20382，覆盖QA/QC的CAPA闭环：员工经n8n表单提交审核发现，系统生成唯一finding ID并规范化字段后交Google Gemini判定类别、风险等级、严重度评分、是否需要CAPA及建议措施；不需要的写入Google Sheets的No_CAPA_Log留痕；需要的在CAPA_Log建条目，按部门从Owner_Directory查负责人邮箱，按风险算截止日期，状态置Assigned并经Gmail通知。负责人用第二个表单提交完成说明与证据，状态变为Awaiting QA Verification并邮件通知QA；QA用第三个表单决定Closed（发关闭通知）或Rework Required（发返工请求并记录）。配置需三个标签页结构匹配（含CAPA_ID、Department等键）、Gemini与Gmail凭据，并替换qa-team@example.com等占位收件人。

这次做成什么

设计一套不依赖原付费文件的CAPA流程练习：用三个自建表单和一张三标签页Sheet，手工跑通"上报→Gemini定级→指派→提交证据→QA验证关闭/返工"完整闭环一次，验证字段映射和状态流转逻辑，再决定是否购买原模板。

准备什么

• n8n实例及创建表单触发器（Form Trigger）权限
• Google Sheets与Gmail的OAuth凭据
• Google Gemini（Google AI）API凭据，调用可能产生费用
• 一个含CAPA_Log、Owner_Directory、No_CAPA_Log三个标签页的测试表格
• 注意：原模板为付费商品，本页练习是本站独立重建方案，不含原工作流文件

具体怎么做

1. 建三标签页Sheet

   CAPA_Log列：CAPA_ID、Finding_ID、Department、Category、Risk_Level、Severity_Score、Status、Owner_Email、Due_Date、Completion_Notes、Notification_Status。Owner_Directory列：Department、CAPA_Owner_Email。No_CAPA_Log列：Finding_ID、Decision、Rationale、Logged_At。

2. 建表单一：发现上报

   用n8n Form Trigger建"审核发现上报"表单，字段：reporter_name、department（下拉：生产/质检/仓储）、description、evidence_link。后续接Set节点生成Finding_ID（如F-再加时间戳），把字段规范化后交给Gemini节点。

3. 接Gemini定级与分支

   Gemini节点使用下方提示词返回JSON。接Switch节点按capa_required分流：false→追加一行到No_CAPA_Log；true→生成CAPA_ID（C-前缀），按department查Owner_Directory得Owner_Email，按risk_level算Due_Date（高=7天、中=14天、低=30天，本站设定），追加到CAPA_Log并置Status=Assigned，经Gmail给Owner_Email发指派邮件，把发送结果写回Notification_Status。

4. 建表单二：完成提交

   第二个Form Trigger字段：CAPA_ID、completion_notes、evidence_link。收到后按CAPA_ID匹配更新CAPA_Log的Status为Awaiting QA Verification，并邮件通知QA测试邮箱。

5. 建表单三：QA验证并闭环

   第三个Form Trigger字段：CAPA_ID、decision（下拉：Closed/Rework Required）、qa_comment。Closed→更新状态并发关闭通知；Rework Required→状态置Rework Required，给负责人发返工邮件并记录Notification_Status。依次发布三个表单，用合成数据完整跑一遍。

可直接复制的材料

Department,CAPA_Owner_Email
生产,aiplay-owner-prod@example.com
质检,aiplay-owner-qc@example.com
仓储,aiplay-owner-wh@example.com

你是质量体系工程师，请评估下面的QA/QC审核发现，只输出一个JSON对象，不要输出其他文字：
{"category":"来料|过程|成品|设备|文件|其他","risk_level":"高|中|低","severity_score":1到10的整数,"capa_required":true或false,"recommended_action":"一句话中文建议措施","rationale":"一句话中文判定理由"}

判定规则：
1. 可能导致产品不合格流出、安全隐患或客户投诉→capa_required=true且risk_level为高；
2. 影响内部良率或可追溯性但无流出风险→capa_required=true，risk_level为中或低；
3. 纯记录偏差、已当场纠正且无复发迹象→capa_required=false。

审核发现：
上报部门：{{department}}
问题描述：{{description}}
证据链接：{{evidence_link}}

输入与输出示例

本站虚构演示，未实际运行原模板或调用Gemini；风险等级与期限为练习设定。

输入

表单一提交：reporter_name=王测试，department=生产，description="装配线B工位扭力扳手校准标签过期3天，期间已加工约200件"，evidence_link=https://drive.example.com/fake-evidence-01

对应输出

Gemini返回{"category":"设备","risk_level":"高","severity_score":8,"capa_required":true,"recommended_action":"隔离该批次并复检扭力记录","rationale":"校准过期涉及批量产品追溯风险"}；CAPA_Log新增一行CAPA_ID=C-20261003-01、Status=Assigned、Owner_Email=aiplay-owner-prod@example.com、Due_Date为提交日+7天；负责人收到指派邮件；表单二提交后状态变Awaiting QA Verification；表单三选Closed后状态变Closed并发出关闭邮件。

做完检查这些

• capa_required=false的发现只写入No_CAPA_Log且不产生任何指派邮件
• CAPA_Log中新行的Owner_Email与Owner_Directory中该部门的邮箱一致，Due_Date符合所设期限规则
• 表单二提交后同一条CAPA的Status变为Awaiting QA Verification，QA邮箱收到通知
• 表单三分别选Closed和Rework Required时，状态与邮件走向各自正确

容易卡住的地方

• 原模板需付费购买，本页是独立重建练习，不包含原工作流文件，界面与字段名以原模板为准
• Department取值在表单、Owner_Directory中必须逐字一致，否则查不到负责人邮箱
• 占位收件人（如qa-team@example.com）必须替换为真实测试邮箱再发布表单
• Gemini与Gmail调用可能产生费用，先用单条合成数据跑通