企业官网建设流程全解析

每年毕业季都有大量同学选“Python + 大数据 + 推荐系统”这类题目，说实话这类项目在网上不缺源码，但大多数都是概念化的Demo，跑起来不是缺数据就是逻辑断层。这个“python基于大数据的新闻分析推荐系统”的项目标题看着很常规，实际做下来会发现它就像一个技术大杂烩：数据采集、清洗、文本分析、推荐算法、可视化展示，每一个环节都能单独拆成一门课。这篇内容我把这个项目从零到尾拆开讲清楚，包括技术选型、架构分层、核心算法怎么落地、以及那些教程里不会写的坑，准备做毕业设计或者想入门推荐系统的朋友可以直接照参考。

它的核心作用就两个：第一，把杂乱无章的新闻文本整理成结构化数据，分析出热点、分类、情感倾向这些有价值的信息；第二，根据用户的历史阅读行为推荐个性化新闻，解决新闻平台“千人一面”的痛点。无论你是刚学完Python基础、想找一个完整实战项目的初学者，还是正在选毕业设计题目的学生，这个项目都可以当作一条很好的主线和练手场地。

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

1.1 系统到底要解决什么问题

很多人在看到“新闻分析推荐系统”这个标题时，最容易犯的毛病是把核心精力全放在“推荐算法”上，一上来就研究什么深度兴趣网络、Graph Embedding，结果数据管道没搭好，算法再好也是无米之炊。实际做下来你会发现，这个系统的第一难点在数据，第二难点在分析，最后才是推荐。

先明确需求：新闻平台每天会产生海量内容，用户不可能把所有新闻都读完，所以系统要做的首先是“分析”新闻——比如自动把新闻分类为科技、财经、体育、娱乐等主题，统计热点关键词的波动趋势，判断新闻情感是正向还是负向；然后才是“推荐”——根据用户的历史点击行为，找到用户可能感兴趣的新闻推给他。

生活化一点讲，这个系统就像一个越来越懂你的老编辑：刚开始他手里没你的任何资料，只能把最热门的新闻推给你（热度推荐）；看了几次你点击了哪些内容之后，他摸清了你的兴趣方向（基于内容的推荐）；再往后，他发现和你口味相似的一群人都关注了某类新闻，于是也推给你（协同过滤推荐）。这个演进过程其实就是整个推荐系统最经典的三层递进结构。

1.2 架构分层与技术选型策略

这个项目最忌讳的就是一开始就上重型架构。很多教程喜欢把系统画成五六台机器的集群图，Hadoop、Spark、Kafka、Flink一字排开，看起来非常唬人，但真到你实际部署时，光环境搭建就能劝退一半人。我的建议是遵循“能单机跑通，再向集群平滑演进”的思路。

我自己采用的架构是这样四层：

• 数据采集层：用Scrapy框架加requests库定时抓取新闻，把标题、正文、发布时间、来源、分类等字段落入MySQL。
• 数据存储层：MySQL作为业务库，Hive作为离线分析的数据仓库，适合对历史数据进行批量统计。
• 数据分析层：单机量级的统计用Pandas处理，数据量大或者需要演示大数据能力时，切换到Spark SQL跑同样的逻辑。
• 推荐与展示层：推荐引擎输出候选新闻列表，Flask提供Restful API接口，前端用ECharts做可视化面板。

这套选型背后有一个很实际的逻辑：Pandas处理百万行以内的DataFrame非常舒服，代码写起来又短又直观；而当数据量真正上了一定规模，同样的清洗和统计逻辑用Spark SQL只改几个函数名就能迁移过去。先保证项目完整性，再考虑规模扩展，是这类综合项目最稳的推进策略。

用户行为数据则统一记录到一张MySQL表，字段包括用户ID、新闻ID、行为类型（点击、点赞、收藏）、行为时间。推荐系统每次计算时就从这个表里拉取最近一段时间的行为记录，实时更新推荐结果。

2. 新闻数据采集与清洗：一篇新闻是如何变成结构化数据的

2.1 新闻源选择和字段规格设计

采集新闻之前最重要的不是写代码，而是先确定数据源和数据结构。我在实际项目中选了三个新闻网站的不同频道作为采集对象，覆盖科技、财经、体育、娱乐四类内容，采集字段统一设计成下面这张表的结构：

