本地 AI 角色扮演指南：LLM、图像生成与语音克隆

到了 2026 年，本地 AI 角色扮演不再一定意味着：

打开终端，安装 48 个 Python 包，搞坏 CUDA，哭一场，然后重装 Windows。

好吧。有时还是这样。

不过，现在确实可以搭建一个完全在自己电脑上运行的系统：

角色在本地思考 → 在本地回复 → 在本地生成场景图 → 用本地语音说话。

下载好模型后，这些操作不需要互联网。不需要云端 API；本地组件仍然通过电脑上的本地 API 相互通信。

没有按 token 收费，没有消息配额，也不用把聊天记录发给别人的服务器。

更有意思的是，各个组件已经能够组合出不错的体验，不必像一场专门给喜欢盯着显存占用的人看的技术演示。

这篇文章会搭建四个部分：LLM → 前端 → 图像生成 → TTS，并讨论 6、8、12 和 16 GB 以上显存适合怎样的配置。

我们到底在搭建什么？

如果你想先看看这套组合外面的游戏，Multiic 的 AI 角色扮演介绍展示了角色卡、多人场景、记忆和画面如何协同工作。

简化后的本地 AI 角色系统是这样的：

                 ┌─────────────────┐
你的消息 →   │       LLM       │
                 │ KoboldCpp/GGUF  │
                 └────────┬────────┘
                          │
                  角色回复
                          │
             ┌────────────┼────────────┐
             ▼            ▼            ▼
         界面      ComfyUI        TTS
                         图像        声音
             │            │            │
             └────────────┴────────────┘
                          │
                        场景

先明确一点：它不是一个巨大的单一 AI 模型。通常使用多个专门的模型更方便。

LLM 负责：

对话。
性格。
记忆。
场景逻辑。

图像模型负责：

角色外貌。
姿势。
环境。
光照。
镜头。

TTS 负责：

声音。
语调。
情绪。
发音。

前端把它们连接起来。这种模块化正是本地系统的魅力：不喜欢声音，就换 TTS；不喜欢画风，就换 checkpoint。

凌晨三点在 Hugging Face 找到新的 RP 模型？换一个 GGUF 就行。

十分钟后，你又开始说服自己：下载一个 9 GB 模型，也算科学研究。

我推荐的组件组合

如果想先看简短答案：

我推荐的组件组合
组件	我会使用什么	用途
LLM 运行程序	KoboldCpp	方便运行 GGUF
LLM 模型	Saiga Nemo / Qwen3.5 / 优秀 RP 微调模型	取决于显存和语言
前端	Multiic 或 SillyTavern	角色、记忆和界面
图像后端	KoboldCpp / ComfyUI	快速开始 / 灵活工作流
图像模型	SDXL / FLUX / Qwen Image / 新一代 4B 模型	取决于 GPU 和任务
快速 TTS	Supertonic 3 / Kokoro	快速本地语音
声音克隆	Qwen3-TTS	新一代克隆与表现力
较老但仍能使用的克隆方案	XTTS-v2	成熟生态与现有集成

不一定非用这些程序，但这是一个不错的起点。

第一部分：本地 LLM

先从大脑开始。

GGUF 格式很适合本地 RP。使用兼容的运行程序，可以：

完全在 GPU 上运行。
部分在 GPU 上运行。
把部分权重放在系统内存里。
完全在 CPU 上运行，只要你有僧侣般的耐心。

在 Windows 上，KoboldCpp 是一个简单的选择。

KoboldCpp

KoboldCpp 从一个简单的 llama.cpp 启动器发展成了相当强大的工具。一个独立可执行文件即可在 CPU/GPU 上运行兼容 GGUF，支持全部或部分 GPU 卸载，并通过 API 提供生成结果。项目也支持图像生成、语音识别、TTS 和多种兼容 API。

Windows 上的大致步骤：

下载 koboldcpp.exe。
下载 .gguf 模型。
选择模型。
设置上下文长度。
为兼容的 NVIDIA GPU 启用 CUDA。
启动。

不用单独安装 Python，不用 conda，也不用向 requirements.txt 献祭。所以我常把它推荐给想玩游戏的人，而不是想再拿一个依赖管理学位的人。

KoboldCpp 还提供位于 /v1 的 OpenAI 兼容 API，前端不一定需要知道背后是本地模型。典型地址：

