企业官网建设流程全解析

1. 项目概述

其实我一直觉得，目标检测这个方向最让人上头的不是模型本身，而是"我自己的数据到底能不能训出来"这件事。YOLO26 这个词最近在圈子里被频繁提起，我个人的理解是，它并不是官方某个固定版本号那么简单，更多时候是大家在项目群里对"新一代 YOLO 系列工具链"的一种统称——我们把 ultralytics 框架下当前可用的、包含最新改进的检测训练体系约定俗成叫作 YOLO26。

有朋友可能会问：我到底要不要追这个版本？我的建议很直接——先别纠结名字，核心是这套流程能不能跑通你自己的数据集。这篇文章我打算用一次完整的人形检测项目为例，从环境准备、数据标注、yaml 配置、训练调参到推理导出的全流程，带你训练出第一个属于自己的 YOLO26 模型。无论你是要做计算机视觉大作业，还是想在公司内部落地一个人员入侵检测原型，这套方法论基本都能复用上。

先说清楚这篇文章适合谁：刚接触目标检测、想拿自己的图片跑通一套完整流程的初学者，以及被数据集格式、loss 不收敛、显存爆掉等问题卡住的项目开发者。我会把每一步的操作意图和坑位都交代清楚，照着做基本不会迷路。

2. 用 YOLO26 之前，先把这些底层逻辑想明白

2.1 为什么目标检测训练不是"喂图"那么简单

目标检测和图像分类最大的区别在于：分类只回答"这是什么"，而检测要回答"这是什么、它在哪里"。所以模型输出的不是一个概率值，而是一堆边界框坐标加类别概率。YOLO 系列的核心思想是把整张图划分成一个 S×S 的网格，每个网格负责预测中心点落在该网格内的目标，同时输出边框位置、置信度和类别概率。

放到实际训练里，这就意味着你的标注不能只给图片打个标签，还需要精确标出每个目标的外接矩形框。很多人第一次训练模型，数据准备好了、代码跑起来了，结果 mAP 惨不忍睹，回头一查，问题往往出在标注框质量上：框太大把背景包进去了，或者太小只框住了目标的一半。模型学到的特征就会很混乱。

从我自己的实践体会来看，训练一个可用的检测模型，60% 的精力要花在数据上，模型本身反而不是最大的瓶颈。YOLO26 这类模型在 COCO 等公开数据集上的 baseline 已经相当能打，但换到你的业务场景里，能不能泛化就全看训练数据是否贴近真实分布了。

2.2 从 YOLOv5 到 YOLO26：模型中到底改了什么

很多人在选版本时犹豫不决。我简单梳理一下脉络：YOLOv5 奠定了 ultralytics 框架的易用性，YOLOv8 引入了 anchor-free 检测头和 C2f 结构，训练时还可以用方形自适应灰度填充；到后续版本，C2f 继续演进，检测头也做了解耦优化，同时支持旋转框、姿态估计、跟踪等多种任务。

YOLO26 如果按社区讨论的语境来理解，其实代表的是这个框架体系里集成最新改进的一代。它普遍有这些特点：第一，模型配置文件对用户更友好，结构可视化更清晰，也就是热词里常说的"yolo26结构图"可以很方便地导出来；第二，对边缘端部署做了针对性优化，很多人在树莓派 5、Jetson 这类设备上部署，模型精度和推理速度之间的平衡更灵活；第三，提供了多种模型规格，n/s/m/l/x 不同尺寸对应不同的精度与速度取舍。

举个例子，如果你用的是树莓派 5 这种算力有限的设备，建议直接选 n 或 s 规格；要是做离线分析、对速度不敏感，那 l 或 x 规格能换来更高的精度。这个选型思路在 YOLO26 里依然成立，具体到你自己项目里，先用小模型把流程跑通，再逐步放大，是最稳妥的策略。

2.3 别把检测训练和"OCR 或知识库"混为一谈

平时在社区里经常看到两类容易混淆的问题：一类是 "easyocr 训练自己的模型"，另一类是 "anythingllm 可以训练模型吗"。这里我说清楚：EasyOCR 是 OCR 识别工具，你要是想训练自己的检测模型来定位文字区域，那可以用 YOLO26 做文本检测，但识别文字内容本身还是需要 OCR 模型，方向别搞反。

