故事变游戏

它解决什么问题

把一段叙事改造成游戏，最常见的失败是「逐章复演」：把小说的每一章拆成一段过场动画，玩家只负责按按钮。这个技能要压制的正是这种冲动。它把策划约束前置成一份产品契约，强制回答一组很容易糊弄过去的问题：单局多长、玩家能做什么、世界怎么响应、什么事实不能改。

角色定位是「编排器」，不是「教程」。它不教编码模型写引擎，只负责守住三件事：改编判断是否成立、阶段边界是否清晰、完成证据是否真实存在。

核心能力

输入不挑形式。小说、网文、剧本、分镜脚本、神话传说、历史纪事，甚至任何含角色与冲突的文本，都会被拆成可处理的结构单元。拆解结果写入 SOURCE_BIBLE.md，覆盖六个维度：

• 世界硬规则与可重复动作
• 空间、角色与势力
• 条件事件与标志物
• 不可改事实与设计空白

改编边界表只允许四种类型：immutable、adaptable、open、conflicted，每条都要求标注证据位置。这意味着「原著党会抗议」不是一句感想，而是一条待裁决的记录。

三种运行模式覆盖不同协作节奏：quick 自动跑完概念选择后的整条流程；director 在概念阶段停靠，交给人拍板；resume 读取 _progress.md 和交接门表，从最早未过门的阶段继续，不会重复已完成的工作。

关键步骤与产物

八个阶段，每个阶段产出一份落盘文档，过门后才允许进入下一阶段：

1. 需求 intake：框定十一个产品维度，生成 PRODUCT_BRIEF.md。这一步不可跳过，未确认的假设必须记入 _progress.md。
2. 内容拆解：生成 SOURCE_BIBLE.md，验收标准是成功单元集合等于来源边界集合。
3. 概念设计：产出三个真正不同的紧凑概念卡，附行业对标矩阵与核实状态列。
4. 游戏世界设计：GAME_DESIGN.md 按 16 节 checklist 组织，包含两层循环、数值预算、决策深度示例和关卡节拍。
5. 美术方向：ART_DIRECTION.md 规定形状语法、色盲可读的功能色光、运动与转场规格，以及每个界面的招牌时刻。
6. 构建执行：BUILD_BRIEF.md 只固定目标、不变量和完成证据，框架与渲染技术由实现模型自行决定。
7. 质量验证：QA_REPORT.md 记录环境命令、通过项、证据路径、未测试范围和三项裁决。

设计收敛的判据很具体：一个能证明核心幻想的、可完整游玩的网页游戏验证切片，时长服从 PRODUCT_BRIEF 锁定的单局范围（默认 10–30 分钟）。

适用边界与注意点

不要指望它证明有趣。技能本身明确承认 AI 无法客观验证趣味性、长期平衡或商业价值，所以它把验收标准压在可观测事实上：加载路径存在、核心动作被实际执行过、结果画面有证据、重开可用。

QA_REPORT.md 中只要还存在 blocker 或 major，就不能宣称流程完成。发现问题的回流规则按归属划分：构建问题回 build，设计问题修订后重建回归，产品方向问题则必须显式回到 intake 修改 PRODUCT_BRIEF.md，不能在中间阶段偷偷改需求。

另一个常见误用是本地化。跨语言输入时，技能会分别记录原作文化语境、目标玩家市场和界面语言，并在 SOURCE_BIBLE.md 维护统一术语表，但不会把本地化简化成逐字翻译。如果目标是严肃历史题材或改编敏感作品，immutable 边界的事先确认会显著降低返工成本。