Cp/Cpk 计算器 常见报错与排查｜过程质量管控·6 个真实卡点的定位与解法（附源码）
（复制到编辑器，段落间距保持一致）
场景引入：Cp/Cpk 计算器到底解决什么
过程能力算不清、判异规则记不住、SPC 系统贵且不会用。 很多人以为买一套系统或写一段脚本就能解决，结果是工具用起来了，数据口径还是各说各话。Cp/Cpk 计算器 真正要解决的是：把「过程质量管控」里那件重复又易错的事，固化成一条能重复跑、结果能复现的流程。
本文从报错与排查的角度，把这条流程拆到可以照着做。
先跑通再排查
排查前先做一件事：跑内置演示数据。
- 演示数据能跑出结果 → 程序与依赖没问题，问题在数据或业务配置；
- 演示数据也报错 → 问题在环境或程序本身，先解决这个。
这一步能省掉大量无效排查。
报错清单与定位路径
下面是实际用下来最常撞的几类问题，按「现象 → 可能根因」列出：
1. 控制限算出来是空的 / 报错样本不足
- 可能根因：子组数 m 小于 2 或分组列解析失败；
- 排查动作：检查 CSV 分组列名与行数；先跑内置演示数据确认程序本身正常。
2. 判异规则一直误报，一半点都标红
- 可能根因：控制限按 3σ 算但过程本身有系统漂移；
- 排查动作：先看 Rule 1 的触发时间序列，若呈周期性说明是设备周期性动作，不是随机波动。
3. Cpk 高得离谱，明显不符合现场
- 可能根因：规格限被填成了控制限，或单位不一致；
- 排查动作：核对 USL/LSL 是客户规格还是内部目标，两者不能混用。
4. 导入中文 CSV 后数据全空
- 可能根因：编码或分隔符不匹配；
- 排查动作：统一存为 UTF-8 无 BOM、逗号分隔；读取时显式指定 encoding。
5. 不同批次数据放一起算，结果不可信
- 可能根因：未按批次分组，直接把所有点当同一过程；
- 排查动作：先按批次/机台/日期分组，再分别计算控制限。
6. 换了台设备数据结论就反转
- 可能根因：量测系统未做 GRR 验证，设备间有系统偏差；
- 排查动作：做量测系统分析，GRR 不合格时先修测量系统再谈过程能力。
根因判断顺序
按这个顺序排，不要跳步：
- 环境层：依赖版本、编码、路径、权限；
- 数据层：格式、字段、缺失值、量纲；
- 配置层：参数、阈值、映射关系；
- 逻辑层：以上都排除后，再怀疑程序本身。
修复动作清单
对号入座修：
- 控制限算出来是空的 / 报错样本不足 → 子组数 m 小于 2 或分组列解析失败。检查 CSV 分组列名与行数；先跑内置演示数据确认程序本身正常。
- 判异规则一直误报，一半点都标红 → 控制限按 3σ 算但过程本身有系统漂移。先看 Rule 1 的触发时间序列，若呈周期性说明是设备周期性动作，不是随机波动。
- Cpk 高得离谱，明显不符合现场 → 规格限被填成了控制限，或单位不一致。核对 USL/LSL 是客户规格还是内部目标，两者不能混用。
- 导入中文 CSV 后数据全空 → 编码或分隔符不匹配。统一存为 UTF-8 无 BOM、逗号分隔；读取时显式指定 encoding。
- 不同批次数据放一起算，结果不可信 → 未按批次分组，直接把所有点当同一过程。先按批次/机台/日期分组，再分别计算控制限。
- 换了台设备数据结论就反转 → 量测系统未做 GRR 验证，设备间有系统偏差。做量测系统分析，GRR 不合格时先修测量系统再谈过程能力。
如何避免复发
- 先确认程序本身没坏：跑一遍内置演示数据。
- 报错现象相同，根因可能完全不同，按顺序排不要跳。
- 数据类问题优先查格式与编码，业务类问题再查逻辑。
- 修完保留复现步骤，下次同类问题能秒定位。
把修复动作固化进脚本或检查项，比记在脑子里可靠。
相关工具
同一系列的相关工具：
- Xbar-R 控制图工具｜过程质量管控·批量数据做子组过程能力评估（附源码）
- 六西格玛 DPMO工具｜过程质量管控·过程能力换算成质量水平（附源码）
- Cpk 趋势监控工具｜过程质量管控·多批次过程能力衰减追踪（附源码）
- GRR 量测系统分析工具｜过程质量管控·量测系统可信度验证（附源码）
使用边界
本工具基于仿真/演示数据开发，可直接用于教学、方案验证与算法预演；接入真实工厂数据前请做二次验证，商用授权请联系作者。
