给 AI 一篇文章（比如语文课文《孔乙己》），它自动帮你做出一款可以玩的 RPG 游戏——有场景、有角色、有对话、有选择、有结局。
我们都读过很多故事，但"读"和"经历"是两回事。
你读《孔乙己》的时候，你是一个旁观者，看着这个人的命运在几页纸里走完。但如果你就是孔乙己呢？你站在咸亨酒店的柜台前，短衣帮在笑话你，你要不要辩解？丁举人的书房里有一本你做梦都想要的书，你偷不偷？
这就是"文章变游戏"的魔力——让读者从旁观者变成当事人。
但问题是，做一款 RPG 游戏的工作量非常大：写剧本、画地图、配角色、写事件脚本、调试流程……一篇几千字的课文，手工做成游戏可能需要几周。
如果 AI 能自动完成这个过程呢？
所有生成的游戏都采用故事主人公的第一人称视角。玩家不是旁观者，而是亲身经历故事的人。
- 《孔乙己》→ 你就是孔乙己
- 《皇帝的新装》→ 你就是皇帝(x) （演示的时候尽量选有戏剧效果的文章）
这个设计选择让游戏天然具有代入感，也简化了视角转换的复杂度。
游戏的推进方式：
- AI 先从文章中梳理出完整的时间线和关键剧情触发节点
- 沿着时间线推进游戏，每到一个关键节点，提供选择题让玩家做决策
- 选择题由 AI 生成，通常 2~4 个选项
- 不同选择导向不同的对话、场景细节、甚至短期剧情走向
示例：《孔乙己》的一个决策节点
场景：丁举人的书房
触发条件：玩家进入书房后看到书架
[选项A] 忍住了。这不是你的书。（离开书房）
[选项B] 拿起那本书翻了翻，爱不释手。（触发偷书剧情线）
[选项C] 跟丁举人开口借。（触发求借剧情线，被拒绝后回到选择）
主人公视角 + 自由选择，会导致剧情分支爆炸。解决方案是关键节点收束：
- 每篇文章有若干锚定事件（不可改变的核心剧情），无论之前怎么选，这些事件终将发生
- 玩家的选择影响的是过程体验和细节差异，而非最终走向
- 这既保证了叙事完整性，又给了玩家参与感
《孔乙己》的锚定事件示例：
- 孔乙己在酒馆被嘲笑 → 必定发生（但被嘲笑时的反应可以不同）
- 偷书被发现 → 必定发生（但偷书的动机铺垫会因前期选择而不同）
- 被打断腿 → 必定发生（核心悲剧节点）
- 最后一次出现在酒馆 → 必定发生（结局）
在锚定事件之间，玩家的选择可以自由展开；到了锚定事件，所有分支汇聚。就像河流可以分叉，但最终都流向同一个瀑布。
一篇课文级别的文章（2000~5000 字），建议生成的游戏规模：
| 要素 | 建议范围 | 说明 |
|---|---|---|
| 场景/地图数 | 5~10 个 | 太少没有探索感，太多节奏拖沓 |
| 决策节点 | 3~6 个 | 每个节点 2~4 个选项 |
| 总游玩时长 | 10~20 分钟 | 适合演示，不会太长 |
| NPC 角色数 | 3~8 个 | 含主角和关键配角 |
文章输入（纯文本）
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Generator Agent │
├──────────┬──────────┬──────────┬──────────┬────────────────┤
│ ① Text │ ② Game │ ③ Scene │ ④ Scene │ ⑤ Asset │
│ Analyzer │ Designer │ Planner │ Builder │ Mapper │
│ 文本分析 │ 游戏设计 │ 场景规划 │ 场景构建 │ 素材映射 │
├──────────┴──────────┴──────────┴──────────┴────────────────┤
│ ⑥ RPG Maker Adapter │
│ 将上层输出转换为 RPG Maker MZ 工程文件 │
├─────────────────────────────────────────────────────────────┤
│ ⑦ Auto Tester │
│ Player Agent + Reviewer Agent 自动测试 │
└─────────────────────────────────────────────────────────────┘
│
▼
可运行的 RPG Maker MZ 游戏
输入：一篇文章的纯文本
输出：结构化的叙事骨架
具体工作：
- 角色提取：识别所有出场人物，包括命名角色（孔乙己、丁举人）和群体角色（短衣帮、小伙计）
- 角色画像：每个角色的性格特征、外貌描述、说话风格、与主角的关系
- 时间线梳理：把文章中的事件按时间顺序排列，标注因果关系
- 场景识别：文章中出现了哪些地点（咸亨酒店、丁举人家、街道）
- 情感曲线：故事的情绪走向（开场平淡 → 被嘲讽的尴尬 → 偷书的紧张 → 断腿后的悲凉）
- 主题提炼：核心主题是什么（科举制度对人的异化、底层知识分子的悲剧）
输入：模块 ① 的叙事骨架
输出：游戏设计文档（Game Design Document, GDD）
具体工作：
- 确定锚定事件：哪些剧情节点是不可更改的
- 设计决策节点：在哪些位置给玩家选择权，每个选择有什么选项
- 设计分支与收束：选择之后剧情怎么走，怎么回归主线
- 定义游戏节奏：开场 → 建立日常 → 第一个冲突 → 升级 → 高潮 → 结局
- 定义交互方式：哪些地方是纯对话推进，哪些地方需要玩家走动探索
为什么需要这一步：这是从"文学"到"游戏"的翻译层。文学是线性的，游戏是交互的。直接跳过这一步去分镜，做出来的只是"会动的 PPT"，不是游戏。
输入：GDD
输出：场景清单 + 场景连接图
具体工作：
- 列出所有需要的地图/场景
- 定义场景之间的转换关系（从酒馆出门到街道，从街道走到丁举人家）
- 每个场景的基本描述（大小、氛围、时间段——白天还是晚上）
输出示例（《孔乙己》）：
场景1: 咸亨酒店内部（主场景，反复出现）
├→ 场景2: 酒店门口/街道
│ ├→ 场景3: 丁举人宅邸外
│ │ └→ 场景4: 丁举人书房
│ └→ 场景5: 街巷（被打后爬行）
└→ 场景6: 咸亨酒店（结局版，深秋）
输入：场景清单 + GDD 中该场景的事件
输出：每个场景的完整定义
对每个场景生成：
- 地图布局：瓦片级别的空间安排（哪里是柜台、哪里放桌椅、门在哪个方向）
- NPC 配置：每个 NPC 站在哪里、面朝什么方向、有什么对话
- 事件脚本：玩家走到某个位置 / 跟某人对话 / 做出某个选择后，触发什么剧情
- 对话树：完整的对话文本，包含选择分支
- 环境设定：BGM 选什么、屏幕色调（白天/傍晚/夜晚）、天气效果
输入：所有角色描述 + 场景描述
输出：RPG Maker MZ 内置素材的映射表
策略：优先使用内置素材
RPG Maker MZ 自带大量素材资源：
| 素材类型 | MZ 内置情况 | 映射方式 |
|---|---|---|
| 角色行走图 | 丰富，多种风格 | AI 根据角色描述从内置库中匹配最接近的 |
| 角色立绘 | 有基础集 | 匹配或标注缺失 |
| 瓦片地图块 | 室内/室外/城镇等多套 | AI 根据场景类型选择对应图块集 |
| BGM | 多种情绪风格 | AI 根据场景情绪匹配（紧张/悲伤/日常/欢快） |
| 音效 | 基础音效齐全 | 脚步、开门、对话提示等直接使用 |
当内置素材无法满足时：标记为缺失，后续可用 AI 生图补充，但 MVP 阶段不做。
输入：上面所有模块的结构化输出
输出：可直接用 RPG Maker MZ 打开的完整项目文件
这是最硬核的技术模块。 RPG Maker MZ 的工程文件全部是 JSON 格式，主要包括：
| 文件 | 内容 |
|---|---|
data/MapXXX.json |
地图数据（瓦片、事件、NPC） |
data/CommonEvents.json |
公共事件（跨地图的全局逻辑） |
data/System.json |
系统设定（主角、初始地图、术语） |
data/Actors.json |
角色数据 |
data/MapInfos.json |
地图索引和层级关系 |
Adapter 的工作就是把前面模块输出的"高级描述"翻译成这些 JSON 文件的具体格式。
这里对大模型的要求很高：需要精确理解 RPG Maker MZ 的数据结构和事件指令系统。事件指令是一套编号体系（比如指令码 101 是显示文字，201 是场所移动，102 是显示选项），AI 必须正确使用这些指令码组织出逻辑正确的事件序列。
核心洞察：RPG Maker MZ 导出的游戏本质上是一个 Web 应用（基于 HTML5/JavaScript），可以在浏览器中运行。这意味着我们可以用浏览器自动化来测试！
测试架构：
Generator Agent RPG Maker MZ Project
(生成游戏) ──────────────────────→ (JSON 工程文件)
│
部署为 Web 应用
│
▼
Player Agent ──── 浏览器自动化 ────→ 浏览器中运行的游戏
(AI 测试员) ←─── 截图 + 文本 ───── (键盘控制移动/确认/选择)
│
│ 收集：截图序列 / 对话日志 / 是否卡关 / 地图覆盖率
▼
Reviewer Agent
(AI 评审员) → 生成评分报告
Player Agent 的行为：
- 控制角色在地图上行走（上下左右方向键）
- 与 NPC 对话（确认键）
- 在选择节点做出选择（方向键 + 确认键）
- 尝试覆盖所有可达区域和对话
- 记录走过的路径和看到的所有文字
Reviewer Agent 的评估维度：
| 维度 | 评估方式 | 权重 |
|---|---|---|
| 可运行性 | 游戏是否能正常启动和运行，无报错 | 最高 |
| 可通关性 | Player Agent 是否能走完全部剧情流程 | 高 |
| 叙事还原度 | 游戏中的对话和事件与原文的吻合程度 | 高 |
| 地图合理性 | 地图布局是否符合场景描述，有无不可达区域 | 中 |
| 节奏感 | 游戏过程是否有合理的起伏，不会一直对话或一直走路 | 中 |
| 选择意义感 | 不同选项是否带来可感知的差异 | 中 |
测试的亮点：这个自动测试方案本身就是一个重要的展示——"AI 做了一个游戏，然后另一个 AI 来玩这个游戏并打分"。这种AI 闭环自测的能力非常有说服力。
- RPG Maker MZ：Steam 版即可，用于打开和预览生成的项目，也可以用编辑器手动微调
- 项目文件格式：全部是 JSON，AI 可以直接读写
- 测试部署：RPG Maker MZ 支持导出为 Web（HTML5），部署后用浏览器自动化工具（如 Playwright）进行自动测试
- 开发语言：Agent 框架可用 Python/TypeScript，Adapter 层需要深度了解 MZ 的 JSON schema
用《孔乙己》举例，整个流程大概是这样的：
输入: 鲁迅《孔乙己》全文
│
▼
[Text Analyzer]
角色: 孔乙己(主角)、掌柜、小伙计(叙述者→配角)、短衣帮(群体)、丁举人
时间线: 日常饮酒 → 教小伙计写字 → 偷书 → 被打断腿 → 最后出现
场景: 咸亨酒店、街道、丁举人家
情感线: 滑稽 → 温情 → 紧张 → 悲凉
│
▼
[Game Designer]
锚定事件: 被嘲笑、偷书、断腿、最后的秋天
决策节点:
① 酒馆里被嘲笑时 → 辩解/沉默/反击
② 教小伙计写字时 → 耐心教/敷衍/谈理想
③ 在丁举人书房 → 忍住/偷书/借书
④ 被抓后 → 求饶/辩解/沉默
分支收束: 所有路径在"断腿"节点汇聚
│
▼
[Scene Planner]
地图1: 咸亨酒店（主场景）
地图2: 酒店外街道
地图3: 丁举人宅邸
地图4: 丁举人书房
地图5: 小巷（被打场景）
地图6: 咸亨酒店-深秋版（结局）
│
▼
[Scene Builder]
地图1详细设计:
- 15×12 瓦片，木质地板
- 左侧: 柜台（掌柜站在后面）
- 中间: 三张方桌（短衣帮围坐）
- 右下: 入口
- 事件: 玩家进入后触发掌柜对话 → 短衣帮嘲笑 → 决策节点①
...
│
▼
[Asset Mapper]
孔乙己 → Actor001, 长袍书生行走图
掌柜 → NPC模板-中年男性, 围裙
短衣帮 → NPC模板×3, 短衣造型
酒馆 → 内置图块集"Inside_A/B" + 桌椅家具
BGM → 日常场景用"Town3", 悲伤场景用"Scene2"
│
▼
[RPG Maker Adapter]
生成完整 MZ 工程 → data/*.json + img/ + audio/
│
▼
[Auto Tester]
Player Agent 自动通关 → Reviewer Agent 评分
评分: 可运行 ✓ | 可通关 ✓ | 还原度 85% | 地图合理 ✓ | 总评 B+
│
▼
输出: 可玩的《孔乙己》RPG 游戏 + 测试报告
- 输入输出的反差感极强：一篇文章进去，一个可运行的游戏出来。非技术人员也能立刻理解这有多厉害。
- 覆盖大模型全栈能力：文学理解、创意设计、空间推理、代码生成、自我评估——一个项目全部覆盖。
- 可无限扩展：不只是课文，任何故事、新闻、历史事件都可以变成游戏。想象一下"AI 把今天的热搜做成了一个 RPG"。
- 现场演示效果拉满：当场给一篇文章，等几分钟，打开游戏就能玩。这种演示几乎没有对手。
- 三重 AI 能力展示：Generator（生成游戏的 AI）+ Player（玩游戏的 AI）+ Reviewer（评价游戏的 AI）。一个项目展示了 AI 的创造、执行、评价三种能力。