http://127.0.0.1:5001

前端发送提示词，接收文本。

选择哪个 LLM？

我另有一篇本地角色扮演模型指南，这里简单介绍。

6 GB 显存

英语 RP 可以选 Stheno 8B Q4。如果更重视智能与多语言，可以考虑更小量化版本的 Qwen3.5-9B。

8 GB

Qwen3.5-9B Q4 可以作为通用选择。

俄语可以使用 Saiga Nemo 12B Q4_K_M，但模型文件本身约 7.5 GB，需要较小上下文或部分 CPU 运行。

12 GB

俄语方面，我喜欢 Saiga Nemo 12B Q5/Q6。

英语方面：Rocinante-X / Impish Bloodmoon / 其他优秀 Nemo RP 微调模型。

16 GB 以上

可以考虑 20–30B 模型和 MoE：Gemory 26B-A4B、Gemma 4，以及更大的 Qwen。

量化方式和总权重大小仍然重要。MoE 的活跃参数数量，并不代表保存全部权重所需的内存。

上下文设多大？

不要自动选择模型页面标注的最大值。支持 128k 并不意味着：

太好了，那就设成 128000。

上下文会通过 KV 缓存消耗内存。普通 RP 我会从这里开始：

8192–16384

只有确实需要时再增加。可用的 16k 上下文通常比 128k 更实用；后者可能把一半模型挤进系统内存，让回复速度变成一只沉思的乌龟。

使用 CPU 并不是失败

有一种奇怪的想法：

模型必须全部放进显卡。

不一定。KoboldCpp 可以把部分层留在系统内存，由 CPU 计算。速度会变慢，但 RP 不要求每秒 100 tokens。

每秒 8–20 tokens 也可能很舒服，尤其是开启流式输出后：剩余内容还在生成，文本已经逐渐显示。要让声音同样提前开始，还需要单独支持流式 TTS 的集成。

第二部分：前端

单独的 LLM 不会管理：

角色卡。
人际关系。
持久记忆。
外貌。
图像。
声音。
世界。

这些通常由前端负责。有两个选择：

**SillyTavern：**适合想自己组装各个组件的人。
**Multiic：**适合想把文本、图像、角色、语音和沙盒放在一个系统里的人。

SillyTavern

SillyTavern 已成为常见的本地角色聊天前端。它支持：

角色卡。
群聊。
世界书。
用户人设。
记忆功能。
TTS。
图像生成。
KoboldCpp 连接。
API 连接。

文档将 KoboldCpp 描述为独立的 GGML/GGUF API，并提供 NVIDIA 快速入门。如果你的目标是：

和角色聊天，并自己组装整个系统。

它是一个不错的选择。

Multiic

Multiic 走的是另一条路线：LLM + 图像 + 语音 + 角色 + 场景状态 + 沙盒。LLM 在可视化场景中回复。

可以使用：

本地 GGUF。
外部 API。
本地图像后端。
ComfyUI。
本地 TTS。

多个模态一起工作时，优势就很明显。例如：

玩家：
我走到窗边，问 Dina 看见了什么。

↓

LLM：
生成 Dina 的反应。

↓

场景导演：
确定位置、表情和镜头。

↓

ComfyUI：
生成场景。

↓

TTS：
说出对白。

这时 AI RP 更像一部没有尽头的视觉小说，而不是聊天机器人。

第三部分：本地图像生成

下一层是图像。如果想针对角色和场景灵活调整，我会选择 ComfyUI。并不是因为它的界面特别友好。

它看起来像核反应堆的电路图，被人不小心接到了动漫女孩生成器上。

但它确实很灵活。你得花时间学习节点、选择兼容模型，并搭建或调整工作流。

如果想快速开始，直接在游戏里生成图像，KoboldCpp 更简单。它支持图像生成，而且已经集成在 Multiic 中。起步时不需要额外学习 ComfyUI 或组装节点图，但仍需下载并选择兼容的图像模型。

我会先用 KoboldCpp，想要更多控制时再转向 ComfyUI，例如自定义 LoRA、角色参考图、姿势和复杂工作流。

为什么用 ComfyUI？

不再只有固定链路：

提示词 → image

而是搭建工作流：

提示词
  ↓
角色参考图
  ↓
姿势
  ↓
模型权重
  ↓
