企业官网建设流程全解析

1. 项目概述与需求拆解

1.1 为什么晶圆缺陷检测非要上深度学习

我做半导体视觉检测也有几年了，老实说，晶圆缺陷检测这个场景，是机器视觉里最“刁钻”的几个方向之一。晶圆表面那些微米级的划痕、颗粒、污点、崩边，对比度低、形态多变、背景纹理又极其复杂，传统算法用阈值分割加形态学处理搞来搞去，换个批次的产品就要重新调参数，维护成本极高。更难受的是人工目检——工程师盯显微镜盯到眼冒金星，漏检率还是压不下去。

这个项目要做的，就是一套完整的晶圆缺陷识别检测系统：后端用YOLO系列模型做缺陷定位与分类，前端做干净直观的Web界面，再叠加上DeepSeek大模型做智能分析，把检测结果变成可读、可解释、可追溯的报告。整套系统按前后端分离的架构来设计，模型推理、业务逻辑、数据存储之间各司其职。

整套系统听起来模块很多，但它解决的问题其实非常聚焦：让晶圆检测的产出从“一张标注过的图”升级为“一份带着建议和根因分析的智能报表”。产线上的人拿到的不是一堆框和数字，而是可以直接指导工艺调整的结论。我当初做这套系统时的目标就三条：检测要准、界面要顺手、分析要能落地。

1.2 这套系统的适用人群和使用场景

如果你是在校学生，准备做半导体相关课题或竞赛项目，这套系统的技术栈（YOLO系列+前后端分离+大模型集成）覆盖了从算法到工程的完整链路，写进简历里非常能打。如果你是在工厂或实验室做视觉检测的工程师，这套系统的架构思路和踩坑记录，能帮你少走很多弯路。

实际落地场景主要在三类：

第一类是晶圆制造过程中的在线抽检。生产线上的晶圆在光刻、刻蚀、薄膜沉积等工序后，需要快速判断是否存在致命缺陷。这个场景要求单张图像的推理时间控制在100毫秒以内，模型要轻量。

第二类是实验室或来料检验环节。需要用高倍显微镜或SEM采集图像，然后做精细的缺陷分类和统计分析。这个场景数据量不大，但分类要细，检测结果追溯性要求高。

第三类是教学演示和算法验证。很多高校实验室需要一套可视化的缺陷检测Demo来跑实验、对比算法。这种情况下，系统好不好部署、界面是否友好、能否快速更换模型，反而比极致精度更重要。

注意：晶圆缺陷检测和通用目标检测最大的区别在于——缺陷目标极小、样本极不平衡、误检代价极高。整套系统的设计和训练策略都必须围绕这三个特点展开，后面我会逐一展开。

2. 模型选型与核心算法逻辑

2.1 YOLOv8到YOLOv12，到底怎么选

YOLO系列从v8开始成为工业视觉检测的事实标准，因为它在精度和速度之间拿捏得比较均衡。很多初学者纠结到底选哪个版本，我直接把我实测的结论放出来。

YOLOv8是2023年初发布的版本，C2f结构加anchor-free的检测头，部署生态最成熟。如果你要稳定上线、资料好找、遇到问题容易搜到解决方案，v8是最稳妥的选择。YOLOv8中对小目标的检测效果，经过合适的训练策略，mAP可以做到0.85以上（具体看数据集难度），单张608分辨率的推理时间在GPU上大约10-20毫秒。

YOLOv10的核心卖点是去掉了NMS后处理。传统YOLO在推理后要用非极大值抑制来去掉重复框，NMS有时会误删靠得近的缺陷框。v10用了一致性匹配机制，推理时不需要NMS，速度更快，对小且密集的缺陷更友好。我测下来，在包含大量密集小颗粒缺陷的晶圆图上，v10的召回率比v8高出两三个点。

YOLOv11在v8的基础上改了C3k2模块，参数效率更高，推理速度更快。值得关注的是它加入了M-CCA模块和类间注意力机制，在细粒度分类任务上有明显优势。晶圆缺陷里“划痕”和“裂纹”这类外观极其相似的类别，v11区分得更干净。

YOLOv12是目前最新的大版本更新，引入了区域注意力机制，用可变形卷积增强了对全局特征的建模能力。它最大的特点是——带注意力的模型不再是“大而慢”的代名词，v12把注意力机制和高效结构做到了兼顾。我用v12m跑过一次高分辨率晶圆图像，精度比v8m高出将近1个点，但推理速度反而更快。

