mcpField
C
car-corrective-action

car-corrective-action

github.com/rbraga01测试与质量4239 次安装1 周前更新
代码仓库

关于 car-corrective-action

用于编写纠正措施请求(CAR)的质量管理技能,适用于不合格、客户投诉和审核发现。它引导团队以证据分析根因、制定措施,并在结案前验证有效性。

主要功能

  1. 01CAR 结构与所需记录
  2. 02发生与流出的根因分析
  3. 03纠正措施规划及证据
  4. 04有效性验证标准
  5. 05结案清单与输出格式

适用场景

  1. 01记录 NCR 的处理措施
  2. 02处理客户投诉
  3. 03响应审核发现

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/rbraga01/quality-engineering-skills --skill car-corrective-action

安装后在 Claude Code 中输入/car-corrective-action确认已加载。

附带文件references/car-template.md

详细介绍

纠正措施请求(CAR)编写

适用场景

在以下情况下编写 CAR:

  • NCR 要求采取永久纠正措施
  • 客户投诉
  • 内部或外部审核发现(主要或次要不符合项)
  • 需要系统性纠正的重复不符合项

CAR 是问题经过分析、纠正并采取措施防止再次发生的书面证据。ISO 9001 §10.2.1 要求对已采取的措施及其结果形成文件化信息。对于 IATF 16949 审核中的主要不符合项,CAR 通常必须在 90 天内关闭;请查阅适用的 CSR,确认客户特定的关闭期限。

与 NCR 的关键区别

NCRCAR
问题是什么(客观事实)问题为何发生,以及将采取什么措施
发现环节和证据根本原因分析 + 措施
严重程度和处置有效性验证
立即编写调查后编写

CAR 会引用 NCR,并将其延伸至纠正措施范畴。


CAR 结构

1. 标题信息
字段内容
CAR 编号可追溯至 NCR 或审核发现
NCR / 发现项参考编号将此 CAR 与触发事件关联起来
开立日期
负责人责任人(姓名,而非职能)
目标关闭日期
关闭授权人有权关闭此 CAR 的指定人员(质量经理或同等职位)
实际关闭日期(关闭时填写)
2. 问题摘要

用一两句话概述 NCR 或发现项。客观、准确。必须与 NCR 描述完全一致,不得加入新的解读。

示例:

“批次 2026-05-12-A 中有 200 个连接器,其中 47 个的插针插入深度低于下限 0.6–1.5 mm(规格为 5.0 ± 0.3 mm)。在来料检验时发现(NCR-2026-0047)。”

3. 立即遏制措施(如 NCR 中尚未记录)

确认遏制措施已落实。如果已记录在 NCR 中,请引用该记录。如果尚未采取措施,请在此处定义。

4. 根本原因分析

这是 CAR 的核心。请使用结构化方法:

推荐工具:

  • 对于线性因果链,使用 5-Why
  • 对于复杂或多因素问题,使用 鱼骨图

识别两个根本原因:

  1. 发生根本原因——不符合项为何发生?
  2. 流出根本原因——为何未能在问题到达下一位客户前检测出来?

记录完整因果链,而不只是结论:

Root cause of occurrence:
Why: Connector pin depth OOS → Why: insertion force insufficient → 
Why: pneumatic jig set to wrong pressure → Why: pressure setpoint not in work instruction →
Root cause: Work instruction for Station 3 does not specify jig pressure setpoint.

Root cause of escape:
Why: Not detected at our outgoing inspection → Why: no depth measurement in outgoing
inspection plan → Root cause: Control Plan does not include pin depth at outgoing.

**验证:**说明如何确认根本原因。可接受的验证方法包括:

  • 复现测试(证明消除或恢复根本原因会产生或避免缺陷)
  • 数据关联(根本原因变量与缺陷发生之间存在统计关联)
  • 实物证据(对失效零件或过程的检查揭示了因果机制)
  • 直接审查记录(确认缺少所需控制)

仅有团队意见支持、未经证据验证的根本原因,不能作为 CAR 关闭的依据。

5. 纠正措施

每个根本原因对应一项纠正措施。措施必须直接解决根本原因,而非表面症状。

#针对的根本原因纠正措施负责人目标日期
1WI 未规定夹具压力更新 WI-Station-3,规定夹具压力为 4.5 ± 0.2 bar[姓名]2026-06-05
2CP 未在出货环节检查深度在出货环节的控制计划中增加插针深度测量,每批抽样 10%,n=5[姓名]2026-06-05

措施质量检查:

  • 如果落实此措施,能否防止根本原因再次发生?
  • 措施是否具体(谁在何时之前做什么)?
  • 能否验证措施是否已落实?
6. 实施证据

对于每项纠正措施,都要记录其已实际实施的证据:

