企业官网建设流程全解析

做评论类项目的人应该都遇到过这个尴尬：后台囤了几十万条用户反馈，产品经理想从中提炼出“用户到底在骂什么、夸什么、最关心什么”，结果只能靠人工一条条翻，翻到后面眼睛都花了。我去年用Django从零搭了一套“用户评论热点问题挖掘与反馈分析系统”，从数据接入、中文分词、热点聚类、情感打分，到可视化看板和管理后台，整条链路都跑通了。这篇就完整复盘一下这套系统的设计思路、算法选型和Django工程化落地的关键细节，给同样在做评论分析、用户反馈挖掘这类项目的朋友做个参考。

这套系统最核心的价值，就是把“人工读评论”这件事变成“机器先筛一遍，人只看重点”。它做三件事：从评论里提取高频热点和突发问题，给每条评论做情感倾向判断，最后把分析结果以图表和报告的形式推到运营和产品面前。不管你是要给电商平台做商品口碑分析，还是给SaaS产品做用户反馈监控，甚至给校园论坛做舆情观察，这套Django系统的架构都能直接复用。

1. 做这套系统的原因与整体设计思路

1.1 为什么是Django，而不是Flask或Spring

选型的时候我其实纠结过一段时间。论轻量，Flask更灵活；论性能，Spring那套在Java体系里确实能打。但最后我还是定了Django，理由很实在：这项目涉及的东西太杂了——要建一堆数据表存评论和热点结果，要写后台给运营人员标注反馈，要做API给前端看板供数，还要挂定时任务晚上自动跑算法。

Django把这些需求全包圆了。ORM帮你把表结构管理得明明白白，Admin自带后台稍作改造就能用，DRF写接口效率极高，再挂个APScheduler或者Celery就能跑定时任务。一个框架搞定全套，不用像Flask那样自己拼轮子。而且Django的ORM在做“查询-更新-删除”这类常规操作时非常舒服，比如我在算法模块里要批量更新评论的情感标签：

# 批量更新情感标签，避免一条条save() Comment.objects.filter(status='pending').update(sentiment='positive')

这一行能把几千条评论的状态一次刷完，放到Flask里你得自己写SQL或者循环遍历，麻烦不少。

1.2 系统模块拆分

整个系统我拆成四个相对独立的模块，每个模块之间只通过数据和接口通信，互不掺和内部逻辑：

1. 数据接入层：负责评论数据的导入、清洗和入库，支持接口推送、Excel上传、爬虫落库三种方式。
2. 分析引擎层：这是核心，做文本预处理、热点挖掘、情感分析，全部封装成独立的Python服务模块，不依赖Django的request/response生命周期。
3. 任务调度层：负责定时触发分析任务、管理任务状态、生成分析报告。
4. 展示与反馈层：Web看板（ECharts图表）、管理后台、反馈工单流转。

这种分层方式的好处是，分析引擎可以脱离Web单独测试，出问题的时候也容易定位。比如用户反馈“热点列表不对”，我可以直接在命令行跑一次算法脚本，对比结果，而不是在浏览器里反复刷新调试。

在APP划分上我没有走极端模块化的路子，而是按Django官方推荐的方式创建了三个APP：comments（评论数据）、analytics（热点与情感分析）、dashboard（看板与报告）。运行django-admin startapp分别建这三个APP，各自负责自己的模型、服务和视图，代码结构清晰，后面扩展也方便。

1.3 架构上的几个关键取舍

有几个设计决策我想单独说一下，因为都是实际开发中容易被忽略的点。

第一，分析逻辑不放在请求链路里。Web请求应该只负责查库、渲染、返回JSON，如果同步去跑分词、聚类、情感分析，一个请求没个十秒八秒下不来，体验极差。我这边采用的是“先写库，后分析”的模式：评论进来先落库，状态标记为pending；分析引擎定时扫描pending数据，跑完把结果写回，状态改成done。这样Web端永远只查结果表，响应速度很快。

