1003 Star 的 NovelToGame：7 个 Agent skill，怎么把一本小说真正做成能通关的游戏
“把小说做成游戏"这件事，过去要么是大厂团队的专利，要么停留在 AI 生成几张概念图、几段设定文档，离"真能玩"差着十万八千里。最近有个开源项目换了个思路：它不做又一个游戏生成器，而是把资深游戏策划的改编方法论，固化成一套可以装进编码 Agent 的 skill 工作流，让 Claude Code、Codex 这类工具按部就班地把小说做成能实机通关的游戏。
它叫 NovelToGame，1003 Star、136 Fork，MIT 协议，主语言是 Markdown——这点很关键，说明它交付的不是可执行软件，而是一整套结构化的 AI 指令与规范。我把仓库克隆下来，通读了 7 个 skill 的 SKILL.md、流程契约和两个完整示例的验收记录，这篇讲清楚它到底凭什么能让 AI 做出"真游戏”，以及它的边界在哪。
一、先定性：它是给 AI 的"改编总监 SOP"，不是游戏引擎
很多人看到"小说转游戏"会以为是上传文本、点按钮、等出片的 SaaS。NovelToGame 完全不是这个形态。
它是 7 个 Agent skill 的合集，安装方式是在你已经在用的编码 Agent 里跑一条命令，比如 Claude Code 下：
npx skills add zenstory-ai/novel-to-game -g -y -a claude-code -s '*'
装完之后，真正干活、写代码、跑测试的是你的 Claude Code/Codex/Kimi Code，这套 skill 扮演的是一个懂游戏策划的总监角色：它规定先做什么、产出什么文档、用什么标准淘汰方案、什么情况下必须停下来等人拍板。模型负责执行，skill 负责方法论和质量门禁。理解这个分工，是看懂整个项目的前提。
七个 skill 里，novel-to-game 是总入口负责编排，其余六个分别对应拆书、概念、世界设计、美术、构建、验收六个阶段。它还提供 director（在三个关键节点停下等你决策）和 resume（读进度文件从断点续跑）两种模式。
二、忠于原著不是口号：事实分级 + 原文出处
AI 改编最容易翻车的地方是"一本正经地胡说八道"——把原著没有的设定当成原著内容。NovelToGame 用一套叫 SOURCE_BIBLE（原著事实库）的机制来约束。
在 novel-game-analyze 阶段，它通读全书，把关键事实分成四类并标注章回或文件位置：
- immutable（不可改）：世界硬规则、关键角色目标、转折结局，改编不能动；
- adaptable（可调适）：可以为玩法让路的弹性设定；
- open（原著留白）：原著没交代的地方，允许原创；
- conflicted（前后矛盾）：原著自身的矛盾，显式标出来，不替作者圆谎。
凡是原著没有、由改编补出来的内容，一律明确标注为"设计发明"，绝不冒充原著设定。这条规则在 AI 创作里相当罕见——大多数工具恨不得让生成内容看起来天经地义，它反而要求把"哪些是书里的、哪些是编的"分得清清楚楚。
三、概念选型用"硬性否决"，从源头拒绝换皮
确定玩法方向的 game-concept 阶段，它不是让 AI 拍脑袋选一个品类，而是横向比较多个可行方案，再用明确的否决标准筛掉不合格的。README 里列的淘汰条件很能说明它的策划审美，比如：核心循环脱离原著核心冲突、遮掉专有名词后只剩通用换皮模板、玩家只是花资源解锁既定剧情——命中任何一条，方案直接出局。
更重要的是职责隔离：概念选型、世界设计（GAME_DESIGN.md）、美术方向（ART_DIRECTION.md）各自落在独立文档、各有负责人，到了构建阶段不允许擅自推翻前面的设计。这解决了 AI 生成常见的"边做边改、最后四不像"问题。它还要求借鉴成熟品类时必须保留该品类的"基础体验外壳"——做《梦幻西游》式回合制 RPG，就不能只交一串光秃秃的战斗关卡，进入世界、目标指引、成长反馈这些玩家熟悉的外围体验都得有交代。
四、先白盒验证风险，再谈量产
game-build 阶段的做法很工程化：在批量生产美术资产之前，先针对"头号设计风险"搭一个白盒原型（whitebox），用最便宜的方式验证这个玩法到底成不成立。
白盒试玩还要求起一个没读过设计文档和源码的独立 Agent 会话，仅凭画面和正常输入来玩，模拟真实玩家，如实记录出错位置、输入、预期与实际差异。试玩暴露的问题按职责退回——产品问题改简报、设计美术问题改对应文档、代码问题修实现后复跑同一条验证路径，而不是在下游打补丁糊过去。流程里还埋了预算复盘机制：一旦任务耗时持续攀升或多个任务抢改同一批文件，立刻停止加内容，优先保住核心循环，把外围场景砍掉。
五、六项实机 QA：跑不通就不算可玩
这是整个工作流最硬的部分。game-qa 不看 AI 自述"我做好了"，而是要求游戏在目标环境里真实启动，通过一次完整运行验证六项指标：launch（启动）、render（渲染）、input（输入）、coreLoop（核心循环）、outcome（至少一个设计结局）、restart（重开）。
自动化状态只有 NOT_RUN、FAIL、PASS 三个值——没真跑过实机，永远是 NOT_RUN，不能算通过。没测到的环境和特性则如实写进 limitations，不把没验证的说成已验证。
六、两个真实示例：确实是能点开玩的游戏
光讲方法论是空的，仓库里放了两个完整示例，都能在浏览器在线试玩，而且各自带全套改编工作区。
**《西游记·三借芭蕉扇》**是一款《梦幻西游》式回合制 RPG，选了原著第五十九至六十一回，191 个文件、约 1.09 万行 JS：四张彩绘场景点地行走、任务追踪自动寻路、五行相克和七十二变战斗。它的 verification.json 里六项检查全是 PASS，同时 limitations 老实记录了"只在桌面 1440×900 的本地 Chromium 跑过，移动端和其他浏览器未验证"。
《金瓶梅·风月总账》（标注 18+）是一款古风恋爱互动影游，274 个文件：五条个人线、共十六个结局，每个关键选择都触发专属剧情过场而非动图充数，配快存、剧情树、CG 鉴赏。这个例子正好展示了它对互动叙事的要求——人物关系靠神态、称呼变化体现，而不是挂一个生硬的好感度数字。
七、祛魅：好用，但别指望它一键出大作
把边界讲清楚才负责任。
第一，它是 skill 不是软件。你必须先有 Claude Code/Codex/Kimi Code 的使用习惯和对应订阅，所有生成消耗的是你自己的 Agent 额度，复杂项目耗时和 token 都不低。第二，产出质量的天花板由底层模型决定，skill 能保证流程严谨、不丢环节，但不能让一个弱模型凭空做出好游戏。第三，它的目标是浏览器小游戏、文字冒险、互动影游这类可玩原型，大型 3A 或商业引擎项目不是它的场景；生成的代码仍然需要你自己 review 和测试。第四，配音默认关闭、运行期实时合成必须在产品简报里显式批准，原著全文和设计文档不会外传，这点对版权敏感的作者比较友好。
许可是宽松的 MIT，商用和二次开发都没什么障碍。
我的判断
NovelToGame 最有价值的地方，不是"AI 能做游戏"这个噱头，而是它把一个资深游戏策划脑子里那些隐性的质量标准——原著考据、方案否决、白盒验证、实机门禁、职责退回——变成了 AI 可以严格执行的显性流程。它不会让你一夜之间做出爆款，却能让一个懂故事但不懂游戏开发的人，借助编码 Agent 把改编这件事做得有章法、可追溯、且最终真的能玩。
如果你已经在用 Claude Code 或 Codex，又正好有想游戏化的故事，值得装上跑一个最小示例感受一下；但请把它定位成一个靠谱的"AI 改编总监"，而不是替代你判断的黑盒。