用URL的MD5作为news_id是一种很实用的小技巧，因为同一个网站同一篇文章的URL是固定的，MD5结果天然去重，比自增ID更可靠。采集时还要记录publish_time和crawl_time两个时间，后面做热点趋势分析时，publish_time决定新闻归属的时间窗口，crawl_time用来监控采集延迟。

2.2 爬虫实现与请求频率控制

我第一版的采集器用的是requests加BeautifulSoup，因为目标网站结构简单，直连解析即可。后续发现要维护多个站点的解析规则，代码越写越乱，就升级到了Scrapy框架，用Spider分离不同的解析逻辑。

下面是requests版采集器的核心代码结构：

import requests from bs4 import BeautifulSoup headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36", "Accept": "text/html,application/xhtml+xml", "Accept-Language": "zh-CN,zh;q=0.9", } def fetch_news_list(url): resp = requests.get(url, headers=headers, timeout=10) resp.encoding = "utf-8" soup = BeautifulSoup(resp.text, "lxml") news_items = [] for item in soup.select(".news-item a"): title = item.get_text().strip() link = item.get("href") if title and link.startswith("http"): news_items.append({"title": title, "url": link}) return news_items

这里需要重点说明两个容易踩坑的点。一是编码问题，国内新闻站大部分是UTF-8，但也有部分老站是GBK或GB2312，写采集器时一定要先检查页面编码，resp.encoding设置错了轻则乱码，重则整篇正文解析失败。二是请求频率，建议每次请求之间至少sleep 1秒到3秒，不要对目标站点发起高并发采集，一方面是不给对方服务器制造压力，另一方面也是对自己IP负责，采集就走正道、控制频率，这本身就是工程上的最佳实践。

爬虫写完后还有一个很必要的步骤叫“解析校验”。新闻网站的页面结构经常改版，今天能抓到的标签明天可能就失效了。我的做法是把每次采集的HTML页面落一份到本地，同时在日志里记录成功解析的条目数和失败数，一旦异常波动就说明页面结构变了，需要及时调整解析规则。

2.3 数据清洗与Hive/Spark清洗实操

采集下来的数据是“脏”的，不能直接进入分析环节。清洗主要解决四类问题：正文中包含HTML标签和广告噪声、发布时间格式不统一、部分字段缺失、以及同一新闻重复出现。

先用Pandas做一套快速清洗，代码如下：

import pandas as pd import re def clean_content(text): if not isinstance(text, str): return "" text = re.sub(r"<[^>]+>", "", text) # 去HTML标签 text = re.sub(r"\s+", " ", text) # 合并空白 text = re.sub(r"（.*?）", "", text) # 去括号内容 return text.strip() df = pd.read_csv("news_raw.csv") df["content_clean"] = df["content"].apply(clean_content) df = df.dropna(subset=["title", "content_clean"]) df["publish_time"] = pd.to_datetime(df["publish_time"], errors="coerce") df = df.drop_duplicates(subset=["news_id"])

这一段看着简单，里面有两个细节值得展开。第一，re.sub去括号内容所采用的规则要谨慎，新闻正文经常有“记者讯（本报记者XXX）”这种信息，去括号可以去掉很多冗余，但如果正文里有很多正常的括号内容，这个规则就过于暴力。我的处理方式是只去掉以数字、地址、来源信息开头的括号，而不是无差别清除。第二，drop_duplicates用news_id，但实际新闻站之间会互相转载，同一篇文章可能标题一模一样却来自不同站点，这时候news_id不同就漏掉了。所以我还会加一遍标题相似去重，用编辑距离或SimHash摘要比对，对重复转载做二次过滤。

当数据规模上升到百万级之后，Pandas的清洗逻辑就可以平滑切换到Spark SQL。同样逻辑的Hive SQL长这样：

INSERT OVERWRITE TABLE news_clean SELECT news_id, title, regexp_replace(content, '<[^>]+>', '') AS content_clean, category, source, CAST(publish_time AS TIMESTAMP) AS publish_time FROM news_raw WHERE title IS NOT NULL AND length(trim(content)) > 50 GROUP BY news_id, title, category, source, publish_time;

这里用length(trim(content)) > 50作为过滤条件，是因为真正的新闻正文至少应该在几十个字以上，很多采集噪声其实是短的列表页摘要。这个阈值不是拍脑袋定的，我统计过三万多条样本的正文长度分布，发现小于50字的正文基本都无法用于后续分词和关键词提取。