第二，算法参数全部放在配置中心里，不写死在代码中。比如热点阈值、情感词典路径、聚类半径，这些都放到Django的settings.py里或者单独一个algorithm_config.py，方便调参。我吃过亏——早期把阈值写在算法代码里，每次调参都得改代码重启服务，后来集中管理就好了。

第三，给管理后台留了人工干预入口。算法不是百分之百准确的，尤其情感分析和热点聚类，偶尔会把中立评论判成负面，或者把两个不相干的热点聚到一起。所以我做了“人工复核”机制：后台可查看算法结果，支持人工修正标签，修正后的数据会同步反馈到报告里。这点很重要，真正给业务用的时候，纯黑盒的算法是没法交付的。

2. 评论数据接入与中文文本预处理

2.1 数据来源：先别急着爬，把接口和导入做稳

很多朋友一听到“评论挖掘”就想着写爬虫，我建议先把心收一收。真实落地场景里，评论数据往往可以从系统内部拿到：电商平台的订单评价表、SaaS产品的工单备注、社区论坛的用户回帖数据库，这些数据通常能通过SQL导出、平台OpenAPI或者管理员后台获取。

我在这个项目里做了三种数据接入方式：JSON接口推送（适合系统对接）、Excel上传（适合运营手工整理）、数据库直连导入（适合初始化历史数据）。这三种方式平摊下来，覆盖了绝大多数场景。接口推送用DRF写一个/api/v1/comments的POST接口，做了简单的鉴权和幂等校验；Excel上传用pandas读取再批量入库；直连导入就是写一段管理命令，python manage.py import_comments，指定数据源连接串就行。

有个细节需要注意：Django的批量写入一定要用bulk_create，亲测十万条评论用bulk_create秒级入库，而用普通create()循环的话要跑好几分钟，这个差距在数据量上来之后特别明显。

2.2 数据清洗：脏数据比你想象的更常见

评论数据脏是常态。我接到的第一批数据里，就出现了大量HTML标签残留、表情符号乱码、重复评论、纯标点垃圾内容，还有不少只有几个空格字符的“空评论”。如果不做清洗，后面分词和聚类的结果会被带偏。

清洗这一步我封装了一个clean_text函数，主要做这几件事：

def clean_text(text): import re # 去HTML标签 text = re.sub(r'<[^>]+>', '', text) # 去URL text = re.sub(r'http[s]?://\S+', '', text) # 去表情符号（保留中文、英文、数字和常见标点） text = re.sub(r'[^\u4e00-\u9fa5a-zA-Z0-9，。！？、；：""''（）\s]', '', text) # 合并多余空白 text = re.sub(r'\s+', ' ', text).strip() return text

这条正则看着简单，但踩过的坑不少。最初我没有过滤表情符号，结果“这个产品太好用了😍”这句话分词后出现一堆乱码字符，聚类时全被当成了噪音。另外还做了一个规则：清洗后长度小于2的评论直接丢弃，重复评论按内容指纹去重，避免同一个用户重复刷屏把热点带偏。

2.3 分词与去停用词：准确率的关键在词典

中文文本处理绕不开分词。我这边选的是jieba分词库，原因很简单：成熟、社区活跃、支持自定义词典，而且能和Python生态无缝衔接。分词这一步直接决定后续热点识别的质量，所以不是简单调用一下jieba.cut()就完事。

第一，加载业务自定义词典。通用词典里没有领域词汇，比如“续航”“闪退”“加载慢”“客服态度差”这些业务关键词，默认分词可能被切得七零八落。我在项目里维护了一个user_dict.txt，每行一个业务词，比如：

续航 闪退 物流慢 售后响应 开机黑屏

jieba.load_userdict('user_dict.txt')加载后，分词准确率提升非常明显。