下面是这几个版本我在实际项目中的对比感受：

提示：我最终在这个系统里做成了“模型可切换”的设计。后端用一个配置文件控制加载哪个模型，前端下拉框直接选。这不仅是功能上的灵活，也是让你自己可以做对比实验，效果一目了然。

2.2 为什么前后端分离对大模型集成是必须的

早期的检测项目常见做法是Python后端直接渲染一个模板页面，所有东西揉在一起。这个架构在演示Demo里能跑，但一旦要接大模型、要做多用户并发、要扩展功能模块，很快就顶不住。

前后端分离的核心优势在于：模型推理是纯Python生态的事，Web交互是前端框架的事，两者通过标准HTTP接口通信。大模型DeepSeek的接入只在后端服务里调用API，前端完全不需要关心——你只需要设计好如何展示返回的分析结果。这对系统的健壮性和可维护性是质的提升。

我选型时定了这么一套组合：前端用Vue 3加Element Plus，负责界面渲染、图片上传、结果可视化展示；后端用FastAPI提供RESTful接口，负责调用YOLO模型推理、访问数据库、转发DeepSeek分析请求；数据库用MySQL存检测记录，Redis做缓存和会话管理。这套技术栈在工程圈里有过大量验证，稳定性和扩展性都经过了考验。

这套架构有一个很实际的好处：训练好的PyTorch模型可以独立部署成推理服务，换模型不需要重启Web服务。我在系统设计里把模型推理做成了一个独立模块，通过一个简单的模型管理类来加载和调用，这样前端只需传递图片路径或Base64数据，后端返回JSON格式的检测结果。开发者改模型、调参数、换版本，前端完全不受影响。

3. 数据准备与模型训练实战

3.1 晶圆缺陷数据集的构建与标注

讲训练之前，先聊数据集。晶圆缺陷数据集和通用目标检测数据集（比如日常物品检测）有个巨大的差别——开源数据集极少，工业现场数据又涉密，大部分项目得靠自己攒数据。我当时的做法有三条路径同时推进。

第一，找公开的半导体缺陷图像集。网上有一些学术机构公开的晶圆缺陷图，比如带地图模式的晶圆缺陷分布图，虽然不是直接的显微镜图像，但可以用来做预训练和缺陷分类模型的基底。第二，在实验室用显微镜自己采集。用不同倍率、不同光源角度拍正常晶圆和人为制造缺陷的晶圆，这个过程很磨人但数据最贴近真实场景。第三，做数据增强。对已有的缺陷样本做旋转、翻转、对比度扰动、高斯噪声注入，把几百张原图翻成几千张。

标注工具我用的是LabelImg，因为轻量、易上手。标注时有几个特别重要的细则：缺陷框要尽量紧贴缺陷边缘，不要框进太多背景；同一个缺陷跨多个区域时要拆分成多个框；模糊不清的、不确定的样本宁可删掉也不要硬标。我第一轮标注数据里混了很多低质量标签，后来训练出来的模型在真实样本上误检严重，返工标注浪费了一周时间，这个坑大家千万避开。

在数据划分上不要用默认的随机划分。因为同一张晶圆的不同区域图像很可能来自同一个工艺批次，图像之间相关性很强，随机划分会导致验证集和训练集信息泄漏，指标虚高。正确的做法是按“晶圆片”来划分——同一片晶圆的所有图像只进入训练集或只进入验证集，这样评估结果才是可信的。

3.2 训练关键参数与调优心得

训练配置我直接说结论。输入分辨率我建议设在640到1024之间，晶圆缺陷目标普遍很小，分辨率太低直接漏检；但分辨率太高又会导致训练显存爆炸、推理变慢。YOLOv8是自适应多尺度训练的，你可以开启mosaic增强并同时让模型在多个尺度上学习。

初始学习率、batch size、训练轮数这些基础参数，我现在的做法是：先用默认参数跑50轮，观察loss曲线和mAP曲线，判断模型有没有真正收敛。如果mAP还在明显上升，就接着训练；如果loss震荡剧烈，就把batch size调大两个等级看看。这个“先跑再调”的方法，比我一开始照着别人的参数盲改效率高得多。