3. 新闻内容分析与特征提取：从文本里挖出信息

3.1 分词、停用词与TF-IDF关键词提取

分析新闻文本，第一步是做中文分词。中文不像英文有天然空格分隔，必须用分词工具拆成词语序列。目前最实用的就是jieba分词，代码量小、准确率可以接受，加载专业词典后还能提升科技、财经词汇的切分效果。

import jieba import jieba.analyse jieba.load_userdict("user_dict.txt") # 自定义领域词典 content = df["content_clean"].iloc[0] seg_list = jieba.lcut(content) print(seg_list[:20]) # 使用TF-IDF算法提取关键词 keywords = jieba.analyse.extract_tags(content, topK=10, withWeight=True) for word, weight in keywords: print(word, weight)

停用词列表是必然要做的一步。“新闻”“记者”“报道”“今天”“我们”这类词出现频率极高，但对区分新闻主题没有任何帮助。我收集了一个包含1200个中文常用停用词的列表，分词后过滤停用词再进入下一步统计。这里要说一个很实际的经验：过滤停用词的顺序非常重要，一定要先分词再过滤，而不是先按停用词切分文本，否则会把“现代”切成“现”和“代”，直接把词义干掉了。

TF-IDF算法本身也很值得补一句：TF（词频）衡量词在本篇新闻中的重要程度，IDF（逆文档频率）衡量词在全语料中的区分度。某个词如果一个小时内出现在几百篇新闻里，它的IDF值就会很低，说明它已经成了大众词而不是特色词。jieba.analyse.extract_tags内部封装的就是这套逻辑，用起来很简单，但理解原理能帮你判断提取结果是否合理。

3.2 新闻分类与主题聚类实战

分类是推荐的基石。如果一条新闻连属于科技还是娱乐都不知道，推荐系统就只能瞎猜。分类我的方案是两层：第一层是基于配置词表的规则分类，第二层是基于TF-IDF加KMeans的聚类自动补全。

规则分类逻辑很直白，我准备了一份每类50个关键词的词典，例如“芯片”“算法”“人工智能”归到科技，“股市”“基金”“银行”归到财经，“进球”“联赛”“球员”归到体育。匹配到哪个分类词多就归到哪类。这份词典来自对历史数据的统计筛选，不是拍脑袋写的。

规则分类的优点是可解释性强，但覆盖不全，长尾新闻往往匹配不到任何分类。这时候就用聚类模型做兜底。

from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.cluster import KMeans corpus = df["content_clean"].tolist() vectorizer = TfidfVectorizer(max_features=5000, stop_words="zh") X = vectorizer.fit_transform(corpus) kmeans = KMeans(n_clusters=4, random_state=42) df["cluster"] = kmeans.fit_predict(X)

每篇文章变成一个5000维的稀疏向量，KMeans聚类成4簇。聚类完成后不能直接拿簇编号当分类名，还需要人工查看每簇的高权重词，给簇打上语义标签。举个例子：某一簇最高的几个词是“股票”“涨幅”“基金”“市场”，那基本可以认定这簇对应财经类。这一步本质上是用无监督方法做预标注，再交给人工审核确认。

使用LDA主题模型还可以挖掘更深层的主题结构，比如把“科技”进一步拆分成“芯片”“互联网”“新能源”等子话题。这个粒度对推荐系统尤其有帮助，因为用户可能只对科技下的“芯片”感兴趣而不是所有科技新闻。

3.3 情感分析与热点趋势统计

新闻分析最后一个重要维度是情感。我用的是SnowNLP库，它对简体中文文本能输出0到1之间的情感倾向分数，越接近1代表越正向，越接近0代表越负向。

from snownlp import SnowNLP def get_sentiment(text): try: s = SnowNLP(text) return s.sentiments except Exception: return 0.5 df["sentiment"] = df["content_clean"].apply(lambda x: round(get_sentiment(x), 3))

情感分析在新闻系统里有两个实际应用场景：一个是对单条新闻判断自动打“正、负、中”标签，推荐时可以把负面哀伤类新闻适当降权；另一个是结合时间序列做热点事件的情感波动曲线，比如某种金融新闻发布后的24小时内，用户对相关报道的情绪是越来越乐观还是越来越悲观。这种时序上的分析结果不仅适合可视化展示，也能丰富用户画像。

