LSTM字符级语言模型实战：用鹿鼎记训练AI续写武侠小说

简介：基于金庸《鹿鼎记》全文的 LSTM 文本生成项目，面向自然语言处理入门者、毕设学生或对小说自动续写感兴趣的开发者。项目用爬虫抓取金庸网小说目录及各章节文本，原始语料约 100 万字，演示时截取前 5 万字符，并完成排序去重、字符词典与整数映射表构建，再按 40 字符为一句切分训练数据，最终训练出的权重文件可直接加载生成仿鹿鼎记风格文本。压缩包内共 5 个文件，包含 2 个 Python 脚本、1 份 Markdown 说明文档、1 份 txt 语料以及 1 个 hdf5 模型权重文件，整体约 18.78MB，体积紧凑、结构清晰，便于快速下载与本地复现。README 文档对爬虫、训练及生成步骤做了说明，适合对照代码快速上手。已有 192 人学习浏览，适合作为深度学习文本生成的参考实现，也可在现有代码基础上调整语料或模型参数，用于课设、毕设或拓展实验。

1. 用鹿鼎记文本训练LSTM写小说：这个项目到底能生成什么

很多人第一次碰 LSTM，是在股价预测、设备寿命预测这类回归任务上，输入一串数字输出一个数字；但 LSTM 真正的老本行是序列生成。这个项目把《鹿鼎记》全本 txt 当作数据集，训练一个字符级 LSTM 语言模型，让它学着输出韦小宝式的对白和章回体叙事。它解决的不是“写出完整小说”，而是“给定开头，按金庸的用词习惯续写一段不露怯的文字”。适合刚学完 Python 基础、想拿一个真实文本做 NLP 入门，又不想一上来就上 BERT、GPT 的读者；也适合想交文本生成 demo 作业的人。后面所有源码和参数，我按“能跑、能训练、能出结果”的顺序展开，尽量少讲虚的。

2. 把鹿鼎记清洗成字符级数据集：编码、切分与滑动窗口

2.1 为什么字符级比词级更适合这本小说

先回答一个必须想清楚的问题：明明是中文文本，为什么不用分词后的词序列？常见做法是 jieba 分词后做词级 LSTM，但在古典章回小说上分词反而帮倒忙。“韦小宝道”可能被切成“韦/小/宝/道”或“韦小宝/道”，专名切法飘忽不定，词表还会膨胀到上万个词；而鹿鼎记全书总字数在百万字上下，字符级只需要把每个汉字、标点、数字映射成一个整数 ID，词表通常只有几千个符号，模型小、训练快、没有 OOV 问题。字符级 LSTM 生成时按字输出、按字拼接，天然避开了“生造一个不存在的词”的尴尬。

另一个理由是金庸文本的特性。鹿鼎记里大量对白带着口语和方言语气词，“罢”“喀”“哼”这类单字频繁出现，分词器往往直接丢掉语气词或切错位置；字符级把这些都作为合法 token 保留下来，让模型自己学“哼”后面常跟什么。从结果上看，字级模型学到的不是语法树，而是“字接字的转移规律”，这正是百来万字的文本量驾驭得住的尺度。相比之下，如果用词级模型，词表大、数据稀疏，训练同样的 epoch 效果往往比字级差一截。

2.2 清洗与编码：把一本 txt 变成模型能吃的字典

拿到手的数据通常是流传已久的《鹿鼎记》全本 txt，各版本差异不小，有的带章节标题、有的混入其他小说片段，第一件事不是建模而是清洗。我一般把预处理单独放到 preprocess.py，用下面这个写法做四件事：自动探测编码、统一全半角、删冗余空行、生成字符到 ID 的映射。

