企业官网建设流程全解析

简介：面向短剧、漫剧创作者、内容团队及AI产品开发者的一份自动化生成平台源码包。其核心定位是输入一句话即完成从剧本、分镜、配音到成片输出的全流程创作，把原本依赖编剧、拍摄、剪辑的复杂链路压缩为AI驱动的单点操作，显著降低短视频制作门槛。包内共365个文件，以Go语言后端服务为主体，搭配TypeScript与Vue构成前后端工程，核心模块涉及提示词处理、AI控制、分镜任务调度等，另含SQL脚本、环境变量、说明文档与配置文件，压缩包约2.48MB，目录结构清晰便于按模块定位代码。当前已有805人学习下载。这份资源包含可部署的前后端源码、自动化分镜任务调度逻辑与配套配置示例，可直接用于二次开发或原型验证；从文件结构可观察Go服务与前端Vue工程的清晰分层，方便梳理一句话生成短剧的整体架构与数据流转路径。

1. 灵果短剧AI在解决什么问题：一句话到成片，中间的坑比想象中多

“一句话生成一部短剧”听起来像营销话术，但灵果短剧AI这类一站式平台，确实把短视频剧集的生产拆成了可自动化的流水线：剧本由大模型生成，分镜从剧本结构化出来，画面、配音、字幕、背景音各自由独立模型完成，最后合成一个完整成片。对于没有导演和剪辑团队的个体创作者、MCN中台，或者想短周期验证剧情脚本的短剧从业者，这套方案能大幅压缩从创意到样片的时间。但“全自动化”不等于“全自动出好片”，真正落地时，模型的配合方式、参数的调整，以及中间格式的可靠程度，往往比模型本身更决定成片质量。这篇笔记会顺着这条流水线，把每个环节做什么、为什么这样做、参数怎么调、坑在哪里讲透。

2. 拆开“全自动化”：从剧本到成片的六段流水线

一个完整的短剧/漫剧生成平台，内部并不是一个“大模型吃进一句话吐出一整段视频”，而是一条多AI协作的流水线。我接触过的类似方案，基本都是六个模块串起来：剧本生成、分镜设计、角色与画面生成、配音、字幕/合成。下面拆开讲清楚每个模块的职责和选型理由，这对后续调参和排错很重要。

2.1 为什么不能只要一个大模型：多AI协作的流水线结构

很多第一次接触这类平台的人会问：为什么不直接用视频生成大模型，比如输入“悬疑短剧开场，妻子深夜回家发现门锁被换”，让模型直接输出一段40秒视频？答案是目前任何单模型都做不到可控的剧情和角色一致性。视频生成模型擅长生成几秒到十几秒的“画面片段”，但它不理解“第一集留悬念、第三集揭示对立”这种叙事结构，更无法保证同一角色在不同镜头里长得一样。这就像让一个画师直接画一部动画，他画得完，但前后风格、人物长相、剧情连续性都会崩。

所以常见做法是拆成多个专用模型，用流水线把任务分给不同模型：语言模型负责把一句话扩写成剧本，另一个语言模型把剧本转成分镜表，图像模型根据分镜生成关键帧，视频模型再基于关键帧生成动态片段，TTS模型负责对白，最后用FFmpeg之类工具合成。每个环节只做一件事，彼此通过文件或JSON接口传递数据，这样即使某个环节翻车，也能单独替换或重新跑。这个思路不是灵果独有，而是这类AI视频生成的通用工程架构。

流水线的数据结构，可以用一个简单的 JSON 中间格式来理解。以下是我在类似项目里常用的一种分镜表示：

{ "video_title": "陌生邻居", "scenes": [ { "scene_id": 1, "duration_sec": 5.0, "shot_type": "中景", "camera": "缓慢推进", "prompt": "深夜公寓走廊，一个年轻女性站在自家门前，钥匙滑落", "dialogue": "（钥匙声）怎么打不开？", "character": "女主" } ] }

这段结构里，scene_id 用来排序，duration_sec 控制时长，prompt 给视觉模型，dialogue 给配音。把剧本输出成这种结构的好处是：后续每个模型读到的都是明确的“最小任务”，视频生成模型一次性只需生成5秒内容，压力小，生成成功率也高。参数说明：shot_type 和 camera 会影响镜头控制，但在国内可用的视频生成模型里，它们未必会被完全遵守，所以 prompt 里的描述越具体越好。

