从后端经验走向体验设计
十年后端经验不是需要暂时放下的包袱。你熟悉的状态、事务、重试和异常处理，正好可以帮助你发现许多容易遗漏的体验问题。
差别是：接口的调用方能读协议，玩家只能通过屏幕、声音、操作结果来理解你的系统。
契约：从字段含义，到玩家预期
接口契约规定输入、输出和错误。体验也存在一种契约：按钮写“继续游戏”，玩家就期待回到刚才那一局，而不是重新生成棋盘。
你需要定义它承诺了什么：继续哪一局？恢复到哪一步？哪些资源已经确认？如果恢复失败，怎么解释？
这个类比的边界是：玩家没有读过你的 OpenAPI 文档。即使实现完全符合内部协议，如果界面建立了另一种预期，体验仍会冲突。
状态机：同一个页面，可以有多种行为
棋盘在游玩、暂停和结算处理中可能长得很像，但允许的操作不同。
把状态机交给 AI，可以减少“弹窗关了但棋盘仍可点击”“后台还在扣时间”之类的遗漏。不过状态机只规定合法变化，无法自动判断这些变化对玩家是否自然。仍然要看反馈与试玩。
幂等：重复事件也有体验后果
你知道重复订单不能重复扣款。同样，重复结算、重复广告回调、连续点击重试，都不应该多发奖励或多开一局。
体验需求可以直接写成：
同一次奖励机会收到多次完成事件时，只发放一次；界面显示已确认结果；重复事件不再弹出第二个成功提示。
生产实现还需要可信状态与持久化边界。浏览器内的一个布尔值只适合教学，不足以承担正式发奖保障。详见广告与信任。
可观测性：从服务异常到玩家路径
后端日志能告诉你请求失败。体验排查还需要知道玩家当时在哪里、期望什么、界面显示什么，以及下一步是否可达。
session_id / 关卡 / 当前状态 / 触发事件
操作是否有效 / 状态是否转移 / 结果是否已展示
失败类别 / 是否出现重试入口 / 是否恢复成功
记录应围绕排查目的，避免采集不必要的个人信息。也别把没有点击误认为没有理解：玩家可能正在思考，也可能因为系统卡住而无法操作。
验收：正确运行，还需要被正确理解
技术验收：“目标计数从 4 变成 6。”
体验验收：“最后一次消除后，玩家能看见目标已完成，并知道主要按钮会进入下一关。”
前者可用自动化检查；后者需要界面检查和玩家观察。两者可以放在同一份验收清单里，不能互相代替。
发给 AI 的任务
请先把这个功能写成状态与事件表，补充每次转移的玩家反馈。
同时检查：重复点击、乱序回调、弱网、后台与冷启动。
每项标明：工程上必须保证的约束，以及需要试玩确认的体验假设。
动手练习
打开状态沙盒，尝试在暂停时发送“达成目标”。然后选一个你的真实功能，写三条“实现正确但玩家仍可能误解”的情况。这会帮助你把工程验收扩展为完整体验验收。
本章映射是面向后端开发者的原创教学类比；UX 对整体交互体验的关注可参见 Norman 与 Nielsen 的定义。