1. 无"绝对标准"的端面

做过光模块和光纤连接器的人都有一个共同体会：端面检测这件事，最难的不是"看不看得见"，而是"算不算合格"。

以 MPO/MTP 多芯连接器为例，同一根 FAU（Fiber Array Unit）端面，在 A 客户那里是良品，发到 B 客户那里可能直接被判报废。原因并不复杂——光通信行业至今没有一套全球统一的端面验收标准：

• 电信运营商（如国内三大运营商、海外 Tier1 运营商）通常沿用 IEC 61300-3-35 的框架，但对划痕、凹坑的容忍度相对宽松，更关注回波损耗和插入损耗的最终表现；
• 互联网大厂 / 数据中心客户对高密度 MPO 链路极其敏感，往往在 IEC 基础上加严，划痕长度、污染面积都卡得更死；
• 海外客户（尤其是欧美日客户）常有自己的企业标准，甚至直接引用自家实验室的判定细则，颗粒度细到"单根光纤 vs 整个端面"的统计口径都不同。

于是就出现了最尴尬的场景：

同一根光纤，在这个厂是良品，发到另一个客户那里就被退货。

对产线来说，这意味着返工、客诉、甚至整批退货；对质量部门来说，这意味着"合格"这个词本身失去了确定性。问题的根源不在检测设备的分辨率，而在判定规则的管理方式。

2. 传统做法

大多数早期视觉检测系统，判定逻辑是写死在代码里的。看似简单，实际埋了三个坑：

2.1 规则硬编码

典型的硬编码写法是这样的：程序里直接写死一条判断——如果缺陷类型是划痕且长度超过 3 微米，就判 NG；如果缺陷类型是污染且面积超过 500 平方微米，也判 NG；其余情况一律判 OK。这些数字和条件全部嵌在业务代码的分支语句里，与检测流程紧紧绑在一起。
当 B 客户要求划痕 < 2μm 时，工程师只能改代码、重新编译、重新测试、重新上线。一次标准变更，牵动研发、测试、产线三方，周期以周计。

2.2 定制化系统

为了同时满足 A、B 两个客户，常见做法是部署两套系统或者维护两个分支版本。结果是：

• 维护成本翻倍，bug 修一处要同步两处；
• 现场操作员容易选错程序，把 A 客户的规则用在 B 客户的订单上；
• 历史数据口径混乱，追溯时说不清当时用的是哪套标准。

2.3 报告格式

A 客户要 Excel，B 客户要 PDF，海外客户要英文模板加特定字段顺序。每来一个新客户，就要单独开发一套报告导出逻辑，质检报告成了定制开发的泥潭。

3. 可配置规则引擎

核心思想只有一句话：把判定规则从"写死在代码里"变成"可配置的规则引擎"。

系统架构上，把原来耦合在一起的"图像处理"和"合格判定"彻底拆开：

关键变化在于：检测层只负责"客观描述看到了什么"，判定层负责"按谁的规矩算合格"。

检测层输出的是与标准无关的结构化缺陷特征，例如：

检测层输出的是一份与标准无关的结构化缺陷特征清单：先标明这是第几号光纤，再逐条列出每个缺陷的类型（划痕还是污染）、量化指标（划痕的长度与宽度、污染的面积）、以及它落在端面的哪个区域（纤芯区还是包层区）。整份数据只描述"看到了什么"，不含任何合格与否的判断。
判定层拿到这份"体检报告"，再套用不同客户的规则集，得出不同结论。同一份检测数据，可以同时算出多个客户的判定结果——这正是解决"一根光纤两种命运"的技术基础。

4. 规则引擎怎么设计

4.1 规则的数据模型

一条判定规则，本质上是「作用域 + 条件 + 结论」的三元组：

把规则写成配置后，A 客户和 B 客户的差异就变成了两份配置文件的差异。

A 客户的规则集标注客户为 A、版本为 2024.1，其中包含两条规则：一是单根光纤上的划痕长度若超过 3 微米则判 NG，二是单根光纤上的污染面积若超过 500 平方微米则判 NG。

B 客户的规则集标注客户为 B、版本为 2024.3，规则条目与 A 客户完全同构，只是阈值更严：划痕长度超过 2 微米即判 NG，污染面积超过 300 平方微米即判 NG。

可以看到，两份配置的差别仅在于几个数字，规则的结构、字段和语义完全一致。
改标准 = 改配置，不发版、不停线、不碰代码。

4.2 规则引擎的执行逻辑

规则引擎的执行逻辑可以这样理解：

引擎初始化时，先把当前生效的规则集读进来，把其中的规则列表保存在内部。