2.2 剧本生成与结构化分镜：中间格式才是关键

流水线的第一环是“一句话扩展成剧本”。这里的核心不是让模型写得多精彩，而是让它输出“结构化剧本”——即带有场次、角色动作、对白、时长的脚本。如果只输出一个散文故事，后续分镜就没法自动化。所以常见做法是在 Prompt 里强制模型输出 JSON 或表格，然后用代码解析。灵果这类平台通常内置了剧本模板，但我自己接第三方模型时发现，模板的稳定性决定了整个流程的成败。

举个例子，给剧本模型的提示词里，除了写“生成一个3集短剧，每集60秒”，还要明确要求“每集包含3个场景，每个场景包含动作描述和对白”，并且给一个输出样例。这里有三点容易踩坑：第一，模型输出的 JSON 可能带注释或换行，直接 json.loads 会失败，需要先做清洗；第二，分镜数量太密会让后续视频生成步数爆炸，每集60秒分成6个10秒镜头是比较稳的节奏；第三，对白里如果包含括号动作提示，配音模型会读出来，必须用正则提前剥离。

剧本模型我一般会用支持超长上下文的对话模型，因为生成完一集后，下一集要基于前情，避免人物关系和风格断裂。如果直接用无状态接口，每集的角色设定会漂移，刚才还叫“女主张薇”，下一集可能变成“李薇”。一个很土但有效的办法是：把第一集生成的“人物设定表”作为额外上下文，喂给第二集的生成请求，而不是只喂第一集全文。

2.3 角色一致性与画面生成：最考验工程的部分

分镜表有了，下一步是生成画面。这一步在全自动化链路里最不可控。视频生成模型确实能根据 Prompt 生成动态片段，但同一个角色在多个分镜里要保持五官、服装、发型一致，需要额外机制。常见做法有两种：一种是先用图像模型（SD系列）生成一张“角色设定图”，然后在视频生成时把这张图作为条件输入，让模型参考；另一种是给每个角色设计一个独特的视觉标记词，比如“红色短发、左脸有痣”，保证每次 Prompt 都带上这个词。

我在实际项目里更推荐“角色图 + 描述词”双保险。因为纯文字标记在长剧集里会丢失，模型一眼没注意就成了另一个人。角色图相当于给了一个参考锚点，大幅降低脸崩概率。具体实现上，可以用 IP-Adapter / 类似参考网络，也可以直接把角色图拼进首帧。不同视频模型对输入格式的要求差异很大，有的只认首帧图，有的支持多参考图，所以在配置层要留出接口，不要写死。

漫剧和短剧在这里也有区别。漫剧的画面相对静态，主要靠分镜切换和运镜，对视频生成的一致性压力小得多，甚至可以退化为“高质量图片 + 局部运动”方案。短剧则更需要肢体动作和面部表情，对视频生成模型的推理时长和显存要求更高。如果只是做漫剧，我不建议直接上视频生成，用图生视频里“轻微运动”模式就够，成本低且不容易鬼畜。

2.4 配音、字幕与成片合成：用 FFmpeg 把碎片拼成剧

画面片段生成后，还需要配音、字幕、背景音乐和拼接。配音这一环相对简单，TTS 模型已经非常成熟，需要注意的就是语速和情绪标注。台词模型支持情感提示，比如“（低声）”“（急促）”，但并不是所有 TTS 都认，需要测试。我一般会把对白中的括号内容全部剥离，只保留纯台词，然后用额外的参数控制语速和音调，否则配音会给人“念稿”的感觉。

最后合成阶段，所有AI平台都离不开 FFmpeg。这一步的工程价值常常被低估。每个分镜的视频片段分辨率、帧率可能不同，拼接前要统一转码；字幕文件需要和音频时间轴对齐，而音画不同步是最常见的翻车原因。我会在这时做一个中间检查：先不合成画面，只把对白音频拼起来，检查总时长是否与分镜总时长一致，差了再调整视频片段时长或加转场。使用 FFmpeg 合成的基本命令如下：

ffmpeg -f concat -safe 0 -i filelist.txt -c:v libx264 -pix_fmt yuv420p -crf 18 output.mp4

