企业官网建设流程全解析

每年三四月份，找我咨询毕业设计的同学突然变多，问得最密集的题目就是Django+LLM大模型+滴滴出行分析方向的出租车供需平衡优化系统。这个名字虽然长，拆开其实就是三件事：用Django搭一套完整的Web后台，用大数据分析处理订单和车辆数据，再用大模型接口让系统具备智能问答和分析报告能力。很多人一听说"滴滴出行分析"，第一反应是以为要碰真实用户隐私和商业数据，其实毕业设计真正要做的，是拿脱敏公开数据或模拟数据走通一条完整链路。

这个系统解决的是打车场景里非常典型的供需错配问题：早晚高峰某些区域大量乘客叫不到车，同时另一些区域车辆空驶空转。系统通过历史订单数据预测未来一小时的热点区域和车辆缺口，给出调度建议，再用大模型把统计结果翻译成自然语言汇报。适合的人群大概有三类：正在纠结毕设选题的计算机应届生，想做数据分析方向又想蹭一点大模型热度的同学，以及需要快速搭建一个可用于答辩demo的开发者。下面我按自己做项目时的思路，把从选题到交付的全过程拆开讲一遍。

1. 先想清楚这个项目到底在做什么：选题逻辑与功能拆解

1.1 为什么"供需平衡优化"是毕业设计里的高性价比选题

在出行场景里，早晚高峰、节假日、恶劣天气下"打车难"几乎是必然现象。本质上是供需在时间和空间上匹配错位：乘客在商圈、车站、机场把手机举了半天叫不到车，而两三公里外的区域却停着一排等待派单的空车。用数据科学的话说，这是典型的供需失衡，也是出行平台最想优化的核心问题之一。

毕业设计选这个方向，天然就有几个好处。第一，业务场景足够真实，评委老师一听就懂，不需要你花五分钟解释"我做了个什么系统"。第二，有明确的量化指标，比如订单应答率、平均等待时长、区域供需比，这些都能直接用图表展示。第三，可以往上面叠技术层级：底层是Django的数据管理，中层是机器学习模型做预测，顶层是LLM做智能化交互，每个技术点都有落点，不会让人觉得是硬凑关键词。

从我实际辅导经验看，这个题的完成度上限很高，但下限也不低。有人用纯统计方法加规则引擎就能做出一个效果不错的系统，有人硬套神经网络最后连数据都跑不动。我的建议是，把重心放在"能不能形成闭环"上：有数据、有分析、有预测、有优化建议、有可视化展示，五步走通，这个题就立住了。

1.2 三层技术栈：Django、大数据分析、LLM各负责什么

我习惯把这类项目理解成三层结构。

第一层是Web应用层，用Django来做。为什么选Django？因为它自带ORM、Admin后台、用户认证和表单处理，开发效率极高。毕设不同于工业级项目，核心诉求是快速交付、稳定演示、方便二次开发，Django恰好全部满足。项目大了也不会乱，App模块可以按业务拆，比如订单分析、预测、调度、LLM问答各放一个应用。

第二层是数据层，也是"大数据"这个关键词真正落地的地方。这里要澄清一个误区：毕业设计里的大数据，不一定要上Hadoop/Spark集群。更接地气的做法是，用pandas处理几百万条订单数据，做分块读取、预聚合、特征提取，最后把统计结果落到数据库里。如果你的数据规模真的上千万条，再引入Spark离线计算也不迟，否则毕设期间维护一个集群就是给自己挖坑。

第三层是智能化层，也就是LLM大模型。LLM在这个系统里不是用来做预测的，而是用来"沟通"的。它能干的事情包括：根据当天统计指标生成交通分析日报、回答"XX商圈现在好不好打车"这类自然语言问题、把调度建议解释成人话。LLM的引入能让系统看起来"活"了，而不是一堆冷冰冰的图表。

三层各司其职，演示的时候逻辑非常清晰：Django管界面和流程，数据层管分析和预测，LLM管智能表达。

1.3 系统功能清单：从演示视角倒推出要做什么

我每次带项目都会先让同学写一份"演示脚本"，从答辩场景倒推系统该有哪些功能。按照这个思路，这套系统至少有六个模块不能少。

