1. 课程导入与验收交付全景
在机器视觉项目中，调试成功并不等于项目结束。很多工程师都有过类似经历：现场图像稳定、识别率达标，但客户迟迟不签字，尾款一拖再拖。问题往往不在技术本身，而在于验收与交付这一环节没有被当作一个独立的工程阶段来管理。本课程围绕 Cognex In-Sight 系列智能相机，系统讲解从现场调试完成到客户正式签收的全过程。
一、什么是 In-Sight 项目验收与工程交付
验收是指依据合同、技术协议或双方确认的验收标准，对视觉系统的功能、精度、节拍、稳定性进行可重复的验证，并形成书面结论的过程。工程交付则是把一套可运行、可维护、可追溯的视觉系统完整移交给客户的过程，它包含硬件、软件、文档、培训与知识转移。
两者关系可以这样理解：验收回答"系统是否达标"，交付回答"客户是否能独立用好这套系统"。只做验收不做交付，客户拿到的是一个"黑盒"；只做交付不做验收，双方对"是否达标"永远各执一词。
对 In-Sight 项目而言，交付物通常包括：相机与镜头/光源的安装位置与型号记录、Job（作业）文件与固件版本、通信配置（如 Ethernet/IP、PROFINET、TCP/IP 字符串、Modbus TCP）、标定数据、验收测试报告、操作与维护手册、备件清单。这些内容缺一项，后期维护成本就会成倍上升。
二、验收交付的目标与参与角色
验收交付的核心目标有三个：可验证——每一项指标都有明确的测试方法和判定阈值；可复现——换一个班次、换一名操作员，结果一致；可追溯——出现争议时能查到当时的配置、版本与测试数据。
典型参与角色包括：视觉工程师（负责调试与测试）、电气/机械工程师（负责触发信号、剔除机构、安装刚性）、客户生产与质量人员（负责确认节拍与判定标准）、项目经理（负责进度与签字流程）。实际项目中最容易被忽略的是客户质量人员，而他们往往掌握最终判定权，因此验收标准必须在项目早期就与其对齐。
三、从现场调试到客户签收的典型流程
下面这张图给出了 In-Sight 项目验收交付的完整认知地图，从调试完成一路走到客户签收与质保启动，并标注了每个阶段的关键输出与常见风险点。
四、验收标准怎么定才不扯皮
验收争议的根源，几乎都出在标准定义上。以最常见的"识别率"为例，如果只写"识别率 99%"，双方理解可能完全不同：是单次测试 100 件中 99 件正确，还是连续 8 小时运行统计？缺陷件算不算分母？
建议在技术协议中把指标写成可执行的形式，例如：
指标名称：字符识别准确率
测试样本：良品 500 件 + 缺陷件 50 件（缺陷类型覆盖划伤、缺字、错字）
判定方式：良品误判为 NG 的数量 ≤ 5 件；缺陷件漏判为 OK 的数量 = 0
测试条件：产线正常速度，环境光照稳定，连续运行 2 小时
统计口径：以 In-Sight 输出的 Pass/Fail 结果与人工复判结果比对
这样写的好处是：测试样本数量、缺陷类型、判定阈值、测试条件、统计口径全部明确，验收时只需按表执行，不需要现场"再商量"。
五、验收测试报告应包含什么
一份可用的验收测试报告，至少应包含以下字段，建议直接做成表格模板在项目启动时就发给客户确认：
| 字段 | 说明 | 示例 |
|---|---|---|
| 测试项目 | 被验证的功能或指标 | 字符识别准确率 |
| 测试方法 | 如何执行、用什么样本 | 500 良品 + 50 缺陷件，连续 2 小时 |
| 判定标准 | 合格阈值 | 误判 ≤ 5 件，漏判 = 0 |
| 实测结果 | 实际统计数据 | 误判 2 件，漏判 0 件 |
| 结论 | 合格 / 不合格 / 有条件通过 | 合格 |
| 测试人 / 日期 | 责任人与时间 | 张工 / 2025-03-12 |
| 客户确认 | 客户签字或邮件确认 | 李主管（签字） |
六、交付阶段的知识转移
交付不是把文件拷给客户就结束。真正有效的知识转移至少包括三件事：
- 操作培训：如何开机、切换 Job、查看结果、处理报警、日常清洁镜头与光源。
- 维护培训：如何备份与恢复 Job、如何查看固件版本、如何判断相机与 PLC 通信是否正常。
- 应急处理：常见故障（图像模糊、触发丢失、通信超时）的排查顺序与联系人。
培训完成后应留下签到表与培训记录，这既是交付凭证，也是质保期内判断"是设备问题还是操作问题"的重要参考。