LoRA
  ↓
ControlNet
  ↓
采样器
  ↓
面部细化
  ↓
放大
  ↓
图像

前端可以自动向工作流提供数据。只需搭建一次，游戏随后改变：

提示词。
角色。
随机种子。
参考图。
姿势。
服装。
环境。

选择哪个图像模型？

这里变化比 LLM 更快。2026 年可以大致分成几类。

老朋友 SD1.5

优点：

轻量。
庞大的 LoRA 生态。
角色训练相对容易入门。
生成快。
较弱 GPU 也能使用。

缺点：

人体结构较弱。
对复杂提示词的理解较弱。
分辨率和构图落后于现代模型。

只有 4–6 GB 显存时，SD1.5 仍然值得考虑，尤其是已经有不错的角色 LoRA 时。

SDXL

SDXL 也算经典，但仍适合本地 RP。优点：

很多 checkpoints。
很多 LoRA。
需求相对适中。
速度和质量较均衡。
有保持角色一致性的方案。

8 GB 显存下，它是比较容易上手的选择，具体取决于工作流和其他已加载模型。

FLUX

FLUX 更擅长理解正常语言。你可以说：

女孩站在窗边，回头看向镜头，左手触碰玻璃，窗外是傍晚的城市。

而不是拼出：

1girl, window, looking_back, hand_on_window,
night_city, masterpiece, best_quality...

一些新版本更轻。ComfyUI 的 FLUX.2 Klein 4B 官方指南在测试用 RTX 5090 上报告蒸馏版本约需 8.4 GB 显存，面向快速交互工作流。

这对 RP 很有吸引力：快速生成通常比花两分钟做一张完美图片更重要。

Qwen Image 与指令式图像模型

另一个趋势是模型更能理解普通句子、参考图和编辑指令。对游戏来说，这比旧式标签提示方便。LLM 可以写：

Fiona 侧坐在旧沙发上，不耐烦地看着玩家。厨房透出暖光，中景，平视镜头。

直接发给图像模型。LLM 也就成了小小的场景导演。我会这样设计集成。

角色一致性

真正的难题开始了：画一个漂亮女孩很容易，画同一个女孩二十次更难。可以考虑：

角色 LoRA

成熟的方法：训练角色 LoRA，再加入工作流。优点：

帮助保持身份一致。
文件小。
使用快。

缺点：

每个角色都要训练 LoRA。

参考图适配器

越来越多模型和工作流接受一张或多张参考图。很适合用户创建的角色：保存几张肖像，生成新场景时重复使用。

图像编辑

更有趣的是编辑现有画面，而不是全部重新生成。例如：

原始图像:
Dina 坐在沙发上。

新场景:
Make her stand up and look toward the door.

长远来看，这也许是 AI 视觉小说最方便的方式。它可以帮助保留：

人物。
服装。
房间。
光照。

第四部分：本地语音

过去两年进步很大。以前本地 TTS 往往只是：

从技术上说，这是人类语音。

现在已经有适合游戏的模型。我会分为三组。

方案一：Supertonic 3，重视速度

需要非常快的本地 TTS，Supertonic 3 仍值得考虑。它使用 ONNX，为设备端快速推理设计。Supertonic 3 于 2026 年 4 月发布，支持 31 种语言，朗读更准确，重复和漏读更少。主要优势：

延迟。

角色回复后，还要等五秒才有声音，沉浸感很快就没了。快速 TTS 能更早开始播放。

重要更新

原开源项目在 2026 年 9 月归档，官方开发和支持已结束。模型和 ONNX 文件仍可下载、本地运行，但不能指望持续官方维护。模型本身不会因此变差，不过新项目应考虑这一点。

方案二：Kokoro，小巧且快速

适合重视以下几点的人：

模型小。
CPU 推理。
低延迟。

Kokoro 只有 82M 参数。一些本地实现下载文件后即可离线使用。SillyTavern 支持 kokoro.js，兼容浏览器也能使用 WebGPU。简单的角色声音可以很省资源。

方案三：Qwen3-TTS，声音克隆

这就更有意思了。Qwen3-TTS 在 2026 年 1 月发布 0.6B 和 1.7B 版本。官方模型支持十种语言：

中文。
英语。
日语。
韩语。
德语。
法语。
俄语。
葡萄牙语。
西班牙语。
意大利语。

