做过毕设的人都知道最难受的不是写代码而是开题时拍着胸脯说基于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或FastAPIDjango在这一类项目里有三个不可替代的优势。第一是ORM极其适合数据分析类项目。购物商城数据分析的底层是多表关联查询聚合运算Django ORM的annotate、aggregate、Prefetch能让你用Python代码完成绝大多数SQL操作而且模型定义本身就是数据字典中期检查时直接拿models.py讲数据库设计比贴SQL清晰得多。第二是自带Admin后台。毕设阶段通常需要一个管理入口来导入数据、查看原始表Django Admin不用写一行前端代码就解决了这个问题省下来的时间可以全部投入到可视化看板和大模型agent上。第三是生态成熟。pandas处理完的数据可以直接塞进Django的JsonResponsedjango-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配合errorscoerce把所有非法值统一处理成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_orderMax(order_time), order_countCount(id), total_amountSum(pay_amount) ) )得到RFM值之后前端用散点图展示x轴为消费频率、y轴为消费金额、点大小为最近消费天数再用颜色区分客群标签。这张散点图放出来整个用户分析页的档次立刻不一样。我见过评委专门指着这张图问RFM阈值的计算依据所以要在论文里写清楚阈值默认取全体客户的均值也可以用quantile分位数来计算后者更稳健。4.4 库存预警页商业闭环里的最后一块拼图前面几页都在讲卖了多少库存预警页解决的是还能卖多久。这个页面的核心指标是预计售罄天数计算公式是预计售罄天数 当前库存 / 近7天日均销量当预计售罄天数小于15天时标记为低库存警告小于7天时标记为紧急补货。反之如果近30天销量几乎为零且库存量很大标记为滞销品建议清仓。库存预警页的图表我用的是双轴图左侧柱状图是当前库存量右侧折线图是近7天日均销量散点大小代表商品价格。表头加了两个筛选下拉框类目和库存状态。这套设计的核心在于把数据分析结果直接转化成可执行的动作而不是停留在数据展示。评委问你的系统有什么实际价值时你就可以拿这个页面举例——它能直接告诉运营人员明天应该补什么货清什么仓。5. 大模型agentdeepseek接进来之后到底能干嘛前面所有分析功能本质上都是人工设定好的规则用户得自己去看图表得出结论。大模型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: fBearer {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开发中容易忽略的三个细节细节一上下文管理。如果你做了多轮对话每轮都把历史消息全部发給deepseektoken消耗会很大而且Django后端响应会变慢。我的做法是只保留最近两轮的关键结论摘要拼成一个短上下文。这在大模型API调用中是标准的滑动窗口策略。细节二敏感词过滤。虽然这是一个纯学习项目但作为毕设代码必须在agent入口加一道检查把涉及隐私、违法违规、诱导性内容的输入拒之门外。这不是形式主义而是体现出你在做工程时的责任心答辩时被问到安全性时能大方作答。细节三API Key不能硬编码在前端。一定要放在后端环境变量里例如.env文件或Django的settings.py中读取。我见过有人直接把Key写进Vue的axios请求头里结果一打开控制台就能看到明文Key这在答辩演示时是非常严重的减分项。6. 数据库设计与接口联调把前后端缝起来的实操细节数据模型和可视化方案定了之后最大的工作量在数据库表设计和接口联调上。这一节聊几个最常出问题的地方都是在真实项目里踩出来的经验。6.1 五张核心表的关系设计前面提到四个宽表这里拆成更具体的关系型表结构。我用的是经典的电商五表模型用户表Userid, username, password, register_date, city, user_level类目表Categoryid, name, parent_id支持两级类目商品表Productid, sku_id, name, category_id, brand, price, stock, status订单表Orderid, order_no, user_id, order_time, status, total_amount, pay_amount订单明细表OrderItemid, 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(days30): cache_key fsales_trend_{days} result cache.get(cache_key) if not result: result Order.objects.filter(...).aggregate(...) cache.set(cache_key, result, timeout300) 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%的配图都已经在不经意间存好了根本不需要冲刺阶段熬夜补截图。这个小习惯能让整个毕设周期最后两周的体验完全不同。