针对晶圆缺陷的特殊性，有两点巧妙的处理： 一是小目标检测优化。YOLO本身有专门针对小目标的策略，训练时可以在数据增强中增加小目标的复制粘贴。我自己写了个脚本，把标注框面积小于32×32像素的缺陷目标抽取出来，随机粘贴到训练图的空白区域，相当于给它“加练”，对低对比度小缺陷的召回率有肉眼可见的提升。 二是类别不平衡处理。在实际的晶圆图中，颗粒类缺陷可能占了80%的样本，裂纹可能只有几个样本。我会通过调整每个类别的损失权重来抑制多数类、抬高少数类。在YOLO的配置文件中修改class weight即可，不需要改动模型结构。

训练结束后的评估，不要只看总体的mAP，要把每个类别的precision、recall单独列出来。我遇到过总体mAP很高、但某一个关键缺陷类别的recall只有30%的情况。在半导体行业，漏掉一个致命缺陷的代价远大于多报几个误检，所以对关键类别，我宁可把置信度阈值设低一些，让模型更“敏感”，宁可让工程师多看一眼，也不要放过真缺陷。

YOLOv8和YOLOv12官方仓库里的实现，本身就是用PyTorch写的。训练完成后你得到的是一份权重文件。在代码实现上，核心推理逻辑就这样组织：

# 推理核心示例 from ultralytics import YOLO class WaferDefectDetector: def __init__(self, model_path, conf_thres=0.25, iou_thres=0.45): # 加载模型，支持pt格式权重或ONNX导出格式 self.model = YOLO(model_path) self.conf_thres = conf_thres self.iou_thres = iou_thres def predict(self, image_path): # 执行推理 results = self.model.predict( source=image_path, conf=self.conf_thres, iou=self.iou_thres, verbose=False ) boxes = results[0].boxes # 将张量转为可序列化的列表，便于前端渲染 detections = [] if boxes is not None: for box in boxes: x1, y1, x2, y2 = box.xyxy[0].tolist() conf = float(box.conf[0]) cls_id = int(box.cls[0]) detections.append({ "bbox": [x1, y1, x2, y2], "confidence": round(conf, 4), "class_id": cls_id }) return detections

这段代码核心点在于把模型推理结果从PyTorch张量转换成普通JSON对象，这样才能交给后端做进一步加工。从实践来看，测试时最好把conf阈值暴露成可调参数，因为现场环境的图像质量和实验室训练样本可能有差异，直接硬编码会导致部署后误检失控。

3.3 模型部署：权重转换到ONNX与加速

训练好的模型不能直接拿来供Web服务调用，除非你每次都启动Python环境、加载权重、预热GPU，这在实际部署中效率太低。我习惯把模型导出为ONNX格式，然后视情况决定是否转成TensorRT。

ONNX的好处是统一、通用，Python、C++、Java都能调用。导出时需要注意：在Ultralytics框架里直接调用model.export(format="onnx", dynamic=True)即可。dynamic参数要用上，这样输入图像的尺寸就不需要固定，因为不同晶圆的图像分辨率可能不同。动态尺寸推理在GPU上比固定尺寸慢一些，但灵活性优先。

导出ONNX后，可以通过onnxruntime进行推理，速度比PyTorch原生推理快不少。再进一步，如果现场有NVIDIA显卡，建议把ONNX转成TensorRT。TensorRT因为是专门针对N卡优化的，推理速度还能再快两三倍。不过TensorRT的转换依赖具体的显卡型号和TensorRT版本，换一张显卡就需要重新转换一次，这也是很多人说“TensorRT麻烦”的原因。我的建议是：先跑ONNX版本保证功能可用，再根据实际性能瓶颈决定要不要上TensorRT。

推理服务我采用SPA（单进程单加速器）的方式部署，在FastAPI中加载一次模型，然后用一个全局变量持有推理引擎实例，避免每次请求都重新加载模型。这个细节极其重要——模型加载本身可能要消耗几十到几百毫秒，如果每次推理请求都要重新加载，整个系统基本处于不可用状态。

4. 前后端分离与Web界面实现

4.1 FastAPI后端接口设计与数据流

后端是整个系统的“腰”，腰不好，前后端都受罪。FastAPI是我目前最推荐的Python后端框架——原生支持异步、自动生成交互式API文档、类型校验严格，这些特性在工程落地时好处十分明显。

后端接口我设计了五个核心端点：

