企业官网建设流程全解析

简介：一套面向毕业设计与深度学习入门者的农作物病虫害识别系统完整项目，基于Python实现，融合云服务与CNN图像分类技术。项目覆盖数据采集、图像预处理（缩放、裁剪、旋转增强、归一化）、模型训练与优化等完整流程；后端采用Flask提供API服务，前端支持图像上传与结果展示，并给出AWS、GCP云端部署方案。资源共60个文件，约88.75MB，其中9个Jupyter Notebook分别基于TensorFlow、Keras、PyTorch、Fastai等框架实现，并对比ResNet50、DenseNet121、VGG16、VGG19等网络；另有Python脚本、HTML/CSS/JS前端页面、模型pkl权重、MD部署文档、Dockerfile及YAML配置，还包含演示图片与运行说明，方便搭建本地或云端环境。目录结构清晰，已有127人浏览学习；对于需要快速完成课设、毕业设计，或入门深度学习图像识别的读者，可直接对照不同框架的Notebook训练与部署指南动手复现，同时理清从数据预处理到云端上线的完整链路，节省环境配置和代码梳理时间。

1. 这个标题到底在做什么：先把「云技术 + 深度学习」的边界拆清楚

一套「基于云技术与深度学习的常见农作物病虫害识别系统」，本质上是三件事：整理带标签的作物叶片图像数据，训练一个图像分类模型，再把这个模型包装成能对外提供识别服务的云端接口。很多人拿到这类源码.zip的第一反应是「直接从训练代码跑起」，但真正决定这个系统能不能用的，反而是数据目录怎么摆、训练和推理的前处理是否一致、模型文件怎么在云服务器上被加载这三件不起眼的事。

这套系统适合两类人：一类是做课程设计、毕业设计，需要从源码里拆出「数据模块 + 训练模块 + 接口模块」三层结构来写文档；另一类是给农技站、种植基地做小规模试点，手里有几百到几千张现场照片，想先花一两天搭出一个能识别番茄叶霉病、玉米锈病这类常见病害的原型。云技术在这里不是噱头，它解决的是两个实际痛点：本地没有 GPU 时把训练放到云上跑，以及模型训练好后让多个终端共享同一个识别服务。下文所有内容都围绕「拿到源码后如何按顺序落地」展开，代码以 TensorFlow/Keras 生态为主，这也是这类系统最常见的实现方式。

2. 系统架构与模型选型：识别系统先想清这四件事

2.1 四个模块与数据流：识别系统为什么不能只写一个 CNN

常见农作物病虫害识别系统的代码包，拆开来看几乎都是同一个骨架：数据管理、模型训练、识别服务、结果回显。如果你只看训练脚本，会觉得这系统就是个 CNN 分类器；但把它放到真实场景里，数据管理的代码量往往比模型还要多，因为田间拍摄的照片不会像公开数据集那样自动带好标签。

数据流通常是这样的：用户上传一张叶片照片，识别服务先对图片做尺寸归一化和像素值归一化，再把归一化后的张量喂给模型，模型输出每个类别的置信度，最后由服务层决定是直接返回「番茄晚疫病，置信度 87%」，还是低于阈值时返回「无法判断，请重新拍摄」。云技术在这一层最常见的落法不是自建集群，而是训练时租用云 GPU 实例跑训练脚本，推理时把模型和 FastAPI 服务打包成 Docker 镜像部署到云服务器，照片本身可放在对象存储里，接口只传路径或直接传图片二进制流。

我们一般建议源码里的目录结构长成下面这样，这也是大多数这类项目的标准形态：

crop_disease_system/ ├── data/ │ ├── raw/ # 原始图片，按类别分文件夹 │ ├── train/ # train/val/test 划分后的训练集 │ ├── val/ │ └── test/ ├── src/ │ ├── train.py # 模型训练入口 │ ├── preprocess.py # 统一的前处理逻辑 │ ├── predict.py # 单张图片推理 │ └── app.py # FastAPI 识别服务 ├── models/ # 训练产出的权重文件 ├── requirements.txt └── README.md