第二，维护停用词表。像“的”“了”“就”“都”这类虚词，对热点识别毫无贡献，必须过滤掉。我用的是通用的中文停用词表，还根据项目数据手动补充了几个高频噪音词，比如“感觉”“觉得”“真的”这类主观引导词，在情感分析场景下也当停用词处理。

第三，注意编码问题。早期在Windows环境用pycharm跑的时候，读取TXT词典总是报UnicodeDecodeError，后来统一把词典文件保存为UTF-8编码，并在代码里显式指定：open('user_dict.txt', encoding='utf-8')，问题解决。这类小坑看着不起眼，实际开发中经常让人抓狂。

2.4 同义词合并与业务词扩展

评论是用户随口写的，同一个问题可能出现N种表达方式。“发货慢”“物流慢”“快递太慢了”其实说的是同一件事。如果不做同义词合并，热点列表会被拆得很碎，看不出真实的问题集中度。

我建了一张同义词映射表，保存在synonyms.json里：

{ "发货慢": ["发货慢", "物流慢", "快递太慢", "配送迟缓", "一直不发货"], "客服态度": ["客服态度差", "客服不回复", "售后没人理", "客服敷衍"] }

分词之后，每个词都过一遍同义词映射，命中的统一替换成标准词。这样聚类出来的热点词表干净很多，“物流问题”能聚成一个足够大的簇，而不是散成几十个低频率碎片词。

这一步做完，数据的预处理链路就闭环了：原始评论 → 清洗 → 分词 → 停用词过滤 → 同义词归一，输出的都是标准化后的词序列，供后面的热点挖掘算法使用。

3. 热点问题挖掘的核心算法选型与实现

3.1 为什么不用“数词频”这种简单办法

先说一种直觉方案：统计评论里每个词出现的次数，次数最多的词就是热点。这样做在极小的数据集上勉强能用，但放到真实场景里问题很大。最典型的是“产品”“东西”“感觉”“问题”这类泛化词会霸占词频榜，但它们根本算不上“热点”，只是用户表达时的常用词。

所以热点挖掘不能只看“出现多少次”，还要看“在这个时间段内是不是异常突出”。这背后是信息检索里的经典思想：一个词的重要性，取决于它在当前文档集合中的区分度，而不只是它在单篇文档里的出现频次。

3.2 TF-IDF：找到每个时期的特征词

我的热点识别第一层用了TF-IDF（词频-逆文档频率）。

简单说一下原理。TF是词频，指的是一个词在评论集中出现的次数；IDF是逆文档频率，指的是包含该词的文档数占总文档数的比例取对数再取倒数。当一个词在某一批评论里频繁出现，但在整体评论历史里很少出现时，它的TF-IDF值会非常高。换句话说，TF-IDF能帮你找出“这个时期突然爆发”的词，这正是热点问题的本质。

Django落地的时候不需要自己从头实现TF-IDF，用sklearn的TfidfVectorizer就能搞定。我按天或者按周把评论分组，每个分组视为一个文档，计算每个分组的TF-IDF，取排名靠前的词作为热点候选词。

from sklearn.feature_extraction.text import TfidfVectorizer vectorizer = TfidfVectorizer(token_pattern=r'\S+', max_features=5000) tfidf_matrix = vectorizer.fit_transform(doc_list) feature_names = vectorizer.get_feature_names_out()

token_pattern这里要特别注意，jieba分词后已经用空格隔开了词，所以直接用\S+匹配非空白字符即可。如果还是用默认的token_pattern，会被再次切分，把“客服态度差”拆成“客服态度”和“差”，热点语义就丢了。

3.3 TextRank：抽取核心问题和关键短语

TF-IDF能找出关键词，但它只基于统计，不带语义。为了把热点从“词”提升到“问题描述”的层面，我叠加了一层TextRank算法。

TextRank和图排序算法PageRank思路很像：把句子里的每个词当作图中的一个节点，词与词在同一句话中共现就建立一条边，然后迭代计算每个词的权重。权重高的词，往往是一句话里最核心的、和主题连接最紧密的词。

