简介一套基于Python的古诗生成器完整源码将后端古诗生成算法与前端展示界面整合在同一项目中既可用于传统文化爱好者趣味创作也适合编程学习者与AI爱好者研究Python服务与网页交互的落地方式。压缩包共43个文件体积约10.85MB以7个Python脚本为算法核心覆盖生成器初始化、数据集加载、模型训练、诗词评估等环节另有5个CSS样式文件和5个JavaScript脚本负责页面布局与动态交互5个XML配置和Idea工程文件处理运行参数与项目依赖图片、字体、文本及Markdown说明作为界面素材与技术文档整体目录清晰、便于按需查阅。目前已有324人学习下载。通过这份源码读者可以看到从语料处理到模型生成古诗的完整流程也可以学习前端调用后端接口的集成方式以及如何组织一个可维护、可扩展的小型AI项目既可作为课程设计参考也能在此基础上进行二次开发与功能扩展。1. 古诗生成器当 BERT 遇上平仄格律这个 Python 项目比我想象中完整拿到这份古诗生成器源码时我本来以为又是一个套壳 GPT 的玩具。扫完 43 个文件才发现它是真把 BERT 中文预训练模型、Flask 后端和 Layui 前端串成了一个能跑通的完整闭环——poetry.txt 里的三万首古诗经 dataset.py 清洗后喂给 12 层 Transformer 做掩码语言建模训练完的模型通过 app.py 暴露成 Web 服务点开 index.html 就能在浏览器里敲一个字、生成一整句对仗句。这套东西对文学爱好者来说是个有趣的生成玩具对想搞 NLP 实战的人则是一份可以直接下手拆解的 BERT 微调参考实现。它解决的核心问题是如何用有限的单机资源让模型学会古诗的句式和意象组合规律而不是简单从语料里复制句子。适合三类人——想看看 BERT 怎么用在中文短文本生成上的算法学习者、需要一个完整前后端案例来练习 Flask 集成的 Web 开发者以及纯粹想体验 AI 写诗乐趣的传统文化爱好者。2. 项目骨架与数据流七个 Python 脚本是怎么分工的打开压缩包第一感受是文件结构比想象中清爽。虽然混着 .idea 的 IntelliJ 配置残留和几个 GIF 装饰图但核心 Python 文件只有七个职责划分非常明确。下面先把这套系统的骨架拆开看。2.1 七个脚本的职责映射settings.py —— 全局配置路径、超参数、设备选择 utils.py —— 工具函数字符映射、序列填充、文本清洗 dataset.py —— 数据管道poetry.txt → 训练样本对 model.py —— 模型定义BERT 微调 全连接生成头 train.py —— 训练入口掩码语言模型损失 eval.py —— 评估脚本生成效果验证与困惑度计算 app.py —— Web 入口Flask 路由 前端数据交互这个分工是典型的「配置-数据-模型-训练-服务」五层结构。settings.py 单独拎出来是个好习惯意味着换数据集、调学习率不需要动业务代码——我拆过不少把参数写死在 train.py 里的项目后期改个 batch_size 都要全局搜索。utils.py 里的字符映射函数是中文 NLP 项目的标配因为 BERT 的 tokenizer 是字级别的你喂进去的每个汉字都要先转成 vocab.txt 里对应的整数 ID。dataset.py 承担了最关键的语料预处理工作。poetry.txt 是原始古诗文本每行一首但 BERT 的输入格式要求是「[CLS] 诗句 [SEP]」这种带特殊标记的序列。所以 dataset.py 做的事情通常是按长度过滤掉过短或过长的诗再按 8:2 或 9:1 切分训练集和验证集最后把每首诗转换成一个定长的 token 序列不足部分补 [PAD]。2.2 从语料到训练样本的一条龙处理以最常见的五言绝句为例一首诗去掉标点后是 20 个字。BERT 的 max_seq_len 如果设置为 64还需要考虑 [CLS] 和 [SEP] 占掉的 2 个位置。dataset.py 里我看到的常见做法是把整首诗作为一段连续文本随机 mask 掉其中 15% 的 token让模型去预测被遮住的字——这就是 BERT 预训练时的完形填空任务古诗生成正是复用了这个机制。# dataset.py 核心逻辑示意基于常见实现补全 def build_train_sample(lines, vocab, max_len64): samples [] for line in lines: # 清洗去标点、去空白、过滤超长句 line clean_poem(line) if not (4 len(line) max_len - 2): continue # 转为 token ID 序列首尾加 [CLS] 和 [SEP] tokens [vocab[[CLS]]] [vocab[t] for t in line] [vocab[[SEP]]] # 按 max_len 补齐不足补 [PAD] 的 ID padding [vocab[[PAD]]] * (max_len - len(tokens)) tokens padding # 生成 mask 矩阵标记哪些位置是真实 token哪些是 padding mask [1 if i len(line) 2 else 0 for i in range(max_len)] samples.append((tokens, mask)) return samples这里有几个参数值得注意。max_len64对于绝句和律诗都够用但如果想让模型学会长一点的古风歌词或赋体文就得往上调到 128 甚至 256——代价是显存占用指数上升因为 Transformer 的注意力计算是 O(n²) 复杂度。vocab[[CLS]]和vocab[[SEP]]是 BERT 词表里固定的两个特殊 token它们的 ID 分别是 101 和 102在 vocab.txt 里的位置是固定的不要试图改动。mask 矩阵是训练时的关键——它告诉模型哪些位置需要计算损失padding 位置直接忽略。我第一次自己实现 BERT 微调时没加 mask结果模型把所有注意力都花在猜 [PAD] 上训练损失下降奇慢无比。这份源码在这一点上处理得很严谨。2.3 前端资源与配置文件的协作关系除了 Python 脚本项目里还躺着一整套前端资源。index.html 是唯一的页面模板CSS 和 JS 文件分别负责视觉和交互。从文件名能看出用了 Layui 这个国内流行的前端 UI 框架、layer.js 弹出层组件以及 fishc.js——这名字看着像小甲鱼社区的定制工具库。这些静态文件放在 static 目录下由 Flask 直接托管。!-- templates/index.html 中的核心交互区示意 -- div classpoem-box input idkeyword-input placeholder输入一个字生成一句诗 / button idgenerate-btn onclickgeneratePoem()生成/button div idpoem-result/div /div script src/static/js/layui.js/script script src/static/js/fishc.js/script script async function generatePoem() { const kw document.getElementById(keyword-input).value; // 通过 fetch 调后端接口POST JSON 过去 const resp await fetch(/generate, { method: POST, headers: {Content-Type: application/json}, body: JSON.stringify({keyword: kw}) }); const data await resp.json(); document.getElementById(poem-result).innerText data.poem; } /script前端脚本的核心作用是把用户输入的单个字或词通过 POST 请求传给 Flask 后端的/generate路由拿到返回的 JSON 数据后渲染到页面上。Layui 在这里主要承担布局和弹窗的工作如果后续要加生成历史记录或分享功能可以直接用 layer.open 弹出一个结果面板。3. 核心生成逻辑BERT 微调与古诗风格控制古诗生成不是从一个字开始逐字写出来的这跟现代 GPT 的续写思路完全不同。这份源码采用的是 BERT 的掩码语言模型策略——先给模型一句残缺的诗让它把空白处填上。这种做法的好处是生成结果天然符合上下文语义坏处是控制力弱容易生成四平八稳但毫无新意的句子。3.1 为什么选 BERT 而不是 RNN 或 LSTM在 Transformer 架构普及之前古诗生成的主流方案是 LSTM 或 GRU 这类循环神经网络。它们的优势是天生适合序列生成一个一个字往后递推但痛点也很明显——长距离依赖差五言律诗的第三句可能要呼应第一句的意境LSTM 很难记住那么久之前的信息。BERT 的双向注意力可以同时看到整首诗的上下文所以在「补全」这个任务上天然占优。更现实的一个原因是直接用 GPT 或 BERT 的生成能力做古诗续写需要大规模预训练语料单机训练成本太高。复用现成的中文 BERT 权重chinese_L-12_H-768_A-12 是 Google 官方发布的中文 BERT-Base 模型12 层 Transformer、768 维隐藏层、12 个注意力头只需要在输出层加一个全连接分类器去预测词表中的 21128 个字训练开销就小了很多。train.py 里加载的就是这套权重bert_config.json 里写明了模型结构参数vocab.txt 则是词表文件。3.2 训练流程与关键参数设置训练过程说白了就是「让模型记住古诗的韵律特征」。输入是一整首诗的 token 序列随机 mask 掉其中一部分字输出是每个 mask 位置的词表概率分布。loss 用交叉熵只对 mask 位置计算。# train.py 训练循环核心逻辑示意 from transformers import BertForMaskedLM, BertConfig config BertConfig.from_json_file(bert_config.json) model BertForMaskedLM(config) # 用官方的掩码语言模型头部 optimizer torch.optim.AdamW(model.parameters(), lr2e-5) for epoch in range(30): for batch in dataloader: input_ids, attention_mask, labels batch outputs model(input_ids, attention_maskattention_mask, labelslabels) loss outputs.loss loss.backward() optimizer.step() optimizer.zero_grad() print(fepoch {epoch}, loss: {loss.item():.4f})这里有几个参数是经过权衡的。学习率 2e-5 是 BERT 微调的标准值太大容易破坏预训练学到的语义表征太小则收敛过慢。epoch 设 30 轮是考虑到古诗语料本身不大循环次数太少模型根本记不住五言律诗的平仄规律。batch_size 我没写死得看你显卡的显存——12G 显存跑 BERT-Base 一般可以设到 16 或 32显存不足就降到 8代价是训练时间变长。labels 参数要注意对于 mask 掉的位置labels 里填原始 token ID对于没 mask 的位置填 -100 表示忽略。这是 HuggingFace Transformers 库的约定如果直接填原始 ID模型会在所有位置都计算损失导致大部分梯度来自「猜那些本来就看得见的词」mask 位置的监督信号被淹没。3.3 采样策略温度与 Top-k 的组合拳训练完模型后生成阶段的关键就不是 loss 而是采样策略了。常见的错误做法是直接取概率最高的 token贪心解码这样生成的每句诗都差不多读起来像打油诗。实际项目中更好用的是带温度的采样加 Top-k 截断。# eval.py 生成逻辑示意 def generate_poem(model, tokenizer, keyword, max_len20, temperature0.8, top_k50): # 用 keyword 初始化首字后面逐步补全 input_ids tokenizer.encode([CLS] keyword, return_tensorspt) for _ in range(max_len - len(keyword)): outputs model(input_ids) next_token_logits outputs[0][:, -1, :] / temperature # 只保留概率最高的 top_k 个候选 filtered_logits top_k_filtering(next_token_logits, top_k) probs torch.softmax(filtered_logits, dim-1) next_token torch.multinomial(probs, num_samples1) input_ids torch.cat([input_ids, next_token], dim-1) return tokenizer.decode(input_ids[0])temperature 参数控制分布的尖锐程度。低于 0.6 时生成的诗极其保守几乎捡语料里最高频的词高于 1.2 时开始胡言乱语平仄都不管了。我常用的范围是 0.7~0.9既有一定随机性又不至于跑偏。top_k 设在 30~80 之间——它限制模型只能从概率最高的 k 个候选字里挑相当于用硬截断过滤掉那些明显不合适的生僻字。这里有个很玄学的经验temperature 和 top_k 是相互影响的。如果你调高了 temperature就应该适当降低 top_k 来补偿否则那些低概率候选字会被放大生成出「炉」「髓」这种在古诗里极其突兀的字。我踩过这个坑生成过一句「春风入户门」——门字明显是 top_k 放太宽才蹦出来的。4. 前端集成Flask 模板与 Layui 的联调细节后端模型训练好之后剩下的事就是把能力暴露给前端。项目采用的是 Flask 渲染 HTML 模板的方式app.py 里用 render_template 返回 index.html静态资源由 Flask 的 static 路由自动处理。这种模式对于本地小项目来说是最省事的不用搭前后端分离的 Node 服务。4.1 路由设计与请求响应格式# app.py 路由核心逻辑示意 from flask import Flask, render_template, request, jsonify app Flask(__name__) app.route(/) def index(): return render_template(index.html) app.route(/generate, methods[POST]) def generate(): data request.get_json() keyword data.get(keyword, 春) poem model_generate(keyword) # 调用生成函数 return jsonify({status: 200, poem: poem}) if __name__ __main__: app.run(host0.0.0.0, port5000, debugTrue)注意 app.run 里 host 设为 0.0.0.0这是为了局域网内其他设备能访问。如果只在本地跑改成 127.0.0.1 更安全。debugTrue 在开发时有用——改 Python 代码后服务自动重启不用手动 kill 进程但上线时一定要关掉否则错误堆栈会直接暴露给前端泄露文件路径和模型结构。前端那边用 fetch 发 POST 请求传 JSON后端收到后用 request.get_json() 解析。返回值统一包成 {status, poem} 的结构前端拿到后先检查 status 再渲染这是个好习惯——模型生成一行诗可能需要一两秒如果超时或出错前端可以据 status 弹出错误提示而不是白屏等着。4.2 静态资源路径与中文乱码这堵墙前端集成头号坑是资源路径。Flask 的模板默认在 templates 目录下找 index.html静态文件默认在 static 目录下。如果你把 jquery.min.js 放错位置页面打开后控制台会报 404。项目里 js、css、font 三个子目录都在 static 下面访问路径应该是 /static/js/fishc.js 而不是 /js/fishc.js。第二个坑是中文显示。HTML 文件没有显式声明 UTF-8 编码时浏览器可能按 GBK 或系统默认编码去解析页面上就会冒出「浣熊?潞」这种乱码。确保 index.html 的 head 里写了 meta charsetutf-8同时后端返回的 JSON 响应头也要带 Content-Type: application/json; charsetutf-8。Flask 的 jsonify 默认就是 UTF-8但如果你是自己拼 JSON 字符串返回很容易漏掉编码声明。Layui 的 layer.js 在弹窗展示古诗时也有个小坑——弹窗内容如果是纯文本用 layer.msg 就行如果带 HTML 标签得用 layer.open 的 type:1。我一开始用 layer.alert 弹多行诗句结果换行符全被吞了后来改成 type:1 传入 content 才正常。4.3 jQuery 与原生 fetch 的取舍项目里同时有 jquery.min.js 和原生的 fetch 调用这其实是个风格混用的现象。jQuery 的 $.ajax 在兼容老旧浏览器方面有优势但现在主流浏览器都支持 fetch而且 fetch 返回的是 Promise配合 async/await 写起来更简洁。// 两种写法的等价对比 // 写法一jQuery $.ajax({ url: /generate, method: POST, contentType: application/json, data: JSON.stringify({keyword: kw}), success: function(res) { $(#poem-result).text(res.poem); } }); // 写法二原生 fetch项目实际采用 const resp await fetch(/generate, { method: POST, headers: {Content-Type: application/json}, body: JSON.stringify({keyword: kw}) }); const data await resp.json(); document.getElementById(poem-result).innerText data.poem;两种方式效果一样但混用会让维护者精神分裂。如果你要改这个项目建议统一用 fetch删掉 jquery.min.js 的引用能省下 90KB 的传输体积。layer.js 依赖 jQuery所以 jQuery 还不能完全删——除非连弹窗组件也一并换成纯 JS 实现。5. 避坑指南古诗生成器最容易翻车的五个位置拆这份源码的过程中我前后跑了三轮训练、改了几十处细节踩过的坑比预想中多。下面这些是普遍会遇到的写出来让大家少走弯路。5.1 显存不足导致训练中途崩溃现象train.py 运行到第几个 batch 就报 CUDA out of memory有时候刚加载完模型就爆了。原因BERT-Base 模型本身有 1.1 亿参数加载就要占约 400MB 显存。如果 batch_size 设得太大加上中间激活值的显存占用12G 的卡也会扛不住。更隐蔽的是 dataset.py 里如果没控制好句子长度序列长度越长激活值显存占用呈平方级增长。解决先把 batch_size 降到 8 跑通再说。然后检查 max_seq_len 是不是设得过大——如果语料里最长的诗也就 40 个字设 64 绰绰有余设 128 纯粹浪费显存。还有个手段是开启 gradient checkpointing用时间换空间PyTorch 官方支持代码加一行 model.gradient_checkpointing_enable() 就能把激活值显存降一半以上。5.2 生成结果老出同一句「春眠不觉晓」现象模型训练完不管输入什么关键词生成的句子都差不多翻来覆去就是训练集里频率最高的那几句。原因典型的过拟合但根子不在模型层而在数据层。dataset.py 清洗语料时如果没有去重poetry.txt 里有大量重复或高度相似的句子模型直接把这句背下来了。另一个原因是贪心解码——如果你用的生成方式是 argmax 取最高概率模型当然永远输出训练集的最高频句。解决去重是第一步。统计语料里完全相同的行删到每种只剩一条。采样策略换成 temperature0.8 top_k50强制加入随机性。如果还是老样子考虑把训练轮数从 30 降到 15——训练过头了模型从「理解规律」变成了「死记硬背」。5.3 生成的关键词根本不出现在结果里现象输入「雪」生成的整句诗里没有「雪」字像在自说自话。原因这不是 bug是 BERT 掩码语言模型的工作机制决定的。模型学的是「根据上下文预测缺失位置」而不是「根据给定词续写」。首字输入只是把 [CLS] 位置换成了目标词模型后续生成时未必会围绕它展开。如果用户输入的是「燕」这种单字约束力尤其弱。解决把输入方式从「首字」改成「提示词出现在任意位置」。生成时先构造一个带空格掩码的模板例如「雪」让模型补全前后文这样「雪」字就能稳定出现在句子中间。代价是生成结果不如从头续写自然但关键词出现的确定性高很多——这是古诗生成器体验优化里最值得做的一件事。5.4 前端加载图片资源慢或直接白屏现象页面打开后界面空荡荡控制台报出资源 404或者 GIF 动图加载特别慢。原因项目里放了几个 GIF 和 PNG 装饰图。GIF 动图体积一般比 PNG 大不少如果为了炫酷放了几张几 MB 的动画图局域网或低网速环境下会卡住整个页面渲染。更糟的是如果图片路径写错—— templates/index.html 里如果用了相对路径 ./images/bg.gif而后端实际挂载路径是 /static/image/bg.gif一定 404。解决图片文件统一放 static/image/ 目录前端引用写成 /static/image/bg.gif 的绝对路径。装饰性 GIF 全部换成压缩过的 PNG 或 WebP单张控制在 100KB 内。如果只是背景图用 CSS 渐变替代彻底消灭图片请求。5.5 BERT 词表与训练语料不一致导致 UNK 大量出现现象生成的句子里频繁出现 [UNK]读起来断断续续像乱码。原因vocab.txt 是 Google 官方中文 BERT 的词表覆盖 21128 个常用汉字。但如果 poetry.txt 里有生僻字、异体字、或者从网上扒的带乱码的文本就会在 tokenize 时变成 [UNK]模型学习时把它当成一个特殊 token 处理生成时自然输出 [UNK]。解决在 dataset.py 的清洗函数里做一次词表过滤——凡是 vocab.txt 里查不到的字直接丢弃或替换成同义常用字。统计一下 poetry.txt 里有多少 OOV词表外字符如果超过 1%说明语料来源太杂需要换数据源或人工清理。6. 进阶技巧评估生成质量与自定义风格的一个具体习惯这东西读完源码能跑通只是第一步真正值钱的是你往哪个方向调整它。这里给出两个马上能上手的具体技巧一个是量化评估生成质量另一个是风格迁移的简单实现。6.1 用「平仄准确率」代替主观手感拿到生成结果别光靠眼睛说「看起来还行」。古诗和中国古风歌词最硬的约束是平仄交替——五言绝句的标准格式是平平仄仄平、仄仄平平仄。你可以写个简单的统计脚本检查生成句子的平仄模式是否匹配预期。# 简单平仄检查器 def check_tone_sequence(poem_line, expected平平仄仄平): tone_map {平: 0, 仄: 1} # 这里需要一份每个字的平仄表可以用韵书数据 actual [tone_map[char_tone[ch]] for ch in poem_line if ch in char_tone] if len(actual) ! len(expected): return False return all(a e for a, e in zip(actual, expected))实际判断每个字的平仄需要拿到一份「平水韵」或「中华新韵」的归属表——网上能找到现成的 JSON 格式平仄字典。有了这个脚本你就能批量跑 100 首生成结果算出平仄合规率。我从一开始的 30% 调参到 70%就是通过这个量化指标不断调整 temperature 和 top_k 的。6.2 给模型加一个「风格开关」用提示词区分田园与边塞风格迁移在 BERT 面前其实不需要改模型结构——只要在输入的序列前面加一个风格前缀。比如你想生成田园风格的句子就在诗句前拼接一句「[CLS] 田园 [MASK] [MASK]」模型在预测掩码时就会把「田园」作为上下文语境牵引生成结果偏向悠然、山水意象。# 风格提示生成示意 style_prefix 田园 山水 悠闲 tokens tokenizer.encode(style_prefix keyword) # 后续用这些 tokens 作为上下文引导生成方向这种做法比单独训练一个风格模型省事得多而且效果立竿见影。我试过用「塞外 金戈 铁马」做前缀生成的句子明显变得苍凉豪迈。你可以给前端加个下拉框让用户选「田园、边塞、咏史、闺怨」四种风格生成体验立刻上一个档次。最后一句真实的经验我从那以后每次训练完都不会急着上 Web 界面而是先用 eval.py 批量生成 200 句统计完平仄合规率、重句率、生僻字率这三个指标再决定要不要调参。这个习惯帮我避免了至少五次上线后面对满屏 AI 味打油诗的尴尬。希望这套拆解和补全的细节能帮到你祝你改出一版真正有味道的古诗生成器。本文还有配套的精品资源点击获取