这样的分层逻辑在于：preprocess.py是训练和推理共用的同一份前处理代码，谁都不许各自写一份，否则就会出现「训练时用 PIL 读图、推理时用 OpenCV 读图」这种灾难。对象存储和云 GPU 在这一层都不是必须项，但源码里留好data/raw/和models/这两个目录，后续拓展云存储和模型版本管理会顺很多——这是我这几年看这类系统源码后认为最容易被忽略的设计点，初期顺手做好能省下大量返工。系统设计阶段要清楚：核心不是写出 SOTA 模型，而是保证「数据进得来、权重存得住、接口调得通」。

2.2 数据集的组织方式：标签目录、类别划分与公开数据集

在写训练代码之前，先确认数据怎么摆。常见公开数据集 PlantVillage 包含番茄、玉米、葡萄等多种作物的健康与病害叶片图像，类间样本数差距极大，多的类别有几千张，少的只有几百张。这种集合拿到手第一件事不是训练，而是把类别筛选到和你业务匹配的子集，比如只做番茄的 9 类（健康 + 8 种病害）。

推荐用目录结构直接表达标签，因为 Keras 的image_dataset_from_directory能自动从子目录名读取类别，不需要额外写 CSV 标签文件：

data/train/ ├── Tomato_healthy/ ├── Tomato___Late_blight/ ├── Tomato___Leaf_Mold/ └── Tomato___Septoria_leaf_spot/ data/val/ └── ... # 与 train 同构

划分比例按 8:1:1 或 7:2:1 都行，关键是保证划分前先对文件列表做一次永久随机打乱，并且固定随机种子。很多「训练时 98% 验证集 60%」的翻车现场，就是 val 和 train 里混入了同一批图片——田间采集时连续拍摄的叶片本来就很像，不做去重划分会让验证集严重偏乐观。我会额外加一步：按图片文件名或哈希做去重，把完全相同的文件从训练集里剔除，再随机划分。

如果你要自建数据集而不是用公开集合，有一个容易被轻视的点：每个类别要保证在多个角度、多种光照条件下采集，而不是在同一个上午对着同一块田拍完。否则模型学到的是「那块田的背景」，不是「病斑的特征」。采集完可以按下面的脚本把 raw 目录划分成 train/val/test：

# split_data.py import os import random import shutil random.seed(42) # 固定随机种子，保证每次划分结果一致 RAW_DIR = "data/raw" TRAIN_DIR = "data/train" VAL_DIR = "data/val" TEST_DIR = "data/test" RATIO = (0.8, 0.1, 0.1) for cls in os.listdir(RAW_DIR): cls_path = os.path.join(RAW_DIR, cls) if not os.path.isdir(cls_path): continue images = [f for f in os.listdir(cls_path) if f.lower().endswith((".jpg", ".jpeg", ".png"))] random.shuffle(images) # 打乱后再切分，避免连续拍摄样本扎堆 n_train = int(len(images) * RATIO[0]) n_val = int(len(images) * RATIO[1]) for split_dir, split_list in [ (TRAIN_DIR, images[:n_train]), (VAL_DIR, images[n_train:n_train + n_val]), (TEST_DIR, images[n_train + n_val:]) ]: target = os.path.join(split_dir, cls) os.makedirs(target, exist_ok=True) for img in split_list: shutil.copy(os.path.join(cls_path, img), os.path.join(target, img)) print("划分完成，请人工抽查 val/test 中是否存在与 train 重复的图片")

这段代码的逻辑不复杂，但需要注意三个参数：random.seed(42)保证可复现，你同事跑出来的划分和你完全一致；RATIO三元组按训练/验证/测试分配比例；shutil.copy用复制而不是移动，留一份 raw 作为后悔药。如果某些类别图片数不足 50 张，我不建议硬切 8:1:1，此时可以直接做 K 折交叉验证，或者用数据增强后的副本补足训练集，否则验证集会太小、指标波动大到你无法判断模型好坏。

2.3 模型选型：从 ResNet50 迁移学习起步，别从零训练 CNN

