起初接这个选题时我以为又是一套“爬虫图表”的拼凑项目真正做完才发现这里面可挖的东西比想象中多得多。它表面上是给计算机毕业设计准备的源码实际上串起了一条非常完整的数据工程链路采集、清洗、存储、分析、可视化再到推荐和对话式查询。对想在大数据、数据分析、电商产品这几个方向上找感觉的同学来说这是一块很合适的练手靶场。我把这套系统的核心功能拆开讲用 requests 做数据采集端把某电商平台上手机品类的商品信息抓下来用 Flask 构建后端服务用 pyecharts 生成可视化图表呈现品牌分布、价格区间、评论热度、促销趋势等维度再叠加一个基于统计召回和属性相似度的推荐模块最后用大模型 agent 能力做自然语言交互式查询。以下是我完整做完后的复盘包含技术选型的理由、每一个环节的坑、以及答辩演示时容易被问倒的细节。1. 选题动机与系统边界为什么手机品类这么适合做成毕设1.1 这个系统到底解决了什么问题很多同学做毕设喜欢一上来就搞复杂模型比如训练一个推荐神经网络最后却发现数据凑不齐、效果说不清、答辩被追问到哑口无言。这套系统的聪明之处在于它不把重心放在算法上而是放在“数据从哪来、怎么变成有价值的图表、如何被用户使用”这条完整链路上。选择手机品类做数据源有几个现实原因手机商品结构相对统一品牌、价格、内存、颜色、评价数、店铺名等字段齐全适合做结构化分析。数据量适中单页列表加详情页几千条数据就能支撑起很有说服力的可视化结论。用户认知门槛低无论答辩老师还是评审专家都对手机品类有直观感受不需要额外解释业务背景。推荐模块容易落地基于品牌偏好、价格区间、内存容量做召回排序效果好且可解释。系统解决的直接问题就是一个普通用户面对海量手机商品时难以快速判断价格是否合理、口碑是否真实、哪些品牌/配置最值得关注。系统通过可视化看板呈现整体行情通过推荐模块输出“适合你”的商品列表通过对话式查询让人直接问出“三千元以内、续航好、拍照强的手机有哪些”。1.2 核心模块与最终交付物我梳理出的系统模块清单如下这直接对应着源码里的目录结构模块主要职责核心技术点数据采集模块定时抓取手机商品列表与详情requests、多页解析、限速重试数据清洗模块字段抽取、单位统一、缺失值处理pandas、正则表达式存储模块保存结构化数据供分析使用SQLite / CSV分析模块计算品牌、价格、热度等指标pandas、聚合统计可视化模块生成图表并嵌入 Web 页面pyecharts、Flask推荐模块根据用户偏好输出 TopN 商品属性相似度、加权排序智能问答模块自然语言理解与工具调用大模型 API、agent 框架最终交付的是一套能够独立运行的项目演示时先启动爬虫灌入数据再启动 Flask 服务浏览器里就能看到完整看板、推荐结果和对话窗口。2. 技术选型复盘Flask、pyecharts、requests 的组合凭什么够用2.1 每层技术解决的核心矛盾技术选型不是越新越好而是正好卡在毕业设计的工作量和展示效果之间。先说 requests。很多人纠结要不要上 scrapy我的结论是这个项目规模完全不需要。手机品类抓取量在几千到几万条之间requests 配合 Session、重试机制、随机延时完全够用而且代码直观答辩时能一句话讲清楚“我发了一个 HTTP 请求拿到 HTML再用 XPath/正则抽取字段”。用 scrapy 当然更工程化但对于 300 行代码就能讲明白的采集逻辑scrapy 的中间件、管道反而变成了解释负担。再说 Flask。它足够轻能快速把数据分析结果以 Web 服务形式暴露出来。和 Django 相比Flask 更契合这类工具型项目——需要的只是几个路由返回 JSON 或渲染页面不需要后台管理、表单框架、ORM 全家桶。而且 Flask 和 pyecharts 的对接资料非常多遇到问题很容易查到现成解法。pyecharts 的作用是把 pandas 算出来的 DataFrame 变成 echarts 可识别的配置。它不是简单的图表库封装而是自带了一套主题体系和交互事件生成的图表支持缩放、提示框、动态排序视觉效果在毕设演示中是加分项。最方便的是它可以直接输出 HTML 片段也可以生成 JSON 配置交给前端渲染这为 Flask 集成提供了两种成熟路径。2.2 整体数据流转与存储选型我在设计时把系统分成了四层每一层的输入输出都非常明确采集层requests 抓取列表页和数据详情页解析出原始字段写入临时文件。清洗层pandas 读取临时文件做去重、类型转换、价格单位统一生成干净的结构化数据表。分析层对干净数据做分组聚合计算各维度指标输出图表数据和推荐候选集。展示层Flask 读取分析结果通过接口和页面模板渲染看板。存储这里我尝试过 MySQL后来换成了 SQLite。原因很实际毕设项目需要让老师一键跑起来SQLite 是单文件数据库免安装数据量又不大。如果上了 MySQL环境配置问题可能比项目本身还耗时。数据量在几万条场景下SQLite 的查询性能绰绰有余。提示如果你后续想扩展成真正可部署的系统可以把存储层抽象一下预留 SQLAlchemy 接口但演示版本用 SQLite 是最稳的选择。3. 数据采集工程化requests 爬手机商品数据时真正要注意的细节3.1 请求策略与反爬应对采集模块是整套系统的地基地基不稳后面全是空中楼阁。我在写爬虫时踩过不少坑核心经验可以浓缩成三条像真人、留余地、可重试。像真人指的是请求头必须伪装到位。只写一个 User-Agent 远远不够我见过太多新手在这上面栽跟头。需要至少将 User-Agent、Referer、Accept、Accept-Language 头完整带上并且最好准备一个 User-Agent 池每次请求随机切换。以下是示例import requests import random UA_POOL [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0 Safari/537.36, ] def make_session(): sess requests.Session() sess.headers.update({ User-Agent: random.choice(UA_POOL), Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/webp,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.6, }) return sess留余地指的是请求频率必须保守。手机品类数据量不需要高并发每抓一页睡上 1 到 3 秒总耗时也在可接受范围内。很多反爬机制的核心触发条件就是“单位时间请求量超过阈值”控制节奏比花式绕过更可靠。可重试指的是对偶发失败要有兜底。我在代码里封装了带重试机制的请求函数连续失败超过三次就记录日志并退出避免死循环或触发更严厉的限制def safe_get(url, sess, retries3): for i in range(retries): try: resp sess.get(url, timeout10) if resp.status_code 200 and resp.text: return resp.text except Exception: pass time.sleep(2 random.random()) return None3.2 字段清洗与落库结构原始数据拿回来后清洗是最容易被低估的环节。我最初直接把页面上的文本塞进数据库结果后面做可视化时到处出问题价格带了“元”字、评论数带了“万”字、有的商品没有内存字段、品牌命名单双引号不一致。我的处理办法是写一个独立的清洗脚本用 pandas 分阶段处理import pandas as pd def clean_data(df): # 统一品牌名称去掉空格和特殊字符 df[brand] df[brand].str.strip().str.upper() # 价格字段抽取数字并转成浮点数 df[price] df[price].str.replace([^0-9.], , regexTrue).astype(float) # 评论数处理1.2万 - 12000 def parse_comment_cnt(s): s str(s) if 万 in s: return float(s.replace(万, )) * 10000 return float(s.replace(,, ).replace(条, )) df[comment_cnt] df[comment_cnt].apply(parse_comment_cnt) return df存储表结构设计成一张主表就够了核心字段包括字段名类型说明sku_idTEXT商品唯一标识titleTEXT商品标题brandTEXT品牌priceREAL当前价格original_priceREAL原价或划线价comment_cntINTEGER评论数shop_nameTEXT店铺名memoryTEXT内存版本如 8GB256GBcategoryTEXT商品类目清洗后我会再跑一次去重和缺失值检查确保进入可视化阶段的数据是干净可信的。数据质量直接决定了图表能不能讲出好故事这一关不能图省事。3.3 爬虫稳定性的运维手段采集模块写完只是第一步真正稳定跑完需要加几个保险。我把采集脚本设计成支持增量更新的模式每次运行前先读取数据库里已有的 sku_id 集合遇到重复商品就跳过。这样演示前临时加跑一轮不会把数据搞乱。同时采集进度日志要打印清楚包括当前页码、成功条数、失败累计次数。我建议用标准库 logging 输出到文件而不是只 print 到控制台。因为采集是长时间任务中途可能断网或手动中断有日志才能排查问题。还有一个容易忽略的点字段抽取规则要尽量和 HTML 结构解耦。我第一版解析逻辑强依赖某个具体的 class 名称结果页面结构调整一次就全崩了后来改成“先定位商品块再在块内按文本模式匹配”健壮性好很多。4. 分析指标与图表映射把原始 SKU 变成可视化叙事的计算逻辑4.1 关键指标定义与计算口径数据到手后分析模块的目标是把密密麻麻的 SKU 记录提炼成有业务含义的指标。我定义了以下几组核心指标品牌分布按品牌分组统计商品数量和评论总数的占比反映各个品牌的市场声量。价格区间分布将价格划分成 0-1000、1000-2000、2000-3000、3000-5000、5000 以上五个区间统计每个区间的商品数和平均评论数。价格与口碑关系计算每个品牌的平均价格和平均评论数用散点图观察是否存在“价格越高口碑越好”的直觉误区。高性价比商品评论数高、价格低于同配置均价的商品列表这是推荐模块的重要候选集。促销力度排行用原价减去现价再除以原价计算折扣深度观察哪些品牌促销策略更激进。计算口径定了之后分析逻辑就变成一段清晰的 pandas 分组聚合代码price_disc pd.cut(df[price], bins[0, 1000, 2000, 3000, 5000, float(inf)]) summary df.groupby(price_disc).agg( product_cnt(sku_id, count), avg_price(price, mean), total_comment(comment_cnt, sum) ).reset_index()注意以“现价”作为价格字段基准而不是原价或划线价否则会出现大量商品被错误归入低价区间的失真结论。4.2 图表选型与业务含义对应图表不是随便挑一个好看的样式每种图都有它最适合回答的问题。我最终确定的图表组合如下分析问题图表类型为什么选它哪些品牌手机最多饼图 / 环形图直观呈现占比适合品牌份额对比手机价格分布在哪个区间柱状图区间统计对比清晰差异一目了然品牌价格与评论量关系散点图气泡图展示两个连续变量的相关性气泡大小映射商品数价格与折扣深度关系箱线图反映不同品牌/价格段的价格离散程度比纯均值更有说服力单品热度排行横向条形图Top10 名称较长横向排列阅读更舒服内存版本分布堆叠柱状图展示不同内存版本在各价格区间中的构成离线分析结果我在演示前都会人工扫一遍数据异常往往一眼能看出来。比如某个品牌的平均价格突然低得离谱大概率是清洗时混入了配件或二手机型回到上一步做过滤即可。5. Flask 与 pyecharts 的联动动态生成图表看板的三种写法5.1 方案一后端渲染 JSON 配置文件pyecharts 支持将图表配置导出为 JSONFlask 后端读取这个 JSON传给前端模板再由前端调用 echarts 渲染。这是我最推荐的方案因为它让后端只负责数据计算前端只负责渲染双方职责清晰。具体流程是分析脚本生成图表配置后存入文件或内存Flask 路由读取并传给模板from flask import Flask, render_template, jsonify import json app Flask(__name__) def load_chart_config(chart_name): with open(fcharts/{chart_name}.json, r, encodingutf-8) as f: return json.load(f) app.route(/) def index(): return render_template(index.html) app.route(/api/chart/brand) def brand_chart(): return jsonify(load_chart_config(brand_pie))前端模板里用 echarts 实例化!DOCTYPE html html head script srchttps://cdn.jsdelivr.net/npm/echarts5/dist/echarts.min.js/script /head body div idbrandChart stylewidth:100%;height:400px;/div script fetch(/api/chart/brand) .then(res res.json()) .then(option { const chart echarts.init(document.getElementById(brandChart)); chart.setOption(option); }); /script /body /html5.2 方案二前端异步加载增强交互图表都展示出来后交互体验是下一个需要解决的问题。我加了两个交互点点击饼图某个品牌时联动更新右侧价格区间图切换价格区间时推荐列表跟着刷新。这种联动本质上就是前端监听事件后再次向后端发起接口请求后端返回对应条件下的图表配置。联动实现不复杂但有一个后端接口设计原则接口入参不要写死接受过滤条件。app.route(/api/chart/price_dist) def price_dist(): brand request.args.get(brand, ) df load_clean_data() if brand: df df[df[brand] brand] # 按价格区间聚合 ... return jsonify(chart_option)这种参数化接口让看板从“静态展示”进化成“可交互的数据分析工具”答辩时的演示效果会明显不一样。5.3 联动细节与性能优化联动做多了会遇到一个性能问题每次切换条件都重新读全量数据导致接口响应越来越慢。我的优化办法是在 Flask 启动时加载一次数据到内存后续查询都在内存中使用 DataFrame 过滤而不是每次都从数据库读。_DATA_CACHE None def load_clean_data(): global _DATA_CACHE if _DATA_CACHE is None: _DATA_CACHE pd.read_csv(data/clean_phone_data.csv) return _DATA_CACHE这个优化对几万条数据效果非常明显接口响应从几百毫秒降到几十毫秒。演示时鼠标滑来滑去不卡顿观感完全不同。另一个细节是 echarts 的 resize 问题。浏览器窗口变化后如果图表容器尺寸变了需要调用chart.resize()否则会出现图表显示不全或空白。我在页面里加了一行监听window.addEventListener(resize, () { chart.resize(); });6. 推荐模块设计不堆算法的轻量召回排序方案6.1 用户行为冷启动问题推荐模块是很多同学想“秀肌肉”的地方但也是最容易失控的地方。一上来就写协同过滤结果用户行为数据根本没有算法成了空中楼阁。我的处理思路是先承认冷启动问题再通过一条可解释的规则链路输出推荐结果。系统里没有真实用户历史行为我把“用户偏好”设计成交互式的三个输入预算范围、倾向品牌、关键需求比如续航优先、拍照优先、性能优先。基于这三个输入推荐模块在主数据集中做召回和排序。这种交互式推荐的好处是演示起来非常直观老师问“你推荐我三千块以内买个拍照好的手机”你在系统里输入条件就能看到结果当场验证。6.2 基于商品属性相似度的召回召回阶段的核心是用商品字段构造检索条件。价格区间是最强约束先过滤掉预算范围外的商品然后根据倾向品牌做加权召回如果没有明确品牌偏好就按评论数取各价格段的口碑头部商品。召回之后做属性相似度打分。这里不需要向量化因为手机的结构化属性足够强。我定义了以下打分因子因子权重说明价格接近度0.4价格离当前筛选中心越近得分越高评论数对数0.3评论数是口碑和热度的替代指标折扣深度0.2促销力度大的商品更容易吸引用户配置完整度0.1内存、颜色等信息缺失则扣分价格接近度计算我用了归一化绝对误差分越低越好def price_score(price, target_price, max_price): diff abs(price - target_price) / max_price return max(0, 1 - diff)6.3 排序规则与可解释性推荐结果不能只是一串商品 ID系统要把“为什么推荐这个”讲清楚。我在结果列表里显示了三条推荐理由的标签价格在预算内、同价位评论数前 10、促销力度超过 30%。这种可解释性不仅提升用户体验更重要的是答辩时能清楚说明推荐逻辑避免“黑箱算法”式的尴尬提问。排序最终使用加权总分倒序但我会加一个去重约束同一品牌在同一价格区间内最多展示两个商品防止结果页被某个品牌刷屏影响多样性。def rank_products(candidates, weights): candidates[score] ( weights[price] * candidates[price_sim] weights[comment] * candidates[comment_score] weights[discount] * candidates[discount_score] ) final_list [] seen_brand {} for row in candidates.sort_values(score, ascendingFalse).itertuples(): brand row.brand if seen_brand.get(brand, 0) 2: continue final_list.append(row) seen_brand[brand] seen_brand.get(brand, 0) 1 return final_list[:10]7. 大模型 agent 与对话式分析给系统加一个“智能导购”7.1 为什么用 agent 而不是简单接口加了推荐模块后业务逻辑已经能回答预设问题但用户要的是自然语言问答。比如“1500 到 2500 之间的手机哪些牌子性价比高”这种问题如果用传统规则接口参数该怎么拆品牌、价格、性价比这三个词需要拆成结构化条件。这时候大模型 agent 就派上了用场。我想过只调用大模型接口生成 SQL 或过滤条件但发现不够灵活。更合理的方案是让大模型充当“意图理解工具调度中枢”它把用户的话翻译成系统内部可执行的函数调用然后调用我写好的查询函数再把结果组织成自然语言回答。7.2 工具调用与提示词设计实现上我参考了 agent 工具调用的常见范式。核心思路是定义几个明确的方法让大模型根据用户输入决定调用哪个方法传入什么参数。TOOLS { get_top_products: { description: 根据价格、品牌、需求获取推荐商品列表, parameters: [price_min, price_max, brand, need] }, get_brand_summary: { description: 获取某品牌的均价、平均评论数、促销力度, parameters: [brand] }, get_price_trend: { description: 获取某价格区间的商品数量与平均评论数, parameters: [price_min, price_max] } }提示词里我明确告诉大模型不要自己编造数据只能调用工具获取结果如果工具没有返回合适数据就如实说不知道。这样能很大程度避免大模型“一本正经胡说八道”的问题。7.3 实际效果与翻车教训这个模块我调试了很久最典型的翻车场景有三个大模型把品牌名理解错比如把“爱酷”当成“苹果”导致工具收到错误参数。解决办法是在工具函数里做品牌名归一化和商品数据中的品牌列表做个模糊匹配。大模型直接输出“根据分析苹果手机均价最高”之类结论但实际上它没有调用任何工具是在瞎编。解决办法是在提示词中强制规定回答路径必须包含“我调用了 XX 工具返回结果是……”。连续对话时上下文过长token 消耗严重。解决办法是只保留最近两轮对话和当前工具结果不把全量商品数据塞进上下文。agent 模块让系统的“智能化”感知非常强演示时话题性很足但要注意它依赖大模型接口网络不稳时会出现响应慢甚至超时最好准备一个降级策略。我的做法是大模型无响应时自动回退到预设的规则问答保证系统任何时候都能工作。8. 答辩演示与常见坑位从爬到可视化全链路的排错经验8.1 爬虫运行中的典型异常整个链路里爬虫环节最容易出问题我把实际遇到的典型异常和解决办法整理成了一份清单异常现象可能原因排查与修复返回 403 / 频繁跳验证页请求频率太高或请求头不完整降低频率、轮换 UA、增加延时部分商品价格解析为 0页面改版导致字段没抽取到检查当前 selector 或改用品牌搜索页兜底SQLite 数据库锁死采集和展示进程同时写入采集用独立进程展示只读避免长事务中文乱码页面编码识别错误用resp.apparent_encoding再手动指定 utf-8评论数解析报错数据中存在“暂无评论”文本解析前先判断是否为纯数字文本8.2 图表不显示或白屏的定位路径Flask 页面白屏第一反应不要查 echarts先看浏览器 Console 报错。我遇到的十次白屏里七次是接口返回的 JSON 格式问题两次是 echarts CDN 没加载成功只有一次是图表配置字段写错。定位方法非常直接在浏览器里直接访问接口地址看返回结构是否和前端期望一致。curl http://127.0.0.1:5000/api/chart/brand如果接口正常再检查前端是否获取到了数据。在setOption之前打一条console.log(option)确认 option 不是空对象这一招能过滤掉大半问题。8.3 演示前的数据量与性能准备毕设演示最怕现场翻车我总结了几条演示前必须做的准备数据量不要太大。我测试过三万条商品数据和三十万条商品数据看板响应速度有明显差别演示场景保持一万条以内最流畅。预生成图表配置。与其让用户现场等待爬虫运行不如提前把图表配置生成好演示时直接展示需要增量更新时再现场跑一小段。准备一个“故障预案包”。把常用异常和处理命令写在一个 README 里万一现场报错按文档顺序排查比现场翻代码靠谱得多。所有第三方资源用本地文件。echarts 的 JS 库不要依赖线上 CDN演示场地网络不可控提前下载到本地 static 目录更稳妥。把大模型 agent 的接口 key 写进本地配置文件不要硬编码到源码里避免源码打包或上传后被泄露。这个细节虽然小但在答辩场景下被问到安全问题时反而很加分。整个项目做完我最深的体会是这套系统的价值不在单个模块的技术难度而在于它把数据全流程串成了一个完整产品每一层都有产出物每一层都能应对追问。你如果也想在这个选题上打磨建议不要停留在把源码跑通而是亲手把每一个模块的边界、异常和优化点都过一遍答辩时你会发现自己心里特别有底。