企业官网建设流程全解析

先聊个现象：这两年“智慧环保”喊得特别响，垃圾桶旁边立个屏幕，摄像头一扫就能告诉你“塑料瓶是可回收物，剩饭是厨余垃圾”。但真正去落地的时候，你会发现这套看起来简单的流程，背后全是细节。我这两年代做垃圾分类识别项目，从YOLOv5一路换到YOLOv8，又折腾过蒸馏、量化、边缘部署，踩过的坑能写满一本笔记本。今天就把我实际的模型选型对比、训练调参和部署经验全部摊开来讲，尽量让你看完能少走弯路，尤其是那些常规课程和GitHub README里不会写的坑。

这个选题适合谁？一类是刚入门做视觉识别、想用一套开源方案快速搭出垃圾分类原型的同学；另一类是做智慧环保集成项目的工程师，已经在用YOLO识别垃圾，但被误检率、FPS、模型体积这些问题卡住，想看看别人是怎么解决的。无论你是什么基础，这篇文章的重点不是给你贴一堆公式，而是把“选哪个模型”“标注怎么搞”“训练踩了什么坑”“部署时怎么优化”这些决策过程梳理清楚。

1. 方案选型：为什么是YOLO全家桶，而不是检测头加分类器的老路子

1.1 一个垃圾识别项目，核心需求到底是什么

做任何项目的第一步，不是急着下载模型，而是先把需求拆清楚。垃圾分类识别这个场景，表面上看起来是“识别垃圾种类”，实际拆开之后至少有三个子任务：检测垃圾在画面的位置、分类垃圾属于哪个类别、在真实环境里持续稳定地工作。前两个问题可以用图像分类加目标检测分别解决，但第三个问题把整个方案的复杂度拉高了不止一个量级。

我接触过不少团队的第一版方案，是直接用ResNet或者MobileNet做图像分类：截图、缩放、丢进分类器，输出瓶瓶罐罐的类别。这套方案在实验室里跑得很欢，但一进真实场景就露馅——垃圾桶旁边有树叶、有手、有阴影、有灯光反射，分类器很容易被背景干扰。更重要的是，当画面里同时出现一个塑料瓶和一个香蕉皮，分类器根本不知道要“看”哪个，只能整体输出一个概率分布，这在垃圾分类场景里是完全不可接受的。

所以最终方案必须落到“目标检测”这个方向：先定位，再分类。这也就解释了为什么YOLO会成为这类项目的事实性标准——他把定位和分类融合在同一个网络里，一次前向传播就能输出所有目标的位置和类别。再加上YOLO的开源生态成熟，预训练权重、部署工具链、社区解决方案都很齐，不用从零造轮子，对于环保这样预算有限的领域来说性价比非常高。

1.2 目标检测与图像分类在产业链上的定位差异

图像分类解决的是“这是什么东西”，目标检测解决的是“这些东西都在哪里，各自是什么”。听起来只差一点点，但背后是完全不同的技术路线。分类模型只看全局特征，用一个global pooling把整个图浓缩成一个特征向量；检测模型需要保留空间信息，因为你要输出边界框的坐标，所以它的特征图结构、锚框设计、后处理逻辑都比分类模型复杂得多。

在垃圾分类的产业链里，这个差异直接影响了终端设备的形态。如果只做分类，你可以在树莓派上用MobileNet跑到30 FPS，但没法告诉机械臂该抓哪里。如果做检测，哪怕YOLOv5s这种轻量模型，也能输出框的坐标、宽高、类别，机械臂就能根据中心点规划抓取路径，分拣流水线才能真正实现自动化。这也是为什么我后来把方案定为“检测为主、分类兜底”——检测负责定位和粗分类，遇到实在难以判定的类别，再结合一个轻量分类模型从局部区域做二次确认。

1.3 数据、算力、场景三者约束下的模型选型路线

模型选型不能光看排行榜上的mAP数字，得看你的约束条件。我接触的垃圾分类项目大致分三类：固定机位对单个垃圾桶、移动巡检车对多个点位、还有手持终端现场拍照。三个场景的算力、时延、功耗要求完全不一样。固定机位通常有电源，可以用NVIDIA Jetson或者其他小工控机，模型可以选大一点的YOLOv8m；移动巡检车需要电池供电，模型必须是轻量级加量化；手持终端就更苛刻，要么接云端的API，要么在手机端部署非常小的模型。