其中 filelist.txt 每行是“file 'scene_001.mp4'”，顺序由分镜编号决定。逻辑说明：concat 协议用于无缝拼接同编码片段，libx264 做编码，yuv420p 保证兼容性，crf 控制画面质量。参数说明：crf 值越小质量越高，但文件也更大；如果片段分辨率不一致，要先统一分辨率，否则 concat 会失败或黑屏。这一步的坑，后面避坑章节还会细说。

3. 本地部署与最小跑通：从 Lingg.zip 到第一条成片

拿到灵果短剧AI这类 zip 包后，第一件事不是急着跑，而是先搞清包里的结构。常见的压缩包会包含核心代码、模型调用脚本、配置文件和一个示例输入目录。部署的核心是把模型后端接好，而不是把前端跑起来。下面按环境、配置、最小示例三步走。

3.1 环境准备：Python版本、依赖与显存规划

这类项目几乎都是 Python 写的，依赖里通常包含 PyTorch、transformers、diffusers、openai、ffmpeg-python 等。如果直接用全局环境，很容易和已有的包冲突。我一般会先建一个独立的虚拟环境，再用 requirements.txt 安装。注意两个高频坑：第一，PyTorch 和 CUDA 版本不匹配会导致模型加载时报错；第二，有些包在 requirements.txt 里是 github 路径，需要先装 git 和编译工具。

一个相对稳妥的安装流程如下：

cd Lingg python -m venv venv source venv/bin/activate pip install --upgrade pip pip install -r requirements.txt python -c "import torch; print(torch.__version__, torch.cuda.is_available())"

逻辑说明：venv 把项目依赖隔离在单独目录，避免污染系统 Python；requirements.txt 是项目开发者锁定的依赖清单，按顺序安装即可。参数说明：最后一行用来验证 torch 是否识别 GPU，如果输出 False，说明 CUDA 没装对，后面跑视频生成几乎注定翻车。这一步会花不少时间，建议用国内 pip 镜像加速，但不要因镜像版本滞后而强制升级核心依赖。

显存规划是另一件大事。视频生成模型对显存的占用非常高，默认参数下，生成 10 秒 512x768 的视频，一般需要 12GB 以上显存。如果你的显卡只有 8GB，常见做法是开启 offload（把模型权重临时放在内存，GPU 只做计算），或者降低生成分辨率。灵果这类平台如果集成了视频生成后端，配置文件中通常有“device_map”或“enable_offload”选项，不要忽略它。显存不够会直接 OOM 崩溃，但很多项目不会告诉我“OOM”因为它是静默的，表现为生成到一半进程退出。

3.2 配置 config.yaml：模型后端、密钥与路径

解压之后，项目根目录一般会有一个 config.yaml 或 .env 文件，记录了所有模型接口的配置。无论是调用云端大模型 API，还是本地加载开源模型，都要在这里把地址、密钥、模型名称写清楚。常见做法是：剧本模型用云端 API，视频和图像模型用本地/私有化部署。因为剧本模型的上下文理解和长文生成，云端模型效果更好；而视频模型如果走云端，按秒计费，成本非常高，所以有本地算力的话尽量本地跑。

下面是我整理的一个最小配置示例，比真实项目的简单，但结构类似：

llm: provider: "openai_compatible" base_url: "http://10.0.0.2:8000/v1" api_key: "sk-xxx" model: "qwen-long" temperature: 0.7 video: provider: "local" model_path: "/data/models/animatediff_ckpt" resolution: [512, 768] frames: 30 enable_offload: true tts: provider: "edge_tts" voice: "zh-CN-XiaoxiaoNeural" rate: "+10%"

参数说明：llm 段里的 base_url 指向一个兼容 OpenAI 接口的服务，api_key 可以是代理服务生成的，不一定是某个官方账号的密钥；temperature 控制剧本的随机性，0.7 算是稳定和创意的平衡点，做剧情悬疑时我会调到 0.8，做口播短剧会降到 0.5。video 段里的 model_path 是本地模型权重目录，frames 表示要生成的帧数，30 帧配合 512x768 在大多数场景下能生成约 1 秒内容。tts 的 rate 是语速偏移，+10% 表示比默认速度快 10%。

这里要特别提醒：不要把云端服务的接口地址误写成 localhost。把大模型部署在同一台机器上的话，地址通常是一串局域 IP，localhost 只在同一进程内起服务时才有效。配置好后，建议先用 curl 快速验证接口能不能通，再跑完整流程。