热点趋势的计算相对简单，把清洗后的新闻按publish_time按小时分组，统计每个小时内各分类的新闻数量，再叠加关键词语义匹配，就能画出“某关键词的近7天热度折线图”。这类图表放在系统首页的可视化面板里非常加分。

4. 推荐系统核心实现：从“千人一面”到“千人千面”

4.1 三种推荐策略的组合与切换逻辑

整个项目最核心也最容易答非所问的部分就是推荐系统的实现。我最终采用组合策略，原因是任何一种单算法都有明显短板：

• 热度推荐：按点击量、发布时间、点赞数综合排序，给新用户和新新闻兜底。
• 基于内容的推荐：根据新闻的TF-IDF特征向量，计算和用户历史喜欢新闻的相似度，推荐最相似的新闻。
• 协同过滤推荐：根据用户群体的行为交集实现个性化推荐，可分为基于用户的UserCF和基于物品的ItemCF。

实际推荐时遵循一个简单的优先级逻辑：新用户没有行为数据，走热度推荐；老用户行为充足，走混合推荐，具体实现是内容推荐和协同过滤各占一定权重，再叠加时间衰减因子。

这里要提醒一个常见错误：很多人做推荐系统时把精力都花在调算法上，却忘了新闻推荐和电商、视频推荐最大的区别在于强时效性。三天前的新闻即使再热门，对多数用户也已经没有价值了。所以所有推荐候选集最后都要过一道时间衰减，我给每条新闻算一个基础热度分，再乘以一个随时间指数衰减的系数：

import math from datetime import datetime def time_decay_score(base_score, publish_time, decay_lambda=0.03): hours_age = (datetime.now() - publish_time).total_seconds() / 3600 return base_score * math.exp(-decay_lambda * hours_age)

这个decay_lambda取值0.03，意味着新闻大约每23小时，热度贡献就衰减一半，这个半衰期对新闻场景来说比较合适。你可以根据自身场景调节，如果做的是深度长文推荐，半衰期可以拉长到两三天。

4.2 UserCF与ItemCF的代码实现

协同过滤的最小可运行版本并不复杂。先说UserCF的思路：找到和你阅读历史最相似的一批用户，把这些人喜欢而你还没看过的新闻推给你。用户间的相似度我用的是余弦相似度，把用户看过哪些新闻看成向量。实际代码比很多教程写的更短：

import pandas as pd from sklearn.metrics.pairwise import cosine_similarity from scipy.sparse import csr_matrix # user_item表: uid, news_id, score user_item = pd.read_sql("SELECT uid, news_id, score FROM user_behavior", engine) # 构建稀疏矩阵 uid_list = user_item["uid"].astype("category") nid_list = user_item["news_id"].astype("category") row = uid_list.cat.codes.values col = nid_list.cat.codes.values data = user_item["score"].values matrix = csr_matrix((data, (row, col))) # 用户相似度矩阵 user_sim = cosine_similarity(matrix) def recommend_by_users(uid, top_n=20): uid_idx = uid_list.cat.categories.get_loc(uid) sim_scores = list(enumerate(user_sim[uid_idx])) sim_scores = sorted(sim_scores, key=lambda x: x[1], reverse=True) candidate_scores = {} for other_idx, sim in sim_scores[1:11]: if sim < 0.3: continue # 取该用户看过的新闻，按相似度加权 row_indices = matrix.getrow(other_idx).indices for news_idx in row_indices: news_id = nid_list.cat.categories[news_idx] candidate_scores[news_id] = candidate_scores.get(news_id, 0) + sim # 过滤用户已看的新闻 watched = set(user_item[user_item["uid"] == uid]["news_id"]) candidates = [(nid, s) for nid, s in candidate_scores.items() if nid not in watched] candidates.sort(key=lambda x: x[1], reverse=True) return [nid for nid, _ in candidates[:top_n]]

ItemCF的逻辑则是反过来的：统计两个新闻之间被多少用户共同看过，新闻A和新闻B经常一起被同一批用户看，那看过A的用户也适合推荐B。ItemCF的好处是新闻之间的相似度矩阵可以离线计算，在线推荐时响应速度更快，尤其适合新闻这种物品数量相对有限的场景。