我的总体选型思路是：主干网络选带CSP结构的版本（v5、v8都是），因为这类结构有较好的梯度隔离特性，训练时稳定，部署时各层结构清晰；输出头选解耦头（v8的Decoupled Head），因为分类和回归两个任务在网络里各走各的分支，收敛速度快，精度也比耦合头高。至于锚框，Anchor-Free在YOLOv8里已经做得比较成熟，减少了调参的负担。简单说，在现在的生态下，新项目我一般直接上YOLOv8起步，旧项目维护v5也不着急迁移，但如果是全新项目尤其是生产环境，YOLOv8的综合性价比是最高的。

2. YOLO版本演进对比：从v5到v8，选哪个版本给自己干活

2.1 版本迭代背后的逻辑，不只是变大变小

YOLO系列的演进，不只是“数字大了模型就更强”。从v5到v8，每一代的核心变化都围绕一个主题：让模型更容易收敛、更容易部署、更容易在边缘设备上跑起来。v5的贡献在于把之前YOLOv4里零散的改进（Mosaic增强、CSP结构、SPP模块）工程化，训练极其稳定，成了社区里的“劳模”；v6主要面向工程部署做了很多兼容性优化；v7则更偏向在速度和精度之间做极端调校；到了v8，最大的变化是重新设计了检测头，把原来的耦合输出拆成两个独立分支，同时全面转向Anchor-Free，配合TaskAlignedAssigner做动态标签分配，精度提升非常明显。

对于垃圾分类这个具体场景，我实际体感最明显的差异是：v8在“物体堆叠、相互遮挡”的情况下的识别比v5更稳。垃圾桶里垃圾经常是挤在一起的，好几个目标挨得很近，v5的Anchor分配经常出现误匹配，该学A的框重点落在B上面；而v8的动态分配会根据预测和真实框的匹配质量来调整，边界清晰很多。所以如果你处理的垃圾数据遮挡严重，优先考虑v8及以上版本。

2.2 用同一批垃圾数据跑出来的实测对比

为了给大家一个有参照系的结论，我专门用同一批自建的垃圾分类数据集（21个类别，包含塑料、玻璃、纸类、金属、织物、厨余等，总共大概一万两千张图片）分别训练了YOLOv5s、v5m、v8n、v8s，统一输入尺寸640×640，batch size 32，都训100轮。以下是实测数据的汇总表：

这里有一点要强调：上面是在中等数据量、常规训练条件下得出的结果，不代表在所有数据集上v8s都一定碾压v5m。但至少给了我一个强烈的信号——v8n用比v5s小一半多的体积，达到了接近v5m的精度，这对边缘部署特别友好。我最终在大多数点位选了v8s做主力模型，v8n做巡检车上的备用模型。

2.3 损失函数与动态标签分配，决定了收敛速度和精度上限

很多人看模型对比只看结构图，忽略了一个关键点：损失函数怎么设计，直接决定了训练能不能收敛、收敛在什么水平。YOLOv8使用了BCE损失做分类、CIoU损失做回归，并且通过TaskAlignedAssigner在每轮迭代中动态选择哪些预测框作为正样本。这和v5固定的Anchor分配策略有本质区别——固定分配是先验的，遇到生活垃圾这种长尾分布（比如烟头、果核特别多，而灯管、电池特别少），固定规则经常把稀有类分配错；动态分配则让模型自己在训练中去学习“哪个预测框更应该对这个目标负责”。

我在调参的时候发现一个现象：同样数据集、同样GPU，v8在训练前期loss下降就比v5快很多，大约到40轮左右就已经达到v5训练60轮的精度水平。这种收敛速度的差异对项目节奏影响很大——模型的迭代试错周期缩短，多轮实验就能在同样的时间内完成。CIoU回归损失在处理垃圾这种大变形目标上也更稳：一个被踩扁的纸箱，框的宽高比变化很大，CIoU会同时约束重叠面积、中心点距离和长宽比，比单纯IOU损失更准确。

3. 数据标注与模型训练的核心细节

3.1 数据集构建，比想象的更费功夫

说句实话，垃圾分类项目里最耗时、最能决定成败的不是模型，而是数据集。我第一批数据犯过一个低级错误：在网络上下了一堆“垃圾分类图片”，没做清洗就直接训练，结果模型过拟合到很多奇怪的背景特征上——后来排查发现，有些图片带水印，模型居然学到了“有水印的图片大概率是可回收物”。数据质量比数据量重要得多。

