先定义案例边界
案例开始时记录产品、相机、光源、节拍、数据来源和缺陷定义。不要只写“提升准确率”，而要说明误检和漏检分别会带来什么业务影响，以及最终由谁验收。
| 记录项 | 建议内容 | 为什么重要 |
|---|---|---|
| 产品与工位 | 产品型号、工位、相机和照明 | 限定图像分布和可迁移范围 |
| 缺陷类别 | 缺陷名称、严重等级、是否允许共存 | 决定标签规范和验收样本 |
| 样本规模 | 图片数、缺陷实例数、正负样本比例 | 避免用少量样本代表整条产线 |
| 数据划分 | 训练、验证、测试的时间或批次边界 | 防止同一批次泄漏到多个集合 |
| 验收口径 | 漏检率、误检率、延迟、吞吐和稳定运行时间 | 让模型指标与业务决策对应 |
在 IndVis 中形成数据闭环
01
建立项目和标签规范
按产品或工位建立项目，明确矩形、分割、关键点或分类任务，记录每个缺陷的边界和排除规则。
02
导入并分层抽样
导入不同批次、班次、光照和缺陷程度的图片，按批次或时间留出独立测试集。
03
协同标注与质检
让标注员执行初标、审核员抽检和返工闭环，重点处理边界模糊、缺陷共存和无缺陷样本。
04
训练、比较和登记
记录模型系列、输入尺寸、数据版本和训练配置，在同一测试集上比较，再将候选权重登记到模型库。
05
上线前回放验证
使用真实产线回放或旁路数据验证误检、漏检、延迟和异常恢复，确认模型版本与标签顺序一致。
性能如何写得可信
公开案例应同时给出评估数据和条件：测试集来源、图片分辨率、硬件、批大小、置信度阈值、后处理规则和统计时间。mAP、Precision、Recall 适合描述模型，误检率、漏检率、节拍和稳定运行时间更接近产线验收。
不使用脱离条件的单一数字
不同模型、数据集、输入尺寸和设备之间不能直接横向比较。没有经过双方确认和复测的数据，不应写成平台固定性能承诺。