来料与成品检验：把判定规则从老师傅脑子里搬进系统

一、质量检验为什么总停在纸单上

很多工厂的检验环节并不是没有流程，而是流程活在人和纸上。典型的样子是这样的：

• 检验标准写在作业指导书里，或者干脆在老师傅脑子里。同一批物料，两个人检，一个判合格一个判让步，谁也说不清谁对。
• 检验单是纸质表格，填完归档。想查"上个月这家供应商的不合格率"，得把一摞单子摊在桌上数。
• 不良原因随手写"尺寸不符""外观不良"，用词不统一，统计出来一堆同义词，没法拿去做供应商沟通。
• 来料没检就上线、成品没检就发货，靠的是仓库和车间的人互相提醒，一旦换班就漏。
• 质量数据只在质量部自己手里。采购问"这批能不能退"、生产问"这个半成品敢不敢往下走"，都要跑一趟办公室。

这些问题的共同根源不是"缺一个检验员"，而是判定规则没有被做成数据结构。规则不落进字段和字典，系统就只能记录结果，无法约束过程。

下面讲怎么用 AI 构建器（用自然语言描述业务需求，平台自动生成数据表、管理页面和移动端界面的开发方式）把检验这件事搭成一个可追溯、能拦人的闭环。核心是三张东西：检验项目标准表、检验单主表、检验明细子表，再加上一个不良原因字典。

二、先把判定标准做成数据，而不是文档

这是整个方案的地基，也是最容易被跳过的一步。如果直接开始建"检验单"，最后得到的还是一张电子化的纸质表格——换了个地方存，还是不能自动判定。

检验项目标准：一条记录 = 一个测点

不要做"一张标准表带一堆文本备注"的结构。要做成一行一个检验项目的明细表，字段大致是这样：

两个容易踩的坑：

第一，公差不要写成字符串。 "20±0.1"这种写法人看得懂，机器看不懂。拆成标准值、上限、下限三个数字字段，AI 构建器生成时明确说明这三个字段是数值类型，判定逻辑才有依据。

第二，一定要给标准留版本号。 客户图纸改版后，旧检验单是按旧标准判的。没有版本，半年后追溯会出现"这张单按现行标准是不合格的，当时怎么判的合格"这种解释不了的争议。做法是检验单上同时存"标准版本"快照，而不是只存一个指向标准的引用。

不良原因字典：先统一用词再谈统计

平台的数据字典能力（集中管理下拉选项，多个模块共用一套枚举值）在这里正好用上。建议至少建三套字典：

• 不良现象：划伤 / 尺寸超差 / 变形 / 脏污 / 缺件 / 错料 / 功能失效……
• 不良责任归属：来料问题 / 制程问题 / 设计问题 / 运输损坏 / 人为操作
• 处置方式：合格放行 / 让步接收 / 退货 / 返工 / 报废 / 待定

这三套字典决定了后面所有报表的质量。字典值一开始不必求全，但必须由质量部定稿后统一维护，不能让每个检验员自己填。填写时是下拉选择而不是自由文本，这一条要在建页面时就定死。

补充一个平台侧的便利：字典值改动不会破坏历史数据（存的是值编码），所以后期可以按需增补，不必担心前期定得太少。

三、检验单怎么建：主表 + 明细，一张单一次判定

主表：一次检验活动

建议的字段结构（这是给 AI 下指令时的描述清单，不必逐字照抄）：

• 单据编号：按"前缀 + 日期 + 流水"自动生成，例如 IQC20260812-003，不要人工填
• 检验类型：来料 / 过程 / 成品出货 / 退货复检（字典）——四类共用一张主表，比建四个模块好维护
• 触发来源：到货单号 / 生产工单号 / 发货申请号（引用字段，可空）
• 物料或产品：编码 + 名称（从基础档案带出，名称存快照）
• 供应商 / 客户：按检验类型联动显示，来料看供应商，出货看客户
• 批次号、生产日期
• 送检数量、实测件数、合格件数、不良件数（数值）
• 整批判定结果：待检 / 合格 / 让步接收 / 退货 / 报废（字典）
• 标准版本快照
• 检验员、检验时间；审核人、审核时间、审核意见
• 附件：外观照片、量具读数照片、外部检测报告
• 状态：草稿 / 待检 / 已判定 / 已审核 / 已关闭

明细子表：一行一个检验项目

明细不是"备注里写几句"。每一行对应标准表里的一个检验项目：项目名称、标准值与上下限（从标准带出并快照）、实测记录（多件时存一组读数）、单项判定（合格 / 不合格 / 不适用）、不良现象（字典多选）、不良数量、该行的照片。