如果你只用Pandas做练习，几千用户、几千新闻的矩阵乘法还能接受；但一旦用户量上来，全矩阵计算就吃不住了。这时候有两个优化方向：一是用scipy的稀疏矩阵替代二维数组，二是只选取和目标用户相似度最高的前N个用户去计算，而不是遍历全体用户。后者叫近邻截断，是工业界标配做法。

4.3 冷启动问题的解决办法

冷启动是推荐系统里绕不开的问题，我在这项目里分新用户和新新闻两种情况处理。

新用户没有行为记录，UserCF和ItemCF都失效，解决方案是走热度推荐。热度榜不能只用点击量排序，我给出的综合热度公式是：

hot_score = (click_count / max_click) * 0.5 + (interact_count / max_interact) * 0.3 + (1 / hours_age) * 0.2

这里click_count用全站最大值做归一化，交互量包括点赞和收藏，时间因素直接用倒数的形式加入，保证越新的新闻有机会排在前面。

新新闻没有用户行为数据，协同过滤也失效，解决方案是走内容推荐。每条新闻入库后立刻做分词和TF-IDF向量化，然后和用户历史上喜欢的新闻向量做余弦相似度计算，相似度高就进入该类用户的候选池。换句话说，系统不看用户有没有看过这篇新闻，只看这篇新闻和他的历史口味像不像。

在实际代码里，新新闻的向量化可以在数据采集清洗管道中一并完成，入库时就带上特征向量字段，这样推荐引擎调用时直接取向量计算，不用再临时处理文本。

5. Flask后端与ECharts可视化：让分析结果在浏览器里跑起来

5.1 Flask API接口设计

整个系统的后端我用Flask做的轻量级服务，对外提供JSON格式的接口。前端和后端完全分离，前端只负责发请求和画图，后端只负责算数据和返回结果。

核心接口列表如下：

其中/api/user/action是推荐系统闭环的关键接口。前端在用户点击某条新闻时异步发送POST请求，把行为数据写入MySQL，下次计算推荐结果时，这次点击就会影响推荐候选集的排序。没有这个闭环的推荐系统都是假的。

一个接口的写法示例：

from flask import Flask, jsonify, request app = Flask(__name__) @app.route("/api/recommend", methods=["GET"]) def recommend(): uid = request.args.get("uid", "anonymous") rec_list = get_recommendations(uid, top_n=20) return jsonify({"code": 0, "data": rec_list}) @app.route("/api/user/action", methods=["POST"]) def user_action(): data = request.get_json() save_behavior(data["uid"], data["news_id"], data["action_type"]) return jsonify({"code": 0, "msg": "ok"})

接口设计有一个容易被忽略的细节：所有时间字段在JSON返回时统一转换成字符串格式，否则前端JavaScript拿到的会是时间戳，处理起来容易出岔子。我自己是在Flask中自定义了一个JSONEncoder，日期字段统一序列化为“YYYY-MM-DD HH:mm:ss”格式。

5.2 ECharts可视化组件配置

可视化面板我选择ECharts，最大的原因是配置灵活、图表种类丰富、前端集成不用引太多依赖。我用到的图表组件包括：词云图展示热点关键词、折线图展示热度趋势、饼图展示新闻分类占比、散点图展示情感与热度的交叉分布。

词云图的配置有一点需要特别注意：它不在ECharts官方包里，要单独引echarts-wordcloud插件，很多新手在这里卡住。配置的核心是data数组里放词和权重，权重直接取TF-IDF值即可：