很多课程设计直接写一个 5 层 CNN 从头训练，准确率卡在 70% 上下。真实项目中很少这么干，因为我们手里的数据量远不足以支撑从零训一个深层网络。这里的成熟做法是迁移学习：加载 ImageNet 预训练权重，冻结前若干层，只训练最后的分类层或微调后几层。使用 TensorFlow/Keras 时，常见的选择是 ResNet50 或 EfficientNetB0，前者蒸馏稳定、几乎不会训练崩，后者参数更小、便于部署到 CPU 云服务器上推理，适合作为系统的默认基线。

如果你要训练一个 V2 版本（比如把类别从番茄扩展到水稻、小麦），注意一个容易被忽略的选型细节：预训练权重是 224x224 输入尺寸训出来的，换模型时不要把输入分辨率擅自改成 512，这会让模型加载时报 shape 不匹配，或者被迫丢弃预训练权重。v2 的输入图像尺寸应优先保持和预训练一致，如果确实需要大图细粒度识别，再考虑引入坐标注意力或做图像切片推理，而不是盲目改分辨率。

选型对比可以按这张表来定：

结论很直接：第一版永远从 ResNet50 微调开始，等到确定业务需要更低延迟或更高精度时，再横向换成 EfficientNet 或尝试 ViT，并保留同一个评估脚本去跑对比。模型选型这层决定了系统的识别上限，但决定下限的往往是数据质量和前处理一致性，这两个坑下文都会展开。

3. 用 Keras 把训练跑通：核心代码与参数怎么定

3.1 训练脚本：数据增强、迁移学习、早停与 Checkpoint

当你从 vscode 里新建好项目目录、用pip install tensorflow装好依赖后，最先要跑通的就是训练脚本。这个训练脚本的骨架可以覆盖整个深度学习识别系统的核心逻辑：数据读取、增强、迁移学习、回调函数。下面给出一个经过实际项目验证的最小可用版本，不需要 GPU 也能用小数据集跑通，但完整训练建议放到云 GPU 实例上执行，代码完全一致。

# src/train.py import tensorflow as tf from tensorflow.keras import layers, models from tensorflow.keras.applications import ResNet50 from tensorflow.keras.callbacks import EarlyStopping, ModelCheckpoint, ReduceLROnPlateau IMG_SIZE = (224, 224) BATCH_SIZE = 32 EPOCHS = 30 NUM_CLASSES = 9 # 数据增强：只对训练集做，验证集和测试集不做 train_ds = tf.keras.preprocessing.image_dataset_from_directory( "data/train", image_size=IMG_SIZE, batch_size=BATCH_SIZE, label_mode="categorical", ) val_ds = tf.keras.preprocessing.image_dataset_from_directory( "data/val", image_size=IMG_SIZE, batch_size=BATCH_SIZE, label_mode="categorical", ) # 归一化：把 0-255 像素值缩放到 0-1 normalization = layers.Rescaling(1.0 / 255) train_ds = train_ds.map(lambda x, y: (normalization(x), y)) val_ds = val_ds.map(lambda x, y: (normalization(x), y)) # 训练集加数据增强，缓解类别少、图片少的问题 data_augmentation = tf.keras.Sequential([ layers.RandomFlip("horizontal"), layers.RandomRotation(0.1), layers.RandomZoom(0.1), ]) # 迁移学习：ImageNet 预训练权重 + 全局池化 + 全连接分类头 base_model = ResNet50(weights="imagenet", include_top=False, input_shape=(224, 224, 3)) base_model.trainable = False # 第一阶段冻结主干 model = models.Sequential([ data_augmentation, base_model, layers.GlobalAveragePooling2D(), layers.Dropout(0.2), # 防过拟合 layers.Dense(NUM_CLASSES, activation="softmax") ]) model.compile( optimizer=tf.keras.optimizers.Adam(learning_rate=1e-3), loss="categorical_crossentropy", metrics=["accuracy"] ) callbacks = [ EarlyStopping(monitor="val_loss", patience=5, restore_best_weights=True), ModelCheckpoint("models/crop_model.h5", monitor="val_accuracy", save_best_only=True), ReduceLROnPlateau(monitor="val_loss", factor=0.5, patience=3, min_lr=1e-6) ] history = model.fit( train_ds, validation_data=val_ds, epochs=EPOCHS, callbacks=callbacks ) # 解冻最后 10 层做微调，学习率调小 base_model.trainable = True for layer in base_model.layers[:-10]: layer.trainable = False model.compile( optimizer=tf.keras.optimizers.Adam(learning_rate=1e-5), loss="categorical_crossentropy", metrics=["accuracy"] ) model.fit(train_ds, validation_data=val_ds, epochs=EPOCHS // 2, callbacks=callbacks) model.save("models/crop_model_final.h5")