AnythingLLM 是知识库问答应用，它更多是把文档切块后做向量检索，再配合大模型生成答案，和我们这里讨论的"训练一个目标检测模型"完全是两回事。如果你只是想把公司内部文档做成问答机器人，不需要训练模型，配置好向量库就行；但如果你要识别图片里的目标个数和位置，那就得回到 YOLO26 这条路上来。

想清楚你要解决的是检测、分类、OCR 还是知识库问答，才能选对工具。这个前置判断比调参都重要，能帮你少走好几天的弯路。

3. 训练环境搭建与数据准备

3.1 环境安装：用 conda 隔离环境是必须做的一步

我之前吃过不少亏：把 PyTorch、TensorFlow 的依赖装在一个环境里，结果版本互相打架，今天这个库升级，明天那个库不兼容。所以这里明确建议，训练 YOLO26 一定要单独建一个虚拟环境。

我自己用的是一套比较稳妥的配置，放在这里供你直接参考。

conda create -n yolo26 python=3.10 -y conda activate yolo26 # 先装 PyTorch，注意根据自己的 CUDA 版本选择安装命令 # 以 CUDA 11.8 为例 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 # 安装 ultralytics 框架 pip install ultralytics # 如果之后要导出 ONNX 或 TensorRT，需要补充下面这些 pip install onnx onnxruntime-gpu

装完以后，验证一下环境是否可用：

import torch import ultralytics print("CUDA available:", torch.cuda.is_available()) print("GPU name:", torch.cuda.get_device_name(0) if torch.cuda.is_available() else "CPU only") print("Ultralytics version:", ultralytics.__version__)

如果 CUDA 不可用，也不是不能跑，就是训练会慢很多。小数据集、n 规格模型用 CPU 也能出结果，但训练集大、epoch 多的时候建议还是想办法搞一块 N 卡。实测下来，一张 8GB 显存的显卡跑 s 规格、640x640 输入、batch size 16，基本可以撑住，再大就得调小 batch 或用梯度累积。

3.2 数据采集：自己拍照、公开数据集还是爬图

训练数据从哪里来，取决于你的需求。

如果是做计算机视觉大作业或者课程项目，最省事的方式是直接用公开数据集，比如 COCO、VOC，或者 Roboflow 上现成的数据集。但有一个问题：公开数据集的类别和你的需求不一定匹配。

如果要做人员入侵检测这类特定场景项目，我的经验是：先拍或搜集 500~1000 张覆盖场景多样性的图片，比如不同光照、不同角度、不同距离的人形样本，通常效果就比直接拿 COCO 的人类别好。因为 COCO 里的 person 类别包含各种生活场景，而你的监控画面角度相对固定，模型的适配空间反而不如自己标注数据来得精准。

图片采集要注意的点：

• 场景多样性优先：别只在同一角度、同一天气下拍，那样模型容易过拟合到背景上。
• 分辨率不用太高：训练时 YOLO26 默认会把输入图缩放到 640x640，所以原图 1280 以上就很够了，过大的图反而增加标注负担。
• 数量服从质量：300 张高质量、标注准确的图片，胜过 1000 张标注混乱的图片。

3.3 数据标注：LabelImg 已经够用，但格式别选错

数据标注工具我推荐三个：LabelImg、anylabeling、Roboflow。其中 anylabeling 对 YOLO 格式支持很友好，自带模型辅助标注，可以提高效率。

标注完成后最关键的是导出格式必须选 YOLO 格式。YOLO 格式的标注文件是 txt，每一行表示一个目标：

class_id center_x center_y width height

需要注意：坐标全部是归一化后的数值，范围 0~1。中心点坐标、宽高都要除以图片的宽或高。很多人第一次训练 loss 爆炸或者完全学不出来，就是格式写错了。

举例说明，一张 1920x1080 的图片里有一个行人，边界框左上角坐标是 (960, 540)，右下角是 (1200, 810)，那么：