这样做的效果是：能抽取出“充电慢”“售后无响应”这种短语级别的热点表述，而不是孤零零的“充电”“售后”。简单来说，TF-IDF告诉你“最近哪些词异常突出”，TextRank告诉你“这些词背后用户在讨论的核心短语是什么”。

提取核心短语后会有一个汇总环节：把TF-IDF选出的TOP词和TextRank选出的TOP短语做个交叉匹配，保留同时出现在两个列表里的词，再去掉泛化词，最终形成一个“热点问题候选池”。

3.4 DBSCAN聚类：发现隐性问题簇

光有词还不够，我还希望把表达同样问题的评论自动归拢到一个簇里。比如“开机黑屏，没法用”和“电脑黑屏了，开不了机”表述不同，但都是同一个问题。词级别的方法没办法处理这种情况，必须上聚类。

聚类算法我对比过K-Means和DBSCAN，最后选了DBSCAN。原因是评论数据密度分布不均匀、簇的形状不规则，K-Means需要提前指定簇的数量，而且只能聚出球形簇，不适合短文本。DBSCAN基于密度，不需要预设簇数，还能把噪声点单独标记出来。

这里的技术栈是用SentenceTransformer把每条评论编码成向量，再用DBSCAN聚类。一开始我试用过zh-NER-bert那种重型模型，效果确实好，但推理速度太慢，几万条评论跑一次要好几个小时。后来换成轻量模型，准确率略降但速度提升了十倍，运维上能接受。还要吐槽一句，首次加载预训练模型时要从网上下载权重，在服务器环境必须提前准备好离线模型文件，不然部署的时候会被卡住。

DBSCAN的两个参数eps（邻域半径）和min_samples（最小样本数）对结果影响很大，我有过一个eps=0.3时聚类分不出来、调到0.5后全部分成一类的翻车经历。调参的方法就是抽样可视化，把聚类结果导出成散点图看几轮，比盲试参数高效得多。

3.5 热点分值与趋势判定

聚类出来的簇要排序，不能光看簇内评论数量。为了防止误导，我设计了一个热点分值公式：

热点分 = 评论数量权重 + 情感负向权重 + 时间衰减权重

具体数值上，评论数量权重占50%，负面情感占比占30%，时间衰减占20%。时间衰减的意思是：今天的评论权重比上周高，这样能突出“新近爆发”的问题。用指数衰减函数new_score = old_score * exp(-0.1 * days_ago)实现，时间越久远，热度值越低。

最终每个热点问题会生成一条记录，包含热点名称、爆发言论数、情感分布、趋势方向（上升/下降/持平），这些字段直接进数据表，供看板展示。

4. 用户反馈分析与情感倾向识别

4.1 情感词典方案为什么能打

讲情感分析就绕不开一个问题：用预训练模型还是用词典。我一开始试过直接用sentiment类预训练模型，准确率确实不俗，但有两个痛点：一是模型推理速度慢，批量处理几万条评论时耗时感人；二是模型结果不可解释，运营同学会问“为什么这条判为负面”，你很难解释清楚。

所以我在生产环境里用的是“情感词典+规则”的混合方案。情感词典是两个列表：正面词表（“好用”“流畅”“喜欢”“满意”等）和负面词表（“卡顿”“闪退”“垃圾”“失望”等）。分词后统计每条评论命中多少正面词和负面词，加权计算情感得分。

4.2 正面负面中立：三级判定与强度分

落地的时候把情感分成三级：正面、负面、中立。判断逻辑是这样的：

def judge_sentiment(words): pos_count = sum(1 for w in words if w in pos_dict) neg_count = sum(1 for w in words if w in neg_dict) if pos_count == 0 and neg_count == 0: return 'neutral', 0 if pos_count > neg_count: return 'positive', pos_count / (pos_count + neg_count) if neg_count > pos_count: return 'negative', neg_count / (pos_count + neg_count) return 'neutral', 0