判定时，引擎接收一份检测结果，然后做一次"规则 × 缺陷"的双重遍历：对每一条规则，逐个检查检测结果中的每个缺陷；如果缺陷类型与规则关注的类型不一致，就跳过；如果缺陷上缺少该规则所需的度量指标，也跳过；只有当指标存在且满足规则设定的比较条件（小于、小于等于、大于、大于等于或等于阈值）时，才记录一条命中，并把该规则对应的结论（NG、WARN 或 OK）一并留存。

遍历结束后做汇总：只要有任何一条结论为 NG 的规则被命中，整体判定即为 NG；否则判为 OK。最终输出包含整体结论和全部命中明细两部分，明细里保留了是哪条规则、命中了哪个缺陷、给出了什么结论，便于后续追溯与解释。

这段逻辑的价值在于：它永远不需要为某个客户修改。客户差异全部沉淀在规则集里，引擎本身只负责"照着规则算"。
这段代码的价值在于：它永远不需要为某个客户修改。客户差异全部沉淀在rule_set里。

4.3 规则集的版本管理

规则一旦可配置，就必须可追溯。建议给每个规则集打上「客户 + 版本 + 生效时间」三元标识：

• 每次修改生成新版本，旧版本只读保留；
• 每条检测记录都绑定当时使用的rule_set_id；
• 客诉追溯时，能精确还原"当时是按哪版规则判的"。

这一点在应对客户审核时尤其重要——能拿出规则版本和判定记录，比口头解释有说服力得多。

5. 自动切换

规则可配置只是第一步，更关键的是系统要能自动判断当前该用哪套规则，而不是靠操作员手动选。

5.1 三种触发方式

1. 工单驱动：MES 下发工单时携带客户标识，系统自动加载对应规则集；
2. 扫码驱动：操作员扫描产品条码或工单二维码，系统解析出客户与产品型号，匹配规则；
3. 接口驱动：与 MES/ERP 打通，实时接收当前生产任务的客户信息。

5.2 防错设计

自动切换最大的风险是"切错了"。建议加两道保险：

• 界面强提示：当前生效的客户规则以醒目方式显示在检测界面顶部，操作员一眼可见；
• 首件确认：换型后的第一件产品，要求人工确认判定结果与客户标准一致，确认后才放行批量检测。

6. 报告自动生成

判定结果出来后，报告生成同样要"可配置"。思路是把报告拆成数据层 + 模板层：

• 数据层：判定结果、缺陷明细、图像证据、规则版本，统一输出为结构化 JSON；
• 模板层：每个客户一套模板（字段顺序、语言、格式、是否附图像），用模板引擎渲染。

具体做法是维护一张"客户 → 报告模板文件"的映射表：A 客户对应中文模板，B 客户对应另一套中文模板，海外客户对应英文模板。生成报告时，先根据当前客户取出对应的模板文件并加载，再把本次的判定结果作为数据传入模板进行渲染，得到一份填好内容的报告；如果需要 PDF 或 Excel，再在渲染结果的基础上做一次格式转换即可。
新客户来了，只需要新增一个模板文件，不用改一行判定逻辑。

7. 落地建议

1. 先统一"缺陷定义"，再谈阈值差异。不同客户对"划痕"的界定（是否含交叉划痕、是否计入边缘区域）可能不同，规则引擎的defect_type必须先把语义对齐，否则阈值可比性无从谈起。
2. 规则配置要有审核流程。规则可配置意味着"谁都能改"，必须配套权限控制和变更审批，避免误改导致批量误判。
3. 保留原始检测数据。判定规则会变，但原始图像和缺陷特征不应随规则变化而丢失，这是后续复盘和算法迭代的基础。
4. 灰度验证。新规则上线前，用历史数据回放一遍，对比新旧规则的判定差异，评估影响面。
5. 规则与算法解耦但要对齐。检测算法升级后，缺陷特征的分布可能变化，规则阈值需要重新校准。

8. 小结

“同一根 FAU 端面，A 客户判合格、B 客户判报废”，表面看是标准不统一的问题，本质上是判定逻辑与检测能力耦合过深的问题。

把判定规则从代码里抽出来，做成可配置、可版本化、可自动切换的规则引擎，再配上模板化的报告生成，系统就能做到：

• 一套检测硬件，服务多个客户；
• 改标准不改代码，配置即生效；
• 一份检测数据，多种判定结论，多种报告格式；
• 每一次判定都可追溯、可解释、可审计。

在光通信这种"标准跟着客户走"的行业里，检测系统的柔性，往往比检测精度更能决定它能不能真正落地。