企业官网建设流程全解析

“基于deepseek做美食数据分析”这个方向，我去年下半年就开始折腾了。当时手头正好有携程旅行美食频道的数据源可挖，加上DeepSeek的API价格确实诱人，就搭了这么一套系统：爬虫抓数据、pandas做清洗、Django出接口、ECharts画大屏，最后再用DeepSeek做自然语言问答。整套流程跑下来，我发现最大的价值反而不是模型本身多聪明，而是“数据管道”这条链路怎么把噪音变成资产。这篇就把整个系统的架构、关键代码、踩坑实录全部摊开讲，想复刻的朋友可以直接抄作业。

1. 项目整体设计与技术选型思路

1.1 这个系统到底解决什么问题

美食数据分析其实是个非常典型的“数据全链路”场景：原始数据散落在点评网站、攻略平台、外卖App里，格式五花八门，字段严重不统一，有的店铺评分字段缺失，有的地址栏塞了一整段废话，更有大量重复数据需要去重。如果靠人工收集整理，一个城市的餐厅数据就能让人崩溃。这套系统的目标就是：自动抓取携程美食频道的公开数据，经过清洗、标准化、指标计算后，存入数据库，然后通过Django提供API接口，前端用ECharts渲染可视化大屏，最后再叠加DeepSeek的问答能力，让非技术人员也能用自然语言直接查“哪家川菜馆评分最高”这类问题。

适合谁参考？想入门爬虫的Python新手、正在做毕业设计的数据类专业学生、需要搭建数据分析展示平台的后端开发者，都可以从这套架构里找到自己需要的那一环。即使你完全不用DeepSeek，只把前四层（爬虫、清洗、存储、可视化）做完，本身也已经是一个完整度很高的数据项目了。

1.2 为什么选这套技术栈而不是别的

选型这件事，我一贯的原则是“团队熟练度优先，其次才是技术先进性”。这套系统里每个组件都不是最新的，但组合在一起非常顺手。

• Django是Python系最成熟的全栈框架，自带Admin后台、ORM、认证体系，做数据分析平台的数据管理后台几乎不用额外写代码。
• 爬虫用requests+xpath，不用Scrapy的原因是这个项目规模没那么大，单机、单线程、可控频率的抓取就够了，Scrapy的学习成本和配置成本反而有点重。
• 存储用MySQL，因为数据量级在几十万条这个水平，MySQL完全扛得住，而且周边工具链（Navicat、MySQL Workbench）成熟，排查问题方便。
• 可视化用ECharts，这个没什么悬念，国内数据可视化项目的默认选项，图表类型全、交互体验好、文档是中文的。
• DeepSeek放在最上层做“自然语言查询接口”，用它的API把用户问题转成结构化查询条件，再回查数据库，最后把结果生成一段人话解读。

对比一下其他方案：如果用Flask替代Django，开发灵活度更高但Admin后台要自己写；如果用MongoDB替代MySQL，文档型存储对爬虫数据的适应性更强，但和Django ORM的配合不如关系型数据库顺手；如果可视化换成DataV，大屏效果更炫但定制能力不如ECharts。我最后选了现在这套组合，核心原因就是一个字——稳。

2. 数据采集层：携程美食爬虫的完整实现

2.1 爬虫架构和requests会话保持

携程美食频道的页面结构属于典型的“服务端渲染+局部Ajax刷新”混合模式，目录页列表是直接渲染在HTML里的，但分页数据是通过接口异步加载的。我写爬虫的第一步不是急着写代码，而是打开浏览器开发者工具，把关键的请求URL和响应结构摸清楚。

爬虫框架我用了requests.Session，这样能自动保持Cookie和Headers状态。Session对象在同一个会话里多次请求时，会复用底层的TCP连接，效率比每次新建requests.get高不少，也更不容易触发服务器的频率限制。代码层面，核心是构造一个带User-Agent、Referer等常规头的请求头字典，再把需要登录才可见的Cookie手动塞进去。

import requests import time import random from lxml import html HEADERS = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36", "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8", "Accept-Language": "zh-CN,zh;q=0.9,en;q=0.8", } session = requests.Session() session.headers.update(HEADERS) BASE_URL = "https://you.ctrip.com/food/shanghai" resp = session.get(BASE_URL, timeout=10) print(resp.status_code, len(resp.text))

这里有个细节很多人会忽略：session.headers.update(HEADERS)之后，这个Session发出去的每一个请求都会带上这些头，不需要每次单独传。如果你用的是普通函数级的requests.get，每次都要重复传headers，代码冗余不说，还容易漏掉某个关键字段。

