自由记录 · 03

第一批玩家的一句话，让我重写了消除规则

一句“三个不连续的相同物品不应该消失”，让我们重新检查规则、微信布局、定位失败和跨端一致性。

玩家不关心后台做了多少功能，只关心点下去是不是预期结果

“前两个相同，第三个不同，第四个和前两个一样，也不应该消失。”

这是第一批体验者留下的一句话。程序原本会找到暂存栏里任意三个相同物品并消除；玩家理解的规则却是，只有连续放入的三个相同物品才应该消失。

代码没有报错，页面也没有崩溃，但玩家已经不再相信下一次点击。那一刻我才真正明白：开发者检查功能是否存在，玩家判断的是规则能不能相信。

真实反馈最有价值的地方，是它足够具体

“不好玩”“太难了”很难直接指导修改。一句包含操作顺序、预期结果和实际结果的话，却可以马上复现、修正并验证。

后来的标题栏遮挡、网页与微信版本差异、定位失败没有回退，也都遵循同一条判断：问题不是某个功能缺失，而是玩家眼前的过程不自然。第一批用户没有替我们测试完整个游戏，他们让我们离开了自己的视角。

最初的程序会在暂存栏里寻找任意三个相同物品并消除。开发者看到的是“数量够三张，算法正常”；玩家看到的却是前两张相同、中间夹着另一张、第四张相同，它们不应该越过中间物品自动消失。

页面没有崩溃，接口也没有失败，但规则已经违背了玩家的直觉。真正的问题不是代码能不能运行，而是每一次反馈是否稳定可信。

开发者容易从数据结构理解暂存栏，把它看成一个可以搜索的数组；玩家看到的却是一排从左到右放入的格子。界面表现出了顺序，规则就必须尊重这个顺序。

当程序语义和视觉语义冲突时，不应该要求玩家理解实现。正确做法是修改实现，并把这个具体操作序列写进测试，保证以后不会再次回归。

相同，不等于可以跨过去消除

同一轮体验里，我们还发现微信标题栏遮住内容、网页和小游戏布局差异明显、定位获取失败时只提示不可用。这些问题彼此不同，却都让操作变得不自然。

对应的修改也必须落在用户能看见的地方：为微信胶囊按钮保留安全区、让两端共享同一套视觉参数、定位失败后给出手动选城，而不是只在后台记录异常。

网页有浏览器地址栏，微信小游戏有状态栏、胶囊按钮和不同安全区域。像素完全相同并不一定可用，但内容层级、棋盘比例、按钮位置和反馈方式应该保持一致。

我们保留微信特有标题区，同时让数据卡片、棋盘、暂存栏和道具区共享设计参数。这样后续修改一处规则，两端不会继续长成两套产品。

修复不止发生在代码里

“不好玩”很难直接修改，“我先点了两个苹果，再点牛奶，第四个苹果却把前三个苹果消掉了”就能立刻复现。有效反馈包含三个要素：做了什么、原本期待什么、实际发生了什么。

开发者的责任，是把这句话变成测试，修复后再回到真实设备验证。玩家不是免费的测试人员，但第一批愿意认真描述问题的人，往往能帮产品离开自我感觉。

收集问题只是第一步。更完整的流程是记录场景、稳定复现、修复、真机验证，再告诉反馈者发生了什么。如果问题暂时不改，也应该说明原因和下一次评估条件。

这种回应不需要每次都很长，却能建立最早期的信任：玩家知道自己的描述没有落进无人查看的表格，开发也因此获得比“多做几个功能”更明确的方向。

一句有效反馈，包含三个部分

你玩游戏时，最不能接受的是规则突然变化、按钮看不懂，还是失败后不知道原因？

第一批玩家没有替我们检查完所有功能，却让我们重新理解了什么叫“正确”。

它不是开发工具显示一切正常，而是用户知道下一次点击会发生什么。规则一旦清楚，难度才有意义；过程一旦可信，玩家才愿意再给一次机会。