3.3 跑通最小示例：一句话生成10秒漫剧

配置完成，接下来跑一个最小的示例。项目里一般会有一个 run_pipeline.py 或 split_generator.py 之类的主脚本，入口是传入一句剧情梗概，输出成片路径。我第一次跑的时候，会先用一个极短的句子，比如“女主发现邻居的门锁换了”，而不是给“三十集都市悬疑”这种大活，方便定位问题。

一个典型的最小调用如下：

python run_pipeline.py --text "女主深夜回家，发现门锁被换" --scenes 2 --output demo1.mp4

逻辑说明：--text 是那句“一句话”，--scenes 控制生成几个镜头，这是为了快速验证，--output 是输出文件。参数说明：如果脚本内部用的是配置文件里的模型，那么 --scenes 2 会让剧本模型输出两个分镜，后续视频生成也只跑两个片段，整个流程可以在几分钟内跑完。如果此时显存不够，就把 config.yaml 里的 resolution 改成 [384, 512] 再试。

跑通之后，你会看到输出目录里多了一些临时文件：剧本 JSON、每个分镜的图片/视频、对白音频、字幕 SRT，最后合成的 demo1.mp4。我一般会逐个检查这些中间文件，因为“成片能播放”不等于“环节都正确”。例如，有个分镜视频是黑屏，但整体合成成功了，这种情况就是某个环节静默失败，必须看日志里有没有“empty frame”之类的警告。把这个最小链路跑通，后续才谈得上批量生成和调质量。

4. 让输出变“能看”：四个关键参数组怎么调

跑通不等于能用。AI 生成的短剧在“能看”和“不能看”之间的差距，往往是几个关键参数决定的。这一章把调参经验按流水线顺序展开：剧本、分镜、视频、配音字幕。每个参数都给出我常用的取值范围和调整方向，你可以把它们作为起点，再针对自己的素材微调。

4.1 剧本参数：长度、冲突密度与句式

剧本生成参数中最重要的是“输出长度”和“随机性”。输出长度由 tokens 或字数上限控制，如果你发现生成的对白像论文一样长，或者三句话就结束一个场景，就要调整长度参数。另一个是 temperature：高于 0.9 时模型会频繁“脑洞”，容易出现前后矛盾的角色决策；低于 0.4 时又过于机械，像是翻版广告文案。我处理悬疑短剧时一般用 0.75，处理甜宠剧会降到 0.6，因为甜宠剧更依赖固定套路，不需要太多意外。

除了采样参数，Prompt 才是最大的“参数”。建议在提示词里显式限制对白句式，比如“不写旁白，只写对白”，以及“每句对白不超过25个字”。原因是短剧观众只能通过字幕快速读对白，长句会让人觉得节奏拖沓。如果项目里支持“负面提示词”给 LLM，也加上“避免总结性句式、避免主角长篇内心独白”，这一类限制比调 temperature 更有用。

4.2 分镜参数：镜头数、运镜与画面描述

分镜是把剧本转成画面的关键，这一层的参数往往会被忽略。最重要的两个是“每集场景数”和“每个场景的时长”。场景数太多，每个场景分配到的时长变短，视频模型来不及展示有效动作；场景太少，又会让画面看起来像幻灯片。一个规律是：每 10 秒的视频，控制在 2 到 3 个镜头的节奏，这样既有机位变化，又保留了脸部特写的停顿。

画面描述要尽量贴近视频生成模型的语言习惯。你没做过的话，可以从这三个维度补全描述：主体动作、镜头运动、场景氛围。举例：

{ "scene": 1, "duration_sec": 5, "prompt": "深夜公寓走廊，暖黄灯光，女主拿钥匙开门却打不开，镜头缓慢推进到她的面部，表情紧张" }

逻辑说明：这段 prompt 的前半段是静态环境，中间是动作，末尾是镜头和情绪。参数说明：如果视频模型对“缓慢推进”支持不好，就换成“固定镜头”或“变焦”，生成失败率会低很多。另一个常见参数是 negative_prompt，比如“文字、水印、模糊、变形的手、多余的人”，能显著减少画面瑕疵。灵果这类平台可能在分镜生成阶段没有让用户填负向提示，但我一般会在配置文件里预留一个字段，把负面词传进去。