• 上传检测图像：接收Base64编码的图片数据或文件，调用推理模块，返回检测结果、置信度列表、类别列表。
• 获取检测历史：从MySQL查询历史检测记录，支持按时间、缺陷类型筛选，返回给前端做表格展示。
• 拉取在线统计：聚合检测数据，按缺陷类型分组统计数量、变化趋势，供前端图表组件渲染。
• 调用DeepSeek智能分析：把检测结果、历史统计拼装为上下文，请求DeepSeek API，返回分析建议。
• 模型管理：切换当前使用的YOLO版本、调整置信度阈值。

接口返回的数据格式必须统一。我定的规范是：成功的响应统一包含code、message、data三个字段，data里面才是真正的业务数据。前端拿到响应后先判断code，再处理data。这么做的好处是，前端处理逻辑可以统一化，不管哪个接口，都是同一套错误处理流程。

这里有一个后端设计的关键考虑：模型推理是耗时操作，不能让前端一直同步等待。对超时机制我做了精细化的调整：简单的单张图片检测必须控制在500毫秒内响应；DeepSeek分析因为大模型API本身响应需要时间，设置成最多等待30秒，如果超时，就先返回检测结果和“分析生成中”的状态，等异步任务完成后再通过消息推送通知前端更新。这套方案极大改善了用户体验。

4.2 Vue 3前端界面与可视化设计

前端界面这块，我深知检测系统不是给人看的“炫技页面”，而是产线工程师和生产管理人员每天要用的工具，信息呈现的优先级必须清晰。

页面布局按功能分成三大块： 第一块是检测主界面，左侧放图像上传和预览区域，右侧放检测结果可视化。用户上传晶圆图像后，前端立刻在图像上用Canvas画框，框的颜色按缺陷类别区分——致命缺陷用红色、良率缺陷用橙色、可疑目标用黄色。框上标注类别名称和置信度，鼠标悬停可以看到更详细的信息。 第二块是历史记录区域，用表格展示所有检测历史。表格里包含检测时间、晶圆批次号、图像名称、检测到的缺陷类别、数量、处理意见等。点击某一行，可以回看对应图像的检测结果。 第三块是统计面板，用ECharts的饼图展示缺陷类型分布，用折线图展示不同批次的缺陷率趋势。这些图表是给管理人员看的，让他们一眼看出最近工艺有没有异常波动。

交互上有一个点我特别强调：置信度阈值要在界面上可以做调整。现场工程师拿到一批新晶圆时，会根据经验判断这一批图像质量好不好、缺陷明不明显，然后调低或调高阈值再做检测。把这个参数做成前端滑块，连后端都不用改，用户体验完全不同。

前后端联调时最烦的是跨域问题。开发环境下前端跑在本地开发服务器上，后端跑在另一个端口，跨域请求会被浏览器拦截。FastAPI解决这个问题非常简单，添加一个CORSMiddleware中间件，指定允许的来源即可。生产环境我建议用Nginx做反向代理，把前端静态资源和后端API放在同一个域名下，同源策略默认就不冲突了，还顺带解决了SSL证书配置的问题。

// 前端检测请求的核心逻辑 async function uploadAndDetect(file) { const base64 = await fileToBase64(file); const response = await fetch('/api/detect', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ image: base64, conf_threshold: confSlider.value }) }); const result = await response.json(); if (result.code === 200) { renderBoxes(result.data.detections); updateStats(result.data.stats); } else { ElMessage.error('检测失败：' + result.message); } }

这段逻辑看起来简单，但有个被科普烂了却依然反复出现的坑——直接把图片转成Base64塞进JSON里。大图转Base64后体积膨胀约33%，如果晶圆图像分辨率很高，请求体可能达到几MB甚至十几MB，传输很慢。我的处理方式是：前端先把图片压缩到适合检测的分辨率（例如最长边1600像素），再转Base64上传。压完之后模型精度基本不受影响，但接口响应速度快了一倍不止。

4.3 数据库设计与检测记录管理

检测记录的管理是整个系统能够追溯的关键，在设计MySQL表结构时，我按照“一次检测一条主记录，多个缺陷附属于这条记录”的思路组织数据，避免把JSON塞进单个字段导致后期完全没法做筛选。