第一个是数据概览大屏，打开首页就能看到总订单量、总营收、订单完成率、当前空闲车辆数等核心指标。第二个是区域热力图，在地图上展示各区域订单热度，帮用户直观看出哪里在"爆单"。第三个是供需预测模块，选择某个区域和时间段，系统给出未来一小时需求量和供给量的曲线。第四个是调度任务管理，系统自动生成调度建议，调度员可以查看、确认并下发任务。第五个是LLM智能问答，有一个类似聊天窗口的界面，用户可以输入"今晚十点高铁站附近需要调度多少辆车"这类问题。第六个是管理后台，维护司机、车辆、区域信息，以及查看操作日志。

以上六个模块构成了完整的业务闭环。一个模块对应一个技术亮点，写论文的时候每个模块都可以作为一章展开，页数和内容量都不用愁。反过来，如果只做单个功能，比如只做一个预测模型，那论文会很单薄，答辩也容易冷场。

2. 数据链路怎么搭：从原始订单到可用于预测的特征

2.1 数据来源与模型设计：别一上来就盲写模型

数据是整套系统的地基，也是最容易让项目翻车的环节。我自己见过太多项目死在数据集上，想法很好，结果数据一跑全是空值，当场心态就崩了。

毕设选题里出现的"滴滴出行分析"，一般建议使用公开的脱敏订单数据集，或者是按真实数据分布伪造的模拟数据。网上有不少开放的网约车订单数据，常用的字段包括订单ID、上车时间、下车时间、上车点经纬度、下车点经纬度、订单状态、车费金额。如果你的学校对数据来源有要求，就明确在论文里写清楚数据已经脱敏，用于学术研究。实在找不到合适数据，也可以自己写脚本生成模拟数据，只要保留真实场景的分布规律即可。

对应的Django模型设计，我建议至少建三张表：

from django.db import models class Region(models.Model): name = models.CharField(max_length=50, unique=True) geohash_prefix = models.CharField(max_length=10, db_index=True) center_lng = models.FloatField() center_lat = models.FloatField() class Order(models.Model): order_id = models.CharField(max_length=64, unique=True) region = models.ForeignKey(Region, on_delete=models.SET_NULL, null=True) start_time = models.DateTimeField(db_index=True) end_time = models.DateTimeField(null=True, blank=True) status = models.CharField(max_length=20, db_index=True) fare = models.FloatField(null=True, blank=True) class Car(models.Model): plate_no = models.CharField(max_length=16, unique=True) region = models.ForeignKey(Region, on_delete=models.SET_NULL, null=True) status = models.CharField(max_length=20, default="idle") updated_at = models.DateTimeField(auto_now=True)

订单表存出行记录，车辆表存车辆实时状态，区域表存网格信息。三张表的关系很清晰，后续做聚合统计、预测特征都能直接取数。别为了炫技把表设计得特别复杂，没有意义。

2.2 清洗、网格化与特征工程：预测准不准一半看这里

原始数据直接用来训练模型会出问题，必须经过清洗和特征工程。很多人以为这一步是浪费时间，实际上预测准不准，一半看特征，一半看算法。

清洗阶段主要处理四类问题。一是缺失值，比如订单没有下车时间，可以根据时长分布做插值，或者直接标记为异常样本。二是重复数据，同一笔订单出现两条记录，要按订单ID去重。三是异常经纬度，坐标超出城市范围的就应该剔除。四是时间字段的时区问题，数据库存储统一用UTC，展示时再转本地时间，避免模型训练时出现时间偏移。

网格化处理是城市数据分析里很实用的一招。经纬度是连续值，直接建模没法体现城市区域结构。比较简单的做法是使用Geohash编码，将经纬度转成字符串前缀，比如6位Geohash对应大约一公里见方的网格，8位对应一百多米的网格。毕设一般用6位就够了，既能体现空间信息，又不会生成太多空区域。

特征工程阶段，我常用的一套组合如下表所示：

滑动窗口是时序预测里很关键的一招。比如要预测未来一小时某个区域的需求量，就把过去1小时、过去3小时、过去24小时同时间段的数据都作为特征，相当于让模型学到短时波动和长期周期性。

2.3 数据量大怎么办：预聚合、分块处理与定时任务

大数据的"大"字，在毕设里主要体现在处理方式，而不是集群规模。数据量在百万量级时，最简单的做法是分块读取。

import pandas as pd chunk_size = 100000 for chunk in pd.read_csv("orders.csv", chunksize=chunk_size): # 清洗逻辑 chunk = chunk.dropna(subset=["start_time"]) # 分块入库 records = chunk.to_dict("records") Order.objects.bulk_create( [Order(**{k: v for k, v in r.items() if k in fields}) for r in records], batch_size=5000 )

