Amy青梅有不少计算机专业的同学看到“Django + LLM 大模型 + 滴滴出行分析”这种组合，第一反应是：这到底是毕设还是造火箭？等真把题目拆开看，你会发现它本质上是一个“数据可视化 + 算法建模 + 大模型应用”三位一体的综合性项目，难度不低，但也没有想象中那么高不可攀。今天我就以这套出租车供需平衡优化系统为例，完整拆解一遍从选题、技术选型、数据设计到落地的全流程，把那些贯穿项目始终的坑和心得一次说清楚。
这套系统能做什么、解决了什么问题？一句话概括：基于滴滴平台开放的出行订单数据，通过大数据分析手段还原城市出租车的供需时空分布，再结合机器学习模型对短期供需缺口做预测，最终用Django搭建Web平台呈现可视化大屏，并引入大语言模型作为智能分析助手，让用户用自然语言就能查数据、看结论、拿对策。它适合计算机、大数据、人工智能方向的学生作为毕业设计，也适合想快速上手“大模型+行业应用”这套打法的开发者参考。
1. 整体设计与技术选型思路
1.1 为什么选择Django作为主框架
做毕设选Web框架，很多人会纠结Flask、FastAPI和Django。这个项目我最终推荐Django，理由很直接：Django自带Admin后台、ORM、认证体系和模板引擎，这些功能对于毕业设计来说不是“臃肿”，而是“白送的基础设施”。
Django的ORM在操作MySQL或SQLite时非常省心，尤其是数据分析结果需要落库、查询、再渲染到前端大屏的场景。你用Pandas处理完的DataFrame，可以很自然地写入Django模型对应表，前端通过API或者模板直接读取展示，整个数据流是闭环的，不会像Flask那样需要自己拼一堆SQL和路由逻辑。
另一个现实因素是答辩。Django的MVT模式架构清晰，目录结构规范，评委老师看到你的项目分层合理、代码整洁，本身就是一个加分项。再加上Django有完善的Admin后台，你可以在后台直接管理用户、管理数据、配置模型参数，演示时可操作性强，临场翻车概率低。
我见过不少同学用FastAPI写这类项目，性能确实好，但如果你需要快速出效果、又要兼顾行政后台和用户权限管理，Django的“全家桶”优势会非常明显。一句话总结：追求性能上限选FastAPI，追求交付速度和稳定性选Django，毕设的话Django是更稳妥的选择。
1.2 大模型在系统里的角色定位
“LLM大模型”在毕设里听起来很高端，但你要想清楚它到底承担什么职责，功能搞复杂反而容易失控。在出租车供需分析这个场景中，大模型常见的合理落点有三个：
第一是自然语言查询入口。用户输入“昨天晚高峰哪个区域的打车难度最大”，系统调用大模型，将这句话解析成结构化查询条件，例如时间范围、区域筛选、指标名称，再去后端SQL或API执行，最后把结果返回给用户。这个过程比传统的固定筛选项体验好得多，也给答辩增加了亮点。
第二是智能解读分析结论。供需预测模型输出一组数字，比如“未来1小时国贸区域供需缺口指数为0.82”，大模型可以自动生成一段可读性强的业务解读，告诉用户该区域需要增加多少运力、什么时段最紧张、和上周同期比有什么变化，相当于一个自动化的分析师。
第三是策略建议生成。当系统识别到某个区域的供需失衡达到阈值时，调用大模型输出调度建议和原因解释。这里要注意，不要指望大模型生成的建议能真正上生产调度系统，对于毕设来说，它更像是决策辅助和产品能力展示。
1.3 LLM必须遵守的两条红线
大模型项目最常出问题的不是模型效果，而是密钥安全和成本失控，这两点必须从架构层面提前规避。
密钥安全方面，后端调用大模型API时，密钥只能存在服务端环境变量中，任何情况下都不能下发到浏览器端或者出现在前端JS代码里。我见过有同学直接把API Key写死在Vue项目里，结果测试的时候被同学抓包抓到了，一晚上把账户额度刷爆。正确的做法是：Django后端通过 os.environ 读取密钥，对前端只暴露一个