实际构建数据集我分了三条线：一是自采实拍，拉了一个标注团队去不同光线、不同天气、不同垃圾桶型号的现场采集图片，要求覆盖平拍、俯拍、侧拍多个角度；二是从开源数据集（TrashNet、TACO等）中筛选质量高的部分做迁移补充，但严格把关类别体系和标注风格；三是抓拍视频截帧，特别是在流水线上连续抓拍的帧序列，可以低成本获得大量高相关性图像。自采实拍和数据增强可以解决大部分小样本问题，开源数据集则用来补充稀有类别的多样性。

类别体系的取舍也踩过坑。最初参考垃圾四分类标准定类别，后来发现“可回收物”这类高层次类别太抽象，检测模型很难学出统一的视觉模式——一个易拉罐和一个旧衣服，都能叫可回收物，但视觉特征差太远。后来我把类别细化成类似“塑料瓶”“易拉罐”“玻璃瓶”“纸箱”“香蕉皮”“剩饭”这种具体品类，模型精度立刻上来了。经验是：检测模型适合学具体物体，不适合学抽象概念，宁远类别多一些、细一些，也别定容忍度高的大类。

3.2 标注规范，直接影响模型上限

标注规范看起来是个执行问题，实际上是个模型性能问题。标注框的松紧把握、类别边界的划分、遮挡目标的处理策略，都会体现在最终mAP里。我在推进标注规范时定了几条硬规矩：目标占画面小于3%的物体不标，因为YOLO在小目标上的特征提取本来就有限，强行标注反而制造噪声；被遮挡超过50%的目标标注时只画可见部分，不依赖“脑补”整轮廓；类别模糊的目标宁可标记为“其他垃圾”，也不要强迫标注员猜类别，不然训练数据里就会埋下一堆错误标签。

另外，标签一致性训练集里同一种物体在A图片标注为“纸杯”在B图片标注为“纸盒”，模型就学混乱了，loss曲线会一直抖。我的做法是在启动标注前先做一套标注指南，把每个类别的定义、边界情况和典型案例配图写清楚，再抽检复查，抽检不合格的批次全部返工。这个环节看着费时间，但后续训练和上线省心得多。

3.3 训练参数与Loss曲线解读

训练参数这块，我常用的配置可以参考下面这段YAML。不要照搬，要结合自己的数据规模调。

# train.yaml task: detect mode: train model: yolov8s.pt data: garbage.yaml epochs: 100 patience: 20 batch: 32 imgsz: 640 save_period: 10 device: 0 workers: 8 project: runs/train name: garbage_v8s optimizer: SGD lr0: 0.01 lrf: 0.01 weight_decay: 0.0005 warmup_epochs: 3 mosaic: 1.0 mixup: 0.0

几个重要的参数逻辑说一下。mosaic增强在初期打开很有用，它能把四张图拼成一张，极大地丰富了上下文多样性，但最后二十轮我建议关掉——因为Mosaic生成的是“拼接图”，和真实场景分布不同，一直开着会导致模型的最终精度不稳定。mixup我也保持关闭，垃圾图片很多是透明袋、反光材质，混合增强会让这些材质特征被混淆。patience设为20，结合早停机制，如果连续20轮没提升就自动停，能节省大量算力。

训练过程中要盯两条曲线：val_loss和mAP@0.5。正常情况下mAP曲线是阶梯式上升的，越到后面越平缓。如果mAP曲线涨到一定程度开始反复震荡，通常有两个原因：一是学习率过高，二是数据里有错标。震荡得厉害就降lr0到0.001再重新跑最后三十轮；如果震荡伴随loss突然反弹，就回去检查最近的标注批次，大概率是有标签错误。

4. 模型蒸馏与轻量化：把模型从服务器搬到边缘设备

4.1 为什么大模型训出来的能力，要“教”给小模型

边缘部署是垃圾分类系统绕不开的一环。固定机位虽可以用GPU盒子，但大面积铺设的成本依然是痛点。巡检车、小区门口的旧桶改造点，往往只有一块低功耗开发板，甚至是一块不到10瓦的NPU。YOLOv8s在Jetson和部分RK3588平台上跑还能勉强应付，但在更弱一点的芯片上就得动轻量化的脑筋。