import collections import re def read_text(path): # 优先按 utf-8 读，失败再退回 gbk；老版本 txt 多为 GBK 编码 for enc in ("utf-8", "gbk", "utf-16"): try: with open(path, "r", encoding=enc) as f: return f.read(), enc except UnicodeDecodeError: continue raise ValueError("无法识别文件编码") def clean_text(raw): out = [] for ch in raw: code = ord(ch) if code == 0x3000: # 全角空格 out.append(" ") elif 0xFF01 <= code <= 0xFF5E: # 全角 ASCII 范围 out.append(chr(code - 0xFEE0)) else: out.append(ch) text = "".join(out) # 去章节标题：第X回 字样 text = re.sub(r"第[一二三四五六七八九十百零]+回.*?\n", "\n", text) lines = [ln.strip() for ln in text.splitlines() if ln.strip()] return "\n".join(lines) raw, enc = read_text("ludingji_raw.txt") clean = clean_text(raw) counter = collections.Counter(clean) min_freq = 2 chars = [ch for ch, n in counter.items() if n >= min_freq] char2idx = {ch: i for i, ch in enumerate(chars)} idx2char = {i: ch for ch, i in char2idx.items()} with open("ludingji_clean.txt", "w", encoding="utf-8") as f: f.write(clean) print(f"总字符数: {len(clean)}, 词表大小: {len(chars)}")

代码逻辑说明：read_text 按 utf-8、gbk、utf-16 逐次尝试回退，这是处理老文本最省心的方式；clean_text 先把全角 ASCII 和全角空格统一成半角，中文标点如“，”“。”的码位不在转换范围内，因此被保留。正则把每一回的标题行删除，避免模型把“第X回”当成正文反复学习。最后用 collections.Counter 做频次统计，出现次数少于 min_freq 的字符不收入词表，这类字符多是乱码残留和排版异常，删掉不影响生成质量。

参数说明：min_freq=2 是保守值，如果清洗后的文本仍有零星乱码，可以提到 5，vocab 会小几百、训练更快，代价是极低频的冷僻字生成时永远看不到。对小说风格模仿无所谓，要做古字考据就不能这么干，按用途调。这里还有个隐藏细节：字符 dict 的索引 0 被留给了频次最高的字符，如果你后续遇到词表外的神秘字符，.get(ch, 0)会落到索引 0 而不是直接崩。严谨的做法是单独留一个<UNK>位，新手用 fallback 到 0 也能跑。

2.3 源码包里数据与文档的典型落地结构

一个能直接复现的数据集目录，我习惯长成下面这样，这类项目的“数据”部分一般就包含这些文件：

data/ ludingji_clean.txt 清洗后的纯文本 char2idx.json 字符到 ID 的映射 idx2char.json ID 到字符的映射 stats.json 总字符数、词表大小、seq_len、stride

stats.json 供 train.py 读取，避免每次启动都重算一遍词表。标题里说的“文档说明”，通常就是一份 README，写三样东西：运行命令、参数表、数据清洗规则。清洗规则尤其要写清楚：哪些字符进了词表、章节标题怎么处理、有没有做过繁简转换。文档里参数写明白了，别人照做才能复现；文本生成本身随机性就大，参数再对不上，结果差异会放大到没法对比。如果你换其他小说源，清洗规则多半要调整，比如《鹿鼎记》老版本 txt 里混入的体例不同，README 里最好记录改过哪一条正则，否则两周后回来看自己的数据都忘了当初怎么处理的。

2.4 用滑动窗口切出“前字预测后字”的样本

清洗之后要构造训练样本。LSTM 语言模型的基本单元是：看到前面 S 个字，预测第 S+1 个字。做法是把整本书按一个固定窗口滑过去，每个窗口取前 S 个字作输入 x、后 1 个字作标签 y。常见做法是用无重叠切片，但我建议留一点重叠，因为文本边界处的上下文本来就是连续的，重叠让每个片段被多次看到，训练更充分。

import numpy as np def make_dataset(idx_seq, seq_len=64, stride=16): xs, ys = [], [] for start in range(0, len(idx_seq) - seq_len, stride): window = idx_seq[start:start + seq_len + 1] # 多取 1 个字作标签 xs.append(window[:-1]) ys.append(window[1:]) # 标签也是完整序列，对齐计算每个位置 return np.array(xs, dtype=np.int64), np.array(ys, dtype=np.int64) with open("ludingji_clean.txt", "r", encoding="utf-8") as f: clean = f.read() idx_seq = [char2idx.get(ch, 0) for ch in clean] X, Y = make_dataset(idx_seq, seq_len=64, stride=16) print(X.shape, Y.shape) # 例如 (N, 64) (N, 64)

