Python垃圾分类系统实战：从模型训练到Flask部署

简介：本资源是一套面向高校计算机类专业学生的Python垃圾分类系统实战项目，适用于毕业设计、课程设计及人工智能方向期末大作业等实践场景，聚焦图像识别与环保应用结合的技术落地。压缩包共24个文件，含7个核心Python脚本（如classify.py、garbage.py、ui.py等）、3个UI界面文件（.ui）、3个数据集压缩包（cardboard.zip、plastic.zip、trash.zip）、1个C++测试备份文件（.cpp.zbak）及README.md等说明文档，整体61.16MB，结构清晰，模块划分明确——涵盖前端交互、后端逻辑、模型调用与数据预处理全流程。已有41人学习下载，项目曾获课程设计评审98分，并经指导教师审核认证，配套完整开发文档与实现代码，包含界面设计截图、功能流程图、数据集组织规范及模型训练方案，可直接部署调试，为AI+环保类课题提供可复用的工程化参考范例。 不知道你有没有过这种瞬间——站在楼下垃圾桶前，手里拎着外卖盒、快递箱和剩下的半个西瓜，先看一眼桶上的标识，再低头瞄一眼手机搜索，最后还是凭感觉扔进去了。说实话，我自己就纠结过很多次，后来干脆花了两个周末，用Python做了一个垃圾分类系统，拍照识别垃圾类别，几秒钟给你准确答案。项目本身不复杂，但麻雀虽小五脏俱全，从数据集、模型训练到Web部署，一整条流水线都是完整的，而且源码直接开源，改一改就能变成你自己的项目。

这篇文章我就把整套Python垃圾分类系统的实现方案摊开讲。我会把项目定位、技术选型、环境搭建、模型训练、API服务、前端页面和部署优化全流程过一遍，中间穿插我在实际开发中踩过的坑和调整思路。不管你是刚学Python想做课设，还是想系统入门图像分类项目，这套代码和方案都能直接复用。

1. 项目定位：垃圾分类系统到底解决了什么问题

1.1 别急着写代码，先想清楚这个系统要做什么

很多人在拿到"垃圾分类系统"这个题目时，第一反应就是"这不就是个图像分类吗，套个CNN不就行了"。理论上是这样，但真要把系统落地，需要回答的问题远不止分类本身。我在动手前先列了一份需求清单：

• 用户怎么使用这个系统？网页上传图片还是摄像头实时识别？
• 识别出结果之后要展示什么？只告诉类别，还是连投放指导一起给出？
• 分类体系怎么定？四分类（可回收、厨余、有害、其他）还是细分到具体垃圾名称？
• 模型跑在哪里？本地推理还是部署到服务器？
• 谁在用这个系统？如果是教学演示，速度和精度哪个优先级更高？

这些问题看似简单，却决定了整个项目的架构方向。如果目标只是交一个课设，那张静态图片+命令行输出的方案就够了；但如果你想把它做成一个真正能用的小工具，前端交互、模型推理、异常处理、部署方式就都得考虑进去。

我这里最终确定的是一个Web形式的最小可用产品：用户通过浏览器上传一张垃圾图片，后端调用训练好的深度学习模型进行识别，返回垃圾类别名称、所属分类、投放建议和置信度。整个项目包括训练脚本、数据集处理脚本、Flask后端、简单前端页面和部署配置，完整闭环，开箱即用。

1.2 这套源码的整体架构和核心模块

项目的目录结构一开始就要规划好，不然训练到一半你会被各种脚本和权重文件搞得晕头转向。我最终整理出来的结构是这样的：

garbage_classification/ ├── app.py # Flask 后端入口 ├── requirements.txt # 项目依赖 ├── config.py # 全局配置 ├── data/ │ ├── train/ # 训练集（按类别分文件夹） │ └── val/ # 验证集 ├── models/ │ ├── model.py # 模型定义 │ └── efficientnet_finetuned.h5 # 训练好的权重 ├── src/ │ ├── train.py # 训练脚本 │ ├── predict.py # 单张图片预测脚本 │ ├── data_augmentation.py # 数据增强脚本 │ └── preprocess.py # 数据预处理与划分 ├── templates/ │ └── index.html # 前端页面 └── static/ ├── css/ └── uploads/ # 用户上传的图片存放处

数据目录按类别分文件夹存放，这是图像分类任务最常见的组织方式。每个文件夹名就是类别名，训练脚本会自动扫描所有子目录生成标签映射，后期增加新类别只需要往文件夹里丢图片，不需要改代码。