2.2 XPath解析与text()函数的坑

页面拿到之后，用lxml的etree.HTML把HTML字符串解析成Element对象，然后用XPath定位目标节点。携程美食列表页的每个店铺卡片通常包括：店铺名、星级评分、点评数、人均消费、菜系分类、地址、经度纬度（部分页面有）、推荐菜标签。

这里必须强调XPath中text()函数的用法，这是我调试时间最长的点之一。比如要提取店铺名称，典型的写法是//div[@class='hotel_info']/dt/a/text()，但如果目标标签内部还嵌套了其他子标签（比如<a>里有<span>），直接取text()会返回None，因为<a>的“直接文本节点”是空的，文本全在<span>里。

遇到这种情况，有两个处理方式。第一是用string()函数，把整个标签内部的文本拼接起来；第二是改用.//text()然后手动拼接。我在项目里写了一个通用的提取函数：

def extract_text(element, xpath_expr): """用text()取不到时自动fallback到string()""" nodes = element.xpath(xpath_expr) if not nodes: return "" # 如果命中第一个节点本身 first = nodes[0] if isinstance(first, str): return first.strip() return "".join(first.itertext()).strip()

这个函数的好处是兼容两种情形：XPath表达式末尾带/text()时，节点列表里是字符串；不带/text()时，节点列表里是Element对象，用itertext()把所有后代文本节点拼起来。实测下来，对携程这类嵌套层级比较深的美食列表页，一次性正确率提高了非常多。

2.3 断点续爬与异常重试机制

爬虫跑一两个小时不出问题是偶然，出问题才是常态。网络超时、IP临时被封、页面结构改版、被对方服务器返回403，这些都是家常便饭。我写的爬虫必须有三个保命机制：

第一，请求失败自动重试，最多重试3次，每次间隔呈指数退避（第一次等2秒，第二次等4秒，第三次等8秒）。第二，每抓取一个城市就即时写入数据库和本地JSON文件，防止内存里的数据因为进程崩溃全丢。第三，记录已抓取的城市列表和每座城市的当前页码，下次启动时从断点继续。

def fetch_with_retry(url, max_retries=3): for attempt in range(max_retries): try: resp = session.get(url, timeout=10) if resp.status_code == 200: return resp elif resp.status_code == 403: print("触发反爬，等待更长时间") time.sleep(30) else: print(f"HTTP {resp.status_code}，重试第{attempt+1}次") except requests.RequestException as e: print(f"请求异常: {e}") time.sleep(2 ** attempt + random.uniform(1, 3)) return None

2.4 爬虫合规与反爬应对

关于爬虫合规，我在这里多说几句。这套系统面向的是公开数据采集，采集频率被刻意控制在很低的水准——每次请求后sleep 1到3秒随机延迟，单城市采集完成后自动暂停30秒，绝不并发轰炸。携程这类平台的页面结构会不定期改版，所以爬虫代码里XPath选择器全部集中在配置文件中，改版时只改配置不碰逻辑代码。

提示：做技术分享和项目展示时，尽量选择公开的、非登录态可访问的数据进行爬取，并且控制抓取频率。任何绕过登录、破解验证码的行为都不可取，不仅容易吃官司，也背离了学习技术的初衷。

3. 数据清洗与指标建模

3.1 原始数据有哪些脏问题

爬虫只是拿到了“原料”，真正决定分析质量的是清洗环节。我第一版爬完数据直接丢进数据库，结果发现一堆问题：评分字段有的是“4.5分”这种带文字后缀的字符串，有的是“4.5/5分”这种双数字格式；人均消费有“¥128/人”、“人均128元”、“128”三种写法；地址字段里混入了电话区号“上海南京东路288号 021-63248888”；菜系标签有的叫“本帮菜（苏帮菜）”，有的叫“本帮菜|苏帮菜”……

清洗策略我分为三层：格式统一、字段拆分、数据纠偏。

格式统一主要是正则替换，把“人均¥128/人”、“人均128元”、“128/人”都归一化成纯数字人均 = 128。字段拆分解决的是“菜品标签”这类多值字段，把本帮菜|苏帮菜按分隔符拆成列表。数据纠偏是处理异常值，比如负数的点评数、超过5000元的人均消费（这种大概率是录入错误或者高端餐厅里的特殊情况），这些值不能直接删，但需要在指标计算时单独处理。

