这两年咨询计算机毕设选题的同学十个里有六七个都在问同一个方向能不能把古诗词和AI结合起来做。说实话这个标题“计算机毕业设计Python知识图谱中华古诗词可视化 古诗词情感分析 古诗词智能问答系统 AI大模型自动写诗”基本把近两年NLP、知识工程和大模型应用的热门方向全都串起来了。它不是简单的CRUD管理系统也不是跑个别人写好的算法Demo而是把数据分析、知识图谱建模、自然语言处理和生成式AI完整地揉进了一个系统里——这样的项目无论是作为毕设答辩的展示面还是写进简历作为项目经历含金量都远高于那些千篇一律的“图书管理系统”“商城系统”。适合拿这个题目练手的人主要有三类。第一类是打算走数据分析或者NLP方向的本科生想靠一个差异化项目在答辩时撑住场面第二类是研究生预研阶段想提前熟悉知识图谱和大模型接口的这个题目刚好覆盖了完整链路第三类是工作后想转数据工程、AI应用方向的开发者需要一个拿得出手的“作品集”项目。无论你属于哪一类核心要搞清楚的事情其实是一样的这个系统到底由哪几块组成每一块的技术难点在哪怎么把这些模块串成一个能演示、能答辩、能写进文档的完整闭环。下面我按自己在类似项目中摸爬滚打的经验把这个题目的技术架构、落地方案和踩坑点完整拆给你看。1. 内容整体设计与思路拆解这个项目表面上看起来模块很多容易让人一头雾水但拿到手第一步不是写代码而是想清楚整个系统的数据流。古诗词只是一个载体背后的核心其实是“如何把非结构化的文本变成可以被查询、计算和生成的结构化知识”。1.1 核心需求解析拆开标题系统的核心功能可以分成五个相互独立又彼此关联的模块知识图谱构建与可视化把诗人、诗作、朝代、意象、词牌名等实体和它们之间的关系抽取出来存进图数据库再以力导向图或关系图的形式展示出来。古诗词情感分析对诗词的喜怒哀乐倾向做分类或极性打分可以精细到诗句等级也可以聚合到整首诗。古诗词智能问答用户用自然语言提问系统解析意图并转换为图查询语句返回答案。例如“李白写过哪些诗”“带‘月’的诗有哪些”。AI大模型自动写诗调用大模型接口或微调一个小规模生成模型根据给定的主题、风格或首句自动生成古体诗。数据可视化看板诗词数量随朝代的分布、高频意象统计、诗人创作力排行等统计图表。这五个模块如果平行开发很容易出现“代码写了一堆但系统看起来稀碎”的局面。更合理的做法是把它看成一条流水线数据层 → 知识层 → 应用层。数据层负责处理原始诗词文本知识层负责把文本转为图谱和情感标签应用层负责问答和写诗。这样每次只关注一层代码结构也清晰得多。毕设答辩的时候老师最喜欢问的就是“你这个系统的架构是怎样的”如果你能按这个逻辑把图一画条理马上就出来了。1.2 方案选型背后的逻辑选技术栈这件事很多人容易陷入“什么新用什么”的误区。这个项目的技术选型我的建议是围绕易实现、易演示、易解释三个原则来定。知识图谱存储Neo4j 是首选。原因在于Neo4j对中文支持好、可视化界面开箱即用Browser里直接能看到图结构而且Cypher查询语言比RDF体系的SPARQL简单得多答辩演示时写一行查询就能出图效果非常直观。用关系型数据库也能做图谱但连表查询的复杂度会高一个量级解释成本也高。后端框架FastAPI 或 Flask 都可以。如果项目里接了AI大模型的异步调用FastAPI的异步特性会让你舒服很多如果更熟悉传统同步写法Flask也够用。不要在这里纠结太久两个都行关键是别把业务逻辑全堆在路由函数里。前端可视化ECharts D3.js 的组合基本是这个题目的固定答案。ECharts负责统计图表柱状图、饼图、词云D3.js负责知识图谱的自定义力导向布局。有些同学想用现成的图谱可视化插件比如Vis.js或AntV G6也行但D3的自由度最高答辩时从节点颜色映射到边的粗细都能自定义可以讲的东西更多。情感分析轻量方案用 SnowNLP 或 BosonNLP 的预训练模型进阶方案是自己在古诗词语料上微调一个基于BERT的分类模型。这里有个必须提前知道的坑——现代汉语的情感分析模型在古诗词上直接使用时准确率会明显打折因为古汉语的词汇和句法与白话文差异太大。所以常见做法是先用现有工具打个基础分再创建一个简单的领域规则做校正。这个“规则模型”的混合方案在毕设里比单纯刷模型精度更讨巧因为老师会觉得你有工程化思维。大模型写诗优先用现成大模型API比如智谱、Qwen、DeepSeek等国内模型而不是自己训练。毕设的时长和算力基本支撑不起从零训练一个写诗模型。大模型API的优势在于你只需要设计好Prompt和约束条件就能获得相当高质量的产出。在系统设计里把这一层封装成独立的“写诗服务”后面想换成别的模型或本地部署的模型改动成本都很低。1.3 系统模块边界划分我在设计这类系统时习惯把工程结构按模块边界切开以下是一个经过验证的目录划分思路数据采集与预处理模块负责从公开数据集比如全唐诗、全宋词或爬虫获取原始数据清洗后存入MySQL作为原始数据仓库同时输出标准JSON给上层使用。知识图谱构建模块读取预处理后的结构化数据完成实体识别、关系映射与去重合并最后写入Neo4j。知识查询与问答模块实现意图识别和槽位提取把自然语言转化为Cypher查询模板并提供结果的格式化返回。情感分析模块对诗作或诗句进行情感打分结果写入MySQL或者在查询时实时计算。数据可视化模块通过后端Restful API向前端提供数据前端用ECharts和D3.js完成图谱和统计图表的渲染。智能写诗模块封装大模型API调用设计Prompt模板处理生成结果的校验和美化。模块边界划分清晰以后你可以一个人并行开发其实还是得按依赖关系串行推进也可以在组队时把任务拆给队友。更重要的是毕业设计文档里“系统设计”这一章几乎可以直接复用这套模块图。2. 核心算法原理与知识图谱构建详解如果说整个系统是一个建筑那么知识图谱毫无疑问是承重墙。很多毕设中的知识图谱说穿了就是“把数据导入Neo4j然后导出个图”实体之间的关系非常粗糙。但如果能把知识图谱这层做扎实系统质量和答辩深度都会有质变。2.1 古诗文本的实体识别与关系设计古诗词不像新闻或维基百科那样有一套现成的NLP标注工具直接调用中文分词加命名实体识别比如用HanLP或LTP效果通常不理想。问题出在词性上——古诗为了对仗和韵律语序和用词高度灵活“春风又绿江南岸”里的“绿”是动词普通分词器很可能标成形容词。所以在知识抽取环节“正则词典”的混合策略远比纯模型靠谱。你需要构建三个基础词典诗人词典包含诗人姓名、字号、别称例如“青莲居士”、“东坡”。意象词典包含常见的古诗词意象及其变体“月”包含“明月”、“残月”、“弯月”“酒”包含“浊酒”、“清酒”、“金樽”。词牌名词典用于宋词实体的识别。有了词典后实体识别的基本逻辑是这样先从唐诗宋词数据里按书名号或分卷信息抽取出诗作标题与正文然后对正文做关键词匹配匹配到诗人词典就建立诗人实体匹配到意象词典就建立意象实体。朝代信息可以从诗人信息里关联出来。关系设计是整张图的灵魂。我在项目中实际使用的核心关系有(诗人)-[:创作]-(诗作)(诗作)-[:属于]-(朝代)(诗作)-[:使用意象]-(意象)(诗作)-[:采用词牌]-(词牌名)(诗人)-[:师承]-(诗人)这一项要看数据支持情况不是必选(意象)-[:关联]-(意象)表达意象之间的共现关系例如“月”与“思乡”你不需要搞得太复杂关系太多会让图变得很乱演示效果反而差。但“诗作-使用意象”这条关系一定要有因为它是后面做情感分析、问答和可视化的重要支撑。有了“使用意象”这种关系用户才能查“带‘月’的诗有哪些”也才能做“高频意象TOP20”这种统计。2.2 Neo4j图模型与Cypher查询实战Neo4j的安装不多展开下载社区版、起服务、打开7474端口就能用。重点是schema的设计。我建议实体标签设成**诗人Poet、诗作Poem、朝代Dynasty、意象Image、词牌Cipai**这五个就足够。每个节点的属性别贪多但关键字段要留全。一个诗作节点可以这样设计CREATE (p:Poem { title: 静夜思, author: 李白, dynasty: 唐, content: 床前明月光疑是地上霜。举头望明月低头思故乡。, translated_content: ..., tags: [思乡, 月] })入库时用Python的py2neo或neo4j官方驱动批量执行MERGE而不是CREATE这是经验之谈。CREATE会在数据重复导入时生成大量重复节点MERGE会先检查是否存在相同属性的节点存在则不新建能有效保持图的唯一性。常用查询的Cypher语句不妨提前准备好既是演示素材也是问答系统的底层语法查询某位诗人的全部作品MATCH (poet:Poet {name: 李白})-[:创作]-(poem:Poem) RETURN poem.title, poem.content查询含有“月”意象的诗作及其作者MATCH (img:Image {name: 月})-[:使用意象]-(poem:Poem)-[:创作]-(poet:Poet) RETURN poet.name, poem.title LIMIT 20查询与“月”共现频率最高的其他意象MATCH (img:Image {name: 月})-[:使用意象]-(poem:Poem)-[:使用意象]-(other:Image) WHERE other.name 月 RETURN other.name, COUNT(*) AS freq ORDER BY freq DESC LIMIT 10这批Cypher语句既是知识层能力的展示也是后续问答系统组装答案用的核心查询模板。2.3 情感分析模型的领域适配古诗词情感分析是这个项目里最容易“看起来简单但做起来翻车”的模块。直接拿SnowNLP对“大漠孤烟直长河落日圆”做情感判断大概率会得到偏中性的分值。可这首诗的情感基调明显带着孤寂和壮阔并存的复杂情绪。这不是模型笨而是训练数据严重不匹配。一个在毕设中既可控又有解释力的做法是构建一个三层结构的情感分析管线第一层关键词与意象规则打分。整理一份“积极意象词表”春、花、朝阳、喜、笑和“消极意象词表”秋、霜、孤、愁、泪、残按诗句命中的词加权计分。第二层基于预训练模型的概率打分。用SnowNLP或者huggingface上的中文情感分析模型拿到一个0到1的得分。第三层规则与模型结果的融合输出。可以简单加权也可以用权重加阈值的方式 当规则分强烈比如命中3个消极意象词时以规则分为主当规则分不显著时以模型分为主。融合之后把每首诗的情感映射为“积极、中性、消极”三分类同时给一个连续分值。这样的结果比直接用现成工具可视化时更有层次的能支撑“唐代诗词情感分布变化趋势”这类统计图答辩时能讲出很多故事。情感分析的结果要存回MySQL因为它是结构化、低频更新的标签查询时按朝代或诗人聚合出情感分布曲线给前端渲染。这部分可以考虑做成离线批处理避免每次请求都跑一次模型。3. 实操过程与核心功能模块落地整个系统最能打动人的一定是能现场演示的功能。理论上讲得再漂亮实操一跑就露馅的情况每年答辩都有不少。这一节我把每个核心功能的具体落地步骤和关键配置走一遍。3.1 古诗数据采集与标准化预处理数据是全部模块的地基。这里我强烈建议优先用公开的整理好的数据集比如“全唐诗”的JSON/CSV版本网上有很多开源的中文古诗词数据集通常包含标题、作者、朝代、正文、注释等字段。自己写爬虫去爬古诗文网虽然也是一个选项但耗时、容易被反爬拦截而且清洗的工程量会拖着整个项目进度。拿到原始数据后标准化的流程分四步走格式规范化把繁体统一转简体全角符号转半角去掉多余空格、换行以及注释中混杂的OCR错误字符。字段抽取从原始文本中抽取出“标题、作者、朝代、正文、诗体五言/七言/绝句/律诗”等结构化信息。诗句切分按句读逗号、句号把正文切分为单句为后续意象匹配和情感分析提供细粒度输入。数据去重同一首诗在不同数据集中可能重复出现以“标题作者正文”作为唯一键去重。这一步完成之后你会得到一张干净的诗句级明细表。这个表既是知识图谱的输入也是情感分析和问答的数据底座。要特别留意保存数据处理脚本这不仅能体现工程能力答辩讲“数据来源和清洗逻辑”时也有的放矢。3.2 可视化看板的数据接口设计前后端数据交互建议统一走RESTful API不要在后端模板里直接渲染前端页面。接口风格要统一、语义要清楚比如GET /api/poet/{name}/poems获取诗人的作品列表GET /api/analysis/sentiment?dynasty唐获取指定朝代的情感分布GET /api/graph/poem/{id}/relations获取某首诗在图谱中的关联实体GET /api/statistics/top_imagerys获取高频意象统计POST /api/ask接收问题返回问答结果POST /api/write_poem接收主题和风格参数返回生成的诗词这里有个后端工程上的体会定义一个统一响应结构比如{code: 0, message: success, data: {...}}所有接口都按这个结构返回前端处理逻辑会简单很多。很多同学做毕设时接口风格五花八门前端调试起来非常痛苦。3.3 知识图谱可视化的渲染方式知识图谱的可视化是本项目演示的重头戏。用D3.js实现一个力导向图的方法网上很多但有几个关键参数直接影响演示效果。节点大小、颜色和标签的映射逻辑是第一个关键点。我建议节点大小按实体的“连接度”度中心性映射连接越多的节点越大颜色按实体类型映射诗人一类颜色诗作一类颜色意象一类颜色这样一眼就能看出图的结构。力导向图的charge强度和linkDistance参数需要反复试太近会糊成一团太远则整图散架。前端加载大图时一个常见的性能瓶颈是一次性渲染成千上万个节点浏览器会卡死。解决思路是“分层下钻”第一层只渲染“朝代-诗人”两级关系整体看起来很简洁点击某个诗人节点后再动态加载该诗人的“作品与意象”子图。这样做既免去了性能问题也让演示过程像讲故事一样有层次感先看全貌再落到细节。答辩时这一手非常加分。3.4 智能问答系统的意图识别与查询生成问答模块包含几步典型的自然语言处理流程但别指望用多复杂的模型。把意图预定义为有限的几类就够用查询诗人的作品查询含有某意象的诗查询某朝代的诗歌统计查询某诗人的代表作查询某句诗的出处意图识别用规则关键词即可。比如出现“有哪些/写过/的作品”归属到前两类出现“统计/分布/多少”归属到统计类。槽位提取做两件事抽诗人名对着诗人词典匹配抽意象词对着意象词典匹配。整个问答逻辑是这样跑的先做规则匹配和词典匹配 → 得到意图和槽位 → 从意图模板库中取出对应的Cypher模板 → 填充槽位值 → 执行查询 → 对查询结果做格式化 → 返回给前端。举个例子用户问“李白的诗里常用什么意象”系统解析出诗人“李白”意图为“诗人高频意象”对应CypherMATCH (poet:Poet {name:李白})-[:创作]-(poem:Poem)-[:使用意象]-(img:Image) RETURN img.name, COUNT(*) AS freq ORDER BY freq DESC LIMIT 10如果词典匹配不到槽位值就让前端提示“暂时无法回答”或者调用大模型做一次兜底解析。这个兜底设计很实用既能覆盖长尾问题也能避免答辩时遇到预料之外的问题而卡壳。3.5 AI大模型写诗功能的Prompt设计与接口封装写诗功能是大模型能力的集中体现也是整个项目里最容易出效果、也最容易翻车的部分。翻车原因大多是提示词设计不到位输出的东西既不像古诗也没有主题相关性。先把写诗服务封装成独立的类或模块。以调用常见国内大模型API为例关键在于三点系统提示词、用户提示词、生成参数。一个我自己调过很多次、效果比较稳定的Prompt模板结构是[系统角色] 你是一位精通中国古典诗词创作的诗人擅长五言绝句、七言绝句、律诗等多种体裁。 [用户要求] 请以“秋思”为主题创作一首七言绝句。 要求 1. 符合七言绝句的格律每句七字共四句 2. 诗中尽量使用“月、风、落叶”等秋季意象 3. 表达思念和孤寂的情感 4. 不需要解释只需要输出诗本身和标题。在API请求参数里temperature建议设置在0.7到0.9之间。太高容易乱来出现生造词太低则容易流于平庸缺少诗意。max_tokens根据诗体控制五言绝句四句共20字加上标题和可能的注释设定256个token足够律诗可以设到512。生成结果的校验也值得做好。常见问题是生成结果不是古诗格式比如句子长度对不齐。一个简单的校验函数可以这样写按换行或标点切分输出检查每一句是否达到指定字数七言每句7字五言每句5字不达标则重新调用一次接口或者提示用户重新输入。校验逻辑虽简单但能避免演示现场翻大车。前端交互上给用户两个可配置项主题词必填和风格倾向可选豪放、婉约、田园、边塞等。把风格作为Prompt里的关键词约束大模型的输出会更有辨识度。这里再分享一个实用的小技巧如果把生成的诗词和知识图谱联动比如生成“月”主题的诗后自动在页面上展示知识图谱中“月”相关的真实古诗词和意象子图这种“AI生成与真实知识交叉验证”的联动设计会让系统显得非常完整答辩老师印象分会高很多。4. 常见问题与排查技巧实录这类综合型项目开发过程中遇到的坑远比想象中多。我把自己经历过的和身边人反馈过的典型问题整理一下你在动手前先看一遍能省很多无用功。4.1 数据入库与图谱构建问题问题Neo4j导入数据太慢。逐条写Cypher的CREATE语句大批量导入时速度会非常感人。解决办法是使用UNWIND批量导入方式一次把一批数据作为参数传入一条Cypher语句用UNWIND $batch AS item MERGE ...完成多条写入性能能提升一个数量级。问题同一诗人出现多个节点。原因是不同数据源里诗人名字写法不同“李白”和“李太白”。解决办法是在诗人词典中增加一个“别名映射表”入库前先做姓名归一化把别称统一映射到本名。问题图谱关系全部指向空节点。出现这种情况基本是实体名匹配失败比如数据清洗时把“李白”清洗成了“李 白”。这类问题要靠入库前打印一批抽样数据人工检查解决不要指望完全自动化。4.2 情感分析与问答模块问题问题情感分析结果严重偏中性。归因于现代汉语模型不擅长古汉语。可以增加领域规则词表和加权权重实测下来能明显拉升消极诗和积极诗的分差。问题问答系统答非所问。大多因为意图分类错误。典型的如“李白的诗有哪些”被识别成意象查询。建议对每个意图的正则表达式做至少10个不少于变体的测试覆盖常见的口语化问法。问题Cypher模板传参注入导致查询失败。当用户输入包含特殊字符如引号、括号时直接拼接Cypher容易语法错误。务必使用参数化查询把槽位值作为参数传入例如MATCH (poet:Poet {name: $name})这既是稳定性问题也是安全底线。4.3 写诗模块与大模型调用问题问题生成内容出现“不像诗”的现代词。在Prompt中补充“避免现代词汇保持文言风格”能改善同时可以把temperature调低一点或增加“参考范例”选一首古人同主题的诗放在Prompt里作为格式示范模仿效果会更好。问题请求大模型接口超时。API调用网络波动很常见。前端要设置loading状态后端要对异常设置超时重试和兜底返回。兜底可以返回一句准备好的古诗词或一句“创作失败请稍后再试”不要直接抛500。问题本地没有可用的大模型环境。不要把时间耗在部署开源大模型上毕设阶段使用云端API是性价比最高的选择。只要注意接口封装得够好文档里写明未来可以无缝替换为本地模型答辩时就不会被扣分。4.4 可视化与整体联调问题问题前端图表加载慢或白屏。绝大多数情况是接口数据量过大一次性把整张图所有节点返回给前端。解决思路前面提过——分层下钻、按需加载数据不冗余是基本工程素养。问题联调接口跨域。如果前后端分离部署跨域是必踩的坑。后端加一个CORS中间件允许本地开发域名访问即可。这个不起眼的小问题每年卡住一堆人。问题演示环境数据库没启动。答辩前一定要做一次冷启动演练从Neo4j服务启动、MySQL服务启动、后端启动、前端启动全部走一遍。很多项目平时能跑一到答辩现场就因为环境依赖问题崩了这一点切记。5. 扩展方向与项目进阶建议基础版本跑通以后这个项目还有很大的扩展空间。如果你时间有余或者想在答辩中讲出更多亮点以下几个方向优先级都比较高大模型与知识图谱融合问答现有的问答是规则化的遇到不在模板内的问题就只能答“不知道”。可以考虑用大模型对用户问题做意图识别和槽位抽取再用抽取出的实体去查询知识图谱。这能让系统看起来真正“智能”起来也贴近目前工业界的RAG检索增强生成范式。诗词风格迁移与赏析生成在写诗模块之外增加“诗词风格分析”和“白话赏析自动生成”。对一首给定的诗让大模型生成一段赏析文字配合情感分析模块呈现能更突出AI能力。可视化加入时间轴和地图维度把诗人出生地、仕宦地映射到地图上加上年代时间轴做“诗人生平轨迹图”。需要额外采集地理信息但维度一加系统深度立刻不一样。模型层面微调一个古诗文专用Embedding或情感模型如果后面要投递NLP岗位这条路径很值得展示。在预训练模型基础上用收集的古诗词语料做增量预训练或者微调哪怕只是小规模的实践写进简历也是非常扎实的项目点。扩展方向不用贪多挑一个和你的职业规划最契合的做深做透就够了。6. 开发排期与答辩准备建议一个完整版本最好控制在8到10周左右。这里给一个排期参考第1周数据采集、清洗、入库。这一步的时间不能省数据质量决定一切。第2周知识图谱实体关系设计与数据导入Neo4j。第3周后端框架搭建完成基础API和统一的响应结构。第4周知识图谱可视化与统计看板的前端开发。第5周情感分析模块开发与结果入库。第6周问答系统规则引擎与Cypher模板开发。第7周大模型写诗模块开发与Prompt调优。第8周前后端联调、Bug修复、演示数据准备。第9周毕业设计文档撰写、PPT制作、答辩演练。文档方面别把LW文档当成事后补的作业。建议每完成一个模块就同步写一篇对应章节最后汇总微调这样文档质量和开发一致性都会好很多。答辩前的系统演示至少准备三条主线一是知识图谱查询与可视化路线讲数据如何变成知识二是情感分析与统计分布路线讲分析能力三是问答和写诗路线讲智能交互。三条线分别对应数据、算法、应用基本覆盖了答辩组老师最关心的全部维度。最后再分享一点个人体会这个项目真正有价值的地方不在于技术有多前沿而在于它完整模拟了一个AI应用从数据到知识再到智能服务的生产链路。把你在这个链路里解决的问题、对比过的方案、踩过的坑如实记录下来就是最扎实的毕设作品。很多东西只有亲手做一遍才会发现网上那些教程省略了多少关键细节——比如一条Cypher语句的性能差异、一个Prompt调参对输出质量的直接影响。做项目的过程本身就是把知识图谱、NLP、大模型应用这些抽象概念变成肌肉记忆的过程。祝你顺利跑通全链路答辩发挥出自己的真实水平。