强度分用来表示情感有多强烈，比如“非常垃圾”和“有点失望”虽然都是负面，但负面程度不同。这里做了一层简单的程度副词加权：命中“非常”“特别”“极其”等强程度词时，情感权重乘以1.5；命中“有点”“稍微”“不太”等弱程度词时，权重乘以0.5。这层规则很简单，但实际效果比纯词典好很多，原因是口语里程度副词出现频率很高。

当然这套方案也有短板，否定句式就是个老问题。“客服态度一点都不好”——“好”是正面词，但“一点都不”把语义反转了。我加了一层否定词表：如果正面词前面两个词以内出现否定词，情感判定翻转。这个正则规则不完美，但能覆盖大部分场景。

4.3 从评论到反馈：问题归因与分类

情感倾向只是“用户爽不爽”，产品经理更想知道“为什么爽/为什么不爽”。所以我在情感分析之后又加了一步：问题归因。把负面评论映射到具体问题分类，比如“性能问题”“售后问题”“物流问题”“价格问题”“功能缺失”等。

这一步的落地方法很简单，每个问题分类维护一个规则词表，评论分完词后逐一匹配。比如命中“卡顿”“闪退”“崩溃”“黑屏”则归入“性能问题”；命中“客服”“售后”“不理人”“敷衍”则归入“售后问题”。分类结果存在feedback_tag字段里，后台可以直接按分类筛选评论。

规则的局限是覆盖面有限，可能出现“未分类”的情况。我留了一个兜底：未分类的负面评论自动进入“待人工分类”队列，后台运营看到后手动打标签，打标的数据会回流到规则词表里，形成持续优化的闭环。这里和前面提到的“人工介入”设计是一脉相承的。

4.4 反馈闭环：让分析结果真正用起来

分析出来结果如果不进入业务流程，就是一张漂亮的无用图表。所以在反馈闭环上我还做了一个工单流转功能：某个热点问题的负面情感占比超过阈值（比如40%），系统自动生成一条反馈工单，推送给相关负责人，负责人可以标记“已处理”“处理中”“已解决”。

工单处理完成后，这个热点会被标记为“已闭环”，在下一次分析中可以对比闭环前后的情感变化。这一整条链路：

评论进来 → 热点识别 → 情感打分 → 问题归因 → 自动生成工单 → 人工处理 → 效果回看

本质上就是把“用户反馈”变成了“可追踪的问题记录”，这也才是“反馈分析系统”真正的意义所在。

5. Django工程化落地：模型、任务与API设计

5.1 数据表设计：十张表以内的方案

系统整个模型的表数量比我一开始预想的要少，核心就这几张：

重点说一下Comment表的索引设计。上线初期，我按自然习惯用created_at字段做查询条件，数据量到几十万的时候，按时间范围查+排序的速度明显变慢。后来加了created_at联合索引，并把sentiment单独建了索引，查询速度提升明显。经常做这类业务的朋友应该深有体会：Django的ORM写起来很爽，但建表的时候不思考索引，数据量上来就会还债。

5.2 定时任务：用APScheduler做周期性分析

分析任务不能手动点按钮跑，必须定时自动执行。Celery是Django生态里最常见的方案，但它要额外引入消息队列（Redis或者RabbitMQ），部署成本不低。考虑这个项目的数据量和复杂度，我选了APScheduler，直接把定时任务跑在Django进程里，简单可靠够用。

在apps.py里注册启动函数，在settings.py里配置任务计划：

sch = BackgroundScheduler() sch.add_job(run_analysis, 'cron', hour=2, minute=30) # 每天凌晨2:30跑 sch.add_job(run_report, 'cron', hour=6, minute=0) # 凌晨6点生成报告 sch.start()

为什么选凌晨跑？因为评论一天积累下来，凌晨数据最完整，跑完正好赶上早上上班看报告，时间上很合理。另外任务跑批时如果数据量太大，会占用数据库IO和CPU，放在业务低峰期最安全。