主子表结构是平台原生支持的页面形态：主表页面下方直接挂明细表格，新增明细行时自动带上主表关联，不需要额外开发。这一点决定了实施顺序——先把标准表和字典建对，再建检验单，最后才做统计页。反过来做会返工。

让系统替你判一次

有了上下限和实测值，判定规则可以写成一句话交给 AI 构建器生成："明细行录入实测值后，若超出上下限则该行单项判定自动置为不合格；关键项出现任一不合格时，整批判定默认为退货且不允许改为合格，除非填写让步理由；其余情况按不良率是否超过设定阈值给出默认建议，检验员可覆盖但必须留原因。"

要强调一句：自动判定给的是默认值，人保留覆盖权，但覆盖必须留下痕迹。平台的审计日志会把改动记录下来，谁把"退货"改成"让步接收"、什么时候改的，事后能查。这比追求全自动更符合车间现实，也比纯手工可靠。

四、检验单从哪里来：三个触发点

很多质量系统失败在"检验员自己去建单"——忙起来就不建，数据永远不全。正确做法是让单据自己冒出来。

来料检验：到货即生单

如果已经做了采购到货 / 入库登记，那么到货记录一保存就生成一张待检检验单，推到检验员的工作台待办里。仓库侧的入库页面读取这张单的判定结果：未判合格的来料不能办理正式入库，只能进待检区库位。这个卡点是靠数据关系实现的——入库时校验关联检验单的状态字段，不通过就拦下并提示原因。

没有采购模块也能起步：先做一张最简的"到货登记"表（供应商、物料、批次、数量、到货时间），照样能触发生单。

过程检验：报工时抽检

生产工单每完成一道工序、员工报工的时候，按工艺要求生成过程检验任务。这里的关键是上道工序未检合格，下道工序不能开工，同样用状态校验实现。

成品检验：完工入库前卡住

成品完工后、入库前必须有一张已审核的出货检验单。这条卡点最有价值——它拦住的是真正会造成损失的那一步。

三个触发点的实现难度都不高，因为它们本质上是同一件事：在另一张业务表的保存动作上，检查关联检验记录的状态。区别只在触发时机和取哪张源单。

五、页面怎么用：不同角色看不同的三块

检验员：待办列表 + 一张录入页

登录后的工作台直接看到"待检 N 单"。点开是主子表页面：上半部分是送检信息（已带出，不用填），下半部分明细行已经按标准版本自动展开成若干行——检验员只填实测值、选不良现象、拍照。整批判定由系统给默认值。

这里有个体验细节值得在建页面时提出来：明细行自动展开。如果每张单都要检验员手工加十几行项目，没人愿意用；从标准表按对象带出，才真正省时间。

质量主管：审核页 + 统计页

审核页列出"已判定待审核"的单，能直接看到哪些是关键项不合格、哪些被人工覆盖了默认判定（这些要显眼标出）。

统计页建议做四张，都是业务人员每天真正会看的：

• 供应商来料合格率排行：按供应商 + 月份分组，列送检批次、合格批次、让步批次、退货批次。这是采购谈判的直接弹药。
• 不良原因 Pareto：按不良现象字典统计发生次数与涉及数量，降序排列，一眼看出该先解决哪一类。
• 物料 / 产品不良趋势：按周或月看某颗关键物料的不良率走势，判断改善有没有效。
• 检验工作量：按检验员和日期统计单量与平均判定时长。

平台的报表能力支持这种分组小计与合计行的呈现，数据量大时用游标分页（一种翻页方式，比一次性拉全表更稳）保证页面不卡。需要给外部审核用的报表可以直接导出。

采购 / 生产 / 仓库：只读联查

这三个角色不需要进质量模块找单子。做法是在他们自己的页面里挂一个联查区：采购订单详情页显示该单历次来料检验结果；生产工单页显示各工序过程检验状态；入库单页面显示关联检验单的判定结论。引用字段 + 联查视图让质量结论出现在决策发生的地方，而不是让人去跑办公室。

权限上，这三类角色给只读即可。平台的角色权限配置支持按模块、按操作粒度授权，也能限制可见的数据范围（比如车间只看本产线的单）。

六、移动端：车间里的检验才是真检验

量具在车间，产品在产线旁，纸质记录回到办公室才补录——数据永远滞后且失真。移动端的价值就在这里。

PC 端构建好的检验模块会自动同步到移动端，不需要为手机单独再做一遍。检验员在手机上的实际动线是：

1. 打开工作台，看到待检任务
2. 扫码或搜索进入这张检验单
3. 逐项录入实测读数，超差的项目当场标红
4. 拍外观照片直接附到对应的明细行上
5. 提交判定，单据立刻流转到主管待审核