为什么标签也是长度为 64 的序列而不是一个单字符？这是很多第一次写的人弄错的地方。输入“韦小宝道”四个字时，如果标签只有一个字，模型只在最后一个位置学“道”后面该接什么，前三个位置白白浪费。让标签错位对齐，每个位置都在学“当前位置的下一个字”，同一段样本被重复利用了 seq_len 次，训练效率高得多。PyTorch 的 CrossEntropyLoss 要求把 (B, S, V) 拍平成 (BS, V)，标签也拍平成 (BS)，代码里用 view(-1, vocab_size) 一步完成。

参数说明：seq_len=64 大约覆盖两句对白，入门够用；想生成更长、更连贯的段落，把 seq_len 提到 128，但训练时间和显存接近翻倍。stride=16 代表每 16 个字取一个新窗口，相邻样本重叠 48 个字，同一个句子在多个上下文里被学好几遍；stride 等于 seq_len 即无重叠，样本量只剩四分之一，通常也够用且省内存。这两个参数是训练数据规模的关键旋钮，改它们比改模型结构对结果的影响更直接。

3. 搭建 LSTM 小说生成模型：结构与必须调对的三个参数

3.1 一张 Embedding 加两层 LSTM 加一个全连接

字符级语言模型的网络结构相当固定，PyTorch 里按下面写法搭：

import torch import torch.nn as nn class CharLSTM(nn.Module): def __init__(self, vocab_size, embedding_dim=128, hidden_size=256, num_layers=2, dropout=0.0): super().__init__() self.embedding = nn.Embedding(vocab_size, embedding_dim) self.lstm = nn.LSTM( input_size=embedding_dim, hidden_size=hidden_size, num_layers=num_layers, batch_first=True, dropout=dropout if num_layers > 1 else 0.0, ) self.fc = nn.Linear(hidden_size, vocab_size) def forward(self, x, hidden=None): emb = self.embedding(x) # (B, S, D) out, hidden = self.lstm(emb, hidden) # out: (B, S, H) logits = self.fc(out) # (B, S, V) return logits, hidden

forward 里把整个序列一次丢进 LSTM，每个时间步的输出都接同一个全连接层，得到该位置对下一个字的预测分布。batch_first=True 让输入形状是 (B, S, D)，纯属省心；PyTorch 文档里常见写法是 (S, B, D)，两种都行，但 batch_first 配合 DataLoader 更顺手。

这里没有双向 LSTM，也没有 attention。理由是生成任务有因果约束：预测当前位置的字时只能看它前面的字，不能偷看后面的字；双向 LSTM 在训练时能用上后文，但生成时用不上，会造成训练和推理行为不一致。attention 在字符级短序列上收益有限，鹿鼎记这种文本的依赖大多是三五字内的局部模式，两层 LSTM 的隐藏状态已经装得下。和 pytorch lstm 源码里的标准实现相比，我没有改 LSTM 内部结构，只是把输出接成语言模型头。如果你之前写过 LSTM 时间序列预测，会发现这是同一套结构，区别只在输出维度换成词表大小、损失从 MSE 换成交叉熵。

3.2 三个必须调对的参数：embedding、hidden 与层数

hidden_size 是最值得加预算的参数，鹿鼎记的人物关系和文体风格隐藏在较长的字符模式里。hidden=256 的模型参数总量在百万到两百万级别，在百万字语料上三个 epoch 就能过拟合；hidden=512 能记住更长的文体特征，但纯 CPU 训练会明显变慢，建议有 N 卡再上。层数方面，字符级任务不是图像分类，不需要堆很深去逐层提特征；层数从 1 加到 2 通常有帮助，再加到 3 层在小说文本上往往只让 loss 下降变慢，还容易把时间耗在让深层梯度稳定上。

dropout 参数要克制：训练时 dropout 能抑制过拟合，但生成时 dropout 必须关掉，否则随机性被放大。按我的经验，小说生成项目建议 dropout=0.0 或 0.1，把防过拟合的重心放在早停和控制 epoch 数上，而不是 dropout。损失函数选 nn.CrossEntropyLoss 而不是 MSE：字符预测是分类问题，MSE 会把概率分布当数值去回归，收敛慢，生成的分布也偏平。

3.3 训练循环：梯度裁剪、teacher forcing 与 checkpoint

训练脚本是整套源码里的核心。关键代码：