不同版本提供：

流式语音。
声音克隆。
声音设计。
自然语言指令控制。

RP 最有意思的是克隆。官方 0.6B Base 支持使用约三秒参考音频克隆声音。不用训练完整模型，就能给角色自己的声音。

为什么对 RP 很重要？

旧方式：

Dina → 声音 7
Fiona → 声音 11
Laura → 声音 3

新方式：

Dina → reference_dina.wav
Fiona → reference_fiona.wav
Laura → reference_laura.wav

TTS 尝试保持对应的声音身份。合适的 Qwen3-TTS 版本还能接收这类指令：

Speak quietly, slightly irritated,
trying not to show that she is scared.

1.7B CustomVoice 和 VoiceDesign 支持指令式风格控制；Base 使用不同的克隆模式。做有声书很不错，做 RP 更不错，因为 LLM 已经知道角色情绪。

可以连接成：

LLM:
emotion = angry
intensity = 0.65

↓

TTS:
Speak in a restrained but clearly angry voice.

角色就不只是机械地念文字。

XTTS-v2 呢？

它还在，也还能用。主要优势是周边基础设施已经齐全：API 服务、SillyTavern 集成和许多教程。

SillyTavern 文档介绍了本地 XTTSv2 服务，以及约十秒 WAV 的克隆方式。今天我会先看 Qwen3-TTS。XTTS 更适合：

我需要一个已经熟悉、经过验证的流程。

TTS 对比

星级是我对 RP 的粗略评价，不是统一基准测试。速度和质量取决于硬件、语言与集成。

TTS 对比
TTS	速度	克隆	情绪	俄语	资源	我会用于
Supertonic 3	★★★★★	有限/自定义配置	★★★☆☆	✓	很少	实时 RP
Kokoro	★★★★★	无标准声音克隆	★★★☆☆	官方未列出	很少	简单快速的声音
Qwen3-TTS 0.6B	★★★★☆	★★★★★	★★★★☆	✓	中等	平衡资源需求与能力
Qwen3-TTS 1.7B	★★★☆☆	★★★★★	★★★★★	✓	较高	质量和表现力
XTTS-v2	★★★☆☆	★★★★☆	★★★☆☆	✓	中等	现有集成

关键问题：它们都在争一块 GPU

很多教程忘记提这一点。你有：

LLM
图像模型
TTS

三个都想要显存。

前两个看着彼此，就像两只猫盯着唯一的纸箱。

例如：12 GB 的 RTX 3060

假设 Saiga Nemo Q5 大约占用：

~9 GB

SDXL/FLUX 还想要几 GB。两者已经无法轻松共存。怎么办？

方案一：动态加载和卸载模型

集成能够管理加载时，这很合理。两个独立服务不会自动替彼此卸载模型。

聊天：
LLM 在 GPU 上。

↓

需要图像：
卸载部分或全部 LLM。
加载图像模型。
生成图像。
释放图像模型。

↓

重新加载 LLM。

延迟不理想，但普通消费级 GPU 也能使用不错的模型。

方案二：部分 LLM 留在系统内存

可以这样折中：

70% 的 LLM 层 → GPU。
其余 → CPU/系统内存。
留部分显存给 ComfyUI。

文本会慢一些，但图像不一定每次都要求完整重载。

方案三：两块 GPU

如果还有一块 NVIDIA 显卡，多模态系统会方便一些：

GPU 0:
LLM

GPU 1:
ComfyUI

TTS 可以留在 CPU 或其中一块 GPU。这样能减少文字与图像之间的等待。

方案四：按需生成图片

不用每句话都生成图，那反而可能很烦。更适合这些时刻：

地点改变。
服装改变。
出现其他角色。
发生重要动作。
玩家主动要求图片。

LLM 可以帮助判断时机，明显降低负担。

到底需要多少硬件？

非常粗略。这是配置方向，不保证所有模型都能同时放入显存：

到底需要多少硬件？
GPU	可以尝试的组合
6 GB	7–9B LLM + SD1.5 + 轻量 TTS；轮流加载
8 GB	8–9B LLM + SDXL 或轻量新模型 + 本地 TTS
12 GB	12B LLM + 动态加载的 SDXL/FLUX + 合适 TTS
16 GB	更大 LLM 或更方便的多模态运行
24 GB	更多余量，减少反复管理显存
两块 GPU	更接近实时体验的选择