x_center = (960 + 1200) / 2 / 1920 = 1080 / 1920 = 0.5625 y_center = (540 + 810) / 2 / 1080 = 675 / 1080 = 0.625 width = (1200 - 960) / 1920 = 240 / 1920 = 0.125 height = (810 - 540) / 1080 = 270 / 1080 = 0.25

对应 txt 里的内容（假设 person 是第 0 类）：

0 0.5625 0.625 0.125 0.25

用 anylabeling 或 LabelImg 导出的 YOLO txt 会自动算好这些值，但我还是建议你抽几行出来手动验证一下，免得工具配置出错导致全部白标。

标注时的几个建议：

• 遮挡严重的对象可以适当框小一点，让模型专注于可辨识的部分。
• 类别不平衡要警惕：如果你有 20 个类别，但某个类别只有 20 个样本，那这个类别基本等于没训，需要补充数据或做数据增强。
• 每张图的标注时间控制在 1~2 分钟以内，批量处理时效率才高。

3.4 数据集目录结构与划分

YOLO26 训练要求数据集按固定目录结构组织。我一般这样建：

datasets/ └── person_detect/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ └── labels/ ├── train/ ├── val/ └── test/

其中 labels 下的 txt 文件和 images 下的图片文件名一一对应。注意两个关键点：

• 图片和标签的目录名一定要严格对应，否则训练时 0 张图片被读取的报错是常事。
• 用脚本按比例划分，推荐 train:val = 8:2 到 9:1 之间，测试集可以单独留出来不看，等最终评估再用。

划分脚本我习惯写成这样可以重复用的：

import os import random import shutil random.seed(42) data_dir = "datasets/person_detect" image_dir = os.path.join(data_dir, "images") label_dir = os.path.join(data_dir, "labels") all_images = [f for f in os.listdir(image_dir) if f.endswith((".jpg", ".jpeg", ".png"))] random.shuffle(all_images) train_ratio = 0.85 val_ratio = 0.15 train_count = int(len(all_images) * train_ratio) val_count = int(len(all_images) * val_ratio) train_images = all_images[:train_count] val_images = all_images[train_count:train_count + val_count] test_images = all_images[train_count + val_count:] def organize(image_list, split_name): os.makedirs(os.path.join(image_dir, split_name), exist_ok=True) os.makedirs(os.path.join(label_dir, split_name), exist_ok=True) for img_name in image_list: src_img = os.path.join(image_dir, img_name) dst_img = os.path.join(image_dir, split_name, img_name) shutil.move(src_img, dst_img) base_name = os.path.splitext(img_name)[0] src_label = os.path.join(label_dir, base_name + ".txt") dst_label = os.path.join(label_dir, split_name, base_name + ".txt") if os.path.exists(src_label): shutil.move(src_label, dst_label) else: print(f"Warning: label not found for {img_name}") organize(train_images, "train") organize(val_images, "val") organize(test_images, "test") print(f"Train: {len(train_images)}, Val: {len(val_images)}, Test: {len(test_images)}")

注意：一定先确认所有 txt 标签文件都存在再划分，否则某个图片没有对应标签文件，训练时会直接跳过它，数据量莫名其妙就少了，很多人没意识到这一点。

3.5 写 data.yaml：类别定义必须和标注一致

接下来需要写一个 data.yaml 文件，这个文件是给训练器看的，告诉它数据在哪、要预测哪些类别。

train: datasets/person_detect/images/train val: datasets/person_detect/images/val test: datasets/person_detect/images/test nc: 1 names: ['person']

如果从 COCO 数据集里筛选类别，nc 改为实际用到的类别数量，names 写上类别名称。需要特别注意索引对应关系：标注文件里的 class_id 0 对应 names 列表里的第一个类别，class_id 1 对应第二个，千万别搞反。这个错误极为常见，一旦错了模型训练时 loss 能降，但结果会一塌糊涂，因为类别标签被整体平移了。

4. 训练配置参数与调优实录

4.1 模型规格选型：n、s、m、l、x 到底怎么选

YOLO26 系列提供多种规格的模型，每个规格对应不同的网络深度和宽度参数。我的建议是：

• 只是想跑通流程、验证数据：直接用 n 规格，几分钟就能跑完一个 epoch，快速发现数据问题和配置错误。
• 实际项目落地、追求精度：用 s 或 m 规格。精度有提升，训练时间尚可接受。
• 离线推理、对速度不敏感：可以尝试 l、x，但要在显存和训练时间上做好准备。

