企业官网建设流程全解析

每年上半年我都能收到十几条差不多的问题：老师让选个"有亮点"的毕设题目，最好带点AI、带点大数据，但自己只想安安稳稳毕业，怎么办。这个标题——"Django+DeepSeek大模型知识图谱古诗词情感分析、推荐、可视化"——基本就是这类需求的完美答案。它几乎把所有"看上去很贵"的技术词打包了：深度学习、大模型、知识图谱、推荐系统、数据可视化，后端用的还是Python生态里最好上手的Django。更重要的是，这个组合不是硬凑的，知识图谱可以给推荐提供路径依据，DeepSeek大模型负责情感判断，情感标签又反过来成为图谱实体和推荐特征，三个模块咬得很紧，答辩时讲起来能形成一条完整的主线，而不是一个个孤立的demo。

这篇文章我把整个系统的技术拆解和一整套可落地的实现方案写清楚，适合正在做这个题目、或者想在技术方案上换一套组合拳的同学参考。数据怎么清洗、图谱怎么建模、DeepSeek怎么接进来、推荐怎么和情感关联、可视化怎么做得不像应付差事，每一块我都按实际开发顺序来。

1. 为什么说这个选题的核心竞争力在于"技术闭环"

1.1 盘点一下标题背后到底涉及多少技术栈

先把这个题目里藏着的技术点逐个拆出来，你心里就有底了：

这个组合的价值在于，它是一个从"数据"到"知识"再到"应用"的完整链路。传统毕设常见的问题是两个：一是只有管理系统没有智能，二是只有一个单独的模型没有系统。而这个题目标题直接体现了一鱼三吃的思路——你有算法（情感分析），有结构化知识（图谱），有交互应用（Web和可视化），有业务场景（推荐）。

1.2 难度分层：什么对你来说是真实的挑战

我对这套技术栈的难度评估是这样的：

• 低难度：Django基础CRUD、ECharts图表绘制、MySQL数据表建模。只要走完一遍官网教程就能干活。
• 中难度：知识图谱建模与Neo4j操作、DeepSeek API的工程化封装（Prompt设计、响应解析、异常兜底）、推荐算法的设计。
• 高难度：严格来说没有。真正的难点只在前期数据清洗和图谱中诗词实体与情感标签的对齐。

这也是这个选题适合毕业设计的原因：它上限可以够到"不错的工程实践"，下限也只是一个重复劳动不多、需求描述清晰的标准项目。你不需要啃深度学习原理调参，也不需要从零训练Transformer。

1.3 和普通管理系统类毕设拉开差距的关键点

做图书管理系统、教室预约系统这类题目的同学，答辩时讲的核心词无非是"增删改查"。但你这个题目里可以讲出决策逻辑：比如"推荐一首诗"这个行为背后，是先在知识图谱里遍历诗人、朝代、词牌的多跳关系，再用情感分析结果做过滤排序。这种从"记录数据"到"基于知识做推断"的转变，是评委最认可的差异点。

2. 数据是地基：古诗词语料的获取、清洗与结构化字段设计

2.1 数据源选择与最基本的字段约定

古诗词公开数据其实很丰富，比较常见的是整合自各开源语料库的JSON合集，一般包含标题、作者、朝代、正文、注释、译文、赏析等字段。建议统一收集后落成一份标准格式的JSON或CSV，字段设计如下：

{ "id": "poem_000123", "title": "静夜思", "author": "李白", "dynasty": "唐", "type": "五言绝句", "content": "床前明月光...", "tags": ["思乡", "写景", "月亮"] }

推荐把数据总量控制在8000到15000首比较合适。太少，图谱和推荐都显得单薄；太多，清洗和对齐工作会压垮你。我个人的建议是只保留1000到3000首精华作品就能把全流程跑通，后续写论文时再说明"系统设计支持扩展"即可。

2.2 清洗环节最容易翻车的三个细节

第一个坑是繁体字与异体字。古诗词里大量繁体字形，直接入库会导致检索和情感分析效果变差。处理时可以统一转简体，但要小心部分字在诗词语境里转写后语义变化，比如"云"和"雲"。建议整理一份针对诗词语料的简繁映射表，而不是直接硬转。