用pandas的chunksize参数分块读，然后用Django ORM的bulk_create批量入库，比逐条插入快几十倍不止。如果数据量太大导致MySQL写不进去，还可以先在本地用pandas做预聚合，只把每小时、每区域的统计指标入库，原始明细存CSV备份。

预聚合是精髓。比如"区域订单量统计表"，不需要保存每一笔订单，只要每小时跑一次任务，统计各区订单量、应答率、空闲车辆数，存到一张简单的统计表里即可。查询大屏数据时，直接查统计表，秒开。

定时任务可以用Celery加Redis，也可以用更轻量的APScheduler。毕设演示求稳，我更喜欢APScheduler，不依赖额外消息队列，一个进程就能跑起来。

3. 供需预测与调度优化：核心算法不写复杂也能出彩

3.1 供需指标拆解：先定义"失衡"，再谈"优化"

优化这个词听起来抽象，落到系统里就是几个公式。我常用的核心指标有三个。

第一个是区域供需比，公式是空闲车辆数除以订单需求量。比值小于1说明供不应求，大于1说明运力过剩。第二个是订单应答率，计算方式是成功接单的订单数除以总下单数。应答率越低，乘客体验越差。第三个是平均等待时长，统计从下单到司机接单的时间间隔。

实际项目里可以设置阈值：供需比低于0.8判定为"运力不足"，高于1.5判定为"运力过剩"。这样系统就能自动标记出问题区域，不需要人工盯数据看。答辩的时候评委问你"你凭什么说这个区域缺车"，你把这段规则讲清楚就行，很有说服力。

3.2 需求与供给预测：时间序列的三大常见错误

预测模块是这个系统里技术含量最高的部分。我不建议一上来就上LSTM或者Transformer，毕设的时间和技术积累有限，LightGBM、XGBoost这类梯度提升树模型在表格数据上往往比深度学习模型效果更好，也更容易调参。

训练一个需求预测模型，核心流程不复杂：

import pandas as pd from xgboost import XGBRegressor from sklearn.metrics import mean_absolute_error df = pd.read_csv("train_features.csv") df = df.sort_values("start_time") # 按时间排序，不能乱序 features = ["hour", "weekday", "is_holiday", "region_id", "last_1h_order", "last_1h_empty_car", "avg_wait_time"] X = df[features] y = df["future_1h_order"] split_idx = int(len(df) * 0.8) X_train, X_test = X.iloc[:split_idx], X.iloc[split_idx:] y_train, y_test = y.iloc[:split_idx], y.iloc[split_idx:] model = XGBRegressor(n_estimators=300, learning_rate=0.05, max_depth=6) model.fit(X_train, y_train) y_pred = model.predict(X_test) print("MAE:", mean_absolute_error(y_test, y_pred))

这里有三处坑，都是我反复踩过的。

第一坑是随机乱打乱数据集。时序数据跟普通回归数据不一样，今天的样本不能跟下个月的样本混在一起随机切分，否则模型会通过时间泄漏取巧，线上效果翻车。正确做法必须按时间顺序切分，前80%训练，后20%验证。

第二坑是特征穿越。构造特征时用了未来时刻的数据，模型在训练集上表现极好，但一到真实预测就废。比如预测未来一小时需求，结果把这一小时的真实订单量放进了特征，这叫"开卷考试"，没有任何意义。特征只能用历史时刻的数据。

第三坑是只看准确率不看业务效果。对预测模型来说，MAE（平均绝对误差）和RMSE（均方根误差）比R²更直观。我一般会额外计算一个"方向命中率"：预测值偏高或偏低的方向是否跟真实情况一致。对调度系统来说，方向对了才有用，数量差一点可以接受。

3.3 调度策略引擎：用规则生成可解释的调度方案

预测出来以后，怎么变成可执行的车辆调度方案？这里我用的是规则引擎加贪心算法，简单可控，还能向评委解释。

def build_dispatch_plan(regions, pred_demand, pred_supply, safety_margin=5): plan = [] shortage = {} surplus = {} for r in regions: demand = pred_demand.get(r, 0) supply = pred_supply.get(r, 0) if supply == 0 or supply / max(demand, 1) < 0.8: shortage[r] = max(demand - supply - safety_margin, 0) elif supply / max(demand, 1) > 1.5: surplus[r] = supply - demand - safety_margin for target, num in shortage.items(): if num <= 0: continue source = find_nearest_surplus_region(target, surplus) if not source: continue dispatch_num = min(num, surplus[source]) if dispatch_num > 0: plan.append({ "from_region": source, "to_region": target, "car_count": dispatch_num }) surplus[source] -= dispatch_num return plan