先看这份规格对比情况：

我第一轮训练通常这样选：当数据量小于 1000 张、场景相对单一时，直接 s；数据量大、目标小、遮挡多，就 m。n 不是不能用，只是小目标检测时精度风险比较大。

4.2 训练命令的完整解析

在终端里运行训练命令时，关键参数要一个一个搞清楚，不能只是复制粘贴。

yolo detect train \ model=yolo26s.pt \ data=datasets/person_detect/data.yaml \ epochs=100 \ imgsz=640 \ batch=16 \ device=0 \ workers=4 \ patience=20 \ project=runs/train \ name=person_detect_exp1 \ pretrained=True \ cache=True

每个参数的意思我拆开讲一下：

• model：用预训练权重，能从 COCO 已学到的通用特征起步，收敛更快、效果更好。对自定义类别来说，即使 COCO 里没有你的类别，预训练权重仍然能提供底层纹理、边缘、形状等基础特征，属于典型迁移学习，能让训练效率大幅提升。

• epochs：训练轮数。100 轮是我做的实验基准值，如果 loss 还在明显下降，就继续加，用早停机制判断就行。

• imgsz：输入图片尺寸。640 是 YOLO 系列的标准值，显存充足时可以提高到 960 甚至 1280，对小目标检测有明显帮助。代价是训练时间和显存占用等比上涨。

• batch：批次大小，主要被显存上限卡住。显存不够时报错提示通常是 CUDA out of memory，这时优先把 batch 调小，比如从 16 调到 8 或 4，而不是直接换小模型。

• patience：早停耐心值，连续这么多轮验证集指标没有提升就自动停止。100 轮训练配合 patience=20 是个合理组合，能帮你省时间。

• pretrained=True：加载预训练权重，迁移学习的重要性前面已经说了。

• cache=True：把图片提前缓存到内存中，省去每轮读取磁盘的时间，首次运行会多花一点时间，但训练时会明显快不少。

4.3 训练过程中的指标怎么看

训练启动后，终端会实时打印指标，新手看到一堆数字容易懵。核心就看这几个：

• train/box_loss：边框回归损失，持续下降说明模型框的位置在学准。
• train/cls_loss：分类损失，持续下降说明类别判断在变好。
• metrics/mAP50(B)：IoU 阈值 0.5 时的平均精度。0.5 是比较宽松的判定，一般项目里 0.8 以上算可用。
• metrics/mAP50-95(B)：IoU 从 0.5 到 0.95 的平均精度，更严格，学术和竞赛里更看重这个。

判断训练是否正常的几个经验标准：

• 前 10 轮 loss 快速下降，这个阶段属于"从啥也不会到略懂皮毛"，是正常的，别慌。
• mAP50-95 持续上升，说明确实在学，只是速度不同，小数据集通常到 30~50 轮后增速放缓。
• 如果 loss 从第一轮开始就 NaN，那大概率是数据标注里有空框、坐标超界或者格式错误，优先检查数据集。

4.4 改进思路：数据增强与超参数调整

如果你的模型在 val 集上的 mAP 一直上不去，排除了数据问题后，优先尝试数据增强相关配置。YOLO26 内部集成了 mosaic、翻转、色彩抖动等增强策略，大部分情况下默认配置已经够用。但你完全可以通过修改增强参数来调整，比如针对小目标增多的场景，可以让 mosaic 保持开启，同时把 hsv_h、hsv_s 等颜色抖动参数适当调大，增强模型对光照变化的鲁棒性。

还有一类非常有用的技巧是超参数进化，直接跑：

yolo detect tune \ model=runs/train/person_detect_exp1/weights/best.pt \ data=datasets/person_detect/data.yaml \ epochs=30 \ iterations=50 \ batch=16

它会自动搜索一组更优的超参数组合。不过要注意，这个操作比较吃算力，如果你只是课程作业，先把基础训练跑通就够了；要是做正式项目，这个步骤值得跑一次。

5. 推理、模型导出与实际部署

5.1 训练完成后，怎么用模型做推理