5.3 缓存策略：别让高频查询打垮数据库

看板页面第一次打开时可能要同时查热点列表、情感分布、趋势图、词云图，全是聚合查询，直接把压力给到数据库，数据量一大页面加载就卡。我的方案是“异步生成结果 + 缓存结果表”。

分析任务跑完后，直接生成一份JSON格式的分析结果快照，写入AnalysisReport表。看板查询时只要读这条快照记录，不再实时跑聚合。这样看板接口的响应时间稳定在几百毫秒以内，基本不受数据量影响。

配合Django自带的缓存框架，热点榜单接口可以缓存五分钟：设置CACHES为Redis后端，视图函数上直接用@cache_page(300)，核心接口的数据库查询压力进一步下降。

5.4 API接口设计：前后端分离的约定

前端看板用Vue写完之后，通过DRF接口和后端通信。接口做了四个：

• GET /api/v1/hot-topics/?period=week：热点问题列表
• GET /api/v1/sentiment/overview/：情感分布总览
• GET /api/v1/trends/?topic_id=x：某个热点的趋势数据
• GET /api/v1/comments/?filter=negative：筛评论文本

接口设计上有两个细节比较重要。第一个是统一返回格式，不管成功失败都是{code, message, data}结构，前端处理起来不用写大量重复判断。第二个是数据量控制，列表接口默认分页，一页20条，避免一次性返回几百条评论把页面卡死。排序、筛选这些能力，全部通过Query参数暴露出来，比如?ordering=-hits、?sentiment=negative，前端自由度很高。

管理后台侧，我直接用Django Admin做了二次开发。先用pip install django-unfold把默认的Admin界面美化了一层，观感比原生Admin舒服不少，然后注册Comment、HotTopic这些模型，运营人员就能直接在后台审核热点、修正标签、管理工单。Django生态这个东西是真的方便，标准后台+少许自定义，省去了从零开发一套运营管理界面的时间。

6. 数据可视化看板的实现思路

6.1 ECharts接入Django模板

看板部分我用了Vue单页应用 + ECharts图表库，通过API和Django后端对接。图表库强推ECharts，中文文档完善、图表类型全、社区案例多，尤其词云、雷达图、折线图这些分析类图表都有现成配置可抄。

前端项目的构建产物直接放到static目录下，由Django的TemplateView渲染一个壳页面，之后所有数据全部走Ajax拉API填充。这样做的优点是兼容性好，部署的时候只要一个Nginx托管静态文件外加Django跑API即可，不需要复杂的Node服务。

6.2 词云图与TOP-N热词榜

看板首页最醒目的是热点词云。根据热点分值和词频动态生成词云数据，ECharts词云插件接受[{name, value}]格式的数据，热点分值越高，词显示越大。词云图旁边配一个TOP10热词排行榜，用横向柱状图展示，点击热词可下钻到具体评论列表。

这里有个小诀窍：词云的颜色可以用热度值做阶梯映射，热度越高颜色越醒目，用户在视觉上能一眼看出当前最重要的问题。另外词云不要放太多词，50个以内就够了，放多了全是小字，反而看不出重点。

6.3 趋势图与负面雷达图

第二个页面是趋势分析页。选择某个热点问题后，展示它过去三十天的爆发言论数量趋势，是一条折线图。折线上叠加情感分布堆叠面积图，能直观看出“这个问题爆发的时候，负面情绪是不是同步上升”。很多时候热点和负面情绪是有滞后性的——负面评论先涨，隔两天热点才被算法提到最高，把这个趋势展示出来，对业务判断很有参考价值。

雷达图用来展示情感归因的细分维度：性能、售后、物流、价格、功能、体验六个维度，每个维度取负面情感占比，连线成型。哪一块凹陷得厉害，说明哪个领域的负面反馈集中。这个图运营看得多，反馈比较直观。

6.4 看板性能优化

