NovelToGame

给已经在用的编码 agent 的七个开源技能——Claude Code、Codex 或 Kimi Code——把一本小说变成一款游戏。给它一本书，如果再给一个目标平台或引擎：它会读完全文，写一份来源圣经，里面每一条硬规则、每个人物目标、每个转折与标志性细节都带着它出自哪一回或哪个文件位置；它会比较真实的方向，再用点名的硬否决把不合格的删掉；它设计世界观与画面；它照着简报锁定的运行时构建，而不是退回网页；最后它用一次完整运行、六项检查证明成品能玩。三个模式：quick 用默认值起草简报，只在真正卡住方向的事项上停下；director 停在概念阶段等你挑方向；resume 读进度文件，从最后一个真正完成的阶段接着做。一次运行留下五份设计文档、可运行的构建和一份 QA 记录。这里没有 GPU、没有托管服务、也没有捆绑引擎，另有三款改编以浏览器游戏的形式直接可玩，不用安装。

谁做的拥有并维护这个仓库的组织账号，README 里另列了同组织的五个兄弟项目，组织站上还有一份六个项目的总览。138 次提交全部挂在一个 GitHub 账号 worldwonderer 下，而作者字段在 pitechen 的 54 次与 PiteChen 的 81 次之间来回换，所有提交来自同一个地址；贡献者名单只有一个名字。55 次提交带共同作者尾注，每一条都指名某个 Claude 模型——带百万上下文的 Opus 4.8 二十三条、带百万上下文的 Opus 5 十六条、Fable 5.1 十二条、Opus 5 三条、Fable 5 一条。