后端服务我选了Flask而不是Django，原因很直接：项目规模小，只需要一个上传接口和一个预测接口，Flask的轻量灵活完全够用，而且Flask的路由和request处理逻辑非常直白，源码容易读懂，对初学者友好。后续如果要扩展用户系统并发处理，再把Flask换掉也不迟。

2. 技术选型对比：深度学习方案的四个关键选择

2.1 为什么必须用深度学习，而不是OpenCV传统方法

接到垃圾分类这个需求，我先想到了OpenCV加传统图像处理的做法：提取颜色直方图、纹理特征、边缘形状，再丢给SVM或者随机森林分类。这个思路在十年前的论文里很常见，对背景单一的图片确实有效，但一放到真实场景就露馅了。

举个例子：一个透明的矿泉水瓶和一个玻璃瓶，颜色上都是透明偏绿，形状上都是圆柱体，纹理特征更是相似。人眼可以靠高光的折射、瓶身标签、瓶口螺纹这些细微线索来区分，但传统手工特征很难把这些信息编码进去。更麻烦的是，垃圾种类五花八门，从剩菜到纸箱到电池，外观差异极大，靠人工设计特征维度的方案可维护性很差。

深度学习特别是卷积神经网络的优势在于，它不需要你手动设计特征，网络会自己从数据中学出"什么样的外观模式对应哪个类别"。今天它学到的是瓶身螺纹和高光折射的关联，明天换一批新数据，它也能自己调整。所以整个方案的关键决策之一，就是用数据驱动代替人工特征工程。

2.2 模型选型：MobileNet、ResNet还是EfficientNet

确定了用CNN之后，马上迎来的问题是用什么网络结构。我在项目中实际对比了三种主流模型，最终选定的是EfficientNet和MobileNet的组合路线。下表是当时参考的对比数据：

从准确率、参数量、推理速度三个维度综合看，EfficientNetB0和MobileNetV3都明显优于老牌ResNet和VGG。考虑到这套系统以后可能会部署到手机端或者树莓派上，我没有选择一个"大而重"的模型，而是选了EfficientNetB0作为主干。它的提特征效率比同等大小的网络更高，对硬件要求相对友好，训练时间也不会太长。

实际项目中我还做了另一个小技巧：先用迁移学习加载ImageNet预训练权重，再把全连接层替换成垃圾类别数量对应的输出层。这样做起步准确率就高，训练迭代次数可以大幅缩短。

注意：模型选型没有绝对标准，关键是匹配部署场景。如果只在PC上跑演示，ResNet50也完全没问题；如果后续要上Android，MobileNetV3的优先级别更高。

2.3 数据集：用公开数据集还是自己标注

垃圾分类相关的公开数据集其实不算稀缺。常见的有华科大的40类垃圾分类数据集、Kaggle上的Garbage Classification数据集，以及各种新闻报道里配套的图片集。我最终用的是包含40个类别的公开数据集，涵盖玻璃、塑料、金属、纸张、纸板、厨余垃圾、有害垃圾等大类。

选数据集时我特别留意了两件事。第一是类别要平衡，如果可回收垃圾图片有5000张，有害垃圾只有200张，模型会对大类过拟合、对小类欠拟合。第二是图片质量，网上下载的图片分辨率参差不齐，有的还带水印，这些都需要统一预处理。

如果你准备自己做数据集，我会建议从Google图片下载脚本起步，再人工清洗一轮无效图，最后每个类别至少300张以上再考虑训练。另外关键一点：验证集和训练集不要来自同一个"拍摄批次"，不然模型记住的是拍摄环境而非物体本身，验证分数会虚高。

2.4 框架选型：TensorFlow还是PyTorch

这个选择在开发社区里争论了很久，但我个人倾向非常明确：这个项目用TensorFlow/Keras实现。原因不是PyTorch不好，而是对于Web端部署，TensorFlow SavedModel格式配合Flask或者TensorFlow Serving都要成熟很多。Keras的高层API写demo模型速度极快，几行代码就能完成数据增强和模型训练，非常适合快速出一版可用系统。

当然，如果你是PyTorch的忠实用户，用TorchServe或者ONNX导出，效果也是等价的。关键是选一个你熟悉的框架，不要花时间在临阵换框架上。项目中我用了TensorFlow 2.x版本来实现，下面的代码示例也按这个框架写。