def train_one_epoch(model, loader, optimizer, criterion, clip=5.0): model.train() total_loss = 0 for x, y in loader: x, y = x.to(device), y.to(device) optimizer.zero_grad() logits, _ = model(x) # (B, S, V) loss = criterion(logits.view(-1, vocab_size), y.view(-1)) loss.backward() nn.utils.clip_grad_norm_(model.parameters(), clip) optimizer.step() total_loss += loss.item() * x.size(0) return total_loss / len(loader.dataset)

逻辑说明：logits 被 reshape 成 (BS, V)，标签 y 也拍平成 (BS)，这样每个样本每个位置都参与 loss 计算，一个 batch 相当于 batch_size×seq_len 个独立的“前字推后字”任务。criterion 内部已经做了 softmax，不要在外层再手动加，否则数值会变差。

梯度裁剪是必须的一步。LSTM 在长序列上很容易梯度爆炸，不裁剪的话训练经常在某一步 loss 变成 nan，然后整个模型参数被污染，只能重新加载 checkpoint。clip=5.0 是我在文本生成上的默认值；如果 loss 曲线剧烈震荡，可以降到 1.0。

训练循环里还有一个隐含机制叫 teacher forcing：训练时模型每一步输入的都是真实文本的字符，而不是自己上一步预测的结果。这让训练稳定，但代价是生成阶段模型要自己把预测字符当输入继续喂，两种模式的 gap 靠采样温度来缓解。想提高训练-推理一致性，可以在每个 epoch 后半段以 20% 概率把真实输入替换成模型自己的预测，新手不推荐一上来就开，容易把 loss 搞崩。每个 epoch 结束保存 checkpoint 时，只存 model 会很省事，但恢复训练不方便；把 optimizer 状态、epoch、当前 loss 一起打包：

torch.save({ "model": model.state_dict(), "optim": optimizer.state_dict(), "epoch": epoch, "loss": avg_loss, }, f"checkpoint_epoch{epoch}.pt")

4. 跑通训练与生成：从 loss 监控到采样出一段武侠对白

4.1 最小运行命令与硬件要求

拿到源码包后先不要乱改参数，按“数据 → 训练 → 生成”三步走。环境上 Python 3.8 到 3.10 都行，刚装完 Python 的读者记得一并装上 numpy 和 torch；CPU 训练完全可行，就是慢一些，hidden=256、seq_len=64 的配置在普通笔记本上跑一个 epoch 大约几十分钟，能接受。

# 清洗数据 python preprocess.py --input ludingji_raw.txt --output ludingji_clean.txt # 训练，CPU 用户按下面参数跑 python train.py --seq-len 64 --batch-size 64 --hidden 256 --epochs 3 --device cpu # 生成，指定一个开头 python generate.py --checkpoint checkpoint_epoch2.pt \ --seed "韦小宝当下说道" --length 200 --temperature 0.8 --top-k 10

命令行参数解析建议用 argparse，train.py 把 seq_len、batch_size、embedding_dim、hidden_size、num_layers 全部暴露成参数，这样想对比 hidden=256 与 hidden=512 谁更会模仿金庸时不用改代码，跑两次实验就行。generate.py 的 seed 参数是你要续写的开头，length 控制生成字符数，temperature 和 top-k 是采样核心参数，下一节细说。

4.2 loss 曲线怎么读：从 8.x 到 2.x 的参考节奏

刚开始训练时 loss 会在 8 附近，因为随机初始化的模型对每个字符的输出概率接近均匀分布，vocab 几千个字，log(词表大小) 就是初始 loss。正常节奏大概是：第一个 epoch 结束时降到 2.5-3.5，第二个 epoch 到 1.8-2.5，第三个 epoch 到 1.5-2.0。如果第一个 epoch 就跌到 1 以下，不是模型聪明，而是序列过短或语料过小，模型在“背”训练集，生成时会疯狂整句复读。

loss 到 1.5 附近继续训练收益很小，生成文字会更流畅但也会更“油滑”，停在 2.0 左右反而是风格最浓的时候。这个区间没有绝对标准，所以多存几个 checkpoint，生成时逐个试。我一般每完成一个 epoch 就顺手生成一小段看看，不要等训练全结束才看结果，文本生成的手感往往比 loss 数值更早暴露问题。

提示：把 checkpoint 按 epoch 分开存，相当于给生成效果多买几份后悔药。训练一次不算贵，重训一次才贵。

4.3 温度采样：让模型敢说“人话”