4.3 视频生成参数：帧率、步数与分辨率

视频生成的三个最关键参数是帧率、采样步数和分辨率。它们的优先级排序是：分辨率 > 步数 > 帧率。分辨率高反而容易让画面细节崩坏，因为模型在 1024x1024 下生成的复杂场景，手部和眼睛跑形概率远大于 512x768。如果不是做横屏精品，我建议默认 512x768，竖屏短剧对应的分辨率。

采样步数和帧率的关系也容易被误解。步数决定视频的噪声去除次数，步数太低画面闪，太高会过饱和。通常 20 到 25 步是安全区。帧率参数会影响文件大小和流畅度，但很多视频模型并不支持任意帧率，只支持 15/24/30 等预设。如果把帧率设成 18，模型会直接按 15 处理，导致实际时长不符合预期。我一般把生成的帧率设为 24，导出成片时再用 FFmpeg 转成 30，避免单个片段时间轴错位。

还有一个容易被忽视的参数是“无种子”。视频模型每次生成不同画面，适合跑多版本，但如果你想重现某次满意的效果，就必须固定随机种子。种子参数一般写成 seed: 42，但注意不同模型版本对同一 seed 的响应不一样，所以记录 seed 时顺便记模型版本，不然下次更新权重后，之前的参数组合也回不到原来的效果。

4.4 配音字幕参数：语速、对白样式与背景音

配音参数往往决定一个 AI 短剧是否“像样”。TTS 提供语速、音调、音量三个基础参数。语速推荐在+10%到+20%之间，因为 AI 合成默认语速通常偏慢。音调要根据角色设置，主角和配角的音调差太近会让观众分不清是谁在说话。如果你是在平台上批量生成，配置文件里可以按角色定义 voice 字段，同一声色共用同一 TTS 声音。

字幕生成也有技术细节：如果对白是模型生成的，字幕的时间戳需要通过音频的静音段来切分，而不是按文本字数推算。很多项目简化处理，直接用朗读时长倒推，结果字幕提前或滞后。更好的做法是让 TTS 接口返回词级时间戳，或者用语音识别反向对齐。如果项目不支持，至少要把字幕延迟 100 到 200 毫秒，因为人眼识别字幕有惯性，字幕比声音稍微慢一点反而自然。

背景音和音效，通常最后用 FFmpeg 混流。混流的参数主要是音量平衡：

ffmpeg -i dialogue.wav -i bgm.mp3 -filter_complex "[1:a]volume=0.2[b];[0:a][b]amix=inputs=2:duration=first" mix.wav

逻辑说明：dialogue.wav 是对白音频，bgm.mp3 是背景音乐，通过 volume 滤镜把背景音乐降到 0.2 倍音量，再用 amix 合并。参数说明：amix 的 duration=first 让输出音频长度跟随第一个输入，也就是对白音频的时长。背景音太大是很多 AI 短剧的通病，建议 0.15 到 0.25 之间，宁可弱也不要盖过人声。

5. 常见问题排查与避坑指南：把翻车率打下来

跑通和调参之后，你会遇到一些“玄学”问题，有时同一套配置，生成结果却截然不同。这一章写几个高频踩坑案例，每条都是现象、原因、解决的结构，也是我自己的血泪经验。

5.1 画面崩坏与闪烁：清空缓存、锁定种子

现象：同一段文本生成两次视频，第一次人像正常，第二次的人脸扭曲，或者视频每帧之间的画面剧烈闪烁，像老式电视信号不好。 原因：闪烁通常是因为视频生成模型在逐帧推理时没有稳定的帧间约束。人脸扭曲则可能是随机种子的影响，也可能是参考图像没有被模型正确读取。这类问题属于概率性翻车，但在长剧集里一旦出现，会让人反复重跑，成本极高。 解决：首先清理临时缓存目录，很多项目会把之前的中间帧存在缓存里，重跑时意外复用了坏数据。其次把随机种子固定下来，找到一个能接受的输出后锁住 seed。最后如果还闪，就把视频解析度降低一级，比如 768 降到 512，闪烁概率明显下降。

5.2 音画不同步：先查节拍再查转码