3. 环境配置与快速启动：从零跑通这套源码

3.1 Python环境准备与依赖清单

很多人第一步就被环境卡住了。这里我把一套干净可复现的环境准备步骤写出来，照着执行即可。

系统环境我用的Windows 10，Python 3.9，原因无他——TensorFlow在3.9上的支持最稳定，很多老版本的坑在3.10之后都冒出来了。如果你之前装过其他Python版本，建议用虚拟环境隔离：

# 创建虚拟环境 python -m venv garbage_env # 激活虚拟环境（Windows） garbage_env\Scripts\activate # 激活虚拟环境（Linux/macOS） source garbage_env/bin/activate

创建完虚拟环境后，我需要确认pip源。国内访问官方源经常慢得让人抓狂，建议直接切国内镜像：

pip install -i https://pypi.tuna.tsinghua.edu.cn/simple --upgrade pip

依赖安装方面，完整的requirements.txt我贴出来：

tensorflow==2.10.0 keras==2.10.0 flask==2.2.2 opencv-python==4.6.0.66 numpy==1.23.5 pandas==1.5.2 matplotlib==3.6.2 pillow==9.3.0 tqdm==4.64.1 gunicorn==20.1.0

特别提醒一下：这里TensorFlow和Keras的版本必须严格对应。TensorFlow 2.10之后Keras已经内置在tf.keras中，不需要单独pip install keras，如果你自己安装了一个新版keras，反而会导致版本冲突报错。如果条件允许，建议直接用GPU版TensorFlow，训练速度快非常多。

3.2 数据准备与预处理脚本

数据集下载好之后，第一步是统一尺寸和格式。我们的EfficientNetB0模型接收的输入尺寸是224x224，所以所有图片都要缩放或裁剪到这个尺寸。一般来说，我会把原始图片先等比缩放到短边256像素，再中心裁剪到224x224。这样既保留了主体信息，又不会因为强行拉伸让物体变形。

数据划分的代码我放到src/preprocess.py中，核心逻辑是把原始数据集按8:1:1划分为训练集、验证集和测试集。为了让读者能调试，我特意用了最简单的shutil复制文件方式，没有引入复杂的生成器：

import os import shutil import random def split_dataset(source_dir, target_dir, train_ratio=0.8, val_ratio=0.1): """把source_dir下的类别文件夹划分到 train/val/test""" for class_name in os.listdir(source_dir): class_path = os.path.join(source_dir, class_name) if not os.path.isdir(class_path): continue images = os.listdir(class_path) random.shuffle(images) train_count = int(len(images) * train_ratio) val_count = int(len(images) * val_ratio) for phase, phase_images in zip( ['train', 'val', 'test'], [images[:train_count], images[train_count:train_count + val_count], images[train_count + val_count:]] ): dst_dir = os.path.join(target_dir, phase, class_name) os.makedirs(dst_dir, exist_ok=True) for img in phase_images: src = os.path.join(class_path, img) dst = os.path.join(dst_dir, img) shutil.copy(src, dst)

这里有一个非常容易踩的坑：文件重名。如果不同来源的图片有相同的文件名，复制到同一个目录时可能会被覆盖。我在实际项目中加了一步，把图片文件名统一改为"时间戳+随机数"后再复制，能彻底避免这种问题。

3.3 数据增强：小数据集逆天改命的核心

垃圾分类数据集的图片数量通常不够大，如果用原始数据直接训练，过拟合几乎是必然的。我的做法是引入一套完整的数据增强流程，包括随机旋转、翻转、亮度调整、对比度调整、缩放和剪切变换。

增加简单数据增强的代码长这样：