显存不是全部。我还希望有：

系统内存

16 GB 作为起步最低值。 32 GB 更舒服。大 GGUF 和部分 CPU 推理用 64 GB 更方便。

SSD

AI 模型吃硬盘，仿佛空间不要钱。一个 LLM：5–20 GB。图像模型、文本编码器和 VAE：再加几十 GB。LoRA 收藏越来越多，也要再加几十 GB。几个月后的 ComfyUI 输出：

这 180 GB 图片是哪来的？

专门给模型准备的 500 GB–1 TB 也会很快消失。

能完全不联网吗？

可以，但前提是下载所有需要的模型和文件。KoboldCpp 本地运行；使用本地 checkpoint 的 ComfyUI 也是如此。Supertonic/Kokoro/Qwen3-TTS 都可以本地运行。前端通过以下地址通信：

localhost
127.0.0.1

数据不必离开电脑。

如何验证离线运行？

最简单的测试：

断开互联网。

真的。验证离线能力时，这比读二十份隐私政策更直接。如果之后：

LLM 能回复。
ComfyUI 能生成图片。
TTS 能说话。

主流程就能本地运行。联网时是否有外部请求，需要另查网络活动。也要提前下载程序首次调用时才会获取的文件。

完整本地配置示例

Windows + NVIDIA 的简单组合可能是：

前端:
Multiic / SillyTavern

↓

LLM:
KoboldCpp
localhost:5001

模型:
Saiga Nemo 12B Q4/Q5
或 Qwen3.5-9B

↓

图像:
ComfyUI
localhost:8188

模型:
SDXL / FLUX / Qwen 图像 workflow

↓

声音:
Qwen3-TTS
或 Supertonic/Kokoro

localhost:<TTS 端口>

就这样。外面看是一个 AI 角色，里面三种完全不同的神经网络忙着假装自己是一个人。

说实话，还挺像生活。

一轮互动是什么样？

例如你写：

Dina，你早知道他会来，对吧？

第一步

前端组装提示词：

系统
角色卡
记忆
当前场景
近期对话
用户消息

第二步

KoboldCpp → Saiga Nemo：

Dina 移开视线。

“也许吧。现在还有什么区别？”

第三步

前端提取场景状态：

character: Dina
emotion: defensive
location: kitchen
pose: looking away
camera: medium shot

第四步

构建图像提示词：

Dina standing in a dim kitchen at night,
looking away from the viewer,
defensive expression,
arms slightly crossed,
medium shot,
warm practical lighting

第五步

ComfyUI 生成图片。

第六步

TTS 集成接收：

text:
也许吧。现在还有什么区别？

voice:
Dina

emotion:
restrained, defensive, slightly angry

再把这些字段转换为所选语音模型支持的设置。

第七步

开始播放声音。已经很像一部小型程序生成视觉小说了。

角色记忆

另一个错误：把角色的一生直接塞进上下文。通常效果不好。最好分成：

角色卡

很少改变的内容：

性格
经历
说话方式
关系

场景状态

现在发生的事情：

地点
服装
情绪
在场角色
时间

长期记忆

重要事件：

玩家在 Josephine 的事情上骗了 Dina。
Dina 后来发现了。
信任下降。

图像也需要记忆

这很重要。如果 LLM 知道：

Dina 今天穿红色外套。

但图像提示只来自当前回复：

Dina 看起来生气了。

一分钟后她就可能有：

新的脸。
绿色裙子。
多出三厘米的胸部曲线。
也许还有尾巴。

图像导演应该收到结构化状态，而不只是回复文本。例如：

{
  "character": "Dina",
  "hair": "curly dark hair",
  "clothes": "oversized red jacket",
  "location": "kitchen",
  "emotion": "annoyed"
}

这能帮助保持视觉一致性。

把 TTS 指令与对白分开

不要让 LLM 写：

[悲伤的声音]
我不知道……

然后把方括号直接喂给 TTS。更好的办法是独立元数据：

text: "我不知道。"
emotion: sad
energy: low
speed: 0.9

集成把它转换成兼容的语音控制。合适的 Qwen3-TTS 版本可以用自然语言指令调整风格。

可以全用 KoboldCpp 吗？