现象：成片中人物的嘴型明显比台词快半拍，或者动作发生完声音才出来。 原因：常见原因是分镜时长和 TTS 生成的音频时长不一致。比如脚本里写了这个镜头 5 秒，但TTS朗读对白花了8秒，拼接时系统直接按“音频总时长”延迟下一个镜头，导致画面停留在上一个结尾处。另一个原因是转码时帧率不匹配，影响了播放速度。 解决：先逐个检查分镜的 audio_duration 和 duration_sec 是否有偏差。有偏差就优先调整分镜时长或文字内容，不建议硬调音频速度，那样声音会变调。然后确认所有视频片段都由同一个帧率参数生成，最后统一转码。如果项目是直接拼接不重编码，一定要用 ffprobe 查看每个片段的实际时长，因为生成的mp4时长经常比物理帧数少1到2帧。

5.3 长剧集上下文丢失：分段生成再合并

现象：第1集里主角叫张文，第2集突然变成林文；或者前一集设置的悬疑线，到第5集完全没交代。 原因：这是因为长剧集拆集生成时，每次只给模型当集的输入，没有把前面的剧情摘要传给下一集。分段生成是性能上的必要手段，但模型上下文是“短时记忆”。 解决：在生成第N集之前，先用模型把前N-1集的剧情摘要压缩成300字以内的梗概，连同“人物设定表”一起作为上下文字段传给下一集。这个做法比直接喂全部历史文本更省钱，也更稳定，因为历史里的低质文本不会被错误带入。灵果这类平台如果支持“续集模式”，一般也是这个原理；如果不支持，可以自己做一层缓存，把人物设定、地点、关键线索存成结构化文件。

5.4 显存溢出与模型加载失败

现象：运行到视频生成阶段时，终端打印 CUDA out of memory，或者进程直接退出没有报错；模型加载时报“size mismatch”或“unexpected key”。 原因：显存溢出通常是分辨率或批处理大小设置过高。尺寸不匹配则是因为下载的权重版本和代码里的模型结构不一致，最常见的是在 diffusers 架构和原生 checkpoint 之间混用。 解决：显存溢出先关掉所有非必要进程，再把 config.yaml 里的 resolution 设为 384x512，同时打开 offload 选项。如果还溢出，就把视频生成拆成两个短片段。模型结构不匹配的解决方式，是把权重转换成项目要求的格式，一般要在项目仓库里找转换脚本，而不是单独下新模型。注意不要同时加载多个大模型到同一块卡上，可以通过把 LLM 走 API、只把视频模型放本机的方式，错开显存占用。

6. 进阶玩法：从批量生成到人工审核闭环

当你能稳定生成单条成片后，下一个瓶颈是效率和品控。我最后的建议是，别让全自动化完全闭环，要在流水线里留一个“人工审核口”。这个口不是让你去剪视频，而是只看三样东西：分镜表、首帧图和成片前5秒。分镜表能看出剧情逻辑是否断裂，首帧图能看出角色一致性和画风漂移，成片前5秒能发现画面崩坏和音画脱节。只要这三项过关，整条成片大概率能看。用这个方法，我曾在一次短剧批量生成中把返工率从一半降到十分之一。

批量生成的高效做法，是把“一句话创意”做成Excel表，每行是一个剧名和梗概，然后用脚本循环调用流水线。这里的关键是设置一个“暂停条件”：某个分镜连续失败两次，就停止这一集的生成，而不是硬跑到底。因为视频生成是概率性的，失败越多，后续的错误会像滚雪球一样被堆进成片里，最后整个片段都不能用。失败的分镜可以单独重跑，不要把整条流水线重跑一遍，否则时间成本翻倍。

我还有一个习惯：每次生成完，把这次用到的 prompt、种子、模型版本都记录在一个 manifest 文件里，连同成片一起归档。听起来像是额外工作，但当客户要求“这个风格再出一部”时，你就会发现，没有元数据的话，想复现某种效果几乎全凭运气。这套做法在单条生成时很麻烦，但做成短剧矩阵后，它就是你能持续复用的“后悔药”。

真正做下来，我最大的体会是：AI短剧生成平台不是让你把导演替换掉，而是让你把制片时间缩短。工具的价值在于让创作者有更多试错机会，而不是让机器替你决定什么是好故事。希望这套从拆解到调参、从踩坑到验收的路径，能帮你在灵果短剧AI这类平台上少走一段弯路。

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