拍照这个动作在手机上比在电脑上自然得多，这也是移动端带来的额外收益：不良现象第一次有了图像证据，后续和供应商扯皮、和客户解释让步理由时不再是空口。

外检报告、客户图纸这类文件同样通过平台的文件上传能力挂在单据上，本地存储和对象存储都支持。

如果检验员手上已有 Excel 的历史检验记录，平台支持表格导入把存量数据灌进新建的表，不必从零开始积累。## 七、让步接收与退货：流转要留证据链

判定不是终点，处置才是。质量模块最容易出问题的地方是"让步接收"——它天然是个灰色口子，管不好就从检验系统退化成盖章机器。

让步接收必须有第二个人签字

数据上的做法：整批判定为"让步接收"时，单据必须额外填写让步理由（为什么可以放行）和限制条件（这批只能用于哪个订单 / 是否需客户书面认可），并且走一次审批才能生效。平台的工作流能力（审批流 / 状态机定义）可以直接挂在这张表的状态字段上：已判定 → 提交让步审批 → 通过则置为让步接收生效，驳回则退回重判。

不要嫌这一步麻烦。让步批次一旦流入客户端引发投诉，能拿出"当时谁批准、依据什么批准"的记录，性质完全不同。

退货要回写到源头

退货判定生效后，需要能反向影响来源单据：来料退货要把到货单标记为待退货并通知采购；成品退货要生成返工或报废任务。这类"满足某条件就自动改另一张表"的联动，由平台的数据流规则引擎承担，不需要写代码，配置条件和动作即可。

同时别忘了库存侧的动作：不合格品要移到隔离库位，不能和合格品混放。如果已有仓库模块，这里就是让检验结论去驱动一次移库。

状态一定要收口

一张检验单的合法路径应该是有限的几条，其他跳转全部禁止。把状态机画清楚再交给 AI 生成，比事后修补便宜得多。终态建议只有三个：合格放行、让步接收生效、退货 / 报废生效。任何"已关闭但没判定"的状态都是漏洞。## 八、上线前查这七件事

质量模块一旦开始拦人，出错就会影响生产节奏。发布前用这份清单过一遍：

1. 标准表覆盖度：抽 10 颗常检物料，看是否每颗都有生效版本的检验项目标准，且上下限都是数字而非文本。缺标准的物料先不要接入卡点，否则到货会全堵在待检区。
2. 字典用词：不良现象、责任归属、处置方式三套字典由质量部定稿，页面上确认这些字段是下拉选择，不是自由输入框。
3. 判定逻辑试算：造三条测试数据——全部合格、非关键项超差、关键项超差——逐条核对系统给出的默认判定和整批结论是否符合预期。这一步不能省。
4. 卡点范围：入库拦截是"硬拦"还是"提示后可继续"？建议首月先软提示（弹窗警告但允许有权限的人放行），跑顺了再改硬拦。直接上硬拦最容易引发一线抵触。
5. 明细自动展开：新建一张检验单，确认选完物料后明细行按标准自动生成，不需要手工添加。
6. 移动端实测：拿真机走一遍完整动线，重点验拍照上传与超差标红。车间网络环境下也要测一次。
7. 权限与留痕：确认采购 / 仓库角色只读；随便改一张已审核单据的判定结果，去审计日志里看能不能查到改动前后值和操作人。

平台的模块发布预检会在提交发布时做一轮静态检查，把报错和警告处理干净再挂菜单，避免线上出现打不开的页面。

九、这套东西能延伸到哪里

检验模块的价值不止于质量部。数据结构立起来之后，往几个方向延伸都很自然：

• 接供应商管理：来料合格率排行直接成为供应商评级依据，配合供货记录形成档案。
• 接设备点检：过程不良若集中在某台设备，与设备点检、维修记录联查就能看出相关性。
• 接生产工单：各工序的过程检验结果汇总到工单上，形成这批产品的完整质量履历，客户要求提供批次报告时一键导出。
• 接客户投诉：新增一张客诉登记表，关联到出货检验单，把"客户说的不良"和"我们检出的不良"对起来看，判断是漏检还是运输环节问题。
• 接追溯：批次号贯穿来料检验、过程检验、成品检验三张单，正向反向都能查。

建议的实施顺序始终是：先标准与字典 → 再检验单主子表 → 然后统计页 → 最后加卡点和工作流。卡点最见效也最伤感情，等前面几步的数据被大家认可了再加，阻力小得多。

从一张纸质检验单到一个能自动判定、能拦人、能出 Pareto 图的质量闭环，需要描述给 AI 的业务语言其实就是一句话："我有哪些物料要检、每项检什么、上下限多少、检完怎么判、判完谁签字、不签不让走。"把这六件事说清楚，系统就长出来了。