代码里几个参数值得单独说明。Batch_size决定显存占用和梯度稳定性，云 GPU 上 32 是安全值，显存不够就降到 16，如果出现 loss 剧烈震荡，优先检查是不是 batch 太小。RandomFlip/RandomRotation/RandomZoom是三种最常见且对叶片识别有效的增强方式，不要上来就加 RandomBrightness，田间照片亮度不均时这个增强容易把病斑颜色带偏。EarlyStopping的patience=5表示验证集 loss 连续 5 个 epoch 不下降就停，防止过度训练；restore_best_weights=True很重要，它能保证停训后模型回滚到最优权重文件，而不是停在最后一个 epoch 的参数上。

微调阶段（解冻最后 10 层）的学习率必须比第一阶段小一个量级，用1e-5而不是1e-3，否则预训练特征会被大步长更新破坏，出现训练集准确率上升但验证集暴跌的过拟合征兆。模型保存两次，中间过程的crop_model.h5是回调保存的 best-only 权重，最终跑完的crop_model_final.h5是最优阶段继续微调的结果，通常前者更适合作为上线模型，因为微调后半段不一定每步都在变好。如果你不想踩「两个 h5 选哪个」的坑，训练完后直接用ModelCheckpoint生成的那份。

3.2 推理与阈值：训练完输出什么，预测时怎么用

训练完成后，模型文件基本在几十到两百兆之间，云服务器上加载它需要几分钟内就能完成。但「加载模型」和「能正确识别」之间还有一段距离，这段距离就是推理脚本要处理的核心：前处理必须与训练时完全一致。很多源码包只给了 train.py，predict.py 写得含糊，所以你拿到手后要自己补齐这一块。

# src/predict.py import numpy as np import tensorflow as tf from PIL import Image CLASS_NAMES = ["Tomato_healthy", "Tomato___Late_blight", "Tomato___Leaf_Mold", "Tomato___Septoria_leaf_spot", "Tomato___Spider_mites", "Tomato___Target_Spot", "Tomato___Tomato_Yellow_Leaf_Curl_Virus", "Tomato___Tomato_mosaic_virus", "Tomato___Bacterial_spot"] def preprocess_image(image_path: str, target_size=(224, 224)) -> np.ndarray: """推理前处理，严格保持与训练时一致""" img = Image.open(image_path).convert("RGB") img = img.resize(target_size) # PIL 的 resize 默认双线性插值 arr = np.array(img, dtype=np.float32) / 255.0 # 归一化到 0-1 arr = np.expand_dims(arr, axis=0) # 增加 batch 维度 -> (1, 224, 224, 3) return arr def predict_top_k(model, image_path: str, k: int = 3, threshold: float = 0.5): arr = preprocess_image(image_path) probs = model.predict(arr, verbose=0)[0] # shape = (NUM_CLASSES,) top_idx = np.argsort(probs)[::-1][:k] # 取概率最大的前 k 个类别 results = [] for i in top_idx: if probs[i] >= threshold: results.append({"label": CLASS_NAMES[i], "confidence": float(probs[i])}) return results if __name__ == "__main__": model = tf.keras.models.load_model("models/crop_model_final.h5") for p in ["test/Tomato_healthy/1.JPG", "test/Tomato___Late_blight/2.JPG"]: print(p, predict_top_k(model, p))