看板页面频繁切换日期、切换热点，后端接口压力不小，前端缓存和后端缓存搭配着做。前端在Vue层用keep-alive缓存已经渲染过的组件，后端接口加cache_page缓存五日内的热点趋势数据。

另外，ECharts在大数据量图表渲染时会有明显卡顿。这里用到了ECharts的sampling配置，开启后图上最多显示几百个采样点，数据量再大也流畅如初。我第一次做完没开采样，加载全年数据时图表卡了将近两秒，加了sampling: 'lttb'之后降到毫秒级。

7. 常见问题与排查技巧实录

7.1 中文乱码：每一层都要问一遍编码

这种问题在中文NLP项目里绝对绕不开。评论存MySQL后，控制台和后台显示乱码，排查是从数据库层面开始做的。MySQL表结构确认用的是utf8mb4字符集，Django的DATABASES配置里加上OPTIONS': {'charset': 'utf8mb4'}，Python连接层再显式指定charset='utf8mb4'。三层都对齐之后，乱码问题才算根治。不要指望只改一个地方，编码这种问题往往是“链路上某一环”断了，排查时每一层都要检查。

7.2 分析任务太慢：卡在哪一步怎么定位

早期跑一次全量分析要三个小时，严重拖慢迭代节奏。解决思路是分步计时：在数据清洗、分词、特征提取、聚类、情感打分五个阶段各加一个logger.info打印耗时。日志显示，时间花在了两处——一是全量聚类在大数据集上的计算开销，二是情感词典的逐字匹配比较慢。

针对性优化方案：聚类改为“先按时间窗口切分再分别聚”，只对当批次数据跑聚类，不再全量反复跑；情感匹配从纯Python循环改成了把词典编译成正则表达式一次性匹配，速度提升明显。实测优化后全量任务从三小时降到四十分钟左右，可接受。

7.3 算法结果不准：从数据集反推权重

热点识别偶尔出傻结果，比如把“不会再用”“不要买”这种常规负面表达当成热点词。排查方法是把结果导出来，人工翻一部分原始评论，看看这些词到底是不是“真的热点”。后来发现，负面词汇天然带有高频属性，热度分计算公式里负面情感占比权重太高，会把“普遍存在的负面抱怨”误判成“突发事件热点”。

调整办法是把负面情感占比权重的阈值调高——单条热点要超过一定负面占比才计入重权，并且结合时间衰减，让突发集中性的负面问题有更高权值。这类调参没有捷径，就是不断拿历史数据验证，先多看结果再改公式。

7.4 定时任务丢数据：数据库锁与任务队列

定时任务跑批的时候偶尔出现“少处理了一部分评论”的情况。排查后发现是两个定时任务在同一时间段抢同一批pending状态的数据，互相把对方任务置为done导致重复或漏处理。

解决办法是在TaskRecord表里加了一个task_lock字段，任务启动时先尝试获取锁，拿到锁才能处理数据，处理完释放。同时把两个任务错开执行时间，避免并发冲突。这不算高深技术，但很实用，做类似系统时可以提前防住。

7.5 问题速查表

写在最后的一些体会

这套Django评论热点挖掘与反馈分析系统从原型到稳定运行，整个迭代过程里我的一个核心体会是：这类项目真正的难点不在算法有多高级，而在于把算法和工程链路无缝咬合。分词准、聚类效果好只是第一步，能不能自动跑批、能不能扛住数据量、能不能让业务看懂结果、能不能人工纠偏，这些工程化的东西才是决定系统能不能真正落地的关键。

最后再分享一个小技巧：热点结果表里一定要留一个“人工核验状态”字段。算法跑出来的热点列表先标记为“待核验”，等运营人员后台确认后再推送到正式看板。这一步看着多此一举，实际使用中能避免不少尴尬场景——算法刚把某个问题推到热点榜，结果运营一查发现是老问题复发，差点闹出乌龙。留这个人工关卡，系统的可靠性和可信度会提升非常明显。