生成阶段如果直接取 argmax，也就是每次选概率最高的字，结果会是灾难性的重复：“韦小宝说道说道说道”。生成必须用采样：把 logits 除以温度 T 后转成概率，再按概率分布抽取。T 越小分布越尖锐，T 越大越敢走低概率路线。小说生成我建议 T=0.8 作为起点。

def sample_from_logits(logits, temperature=0.8, top_k=10): logits = logits / temperature if top_k > 0: topk_vals, topk_idx = torch.topk(logits, top_k) masked = torch.full_like(logits, float("-inf")) masked.scatter_(1, topk_idx, topk_vals) logits = masked probs = torch.softmax(logits, dim=-1) return torch.multinomial(probs, 1).item()

这里先按温度缩放，再用 top_k 把概率最低的几十个候选屏蔽掉，避免模型在某个位置突发奇想输出一个标点乱飞的错字。这两个操作合在一起，比单纯调 temperature 稳定得多。真正的生成循环是这样：把当前的字符序列截取最后 seq_len 个，喂给模型，取最后一个位置的 logits 采样，把新字符追加到序列末尾，窗口往前滑动一格，重复直到达到目标长度。

def generate(model, seed_ids, length, temperature=0.8, top_k=10): model.eval() idx = seed_ids with torch.no_grad(): for _ in range(length): x = torch.tensor(idx[-seq_len:]).unsqueeze(0).to(device) logits, _ = model(x) next_id = sample_from_logits(logits[0, -1], temperature, top_k) idx.append(next_id) return "".join(idx2char[i] for i in idx)

我跑出来的效果，用“韦小宝当下说道”开头，温度 0.8、生成 200 字时会得到类似这样的片段：

韦小宝当下说道：“你这人胡说八道，我几时认得你？”那老者一怔，随即笑道……

注意这只是一段风格示意，不是金庸原文；复现的话每次结果都不同。用“康熙”开头就会自动进入朝堂对白的气口。这就是字符级 LSTM 最有说服力的地方：没人教它什么场合说什么话，它靠字符转移概率自己学会了。

5. 训练 LSTM 写小说最常见的 5 个坑：现象、原因与处理

5.1 UnicodeDecodeError：老 txt 的编码玄学

现象：preprocess.py 一运行就报 UnicodeDecodeError，或者好不容易读进来，打印一串类似“鍚堣偛”的乱码。

原因：网上流传的《鹿鼎记》txt 多是 GBK/GB2312 编码，而 Python 打开文件默认 utf-8，直接 open(path, "r", encoding="utf-8") 必然翻车。还有的 txt 头部带 BOM，有的中途混入 GBK 片段，单一编码策略救不回来。

解决：read_text 里按 utf-8、gbk、utf-16 的顺序逐个尝试，这是最省心的探测方式；还是乱码就检查 txt 是否夹杂了繁简字体，繁体部分用 opencc 统一转简体再继续，否则 vocab 里会出现“韋小寶”和“韦小宝”两套字符，生成时繁体字不受控，一会简一会繁非常出戏。

5.2 生成全是复读机：温度太低、序列太短、过拟合

现象：训练到第 5 个 epoch，不管 seed 是什么，输出都是“哈哈哈哈哈哈”或“韦小宝道韦小宝道韦小宝道”无限循环。

原因：三个因素叠加。一是采样用了 argmax 或 temperature=0.2，概率分布太尖锐，模型永远选最高概率字符；二是 seq_len=32 这种短窗口，模型只能学到几个字的局部循环，学不到长距离句式；三是 epoch 太多，模型把训练文本背下来了，复读是最稳妥的“安全牌”。

解决：生成时先让 temperature 回到 0.8-1.0，加 top_k=10；把 seq_len 提到 64 或 128 重新训练；epoch 控制在 3-4 个。到底哪种原因，看 loss：loss 已经低于 1.2，优先怀疑过拟合，直接加载前面 epoch 的 checkpoint，比继续训练省钱。

5.3 loss 卡在 8 附近不动：输入输出错位

现象：训练了半小时 loss 纹丝不动，始终在初始值 8 附近徘徊。

原因：最常见的是数据切分错位。x 取 chars[i:i+S]，y 也取了 chars[i:i+S]，模型预测的和答案完全重叠，学了个寂寞；或者忘记标签错位对齐，loss 被前一位置的真实字符主导。