第二个坑是作者名不一致。"李白"可能在某些语料里写作"李太白"，不同源的库合并时往往出现同一实体在不同字段下的变体。这个需要做一步实体归并，把别称、字号统一映射到标准人名，否则知识图谱里会分裂出多个"李白"节点。

第三个坑是生僻字、缺字和标点混乱。古籍不全时常见"□"占位符，要统一剔除或标记。另外长诗的分句、断句都要做预处理，生成后续用于情感分析的句子级数据。

2.3 为什么我推荐用MySQL做主数据存储、Neo4j做图谱存储

很多同学会觉得知识图谱就应该全部扔进Neo4j，这其实是个误解。毕设场景下你需要同时支持：

• 常规的列表查询、模糊搜索、分页（适合关系型数据库）；
• 多跳关系遍历、图路径分析（适合图数据库）。

稳妥做法是双存储：MySQL保存诗词原文、作者、朝代等结构化属性数据，Neo4j保存实体与关系，充当图谱查询引擎。两者通过一个统一的DAO层访问，以诗词ID作为关联主键。这样答辩时你也可以解释"为什么没有只用一种数据库"——不同场景下的查询模式决定了存储选型，这是一个可以加分的架构认知点。

3. 古诗词知识图谱的建模实践：实体、关系与属性

3.1 实体类型设计：别只建"诗人—朝代"这种笔记级别的图

很多知识图谱演示项目只做两张实体表，关系也就"And"—"写"—"属于"，这种图答辩时一演示就露馅。古诗词领域至少需要以下五类实体：

• 诗人：属性有朝代、字号、生卒年、籍贯、代表作品数。
• 作品：属性有标题、正文、体裁（诗/词/曲）、词牌名、创作年份（若可考）。
• 朝代：属性有起止年份、历史时期。
• 情感标签：属性有情感维度（喜、怒、哀、乐、思、惧等）。
• 意象主题：属性有主题词（月亮、流水、梅、竹、酒、剑、离别、战争等）。

3.2 关系类型设计：关系要能回答问题，而不是为了有边而有边

图谱里的每条关系都要能支撑某个功能，这是设计的关键。我实际用的关系集合如下：

其中"表达情感"和"包含意象"这两类关系非常关键。它们直接连接了DeepSeek情感分析的输出结果和知识图谱的结构——你每分析完一首诗，就向图谱里写入一条"作品-表达-情感标签"的边。这样情感分析就不再是一个孤立的接口，而是图谱内容的生产者。

3.3 Neo4j实操：导入数据的Cypher脚本与性能优化

把清洗好的诗词数据导入Neo4j，我建议用Python的neo4j驱动批量写入。一个简化版的Cypher导入示例：

// 创建诗人节点 CREATE (p:Poet {name: '李白', dynasty: '唐', id: 'poet_001'}); // 创建作品节点，并与诗人建立关系 CREATE (poem:Poem {id: 'poem_000123', title: '静夜思', content: '床前明月光...'}) WITH poem MATCH (p:Poet {name: '李白'}) CREATE (p)-[:CREATED]->(poem);

批量导入时注意几个关键优化点：

• 使用UNWIND批量提交，不要一条一条执行Cypher，速度差距是数量级的。
• 为常用属性加索引：为Poem.id、Poet.name、Tag.name建索引，遍历性能差别非常大。
• 合并导入用MERGE而不是CREATE，避免重复执行脚本时产生重复节点。

CREATE INDEX poem_id_index IF NOT EXISTS FOR (p:Poem) ON (p.id); CREATE INDEX poet_name_index IF NOT EXISTS FOR (p:Poet) ON (p.name);

一个小经验：图谱数据量在几千节点时Neo4j查询不需要任何调优，但如果你的邻接关系配置得特别深（比如"诗人-作品-意象-作品-诗人"五跳遍历），就要注意限制查询深度，否则前端图表会卡死。

3.4 图谱项目中的无效套路

我见过很多知识图谱毕设项目，"图谱"部分就是一张网页放了一堆圆圈和连线，用户只能拖动，没有实际查询路径。要避免这个问题，你必须让图谱和功能挂钩：比如用户点击诗作节点，可以弹出"相似情感的诗作推荐"，通过图谱路径计算生成结果；点击诗人节点，可以看到他常用的意象和风格演变。头像动图解决不了架构空洞。