我的经验是：直接训练一个小模型，精度往往会比蒸馏出来的小模型低不少。原因在于大模型在同样的数据上学到的特征更丰富，通过蒸馏可以把这个“暗知识”（比如类别间的相似性、边界框的细微回归偏移）传递给小模型。我常用的方案是拿YOLOv8x来当老师模型蒸馏YOLOv8n。具体做法是：老师模型先训好并且固定权重，然后小模型训练的时候除了Ground Truth的硬标签，还拿老师模型的输出（软标签）做辅助监督。分类分支用KL散度对齐学生和老师的类别概率；回归分支直接对齐边界框输出。蒸馏温度我通常设在8到12之间，太高网络输出过于平滑，学不到区分度；太低就和硬标签差不多了。

4.2 量化部署的实际效果，ONNX、TensorRT和RKNN

蒸馏完了之后还要做量化。我试过几种部署路线：ONNX Runtime（CPU）、TensorRT（NVIDIA GPU）、RKNN（瑞芯微NPU）。三者的性能差距非常大。

在NVIDIA平台上，TensorRT的FP16转换基本无痛，精度损失在0.5%以内，可以直接用。INT8需要校准数据，我一般取500张覆盖代表性场景的图片做校准集，校准集不能全挑好识别的图，要把阳光直射、夜间补光、雨天玻璃反光这些场景都放进去，否则量化后的模型会在这些边缘场景里翻车。

RK3588这类芯片是另一个世界。RKNN-Toolkit2虽然支持YOLOv8导出的ONNX转RKNN，但有几个暗坑：一是某些算子在NPU上不支持会退化到CPU执行，性能直接拉垮，我遇到过Gather算子在部分版本下不支持，导致推理时间翻倍的案例；二是量化后NMS部分偶尔出现莫名其妙的坐标偏移。我的处理方法是导出ONNX时把后处理尽量保留在模型外部，让模型只输出原始预测张量，再由板载CPU做NMS和坐标解码。虽然增加了一点CPU开销，但整个流程的可控性高了很多。

4.3 量化感知训练与校准数据的关键性

很多人直接拿训练好的模型强行转INT8，发现精度血崩，就怪量化工具垃圾。实际情况是，常规训练好的模型权重分布不一定是量化友好的，特别是有feature map的值域比较宽时，INT8固定比例映射会带来很大误差。正确做法是做量化感知训练，在训练阶段就模拟量化误差，让模型学会在低比特约束下保持精度。Ultralytics从某个版本开始支持QAT模式，在微调阶段打开，不需要改太多代码。

我用QAT微调YOLOv8n跑出来的经验是：正常训练精度mAP约82%，直接PTQ量化为INT8后掉到78%左右，QAT微调后能回到80%以上。对于垃圾分类识别来说，80%已经可以上线，配合后续置信度阈值调节和逻辑过滤，最终用户体验差不了多少。校准数据的选择同样重要——校准不是喂越多越好的数据，而是要喂分布接近推理场景的数据。我吃过亏，校准集只放了三万张白天晴天数据，夜间场景的激活值域覆盖不够，上线后夜间误检率翻了一倍。

5. 落地部署流程：从训练到推理全链路

5.1 推理框架选型与模型导出的细节

训练和部署之间，隔着一个“模型导出”的关卡。我一开始图省事，直接加载PyTorch权重做推理，速度慢且依赖重，后来统一改成导出ONNX再转各平台的格式。导出时务必加上opset=12以上，兼容更多算子；动态输入尺寸能不开就不开，固定640×640会省掉很多转模型时算子兼容性的麻烦。

转TensorRT时，如果用trtexec工具，建议加上--fp16，然后测一下精度。如果发现某些类别掉点严重，先别急着上INT8——大多数情况下FP16已经足够，INT8是锦上添花，不是雪中送炭。换到瑞芯微平台，就用rknn-toolkit2把ONNX转成.rknn，转换时需要注意量化方案选择，通常先用normal量化策略跑通，再考虑mmse之类的优化策略。我实测下来mmse在部分模型上能提1%到2%的精度，但转换时间会明显变长。

5.2 部署到RK3588与Jetson上的实测表现