from tensorflow.keras.preprocessing.image import ImageDataGenerator train_datagen = ImageDataGenerator( rescale=1.0/255.0, rotation_range=30, # 随机旋转 ±30度 width_shift_range=0.2, # 水平平移 20% height_shift_range=0.2, shear_range=0.2, # 剪切变换 zoom_range=0.2, # 随机缩放 horizontal_flip=True, # 水平翻转 brightness_range=[0.8, 1.2], # 亮度调整 fill_mode='nearest' ) val_datagen = ImageDataGenerator(rescale=1.0/255.0)

我记得第一次训练时偷懒没加数据增强，训练集准确率刷到98%了，验证集只有70%，典型的过拟合。加上旋转和翻转之后，验证集准确率直接拉升到89%左右。如果你之前的项目准确率一直上不去，数据增强绝对是你第一个要检查的环节。

4. 核心功能实现：训练模型与搭建API的完整流程

4.1 迁移学习与模型定义细节

模型定义这块我采用迁移学习的标准流程。先加载EfficientNetB0的ImageNet预训练权重，去掉顶层分类器，然后在上面接一个全局平均池化层、一个Dropout层和一个Dense输出层。为什么加全局平均池化层？因为它可以把任意尺寸的特征图压缩成一维向量，相当于把空间信息分区域取平均，能显著降低过拟合风险。

模型定义的核心代码如下：

import tensorflow as tf from tensorflow.keras.applications import EfficientNetB0 from tensorflow.keras import layers, models def build_model(num_classes): base_model = EfficientNetB0( weights='imagenet', # 加载预训练权重 include_top=False, # 去掉顶层分类器 input_shape=(224, 224, 3) ) base_model.trainable = False # 先冻结底层 model = models.Sequential([ base_model, layers.GlobalAveragePooling2D(), layers.Dropout(0.2), layers.Dense(num_classes, activation='softmax') ]) return model

这里我特意把base_model.trainable设为False，也就是先冻结主干网络的所有层。这样刚开始训练时，只有新加的Dense层在更新参数，相当于在预训练模型的特征基础上做"线性打分"，训练速度快且不容易把预训练权重破坏掉。

等新加的分类层训练得差不多了，再解冻最后几层，用一个很小的学习率做联合微调。这套"先冻结后解冻"的老套路在图像分类上极其经典，也是我强烈建议调试者采用的方式。

4.2 训练参数解读与全程记录

训练阶段的超参数设置直接决定最终效果。我把当时用到的关键参数整理出来，并说明它们的实际作用。

这里特别注意学习率。很多人喜欢用默认的0.001甚至更高，但在迁移学习场景下这几乎是灾难，因为预训练模型的权重已经很好了，过大的学习率会像"急刹车翻车"一样把原有知识破坏掉。我通常把微调阶段的学习率控制在0.0001到0.00001这个区间，稳妥得多。

训练脚本的核心部分：

from tensorflow.keras.callbacks import EarlyStopping, ModelCheckpoint, ReduceLROnPlateau model.compile( optimizer=tf.keras.optimizers.Adam(learning_rate=0.0001), loss='categorical_crossentropy', metrics=['accuracy'] ) callbacks = [ EarlyStopping(patience=5, restore_best_weights=True), ModelCheckpoint('models/best_model.h5', save_best_only=True), ReduceLROnPlateau(factor=0.5, patience=3, min_lr=1e-7) ] history = model.fit( train_generator, steps_per_epoch=train_generator.samples // 32, epochs=50, validation_data=val_generator, validation_steps=val_generator.samples // 32, callbacks=callbacks )

这套配置跑起来之后，我记录的训练曲线大概是这样：前5个epoch验证集准确率就冲上了75%左右，说明预训练权重提供了很好的起点；等解冻主干网络的最后20层再微调10个epoch，验证集准确率稳定在90%以上。如果你的数据集更小，可以适当增加Dropout强度，或者加入L2正则项来防过拟合。

提示：ModelCheckpoint里的save_best_only一定要开，不然训练50轮可能把最好的权重覆盖成一个中途的差权重。restore_best_weights参数和早停搭配，能确保最后留在内存里的是验证集最优状态。

4.3 Flask API：把模型封装成服务

模型训练好之后，下一步就是把模型变成可以被用户调用的接口。Flask这边我写了两个路由，一个处理首页展示，一个处理图片上传与识别。

核心的预测接口实现如下：

import os import numpy as np from flask import Flask, request, jsonify, render_template from tensorflow.keras.models import load_model from tensorflow.keras.preprocessing import image app = Flask(__name__) model = load_model('models/best_model.h5') class_name = ['厨余垃圾', '可回收物', '其他垃圾', '有害垃圾'] category_info = { '可回收物': '请投入蓝色垃圾桶，包括纸张、塑料、金属、玻璃等', '厨余垃圾': '请投入绿色垃圾桶，包括剩菜剩饭、果皮、茶渣等', '有害垃圾': '请投入红色垃圾桶，包括电池、灯管、药品等', '其他垃圾': '请投入灰色垃圾桶，包括砖瓦陶瓷、渣土、卫生间废纸等' } def classify_garbage(img_path): img = image.load_img(img_path, target_size=(224, 224)) img_array = image.img_to_array(img) img_array = np.expand_dims(img_array, axis=0) / 255.0 pred = model.predict(img_array)[0] idx = int(np.argmax(pred)) confidence = float(pred[idx]) return class_name[idx], confidence @app.route('/', methods=['GET']) def index(): return render_template('index.html') @app.route('/predict', methods=['POST']) def predict(): file = request.files.get('image') if file is None: return jsonify({'error': '未上传图片'}), 400 file_path = os.path.join('static/uploads', file.filename) file.save(file_path) result, confidence = classify_garbage(file_path) return jsonify({ 'label': result, 'category': result, 'confidence': round(confidence, 4), 'advice': category_info.get(result, ''), 'image_url': file_path }) if __name__ == '__main__': app.run(host='0.0.0.0', port=5000, debug=True)

这里有几个细节值得注意。第一，模型加载放到全局变量区域，只加载一次，最好不要在每次请求时重新load_model，因为模型加载时间比推理时间长得多。第二，图片预处理必须和训练时保持一致，都缩放成224x224，并且除以255归一化。第三，上传文件要做路径安全校验，不然用户可以直接传一个路径符号搞目录穿越，虽然演示项目无所谓，但习惯要养好。

5. 部署与性能优化：让系统真正用起来

5.1 本地快速启动与局域网访问

运行app.py之后，默认是监听127.0.0.1的5000端口，浏览器输入localhost:5000就能访问。但如果你的用户不在本机，比如在同一个局域网的其他机器或者手机上访问，就需要让服务监听所有网卡地址。上面我的代码里已经写了host='0.0.0.0'，这样局域网内其他设备通过你的电脑IP加端口号也能访问。

首次跑通的时候，我记得最容易出问题的是端口占用。5000端口被其他程序占用时，Flask会直接启动失败，这时候可以换一个端口，比如：

python app.py --port 8080

或者干脆在代码里改成port=8080。本地调试阶段建议打开debug=True，这样改代码后服务会自动重载，还能看到带堆栈信息的报错页面。但生产环境一定记得关闭debug模式和host改成实际监听地址，否则存在很大的安全隐患。

5.2 模型推理加速的三个实操手段

部署之后用户反馈最多的问题就是"识别怎么这么慢"。我实测下来，纯CPU环境下EfficientNetB0推理一张图片大约需要150到300毫秒，还没算上图片上传和加载的耗时。如果并发一多，Flask默认的单线程模式更会拖慢响应。

针对这个问题，我做了三个优化，效果都很明显：

第一，把Flask切到多线程模式。在app.run里加一个threaded=True，Python自带的WSGI服务器就能同时处理多个请求，不再串行排队。对于演示项目来说已经是质的变化。

第二，对模型结果做一次缓存。同一个图片在短时间内被重复上传的概率很低，但同一批测试图片经常会被反复点击。我在Flask里加了一个简单的基于文件MD5值的缓存字典，相同图片直接返回历史结果，省去推理耗时。

第三，导出一个TensorFlow Lite版本的模型。TFLite模型经过量化后体积从原来的约25MB压缩到8MB，推理速度至少翻倍。本地部署时我直接加载量化后的TFLite模型，效果几乎没有下降。

TensorFlow Lite导出的核心步骤：

import tensorflow as tf # 加载训练好的模型 model = tf.keras.models.load_model('models/best_model.h5') # 转换为TFLite格式 converter = tf.lite.TFLiteConverter.from_keras_model(model) converter.optimizations = [tf.lite.Optimize.DEFAULT] tflite_model = converter.convert() # 保存 with open('models/best_model.tflite', 'wb') as f: f.write(tflite_model)

5.3 向移动端和嵌入式设备延伸

如果你想把垃圾分类系统做成一个手机App，思路也完全通。把TFLite模型塞进Android项目的assets目录，然后用CameraX拍照，对照片做相同的预处理后交给TFLite解释器推理。整个流程其实就是这套代码的移动端移植版，模型和预处理逻辑完全复用。

嵌入式设备上也有一个实际可行的路线：用树莓派加摄像头模块，在板子上跑TFLite模型，通过GPIO控制不同分类对应的垃圾桶指示灯。这个方案的实时性要求不高，每两秒识别一次就够用，树莓派4B的CPU跑TFLite量化模型完全没有压力，我实测单帧推理耗时在100毫秒附近。

6. 常见问题与避坑记录

6.1 环境配置阶段的高频问题

下面这组问题我在开发群和评论区被反复问过，整理成速查表方便你快速定位。

6.2 训练过程中的典型问题

训练时损失不下降或者验证准确率和训练差太多，是最常见的两类问题。前者我一般会排查三步：确认数据增强有没有把标签弄乱，确认学习率是否调得太小，以及确认模型结构里激活函数是否加了正确的位置。后者就是过拟合，解决办法通常是增强数据增强强度、增加Dropout比例、或者大幅降低解冻阶段的学习率。

我还遇到过一种比较隐蔽的问题：验证集的图片是从网上爬的官方图，训练集的图片则是摄像头拍的实物图，结果验证集准确率虚高，但真正用手机拍一张实时照片却频繁识别错误。后来我发现是验证集和训练集同源导致的"数据泄露"，换成摄像头采集的真实照片后，准确率才回归真实水平。所以在准备数据集时，一定要让模型面对"没见过的拍摄环境"。

6.3 中文标签编码和显示问题

Flask框架渲染中文一般没问题，但如果你用命令行输出识别结果，Windows控制台默认编码是GBK，print中文标签可能报编码错误。解决办法是在代码开头加：

import sys import io sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding='utf-8')

前端页面这边，后端返回JSON中的中文需要确保Flask的JSON响应是UTF-8格式。如果浏览器出现乱码，在Flask的response对象里手动设置Content-Type为application/json; charset=utf-8即可。

6.4 上传文件时被浏览器拦截

有一个坑是前端input标签若加了accept属性，只允许某些类型的文件，有时候用户手机相册里的图片格式是HEIC，会被浏览器拦截导致无法上传。我建议对上传文件做服务端校验，而不是完全依赖前端过滤，这样后端至少能给出一个明确的错误提示，而不是卡在浏览器端毫无反应。

另外Flask默认的MAX_CONTENT_LENGTH是无限大，不设限制的话容易被大图拖垮内存。我加了一个限制：

app.config['MAX_CONTENT_LENGTH'] = 8 * 1024 * 1024 # 限制8MB

超过限制的图片会返回413错误，前端再提示用户压缩一下图片再传。

7. 下一步还能怎么扩展这套系统

7.1 从单分类到多目标检测

目前的垃圾分类系统解决的是"一张图片里有一种垃圾"的场景，但实际生活中的垃圾桶前经常是多个物体混在一起，比如一个塑料袋里同时装着果皮和塑料瓶。想处理这种复杂场景，就要把系统从图像分类升级为目标检测，用YOLO系列的模型来检测图片中每个物体的位置和类别，再分别给出处理建议。

升级方案我可以给你一个概念上的实现路径：用YOLOv8做检测框架，准备一个带标注框的垃圾检测数据集，训练后每个垃圾物体会被画成框并标出类别。识别结果再叠加四分类投放建议，用户拿手机扫一眼，所有垃圾都有对应答案，体验会比单分类强很多。

7.2 增加语音播报和语音交互

在Web端做完识别之后，你可以用浏览器的Web Speech API直接把识别结果读出来。这个功能在老人使用场景里非常友好，识别完后自动播报"这是可回收物，请投入蓝色垃圾桶"，比让老人看屏幕上的文字直观得多。

语音输入方向也是可以扩展的：用户说出"电池是什么垃圾"，通过语音识别解析关键词，再调用数据库返回对应分类和投放规则。这个方向本质上是结合了NLP和多轮对话，但这个项目目前的主线还是图像识别，语音输入可以作为独立功能叠加。

7.3 引入大模型做知识库问答

如果想做得更智能，可以把垃圾分类知识库和大模型API结合起来。用户拍一张照片识别出具体垃圾名称后，系统自动去检索这个类别更精细的投放指南，比如"纸杯子里有剩奶茶到底怎么扔"这类常见争议场景，大模型可以结合上下文给出更人性化的答复。目前的四分类系统还比较粗，细化场景的回答能力是这套系统后续提升空间最大的方向之一。

我在实际把垃圾分类系统做到了这一步之后，最大的体会是"能跑起来"和"好用"之间差着几十个细节。从数据增强到模型量化，从中文编码到并发处理，每一步都踩过坑也填过坑。希望这篇文章能帮你少走一些弯路。如果你还有更好的分类策略或者部署方案，欢迎按你自己的思路继续往下做，这套源码的结构改起来相当顺手。

本文还有配套的精品资源，点击获取