推理代码的参数要点集中在两处：threshold=0.5是最低置信度门槛，低于这个值的预测应该被当成「不确定」而不是强行返回一个类别，.jpg或.png图片在用 PIL 打开后统一转RGB，避免某些手机拍摄的图片是 RGBA 四通道时导致model.predict直接报 shape 错误。top_k=3返回前三个候选类别，适合做「辅助诊断」而不是「机器下结论」，这在农业场景里更容易被使用方接受。最后，model.predict每次调用都会重新跑一遍图计算，如果接口 QPS 要求高，应改用tf.function或 TensorFlow Serving，后文会提到。

3.3 封装成云端识别接口：FastAPI + 权重加载

源码包里如果只有训练和推理脚本，还不能叫「识别系统」，因为使用方不可能拿着命令行去识别。常见做法是把 predict 脚本封装成 FastAPI 接口，部署到云服务器后供小程序、网页或农技站桌面端调用。FastAPI 自带 OpenAPI 文档，调试非常方便。

# src/app.py from fastapi import FastAPI, UploadFile, File import tensorflow as tf import numpy as np from PIL import Image import io from predict import preprocess_image, CLASS_NAMES app = FastAPI(title="Crop Disease Recognition API") # 模型只在服务启动时加载一次，避免每个请求重复加载 model = tf.keras.models.load_model("models/crop_model_final.h5") @app.post("/predict") async def predict(file: UploadFile = File(...)): contents = await file.read() img = Image.open(io.BytesIO(contents)) # 直接复用 predict.py 里的前处理逻辑，保证一致性 arr = preprocess_image(img) probs = model.predict(arr, verbose=0)[0] top_idx = np.argsort(probs)[::-1][:3] result = [ {"label": CLASS_NAMES[i], "confidence": round(float(probs[i]), 4)} for i in top_idx ] return {"success": True, "predictions": result} if __name__ == "__main__": import uvicorn uvicorn.run(app, host="0.0.0.0", port=8000)

启动命令为uvicorn src.app:app --host 0.0.0.0 --port 8000，这里有几个关键操作：0.0.0.0监听所有网卡，否则云服务器外部访问不到接口；模型加载写在全局区而不是函数内部，这是避免每个请求都把几百兆的权重重新载入一次，否则并发一上来服务直接假死。preprocess_image里Image.open(io.BytesIO(contents))接收的是二进制流，你无需把上传的图片先存到本地磁盘，直接内存推理，减少 IO。

实际部署到云服务器时有一个部署层注意点：云服务器默认有安全组或防火墙，创建实例后要手动放行 8000 端口，否则本地 curl 通了、公网访问超时。如果整个系统走 HTTPS 域名，还需要在前面加一层 Nginx 反代，把/predict转发到本机 8000。云端部署的完整动作是：本地把代码和模型整理好，用 Docker 把 Python 环境和模型一起打包，推到云镜像仓库后在服务器上拉取运行，这样从训练到上线的时间能压缩到一个小时以内。

4. 指标与调优：识别准确率之外，还要盯住哪些数字

4.1 精度、召回与混淆矩阵：类别不平衡的翻车现场

训练日志里那个accuracy是很具迷惑性的数字。假设你的数据里有 3000 张健康叶子和 200 张早疫病叶子，模型即使把所有图片都判成健康，准确率也有 93.7%，但这种模型对农技站来说毫无价值，因为真正要识别的恰恰是少数类。所以在评估代码包里应该加入混淆矩阵和每类召回率的输出，而不是只贴一个总准确率。

# evaluate.py from sklearn.metrics import confusion_matrix, classification_report import tensorflow as tf import numpy as np test_ds = tf.keras.preprocessing.image_dataset_from_directory( "data/test", image_size=(224, 224), batch_size=32, label_mode="categorical", shuffle=False # 保持顺序，方便对齐文件名 ) model = tf.keras.models.load_model("models/crop_model_final.h5") y_true = np.concatenate([y.numpy() for _, y in test_ds], axis=0) y_pred = model.predict(test_ds) y_true_cls = np.argmax(y_true, axis=1) y_pred_cls = np.argmax(y_pred, axis=1) # 输出每个类别的精确率、召回率、F1 print(classification_report(y_true_cls, y_pred_cls, digits=4)) # 输出混淆矩阵，定位哪些类别互相混淆 print(confusion_matrix(y_true_cls, y_pred_cls))