解决：构造样本时严格写成 window[:-1] 和 window[1:]；训练前打印一对 x 和 y 人工核对，x 的最后一个位置应该等于 y 的第一个位置。另一个隐蔽原因：CrossEntropyLoss 对 logits 和 labels 的 shape 有要求，直接把 (B, S, V) 传进去会报错而不是默默算错，看到报错就检查 reshape 是否写成了 view(-1, vocab_size)。

5.4 显存或内存爆掉：batch、seq_len 和 hidden 的三重乘法

现象：GPU 用户跑到第 200 个 batch 报 CUDA out of memory；CPU 用户内存涨到十几个 GB 后直接被系统 kill。

原因：LSTM 的显存占用是 batch×seq_len×hidden_size×层数的中间状态，seq_len=128 时一个 batch 就有上万个时间步的隐藏状态要存，任何一项翻倍都会让占用暴涨。

解决：优先降 batch_size 到 32 或 16；还爆就把 seq_len 从 128 降到 64；最后降 hidden_size 到 128。降 batch、再降 seq_len、最后降 hidden_size，三个参数对训练质量的影响递减，这是性价比最高的降耗顺序。用 CPU 跑时，LSTM 的速度瓶颈在单步循环上，可以用 torch.set_num_threads 限制到物理核心数，别默认吃满所有逻辑核导致系统卡死。

5.5 恢复 checkpoint 后 loss 反弹回高位

现象：昨天训练到 loss=1.8，保存了 checkpoint，今天加载继续训练，第一个 epoch loss 直接跳到 3.5，然后慢慢降回去。

原因：只保存了 model.state_dict，optimizer 里的 momentum 和学习率状态全部被重置，Adam 重新从零累积一阶二阶矩，前几百步在高学习率下震荡，表现就是 loss 回跳。如果还改过词表或换过数据文件，idx2char 映射对不上，结果会更离谱。

解决：保存 checkpoint 时把 optimizer.state_dict、epoch、loss 一起打包，像第 3.3 节那样；恢复时分别 load 再继续训练。如果确实只保存了 model，加载后前几百步用较小的学习率热启动，比如 1e-4，等 loss 回到原水平再切回 1e-3，也算一种事后补救。

6. 让生成结果更像鹿鼎记：温度采样、种子设计与验收方法

6.1 按文本类型选采样参数

对白多的段落温度 0.7-0.8，叙事段落 0.9-1.1。怎么判断当前生成的是对白还是叙事？看 seed 里有没有“说道”字样：seed 带“说道”，模型大概率先走对白，这时温度低了会复读“说道”，温度高了会蹦出不存在的口语词。我的经验区间如下：

6.2 用 seed 控制“角色出场”

模型其实已经学会了文本里不同角色的用词倾向：“康熙”后面跟的多是朝堂词，“韦小宝”后面跟的是市井口语。生成时直接用不同 seed 做可控生成：seed 用“康熙道”生成朝堂戏，用“韦小宝笑道”生成市井戏。如果你想稳定控制某个角色的口吻，可以在数据预处理时给不同角色的对白前加特殊标记，比如<韦小宝>这样的 token，但这是进阶玩法，基础版靠 seed 就够用。

6.3 验收：不止看 loss，还要看复读率

拿一段保留的文本算 perplexity 是客观指标，但对小说生成，perplexity 低不等于好看。我自己的验收办法是“复读率 + 人眼扫描”：

def repetition_rate(text, n=8): seen = 0 for i in range(len(text) - n): if text[i:i+n] in text[i+1:]: seen += 1 return seen / (len(text) - n)

生成 300 字，计算任意连续 8 个字符在整段里被重复出现的比例，超过 30% 就判定复读，直接换 checkpoint 或调高温度；剩余段落人眼扫一遍，看繁体字残留、括号不配对、引号只开不合。出现语法层面的错乱，不用回训练环节找原因，先查清洗阶段的字符过滤规则。

这套项目跑到最后，我最大的血泪经验是：不要在 loss 好看时就急着收手。小说生成的质量分水岭在采样参数和 seed 设计上，这两件事对每个 checkpoint 都要重试一遍，多存几个 checkpoint 就是多买几份后悔药，训练一次不算贵，重训一次才贵。希望帮到你。

本文还有配套的精品资源，点击获取