import re import pandas as pd def clean_price(raw_text): """把各种人均消费文本清洗成float""" if not raw_text: return None text = str(raw_text) nums = re.findall(r"\d+\.?\d*", text) if not nums: return None return float(nums[0]) def clean_rating(raw_text): """清洗评分字段，提取第一个浮点数""" if not raw_text: return None text = str(raw_text) m = re.search(r"(\d+\.?\d*)", text) return float(m.group(1)) if m else None

3.2 核心指标怎么设计

清洗完之后，单纯展示“评分最高的餐厅Top10”太单薄了，我需要设计几个有业务含义的衍生指标，让大屏和问答都能讲出有价值的信息。

• 热度指数：热度 = log2(点评数 + 1) * 0.7 + 评分 * 0.3，这个公式的意思是：点评数每翻一倍热度指数增加0.7分，评分作为修正项。用对数是为了压制头部效应，避免几个超级连锁店的点评数把所有中小店铺都压得看不见。
• 性价比评分：性价比 = 评分 / log2(人均 + 1)，之所以加log，是因为人均消费从100涨到200和从500涨到600，消费者的敏感度完全不同，用log能更好反映这种边际递减的感知。
• 菜系竞争强度：某个菜系在同一个城市的店铺数量/总店铺数，这个指标反映的是供给侧的饱和度，对判断“开一家什么类型的餐厅更容易跑出来”很有参考价值。

这些指标不是凭空拍脑袋定的，而是参考了大众点评和携程的推荐算法公开资料，再用实际数据做了反复验证——比如用热度指数排序出来的Top10，和手动翻阅点评结果基本一致，说明这个加权公式是合理的。

3.3 分城市存储与去重策略

同一个餐厅可能在多个页面重复出现，也可能在不同城市有分店。我在MySQL里建了两张核心表：一张是restaurant店铺主表，用(城市, 店铺名, 地址)三个字段联合判断唯一性；另一张是restaurant_history历史快照表，保留每次抓取的数据全量，方便后续做“评分涨跌”分析。