评估时要特别注意三点：shuffle=False是为了让预测结论能对应到具体文件，方便手持一张错分图片去复现排查；classification_report里的recall如果是某个类别只有 0.4，说明该类别的样本大概率被系统性误判成了别类；confusion_matrix里看对角线旁边的密集区域，比如「晚疫病」和「早疫病」互相混淆，那就需要补充两类各自的典型样本。

真实项目里我吃过一个亏：只看总准确率 95% 就上了生产，结果农户上传的番茄叶霉病图片几乎全部被识别成健康。翻车原因是叶霉病早期病斑很小，模型被健康样本带偏。这之后我把评估习惯改成「每个类别 recall 必须过 80% 才允许上线」，并且把测试集里各类别数量打出来，样本少于 50 的类别不单独做上线评估。这套习惯比调参更管用。

4.2 云上训练与本地验证的指标漂移

用云 GPU 训练时会碰到一个很玄学的现象：云上训练完的模型，下载到本地推理，同一个测试集跑出来的准确率和训练日志不一样，甚至差 2% 到 5%。常见原因是训练日志里的验证集是「训练过程中留在 GPU 环境里的那份数据」，如果你的源码里 val 文件夹没有拷贝上云，云上的image_dataset_from_directory("data/val")实际读的是空目录，Keras 虽然报错但有些版本会静默跳过，导致验证集永远跑在训练集子集上，指标虚高。

要规避这个坑，云上训练跑完后，立刻把模型下载回本地，重新用完整的本地测试集跑一次evaluate.py，以本地结果为最终成绩。如果发现本地指标比云上低，不要急着调模型，先核对数据划分的随机种子是否一致、云上有没有同步最新划分后的 val 目录。指标漂移是数据问题占八成，模型问题占两成，这个判断顺序能节省大量调参时间。

4.3 数据增强和类别加权的调参

当识别指标卡在某个点上不去时，优先考虑两个方向的调整：一是增强策略的强度，二是类别不平衡的加权。数据增强不是越猛越好，RandomRotation(0.1)是 10 度以内的轻微旋转，如果加大到 0.3，叶片纹理被旋转后病斑形状失真，模型反而更难学。类别加权的实现很简单：model.fit里传入class_weight参数，给样本少的类别更高的权重，让损失函数更重视它们。

如果你用的是model.fit(train_ds, ...)这种数据集对象方式，可以先算出每类样本数，再用sklearn.utils.class_weight.compute_class_weight生成权重字典传入。调class_weight后训练集准确率通常略微下降，但少数类召回率明显上升，这正是我们要的。优先用已标注的公开数据训练出一个可用的基线模型，后续自建数据集的类别分布差异可以再靠增量训练修正。

5. 避坑与常见问题排查：从训练到上线最容易翻车的五处

5.1 前处理不一致：训练正常，推理全错

现象：训练时验证集准确率 90% 以上，部署到接口后用手机拍一张同样病害的叶子，识别结果完全错误，甚至返回无关类别。

原因：训练和推理用了两套前处理。常见于train.py用 Keras 的image_dataset_from_directory自动做缩放和归一化，而predict.py单独写了resize，没有除以 255，或者Image.open出来的图片是 RGBA 四通道，模型却期望三通道输入。

解决：把前处理抽成一个独立的preprocess.py模块，训练和推理都从它导入。对着同一张测试图分别走训练管道和推理管道，比较进入模型前的张量是否一致（打印 shape 和数值范围）。额外留一个单测脚本，把测试集里某张图片喂给predict.py，比对输出和线上接口的输出，误差应在 1e-4 以内。

5.2 类别不平衡：「全猜健康」也能刷高准确率

现象：训练日志显示准确率不断上升，但输出混淆矩阵后发现某几个病害类别召回率为 0。

原因：数据集中健康样本占绝对多数，模型学到的决策边界倾向于把所有输入都判为健康，因为这样 loss 已经很低了。只盯accuracy这个指标完全看不出问题。

解决：训练阶段给少数类加class_weight，评估阶段以每个类别的召回率作为上线标准。如果加了权重仍然无效，优先补充少数类样本，用旋转、裁剪、颜色扰动生成增强副本，而不是继续调网络结构。

