4. 原因码字典与元数据管理

原因码字典是 Andon 系统的“语义底座”。如果字典只维护一个编码和一句名称，现场看到的就只是一个编号，系统也无法据此自动派单、计算 SLA、统计责任部门绩效。要让原因码真正驱动处置流程，必须把它当作一条结构化元数据记录来管理：编码是主键，名称是现场语言，描述是判定边界，责任部门决定派单对象，默认处置路径决定下一步动作，生效范围决定它在哪些产线/工位/产品上可用，版本管理则保证历史数据可追溯、变更不破坏已发生的事件。

下面这张图展示了一条原因码记录从“字典定义”到“现场事件”再到“SLA 计算”的元数据依赖关系。可以看到，责任部门和默认处置路径并不是孤立字段，它们直接决定了事件生成后的派单对象与计时起点。

编码：稳定主键，不承载语义

编码是原因码的唯一标识，一旦发布就不应随名称或责任部门变化而修改。推荐采用“域-类别-序号”的分段结构，例如 EQ-MECH-014：EQ 表示设备类，MECH 表示机械子类，014 为顺序号。这样编码本身可读、可排序，但又不把“主轴异响”这种具体语义写死。如果编码里嵌入了部门名（如 MECH-014），一旦责任部门调整，编码就面临两难：改编码会破坏历史数据关联，不改则编码与现状不符。因此编码只做分类和序号，语义交给名称和描述。

名称与描述：现场语言与判定边界

名称是操作工在 Andon 终端上看到并选择的短标签，应控制在 6~10 个汉字，使用现场通用说法，例如“主轴异响”而不是“主轴运转异常噪声”。描述则承担判定边界职责，必须写清楚“什么情况算、什么情况不算”。以 EQ-MECH-014 为例，描述可写为：“主轴运转时出现周期性金属摩擦声，排除刀具与工件碰撞、排屑器刮擦后仍存在。”这条描述直接决定了操作工是否会选这个码，也决定了后续统计口径是否一致。描述中应避免“异常”“不良”等无法判定的词，尽量用可观察的现象、部位、条件来界定。

责任部门与默认处置路径：派单与动作的绑定

责任部门字段决定事件生成后自动派给谁。它通常是一个组织编码，如 MECH、ELEC、QUAL、PE，而不是具体人名。默认处置路径则决定事件进入后的标准动作序列。以 EQ-MECH-014 为例，默认路径可定义为：停机 → 报修 → 主轴检查 → 更换轴承/皮带 → 试运行确认。这条路径不是强制流程，而是默认建议，现场可根据实际情况调整，但调整应记录原因。责任部门和默认路径共同决定了 SLA 的计时起点和升级对象：如果责任部门是设备维修组，响应时限通常从事件创建时刻开始计算；如果路径第一步是“操作工自检”，则响应时限可能从自检完成时刻开始。

生效范围：避免“全厂通用”的误用

生效范围定义该原因码在哪些产线、工位、设备型号或产品族上可用。如果不加限制，操作工可能在一条没有主轴的装配线上看到“主轴异响”选项，造成误选。生效范围可以用“包含”和“排除”两种方式表达。例如 EQ-MECH-014 的生效范围可写为：包含 CNC-01~08、精加工车间；排除 CNC-09（该设备为磨床，无主轴结构）。在 Andon 终端上，系统应根据当前工位或设备自动过滤可选原因码，只展示生效范围内的条目。这样既减少误选，也降低操作工的学习负担。

版本管理：变更可追溯，历史不篡改

原因码字典的变更必须版本化。每次修改名称、描述、责任部门、默认路径或生效范围，都应生成新版本，并记录变更人、变更时间、变更原因和生效时间。关键原则是：历史事件绑定的是事件发生时的字典版本快照，而不是最新版本。例如 EQ-MECH-014 在 v2.0 中责任部门为“设备维修组”，v2.1 中调整为“设备维修组+工艺支持组”，那么 2025-03-01 之前的事件仍按 v2.0 的责任部门统计，之后的事件按 v2.1 统计。这样才能保证 SLA 达成率、部门绩效等指标在时间轴上可比、可审计。

一份可直接参考的原因码字典字段定义

把上述字段落到实际系统中，还需要注意两个工程细节。第一，责任部门和默认路径应使用编码而非中文名，中文名只用于显示，这样组织调整或路径改名时不需要批量改字典。第二，生效范围的匹配逻辑应放在 Andon 终端或边缘服务中，而不是让操作工自己判断。例如终端读取当前工位绑定的设备编号 CNC-03，再请求字典服务返回该设备可用的原因码列表，字典服务根据 scope_include 和 scope_exclude 做过滤。这样即使字典有上千条，操作工看到的也只是与当前工位相关的十几条，选择效率和准确率都会明显提升。

最后，版本管理不只是技术字段，更是一种数据治理约定：任何对已发布原因码的修改都必须走变更流程，生成新版本，并明确生效时间。历史事件永远引用当时的版本快照，统计报表按事件发生时间对应的版本口径计算。这样，原因码字典才能既支撑现场快速选择，又支撑管理层做跨时间、跨部门的可靠分析。