我在办公室搭过一套基准测试环境，分别测了RK3588（瑞芯微）和Jetson Orin Nano上的部署结果。RK3588跑了YOLOv8n INT8，在单路视频流的条件下大概是45 FPS，CPU占用率约35%，NPU负载在70%上下，整体功耗控制得非常好，适合做小区出入口的垃圾投放行为识别。Jetson Orin Nano则跑YOLOv8s FP16，单路大概70 FPS，同样的模型加一个简单的跟踪模块也没有压力。

有两个细节值得注意：一是视频解码，不要占用NPU去解码，要用硬件解码器把RTSP流解成YUV或者BGR矩阵，再把画面送入推理单元，否则性能会大打折扣；二是多路视频流的调度，我用了一个简单的任务队列来管理多路摄像头的推理请求，每路摄像头的帧率控制在10 FPS，因为垃圾分类投放行为的变化速度不快，10帧足够，节省下来的算力可以留给检测多目标的复杂场景。

5.3 避坑指南：边缘部署时常见的误检率问题

这是重头戏。“yolo 边缘部署监控误检率高”几乎是所有边缘项目都会遇到的头号问题。误检率高的原因非常多样：一是边缘设备算力有限，我们被迫换小模型、做重量化，精度本来就有所下降，在低光照、极端角度下就可能乱框；二是图像质量，摄像头的码率不够或者传输丢帧，画面上出现马赛克和运动模糊，放大之后全是噪点，模型在训练时没见过这种输入分布；三是后处理参数没有做场景化调整。

我实际踩过的坑是户外垃圾桶旁边的树荫和树叶晃动的误检——模型会把深绿色叶片识别为“玻璃瓶”。原因挺明显，叶片在对焦不准的时候呈现为高光小圆形区域，和瓶底特征高度相似。后来在三个维度上做了优化：一是降低置信度阈值到0.25的同时，增加一个面积过滤规则，小于某个像素面积的检测框直接丢弃；二是加入帧间稳定性过滤，同一目标连续两帧消失再出现的，大概率是误检；三是针对低光照场景单独训练了一个微调模型，在光线传感器检测到照度低于阈值时切换到夜间模型。经过这三步，误检率从最开始的18%降到了3%左右。

6. 常见问题与排查技巧实录

6.1 YOLO训练中的奇怪现象，从BN崩溃到混淆矩阵异常

“yolo训练中bn崩溃”是我近期在本地遇到的一个比较头疼的问题。BN崩溃的表现是训练过程中loss突然变成NaN，检查日志发现某一层的batch norm的running mean/variance变得极大。这个问题的常见诱因有两个：一是学习率太高，梯度爆炸放大了BN统计量的波动；二是训练数据里存在极端的离群样本，比如全黑图片或者全白图片，BN在计算均值和方差时被它们带偏。解决思路是先降学习率，再排查数据中的异常样本。如果数据集里包含大量裁剪后的黑色背景图像，做一次直方图筛选，把低信息量图片去掉，BN崩溃概率会大幅降低。

另一个常见问题是“yolo混淆矩阵总合不唯一”。混淆矩阵的每一行代表真实类别，每一列代表预测类别，行总和理论上应该等于该类别的真实样本数，但如果你在做统计时用了不同的置信度阈值，或者把多个数据集的结果混在一起算，行和列自然对不上。我的检查方法很简单：先固定置信度阈值，再保证数据集中每个类别的样本数统计一致，然后对比矩阵和results.csv里的分类精度，基本能定位问题出在哪一步。

6.2 目标重叠与实例分割的边界情况

垃圾分类里目标重叠是常态，尤其是厨余垃圾和非厨余垃圾混放时，一个塑料袋可能同时装着剩饭和饮料瓶。YOLOv8的检测框在这种情况下会输出两个高度重叠的框，NMS只能大概率保留置信度高的那一个，另一个就被抑制了。这会直接导致漏检。我尝试过在两个方向解决：一是降低NMS的IOU阈值，从0.45降到0.3，让重叠目标有更大机会同时保留，代价是会有少量重复框；二是针对特别难分的目标，干脆给模型加一个“混合垃圾”类别，当一个框里明显同时包含多种垃圾时，允许它输出混合垃圾，后续再交给人工或者近红外光谱设备精分。这个方法在工程上很实用。

