看到主题是“涌现”之后，我先对这个主题进行了调研和思考，主要是与各种AI聊天，包括Claude Code、豆包和Kimi。答案很明确，我需要设计一种游戏机制，让玩家能够对一些基础元素进行自由组合，进而产生不同的变化、策略和玩法。最理想的情况是，通过利用规则，玩家甚至可以探索和组合出设计者都预料不到的结果。我让AI提供了很多例子，它们分属各种游戏类型。游戏的类型选择，我认为这是必须先决定的。因为
Day 3 – Day 4在验证了TapTap可以做三言的璇玑图后，我开始尝试设计关卡。基本设想是这样的：由AI设计字阵，然后玩家在字阵中通过触屏联线的方式，寻找各种诗句，发现的诗句越多，奖励越多。但是，遇到了很多问题：第一，璇玑图里可以读出的诗句，并非我们在课本或唐诗三百首里学到的那些经典诗篇，而是符合诗句规则的“普通诗句”。因此，它不能“预埋”诗句，并非在一个字阵里藏一首现成的唐诗。如果
Day 5 – Day 6做了很多调整。首先，把三言、五言、七言融为一张璇玑图。因为拆分后AI设计的璇玑图很机械，我想直接融合做出更“涌现”的璇玑图。其次，设计了一个【诗篇】模式，也就是利用在字阵中“藏诗”的方式，让玩家可以获取解璇玑图的“提示”等道具。然后，设计了内置播放器。因为无论【诗篇】模式里解锁的经典诗词，还是璇玑图中解出来的新诗句，基于文字的声韵都匹配了“宫商角徵羽”音阶，所以可
Day 7 – Day 10之前的方案已经放弃了，我回到最基础的部分，试图寻找可用的涌现机制。既然文字按照规律可以组合成新的诗句，那如果回到更基础的汉字本身呢？我用Kimi聊了很多。之所以用Kimi，是因为想节省TapTap的额度。至于为什么不是豆包，或者别的AI，也只是因为很随机地顺手就用了，手机上各种AI都有。然后，我让Kimi基于聊天内容为我设计原型，Kimi就做了下面这个推箱子的原
Day 11 – Day 13最后冲刺阶段，关卡完成了入门四关，正式五关。TapTap Maker的通用点数已经耗尽，只剩基础点数，换言之，我只能用Flash模型了。我主要做了几件事：让DeepSeek Flash学习之前【极致】模型做的核心机制分析、第一至第五关，然后设计第六至第八关。玩家游戏进度记忆储存优化全局交互细节优化全局加载速度不出所料，DeepSeek Flash哪怕学习