4. DeepSeek大模型的情感分析模块：从Prompt设计到工程封装

4.1 情感分析的两种技术路线，你为什么选大模型

传统方案是用NLP模型做情感分类，比如训练一个Bert模型判断整首诗的情感是积极还是消极。这个思路在通用文本上没问题，但用在古诗词上有致命缺陷——古诗词的表达非常含蓄，"感时花溅泪，恨别鸟惊心"字面是写花鸟，实际是悲伤。传统模型很容易把"花""鸟"这种自然意象归为积极情感。大模型在语境理解和文学常识方面强得多，可以结合注释和创作背景做判断。

毕设答辩时肯定会被问到"为什么要用大模型而不是自己训练一个模型"，你的回答重点应该放在"小样本下大模型的迁移能力和语境理解优势"上。这个理由站得住脚，因为诗词情感分析本质上是需要文学常识的细粒度情感任务，你很难用一万条标注数据训练出稳定的模型，而大模型的先验知识里已经包含大量古诗文理解能力。

4.2 DeepSeek API接入：最基本的调用架构

DeepSeek开放平台提供OpenAI兼容的API接口，使用Python调用非常直接。先安装依赖：

pip install openai

这里用OpenAI官方SDK连接DeepSeek兼容接口，写法如下：

from openai import OpenAI client = OpenAI( api_key="your-deepseek-api-key", base_url="https://api.deepseek.com" ) def analyze_poem_sentiment(poem_content, poem_title="", author=""): prompt = f""" 你是一位精通古典诗词鉴赏的专家。请对下面这首古诗词进行情感分析。 要求： 1. 判断整首作品的主要情感色彩（从以下选项中选择一到两个：喜悦、悲伤、愤怒、忧愁、思念、孤独、豪迈、闲适、愤懑、感慨）； 2. 给出每个情感的置信度（0到1之间的小数）； 3. 用一句话说明判断依据； 4. 提取2到3个核心意象关键词。 作品标题：{poem_title} 作者：{author} 正文：{poem_content} 请严格按照如下JSON格式输出（不要输出其他文字）： {{"emotions": [{"name": "悲伤", "score": 0.85}], "reason": "...", "images": ["月亮", "孤舟"]}} """ response = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": "你是一个严谨的古代文学分析助手。"}, {"role": "user", "content": prompt} ], temperature=0.3, response_format={"type": "json_object"}, max_tokens=1024 ) return response.choices[0].message.content

注意几个工程细节：

• temperature必须调低（0.2到0.4），情感分解需要稳定输出，不能每次结果都不一样。
• 强制JSON输出是必须的。你要把大模型的输出直接落到数据库和图谱，不是给人看的，必须结构化成JSON再解析。
• 设置超时和重试，api_key放在环境变量或配置文件中，不要硬编码在代码里提交到Git。
• 批量分析要限速，DeepSeek的API有并发限制，同时处理几千首诗时需要写一个简单的任务队列，建议一次发5到10个请求之间，间隔0.2到0.5秒。

4.3 情感分析结果的入库与图谱联动

拿到分析结果后，需要做一个关键的"搬运"动作：把情感标签写入MySQL表，同时把作品-表达情感-情感标签的关系写入Neo4j。复用3.3里的关系类型，每次分析完成都执行以下操作：

# 解析大模型返回的JSON result_json = json.loads(response_content) # 1. 写MySQL：更新poem表的emotion_summary字段 # 2. 写Neo4j：为每个情感标签建立关系 for emotion in result_json["emotions"]: cypher = """ MATCH (p:Poem {id: $poem_id}) MERGE (e:Emotion {name: $emotion_name}) CREATE (p)-[:EXPRESSES {score: $score}]->(e) """

这个"情感分析结果反哺图谱"的循环非常推荐写进论文第三章，它是整个系统设计中最能体现"大模型与知识图谱融合"的部分。

4.4 答辩追问预备：大模型的"幻觉"问题怎么处理

大模型在抽取情感时偶尔会无中生有，比如对一首明显写景的诗硬抽出"愤懑"情绪。应对办法是加一层校验规则：如果置信度低于0.3，丢弃该情感标签；如果一首诗同时出现矛盾情感（比如同时高置信度标"喜悦"和"悲伤"），保留Top2但要在标注里写"复杂情感"。这一层规则可以当作"基于规则的约束模块"写进论文，属于系统可靠性设计的一部分，体现工程思考。

