2. 验证工程的核心对象与术语体系

质量改进项目做完之后，最容易出现的一种争议是：大家说的“有效”根本不是同一件事。生产说“不良率降了”，质量说“过程能力还不够”，财务说“没看到收益”，客户说“投诉还是没少”。这些分歧的根源，往往不是数据本身有问题，而是术语没有对齐。验证工程的第一项基础工作，就是建立一套可操作、可判定、可追溯的术语体系，让“效果、改进、验证、确认、监控、收益、基线、目标值、规格限、过程能力”这些词在项目里只有一个含义。

一、效果与改进：先分清“变化”和“有价值的变化”

改进指的是一次有目的的措施介入，它改变了过程的输入、方法、设备、人员或控制方式。改进本身是一个动作，例如把焊接电流从 90A 调整到 85A、把抽检改为全检、把手工记录改为扫码采集。效果则是改进介入之后，被测量对象发生的可观测变化。关键点在于：效果是“测出来的”，不是“说出来的”。

效果必须绑定三个要素才能成立：测量对象（哪个特性、哪个指标）、测量方法（用什么量具、什么口径、什么时间窗）、比较基准（和什么比）。缺少任何一项，“效果”就只是一个印象。例如“焊接强度提高了”不是效果陈述；“焊接拉脱力均值由改进前的 420N 提升到改进后的 468N，样本各 30 件，同一拉力试验机、同一速度”才是效果陈述。

二、验证与确认：一个对内，一个对外

这两个词在中文里常被混用，但在验证工程中必须分开。验证（Verification）回答的是“我们有没有把方案做对”——即改进措施是否按设计被正确实施，输出是否符合既定的技术要求。它偏向内部、偏向技术符合性。确认（Validation）回答的是“我们做的是不是对的事”——即改进后的结果是否真正满足使用需求、客户要求和预期用途。它偏向外部、偏向使用有效性。

举个具体例子：某装配线把拧紧扭矩从 12N·m 改为 14N·m。验证要检查的是：扭矩枪是否已按 14N·m 标定、程序是否锁定、每班点检记录是否齐全、实际拧紧曲线是否落在 13.2～14.8N·m 的窗口内。确认要检查的是：改完之后，客户端是否还出现松动失效、售后返修率是否下降、装配件在振动试验中是否通过。验证通过不等于确认通过，这是很多项目翻车的地方。

三、基线、目标值与规格限：三个不能混的“线”

基线是改进前的真实水平，是效果比较的起点。基线必须来自稳定状态下的数据，不能拿异常波动期的最低值或最高值充当基线，否则效果会被系统性高估或低估。目标值是项目立项时设定的、期望达到的水平，它是一个管理承诺，通常带有挑战性。规格限是客户或设计给定的允许边界，是硬约束，不因项目目标而改变。

三者的关系可以这样理解：规格限决定“合格不合格”，目标值决定“这次改进要走到哪”，基线决定“从哪里出发”。如果目标值定得比规格限还宽松，这个项目在质量上就没有意义；如果基线本身已经贴着规格限，说明过程能力严重不足，改进空间大但难度也大。

四、过程能力：把“好”量化成可比较的数

过程能力是把过程输出与规格限放在一起比较的指标。最常用的是 Cp 和 Cpk。Cp 只看波动，Cpk 同时看波动和中心偏移。计算式为：

Cp  = (USL - LSL) / (6σ)
Cpk = min[(USL - μ) / (3σ), (μ - LSL) / (3σ)]

其中 USL 为上规格限，LSL 为下规格限，μ 为过程均值，σ 为过程标准差。举例说明（以下为教学示例数据，非实测）：某轴径规格为 10.00±0.05mm，即 USL=10.05、LSL=9.95。改进前 μ=10.02、σ=0.012，则 Cpk=min[(10.05-10.02)/(0.036), (10.02-9.95)/(0.036)]=min[0.83, 1.94]=0.83。改进后 μ=10.00、σ=0.010，则 Cpk=min[1.67, 1.67]=1.67。可以看到，改进不仅减小了波动，还把中心拉回了规格中心，Cpk 从 0.83 提升到 1.67，这才是可比较、可判定的效果。

五、监控与收益：效果要守得住、算得清

监控是改进效果固化后的持续观察，目的是确认效果没有随时间衰减。监控通常用控制图、点检表、趋势图实现，并设定反应计划：一旦超出控制限或出现连续趋势，就触发复查。收益是把效果折算成经济或资源价值，例如不良率下降带来的返工工时减少、报废材料减少、客户索赔减少。收益必须与基线口径一致，否则会出现“效果很好、收益算不出来”的尴尬。

六、验证对象的四类划分

验证对象不同，验证的侧重点也不同。产品验证关注尺寸、性能、可靠性等实物特性；过程验证关注工艺参数、节拍、过程能力、控制计划；系统验证关注接口、联动、逻辑、异常处理；服务验证关注响应时间、一次解决率、客户感知。同一个改进项目可能同时涉及多类对象，需要分别设定验证指标和判定准则。

七、把术语落到一张判定表上

术语对齐之后，建议在项目启动阶段就填写一张“验证判定表”，把每个术语变成可执行的字段。下面给出一个可直接参考的示例结构（数据为教学示例）：

把上述术语和判定表固定下来，验证工程就有了共同语言。后续无论是做数据采集、假设检验、控制图分析还是收益核算，都能围绕同一套定义展开，避免“各说各话”的验证争议。