训练结束后，runs/train/person_detect_exp1/weights/ 下会生成两个文件：

• best.pt：验证集上效果最好的权重，推荐优先使用。
• last.pt：最后一轮的权重，如果训练后期已经过拟合，它可能比 best 差。

推理的代码非常简单：

from ultralytics import YOLO model = YOLO("runs/train/person_detect_exp1/weights/best.pt") results = model.predict( source="test_images/", conf=0.4, iou=0.45, save=True, save_txt=True, save_conf=True, project="runs/detect", name="inference_test" )

几个参数的经验值：

• conf：置信度阈值，默认 0.25。调太高会漏检，调太低会误检。实际监控场景我一般设 0.4 左右，具体情况还得结合你的任务调整。
• iou：NMS 的 IoU 阈值，默认 0.45。两个框重叠度超过这个值就会被合并，调太高可能两个目标重叠时只保留一个，调太低会把同一个目标重复检出。

我在人员入侵检测项目里遇到的典型情况是：conf=0.3 时把远处的人形轮廓误检成行人，调到 0.5 之后误检明显减少。这个没有标准答案，只能对着具体画面多试几组。

5.2 从 .pt 导出 ONNX，为部署做准备

很多时候我们并不会直接用 .pt 做线上推理。.pt 需要 PyTorch 环境，对于线上服务或者边缘设备来说太笨重了，通常要导出为通用格式。ONNX 是当前兼容性最好的中间格式，可以转换到不同推理引擎。

yolo export model=runs/train/person_detect_exp1/weights/best.pt format=onnx opset=12 simplify=True

导完以后可以用 onnxruntime 验证一下输出是否正常：

import onnxruntime as ort import numpy as np from PIL import Image session = ort.InferenceSession("runs/train/person_detect_exp1/weights/best.onnx") input_name = session.get_inputs()[0].name img = Image.open("test_images/sample.jpg").resize((640, 640)) input_data = np.array(img).astype(np.float32) / 255.0 input_data = np.transpose(input_data, (2, 0, 1)) input_data = np.expand_dims(input_data, axis=0) outputs = session.run(None, {input_name: input_data}) print("Output shape:", outputs[0].shape)

这里要注意预处理细节：YOLO 系列的输入需要归一化到 0~1，且是 NCHW 排布，很多人在自己写推理脚本时忘了做这一步，导致检测结果全是乱的。

5.3 如果有人问你"树莓派上能不能跑"这类问题

树莓派 5 这类边缘设备部署 YOLO 模型，是完全可行的。我的建议是：如果只是验证概念，在树莓派上用 .pt 跑 CPU 推理，帧率大概只有 1~3 FPS，不太实用。如果要做实时检测，建议先用 ONNX Runtime 或 NCNN 做推理加速，并把模型规格降到 n 或者 s。

另外可以把模型做量化。n 规格模型量化后体积能缩小到原来的四分之一左右，推理速度也会改善。代价是精度有一定损失，但边缘设备上这是值得的取舍。

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

6.1 训练时报错 No labels found in train set

这个错误 90% 是数据集目录结构或者 txt 文件没配对导致的。按照我前面的目录结构检查一遍：

• 图片和 txt 标签文件是否在正确的 train/val 文件夹下；
• 文件名是否一一对应（不含扩展名相同）；
• data.yaml 中的路径是否写对，相对路径是相对于当前工作目录还是 yaml 所在目录，容易搞混；
• txt 文件是否是空文件，空标签文件会导致读取失败。

解决办法：我建议写一个小脚本扫描所有标签文件，统计每张图片对应的 txt 是否存在、是否为空，一次性找出所有问题，比肉眼一个个看快得多。

6.2 PyTorch 报 CUDA out of memory

显存不足是最常见的报错。处理顺序我一般这样做：

1. 把 batch size 从 16 降到 8 或 4；
2. 把 imgsz 从 640 降到 512（注意：这个操作会影响模型对小目标的检测能力，慎用）；
3. 换更小的模型规格，比如从 s 换成 n；
4. 实在不行就开 CPU 训练，虽然慢，但对纯验证数据管线来说足够用。