option = { series: [{ type: "wordCloud", gridSize: 10, sizeRange: [14, 60], rotationRange: [-45, 45], textStyle: { color: "random" }, data: keywordData // [{name: "芯片", value: 12.3}, ...] }] };

热度趋势折线图更简单，X轴是时间，Y轴是新闻数量或关键词权重。注意要根据时间跨度动态调整聚合粒度：如果数据只覆盖最近24小时，按小时聚合；如果覆盖最近30天，按天聚合。粒度过细曲线噪声大，粒度过粗看不出趋势变化。

5.3 把推荐和可视化串成一个完整闭环

前端页面我分了三个主要区域：主页左侧是推荐列表，中间是焦点新闻详情，右侧是数据可视化面板。用户在左侧点击新闻后，前端会同时做两件事：展示新闻内容和发送行为上报请求。行为数据积累到一定量，刷新推荐列表时会明显看到推荐内容向用户的兴趣点倾斜。

实际上把推荐结果和可视化面板放在同一个页面有很大好处：用户既能看内容，又能直观看到系统对自己的分析结果。比如可视化面板里展示“你的兴趣标签：科技 60%，财经 25%，体育 15%”，这种透明化设计让推荐系统的“黑盒感”大大降低，演示时也更容易得到认可。

6. 部署、排查与性能优化：实战中最头疼的部分

6.1 Python环境与大数据集群部署策略

这个项目要想顺利跑起来，环境配置是第一个坎。先强调一个经验：永远使用虚拟环境或Anaconda环境来隔离项目依赖，不要一股脑把包装进系统Python环境里。我用的依赖清单大致是Flask、requests、scrapy、pandas、jieba、snownlp、scikit-learn、pymysql、pyecharts这些，其中scikit-learn和pandas版本容易互相踩坑，建议直接装Anaconda基础环境，等于一套预装好的科学计算全家桶。

IDE方面，vscode或者pycharm都可以，重点是把Python解释器路径指到你的虚拟环境，不然就会出现“终端能跑、IDE里执行报ModuleNotFoundError”的经典问题。另一个常见的坑是MySQL连接编码，pymysql连接时一定要加charset="utf8mb4"，否则存中文正文时容易报编码错误或者乱码。

大数据环境这部分，我的建议是“先演示后深挖”。本地跑通全流程用MySQL加Pandas完全足够；如果你的题目要求体现大数据能力，可以在Linux服务器上搭Hadoop伪分布式和Hive，把新闻数据导入HDFS，用Hive SQL做清洗和统计。伪分布式模式的意义是让你把整个大数据生态的流程走通，从HDFS文件落地到MapReduce、再到Hive表查询。等你理解了伪分布式的运作机制，再扩展到三节点集群就只有配置文件的差别了。集群部署策略记住一句话：从单机伪分布式开始，先跑通流程再横向扩展。

6.2 常见问题排查速查表

长时间跑这个项目，我整理了最有代表性的几个坑：

其中“推荐结果永远雷同”是新手最容易遇到也最难自己发现的问题。它看似是算法效果差，其实是推荐策略单一导致的，用户A和用户B拿到的结果几乎一样，因为热度榜的主导权太重。修正方式是给不同用户写入随机扰动因子，同时保证候选池足够大，至少200篇以上再做排序截断。

6.3 性能优化的三板斧

这个项目做到演示级别其实已经够了，但如果想把性能再往上提一点，优先做这三件事。

第一，MySQL加索引。用户行为表每天新增几万行数据，查询“某用户最近一周行为”如果没有索引就是全表扫描，加了(uid, action_time)联合索引后查询耗时能从秒级降到底部毫秒级。这条性价比极高，适合最先做。

第二，推荐结果预计算。个性化推荐的核心计算全部离线跑，每小时在后台任务里计算好每个用户的TopN列表并存入Redis，在线接口只做读缓存操作。这样一来推荐接口的响应时间基本能稳定在10毫秒以内。

第三，文本特征向量化提前入库。每条新闻在采集清洗时就生成TF-IDF特征向量，序列化存入数据库字段，推荐引擎在线计算时直接读取反序列化，不用重新分词重新向量化，节省的算力非常可观。

最后分享一点个人体会

这个项目做完给我最大的感受是：它最大的价值不在某个算法有多前沿，而在于把一条数据管道从头到尾打通了。你既要会爬数据、洗数据，又要会分析文本、构建特征，还要懂推荐算法、做API、画图表，每一项单独拿出来都不算难，难的是让它们在一个系统里顺畅协作。很多问题只有真正动手才会遇到——比如Python环境版本冲突、MySQL编码折腾半天、ECharts词云组件加载不出来，这些都是教程不会写但实际项目里一定会碰到的坎。我的建议是如果你正在做类似的项目，不要急着追求复杂的算法，先把数据管道跑通，把推荐闭环走完，再逐步优化各个模块。这个项目后续还可以扩展的方向也很多：把离线统计升级成Spark Streaming实时计算，把TF-IDF特征换成BERT语义向量，加入用户画像标签体系，或者把推荐结果做得精排和重排两阶段，都是很不错的研究点。