又是一个停车管理系统。每年毕业季都有大量计算机相关专业的同学拿到这个题目但说实话我见过太多人把时间花在车牌识别上最后卡在深度学习模型里出不来反而把最核心的业务逻辑做得稀烂。这篇博文我打算换个思路聊不教你怎么从零训练车牌识别模型而是给你一套真正能跑通、能答辩、能交付的完整方案。我会把车位管理、车牌识别、自动计费、数据统计这四个模块怎么设计、怎么实现、怎么串起来讲清楚同时把部署说明、演示视频准备、设计说明书这些让你头疼的交付物也一并理顺。这篇文章适合没有深度学习基础、但又想把毕设做得像模像样的同学也适合第一次接触 PyQt MySQL 这类桌面管理系统的初学者。下面直接进入正题。1. 先想清楚再动手停车管理系统到底在管什么很多同学拿到题目第一反应是我要做一个车牌识别系统这个定位从根上就偏了。导师要的是一套停车管理系统车牌识别只是入口环节。你真正要交付的是一条完整的业务闭环车辆进来、分配车位、开始计时车辆出去、算钱、收钱、释放车位中间还有管理员看数据、看报表。这个闭环跑通了系统才算立住了。1.1 系统的四大核心模块与数据流我把这套系统拆成四个模块对应标题里的四个关键词车位管理车位状态空闲/占用、车位分配、车位占用数量统计。车牌识别车辆入场时识别车牌出场时识别车牌识别失败时能手动补录。自动计费根据入场时间和出场时间计算费用处理免费时段、首小时、24小时封顶等规则。数据统计按天/按月统计营收、车次、车辆时长、高峰时段用图表展示。数据流转是这样的车辆入场摄像头抓拍一帧画面交给车牌识别模块识别出车牌号后系统分配一个空闲车位在车辆记录表里插入一条入场记录状态为在场。车辆出场时再次识别车牌也可以输入车牌系统查到对应的入场记录调计费模块算出费用管理员确认收款后出场记录补全、车位释放、计费状态结束。所有的操作都落在数据库里统计模块再从库里聚合数据画图表。1.2 用状态机理解车辆记录的流转这一步是很多人容易忽略的重点。一条车辆记录不是一个填完就完事的静态数据它在系统里会有状态变化入场后status在场有入场时间没有出场时间和费用。出场结算中status待结算系统已根据入场时间算好费用。结算完成status已完成出场时间和费用都写进记录。这个状态流转决定了你在设计数据库时需要哪些字段、在界面上需要哪些按钮和逻辑判断。如果你把在场车辆和离场车辆分两张表存那做统计的时候反而要反复 union平白增加工作量。后续我会详细讲表设计这里先建立状态机的概念。1.3 系统做没做完拿这张清单自查我把这套系统的完整性列成一份验收清单你可以对照着自己检查车辆入场能不能生成记录、分配车位车位满了以后入场是否被拦截并给出提示出场时能不能通过车牌号找到入场记录计费能不能正确处理免费时段和超时收费完成后车位是否释放当天收入、车辆数、高峰时段能不能正确统计出来数据库里的记录是否保留了完整的历史数据而不是被删除覆盖运算符、异常输入比如输入了不存在的车牌能不能给出友好提示如果这份清单全部能打勾这个系统已经具备答辩的硬实力了。就算识别率不是100%也可以通过手动录入兜底这在业务上完全站得住脚。2. 技术选型的真实逻辑为什么车牌识别不自研深度学习模型做毕设最忌讳的就是给自己挖一个填不满的坑。车牌识别用现成开源方案绝不自己训模型这是我对所有做这个题目的学生说的第一句话。2.1 技术栈全览与选型理由先给出我这套方案的技术栈你可以直接按这个搭组件选型说明编程语言Python 3.8生态丰富写业务逻辑快界面开发PyQt5界面成熟控件齐全适合桌面管理系统数据库MySQL 5.7或 SQLite 兜底答辩直观表结构能说清楚车牌识别HyperLPR 开源库备用百度云 OCR本地识别免费离线可用图像处理OpenCVcv2配合识别库读取和预处理图片数据可视化pyecharts生成图表方便效果好看代码管理Git requirements.txt交付部署必备为什么选 PyQt5 而不是 TkinterTkinter 虽然更简单但是做表格、多标签页、嵌入图表这些功能要费很多功夫而且界面丑。PyQt5 有QTableWidget、QStackedWidget、QWebEngineView改改样式就很像商业系统。如果你完全没接触过 PyQt5也不用慌这几种控件的用法都比较固定照着例子改就行。2.2 车牌识别方案对比本地识别、云端识别还是自己训练我把常见的三条车牌识别路线放在一起对比你看完就知道为什么我只推荐前两种HyperLPR 本地识别免费、离线、识别普通蓝牌准确率还不错能识别车牌颜色和省份简称。缺点是对部分新能源绿牌、倾斜角度大的图片识别率一般不同版本 API 差异大。百度云车牌识别 OCR准确率极高免费额度对毕设演示够用接入也简单。缺点是必须联网演示现场网络一旦不稳定就翻车而且答辩老师可能会追问离线了怎么办。自己训练 YOLO CRNN技术含量高但是你要准备数据集、标注、训练、调参一套流程下来一个月就没了而且最终效果不一定有现成的 HyperLPR 好。这不是毕设项目应该承担的工作量。我的建议是主用 HyperLPR 本地识别提前准备一张手动录入的兜底通道。识别失败时直接弹窗让操作员手动输入车牌号这不仅为了演示稳妥也是真实停车场系统里非常常见的做法。2.3 环境准备中最容易翻车的三个坑环境配置是很多人卡在第一关的地方我直接把我踩过的坑列出来第一个坑依赖版本互相冲突。OpenCV、numpy、PyQt5 这三个库对版本比较敏感尤其 numpy 版本过高会导致一些老的识别库报np.float属性不存在的错误。建议新建一个虚拟环境统一安装固定版本不要用系统自带的 Python 环境。python -m venv parking_env parking_env\Scripts\activate # Windows pip install opencv-python4.6.0.66 pip install pyqt55.15.9 pip install pymysql pip install pyecharts第二个坑中文路径。识别库读取图片时如果图片路径包含中文比如D:\我的项目\测试图片\车牌1.jpgOpenCV 和 HyperLPR 经常无法读取。项目路径和测试图片路径一律用英文字母命名这是很多人忽略的坑。第三个坑识别库版本差异。HyperLPR 老版本hyperlpr_py3入口函数是pipline.SimpleRecognizePlate新版本则是HyperLPR类。不同版本的返回数据结构也不一样。不要指望照着网上某篇博客写的代码就能一次跑通拿到库之后先打印一下返回结果看清楚结构再处理。3. 数据库设计四张表把业务吃透数据库设计是答辩时老师必然会问的部分。这套系统的核心就是四张表车位表、车辆记录表、费率配置表、日统计表。设计得好不好直接决定你实现业务逻辑时是顺手还是别扭。3.1 车辆记录表入场和出场放在同一行用状态字段区分很多初学者喜欢把在场车辆和历史记录分成两张表这种做法我强烈不建议。原因很简单出场时要更新入场记录的出场时间和费用分两张表反而要额外维护关联关系。放在同一张表用status字段区分即可。建表 SQL 给你参考CREATE TABLE vehicle_records ( id INT AUTO_INCREMENT PRIMARY KEY, plate_number VARCHAR(20) NOT NULL COMMENT 车牌号, entry_time DATETIME NOT NULL COMMENT 入场时间, exit_time DATETIME NULL COMMENT 出场时间, space_id VARCHAR(10) NULL COMMENT 分配车位号, fee DECIMAL(8,2) DEFAULT 0.00 COMMENT 停车费用, status TINYINT DEFAULT 0 COMMENT 0在场 1已完成, entry_image VARCHAR(255) NULL COMMENT 入场抓拍图片路径, exit_image VARCHAR(255) NULL COMMENT 出场抓拍图片路径, INDEX idx_plate (plate_number), INDEX idx_status (status) );几个字段的设计意图说一下。plate_number加索引因为出场时最频繁的操作就是按车牌号查记录。entry_time和exit_time用 DATETIME 而不是字符串是为了方便计算时长和按时间范围聚合统计。entry_image和exit_image保存图片路径而非图片二进制内容避免数据库体积暴涨也方便在界面上回看抓拍照片。3.2 车位表和费率表把可变参数存进数据库而不是写死在代码里车位表用来管理车位状态CREATE TABLE parking_spaces ( space_id VARCHAR(10) PRIMARY KEY, area VARCHAR(20) DEFAULT A区 COMMENT 所在区域, status TINYINT DEFAULT 0 COMMENT 0空闲 1占用, current_plate VARCHAR(20) NULL COMMENT 当前占用车辆车牌 );你可以在界面上初始化生成 A01-A20 这些车位号。分配车位时从空闲车位里挑一个把status置为 1同时把current_plate记录下来出场结算完成后再把这行重置为空闲。费率表是很多人容易忽略的设计。如果把计费规则写死在代码里答辩时老师问怎么调整费率你只能尴尬地说改代码重启。而放到配置表里就变成管理员在界面上改参数立即生效CREATE TABLE fee_config ( config_key VARCHAR(30) PRIMARY KEY, config_value INT NOT NULL, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ); INSERT INTO fee_config (config_key, config_value) VALUES (free_minutes, 15), (first_hour_fee, 6), (extra_per_hour_fee, 3), (daily_cap, 50);这样设计的另一个好处是写计算费用的函数时只需从这张表取出配置规则和业务解耦逻辑更清晰。3.3 日统计表用定时任务或出场时实时汇总统计模块有两种实现路径实时聚合和定时预聚合。实时聚合就是在你查询报表时直接对vehicle_records做聚合计算数据量小的时候完全没问题定时预聚合是每天凌晨跑一个脚本把昨天的数据汇总到daily_statistics表查询起来更快但需要额外维护一个定时任务。对毕设来说我建议直接在查询时聚合不建统计表也能满足功能要求。但如果你想在答辩时多展示一个自动生成日报的功能点可以加上这张简单表CREATE TABLE daily_statistics ( stat_date DATE PRIMARY KEY, total_count INT NOT NULL COMMENT 当日车次, total_fee DECIMAL(10,2) NOT NULL COMMENT 当日营收, total_minutes INT NOT NULL COMMENT 总停车时长(分钟), avg_fee DECIMAL(8,2) NOT NULL COMMENT 单车平均费用 );每次出场结算完成时顺带UPDATE当日统计数据简单粗暴且有效也符合数据统计这个标题关键词。4. 车牌识别模块代码怎么写识别不准怎么办车牌识别是系统里看起来最吓人但实际上套路最固定的部分。我用的方案是HyperLPR 本地识别为主OpenCV 做预处理辅助手动录入作为最终兜底。三个环节配合好演示基本不会出大问题。4.1 本地 HyperLPR 的接入代码HyperLPR 不同版本 API 有差异我给出两种常见版本的写法你根据自己装的版本选择。装库直接用pip install hyperlpr不一定成功建议从 GitHub 拉代码本地安装依赖库会自动带上。老版本 hyperlpr_py3 的调用方式import cv2 from hyperlpr_py3 import pipline image cv2.imread(car.jpg) result pipline.SimpleRecognizePlate(image) # 返回结构通常是 (plates, angles, cards) # plates[0] 是识别出的车牌号plates[2] 是置信度 plate result[0][0] if result and result[0] else None新版本 HyperLPR 的调用方式类似只是入口变为类实例import cv2 from hyperlpr import HyperLPR detector HyperLPR() image cv2.imread(car.jpg) result detector.recognize(image) print(result) # 先打印出来确认返回结构再继续我不建议完全照着我的代码抄因为你从不同渠道拉到的版本可能不太一样。拿到库之后第一步永远是打印返回结果看清楚结构然后写一个统一的封装函数把不同版本的结果转换成plate_number和confidence两个标准字段。后面所有业务逻辑只认这个封装函数这样以后换识别模块改动也只集中在一个文件里。4.2 识别结果的后处理与置信度过滤识别结果不能直接拿来用要做两层处理过滤和清洗。过滤是识别置信度太低的直接不要避免把错误车牌写进数据库清洗是识别结果中可能带有空格、横杠、中文生僻字识别错误等需要用规则把车牌格式整理干净并校验合法性。import re def clean_plate(raw_plate): if not raw_plate: return None # 去掉空格和横杠 plate re.sub(r[\s\-], , raw_plate) # 常见省份汉字开头 字母数字组成的 6~8 位 if not re.match(r^[\u4e00-\u9fa5][A-Z0-9]{5,7}$, plate): return None return plate这个正则表达式看起来简单但能挡住很多垃圾识别结果。比如识别出一个¥或者乱码的O和0混淆问题正则校验能拦下一部分。4.3 演示不翻车的双重兜底机制识别率再高演示现场也极有可能翻车。很多时候是摄像头对着屏幕反光、角度倾斜识别结果就翻了。我的做法是加两道兜底而且这两道兜底完全不影响系统很高级的观感第一道兜底是多帧投票。入场时连续拍摄或者读取 3 帧画面分别识别取出现次数最多的结果。如果 3 次结果都不一样取置信度最高的。这个策略能有效减少偶发误识别代码也就几十行。第二道兜底是手动录入。识别失败或者置信度过低时界面上弹出一个输入框管理员人工输入车牌号同时保留入场抓拍的图片作为人工核验证据。这个流程本身就是真实停车场系统的标配操作答辩时你可以直接说系统支持识别异常时的人工干预这反而是一个亮点。另外建议开发期间用一个images/input文件夹存几张不同车牌的照片调试时直接用cv2.imread读取走和摄像头完全一致的识别流程。等核心逻辑稳定了再换成cv2.VideoCapture(0)读取摄像头画面。这样能有效减少调试时反复进出停车场的痛苦。5. 自动计费费率的边界条件才是答辩加分点计费模块看起来是简单的时长 × 单价但真正让代码变复杂的是那些边界条件不足一小时怎么算免费时段刚好卡在出场时间上怎么处理停了 3 天该怎么封顶这些边界条件处理得清晰与否恰恰是答辩时拉开分差的地方。5.1 计费规则设计把规则拆成可配置参数我使用的计费规则是很多商场停车场的典型方案你可以根据题目要求调整规则项值说明免费时长15 分钟免费时长内出场费用为 0首小时费用6 元超过免费时长后按首小时计费超时每小时3 元超过首小时后每多 1 小时加收 3 元不足 1 小时按 1 小时24 小时封顶50 元单日最高收费 50 元避免费用无限增长这些参数放在fee_config表里而不是写死在代码中。这样既能演示管理员可配置也让计费函数保持清晰。5.2 计费核心函数与边界测试直接上核心代码。这个函数把免费时段、首小时、按小时上取整、跨天封顶都处理好了import math from datetime import datetime def calc_fee(entry_time, exit_time, config): free_minutes config[free_minutes] first_hour_fee config[first_hour_fee] extra_per_hour_fee config[extra_per_hour_fee] daily_cap config[daily_cap] total_minutes int((exit_time - entry_time).total_seconds() // 60) if total_minutes free_minutes: return 0.0, total_minutes # 超过免费时长后参与计费的分钟数 billable_minutes total_minutes - free_minutes # 向上取整到小时 hours math.ceil(billable_minutes / 60) if hours 1: fee first_hour_fee else: fee first_hour_fee (hours - 1) * extra_per_hour_fee # 跨天处理如果时长达到 24 小时按封顶价叠加 if billable_minutes 24 * 60: days billable_minutes // (24 * 60) fee daily_cap * days remain_minutes billable_minutes % (24 * 60) if remain_minutes free_minutes: remain_hours math.ceil(remain_minutes / 60) fee first_hour_fee max(0, (remain_hours - 1)) * extra_per_hour_fee if fee daily_cap * (days 1): fee daily_cap * (days 1) return round(fee, 2), total_minutes这个函数有几个设计细节值得在答辩时展开说。一是选择按总分钟数取整而不是用小时浮点数避免了 1.5 小时乘以 3 元产生精度问题二是免费时长优先扣除也就是先把前 15 分钟拿出来剩余时间才进入计费三是跨天时按封顶价乘以天数再把不足一天的零头单独计算同时限制零头部分不超过单日封顶。我建议你写一小组测试用例把边界情况都过一遍停车 10 分钟费用应为 0。停车 20 分钟费用应为首小时费用 6 元因为已经超出免费时段。停车 1 小时 10 分钟费用应为 6 3 9 元。停车 24 小时费用应为封顶 50 元。停车 25 小时费用应为 50 6 56 元而不是 100 元。把这些测试结果在文档里列出来答辩时边界测试几个字一出口比空口说我实现了计费功能有说服力得多。5.3 支付流程的模拟实现二维码与状态流转Paypal、微信支付、支付宝支付这类真实支付接口毕设里不建议真的去申请接入。流程复杂不说个人很难通过审核。我采用的方案是模拟支付结算时生成一个二维码用qrcode库界面上显示扫码支付 XX 元旁边放一个确认已收款按钮。管理员点击确认后记录状态从待结算置为已完成。这个设计能展示出你对支付流程的理解订单生成、二维码展示、支付回调、状态更新。虽然支付动作是模拟的但流程是完整的。import qrcode img qrcode.make(fPAY|{record_id}|{fee}) img.save(pay_qr.png) # 在 PyQt5 中加载图片显示到 QLabel 即可注意模拟支付一定不能跳过一个按钮直接改状态否则会显得流程断裂。确认收款按钮点击后应同时更新记录状态、释放车位、更新统计数据形成闭环。6. 数据统计与可视化让管理看得见统计模块是整套系统的门面也是答辩展示时最能直观抓住老师眼球的部分。做好了整个项目的系统感直接上一个台阶。6.1 该统计哪些指标为什么我建议至少做这几类统计每类都能落到一个业务问题上营收统计今日营收、本月营收、单车平均费用。回答的是这个停车场赚了多少钱。车次统计今日入场车次、当前在场车辆数。回答的是停车场忙不忙。高峰时段分析按小时统计各时段入场车次画柱状图。回答的是哪些时段是高峰期管理人员该怎么排班。车位占用率任一时刻在场车辆数与总车位数的比值画折线图或曲线图。回答的是停车场资源是否够用需不需要扩建。统计 SQL 其实很简单核心就是按时间范围分组聚合。比如按小时统计一天内的车辆入场数SELECT HOUR(entry_time) AS hour, COUNT(*) AS cnt FROM vehicle_records WHERE DATE(entry_time) 2025-01-01 GROUP BY HOUR(entry_time) ORDER BY hour;6.2 pyecharts 生成图表并嵌入界面pyecharts 生成的图表是一个独立的 HTML 文件需要在 PyQt5 中用QWebEngineView加载它来展示。如果你不想引入浏览器控件也有个更轻量的方案直接用pyecharts生成 PNG 图片保存到本地再用QLabel加载图片展示。这个方案对演示来说完全够用还避免了QWebEngineView体积大、打包麻烦的问题。图表生成代码示例from pyecharts.charts import Bar from pyecharts import options as opts bar Bar() bar.add_xaxis([8-10, 10-12, 12-14, 14-16, 16-18, 18-20]) bar.add_yaxis(入场车次, [12, 25, 18, 16, 22, 30]) bar.set_global_opts(title_optsopts.TitleOpts(title高峰期入场车次分布)) bar.render(peak_hour_bar.html) # 生成 HTML 文件再加载在 PyQt5 里展示 HTML 的代码也非常简单from PyQt5.QtWebEngineWidgets import QWebEngineView browser QWebEngineView() browser.load(QUrl.fromLocalFile(peak_hour_bar.html)) layout.addWidget(browser)实测下来pyecharts 的图表确实比 matplotlib 好看很多配色和交互都接近商业报表答辩时很加分。需要注意 pyecharts 版本从 v1 之后 API 变化较大建议直接用最新稳定版网上很多旧博客的写法不兼容遇到报错优先查官方文档。6.3 日报月报导出与演示截图准备在统计页面做一个导出日报按钮把当天的统计结果生成一个 CSV 文件方便用 Excel 打开。这个功能代码量不大但答辩时能直接展示系统支持数据导出又是一个功能点。import csv with open(daily_report.csv, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerow([统计日期, 车次, 营收, 平均时长]) writer.writerow([2025-01-01, 98, 680.5, 95])编码一定要用utf-8-sig否则用 Excel 打开中文会乱码这个细节我当年踩过提醒你注意。演示前多截几张图表页面和表格页面的图放到设计说明书里文档立刻就充实了。这也是个一举两得的做法——界面截图既是系统功能的证明又是论文里的插图素材。7. 部署交付环境、打包、演示视频与文档说明书的准备顺序标题里提到的部署说明、演示视频是很多同学最后阶段最容易手忙脚乱的部分。其实这几个交付物之间有清晰的先后顺序按顺序来能少走不少弯路。7.1 环境一致性requirements.txt 与虚拟环境部署说明的核心是让其他人或者老师能复现你的运行环境。我建议在项目根目录放一个requirements.txt把依赖环境固定下来opencv-python4.6.0.66 PyQt55.15.9 PyMySQL1.0.2 pyecharts2.0.3 qrcode7.4.2生成这个文件很简单pip freeze requirements.txt注意一条经验pip freeze会把虚拟环境里所有包都列出来包括一些间接依赖。如果你不确定哪些是核心依赖可以手动整理只保留必要项。部署的时候别人拿到项目复制到新电脑执行pip install -r requirements.txt就能装好环境。7.2 PyInstaller 打包 exe 时的三个坑如果毕设要求交付可执行文件就需要用 PyInstaller 打包。打包 PyQt5 HyperLPR 的项目时有三个坑很容易卡住第一个坑识别库的模型文件丢失。HyperLPR 依赖的模型文件.pb 或 .h5 文件默认不会被 PyInstaller 识别到打包出来的 exe 运行时会提示找不到模型。需要在.spec文件里用datas参数把模型目录强制包含进去。第二个坑OpenCV 的动态库缺失。打包后提示找不到opencv_ffmpeg*.dll之类的文件解决办法是手动从site-packages/cv2目录把相关的 dll 复制到打包目录或者在 spec 文件里把 cv2 的数据文件一并打包。第三个坑界面图片和报表模板找不到。程序中用相对路径读取的图片、HTML 模板文件打包后工作目录会改变导致路径失效。我的建议是写一个统一的资源路径函数所有资源读取都通过这个函数来定位打包时再配合--add-data参数处理。打包命令大致如下具体参数根据你的项目结构调整pyinstaller main.py --noconsole --onefile --add-data hyperlpr_model;hyperlpr_model --add-data images;images7.3 演示视频怎么录才不翻车演示视频是毕设交付里技术含量不高但极其影响评价的环节。我见过太多人把演示视频录得断断续续、滤镜乱飞、功能没展示清楚就切走了。录演示视频我有一个固定的脚本顺序系统启动与登录展示系统能正常启动、管理员登录成功。入场流程先展示图片识别模式读取一张测试车牌的图片识别出车牌号、分配车位、入场成功。手动录入兜底故意放一张识别率很低的图片演示手动补录车牌号强调系统的健壮性。出场计费流程输入刚才入场的车牌展示计费明细时长、费用、计费规则说明确认收款、车位释放。统计报表切到统计页展示图表和数据。录制的关键要求是画面稳定、每步操作和界面反馈清晰、遇到识别失败不要慌顺势展示手动录入。你甚至可以针对演示视频提前写好一份操作台词把每个环节要说的话写下来录的时候照着读。这一步看起来笨实际上非常有效。7.4 设计说明书配合系统的写法建议设计说明书毕设中的LW不是把代码抄一遍而是要让阅读者理解你的设计思路。我的建议是文档结构和系统模块一一对应至少包含这些章节需求分析系统有哪些角色管理员/操作员有哪些业务场景入场、出场、统计用文字把流程描述清楚。系统设计总体架构图、模块划分、数据库 ER 图就是前面那四张表画清楚关系。核心功能详细设计每个模块的界面截图 核心代码片段 讲清楚实现原理。计费模块把边界测试用例放进去识别模块把多帧投票和兜底方案讲清楚。系统测试界面功能逐项测试的表格把异常输入、满车位入场、免费时段出场等测试用例和结果列出来。一个很实用的技巧设计说明书的每个功能模块先放界面截图再放一段核心代码再写两三段设计思路文字。这种图 代码 文字三段式结构老师看着轻松答辩时你也好讲。还有一个细节把你的验收清单第 1.3 节那份原样放进说明书测试章节里每一项打勾标上测试结果。这比大段描述系统稳定性好有说服力得多。写到最后我想起自己当年做类似项目时最深的体会是先把主干业务跑通再去碰那些看起来很高深的技术点。车牌识别再准如果计费算错了系统照样站不住脚。反过来只要业务流程闭环清晰、边界情况处理得当识别率差一点完全可以用兜底方案补上。你先照着这个思路把整体框架搭起来后面会发现真正花在调识别模型上的时间其实只占整个项目的一小部分而且这部分的收益也远没有你想的那么大。先把系统跑起来再谈优化这是我能给你的最实在的建议。