主表wafer_detection_record存储每次检测的全局信息，字段包括：记录ID、晶圆ID、批次号、检测时间、图像存储路径、总体判定结果、模型版本号、置信度阈值等。缺陷明细表defect_detail则记录这张图上检出的每个缺陷，字段有：明细ID、关联的主记录ID、缺陷类别、置信度、边界框坐标、是否为致命缺陷。两张表通过主键关联。

这种设计的核心好处是方便统计。比如你想查“最近一周划痕缺陷的检出数量趋势”，SQL写起来非常直接，一个带where条件的分组查询就能完成；而如果所有信息都堆在一个JSON字段里，这种查询几乎没法写，只能把记录全捞出来自己数。对于需要持续监控工艺质量的产线系统来说，这个差别是致命的。

此外我还会定期把检测统计结果汇总到一张agg_daily_summary表里，按日期和缺陷类型做预聚合。因为如果是几万条检测记录，每次打开统计面板都实时聚合，数据库的负担会很重。预聚合这张表每天更新一次，统计页面响应速度基本是毫秒级。

5. DeepSeek智能分析模块的集成

5.1 大模型分析的不是图像，而是检测数据

很多人听到“DeepSeek智能分析集成”，第一反应是让大模型去“看图识别缺陷”。我提醒一下，方向偏了——视觉缺陷识别是YOLO模型的活，DeepSeek大模型的强项在于自然语言的归纳推理。它的任务是对检测结果做二次分析，给出人类工程师会给出的那种判断。

具体怎么做？我的方案是：把YOLO检测输出的结构化JSON数据和过去一段时间的历史统计结果，转成一段结构化的文本描述，然后作为提示词发送给DeepSeek API。模型返回的分析报告包括缺陷分布是否异常、哪种缺陷占比突然上升、可能涉及哪些工艺环节、建议优先排查的方向、是否需要对当前批次做返工或降级处理。

这里提示词工程特别关键。我最初的做法是简单把JSON直接丢给大模型，结果返回的“分析”非常模板化，“建议优化工艺参数”这种废话没有任何指导价值。后来我改成了带上下文的提示词结构：

你是半导体制造领域的资深缺陷分析工程师。以下是一次晶圆缺陷检测的结构化结果： 检测时间：2025-06-12 14:23:05 晶圆批次：WFR-20250612-A3 检出的缺陷分布：划痕 12处，颗粒 8处，裂纹 2处，污点 1处 近7日同类晶圆的缺陷趋势：划痕占比从5%上升至18%，主要集中在边缘区域。 请基于以上数据，分析可能的工艺原因、建议排查方向、并给出处理建议。 请用工程报告的口吻输出，无需解释分析过程，直接给结论。

这种带工程背景、带明确输出格式要求的提示词，返回结果才真正可用。DeepSeek的推理能力和上下文理解能力在大模型里是第一梯队的，只要提示词给到位，它输出的分析报告几乎可以做到“不需要人工修改直接放进日报”。当然，我这里说的是“辅助分析”，最终决策必须由工程师确认，这一点我在系统的界面设计上也做了对应的提示。

5.2 智能分析的服务封装与并发控制

DeepSeek按API方式接入，后端封装一个统一的调用模块。因为大模型API属于外部依赖，网络可能超时或者返回异常，这个模块必须有完善的重试机制和降级方案。我实现时设置了最多两次重试，每次重试之间间隔2秒；如果连续失败，系统返回“智能分析暂不可用，请稍后重试”，同时把检测结果先正常呈现给用户。这样即使是分析模块宕机，系统的核心检测能力完全不受影响。

并发控制上要留心——大模型API通常有每分钟请求数（RPM）的限制。如果产线上的多名工程师同时点击“生成智能分析”，后端短时间内发出大量请求，会直接触发限流。我用Redis做了一个简单的令牌桶限流器，限制每分钟最多调用20次分析接口。超过限制的请求进入队列排队，前端会显示“分析任务排队中”的状态。

我强烈建议给DeepSeek分析功能增加流式输出。大模型生成分析报告可能需要几秒到十几秒，如果使用普通请求，前端只能干等一个长加载动画，体验非常糟糕。流式输出把生成结果增量地推到前端，用户能看到报告一个字一个字地“打出来”，而且可以先看到前面的结论，感情上也觉得速度快了很多。FastAPI支持SSE（Server-Sent Events），实现流式推送非常方便，前端只需要用EventSource接口监听即可。

6. 常见问题排查与实操心得记录