1. 01

   六十五天、五个版本，每个提交都出自同一个账号

   仓库建于 2026-07-18，最早的一次提交题为 Make novel-to-game portable across agent CLIs；最新一次在 2026-09-21，是 chore: prepare v0.4.0 release (#65)。中间是 138 次提交——7 月 72 次、8 月 45 次、9 月 21 次——以及五个 release，每一个都是稳定版：v0.1.0 在 2026-07-31，距仓库出现十三天；随后是 2026-08-05 的 v0.2.0、2026-08-23 的 v0.3.0、2026-09-05 的 v0.3.1 与 2026-09-21 的 v0.4.0。五个 tag 与五个 release 严丝合缝，其中没有预发布或草稿；版本标题本身就是路线图——v0.2.0 是证据优先的交付与第三个示例，v0.3.0 是可重放的改编契约，v0.3.1 是更精简的技能包，v0.4.0 是经盲测的技能与每个示例一次运行。周围是 817 个星、115 个 fork、1 个 watcher，65 MB 的仓库被 GitHub 归类为 Markdown，另有 1 个开着的 issue——一个外人提议把这个项目加进一份插件清单。138 次提交全部关联到账号，全部是 worldwonderer，也全部来自同一个邮箱地址；作者字段在 pitechen 与 PiteChen 之间来回换。55 次提交带共同作者尾注，每一条都指名某个 Claude 模型。

2. 02

   「有出处」落到纸上是什么样子

   这个说法可核对，因为产物是一张表。西游记那份工作站里，analysis/SOURCE_BIBLE.md（12,229 字节）是两列的「事实—证据」清单，证据那一列填的是回数：真扇子一扇熄火、两扇生风、三扇下雨，对的是第五十九回；牛魔王变作八戒骗回真扇，对的是第六十一回。README 把这层叫引用层级：每一条硬规则、每个关键人物目标、每个转折与结局、每个标志性锚点，都要带上它出自哪一回或哪个文件位置，没有回目的作品就记文件；改编边界表每一行也都要引证据。事实随后被贴上 immutable、adaptable、open、conflicted 四种标签之一，原著没有定义的东西一律标成设计发明，不许当成事实夹带进来。概念阶段从另一头守同一条规矩：每个候选方向留一行，写明它触发了六条点名硬否决里的哪一条——核心循环无视原著的中心张力；把专有名词换掉就只剩一个通用模板；玩家只是花资源去解锁一段固定剧情。Project Plateau 还多写了一句：它选中的方向在什么条件下应被判为伪——如果位置与时机造不出一张明显更好的照片，或者拍摄记录从不改变之后任何一次路线或防御决定。

3. 03

   六项检查、一次运行，以及写在旁边的局限

   QA 记录是一份形状很死的小文件。qa/verification.json 把六项点名检查——launch、render、input、coreLoop、outcome、restart——绑在唯一一次完整运行上，每一项只会是 NOT_RUN、FAIL 或 PASS：没验证不算通过，旧的 PASS 会被每一次重跑覆盖。同一个文件里还有一个 completeRun 块——一个 id、一个干净上下文标志、跑到的终局状态、重启后落回的状态，以及指向证据文件的指针——外加一串局限，每一条是一个范围加一个原因，而不是一句结论。金瓶梅那份最坦白：六项全过，而第一条局限写着「快速路径在每屏选择第一项可行主动作，只到达一个失稳结局；没有穷举其他选项或结局」。每个示例都只有一条权威命令来做这件事：Project Plateau 是 npm run verify，它用键盘与鼠标事件驱动真实构建，并在同一次运行里写下输入轨迹与判定；西游记是 python3 test/verify.py；金瓶梅是 python3 test/verify_visual.py --write-evidence。2026-09-20 的一条 pull request 把这三条命令旁边各自长出来的第二个检查器删掉了，理由是检查只该待在真正的边界上。

4. 04

   三个入库的改编工作站，三种被锁定的运行时

   这些示例不是截图，而是整份改编工作站入库。每一份都带 PRODUCT_BRIEF.md、analysis/SOURCE_BIBLE.md、concepts/CONCEPT.md、design/GAME_DESIGN.md、design/ART_DIRECTION.md、build/BUILD_BRIEF.md、build/app/ 与 qa/verification.json，原著文本也一起进仓库：西游记 2.1 MB、金瓶梅 2.1 MB 外加一份 9,858 字节的 Python 脚本负责删节、The Lost World 451,824 字节，各自在 source/SOURCE.md 里记下版本、覆盖范围与权利状态。差别在于简报锁定的运行时。两个中文示例都是无依赖的静态应用；金瓶梅的构建占着仓库里最大的几个文件——1.1 MB 的 data.js 与 706 KB 的 engine.js——并在 9,792 字节的 build/art/generated-art.json 里把全部 41 张图记成用 Codex 自带图像工具生成，同时用 SHA-256 把原版封面与五张人物图钉死。3D 那个 Project Plateau 是 Three.js 加 Vite 的 160 个文件的工程，美术是生成而不是手绘：七个 15 到 34 KB 的 .mjs 脚本生成 .glb 的地形与植被库，再由一份 14,804 字节的 asset-ledger.json 记账。文档的重量则朝反方向走——金瓶梅的玩法设计文档 92,095 字节，Project Plateau 只有 10,787 字节。

5. 05

   给技能瘦身，并且盲测这次瘦身

   技能自己也要过一遍它们强加给用户的那套证据纪律。v0.4.0 之前最后四天里的三条 pull request 把包里的死重砍掉——每个技能重复讲两遍的规则、同一个文件里说好几遍的免责话——理由是这个仓库在削自己的校验器时就已经写下过：技能包为每一行付两次钱，一次在仓库里，一次在 agent 的注意力预算里。文字的瘦身是量出来的，不是吵出来的：在一本虚构小说夹具上做盲测 A/B，每臂三次生成，三个模型在五个维度上盲判。第一轮把包从 1,089 行压到 1,060 行，瘦身臂在 game-concept 上赢了 27 次两两比较里的 18 次（6.87 对 7.13），在 game-art-direction 上赢了 16 次（7.00 对 7.27）。第二轮更值得记，因为它在下一次尝试里输了：game-world-design 对照组 6.84，瘦身组 6.38，27 次里只赢 6 次，被记为回归信号并回退；而美术方向上被判为中性的结果（7.07 对 7.24，27 次里赢 14 次）保留了下来。同一个窗口里行数预算从 1,900 砍到 1,300，于是当时约 1,120 行的包就顶在天花板下面；两周前校验器已经用同样的办法从 968 行降到 760 行——把重复的 schema 检查折进共用辅助函数，再把死代码和一整轮全仓扫描删掉。

6. 06

   作者留在记录里的几次反转

   有四处失败和成功一样被老实写下来。美术方向重来过：早期那批暗色、仿古、写实的实验被否掉，换成一种明亮的 2D 语言，铺到全部 41 张运行时图上。封面随后又错了第二次，而且错得值得记——那张明亮的题图从来没丢，是后来加的一层暗色群像标题页在群像被判「改丑了」并撤回之后仍然生效，而 README 卡片与 QA 截图截的正是这个状态；覆盖被移除，并在同一次运行里重录了截图。部署流水线有一个只在线上才现形的毛病：Vercel 项目已经各自定义了自己的根目录，而工作流又先切进了那个目录，于是命令行把路径算了两遍、在上传之前就失败了；修法是改从仓库根目录调用，并加了一条回归测试，禁止按 job 设置工作目录。Project Plateau 的产品简报则记下：第一次实测跑完整条路线只用了 55.2 秒，推翻了原定 5 到 8 分钟的单局，于是产品边界被切成 1 到 3 分钟，而不是往路线里塞等待。README 唯一拒绝给的数字是它自己的成本：进度文件既没有记录墙上时间，也没有记录 token 消耗。