5. 推荐系统设计：基于图谱路径与情感相似度的混合推荐

5.1 推荐逻辑的整体设计思路

推荐系统是衔接图谱和分析结果的业务应用层。单一算法容易落入俗套，建议做三路并行的混合推荐：

• 基于知识图谱路径的推荐：当用户当前在看某首诗时，在Neo4j里先找到这首诗的情感标签和意象，再通过图谱查询与其共享情感或意象的其他诗作。
• 基于作者的协同推荐：当前用户历史上浏览次数最多的诗人，从图谱中取出同朝代且体裁相似的作品。
• 基于情感偏好的个性化推荐：给用户打"情感偏好标签"——他喜欢的诗歌常是"豪迈"还是"忧愁"，新推荐时优先推荐匹配其偏好的作品。

5.2 最关键的一路：用Cypher实现"图谱相似诗作"查询

核心查询思路是找到与目标作品共享情感或意象标签且未读过的诗作，按相似度排序：

MATCH (p:Poem {id: $poem_id})-[:EXPRESSES]->(e:Emotion), (p)-[:CONTAINS]->(i:Image) MATCH (candidate:Poem)-[:EXPRESSES]->(e) WHERE candidate.id <> p.id WITH candidate, count(DISTINCT e) AS shared_emotions ORDER BY shared_emotions DESC LIMIT 10 RETURN candidate.title, candidate.author, shared_emotions

这个查询的价值在于：推荐理由不是冷冰冰的算式，而是"因为我们有相同的情感表达"。在界面上可以清清楚楚地展示出来，用户和答辩评委都能直观感受到。

5.3 如何做冷启动：新用户没有行为数据怎么办

冷启动是推荐系统必须面对的经典问题。实际操作中我用两种方式解决：

• 随机游览模式：新用户进入后，先按"朝代+体裁"维度给热门榜，展示高知名度的作品，同时引导他做一次"情感偏好小测"（选三首喜欢的诗）。
• 默认偏好兜底：用全局统计中最受用户欢迎的情感标签作为冷启动偏好。

这两种方式都要写进文档，答辩时被问到"用户没有历史行为怎么推荐"就直接有答案。

5.4 推荐效果的评估：毕设里怎么证明"推荐是有效的"

毕设不要求你做离线A/B测试，但至少要有一个评估维度。我当时建议学生做一个简单的模拟点击评估：预置若干用户行为序列，将推荐系统的输出结果与专家标注的"应推荐结果"做Top-N重合率计算，指标可以写Precision@8或者Recall@10。不需要多高，60%以上基本就能自圆其说。

6. Django工程架构与可视化模块：让系统真正"跑起来"

6.1 Django项目结构怎么拆才不像一手糊的

后端工程建议用以下app划分：

poetry_system/ ├── apps/ │ ├── poems/ # 诗词数据管理，列表、详情、搜索 │ ├── poets/ # 诗人管理，诗人画像 │ ├── graph/ # 知识图谱查询接口，Neo4j数据访问 │ ├── analysis/ # 情感分析服务，DeepSeek调用封装 │ ├── recommend/ # 混合推荐逻辑 │ ├── users/ # 用户注册、登录、收藏 │ └── dashboard/ # 可视化数据聚合接口

关键设计理念是把外部依赖封装到service层。比如DeepSeek的调用封装在analysis/services/deepseek_client.py，推荐逻辑封装在recommend/services/recommender.py，view层只做HTTP路由和数据拼装。这样后期调试、换API、扩展模块都不会动到整个流程。

6.2 核心API接口设计预览

以下接口是整套系统的最小可用集，建议写接口文档时按这个表展开：

6.3 可视化模块：ECharts集成与"不露怯"的设计细节

可视化不只是一种锦上添花。你要让评委觉得"可视化是真的在服务功能"，而不是堆一堆图表。我建议做一个"古诗词数字人文看板"，包含以下视图：

• 情感分布雷达图：按朝代维度聚合情感标签（唐宋元明清），一眼看出不同朝代的情感偏好差异。
• 诗人关系图谱：基于Neo4j导出的关系数据，用EChartsgraph类型渲染诗人间的师承、并称、同朝代关系。
• 高频意象词云：统计作品中高频出现的意象词，点选词云中的意象可以联动筛选诗作。
• 时间轴作品流：按创作时间（或朝代）分布的作品数量趋势。

