一份游戏剧本和世界观设定，在硬盘里放了一年。去年写完就没了下文，今年假期把它交给模型，第一次运行出来的版本就已经能玩。
既有设定替代了从零沟通
这次的起点不是一句模糊的想法，而是现成的剧本和设定。让模型读完之前的剧本设定，直接开始写，第一个版本几乎没有明显缺陷，马上能玩，之后只是迭代了几个版本。
剧本和设定在这里起的作用，相当于一份提前写好的需求文档：世界观、玩法规则、目标都已经落在纸面上，模型不需要从一个笼统的愿望里去猜要做什么。从想法到可玩之间，本来有一段“把设定翻译成开发任务”的路——拆功能、定优先级、写清楚每个系统的行为——这次它被大幅省掉了。
后续迭代里的分工也值得记录：人指出哪些地方需要性能调优、哪些地方的设定逻辑要改，模型把这样一句指令展开成完整的实现。需求可以下得很短，因为上下文已经完整地在项目里——剧本、已有代码和此前每一轮修改，都替代了本该写进需求文档的大段说明。
一次体验描述把这个过程比作“一位年薪几百万的游戏公司 CTO，几十分钟干完几个月的活”。这是体验层面的类比，不是可以复核的基准，它传达的只是迭代速度带来的主观感受。
性能问题出现之后
原型跑起来之后，问题才换成性能。最初的实现用 Canvas 绘制，提出提高性能的要求后，实现换成了 PixiJS。调整过程中，执行方会解释自己正在做什么：CPU 耗时花在哪里、和屏幕刷新率是什么关系、算法路径怎么优化、能赢回多少毫秒。
这是一条典型的原型路径：先让东西跑起来，再按帧时间和关键路径逐项优化。“能玩”优先于“流畅”，性能问题要在能玩之后才有资格出现——对一个验证想法的原型来说，次序反过来就什么也验证不了。
原型之后的岔路
接下来的考虑是上架 Steam 和 App Store，就此询问模型，得到的建议是转向 Godot 引擎。同时，一个已经用某种语言写完、又有足够多单元测试把逻辑锁住的项目，替换实现语言被认为是可以轻松完成的事。
需要划清的是，这些都停留在下一步的设想。到这次尝试被记录时，这个游戏是一个能玩的体验版原型，还没有上架任何平台，也没有确定最终用什么技术栈发行。
“代码很好”目前只能算传闻
围绕这次尝试还有一种说法：出来的代码达到国际水准。这里必须区分证据的层级。出来的是功能，代码本身没有读过；所谓水准，一部分来自使用体验——缺陷少、迭代快、讲解专业，一部分来自他人对模型代码能力的评价。产品体验好，推不出代码质量高；要支持“代码优雅”之类的判断，需要真的读代码，需要项目层面的证据。
在证据补上之前，这次尝试能确认的事情是：从一份旧剧本到一个能玩的原型，实现环节已经被压缩到假期里的几次对话。而判断好不好玩、值不值得继续投入、往 Steam 还是别的方向走，这些决定仍然留在人手里。
还要记得原型验证了什么、没验证什么。它能证明的是，一年前写下的设定可以变成一个运行起来没有明显缺陷的东西；它不能证明这个游戏好玩，更不能证明有人愿意为它付费。玩法手感、内容深度、留存，这些要等更多人玩过之后才有答案——原型把“做出来”的门槛降下去了，“做得值得”的门槛还在原地。