如果项目预算允许，可以考虑尝试YOLOv8-seg实例分割模型，它输出每个目标的掩码而不是简单矩形框，能更准确地区分重叠目标的边界。我在一个精细化分拣线项目里用过，模型分割出来的垃圾轮廓能直接给机械臂规划抓取姿态，比边界框方案好看得多，但推理时间会上升，帧率基本要打对折。

6.3 RK3588平台的模型转换与推流完整实录

我把自己最常用的RK3588部署流程整理成一份拷打过的“作业”，方便你直接抄。假设你已经训好了YOLOv8模型并且导出了ONNX。

第一步，在PC上安装rknn-toolkit2并激活对应Python环境。转换脚本可以参照一个比较简洁的版本：

from rknn.api import RKNN rknn = RKNN() rknn.config(mean_values=[0, 0, 0], std_values=[255, 255, 255], target_platform='rk3588') rknn.load_onnx(model='yolov8n.onnx') rknn.build(do_quantization=True, dataset='calib.txt') rknn.export_rknn('yolov8n_rk3588.rknn')

第二步，把生成的.rknn文件拷贝到板子上，用板载的rknn-multi-threaded或者librknnrt.so来做推理。这是C++侧的基本流程，大致是初始化上下文、申请输入输出缓冲区、把视频帧拷贝进输入张量、执行推理、从输出张量解码坐标。

// 伪码示例：读取一帧，推理，后处理 void infer_frame(cv::Mat &frame, rknn_context &ctx) { rknn_input inputs[1]; inputs[0].buf = frame_resized.data; rknn_inputs_set(ctx, 1, inputs); rknn_output outputs[3]; rknn_outputs_get(ctx, 3, outputs, NULL); // 解码三个输出头，对应不同尺度的预测结果 decode_and_nms(outputs, results); }

解码时有个小技巧：YOLOv8的输出相对训练时每一个尺度的输出头大小是固定的，如果你只用NMS自带的nms函数发现速度慢，可以考虑换成OpenCV的cv::dnn::NMSBoxes，实测在RK3588的CPU上比原版快很多。整体流程跑通后，单路视频10 FPS大约只占CPU 20%左右，完全能在实际项目中落地。

6.4 特殊数据集与创意应用：试卷切割、手势识别和红外电力巡检

做YOLO系列项目多了，会发现垃圾分类只是众多垂直应用中的一种，方法论完全可以迁移。比如“基于yolo的试卷题目自动切割”，它的逻辑就是把每一道题目当成一个目标，先检测题目所在区域框，再判断题目包含哪些元素，本质上就是目标检测加字形识别的组合；再比如“yolo手势识别数据集”，跟垃圾识别几乎是一个模板，只是类别从“塑料瓶”换成了“数字1到10”。我个人觉得，YOLO最有价值的地方就是这套“标注—训练—部署”的流水线，只要跑顺了一次，后面接什么场景都是流水作业。

我甚至见过用YOLO做电力红外巡检的案例——目标不是垃圾，而是电力设备上的过热故障点，思路同样是先检测设备区域再分析温度模式。这也是为什么YOLO在真实产业里这么流行：它给从业者一个稳定的底座，剩下的就是数据采集、标注和场景适配这些工程问题。

7. 总结反思与一个帮助了我很多的经验

从决定用YOLOv5开始，到最终在RK3588上稳定部署YOLOv8s和v8n，整个过程耗时约四个月。回头看，真正影响项目成败的不是模型有多先进，而是数据标注质量、部署前期的量化评估和边缘数据分布校验。YOLOv8对比YOLOv5的精度提升是实打实的，但如果你没有花心思处理数据集那部分，提升幅度也会被各种工程问题蚕食掉。

最后分享一个帮了我大忙的小技巧：在垃圾分类场景调试的时候，不要只看最终的准确率指标，要把误检图片按类别切片保存下来，定期观察哪些类别的误检在反复出现。这个方法听起来很简单，但很多团队都是等到客户投诉了才发现问题集中在某几个特定类别上。我自己就是通过这个办法发现的——“树枝”“叶子”“黑色塑料袋”这三个误检类别几乎占了一半以上的bad case，后续针对性地做数据增强和阈值策略之后，整个系统才真正开始稳定。

如果你也正在做类似的项目，建议你先花一周时间把数据规范和标注指南写完，再花三天跑通一个最简版的端到端流程，之后再慢慢优化模型和部署。顺序对了，这个项目就不会太折磨人。