6.1 部署和运行十大高频问题速查

整个系统从开发到部署上线，我踩过的坑怎么也有几十个了。这里挑最典型的几个整理成速查表，你们照着排查基本能解决大部分问题。

这里解释一下误检的背景样本问题。我第一版训练数据里全是“带缺陷”的图，没有放入足够的正常晶圆图作为负样本，模型学到的是“这片区域看起来像晶圆就要框一下”，结果在真实产线上对正常的电路图案疯狂误检。教训是数据集中一定要包含至少20%~30%的负样本，让模型学会判断“什么都没有”的情况。

6.2 第三方图像来源处理与数据合规

做晶圆检测项目，数据来源是一个躲不开的话题。如果是自己实验室采集的图像，所有权清晰，怎么用都没问题。但如果是要用公开的图像集做预训练，务必确认数据的使用条款，不要随便拿去商用。我的习惯是把所有数据来源、采集时间、标注人员、使用权限记录在一个说明文件里，这个习惯帮我在后续的项目交付和审计中省了很多麻烦。

图片在传输和存储过程中也要做脱敏处理。晶圆ID、批次号、工艺参数等敏感信息，在数据库里加密存储，前端默认不展示详细信息，只有权限等级足够的用户才能看到。这套权限控制虽然项目初期做着麻烦，但它是系统能真正进入工业场景的必要条件。

6.3 设备选型建议与性能调优

在设备这一块我多说两句。训练阶段和数据准备阶段对GPU的需求完全不同。数据标注和探索性实验阶段，普通的深度学习主机就够用；但全量训练阶段，显存至少也要16GB，否则batch size和输入分辨率都会被压得很低，训练效果大打折扣。推理部署阶段，一张中端显卡就能覆盖绝大多数产线的实时检测需求，并不需要顶配卡。

如果现场没有GPU，系统也可以退化成CPU推理模式。YOLOv8n和YOLOv11n这么小的模型在CPU上单张推理大概100-300毫秒，对于非实时的批次检测完全可用。我建议大家开发部署时先确保“无GPU也能跑通”，再上GPU加速，这样做的好处是系统在各种环境下的可移植性极强。

性能调优还有三个细节值得提： 第一是图像预处理。晶圆图像读进来先做归一化和格式转换，必须和训练时的预处理保持一致，否则模型输出会有偏差。第二是批量推理。有些场景需要一次性检测几十张图，单张循环处理效率很低。YOLO模型原生支持批量推理，一次传入多张图，推理时间只比单张多一点，吞吐量翻好几倍。第三是显存碎片管理。用GPU跑推理的服务，长时间运行后显存碎片会累积，建议设计定时任务定期释放和重整显存。

6.4 关于系统扩展与二次开发的方向

这套系统目前已经能完整跑通“上传图像-模型检测-结果可视化-大模型分析-历史追溯”的闭环，但如果你想把它进一步发展，有几个方向我认为很有价值。

一是多模型融合。目前的方案是一个模型跑全部缺陷类别，实际工厂可能会针对不同工艺阶段的缺陷训练专项模型——一个专门抓颗粒、一个专门抓划痕，然后用一个仲裁模块把结果合并。第二是主动学习。定期把检测置信度介于0.3到0.7之间的“灰色地带”样本导出来让人工复核，复核结果再回流到训练集，模型会越用越准。这个机制一旦运转起来，系统长期维护的边际成本会越来越低。第三是接入实时监控。把检测能力嵌到产线视频流中，对运动的晶圆逐帧检测，发现缺陷立即触发报警联动机械臂分流，这就是完整的智能化生产线了。

我在实际项目中的体会是：检测系统的精度和效率当然重要，但对产线用户来说，真正让他们认可系统的，反而是那些“不那么技术”的东西——界面是否直观、结果是否可追溯、分析了是否给出下一步动作。所以在整个项目里，我给YOLO模型调试和前端体验的时间几乎是五五开，最终交付时用户满意度比预期好很多。

最后再分享一个经验：系统的置信度阈值和图像上传分辨率，一定要在界面上做成可随时调整的参数，不要固化在代码里。项目上线三天内，现场工程师一定会让你改这三个参数——改一次你就要发一次版本，不如一开始就把调节能力交到他们手里。这是我做了好几轮交付之后踩坑踩出来的结论，希望对正在做类似项目的你能有帮助。