5.3 GPU 显存溢出：OOM 报错卡死训练

现象：云 GPU 实例显存 16G，batch_size 设为 64，训练第一个 epoch 就报ResourceExhaustedError。

原因：输入尺寸 224x224 加上 ResNet50 的中间特征图对显存占用很大，batch 越大占得越多。多卡或单卡不同，显存剩余也不同。

解决：先把batch_size降到 16 或 8 试跑一个 epoch，确认显存余量后再逐步上调。若必须开大 batch，打开混合精度tf.keras.mixed_precision.set_global_policy("mixed_float16")，显存占用可降低约 40%。显存溢出和模型精度没有直接关系，不要为了面子硬开大 batch。

5.4 模型文件加载失败：服务器上没有 GPU

现象：本地训练好crop_model_final.h5，部署到廉价的 CPU 云服务器，load_model报错Could not load model或运行时 GPU 相关依赖缺失。

原因：模型文件默认包含 TensorFlow 的 GPU 算子，如果训练和部署环境的 TensorFlow 版本不一致，或部署环境没有安装 GPU 版运行时，加载就会失败。

解决：部署环境统一用tensorflow-cpu，并在保存模型时用model.save("...", save_format="keras")，避免 H5 格式跨版本兼容问题。如果服务器内存小于 4G，建议把模型导出为 TensorFlow Lite 格式（.tflite），体积约为原来的四分之一，加载速度也会快不少。推理接口吃的是并发和延迟，不是 GPU 算力，CPU 实例足够支撑试点级别的小流量。

5.5 结果不可复现：同一份代码两次跑出不同结果

现象：固定了random.seed(42)，训练两次，最终准确率还是差了 1% 左右，怀疑是不是代码有 bug。

原因：深度学习训练过程受数据读取顺序、GPU 算子并行等影响，本身就是随机的。固定 Python 的random和 NumPy 的种子只能约束一部分，不能完全锁定 GPU 计算结果。

解决：把「可复现」的标准从「完全一致」降级为「多次训练指标波动在可接受范围（如 ±1%）」。记录每次训练的模型文件和对应指标，上线时选验证集指标最好的一份。不要因为两次训练结果不同就反复重训，那是用算力对抗随机性，不值当。

6. 让源码包真正变成你的系统：工程化收尾与二次开发

拿到或自己拼好这套源码之后，最后一步是把「能跑的代码」变成「能长期维护的系统」。我会按三个顺序做：先清理目录，把训练产出的中间文件和临时图片挪出仓库；再补一份一页纸的接口说明，写清上传图片的格式限制和返回字段含义；最后给模型接上一个简单的知识库映射，把「识别出晚疫病」对应到「建议用药和防治措施」，这个映射用 JSON 存就行，不需要数据库。

如果你想做得更进一步，可以试着把模型导出成 ONNX 或 TFLite 格式，用更轻的运行时替代 TensorFlow 全家桶，让云服务器占用从 2G 内存降到 500M；也可以在源码里加入简单的类激活图（CAM）输出，把模型关注到的病斑区域可视化，这项功能用来跟农技人员解释「模型为什么这么判断」尤其有效，比空口说准确率有用得多。这些收尾工作不会改变模型精度，但决定这个系统能否在你离开后还被别人继续使用下去。

我不止一次见到这样的项目：训练脚本和评估脚本写得很好，但 README 里没写测试集的来源和划分方式，半年后原作者自己也说不清哪些数据被用来验证过。所以我的习惯是，在任何源码交付前，先写「如何用 20 张真实照片验证系统是否正常工作」这段文字，再写怎么安装依赖、怎么起服务。这比把代码注释写满更值得投入时间。

这套农作物病虫害识别系统的核心价值，不是那个模型有多前沿，而是它把「数据整理、模型训练、云端接口、识别结果回显」的完整链路打通了。你在源码包基础上每补一个功能和一段记录，当下次遇到水稻或棉花作物时，就有了一个可以直接复用的骨架。这也是我把云训练、容器部署、阈值决策这些细节都摊开来讲的原因。希望帮到你。

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