措施实施证据验证日期
WI 已更新WI-Station-3 rev C,已于 2026-06-04 批准,附件中提供2026-06-04
已开展培训培训出勤记录附后(4 名操作员)2026-06-04
Control Plan 已更新CP rev F,已于 2026-06-04 批准,附件中提供2026-06-04

文件必须以新的修订号和批准日期进行修订。口头声称已实施不构成证据。

7. 有效性验证(VOE)

大多数 CAR 都会在此环节失败。措施已实施,但无人检查它是否确实能防止缺陷。

VOE 要求(ISO 9001 §10.2.1.e):

  1. 方法: 如何检查纠正措施是否有效?(数据收集、监控周期)
  2. 指标: 要测量什么?(缺陷率、检验结果)
  3. 数量/时长: 什么样的样本量或时间周期才构成充分证据?
  4. 目标: 什么样的结果能确认措施有效?

VOE 最低数量指导:

  • 对于已知基准发生率的缺陷:VOE 样本必须足够大,若措施失效,应能观察到至少一次复发。例如:如果基准缺陷率为 5%,那么 60 件产品的零缺陷样本可提供 95% 的置信度,表明当前缺陷率低于 5%。
  • 对于过程参数变更:在新条件下至少连续生产 30 个周期,或按照 Control Plan 中规定的抽样频率 × 3 个周期执行。
  • 对于检测控制的改进:受影响产品系列至少完成一个完整检验周期,且无漏检。
  • 所有情况下的最低要求:说明采用的样本量及选择依据。“10 件产品中零缺陷”并不是适用于高产量过程的有效 VOE。

VOE 结果:

  • 记录监控周期结束后的实际结果
  • 声明:有效 / 无效
  • 如果无效:返回根本原因分析并重复执行
8. AP 修订(AIAG-VDA,如适用)

如果不符合项涉及具有 Action Priority(AP)评级的 PFMEA 失效模式:

  • 纠正措施经验证已实施后,必须更新 PFMEA 中修订后的 S、O 和/或 D 评级
  • 修订后的 AP(AP-revised)必须体现改进——其数值必须低于原始 AP;若未变化,则必须记录理由
  • 只有 VOE 完成后才能记录修订后的 AP,不得在规划措施时记录
9. 系统性预防和横向展开

请问:类似的零件、过程或产品系列中是否可能存在相同的根本原因?

如果存在:

  • 列出类似领域
  • 记录为推广纠正措施而采取的措施
  • 提供横向展开已完成的证据
10. 经验教训

用一两句话记录关键经验,供将来参考:

“装配工位的作业指导书模板必须包含所有过程参数设定值。Control Plan 必须涵盖所有安全相关特性的出货检验。”

将其存入经验教训登记册,并在 PFMEA 更新中引用。


关闭标准

只有在以下所有条件均满足,且关闭授权人(在标题中指定)已签字批准后,才能关闭 CAR:

  • 已记录发生原因和漏检原因,并提供验证证据
  • 已实施纠正措施,并记录修订号和批准日期
  • VOE 已完成,记录了样本量,并确认措施有效
  • PFMEA 已更新(修订失效模式条目;如适用,修订 AP)
  • Control Plan 已更新(如果检测控制发生变化)
  • 作业指导书已更新(如果过程控制发生变化)
  • 已记录横向展开情况
  • 已通知客户关闭情况(如果 CAR 由客户投诉触发,或 CSR 要求通知)
  • 已获得关闭授权人的签字批准

常见错误

  • **将“重新培训操作人员”**作为人为错误的纠正措施——单靠这一措施永远不够;必须改变导致错误发生的系统
  • 未进行 VOE 就关闭——这是重复出现不符合项的最常见原因
  • 基于样本量不足的 VOE——“5 个样本中零缺陷”不算有效性验证;应在收集数据前定义最低数量
  • 实施措施后未更新 PFMEA 和控制计划——下次审核会发现这一缺口
  • 措施过于笼统——“审查程序”→ 不够具体;必须说明是哪项程序、修订为何种内容、由谁负责以及何时完成
  • 未经具名授权人签字就关闭——任何团队成员在未获得明确定义的授权时关闭 CAR,都是治理方面的缺口
  • 缺少 AP 修订记录——当 PCA 针对 PFMEA 失效模式采取措施时,必须在 VOE 后记录修订后的 AP

输出格式

每次开始使用时,询问用户:

“您希望以哪种格式接收输出? A — 结构化 Markdown(包含格式化表格和章节,可直接复制) B — 纯表格(简化结构,适用于 Excel 或 Word) C — 叙述式报告(连贯文本,适用于正式文档或电子邮件)

默认:A。”

根据所选格式调整所有输出章节。如果平台或会话上下文已指定格式偏好,则跳过此问题。

更新日志

版本日期作者变更
1.02026-06-01@RBraga01首次发布
1.12026-06-04@migmcc扩展 CAR 与 D5-D6 的关联,并增加有效性验证要求

评论

支持 Markdown