Django返回JSON数据，ECharts前端渲染。需要特别注意一个细节：ECharts的graph类型性能，超过300个节点后拖拽会很卡。解决方案是：图谱可视化页面只展示局部子图，比如只展示当前选中诗人的两跳邻域，而不是全图塞到前端。这不只是性能优化，也是一个很专业的图数据展示思路。

6.4 Django与DeepSeek耗时操作：别让用户界面卡死

大模型单次分析平均耗时2到5秒，有可能更久。如果之后你做了批量分析或者用户交互式分析，不能同步等待。处理思路：

• 对预定义语料（所有入库诗词），提前跑离线批处理，把结果存进MySQL字段，前端直接读缓存；
• 对新增诗词，提交到后台任务队列（用Celery或者最朴素的多线程队列），任务完成后通过前端轮询或WebSocket返回状态和结果。

对于毕设来说，实现一个"点击分析按钮后显示'正在分析中'，前端每隔2秒轮询一次任务状态"的队列机制，已经足够说明你掌握异步处理的工程能力。

7. 论文写作顺序与答辩准备的几条实用建议

7.1 建议按"数据-知识-算法-系统"四段式组织论文

很多同学写毕设论文喜欢一开始就写"系统实现"，导致前面需求分析完全变成凑字。这个题目建议的章节展开是：

1. 绪论：背景写在数字人文与传统文化的智能传播，这个高度足以撑起开题。
2. 相关技术：Django框架、知识图谱、大模型API、推荐系统、ECharts，各写两页就够了。
3. 需求分析与总体设计：用例图、架构图、功能模块图，强调情感分析与图谱的循环联动。
4. 关键模块设计：数据清洗链路、图谱建模、DeepSeek分析服务封装、混合推荐算法流程，这一章是核心亮点。
5. 系统实现与展示：配截图，每个界面配上"功能说明+数据流转说明"。
6. 系统测试：功能测试、接口测试、情感分析准确率抽样评估、推荐效果Top-N评估。

直白说，很多答辩的通过与否不在代码有多少行，而在于论文里有没有把"为什么这样做"讲清楚。

7.2 答辩时几个高概率追问的应对策略

• 问：情感分析准确率有多高？怎么评估的？答：抽取了100首诗进行人工标注对比，将大模型输出与标注结果的一致性作为指标。同时强调这不是二分类问题，用人工复核+置信度阈值的效果说明更合适。
• 问：知识图谱相比传统数据库的优势到底体现在哪里？答：多跳关系查询和路径遍历，举例子，比如"找出所有和李清照使用相同意象、且情感偏向忧愁的词人作品"这类跨实体查询，关系型数据库要多次JOIN，图谱只需要一次Cypher。
• 问：推荐算法在冷启动和稀疏性问题上有做了优化吗？答：冷启动用主题热榜和偏好小测，稀疏性上则依赖了图谱结构，即便没有用户行为，也能通过诗歌内容情感的一致性产生推荐。
• 问：DeepSeek和本地模型到底有什么区别？为什么用API？答：明确说毕业设计场景下考虑成本、迭代速度和效果稳定度，选择当时综合性价比最高的方案；同时论证了这个工程做好之后，分析服务是可以平滑更换底层模型的。

7.3 一个避坑提醒

强烈建议在开发期间就把设计图和接口文档同步维护，不要等到最后一天再补。这不仅是给答辩看的材料，更是你自己在编码过程中排查问题的重要索引。尤其是Neo4j的实体定义和关系定义表，建议以双列表格放进论文附录，这个习惯反而不容易漏节点关系，也很方便检查你是否真的把数据打通了。

另外，整个过程一定要给"大模型分析"留出一晚上的离线执行时间。我见过学生把所有接口都调通了，结果忘记给全量诗词跑情感分析和图谱关系入库，最后演示时点击推荐返回空数据，直接当场发现数据链路没闭环。强烈建议每完成一个环节就做一次端到端自测，从"选一首诗→分析情感→写入图谱→点击推荐→返回结果"，哪怕只有一条数据也要跑通全链路。