做过毕设的人都知道，最难受的不是写代码，而是开题时拍着胸脯说"基于Python的购物商城数据分析可视化系统"，结果一打开IDE不知道从哪下手。Django、Vue、deepseek agent、大数据可视化这些词堆在一起，听着唬人，但真要落地，涉及的链路比想象中长得多——数据从哪来、指标怎么算、图表怎么联动、大模型agent到底接进来干什么，每一步都是坑。这篇就基于我给学弟学妹们做毕设辅导时反复梳理的那套东西，把整个"购物商城数据分析可视化"项目从头到尾拆一遍，从需求到选型、从数据清洗到可视化看板、从deepseek agent接入到答辩加分项，全部写成能直接照着做的那种。
先说清楚这个项目是什么：它不是一个简单的CRUD商城，而是一套"数据驱动决策"的展示系统。前端Vue展示看板，后端Django提供接口和数据处理能力，中间再插一个大模型agent，让用户可以直接用自然语言问"上个月哪个品类退货率最高"，系统自动生成SQL、拉取数据、产出图表和文字结论。这类项目在毕业设计里属于典型的"技术栈全、亮点明显、工作量可度量"选题。
1. 先想明白：这个毕设到底要解决什么问题
很多做电商数据分析毕设的同学，一上来就急着搭框架，结果做到一半发现做的只是"查订单、看列表"，和"数据分析可视化"完全不沾边。核心原因是没有把问题定义清楚。数据分析类项目的价值不在于"能查到数据"，而在于"能从数据里看出别人看不出的东西"。所以需求和场景一定要在设计阶段就锁定。
1.1 系统的角色与核心痛点
购物商城数据分析平台，站在使用者的角度，至少要回答三类问题。
第一类是经营层问题，也就是老板最关心的：今天卖了多少钱、这个月GMV达成率如何、哪个区域增长最快。这类问题需要的是汇总指标+趋势图。
第二类是运营层问题，运营人员想知道哪些商品是爆款、哪些商品在滞销、用户加购后为什么没有下单。这类问题需要多维拆解，比如价格带分析、品类结构分析、转化漏斗分析。
第三类是决策层问题，更抽象一点：下个月备货应该侧重哪些商品？要不要调整定价策略？季度大促的预期效果是多少？这类问题传统BI做不了，就得靠大模型agent辅助推演，给出基于历史数据的参考结论。
把这三层需求明确之后，系统的功能边界才能定下来。不需要做完整的商城交易功能，不需要做用户注册登录的完整权限体系，最多做个简化版登录用于区分管理员和访客；也不需要接入真实支付宝/微信支付，因为毕设的核心是"数据分析可视化"，不是"电商交易系统"。想清楚"不做什么"，有时候比"做什么"更重要。
1.2 功能模块怎么切才不臃肿
我的建议是把系统拆成四个主模块，每个模块都有明确的输入和输出：
- 数据管理模块：负责商品、订单、用户、评论等数据的导入、清洗、存储，支持CSV批量导入和模拟数据生成。
- 数据分析模块：围绕销售、商品、用户、库存四个维度，提供统计计算、排行、占比、趋势等核心分析功能。
- 可视化大屏模块：基于Vue和ECharts实现，包含总览大屏、商品分析页、用户画像页、库存预警页。
- 智能问答模块：接入deepseek大模型，用户用自然语言提问，agent自动转化为查询逻辑，返回数据和图表。
这个切法在答辩时特别好讲，因为每一块都能对应到"你做了什么工作"。数据管理对应数据处理能力，分析模块对应算法与统计能力，可视化对应前端技能，大模型agent对应新技术应用能力。评委一眼就能看到完整的技术覆盖。
2. 技术选型：Django + Vue + deepseek 这套组合到底好在哪
"什么技术栈最主流"和"什么技术栈最适合你的毕设"是两件事。我见过太多人选了Spring Cloud微服务做电商数据分析，结果到答辩前一周还在调试Nacos注册中心，核心的分析功能反而没做。对于这个题目，Django + Vue + deepseek agent，是经过权衡的结果。
2.1 为什么后端选Django而不是Flask或FastAPI
Django在这一类项目里有三个不可替代的优势。
第一是ORM极其适合数据分析类项目。购物商城数据分析的底层是"多表关联查询+聚合运算"，Django ORM的annotate、aggregate、Prefetch能让你用Python代码完成绝大多数SQL操作，而且模型定义本身就是数据字典，中期检查时直接拿models.py讲数据库设计，比贴SQL清晰得多。
第二是自带Admin后台。毕设阶段通常需要一个"管理入口"来导入数据、查看原始表，Django Admin不用写一行前端代码就解决了这个问题，省下来的时间可以全部投入到可视化看板和大模型agent上。
第三是生态成熟。pandas处理完的数据可以直接塞进Django的JsonResponse，django-rest-framework写API也顺滑，不需要额外学一套序列化工具。
Flask轻量，但到了后期你会发现所有东西都得自己拼，排序过滤、分页、序列化都要手写，工作量并不少。FastAPI性能好，但异步模型和Django ORM的配合在一些场景下不够顺畅，而且答辩时评委更熟悉Django的套路，沟通成本低。如果要做企业级项目开发，Django的一站式设计也会让代码结构更规范，后续维护更省心。
2.2 为什么前端选Vue而不是React或原生页面
Vue在这个项目里最大的优势是"渐进式"和"数据响应式"。可视化管理后台的典型场景是：顶部筛选条件变化，下方一堆图表跟随刷新。Vue的computed和watch天然适配这套交互逻辑，组件的props和emit也能很好地组织图表组件之间的通信。
具体来说，Vue生态里有现成的vue-echarts组件库，接入ECharts只需要几行代码。相比之下，React的Hooks写法对新手上手门槛更高，原生JS做图表联动则要写大量DOM操作，逻辑一复杂就失控。Vue的路由（vue-router）和状态管理（Pinia）也都有成熟方案，做多页面的导航和登录态管理，思路非常清晰。
另外一个实际原因：Vue的中文资料极多，毕设阶段遇到了组件渲染、路由守卫、跨域问题，随便一搜就能找到对应的解决方案。这不是技术鄙视，而是"在有限时间内把项目做完"的现实考量。
2.3 deepseek大模型agent在毕设里的合理定位
大模型不能为了接而接，接进去必须解决实际问题。在这个项目里，我推荐的接入方式是：deepseek作为"数据分析解释器"，用户提问后，agent把自然语言转换为结构化的查询意图，再调用后端接口获取数据，最后用大模型生成分析结论和建议。
比如用户提问："对比一下今年一季度和二季度的各品类销售额变化。"这个query走完agent链路后，前端拿到的是：一张品类销售额对比的柱状图、一段AI生成的文字分析（说明哪个品类增长最快、可能的原因推测、以及建议关注点）。
这里要强调一个关键点：不要让deepseek直接去生成SQL。原因有二，一是deepseek在生成复杂SQL时容易产生幻觉，表名、字段名一旦写错，调试成本极高；二是直接生成SQL会让系统变得不可控，答辩时评委如果问"如果大模型生成了一段错误SQL怎么办"，你很难解释清楚。更稳妥的方案是让大模型做"意图识别+参数抽取"，比如识别出用户要对比"两个时间段"的"品类销售额"，然后把参数传给后端，由后端写死的聚合逻辑来执行查询。
注意：毕设阶段的agent不要追求"完全自主"，能做到"结构化的智能问答"就足够支撑你的创新点表述了。
3. 数据底座：从采集清洗到商品画像的完整链路
数据分析项目最怕的不是没界面，而是没数据。评委打开你的系统，如果图表区域空空如也，哪怕后端逻辑再漂亮，效果也大打折扣。所以数据的工作必须前置，而且要形成一个完整链路：数据准备 -> 数据清洗 -> 数据入库 -> 数据建模。
3.1 数据从哪来：模拟数据生成器的设计思路
真实电商数据涉及用户隐私，不可能直接拿来用。绝大多数毕设用的是公开数据集或模拟数据。我用的是faker库加上自研的业务规则生成器。
具体思路是写一个data_generator.py，模拟一个包含500个商品、2000个用户、10万条订单样本的商城。生成的时候必须注意业务一致性：商品要有类目拉链，订单要有状态流转（待付款、已付款、已发货、已完成、已退款），用户要有注册时间和等级属性。如果只是随机拼凑，分析出来的结论会非常假。
模拟数据的时候有两条经验分享。
第一，订单金额不是纯随机数，要符合"长尾分布"，也就是大量小金额订单加少量大金额订单。实现方法是让订单金额服从幂律分布或对数正态分布，这样后续的价格带分析才有区分度。第二，时间字段要有季节性。比如3月和9月销量偏低、6月和11月偏高，这样才能让趋势图看起来真实，也方便大模型agent被问到"为什么某月销量下降"时给出合理推测。
3.2 清洗环节的三个高频坑
数据清洗是数据分析里最枯燥但最容易让评委问出细节的环节。三个高频坑先说清楚。
第一个是日期格式不统一。有的记录是2024/05/01，有的是2024-05-01 12:33:22，还有的是时间戳。统一格式不能靠肉眼，要用pandas.to_datetime配合errors='coerce'，把所有非法值统一处理成NaT，再根据相邻记录或业务默认值填充。
第二个是重复订单。同一用户短时间重复提交，不能简单删掉，要看业务上下文。如果是"订单号不同但商品和收货人相同"，且时间差在几分钟内，大概率是重复提交，可以只保留最新一条；如果是周期性采购（比如每月购买一次日用品），反而是正常的。
第三个是商品价格与订单金额不一致。这是因为用了优惠券或平台补贴。处理办法是在订单表里增加discount_amount和pay_amount两个字段，把原始价格和实付价格分开存。分析销售额时一律用pay_amount，这是电商分析的标准做法。
3.3 商品画像与分析模型怎么构建
数据入库之后，不要急着做图表，先构建分析模型。我在这套系统里设计了四个核心模型，对应四张宽表。
- 商品宽表（sku_id, 类目, 品牌, 价格带, 销量, 销售额, 库存, 退货率, 好评率, 上架天数）
- 用户宽表（user_id, 注册时间, 城市等级, 累计消费, 消费频次, 最近购买时间, 常用支付方式）
- 订单明细表（order_id, user_id, sku_id, 下单时间, 支付金额, 状态, 渠道来源）
- 日聚合表（日期, 类目, 销售额, 订单量, 客单价, 转化率, 退货率）
这里的核心逻辑是"预聚合"：把10万条订单明细，提前按天、按类目聚合成几千条记录，前端图表查询时只读聚合表，速度会快非常多。很多新手直接把订单明细丢给前端，结果ECharts渲染上万条数据直接卡死。预聚合方案在答辩时还有一个好处——你可以讲"我用了空间换时间的思想，通过预聚合提升查询性能"，这是加分项。
4. 可视化看板：把"卖了多少"变成"为什么好卖"的指标设计
数据可视化不是把图表堆在页面上，而是有一套指标体系和交互逻辑。评委看大屏时，第一眼看的是"有没有按照业务逻辑组织信息"，不是"图表画得炫不炫"。所以这一节我会把四大看板的指标设计和图表选型拆开讲。
4.1 总览大屏：第一屏就要能讲故事
总览大屏是系统的门面，通常放在最上面。我推荐的布局是"关键KPI + 趋势 + 排行 + 结构"四段式。
顶部放四个核心KPI卡片：今日销售额、今日订单量、本月客单价、近7日退款率。这四个数字要能实时反映平台概况，KPI卡片旁边可以配环比涨跌，用红色/绿色箭头表示，这一下就有了商业大屏的质感。
中部左侧放"近30天销售额趋势折线图"，右侧放"品类销售额占比环形图"。底部放"商品销售TOP10排行榜（横向条形图）"和"地区销售热力分布图（地图）"。这套布局不是随便排的，它遵循了用户浏览习惯：先看总量，再看趋势，再看结构，最后看细节。
实现上要注意的是，图表尺寸必须做响应式。vue-echarts官方提供了ResizeObserver的封装，但实际用下来，我建议在组件unmount之前手动调用dispose，不然页面切换后图表的定时器可能还在跑，造成内存泄漏，这在答辩演示时如果开了很久的页面，会被评委一眼发现卡顿。
4.2 商品分析页：拆到类目和价格带才叫分析
很多人的商品分析页就是一张大表格，充其量加个柱状图，这远远不够。我设计商品分析页时，用维度切换的方式去拆。
维度一："类目分析"。按一级类目（服装、数码、美妆、食品、家居）展示销售额、销量、退款率、毛利预估。切换类目后，下钻到二级类目。这里我用的是"钻取式"交互，点击柱状图的某个类目，右侧联动展示该类目下的品牌排行。这个交互在Vue里实现不复杂，核心是维护一个currentCategoryId的响应式变量，所有图表都computed依赖这个变量。
维度二："价格带分析"。把所有商品按价格分为0-50、50-100、100-200、200-500、500以上五个区间，展示每个区间的销量占比、销售额占比和退货率。这个分析的价值在于可以回答"我们的定价策略是否健康"。比如如果0-50元的价格带贡献了60%的销量但只贡献了20%的销售额，说明平台在低价商品上过重，利润空间堪忧，这就是一份可以写进论文结论段的真实发现。
4.3 用户画像页：RFM模型让分析有深度
用户画像页如果只画性别饼图和年龄柱状图，就太普通了。我建议引入RFM模型，这是电商分析里的经典方法，也是答辩时可以重点讲的一个算法点。
RFM三个字母分别是Recency（最近一次消费时间）、Frequency（消费频率）、Monetary（消费金额）。把每个用户的这三个指标算出来，然后按各自的均值分高低，得到8个客群（重要价值客户、重要保持客户、重要发展客户、重要挽留客户、一般价值客户、一般保持客户、一般发展客户、一般挽留客户）。
实现RFM模型的核心代码在Django侧：
from django.db.models import F, Max, Count, Sum rfm_data = ( Order.objects .values('user_id') .annotate( last_order=Max('order_time'), order_count=Count('id'), total_amount=Sum('pay_amount') ) )得到RFM值之后，前端用散点图展示（x轴为消费频率、y轴为消费金额、点大小为最近消费天数），再用颜色区分客群标签。这张散点图放出来，整个用户分析页的档次立刻不一样。我见过评委专门指着这张图问"RFM阈值的计算依据"，所以要在论文里写清楚：阈值默认取全体客户的均值，也可以用quantile分位数来计算，后者更稳健。
4.4 库存预警页：商业闭环里的最后一块拼图
前面几页都在讲"卖了多少"，库存预警页解决的是"还能卖多久"。这个页面的核心指标是"预计售罄天数"，计算公式是：
预计售罄天数 = 当前库存 / 近7天日均销量当预计售罄天数小于15天时，标记为"低库存警告"；小于7天时，标记为"紧急补货"。反之，如果近30天销量几乎为零且库存量很大，标记为"滞销品建议清仓"。
库存预警页的图表我用的是"双轴图"，左侧柱状图是当前库存量，右侧折线图是近7天日均销量，散点大小代表商品价格。表头加了两个筛选下拉框：类目和库存状态。这套设计的核心在于把数据分析结果直接转化成"可执行的动作"，而不是停留在数据展示。评委问"你的系统有什么实际价值"时，你就可以拿这个页面举例——它能直接告诉运营人员：明天应该补什么货，清什么仓。
5. 大模型agent：deepseek接进来之后到底能干嘛
前面所有分析功能，本质上都是"人工设定好的规则"，用户得自己去看图表得出结论。大模型agent的意义在于，把"看图表得出结论"这个动作交给AI，实现"用自然语言问数据"。
5.1 deepseek在整条链路中的位置
先明确架构。我在实际项目里把大模型agent设计成三层：
第一层是前端交互层。页面右下角放一个悬浮对话按钮，用户输入问题，比如"哪款美妆产品的复购率最高？"，前端把问题和当前选中的筛选条件一起发送到后端。
第二层是后端Agent服务层。Django接收到问题后，不直接调用deepseek，而是先做三件事：输入清洗、意图识别、参数抽取。我用了jieba分词配合关键词词典，先判断问题涉及的分析域（销售额/销量/退货率/复购率），再抽取实体（商品名、类目名、时间范围）。这一步是关键，如果实体抽取置信度低于0.6，就回复"抱歉，我暂时无法理解这个问题"。
第三层是LLM生成层。只有在上一步成功的情况下，才把"业务问题+对应数据摘要"一起发到deepseek API，让大模型生成最终的文字结论。这样既控制了风险，又把大模型的价值发挥在了它最擅长的地方——自然语言的组织和业务洞察的表达。
5.2 deepseek API的调用与参数细节
deepseek API的调用方式，本质上和OpenAI兼容，这是它很好接的原因。后端用HTTP请求就能完成调用。
import requests resp = requests.post( "https://api.deepseek.com/chat/completions", headers={ "Authorization": f"Bearer {DEEPSEEK_API_KEY}", "Content-Type": "application/json" }, json={ "model": "deepseek-chat", "messages": [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": user_question} ], "temperature": 0.3, "max_tokens": 500, "stream": False } )这里我踩过一个关键坑：temperature参数。如果调成默认值1.0，大模型生成的结论会非常发散，会编造一些数据里不存在的原因；调成0.2~0.3之后，回答会保守很多，基本只基于提供的数据做分析。在数据分析场景，我们要的是"可控的洞察"，不是"有创意的胡说"。另外如果希望页面像ChatGPT一样流式输出，可以开启stream: True，但Djang那边要注意SSE响应的内容类型必须设置为text/event-stream，否则Vue端接不到增量内容。
5.3 如何设计Prompt让分析与图表联动
大模型agent如果只是生成一段文字，说服力是不够的。最好的效果是：用户提问 -> agent返回文字结论 + 一组可配置的图表参数 -> 前端自动渲染对应图表。
我设计的Prompt包含两部分。System层Prompt要求大模型严格遵循以下规则：
- 只基于提供的数据进行推断，不编造数据
- 回答需包含"数据表现""可能原因""建议动作"三个部分
- 每个回答控制在150字以内，使用简洁的分点说明
User层Prompt则把结构化数据填进去，例如：
当前问题是：对比近两个月数码类目销售额变化。 数据摘要： 6月数码类目销售额：128500元 7月数码类目销售额：167200元 环比变化：+30.1% 热销商品：无线耳机（+45%）、智能手表（+38%）这样大模型输出的结论就有依据。为了让前端能根据文字结论渲染图表，我在返回结构里加了一个chart_config字段，它是后端意图识别时生成的JSON，例如：
{ "chart_type": "bar", "x_axis": ["6月", "7月"], "series": [ {"name": "数码类目销售额", "data": [128500, 167200]} ] }前端拿到这个JSON直接setOption到ECharts实例上，整个过程就闭环了。这种"文字+图表"的双输出设计，在答辩演示时效果极好，因为评委能直观感受到大模型不是空谈，而是真正接入了数据。
5.4 Agent开发中容易忽略的三个细节
细节一：上下文管理。如果你做了多轮对话，每轮都把历史消息全部发給deepseek，token消耗会很大，而且Django后端响应会变慢。我的做法是只保留最近两轮的关键结论摘要，拼成一个短上下文。这在大模型API调用中是标准的"滑动窗口"策略。
细节二：敏感词过滤。虽然这是一个纯学习项目，但作为毕设代码，必须在agent入口加一道检查，把涉及隐私、违法违规、诱导性内容的输入拒之门外。这不是形式主义，而是体现出你在做工程时的责任心，答辩时被问到安全性时能大方作答。
细节三：API Key不能硬编码在前端。一定要放在后端环境变量里，例如.env文件或Django的settings.py中读取。我见过有人直接把Key写进Vue的axios请求头里，结果一打开控制台就能看到明文Key，这在答辩演示时是非常严重的减分项。
6. 数据库设计与接口联调：把前后端缝起来的实操细节
数据模型和可视化方案定了之后，最大的工作量在数据库表设计和接口联调上。这一节聊几个最常出问题的地方，都是在真实项目里踩出来的经验。
6.1 五张核心表的关系设计
前面提到四个宽表，这里拆成更具体的关系型表结构。我用的是经典的电商五表模型：
用户表User：id, username, password, register_date, city, user_level
类目表Category：id, name, parent_id（支持两级类目）
商品表Product：id, sku_id, name, category_id, brand, price, stock, status
订单表Order：id, order_no, user_id, order_time, status, total_amount, pay_amount
订单明细表OrderItem：id, order_id, product_id, quantity, price, discount_amount
这里要特别说明一个设计选择：订单表和订单明细表为什么要分开？因为一个订单可能包含多个商品，如果不拆，统计"每个商品售出多少件"时就会出现笛卡尔积的错误。分表之后，销售额的聚合在OrderItem上做，订单维度的聚合在Order上做，职责清晰，Django ORM写起来也更顺手。
6.2 Django ViewSet + Vue axios 的联调规范
接口联调时最常见的报错是CORS跨域。Django后端跑在8000端口，Vue前端跑在5173端口，属于典型的跨域场景。解决方案是安装django-cors-headers，在settings.py配置：
INSTALLED_APPS = [ 'corsheaders', ... ] MIDDLEWARE = [ 'corsheaders.middleware.CorsMiddleware', ... ] CORS_ALLOWED_ORIGINS = [ "http://localhost:5173", "http://127.0.0.1:5173", ]对于GET请求，这样配置就能搞定。但如果涉及POST（比如agent对话接口），还要注意CSRF的问题。我的做法是在agent接口的ViewSet上增加@csrf_exempt装饰器，同时在前端axios请求头里加上Content-Type: application/json。这个细节看起来小，但在联调时卡住了不少同学一整个晚上。
数据格式方面，我统一采用REST风格。列表接口返回：
{ "code": 200, "message": "success", "data": { "total": 100, "items": [...] } }前端axios封装一个响应拦截器，判断code字段，不是200时就统一弹出el-message提示。这样所有接口的异常处理逻辑都收敛在一个地方，不用每个页面重复写错误弹窗。
6.3 查询性能：给图表接口加缓存
大屏页面通常每5分钟轮询一次数据，如果每次都跑一遍复杂的group by聚合，数据库压力不小。尤其是订单明细分表到了10万条级别后，聚合查询容易达到几百毫秒甚至秒级。
我采用的优化方案是在Django侧增加缓存层。用Django自带的cache框架，配置为LocMemCache就够了，毕设项目不需要引入Redis增加复杂度。
from django.core.cache import cache def get_sales_trend(days=30): cache_key = f"sales_trend_{days}" result = cache.get(cache_key) if not result: result = Order.objects.filter(...).aggregate(...) cache.set(cache_key, result, timeout=300) return result这个方案在答辩时也非常好讲，你可以说"我通过缓存机制，将高频查询的响应时间从均值650ms降到80ms，支撑了大屏的实时刷新需求"。有数据、有方案、有结果，这就是工程能力。
7. 答辩演示与源码整理的加分细节
到了答辩阶段，代码写得再好，展示得不好也会大打折扣。这一节聊几个关于演示节奏和源码整理的核心经验。
7.1 演示脚本要像讲故事
演示不要从头到尾把每个页面点一遍，那是功能浏览，不是项目讲解。我建议设计一条主线，分成四步。
第一步，用"数据准备"开场。打开Django后台，展示模拟数据生成的记录条数、数据库表结构，让评委知道你的数据量级和表设计。这一步大概1分钟。
第二步，用"老板视角"进入总览大屏。指着KPI卡片说"这个平台近30天销售额是xx万，环比增长了xx%"，再用趋势图和品类占比说明"增长主要由数码和美妆两个类目拉动"。这一步把大屏的价值讲清楚了。
第三步，用"运营视角"进入商品分析和用户画像页。现场演示一次联动操作：筛选"数码类目"，点击类目下钻，看到二级类目品牌排行变化；再切到RFM散点图，指出"重要价值客户占整体销售额的55%，是需要重点维护的人群"。这一步是功能深度的体现。
第四步，用"决策者视角"引出大模型agent。现场输入一个问题："下个月哪个类目应该增加备货？"让agent返回分析和图表建议。这一步是创新点的展示。
整个演示控制在8分钟内，宁可少展示功能，也要确保每个功能都讲出"为什么这么做"。
7.2 源码注释与README的整理技巧
源码交付时，评委不一定逐个文件看代码，但一定会打开README。一个规范的README能让评委在2分钟内建立对项目的信心。
我建议README包含六个部分：项目介绍与截图、技术栈清单、快速启动步骤（虚拟环境创建、依赖安装、数据迁移、模拟数据生成、启动命令）、目录结构说明、核心接口文档表、常见问题解决。
还有一个很实用的加分做法：在Django项目里增加一个docs/目录，放入三份文档——数据库设计说明、API接口文档、部署文档。这三份文档不用写很长，重点是体现结构化思维。我在辅导过程中发现，凡是认真写了这三份文档的同学，答辩时被问"你这个功能具体是怎么实现的"时，回答起来都非常从容。
7.3 演示环境准备
演示当天翻车的重灾区包括：数据库没初始化、虚拟环境没激活、API Key过期、Vue依赖没装全。我的建议是准备两个环境，一个开发环境，一个演示环境，演示环境不要放在演示当天才配置，至少提前三天跑通全流程，并截图留档。
另外，建议在本地启用HTTPS或者至少用固定端口访问，不要用localhost:8080这种容易冲突的端口。如果当天网络不好，deepseek API的调用要准备好降级方案，比如在无网络情况下自动返回本地预设的离线回答，避免现场演示agent时长时间转圈，这是非常实际的保底技巧。
8. 从一个完成的项目到一个高分的毕设
系统做完了，论文怎么写，也是毕设里不可跳过的一环。这里给几个写论文和最终交付的建议。
论文目录建议按这个顺序组织：绪论（背景意义、国内外现状、研究内容）、相关技术介绍（Django、Vue、ECharts、大模型agent）、系统分析（需求分析、可行性分析）、系统设计（总体架构、数据库设计、核心模块设计）、系统实现（每个模块的关键代码和页面展示）、系统测试（功能测试、性能测试）、总结与展望。
在"系统设计"部分，最容易拿到高分的细节是画清楚"三层架构图"：表现层是Vue页面，应用层是Django的View和Service，数据层是MySQL和缓存。架构图画清楚，评委就知道你的系统是认真设计过的，不是把功能堆在一起。
一个我特别建议增加的小节是"系统测试"。很多同学只写功能测试，我会建议把重点放在性能测试上。用locust写一个简单的压测脚本，模拟20个用户同时访问总览大屏接口，记录响应时间和错误率。把测试结果截图放进论文，配合前面提到的缓存优化方案，构成完整的"发现瓶颈->分析原因->优化->验证"闭环。这是本科论文里比较稀缺的内容，一般拿到了就是亮点。
最后再分享一个我在辅导中反复强调的经验：不要等代码全部写完再写论文，一定要边写边截图。每完成一个页面的一个功能，立刻截三张图：页面效果截图、功能操作截图、数据库表数据截图。最后整理论文时你会发现，90%的配图都已经在不经意间存好了，根本不需要冲刺阶段熬夜补截图。这个小习惯，能让整个毕设周期最后两周的体验完全不同。