训练启动时加一句device=0是指定 GPU，不加的话代码自动选择，有可能踩坑使用了 CPU 而不自知，导致训练时间爆炸。启动时留意一下终端输出是在 CPU 还是 CUDA 上跑，顺便确认一下torch.cuda.is_available()的输出。

6.3 Loss 不降或者发散

遇到 loss 不降，先检查数据：

• 标注框是否准确，有无大量漏标；
• 类别是否极端不均衡，某类样本太少模型学不动；
• 是否有损坏图片混在数据集里。

比如有一张图片打不开、OpenCV 读取时只有黑图，训练的 loss 计算时可能产生异常。处理方式是写一个检查脚本，逐张用 OpenCV 读取所有训练图片并确认尺寸有效，出现读取失败的直接清理。

如果数据没问题，那就把学习率调低，默认的学习率在某些情况下偏高会导致 loss 震荡。用lr0=0.001这类更保守的设置再试一次。

6.4 模型泛化能力差，训练集表现很好但验证集很烂

典型的过拟合信号，数据量太少或者模型太大。解决办法是加数据增强、减少训练轮数、改用更小的模型规格。还可以通过收集更多场景多样化的数据，从根本上解决泛化问题。

一个小技巧：训练时用 patience 早停，别让它跑满 100 轮才结束。模型通常在 40~60 轮之间到达最佳验证指标，再往后容易过拟合，早停能帮你在最好的位置截住模型。

6.5 常被问到的：姿态模型版本有什么区别

关于 yolo26 姿态模型版本区别，简单来说是：姿态估计模型和检测模型是不同任务，检测模型输出框，姿态模型不仅要框，还要输出每个人体的关键点坐标。同一代框架里通常会有单独的 pose 权重，要用姿态模型就得单独下载，训练时也要用带关键点标注的数据集格式。如果你要做人员入侵检测，检测模型就够了；如果你需要判断人的动作，比如举手、跌倒，就需要姿态模型。

7. 避坑清单与个人经验总结

到目前为止，核心的训练流程已经完整跑通了。但我还是想梳理一份我个人的经验教训，供你一一对照，说不定你正在踩其中一个坑。

第一，项目开始前先确认任务类型，是检测、实例分割、姿态估计还是 OCR 文字定位，不同的任务对应的工具链和标注格式完全不同。硬套格式最常见，比如把分割数据当检测训练，那 loss 就是降不下去。

第二，标注质量再怎么强调都不为过。我见过很多同学花了大量时间收集了 5000 张图，标注时赶进度，框偏移了半个身位，最后训练出来的模型 mAP 始终在 0.6 徘徊。与其盲目堆量，不如把标注质量做好。每个框都要贴合目标边缘，这是模型学习的基础。

第三，对小目标多的场景，一个是提高训练输入尺寸，另一个是确保标注框没有忽略那些小目标。很多标注工具在缩放图片时看不清小物体，导致漏标，这一类漏标对小目标检测的打击往往是致命的。

第四，保留实验记录的习惯。训练时多写几个 name 参数，把每次实验的配置、数据集版本、结果指标记录下来。不要小看这一个习惯，实验对了不知道哪个参数起了作用、错了也无从排查，是项目开发中最浪费时间的事。

第五，在最后为了项目效果，一定要针对场景跑一遍推理测试。训练指标只是参考，最终画面里的表现才真正算数——你需要拿真实业务图片或者实时视频来验证，根据实际检测效果反推要不要补数据、调阈值、换模型，这个阶段不是可有可无的。

我在实际做项目时还有一个体会：第一次跑通模型后，先在验证集上挑出几类错误案例，失败的图片里往往藏着数据分布的秘密。比如大量误检集中在某个特定光照条件下，那说明这一场景在训练集里覆盖不足，解决办法不是调参，而是补这类的数据。这个"针对失败补数据再训练"的循环，才是目标检测项目效果持续提升的真正核心。

最后再分享一个小技巧：训练之前先跑一个只有 10 张图片的 mini 实验，只训练 2~3 轮，确认 loss 能正常下降、没有 NaN、数据读取没问题。这样你在大规模训练之前就知道整条链路是否正常。我后来所有项目都保持这个习惯，它可以帮你省下大量排错的时间。