这段逻辑的核心是三个关键词：缺口、余量、安全边际。某个区域预测需求120辆车，空闲只有80辆，还要留5辆作为安全余量，那最多允许调度35辆。优先从附近运力过剩的区域调车，调拨数量不能超过对方可调出的余量。

这样做出来调度方案是可解释的，每一条调度记录都能回溯：哪个区缺、哪个区多、为什么调这个数量。论文里写调度算法，优先级排序、约束条件、终止条件都能讲清楚，比一句"使用神经网络优化"要扎实得多。

4. LLM大模型接入：让系统会说话而不是只会出图表

4.1 LLM在系统里的四个正确落地姿势

LLM大模型是今年毕设的"流量密码"，但我见过太多项目把LLM做成一个单纯的聊天机器人，跟业务毫无关联。真正合理的做法是让LLM围绕业务数据干活，下面四个方向是我验证过比较靠谱的。

第一是自然语言问答。用户在聊天窗口输入"朝阳区哪里最难打车"，系统先通过规则或检索拿到对应的数据，再让LLM组织语言回答。第二是自动生成分析报告。把最近一周的订单量、应答率、调度记录喂给LLM，自动生成一篇像样的周报。第三是调度建议解释。系统生成调度方案后，由LLM解释"为什么要调车、从哪个区调到哪个区"。第四是运营知识库辅助决策。把一些经验规则、历史案例整理成知识库，用户提问时先检索相关内容，再结合数据回答。

要特别强调一个边界：不要让LLM直接算数或做预测。大模型在数值计算上极不靠谱，你把数据喂给它，它就可能给你编一个数字。数据计算还是交给pandas和模型，LLM只负责表达。

4.2 本地部署与API两种接入方式怎么选

LLM接入有两种主流方式，我建议做成可配置的，答辩现场可以灵活切换。

方式一是本地部署开源模型。用Ollama加载Qwen2.5-7B-Instruct这类模型，完全离线运行，不依赖外网，答辩现场绝对不会出现"网络异常"的尴尬。缺点是对电脑配置有要求，至少16G内存，模型推理速度也就每秒十几个字。

方式二是调用云端大模型API，比如通义千问、智谱清言、DeepSeek等国内厂商提供的接口。优点是速度快、效果稳定、不需要好显卡，缺点是演示时必须保证网络可用，而且账号余额要提前充值，免费额度经常不够用。

我一般建议项目代码里写一个抽象层，配置文件里切换后端：

# settings.py LLM_PROVIDER = "local" # 可选 local / cloud LLM_LOCAL_URL = "http://127.0.0.1:11434" LLM_LOCAL_MODEL = "qwen2.5:7b" LLM_CLOUD_API_KEY = "" # 云端模型API Key LLM_CLOUD_MODEL = ""

然后封装一个统一的请求函数，项目其他模块不用关心底层用的是本地还是云端，只要调用这个函数发提示词、收文本就行。这样做的好处是，学校机房电脑配置好就切本地，配置差就连云端，进退都有路。

4.3 提示词工程与防幻觉：让LLM只看真实数据说话

装卸式聊天谁都会，难的是让LLM不瞎编。防幻觉只有一个核心原则：把真实数据直接拼进提示词，要求LLM的答案严格基于这些数据，而不是让它凭记忆自由发挥。

def build_analysis_prompt(region_name, metrics): prompt = f""" 你是城市出行调度助手。请根据以下真实统计数据生成一条调度建议。 要求： 1. 必须基于给定的数据，不得虚构数字。 2. 回答控制在80字以内，先说结论，再说依据。 区域：{region_name} 过去1小时订单量：{metrics['order_cnt']} 过去1小时空闲车辆：{metrics['empty_car_cnt']} 平均应答等待时长：{metrics['avg_wait']}分钟 当前供需比：{metrics['supply_demand_ratio']} """ return prompt

这样传给LLM的是结构化事实，LLM只需要做总结和润色，不需要做计算。就算它胡说，数字部分也是从代码里取的，不会影响系统真实性。