有趣的是，已经能做很多事。除了 GGUF 文本，它还支持：

图像生成。
图像编辑。
Whisper。
TTS。
图像理解。
多种 API 兼容接口。

极简系统可以主要围绕一个后端搭建，对新手很方便。但我仍然更喜欢 KoboldCpp 负责 LLM + ComfyUI 负责图像 + 独立 TTS。

为什么？各个组件发展速度不同。明天出现出色的图像模型，我想直接替换一个工作流，而不是等待整个单体后端支持它。

最简单的方案

如果你现在想：

真棒。接下来只要安装五个程序，再考个系统管理员证书。

是啊，能理解。所以才有把组件连接起来的项目。Multiic 可以集中使用：

本地 GGUF。
KoboldCpp。
本地图像生成。
ComfyUI 工作流。
本地 TTS。
角色记忆。
可视化场景。

全部在一个界面里。连接设置见 Multiic 帮助。不用自己组装：

SillyTavern
 + KoboldCpp
 + ComfyUI
 + TTS server
 + 自己的脚本

而是使用已经连接的组合。背后的理念一样：专用模型一起工作。

我今天会安装什么？

较弱电脑 / 6 GB 显存

LLM:
Stheno 8B Q4

图像:
SD1.5

声音:
Kokoro / Supertonic 3

前端:
Multiic 或 SillyTavern

相对轻量的组合。

8 GB 显存

LLM:
Qwen3.5-9B Q4
或 Saiga Nemo Q4 部分在 CPU 运行

图像:
SDXL

声音:
Qwen3-TTS 0.6B / Kokoro

前端:
Multiic / SillyTavern

我认为是实用配置，但要按前面的说明安排内存。

12 GB 显存

我喜欢的平衡点：

LLM:
Saiga Nemo 12B Q5/Q6

图像:
SDXL / 现代 ComfyUI 工作流

声音:
Qwen3-TTS

前端:
Multiic

需要时动态加载或卸载语言模型和图像模型。

16–24 GB

有更多尝试空间：

LLM:
20–30B / MoE 模型

图像:
FLUX / Qwen 图像 / 现代图像编辑工作流

声音:
Qwen3-TTS 1.7B

角色:
多张参考图 / LoRA

上下文:
16–32k+

结果开始更有意思，具体选择仍取决于共同内存占用。

费用是多少？

如果已经有电脑：

每条消息的云端推理费为 0 美元。

下载模型之后，这是本地 AI 的主要优势之一。几个小时 RP 中，云端 LLM 会反复处理：

系统提示词
角色
记忆
历史
当前场景

输入 token 可能增加费用，还有图像生成和 TTS。本地成本大致变成：

电费 + 硬件 + 向 CUDA 解释谁说了算所花的时间。

质量比云端差吗？

有时是。

大型前沿云端模型通常比小型 8B 更擅长：

推理。
复杂指令。
复杂剧情。

云端图像模型也可能不怎么设置就产生优秀结果。本地系统则有别的优势：

自由

可以替换组件。

隐私

使用本地连接和存储时，记录可以留在自己的电脑上。

费用

不用逐条计算推理账单。

延迟

轻量 TTS 可以很快响应。

定制

LoRA、微调、角色声音和自己的工作流。

可复现性

下载好的模型不会因为公司替换云端版本而消失。一个 .gguf 文件不会突然改品牌。

这真不错。

正在离开 Character.AI？这里有一篇九款 Character.AI 替代品对比，从在线服务到完全本地的方案都有。

最后

2026 年确实能在普通游戏电脑上搭建完整本地 AI RP：本地 LLM + 持久角色 + 图像 + 声音克隆，前提是合理选择模型并管理资源。

不用服务器集群，不用云端 API 密钥，也不用为本地推理订阅。可以这样开始：

KoboldCpp
+
8–12B GGUF
+
ComfyUI
+
轻量 TTS

之后继续添加：

角色 LoRA。
参考图。
记忆。
情绪识别。
声音克隆。
图像编辑。
多个角色。
世界状态。
本地视频生成。

最后你会发现，本来想组装聊天机器人，却不小心建了一个小型程序生成游戏引擎。

Multiic 大致就是这样诞生的。

试试 Multiic

从一次对话开始

先选一个现成的角色。模型和语音的配置方法都在帮助页里。

下载游戏 ↗查看帮助 →