最近做的几个浏览器作品，方向很不一样：一个海岛塔防，一个场景解谜，还有一个水墨动作原型。
把它们放在一起看，我越来越愿意把验收拆成两个问题：程序是否按预期运行，以及一个第一次打开页面的人，能否理解并完成一次有意义的行动。
漂亮画面可以让人停下来。接下来玩家按哪个键、为什么失败、失败后要重做多少事，才决定他会不会继续。
塔防里的连线，其实是在解释规则
Last Beacon · 最后的灯塔 的炮塔需要接入灯塔电网，有限的容量决定设施能不能工作。连接、供电容量和炮塔输出，构成了同一套决策。
这类设计里，一个“炮塔不攻击”的结果可能有不同原因：没有连接、容量不足，或者还没遇到合适的目标。如果玩家只能看到炮塔静止，规则即使实现正确，也很难被理解。
因此，电网连线、停机标记和容量信息不是收尾时再加的装饰。它们是玩家理解系统的界面。拆掉中继站后，下游设施的供电会重新计算，玩家需要从反馈里看懂这次操作改变了什么。项目规则说明
这也改变了我的检查方式：不只看敌人是否掉血，还要从第一次进入游戏开始，检查“建造—连接—观察—调整”能不能形成一个清楚的循环。
解谜要保留线索，也要保留思考的位置
Silent Meridian · 静默子午线 包含四个章节、十三道谜题，玩家在“现在”与“回声”两个时间状态之间切换。
谜题多起来之后，记忆负担会成为体验的一部分。某个符号在哪里见过？之前验证过哪一种组合？一个提示是新的信息，还是重复描述已经知道的东西？
项目里的证据手册、个人笔记、分级提示和本地存档，就是在处理这类问题。它们不替玩家推理，而是帮助玩家继续推理。语言切换也应保留进度，让理解文字与保持当前状态成为可以同时做到的事。功能与保存边界
这里有个值得放进说明里的限制：存档保存在当前浏览器，同源之外不会自动共享。换浏览器或域名后没有旧进度，和游戏“没有保存”不是一回事。明确这件事，比一个笼统的“支持存档”更有用。
动作游戏把画面与规则之间的缝隙放大了
Ink Blade · 墨刃 目前是一个可玩的 2.5D 动作原型。人物来自分层原画，场景由 Three.js / WebGL 2 渲染，战斗采用独立的固定步长逻辑。
动作体验会把很小的不一致放大。刀尖看起来经过敌人，伤害却没有发生；角色向右滑动，脚步像在原地踏步；动画还没表达清楚，下一次输入已经被判失败。这些问题不能靠增加粒子和震屏解决。
我的关注点是让玩家能把输入、动作和结果对应起来：什么时候可以接下一刀，精准格挡为什么成立，架势被打空之后出现了什么机会。测试可以检查战斗状态和数值，真实操作则需要检查这些变化是否看得见、跟得上。
项目文档也保留了当前边界：触屏还需要真机调试，尚无手柄、存档或装备成长；代码制作的原画变形，也不等于逐帧手绘动画。当前实现与限制
把原型叫作原型，才能让后续改进有清楚的起点。
我会沿着一整段体验检查
对于这类小作品，我现在更愿意先完成一条短但完整的游玩路径，再增加内容数量：
- 从初始页面进入，不依赖作者在旁边讲解。
- 用正常输入完成一次核心操作，确认反馈能解释结果。
- 故意失败一次，检查重试位置和恢复成本。
- 暂停、切换窗口，再回来继续。
- 检查语言、提示和保存等辅助能力是否保留当前进度。
同一套检查放到三个项目里，重点也会不同。塔防关注依赖关系是否看得懂，解谜关注线索是否能接着用，动作游戏关注操作节奏与判定是否一致。
AI 辅助开发可以参与代码、素材和方案探索，但“第一轮代码生成结束”很难成为作品完成的标准。我更愿意把它放在可操作的流程里：搭起一段体验，亲手走完，指出具体的不顺，再回到规则和实现。
这些作品仍有继续打磨的空间。当前对我最有用的进步，是能更准确地说出下一轮该改哪里，而不只是觉得画面还可以更丰富。