CREATE TABLE restaurant ( id INT PRIMARY KEY AUTO_INCREMENT, city VARCHAR(50), name VARCHAR(200), address VARCHAR(500), rating DECIMAL(3,2), review_count INT, avg_price DECIMAL(10,2), cuisine VARCHAR(200), latitude DECIMAL(10,6), longitude DECIMAL(10,6), heat_index DECIMAL(6,4), cost_performance_index DECIMAL(6,4), crawl_time DATETIME, UNIQUE KEY uniq_city_name_addr (city, name, address(191)) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

注意address字段我加了长度为191的前缀索引，因为utf8mb4字符集下，索引字段最大长度是191字符。如果不截断，建立唯一索引时会报“Specified key was too long”错误。这个坑我印象太深了，第一版建表死活建不上，查了半天才知道是索引长度超了。

4. Django后端与DeepSeek智能问答

4.1 Django项目怎么组织

Django项目的组织方式，我建议按功能拆分App，而不是全塞在models.py里。这个项目我拆了三个App：crawler_app管爬虫任务的调度和记录，analysis_app管指标计算和筛选查询，api_app管REST接口和可视化数据输出。多App的坏处是文件数量变多，但好处是代码边界清晰，后期加功能不会牵一发而动全身。

关键配置里有几个点值得注意：DATABASES配置MySQL连接时，OPTIONS里要加"charset": "utf8mb4"，否则写入带emoji的店名会报错；CACHES配置Redis作为缓存后端，热点查询（比如首页Top10榜单）直接走Redis，不给MySQL加负担；REST_FRAMEWORK里配置默认分页类，避免接口一次性返回几千条数据。

4.2 DeepSeek API接入封装

DeepSeek的API接口跟OpenAI格式高度兼容，所以接入逻辑不需要额外装SDK，直接用requests调用就行。我封了一层DeepSeekClient，职责很单一：把用户的问题加上系统提示词，发到DeepSeek的chat/completions接口，返回结果。

核心在做提示词工程。我试过好几版提示词，最后稳定下来的是这种模式：

DEEPSEEK_SYSTEM_PROMPT = """ 你是美食数据分析助手。你只能使用以下数据表进行查询： - restaurant(城市city, 店名name, 评分rating, 点评数review_count, 人均avg_price, 菜系cuisine, 热度heat_index) 规则： 1. 判断用户问题是否涉及数据查询，如果不涉及，就直接回答。 2. 如果涉及数据查询，先输出一个JSON格式的查询计划： {"query": {"city": "上海", "cuisine": "川菜", "min_rating": 4.5, "limit": 10, "order_by": "heat_index"}} 3. 然后等待工具返回结果，再用自然语言回答。 """

为什么提示词里不直接教模型写SQL？因为真实环境里表结构复杂（有多个Join关系），直接生成SQL容易出错，一旦模型把字段名写错，查出来的就是空结果。我的做法是把查询空间收敛到几个常用维度（城市、菜系、评分下限、排序方式），让模型做的是“条件抽取”而不是“SQL生成”，准确性一下子就上来了。

def call_deepseek(user_query): payload = { "model": "deepseek-chat", "messages": [ {"role": "system", "content": DEEPSEEK_SYSTEM_PROMPT}, {"role": "user", "content": user_query} ], "temperature": 0.1, "response_format": {"type": "json_object"} } resp = requests.post( "https://api.deepseek.com/chat/completions", headers={"Authorization": f"Bearer {DEEPSEEK_API_KEY}"}, json=payload, timeout=30 ) data = resp.json() return data["choices"][0]["message"]["content"]

4.3 数据指标计算与筛选接口实现

DeepSeek返回的JSON查询计划会被解析成一个字典，之后就是普通的数据库ORM查询了。这里我的经验是：不要直接用ORM的filter(city=city, cuisine=cuisine)这种硬编码方式，而是动态构造QuerySet，这样新增筛选条件时不需要改视图函数。

from django.db.models import Q def search_restaurants(params: dict): qs = Restaurant.objects.all() if params.get("city"): qs = qs.filter(city=params["city"]) if params.get("cuisine"): qs = qs.filter(cuisine__icontains=params["cuisine"]) if params.get("min_rating"): qs = qs.filter(rating__gte=params["min_rating"]) if params.get("max_price"): qs = qs.filter(avg_price__lte=params["max_price"]) order_field = params.get("order_by", "heat_index") if order_field in ("heat_index", "cost_performance_index", "review_count"): qs = qs.order_by("-" + order_field) return qs[: params.get("limit", 10)]

动态构建QuerySet的写法比逐个判断后拼接字符串SQL干净得多，而且Django的ORM QuerySet是惰性的，只有真正执行时才触达数据库，性能上也没问题。排序字段这里有个安全细节：只允许白名单内的字段排序，否则用户传入任意字段名会导致程序报错，甚至可能通过排序字段探测到非预期字段。

4.4 自然语言问答的完整链路

整个问答链路的顺序是这样的：用户在前端输入“上海最火的川菜馆是哪家”→调用DeepSeek接口→DeepSeek返回JSON查询计划→解析后查询MySQL→把查询结果拼接成上下文再次发给DeepSeek→DeepSeek生成最终的自然语言回答→前端在聊天窗口渲染。

第二个请求才是真正的“分析对话”，它拿到了真实数据，比如“根据热度指数排序，上海最火的川菜馆是XX，人均XX元，有XX条点评”。没有这一步，模型就只能凭常识胡编，而有了数据兜底，回答就变成了“基于事实的解读”。

这两次调用的成本我算过，每轮问答大约消耗几百个token，按DeepSeek目前的价格几乎可以忽略不计。这也是我选它而不是其他闭源模型的原因之一——成本是真的低。

5. 可视化大屏与前端展示

5.1 大屏技术方案对比与选型

可视化大屏的实现方案我对比过好几种：直接用ECharts裸写；用DataV组件库包一层；用Vue+ECharts封装成可拖拽布局的低代码方案。最后选的是Vue3 + ECharts + 自研的栅格布局。原因很简单：ECharts的图表类型最全，热力图、地图、雷达图、关系图都有；Vue3的组合式API写起来比Vue2舒服不少；而自研网格布局只写了一遍，后面所有页面的组件摆放都复用了。

如果你不想碰前端框架，也不想用Vue，那也有更轻量的办法：写一个纯HTML页面，用CSS Grid做栅格定位，ECharts的init方法按ID初始化图表，数据通过Django的模板变量直接注入。缺点是页面动态性差，但做静态展示是大屏足够用了。

5.2 大屏核心图表的配置要点

大屏我放了六个图表模块：城市美食评分Top10横向条形图、菜系热度雷达图、人均消费区间分布直方图、热门商圈地图标记点、评分与人均散点图、城市美食关键词词云。每个图表虽然看起来不一样，但配置逻辑高度相似——都是先fetchDjango接口拿数据，再对ECharts的option做组装。

这里示范一下热力地图的ECharts配置，这个最麻烦但也最出效果：

import * as echarts from 'echarts'; import chinaMap from '@/assets/china.json'; echarts.registerMap('china', chinaMap); const chart = echarts.init(document.getElementById('mapChart')); // cityHeatList 形如 [{name: '上海', value: 152}, {name: '广州', value: 110}] const option = { tooltip: { trigger: 'item', formatter: (params) => `${params.name}<br/>热度指数: ${params.value}` }, visualMap: { min: 0, max: 200, inRange: { color: ['#e0f3f8', '#abd9e9', '#74add1', '#4575b4', '#313695'] }, text: ['高', '低'], calculable: true }, series: [{ name: '美食热度', type: 'map', map: 'china', roam: true, label: { show: true, fontSize: 10 }, data: cityHeatList }] }; chart.setOption(option);

注意visualMap的max值一定要根据实际数据动态调整，如果你写死200，但最大城市热度只有80，整个地图的颜色就会全部偏向低色档，大屏效果非常糟糕。我的做法是在后端接口里同时返回max_heat字段，前端动态设置visualMap的max。

5.3 前后端接口设计与数据格式约定

大屏和Django后端之间通信，我用的是纯JSON接口，没有用Django REST Framework的ModelViewSet，而是手写了几个简单的视图函数返回JsonResponse。原因很简单：可视化大屏需要的接口都是只读查询，不需要CRUD全套功能，手写五个视图函数比配置Serializer简单直接。

接口返回的数据格式，我统一约定为这种嵌套结构：

def city_ranking(request): city = request.GET.get("city", "上海") data = list( Restaurant.objects.filter(city=city) .order_by("-heat_index")[:10] .values("name", "rating", "review_count", "avg_price", "heat_index") ) return JsonResponse({ "code": 0, "data": data, "max_heat": max(item["heat_index"] for item in data) if data else 0 })

后端返回的字段名直接就是前端图表要用的字段名，没有做二次转换。这种“后端迁就前端”的做法在正经开发里不够规范，但在个人项目和大屏demo里非常实用——少一层数据映射，就少一类bug。

6. 部署上线与性能优化

6.1 Django + uWSGI + Nginx 部署

开发环境里跑runserver怎么都爽，但部署到服务器上必须换正式方案。我的部署组合是：Nginx做反向代理和静态文件服务，uWSGI启动Django应用，MySQL和Redis跑在本机或局域网内。

Nginx的关键配置有两点：第一，proxy_pass把请求转发给uWSGI的Unix Socket，比转发到TCP端口性能更好；第二，静态文件和上传资源的location要单独配置，不要让Django处理静态请求，否则并发一上来CPU立刻打满。

server { listen 80; server_name your-domain.com; location /static/ { alias /opt/food_project/staticfiles/; } location /media/ { alias /opt/food_project/media/; } location / { include uwsgi_params; uwsgi_pass unix:/tmp/food_project.sock; uwsgi_read_timeout 60; } }

uWSGI进程数怎么配也有讲究。我最初照着默认配置起了8个进程，结果MySQL连接数报警。后来改成：CPU核心数×2+1个进程，每个进程配一个线程，同时把MySQL的最大连接数调大。爬虫单独跑的时候，Django应用完全不参与，两者互不干扰。

6.2 常见问题排查速查表

把调试期间遇到的高频问题整理成一张速查表，方便直接对着查：

6.3 性能优化：Redis缓存与数据库索引

对这套系统来说，最大的性能瓶颈在可视化大屏。大屏每次自动刷新拉接口，如果全部实时查询MySQL，压力很大。我的方案是：几乎只读的接口全部走Redis缓存，缓存时间设成300秒。Django的cache_page装饰器可以很方便地把视图函数的结果缓存起来：

from django.views.decorators.cache import cache_page @cache_page(60 * 5) # 缓存5分钟 def city_ranking(request): # 查询逻辑 pass

数据库索引方面，restaurant表有两个高频查询字段——city和cuisine，我给它们加了联合索引。注意不要给每个字段都加索引，插入数据时索引维护的成本反而会让写入变慢。我实测过，加了联合索引后，城市+菜系筛选的查询时间从300毫秒降到了30毫秒左右，效果非常明显。

7. 踩坑实录：那些没写在官方文档里的经验

7.1 爬虫采集频率与封IP的平衡

最开始我太心急，把sleep从1秒调到了0.2秒，结果抓到第200条的时候对方服务器直接返回了403。这种封禁一般是短时间的，等30分钟就能恢复，但如果你继续用同一个IP高强度请求，可能被封几个小时甚至一天。

我后来学到的经验是：做这种学习型爬虫项目，最保险的节奏是“单线程 + 每请求1-2秒随机延迟 + 每小时不超过1000个请求”。这不是什么高深的技巧，但能把封禁概率降到非常低。如果你的爬虫目标站点对反爬有严格限制，一律优先使用站方提供的开放API，没有开放API就放弃该数据源，换一个公开数据集。

7.2 DeepSeek提示词的“话术陷阱”

我调试DeepSeek问答时发现一个有意思的现象：直接问“上海评分最高的餐厅”它会给一个大概是常识范围内的回答；但如果把评分数据先抓出来，再告诉模型“数据里显示XX有4.8分，35条点评”，模型的回答就开始出现“这家店虽然评分很高但点评数不多，建议综合考虑”这种理性的判断。

这说明了大模型在数据问答场景里的正确打开方式：不是让模型直接输出答案，而是让模型“基于给定数据做解读”。所以我在系统提示词里写死了一条规则：“只能基于提供的数据分析，不要使用训练数据中的常识推测具体店铺信息”。加了这条之后，回答质量提升非常明显。

7.3 可视化大屏的栅格布局与分辨率适配

大屏最容易被吐槽的点是分辨率。我最初按1920×1080设计，结果在1366×768的笔记本上打开，底部一排卡片被截断了一半。后来总结出的最佳实践是：栅格布局的单位全部用百分比和vw/vh，不要用固定像素；每个图表的容器高度用calc(100vh - 60px)这种动态计算。

还有图表里的字号问题。大屏常见的场景是远处投屏观看，字号不能太小，我全部图表的最小字号都设为12px，标题统一20px+。ECharts的textStyle配置里fontSize是直接作用在图表上的，按这个思路调完，投影效果好了很多。

7.4 从单机到“大数据”的认知重构

题目里带了“大数据”三个字，但实际这套系统的数据量级只有几十万条。我觉得有必要说清楚：这个项目里的“大数据”指的是“大数据处理流程”——从采集、清洗、存储、分析到可视化的完整链路，而不是Hadoop/Spark那套分布式生态。如果你想学真正的分布式数据处理，可以先把这套单机流程跑通，理解数据在每个环节的形态变化，再去学Spark、Flink会是事半功倍的效果。

如果后续数据量真的涨到千万级，升级路径也非常清晰：MySQL单表拆分为分库分表，或者直接迁移到ClickHouse做列式存储；爬虫改成Scrapy+Redis分布式调度；Django接口全部加上Redis缓存；分析层引入Presto或Spark SQL。架构演进的方向是现成的，缺的是你把小规模跑通后的工程能力。

8. 聊聊实测效果与经验教训

整套系统跑了大概一个月之后，我对这个项目的认知有了些变化。最大的收获其实不是代码写了多少行，而是真正理解了“数据管道”这个东西——从网页上一个一个的汉字和数字，到数据库里结构化的一条记录，再到指标计算后的业务洞察，最后到大屏上的图表和问答里的自然语言，每一层都在做“降噪”和“升维”。

有几个经验想特别分享给后来者。第一，先做最小闭环再做扩展。我第一次做的时候想七层架构一次到位，结果哪层都没做好。后来改成“爬虫+SQL+一张Excel图”的最小闭环，跑通后一层一层往上加，效率反而高得多。第二，数据质量永远比模型参数重要。DeepSeek再聪明，你喂给它的数据是错的，回答必然是错的。我花在清洗数据上的时间，是整个项目里最多的。第三，可视化大屏的价值不在炫技，而在于让数据能被直观地“读懂”。好的大屏不需要华丽特效，重点是信息层级清晰、关键指标突出。

这个项目后续可以扩展的方向也很多：接入外卖平台数据做商圈竞品分析，增加时间序列数据做评分趋势预测，把问答能力扩展到语音交互，甚至可以把整套系统打包成Docker镜像发布到GitHub。但不管往哪个方向走，底层的这套“爬虫-清洗-存储-分析-可视化-AI对话”架构都完全不用重写。

如果你按这篇博文把项目搭出来了，卡在哪一步欢迎随时来交流。我自己踩过的坑绝对比你多，早期光是在XPath的text()函数上就折腾了整整一下午——有些知识，只有亲自踩过才知道疼。