这阵子帮几个毕设方向的学生看题目发现“Python知识图谱中华古诗词可视化、古诗词情感分析、古诗词智能问答系统、AI大模型自动写诗”这类缝合型题目出现频率特别高。很多同学一看标题就以为是个“爬数据画图”的活实际动手才发现这里头装了知识图谱建模、中文NLP、图数据库、前端可视化、还有文本生成一整套链路。这篇就把这个项目从头到脚拆一遍包括技术选型思路、图谱设计、情感分析怎么做才贴合古诗词场景、问答系统怎么把自然语言翻译成图查询、写诗模块的两种路线以及毕业设计答辩时最容易暴露的坑。打算做这个题目的朋友可以直接拿这份拆解当施工图。1. 项目全貌这不是“画张图”是一条完整的NLP图数据库技术链路1.1 一个毕业设计题目的真实工作量先泼盆冷水。很多同学看到“古诗词可视化”五个字第一反应是做个网页左边放首诗右边配个图再加点柱状图、饼图。真这么做工作量撑不过两周答辩时候评委三个问题就能问穿。实际上这个题目拆开来看是四个独立的模块每个模块单独拿出来都可以当一个小项目知识图谱构建定义诗人、诗作、朝代、意象、词牌名等实体以及“写作”“属于”“包含”等关系数据清洗后导入图数据库。情感分析对诗词文本做情感分类不是简单的正负二分类而是要识别出思乡、怀古、感伤、豪放、闲适这类细粒度情感。智能问答用户输入“李白写过哪些诗”“带‘月’的诗句有哪些”系统把自然语言转换成图数据库查询语句返回结构化答案。自动写诗给出主题词生成五言或七言绝句这一块既可以用传统生成模型也可以接大模型API。这四个模块还要用Web系统串起来后端给接口前端做可视化和交互。所以这压根不是纯前端项目也不是纯算法项目而是一个全栈算法数据工程的综合项目。也正因为这样它才值得作为毕业设计选题——覆盖面够广每一层都有东西可讲。1.2 整体架构与分层设计我通常建议学生按照“数据层-存储层-服务层-展示层”四层来组织系统。数据层负责语料采集和清洗存储层用关系型数据库配合图数据库服务层用Python写业务逻辑和算法接口展示层用Web前端做可视化页面。这里的关键决策是图谱数据必须用图数据库不能用MySQL硬扛。原因很简单古诗词知识图谱的核心价值在于“关系”。诗人与诗作之间的“创作”关系、诗作与意象之间的“包含”关系、诗人与朝代之间的“生活于”关系这些关联在MySQL里要么靠大量join表要么靠JSON字段硬塞查询复杂不说可视化成关系图的时候还得自己去拼节点和边的数组非常别扭。Neo4j这类图数据库原生支持节点和关系的遍历前端要关系图数据时直接查询出节点和边的结构化JSON就能用。整个项目跑起来的架构大致是这样语料来源公开的古诗词数据集或站点整理后的结构化数据数据预处理Python脚本清洗、去重、补全朝代和作者信息存储层Neo4j存图谱MySQL或SQLite存用户交互记录等业务数据算法层情感分析模型、问答意图识别模块、写诗生成模块服务层Flask或FastAPI提供REST接口展示层前端页面集成ECharts可视化、问答交互界面、写诗结果展示1.3 可交付成果的拆解毕设最终要交源码、说明书文档、答辩PPT和演示讲解。这几个交付物对应的东西不太一样。源码就不说了是整个系统的实现说明书文档要写清楚背景、需求分析、系统设计、数据库设计、算法原理、测试结果这块很多同学容易写得像流水账后面我会讲哪些内容放进文档里是加分项PPT是答辩用的要突出系统架构图、技术亮点和运行效果演示讲解则是准备一个完整的操作流程从首页统计到图谱浏览从问答到写诗一套走下来。2. 知识图谱建模与数据落地从语料清洗到Neo4j入库2.1 实体与关系体系怎么设计知识图谱建模是整个项目的地基地基没打对后面问答和可视化全跟着歪。古诗词领域最常见的实体类型就那几类实体类型属性字段说明诗人姓名、字号、生卒年、朝代、籍贯一诗一作者作者节点独立出来诗作标题、正文、格律五言/七言、体裁正文是情感分析和写诗的关键语料朝代名称、起止时间作为时间维度支撑“唐代诗人有哪些”这类查询意象名称、类别自然/器物/植物/天文“月”“柳”“酒”“江”这类高频意象词牌名名称、格式说明词作品关联词牌和诗作区分开关系类型我建议保持精简关系越复杂数据构建越费劲问答的时候也容易出环。核心关系就这几种诗人-创作-诗作诗人-生活于-朝代诗作-属于-朝代诗作-包含-意象这个关系需要从正文里抽取意象词有人还会加“诗作-引用-诗作”“诗人-师承于-诗人”之类的关系这些属于进阶内容如果语料里有可靠的数据源可以加没有的话宁可不加编出来的关系在答辩时会成为硬伤。这里最关键的设计决策是“意象”这个实体。它是可视化和问答的亮点来源。古诗里的“月”往往带思乡意味“柳”带送别意味“酒”带豪放或愁绪如果我们只是把这些词当作普通词语存起来那图谱就只是个百科结构。把它们抽出来作为独立实体就能支撑“包含‘月’的诗句有哪些”这类有意思的查询也能支撑后面的情感分析。2.2 数据清洗要点古诗词文本的特殊性数据清洗是这项目最枯燥但最不能跳的环节。古诗词文本有几个典型的坑第一个是繁体与异体字问题。同一首诗在不同来源里可能一个字繁体一个字简体不统一会导致后续查询和情感分析都出问题。我的做法是统一转简体同时保留原文字段做展示用。第二个是标点符号不一致。有的数据源用中文全角标点有的用英文半角还有的直接没有断句。这个必须统一格式化否则切分诗句、统计字数都会乱。第三个是诗题与正文的区分。很多数据集里诗的标题是第一个字段正文是第二个字段但有的来源标题里混了注释正文里混了序言清洗时要把这些杂质去掉。第四个是作者姓名差异。同一个诗人可能有字、号、别称比如李白字太白、号青莲居士如果数据来源混用了这些称呼不建别名映射的话图谱里就会出现多个看似不同其实是同一个人的节点。我建议在诗人实体属性里增加“别名列表”字段清洗时做归一化映射。清洗完成之后数据就变成了一个标准格式诗人表、诗作表、朝代表、意象词表、诗作-意象关联表。这批结构化数据既可以导入MySQL也可以后续批量导入Neo4j。2.3 入库流程与Cypher批量导入数据量如果在万首级别逐条插入Neo4j会非常慢。正确姿势是用Cypher的批量导入机制。先建约束和索引CREATE CONSTRAINT poet_name IF NOT EXISTS ON (p:Poet) ASSERT p.name IS UNIQUE; CREATE CONSTRAINT poem_title IF NOT EXISTS ON (p:Poem) ASSERT p.title IS UNIQUE; CREATE INDEX dynasty_index IF NOT EXISTS FOR (d:Dynasty) ON (d.name);注意约束的存在是有必要的。没有唯一性约束的话同一个诗人可能因为数据重复被创建两次节点图谱就出现“分身”。批量创建诗人的示例LOAD CSV WITH HEADERS FROM file:///poets.csv AS row MERGE (p:Poet {name: row.name}) SET p.alias row.alias, p.dynasty row.dynasty, p.birth_year row.birth_year, p.death_year row.death_year注意这里用的是MERGE而不是CREATEMERGE会先查重再创建防止重复节点。诗作和意象的关系建立起来之后整个图谱的查询能力就出来了。比如“李白诗作里包含‘月’意象的有哪些”Cypher可以这么写MATCH (p:Poet {name:李白})-[:CREATED]-(poem:Poem)-[:CONTAINS]-(image:Image {name:月}) RETURN poem.title, poem.content LIMIT 10手写一遍这种查询就会理解为什么这个题目值得用图数据库——这种多度关系遍历在关系型数据库里要写三个表join在图数据库里就是两条边的路径匹配。入库前面还有一个容易忽略的步骤就是把诗人-朝代、诗作-朝代这两类关系先建好。很多同学在可视化的时候发现“唐代诗人分布图”画不出来就是因为数据里没有朝代维度的关系或者朝代名字不统一有的写“唐朝”有的写“唐代”。建议在清洗阶段就统一朝代名称并建立诗人到朝代的关联。3. 情感分析为什么通用情感词典在古诗词上行不通3.1 古诗词情感不是“正负两极”做情感分析的第一反应往往是套用通用情感分析工具比如先做个情感分类输出“积极/消极/中性”。这个思路放在古诗词上会非常尴尬。举个例子杜甫的“感时花溅泪恨别鸟惊心”用通用情感模型大概率判定为负面这没错。但“孤舟蓑笠翁独钓寒江雪”呢表面意象是孤独寂寥但在诗学传统里这种“冷清”恰恰体现着人格的孤傲与超脱你要说它是消极情绪就误会了整首诗的审美取向。所以古诗词情感分析需要设计一套符合诗词审美传统的情感维度体系。我在项目中采用的是八维度情感标签情感维度典型情绪关键词示例诗句风格思乡故乡、归、家书、明月“举头望明月低头思故乡”送别折柳、离亭、酒、泪“劝君更尽一杯酒西出阳关无故人”怀古金陵、旧事、兴亡、残碑“旧时王谢堂前燕飞入寻常百姓家”感伤落花、孤雁、鬓霜、病骨“感时花溅泪恨别鸟惊心”豪放长剑、沧海、鲸吞、万卷“君不见黄河之水天上来”闲适采菊、垂钓、煮茶、山居“采菊东篱下悠然见南山”羁旅客舟、孤馆、残灯、驿路“姑苏城外寒山寺夜半钟声到客船”爱情红豆、罗帐、尺素、西楼“红豆生南国春来发几枝”这套体系的好处是问答和可视化都能直接复用。比如用户问“有哪些表达思乡之情的诗”直接把情感分析结果当索引来查就行。3.2 词典打分最稳的落地方式对于毕业设计我强烈建议第一版先做情感词典加权打分而不是一上来就训练深度学习模型。原因很现实古诗词语料没有足够多的标注数据训练样本不够深度学习模型很容易过拟合而且调参周期长答辩时说不清楚训练过程反而扣分。词典法的基本思路是三步第一步构建古诗词领域情感词表。可以结合通用中文情感词典的基础词再手工补充一批古诗特有的情感意象词。注意这里的“情感词”不只是“悲”“喜”“愁”这类直接情绪词还包括有情感负载的意象词——“残月”带凄清“扁舟”带漂泊“青天”带豪迈。第二步对每首诗的正文做分词统计情感词出现次数和加权得分。每个情感词可以映射到八个维度中的一到两个并给一个权重。第三步归一化处理后取得分最高的维度作为这首诗的情感标签同时把所有维度的得分存下来作为情感分布特征。代码层面大概是这样sentiment_lexicon { 故乡: {思乡: 1.0, 感伤: 0.4}, 孤舟: {羁旅: 0.8, 感伤: 0.6}, 长啸: {豪放: 0.9}, 采菊: {闲适: 1.0}, } def analyze_sentiment(text): scores {label: 0.0 for label in sentiment_labels} for word in segment(text): if word in sentiment_lexicon: for label, weight in sentiment_lexicon[word].items(): scores[label] weight total sum(scores.values()) if total 0: return [闲适], scores # 兜底标签 scores {k: v / total for k, v in scores.items()} label max(scores, keyscores.get) return [label], scores分段和分词需要引入中文分词工具。这里有个细节古诗文分词和现代文分词不太一样一些工具对“孤舟”“残月”这类组合词识别得并不好建议在词典里预置这些组合词先做最长匹配再交给分词器处理效果会好很多。词典法的局限也明显它不能理解诗句的语境比如“东边日出西边雨道是无晴却有晴”“晴”谐音“情”词典法只会把它当成天气词。这种东西要识别就得靠更高级的模型但对毕业设计来说词典法能覆盖大部分典型诗作跑出可解释的结果已经够用了。3.3 进阶方向如果想让情感分析更像“论文工作”如果想在情感分析上增加一些技术含量可以走“词典打分规则优化小模型校准”的组合路线。规则优化是指处理否定词和转折词“不见使‘不见’就是否定后面如果跟一个正向词整体要反转或减弱。小模型校准则是用少量人工标注数据微调一个轻量级文本分类模型让模型学习词典法覆盖不了的语境特征。答辩的时候与其吹“我用深度学习做到95%准确率”不如说“我对比了词典法、规则增强和模型校准三条路线最终采用组合策略在古诗词情感分类上人工评估准确率达到多少”。这种对比表述在评审那里更可信。4. 智能问答把自然语言“翻译”成图查询4.1 意图识别与槽位提取问答模块的外部表现是把用户问题映射到图谱查询。内部本质就是两步判断用户想问什么抽取出查询条件。我把意图分成几类每一类对应一类模板和查询逻辑意图类型用户问法示例需要抽取的槽位生成的查询逻辑查询作者作品“李白写过哪些诗”诗人名匹配诗人节点查询其创作的诗作查询意象诗句“带‘月’的诗句有哪些”意象词匹配意象节点查询包含该意象的诗句查询朝代诗人“唐代有哪些著名诗人”朝代名匹配朝代节点查询该朝代的诗人查询作品详情“静夜思的全文是什么”诗题匹配诗题返回正文和作者查询情感诗作“有哪些表达思乡之情的诗”情感标签查情感分析结果索引写诗“以梅花为主题写一首诗”主题词/格律调用写诗模块实现这类意图识别不需要上复杂的深度学习模型基于规则模板的匹配器通常就能覆盖八成以上问法。核心做法是对用户输入做分词和关键词抽取与意图关键词表进行匹配。def parse_question(question): if any(name in question for name in poet_names): poet extract_name(question, poet_names) return {intent: BY_AUTHOR, slots: {poet: poet}} if re.search(r[“\\‘’](.?)[”\\‘’].*?(诗句|诗|词), question): image extract_quoted_content(question) return {intent: BY_IMAGE, slots: {image: image}} if 朝代 in question or re.search(r(唐|宋|元|明|清)代, question): dynasty extract_dynasty(question) return {intent: BY_DYNASTY, slots: {dynasty: dynasty}} ...这里有两个实操要点。一是同义词和别名映射。用户很可能问“诗仙写过哪些诗”“青莲居士的代表作”系统要能映射到“李白”。所以在处理输入之前先做一个实体别名归一化把所有诗人别名、字、号预先映射到标准名。这个映射表在数据清洗阶段就该建好问答模块直接复用。二是模糊匹配与纠错。用户可能打错字比如“李白”打成“李百”。可以用字符串相似度匹配如编辑距离和拼音匹配做兜底。我的建议是做一个“输入提示-候选确认”的交互当系统不确定时返回“您是想查[李白]的作品吗”让用户确认这样比静默返回空结果体验好得多。4.2 从槽位到Cypher的转换意图和槽位提取出来之后就需要生成Cypher查询语句。这一层要非常小心因为Cypher语句拼错一个小括号、写错一个属性名查询就直接崩掉。我建议封装一个查询构建器而不是在业务代码里到处拼接字符串def build_cypher(intent, slots): if intent BY_AUTHOR: return f MATCH (p:Poet {{name: {slots[poet]}}})-[:CREATED]-(poem:Poem) RETURN poem.title AS title, poem.content AS content if intent BY_IMAGE: return f MATCH (i:Image {{name: {slots[image]}}})-[:CONTAINS]-(poem:Poem) RETURN poem.title AS title, poem.content AS content LIMIT 20 ...千万不要把用户输入直接拼进Cypher做了复用层之后还要做一层输入清洗把引号、分号、注释符这类特殊字符过滤掉防止查询注入。4.3 答案组装与多轮策略查询返回的是节点数据但用户看到的是自然语言答案。答案组装要把图谱查询结果翻译成通畅的中文句子。比如查询“李白写过哪些诗”返回结果是诗歌列表系统拼出“李白共创作X首作品例如《将进酒》《静夜思》《望庐山瀑布》等”。我做了答案模板和结果集规模的适配结果少于3条逐条展示全名和内容结果在3到10条之间列出标题并附上第一条的正文摘要结果大于10条分页展示提示“共找到X首以下展示前10首”多轮策略在毕业设计里做简单版就够了记录上一轮的意图和槽位如果用户本轮问“还有呢”默认延续上一轮查询继续翻页。但这里要小心用户一旦问了新问题上下文必须清空不然会出现上轮问李白、这轮问“写月的诗”结果答案还夹着李白的情况。经验之谈问答系统跑通容易跑“稳”很难。最难处理的是用户的意外输入比如“你好”“在吗”“你叫什么名字”这些寒暄语。我的方案是加一个闲聊兜底意图预设几组问候应答语这样即使用户不问知识图谱内容系统也不至于报错演示的时候也会自然很多。5. 自动写诗传统生成模型与LLM API两条路线的取舍5.1 为什么说自动写诗是“最难做漂亮”的模块自动写诗是这个项目里最吸睛、但也最难做得让评委满意的一个模块。难点不在“生成一句押韵的话”而在“生成的文本要像诗”。如果只是随机拼接一些意象词比如“梅花 雪 寒风 孤影”那不是诗是堆词。真正的诗要有基本的格律结构五言还是七言、押韵处理、意象连贯性还要有点“诗意”——这后一条基本是玄学不过可以通过数据和方法去逼近。毕业设计里自动写诗有两条主流路线各有利弊我分别说下。5.2 路线一开源中文生成模型微调传统路线是微调一个文本生成模型让它学习古诗词的文本分布。早年的做法是用LSTM/GRU这类循环神经网络在古诗语料上训练生成的时候用温度采样控制随机性。现在的做法基本是微调开源的中文预训练生成模型。我的建议是如果服务器没有独立显卡不要走这条路。训练和推理对算力的要求用纯CPU跑非常煎熬一个batch可能就要跑几分钟演示的时候现场生成半天不出结果场面会很尴尬。如果学校能给GPU服务器这条路线可以做训练语料就用之前清洗好的诗作正文格式按“五言/七言情感标签主题词正文”这样的控制码来组织模型学习在指定条件下生成诗句。打个比方这就像让模型在“主题是梅花、情感是闲适、格式是五言绝句”的条件下填空生成。控制码的设计是这条路线里最关键的技巧控制码写得越清晰生成结果越贴近要求。5.3 路线二调用通用大模型API没有GPU又想实现“AI大模型自动写诗”效果的同学最现实的路线是接通用大模型的API。这个方案在毕业设计场景下完全站得住因为项目的重点可以放在“如何设计提示词、如何做结果约束、如何与图谱数据结合”上而不是重复造一个写诗模型。提示词模板我是这么设计的请根据以下要求创作一首古典诗词 主题{topic} 情感基调{sentiment} 体裁{format}平仄和押韵请符合近体诗规范 风格参考{style_ref} 要求诗句意境连贯避免堆砌意象。只输出诗作正文不要输出解释性文字。这里有个非常关键的技巧输出格式约束。大模型经常会在诗的前面加“好的我来为您创作一首”后面加“希望您喜欢”这些都不是诗必须要求模型只输出正文。但如果光在提示词里说“只输出诗”模型偶尔还是不听所以后端代码里要做到两道校验第一道用正则提取诗中“五言或七言、四句或八句”的部分把不符合格式的说明文字过滤掉。 第二道统计每句的数字数如果一句七个字但整首诗有四句就算通过基本校验如果格式乱得离谱直接再请求一次补生成。我是这么写后处理的import re def extract_poem_from_response(response): lines [line.strip() for line in response.split(\n) if line.strip()] poem_lines [] for line in lines: # 去掉可能的序号、引号、说明性标注 line re.sub(r^[\d一二三四五六七八九十][\.、]?, , line) line line.replace(“, ).replace(”, ).strip() if line and 3 len(line) 15: poem_lines.append(line) return poem_lines5.4 增强写诗结果与图谱的联动如果想让写诗模块显得更有系统集成度可以在生成前把图谱数据注入提示词。比如用户以“月”为主题先从知识图谱里查出与“月”关联的高频意象词——“故乡”“秋风”“孤影”把这些词放进提示词里要求模型在诗中融入这些意象。这样写诗模块就不只是孤立的API调用而是真正用上了图谱里的知识答辩演示的时候这一环会非常加分。另外生成结果做一个“情感标签自动识别”的闭环展示把写出来的诗再喂给情感分析模块输出情感维度分布然后展示到前端页面。用户看到系统“能写诗、还能读懂自己写的诗”这种交互闭环给人的直观冲击力远远大于单一功能。6. 可视化集成与整个系统的缝合要点6.1 前端可视化怎么选型前端展示层是评委的第一印象一定不能做得像内部调试工具。我建议首页放综合统计面板朝代分布柱状图、高频意象词云、诗作数量排行、情感分布饼图这些图表用ECharts就能搞定不用上重量级前端框架。知识图谱浏览页是核心亮点。把Neo4j里的节点和边数据通过接口拉出来转成ECharts关系图的格式def graph_for_visualization(scopeall): nodes [] edges [] for record in graph.run( MATCH (n)-[r]-(m) RETURN n.name AS source, type(r) AS rel, m.name AS target LIMIT 500 ): ... return {nodes: nodes, edges: edges}这里必须加LIMIT限制节点数量。全量图谱几千上万条边浏览器渲染直接卡死答辩现场开个页面都要转半天印象分就没了。我的做法是按诗人维度切片默认只展示某个朝代或某几位诗人的局部图谱周围提供筛选条件让用户自己选择查看范围。这既展示了图谱能力又照顾了性能。力导向图布局会对图谱结构做实时模拟数据量一大帧率就暴跌经验值是单次展示控制在100个节点以内。超过这个量哪怕后端数据正常前端也会卡得不像样。6.2 接口层设计给每个模块留“可单独演示”的口子后端接口我建议一个模块一组既方便前端调用也方便答辩时单独演示/api/stats/overview首页统计/api/graph/nodes?dynasty唐图谱节点数据/api/sentiment/analyze?text诗句情感分析/api/qa/ask?question提问问答接口/api/poem/generate?topic月format七言写诗接口每个接口的实现都尽量独立不要有隐式依赖。比如情感分析接口单独传入文本就能返回情感标签问答接口单独传入问题就能返回答案。这样答辩演示时可以一个模块一个模块地走每个模块单独说清楚输入输出和技术实现比整个系统黑盒演示要稳得多。6.3 毕业设计答辩时容易被追问的技术点根据我带过的项目经验评委对这类题目的典型追问集中在几个地方第一个必问的是**“知识图谱相比传统数据库的不可替代性是什么”**。回答思路是古诗词领域核心价值在关系挖掘“李白-创作-《静夜思》-包含-‘月光’”这样的多跳查询在图数据库里是路径遍历逻辑清晰在关系型数据库里要多表join而且随着深度增加复杂度爆炸。同时可视化关系图天然适合图数据模型。只要用一条“查某位诗人用过哪些意象”的查询做对比就能把这个讲透。第二个追问是**“情感分析的准确率如何评价”**。如果全用词典法就得承认它受限于词表覆盖并给出一些失败案例的分析。建议提前人工标注50到100首诗的“标准答案”然后计算自己的系统在这批样本上的准确率比如能到75%左右就做一个效果对比表格说明哪些诗判错是因为谐音、反讽还是语境缺失。这个比空口说“效果不错”有说服力得多。第三个追问是**“写诗模块怎么防止生成低质量内容”**。回答思路是格式校验加主题约束加意象引导三层过滤再加上情感分析模块反向检查生成结果的情绪表达是否与主题一致。这里有一条额外策略如果情感分析发现生成的诗和用户要求的主题情感完全不对应就自动重新生成一次。答辩时把这个“系统自纠错”的流程跑一遍比解释一万句提示词怎么设计都管用。6.4 几个典型的坑位复盘把最后这段踩坑记录放在这都是实际操作中的教训。坑位一是语料版权和来源标注。从公开站点采集语料时不要在文档里把站点名和采集量写得太实用“公开古诗词数据整理”这种表述就够了代码里也尽量避免直接暴露个人抓取信息的痕迹。坑位二是Neo4j的版本匹配。Neo4j Desktop如果用社区版要注意和Python驱动库的版本匹配我之前遇到过驱动版本和数据库协议不兼容导致批量写入报错的情况改了驱动版本才解决。建议学生在写文档时把环境版本列一张表方便评审对照复现。坑位三是前端跨域问题。Flask后端的地址和前端页面地址不一致时会出现跨域请求被拦的情况需要在后端配置CORS。这个坑特别常见有时候接口用Postman测没问题页面里一调就报错八成都出在这。坑位四是演示环境和数据量的平衡。答辩前务必在演示环境里把数据量压到一个“看起来丰富但跑得动”的程度。全量5万首诗的知识图谱前端关系图展示会卡只放500首诗又显得数据单薄。建议是后端数据库保留全量可视化接口默认按朝代切片返回这样既能说“系统支持多少首诗的图谱构建”演示时又流畅。坑位五是把写诗模型和大模型API的隐私问题想清楚。如果用的是通用API用户输入的提示词会作为请求的一部分发出去这在开发环境没什么问题但做成演示系统时要注意提示词里不要放任何个人信息也不要在项目文档里写真实密钥。密钥要放在环境变量里代码仓库只放读取逻辑不放明文配置。这个习惯就算毕业后进公司做项目也会一直受用。这个题目做完一遍等于把数据采集、数据清洗、图数据库、中文NLP、问答检索、文本生成、前后端联调整个链条都摸了一遍。对于毕业设计来说它的价值不在于某一个模块做得有多深而在于让评审看到你具备独立把一个综合型系统从零搭到能演示的能力。最后再给一条建议代码可以分阶段写但文档一定要从第一天就开始留记录每完成一个模块就截图存档等最后写说明书和做PPT时你会发现这些过程记录比代码本身值钱得多。
