射击训练里报靶一直是个繁琐的活儿传统的人工报靶不仅效率低还存在主观误差尤其在高强度训练时教练和学员都容易疲劳分数登记也容易出错。我最近完成了一个“web人工智能开发在线靶机射击分数识别管理系统”把前端网页、后端服务和深度学习模型整个串成了一条流水线算是彻底解决了这个痛点。这套系统基于HTML、CSS、jQuery构建交互界面Python和Django负责业务逻辑与APIORM配合MySQL做数据持久化核心的弹孔识别和环数计算则交给PyTorch模型来干。整个项目做完我发现它非常适合那些想入门“WebAI”全栈开发的人参考也适合射击俱乐部、训练基地、体校等场景直接落地复用。这篇文章我会把整个系统的架构拆解、关键代码逻辑、模型训练细节、部署踩坑记录全部倒出来尽量做到你照着思路也能自己搭一套。1. 项目概述与核心需求拆解1.1 场景痛点与需求分析射击训练的日常流程里学员打完一轮靶纸需要回收、人工判读、登记成绩再录入电脑。遇到训练量大或者靶纸弹孔密集、靠边的情况人工判读很容易出现争议。这个项目设计的初衷就是把“靶纸拍照上传、AI自动识别弹孔、计算并录入环数”这条链路做成一个在线管理系统教练和学员通过浏览器就能操作识别结果自动入库成绩随时可查。需求拆解下来其实就三大块识别准确率模型要能准确找到弹孔位置并映射到对应环区输出环数结果。业务闭环上传图片、触发识别、返回结果、保存成绩、历史查询流程必须完整。易用性前端不用太重能上传图片、能看结果列表、能做简单的数据筛选就行部署要方便。1.2 技术选型思路这套技术栈是我反复权衡之后定下来的不是随手乱配。为什么是Django而不是Flask因为这个系统不只是识别一个接口就完事了它需要用户体系、成绩管理、权限控制这些“管理系统”功能。Django自带Admin后台、ORM、认证系统开发效率非常高尤其是ORM直接避免了我手写一堆SQL的麻烦而且换数据库也方便。为什么识别部分用PyTorchDjango侧主要还是做请求处理和业务编排模型推理这种重计算任务最好独立出去。PyTorch生态成熟训练好的模型可以导出成TorchScript或者直接用Python调用和Django服务通过Python进程内调用就行不需要额外起一个独立服务降低了部署复杂度。前端为什么选jQuery现在很多人一上来就React/Vue但这个项目的交互复杂度并不高主要就是上传图片、异步请求、渲染成绩列表。jQuery足够轻量后端返回JSON前端直接操作DOM渲染开发速度最快而且后续想让原生前端接手也容易。整个系统最核心的亮点在AI识别不在前端工程化没必要为了技术炫技增加复杂度。1.3 系统整体架构整套系统的请求链路是这样的浏览器页面 - 用户上传靶纸图片 - jQuery发起AJAX请求 - Django URL路由 - 视图函数接收图片 - 调用PyTorch模型推理 - 返回JSON结果 - 前端渲染成绩 - ORM写入MySQL数据库模型部分单独封装成一个推理模块和Django业务层解耦。这样模型想换成TensorRT加速、或者其他新模型只需要改推理模块的接口实现业务层完全不用动。数据表设计上用户表负责登录认证靶纸记录表存图片路径和识别状态成绩表存最终的环数和命中信息。三张表通过外键关联查询成绩时一个ORM查询就能把关联数据全部拿到。2. 前端页面设计与交互实现2.1 页面模块划分前端页面我规划了四块登录页、上传识别页、成绩列表页、管理后台页。每个页面独立HTML文件公共的头部导航和样式抽出来复用。考虑到使用场景主要是训练场的平板或笔记本访问页面布局参考了移动端适配思路按钮做大上传区域做醒目。登录页没什么特别的就是标准的用户名密码表单提交后服务端返回Token或Session ID前端记住状态跳转。上传识别页是核心页面要有一个大面积的拖拽/点击上传区域旁边展示识别结果卡片包括环数、命中数、弹孔分布概览。成绩列表页支持按日期、按射手、按成绩区间筛选用jQuery发AJAX请求刷新表格区域。管理后台页则是给管理员维护射手信息和查看系统日志用的。2.2 jQuery核心交互实现前端交互的骨架是AJAX异步上传。这里有个关键点直接通过FormData上传文件而不是把图片转Base64塞进JSON。因为靶纸图片通常是高清照片一张可能2-3MBBase64会增大体积三分之一上传和解析都慢。上传核心代码大概是这个样子$(#uploadBtn).on(click, function() { var fileInput document.getElementById(targetImage); if (fileInput.files.length 0) { alert(请先选择靶纸图片); return; } var formData new FormData(); formData.append(target_image, fileInput.files[0]); formData.append(shooter, $(#shooterName).val()); $.ajax({ url: /api/recognize/, type: POST, data: formData, processData: false, contentType: false, beforeSend: function() { $(#resultArea).html(div classloading识别中请稍候.../div); }, success: function(res) { if (res.code 0) { renderResult(res.data); } else { alert(识别失败: res.msg); } }, error: function() { alert(网络请求异常请重试); } }); });这段代码逻辑很清晰但有几个细节值得强调processData: false和contentType: false必须设置否则jQuery会把FormData强行转成查询字符串文件上传直接挂掉。beforeSend里加了识别中的占位提示让用户知道请求已经发出避免重复点击。好的交互体验不只是“能用”而是要让用户每一步都知道系统在干嘛。服务端返回格式我统一用{code: 0, msg: success, data: {...}}成功和失败都走这个结构前端判断逻辑就特别简单。2.3 前端细节优化与接口约定上传识别页还有一个历史记录区上传成功后最近五条识别结果会直接展示在页面下方不需要跳转。这个是直接用jQuery的DOM操作把新记录插到列表头部。前后端联调时最怕的就是接口字段对不上。我在设计阶段就定了一个接口约定文档所有字段名统一用蛇形命名法比如shooter_name、total_score、hit_countDTO的字段类型也提前约定好。前端拿到的数据一定是个扁平结构嵌套层级多了模板渲染就麻烦。这套约定在后面联调阶段省了不少事。另外一个前端体验的优化点是图片预加载。识别结果卡片里要展示弹孔标注图如果等AJAX返回了再加载大图会出现白屏。我做法是AJAX返回结果里带上小图缩略图的URL前端先渲染缩略图点击再加载原图。这样首屏速度体验会好很多。3. Django后端与ORM数据模型设计3.1 项目工程目录规划Django项目结构我建议按应用拆分不要所有功能堆在一个app里。这个项目拆成了三个appusers负责用户认证和射手管理records负责靶纸图片和成绩记录recognition负责识别接口的封装和视图处理。每个app的职责单一后面扩展功能时不容易改一处崩一片。工程目录大致是shot_score_system/ ├── manage.py ├── config/ # 项目配置 │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── users/ # 用户与射手管理 │ ├── models.py │ ├── views.py │ └── urls.py ├── records/ # 靶纸图片与成绩管理 │ ├── models.py │ ├── views.py │ └── urls.py └── recognition/ # AI识别接口 ├── views.py ├── recognizer.py # 模型推理封装 └── urls.py3.2 ORM模型设计重点数据库设计是这个管理系统的地基。我的核心数据表是这三张射手表记录射手姓名、编号、所属单位或队伍。字段包括id、name、player_no、team_name、created_at。靶纸记录表记录每次上传的靶纸图片原始路径、识别状态。字段包括id、shooter外键、image_path、uploaded_at、status。这里status字段有讲究我设计了pending、processing、done、failed四种状态方便排查问题。如果识别接口异常但图片已经上传了状态可以标记为failed前端能看到上传了但没识别成功就不会误以为成绩丢了。成绩表记录识别出的总环数、命中弹数、详细弹孔坐标。字段包括id、record外键、total_score、hit_count、bullet_pointsJSON格式存储弹孔坐标和环数明细、created_at。模型定义有一个关键点bullet_points用JSONField存详细弹孔信息。这样查询总成绩很快需要看弹孔分布时直接解析JSON不需要额外建一张弹孔表。如果后面要做弹孔分布热力图这些坐标数据也能直接用。ORM查询方面我给Month级联查询加了一个select_related优化。成绩列表页需要展示射手姓名如果直接用外键关联查询每一条记录都会触发一次数据库查询列表一长性能就崩了。用select_related(shooter)可以把JOIN操作提前合并成一次查询性能提升非常明显。3.3 识别接口的完整实现识别接口是后端和模型衔接的桥梁。Django视图收到上传的图片文件先保存到本地再调用识别模块处理。这里需要注意一个细节图片文件保存前一定要做格式校验不只是看扩展名还要用PIL验证是不是合法图片否则有人上传一个改成.jpg的恶意文件模型加载时直接崩溃。接口视图的核心逻辑import json import uuid from django.views.decorators.csrf import csrf_exempt from django.http import JsonResponse from .recognizer import TargetRecognizer recognizer TargetRecognizer() csrf_exempt def recognize_api(request): if request.method ! POST: return JsonResponse({code: 1, msg: 仅支持POST请求}) image_file request.FILES.get(target_image) shooter_name request.POST.get(shooter_name, 未知射手) if not image_file: return JsonResponse({code: 1, msg: 缺少靶纸图片}) # 校验图片格式 ext image_file.name.split(.)[-1].lower() if ext not in [jpg, jpeg, png, bmp]: return JsonResponse({code: 1, msg: 不支持的图片格式}) # 保存图片到本地 filename f{uuid.uuid4().hex}.{ext} save_path fmedia/targets/{filename} with open(save_path, wb) as f: for chunk in image_file.chunks(): f.write(chunk) # 调用模型识别 try: result recognizer.predict(save_path) total_score result[total_score] hit_count result[hit_count] bullet_points json.dumps(result[bullet_points]) # 写入数据库代码略 return JsonResponse({ code: 0, data: { total_score: total_score, hit_count: hit_count, bullet_points: bullet_points, image_url: f/media/targets/{filename} } }) except Exception as e: return JsonResponse({code: 1, msg: f识别过程异常: {str(e)}})CSRF豁免这里要单独说明。因为前端是jQuery发AJAX没有Django模板渲染的CSRF Token机制POST接口如果开着CSRF校验AJAX请求会被403拒绝。我在开发阶段直接用了csrf_exempt但如果是正式的互联网环境建议用Django的ensure_csrf_cookie配合前端读取Cookie再带上Token安全性会更好。训练场的内网环境通常问题不大但你要知道这个取舍存在。3.4 管理后台集成Django的Admin后台是整个管理系统的隐藏福利。我把三个app的模型都注册到Admin管理员登录/admin/路径后可以直接浏览所有射手、靶纸记录和成绩。这个能力几乎零成本Django自带。注册代码也很简单from django.contrib import admin from .models import Shooter, TargetRecord, ScoreRecord admin.register(Shooter) class ShooterAdmin(admin.ModelAdmin): list_display (id, name, player_no, team_name, created_at) search_fields (name, player_no) admin.register(TargetRecord) class TargetRecordAdmin(admin.ModelAdmin): list_display (id, shooter, status, uploaded_at) list_filter (status,) admin.register(ScoreRecord) class ScoreRecordAdmin(admin.ModelAdmin): list_display (id, record, total_score, hit_count, created_at)你可能会觉得管理后台以后不一定用得上但开发调试阶段用Admin看数据比写SQL查询方便太多了。而且上线后如果客户需要手动修正某条异常成绩Admin后台就是一条后路。4. PyTorch射击靶纸识别模型实现4.1 识别任务拆解靶纸识别这个需求本质上是一个目标检测加回归的任务。模型要做的有两件事第一在一张靶纸图片上定位所有弹孔第二根据弹孔中心位置计算其所在环区汇总成总环数。这个任务如果直接用现成的目标检测框架比如Faster R-CNN或YOLO系列能跑通但有点杀鸡用牛刀。靶纸有一个非常强的结构特征——所有环区都是固定的同心圆。这意味着弹孔的环数判定完全可以简化为一个几何计算问题只要能找到靶纸的圆心和环半径再拿到弹孔坐标套一个距离公式就能算出环数。所以我把模型任务拆成了两步弹孔检测用目标检测模型定位弹孔中心点。弹孔通常颜色较深边缘可能带纸纤维破损的不规则形状但目标较小正负样本差异大。环数计算检测到靶纸的圆心和环半径后用几何方法映射弹孔位置到环数。这样做的好处是把复杂问题简化了。目标检测模型只需要输出若干弹孔坐标不需要直接回归环数大大降低了模型学习难度。4.2 数据集准备与标注策略数据是AI项目的命根子。我这次用的训练数据一部分是自己拍的真实靶纸一部分是通过程序合成的方式生成的仿真靶纸。真实靶纸的收集非常费劲。我联系了某个射击训练队他们提供了过去三个月训练积攒的靶纸照片大约有1000张左右。这些照片拍摄角度各异光照有强有弱靶纸有脏污有褶皱对模型鲁棒性非常有帮助。合成数据的逻辑也不复杂。我写了一个脚本在电脑上生成模拟靶纸的背景带环线的靶纸图然后随机在环区范围内生成弹孔弹孔形态做了随机扰动包括大小、深浅、边缘破损形态。合成数据产生了两万多张。真实数据加合成数据混合训练效果比只用其中一种好很多。标注工具用的是开源的图像标注工具类目就一个bullet_hole。标注格式转成了COCO格式方便用PyTorch的数据加载器直接读取。4.3 模型选型与训练细节目标检测模型选的是YOLOv5说实话不是因为它效果最顶尖而是因为它工程化成熟、部署方便、推理速度快。靶纸弹孔是小目标YOLOv5在中小目标检测上的表现在这套场景里足够用。训练细节有几个关键点输入尺寸我把输入图片统一resize到640x640。靶纸图片原始尺寸普遍在2000x3000左右直接原图输入显存不够resize后弹孔会变小所以推理阶段我会做一个缩放处理在小图上先检测大概位置再映射回原图坐标。迁移学习用COCO预训练权重做初始化。弹孔和COCO里的物体类别完全不重合但底层特征边缘、纹理、颜色对比是通用的。迁移学习让模型收敛速度快了很多大概训练了80个epoch就稳定了。数据增强训练时加了随机旋转、亮度扰动、噪声、模糊。这里有一个反直觉的经验——不要加随机裁剪因为裁剪会改变靶纸圆心和弹孔的相对位置关系模型学到的是局部特征而非完整靶纸结构。损失函数与评估指标检测头用的还是YOLO标准的CIoU和分类损失。评估指标我主要看两个单张靶纸的检测召回率弹孔有没有被漏检和环数判定的准确率。漏检比误检更严重漏检一个弹孔总环数就少一大块。4.4 推理模块封装PyTorch模型训练完后我把它包装成一个独立的TargetRecognizer类给后端视图调用。这个类的核心逻辑包括加载模型权重、预处理输入图片、后处理检测结果、计算总环数。import torch import cv2 import numpy as np class TargetRecognizer: def __init__(self, weights_pathbest.pt, devicecpu): self.model torch.hub.load(ultralytics/yolov5, custom, pathweights_path, force_reloadFalse) self.model.eval() if device cuda and torch.cuda.is_available(): self.model.cuda() def predict(self, image_path): # 读取原图获取宽高 img cv2.imread(image_path) h, w img.shape[:2] # 推理得到检测结果 results self.model(image_path, size640) detections results.pandas().xyxy[0] # 过滤掉低置信度目标 detections detections[detections[confidence] 0.3] bullet_points [] hit_count len(detections) for _, row in detections.iterrows(): x1, y1, x2, y2 row[[xmin, ymin, xmax, ymax]] center_x (x1 x2) / 2 center_y (y1 y2) / 2 bullet_points.append({ x: center_x, y: center_y, confidence: row[confidence] }) total_score self.compute_score(bullet_points, w, h) return { hit_count: hit_count, total_score: total_score, bullet_points: bullet_points }compute_score这步是纯几何计算。首先检测靶纸最外圈的紫色大圆或者某个基准环的半径然后按环数差划分等距环带。比如10环在最中心半径最小1环在最外圈。弹孔中心和靶心的距离除以环带宽度取整就能得到环数。这里有个细节必须注意弹孔恰好卡在环线上时怎么判练习规则里通常有“压线算高环”或“算低环”的说法具体取决于比赛规则。我的实现里做了边界偏移距离环线±2个像素内的弹孔按高环记。这样更符合射击训练的惯例也避免了人为争议。但不同客户可能有不同规则所以我把这个偏移量做成可配置参数部署时可以调整。4.5 推理性能优化训练场实际使用场景中教练上传一张图片后总希望尽快出结果最好三秒以内。如果纯CPU推理一张高清靶纸图片可能要5-8秒体验不太好。我的优化方案是先用小尺寸推理定位弹孔再用原图对应区域做二次确认。但后来发现YOLOv5在小尺寸上弹孔小目标丢失率偏高调了一阵参数效果还是不理想。最终用的方案是接收图片后先压缩到短边1600像素然后推理尺寸提高到960。虽然推理时间会多几百毫秒但整体控制在2-3秒准确率也保住了。如果服务器有NVIDIA显卡可以在Django启动时把模型加载到GPU并用torch.no_grad()包住推理代码。GPU推理大概能把时间压到200-400毫秒体验就非常流畅了。5. 系统联调与部署实践5.1 本地联调环境搭建整个系统在本地开发时我建议用虚拟环境隔离依赖。Python版本用3.10Django用4.xPyTorch用2.0稳定版。数据库方面本地开发用的MySQL因为和最终部署环境保持一致避免开发完上线后出现兼容性问题。本地起服务的方式很简单# 创建虚拟环境并安装依赖 python -m venv venv source venv/bin/activate pip install django mysqlclient torch torchvision opencv-python pillow # 数据库迁移 python manage.py makemigrations python manage.py migrate # 创建管理员账号 python manage.py createsuperuser # 启动开发服务器 python manage.py runserver 0.0.0.0:8000这里有一个容易踩的坑mysqlclient这个库在Linux上是正常安装但在Windows上经常编译报错。如果遇到这个问题可以换成pymysql然后在项目的__init__.py里加上import pymysql; pymysql.install_as_MySQLdb()效果等价。5.2 生产部署架构本地开发用的是Django自带的开发服务器性能不行生产环境必须换。我推荐用Gunicorn作为WSGI服务器Nginx做反向代理和静态文件服务。Nginx配置里需要注意把/media/路径指到靶纸图片目录同时设置上传文件大小限制。靶纸图片一般不会超过10MB我设置client_max_body_size 20m留点余量。Gunicorn的进程数设置我建议用(2 x CPU核数) 1这个经验公式。比如4核的服务器就开9个worker。每个worker进程会加载一份PyTorch模型如果开太多worker内存会被模型占满。我在部署时发现一个worker吃掉的常驻内存在500MB到1GB之间8G内存的服务器开4个worker是比较安全的配置。5.3 并发调用与排队策略训练高峰时段可能同时有好几个人上传靶纸图片。如果完全并发跑模型推理GPU或CPU会直接被跑满响应时间飙升。我的做法是加一个简单的排队机制。Django视图收到识别请求后先把图片保存好然后把识别任务丢进一个队列。用一个后台线程池固定跑2-3个识别任务识别完成后更新数据库记录状态。前端AJAX提交后进入“等待识别”的轮询流程每隔1秒查询一次识别状态。不过这个方案在单机部署下已经够用但如果识别任务量特别大建议引入消息队列和独立推理服务这就是更重型的架构了。对于射击训练这种中低并发场景线程池排队完全够。6. 常见问题与排查技巧实录6.1 模型识别不准弹孔漏检和误检漏检常见的原因是弹孔颜色和靶纸底色接近或者弹孔被靶纸褶皱遮挡。我调了几轮后发现靠调阈值只能解决一部分问题最有效的手段是数据增强里面加亮度和对比度的极端扰动让模型见多识广。误检则经常出现在靶纸的印刷标记、污渍、折痕上。这些干扰项和弹孔确实长得像。我的排查思路分两步第一步看误检目标的置信度如果集中在0.3-0.5之间说明模型判定犹豫可以提高置信度阈值第二步是看误检位置是否集中在固定的几个环区如果集中在10环附近很有可能是靶纸中心印刷图案被当成了弹孔需要在后处理里加一个圆心排除区域。6.2 并发上传时接口超时我在压测时发现当并发上来后图片上传接口偶尔会超时。排查后发现原因是模型推理本身耗时较长Django的worker全被识别任务占满了新的HTTP请求进不来。这个问题的解法就是前面说的排队策略识别任务不在视图函数里同步执行而是放队列。上传接口和识别状态查询接口分离前端轮询状态这样即使模型推理再慢HTTP接口都能快速响应。6.3 MySQL连接被断开Gunicorn的多worker模式下每个worker持有数据库连接池长时间运行后MySQL服务端会主动断开空闲连接。一旦连接断开ORM查询就会报OperationalError: (2006, MySQL server has gone away)。我采用的方案是给Django的数据库配置加上CONN_MAX_AGE和CONN_HEALTH_CHECKS选项DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: shot_score, USER: root, PASSWORD: ***, HOST: 127.0.0.1, PORT: 3306, CONN_MAX_AGE: 60, CONN_HEALTH_CHECKS: True, } }CONN_MAX_AGE设为60秒说明连接最长复用60秒超过后自动重建。CONN_HEALTH_CHECKS会让Django在执行查询前先请求MySQL服务器检查连接是否存活。这两个参数配上后这个报错就再也没出现过。6.4 部署时为静态文件踩的坑Django生产环境默认不会主动处理静态文件我一开始部署完后页面样式全丢了。排查才发现是忘记执行collectstatic了。正确做法是先执行python manage.py collectstatic把所有分散的静态文件收集到一个统一目录然后在Nginx配置里把这个目录alias到/static/路径下。Media文件同理Nginx要单独配一个location指向靶纸图片目录。6.5 避坑速查表问题现象可能原因解决方案前端AJAX上传失败没设processData: false检查FormData提交参数模型推理报错图片不是合法图像格式视图层增加PIL格式校验成绩列表页加载慢外键JOIN触发N1查询加select_relatedMySQL连接断开Gunicorn持连接过久设置CONN_MAX_AGE部署后样式丢失未执行collectstatic执行静态文件收集命令靶纸弹孔漏检光照变化太多增强训练数据多样性7. 项目价值与扩展方向这套系统做好了直接带来的收益是很明显的。以前几十张靶纸人工判读要花将近一个小时现在上传图片批量识别几分钟全部搞定而且数字化的成绩记录直接进数据库数据分析也有依据了。后续可以扩展的方向我觉得有两个很有价值。第一个是训练趋势分析系统积累了海量射手成绩后可以分析射击准度的波动趋势辅助教练调整训练计划。第二个是实时弹道可视化把弹孔坐标绘制成热力图直观反映射手的弹着点分布偏好——是普遍偏左下还是偏右上。这个功能技术上只需要把bullet_points的坐标数据用前端图表库渲染Django接口侧几乎不需要改。还有一个思路是把识别模型从YOLOv5升级到更轻量的模型比如通过模型剪枝或蒸馏压到能在边缘设备上运行。这样整套系统甚至可以部署在一个便携平板上训练场不需要专门的服务器。识别速度如果能做到300毫秒以内配合平板的摄像头现场拍照、现场出分体验就完全是另一档了。我在实际项目推进中最大的体会是Web系统加AI模型真正的难点往往不在某一个独立环节而在于各个模块的衔接。前端要理解上传接口的约束后端要理解推理模块的性能边界模型训练要理解真实场景中的数据分布。这整个链路想顺滑地跑起来每一个环节都不能掉链子。如果你也准备做类似的全栈AI项目建议在动手之前先花时间把接口格式、数据流方向和性能预算定清楚后面能少走非常多弯路。