如果你想让项目显得更高级一点，可以引入RAG检索增强生成。思路是，把历史分析报告、运营规则、典型调度案例切成文本块，向量化后存进本地向量库。用户提问时先从库里检索相关片段，再连同实时指标一起拼进提示词。不过毕设阶段这个属于"锦上添花"，时间不够可以不搞，用上面的模板拼接方案已经够用了。

5. Django工程化落地：后台、接口与可视化大屏

5.1 项目结构与核心代码组织：一个管不住的App就会乱

Django项目最怕的是把所有代码堆在一个App里，改两行就出bug。我在搭建这类系统时习惯按业务拆成五个App，每个App只做一类事。

ride_dispatch/ ├── manage.py ├── config/ # 项目配置 │ ├── settings.py │ ├── urls.py ├── apps/ │ ├── accounts/ # 用户与权限 │ ├── analyses/ # 数据统计分析 │ ├── prediction/ # 供需预测 │ ├── dispatch/ # 调度管理 │ └── llm_qa/ # LLM问答 ├── scripts/ │ ├── init_data.py # 数据初始化脚本 │ ├── train_model.py # 模型训练脚本 │ └── generate_report.py # 自动报告生成脚本 ├── static/ # 前端静态文件 ├── templates/ # HTML模板 └── requirements.txt

analyses模块负责读取订单数据、生成统计指标，prediction模块负责训练和调用预测模型，dispatch模块负责调度任务的增删改查，llm_qa模块负责与大模型交互，accounts模块负责登录和权限控制。五个App之间依赖关系尽量单向，数据流是analyses → prediction → dispatch，避免循环引用。

5.2 可视化大屏：ECharts地图、指标卡与实时刷新

Django负责提供数据接口，前端可视化我推荐用ECharts。地图热力图是这套系统的视觉核心，效果非常震撼。

实现步骤大概是三步。第一步，在Django接口中返回按区域聚合的订单量数据，格式类似[{"name": "国贸", "value": 120}, {"name": "中关村", "value": 85}]。第二步，前端通过Ajax请求这个接口。第三步，用ECharts的heatmap组件把数据渲染到地图上。

$.ajax({ url: "/api/analyses/heatmap/", type: "GET", data: { date: "2024-12-20" }, success: function (res) { var chart = echarts.init(document.getElementById("heatmap")); var option = { series: [{ type: "map", map: "city", data: res.data, visualMap: { min: 0, max: 200 } }] }; chart.setOption(option); } });

这里有一个我每次都要提醒的坑：如果你的电脑只能离线演示，记得把ECharts的JS文件下载到本地static目录，不要用CDN地址。不然答辩现场断网，首页直接白屏。

实时刷新用一个定时器轮询就行，比如每30秒请求一次最新数据。毕设场景不需要WebSocket，别给自己增加复杂度。

5.3 定时任务与权限：演示前一定要提前验证

系统里很多数据是"过期"的，比如预测结果，半小时前算的和现在算的可能完全不一样。我一般推荐每小时跑一次预测任务，把未来一小时各区域的需求供给存到预测结果表。前端展示时直接读表，查询压力小，响应也快。

定时任务的实现可以用Django+Celery，但Celery在Windows下经常有兼容问题。我的习惯是推荐APScheduler，只要在Django启动时注册一个后台调度器就行，没有外部依赖，演示前不用额外启动几个服务。

权限方面建议设置两个角色：管理员和访客。管理员能查看调度任务、编辑车辆信息、触发手动预测，访客只能看大屏和问答结果。用Django内置的User模型加一个profile字段就能实现，写论文时这部分也能单独成一个章节。

6. 交付物组合拳：源码、论文、PPT与讲解怎么准备

6.1 源码目录与运行说明：给答辩老师省时间就是给自己加分

毕设交付要求里通常包含源码、论文文档（也就是标题里写的LW）、PPT和讲解材料。源码这部分的重点是"能跑起来"。我见过太多同学的代码写得挺好，结果答辩前临时跑不起来，非常可惜。

一个合格的源码包至少要有这些东西：完整的README运行说明，写清楚Python版本、依赖库、数据库配置、启动命令；requirements.txt锁住所有依赖版本；scripts目录下放数据初始化脚本，一个命令就把测试数据导入数据库；以及一份简单的测试账号列表，方便评委快速登录系统查看效果。

数据初始化脚本值得多花点时间。用python manage.py seed_demo_data一键生成一批带规律的模拟订单数据，能让评委在演示时看到"预测曲线明显跟着早晚高峰起伏"，这个效果比数据乱七八糟强多了。

6.2 论文框架与创新点写法：LW最容易丢分的地方

论文部分最容易被扣分的不是字数不够，而是"答非所问"。评委想看到的是你如何一步步解决问题，不是你抄了一堆技术文档。

我建议按这个框架写：摘要加绪论，重点写选题背景和国内外研究现状，国内外现状里要提到现在大模型在交通领域的应用趋势，但不能只是概念罗列。然后是关键技术介绍，Django框架、机器学习、大模型相关概念各占一节，这节是铺垫，不要写太长。接下来是系统需求分析与总体设计，画出功能结构图和数据库ER图，说明模块怎么划分。然后是核心模块详细设计，订单数据清洗、供需预测模型、调度策略、LLM问答流程各占一章，每章都要写实现思路加核心代码片段。最后是系统测试与效果分析，放可视化大屏截图和预测评估指标。

创新点这部分是拿分关键。你在LLM接入方式、调度规则设计、特征工程上的具体优化都可以写成创新点。比如"将大模型引入交通调度领域，通过结构化数据拼装提示词的方式避免数值幻觉"，这句话就能当创新点写在摘要里。

6.3 PPT与讲解节奏：先演示再讲原理，效果最好

PPT不要做满屏文字，我见过太多同学把论文段落直接粘到PPT上，评委根本不想看。更有效的做法是，PPT只放图表、架构图和关键数据，每页讲一个要点。

演示顺序我建议这样安排：第一分钟介绍选题背景，第二分钟展示系统功能架构，第三到第八分钟现场演示，从大屏、热力图、预测模块一路操作到LLM问答，第九到第十二分钟讲核心技术和实验数据，最后留几分钟提改进方向。

答辩常见问题也要提前准备。比如"为什么用Django而不用SpringBoot"，可以回答Django生态成熟、自带ORM和Admin、开发迭代快，适合数据密集型应用。再比如"LLM输出的结果如果不准怎么办"，要解释系统在提示词里嵌入了真实统计指标，LLM只做语言组织，不下数值结论。还有"这个系统跟真实商业产品有什么区别"，坦诚说明数据规模和策略复杂度上有差距，但整体技术流程与工业界一致。

7. 高频坑位清单：数据、模型与答辩现场的避坑指南

7.1 数据与预测相关的坑

7.2 LLM接入的坑

本地模型首次启动特别慢，甚至可能加载模型就要一两分钟。如果答辩现场用本地部署，一定要提前把所有模型预热好，不要现场从零加载。更稳妥的做法是提前录好一段完整的问答演示视频，现场就算卡死也能用视频兜底。

云端API常见的报错是超时和请求失败。代码里要加抛出异常后重试的逻辑，重试两到三次仍然失败就降级为返回预设文案"当前无法获取智能分析，请稍后再试"，不要让用户看到一堆堆栈信息。

关于幻觉，我再说一遍：凡是涉及数字的结论，一律由代码计算，LLM只负责修饰语言。这个原则写进论文里也是很大的加分项，说明你对大模型的能力边界有清晰认知。

7.3 Django与演示环境的坑

用Django开发时默认跑在开发服务器上，如果现场演示被评委问到"项目能不能部署到Linux服务器"，你得至少知道用gunicorn加Nginx的基本配置思路。如果真要部署，要注意静态文件的收集，python manage.py collectstatic这步不能漏。

还有设置里的调试模式，DEBUG=True时出错会显示详细报错，看着很方便，但演示时万一报错，满屏英文堆栈会显得很不专业。建议演示前至少完整跑一遍操作流程，能报的错提前排完。

MySQL的时区问题也挺常见，如果发现统计出来的数据和实际时间差8小时，去检查Django的TIME_ZONE和MySQL连接参数，统一改成Asia/Shanghai就能对齐。

最后再分享一个我自己的习惯：我接这种项目的时候，都会先把"演示脚本"写出来，哪怕还没开始写代码。演示脚本就是一句话对应一个页面一个操作，比如"打开首页，大屏展示昨日订单量，点击热力地图，看到区域热度分布，切到预测页，跑出未来一小时缺口，再问LLM应该怎么调车"。等你把演示脚本写清楚了，整个系统该有哪些功能、该存哪些表、该接哪些接口，全部都会变得特别清晰。这是我踩了不知道多少次坑之后总结出来的办法，希望它也能帮你在答辩现场少一点手忙脚乱，多一点从容。