海岸线、暴雨和涨水动画只能证明视觉方向，不能证明潮汐避难玩法已经成立。真正可验收的关卡，需要让水位同步改变碰撞、导航和路线状态，并稳定处理警报、封路、到达高地、结算与重开。本文固定 1 名玩家、4 个街区、3 级水位、2 条路线和 480 秒时限，用 6 个节点区分“能展示”与“能重复完成”。
海岸线和城市出现，不等于潮汐玩法成立
一张海岸城市概念图里有高楼、街道、车辆和暴雨，看起来很像灾害关卡。但对玩家来说，真正的潮汐避难玩法至少要回答几个问题：水位升高后，哪些道路不能通行？路线变化是否有明确提示？走进错误路线后会发生什么？到达高地是否只结算一次？重新开始时，上一局的封路和倒计时是否已经清理？
先给结论：水面升高必须同步改变可通行区域、角色碰撞、导航与任务状态，否则它只是天气或镜头演示，还不是完整玩法。
这类内容可以分成四档证据：
本文固定 1 名玩家、4 个街区、3 级水位、2 条避难路线、1 个高地避难点和 480 秒时限。当前素材只有城市与极端天气概念画面，因此角色操作、道路封闭、导航更新和任务结算均应标记为“待验证”，不能用宣传画面代替运行证据。
图注：该图可以说明极端天气中的城市街区与避难氛围，但未直接展示海岸线和水位变化，也不能证明角色可操作、车辆拥有 AI、道路会封闭、潮汐模拟存在或关卡能够结算。画面文字不是运行证据。
节点一：水位、街区和每次运行必须唯一
先不要急着制作大范围涨水效果，应先为测试对象建立唯一编号：街区使用 district_01～district_04，水位使用 water_level_01～water_level_03，高地避难点为 shelter_01，每次运行生成新的 run_id，倒计时固定为 480 秒。
这些编号能让玩家看到的现象与日志一一对应。界面至少显示当前水位、剩余时间、可用路线和撤离目标，避免玩家无法判断自己遇到的是水位变化、任务失败，还是碰撞异常。
重开最容易暴露状态问题。第二局开始时，应同时恢复：
- 初始水位；
- 4 个街区的道路状态；
- 2 条路线的入口状态；
- 480 秒倒计时；
- 未结算状态。
上一局产生的警报、封路和结算事件不能继续影响新局。若没有唯一 run_id，就很难判断第二局的问题究竟来自旧监听器未清理，还是初始化不完整。
节点二：警报、水位变化与封路必须分开提交
警报是给玩家的反馈，不等于水位状态已经改变。更稳妥的流程是：先生成唯一的 warning_event_id，播放声音、文字或界面提示；满足时间或任务条件后，再提交一次水位变化，并记录 water_state_before、water_state_after 和 water_event_id；最后根据新水位更新道路状态。
把三者分开，可以避免两类问题：玩家快速跳过警报导致水位重复推进，或者警报播放失败却提前封路。测试时至少覆盖正常等待、快速跳过、暂停后继续和重复触发四种情况。
警报、涨水动画和道路封闭可以连续发生，但必须是可追踪的不同事件。日志应能回答：哪一次警报触发了哪一次水位变化，又关闭了哪一条道路。没有真实运行日志时，文章只能写“设计规则为……”，不能写成“已经验证通过”。
节点三：水位要真正改变碰撞、导航与路线
水位变化不能只抬高一张水面。假设一级水位关闭街区一侧的小巷，二级水位淹没主路，三级水位只保留通往高地的路线，那么每次变化至少要同步更新四项内容：
水面已经漫过道路，玩家仍能直接走过去，说明视觉与碰撞不同步；玩家被挡住，NPC 却继续沿旧路线前进，说明导航没有更新；切换镜头或重新加载区域后道路恢复可走，则说明不同场景对象没有共享同一份水位状态。
固定测试三种情况：
- 玩家站在即将被淹没的边界，观察更新后是被安全阻挡、转移，还是直接卡住；
- NPC 正在通过道路，观察封路后会重新规划、停止还是继续穿过；
- 水位变化时切换相机或重新加载街区，确认画面与逻辑仍引用同一状态。
每级水位都要记录开放街区、关闭街区和可用路线，不能只保留一张涨水后的截图。AI 生成 3D 场景可以加快街区草稿的搭建，但不能自动证明碰撞、导航和任务状态已经连接。
节点四：两条避难路线要有唯一入口和明确失败原因
为了让选择有意义，可以设计两条风险不同的路线：route_01 较短，但在二级水位时关闭；route_02 较长，却能在更高水位下保持通行。两条路线应拥有独立入口、经过街区、风险条件和终点，不能只是同一条道路换两个名称。
玩家进入已封闭路线时，应收到可理解的原因，例如“当前水位达到二级，桥面已关闭”，而不是撞上一堵看不见的墙。如果路线在玩家途中才关闭，还应按设计给出最近安全点、替代路线或明确失败结果。
测试时记录 route_id、进入时间、进入时水位、当前街区和封路原因。尤其要明确路线关闭的边界规则：如果玩家在水位更新前已经进入，是允许继续通过、要求返回，还是立即判定失败？规则必须固定，不能同一条件下每次得到不同结果。
节点五：到达高地与救援结算只能发生一次
玩家进入 shelter_01，不代表一定完成任务。结算前至少要确认：玩家处于有效避难区域、剩余时间大于 0、当前未处于失败状态，并且本局尚未生成最终结果。
可以使用唯一的 result_event_id，让高地触发器、救援动画和倒计时结束事件共用同一把结算锁。重点测试三种重复触发：
- 玩家在高地边缘反复进出；
- 玩家进入高地与倒计时归零发生在同一时刻；
- 结算动画播放期间再次触发高地区域。
正确结果只能有一个：成功或失败。不能重复发放奖励、显示两个结算界面，也不能先判成功再被超时事件覆盖。
当前只有概念图，因此不能写“玩家到达高地后成功撤离”。更准确的表述是：“设计目标为到达高地后生成一次结算事件，实际触发与防重复状态待验证。”
节点六：暂停、失败与重开不能串状态
暂停和重开应放在四个敏感时刻测试：警报播放时、水位推进时、道路封闭时和结算动画时。暂停后，倒计时、水位状态、动画与输入如何处理，都需要明确规则。
例如，暂停期间可以冻结游戏倒计时和水位推进，但界面动画是否继续播放，要按项目统一；恢复后不能重复播放警报，也不能把暂停期间的多次水位事件一次性补算。退出并重新开始时，则不能继承半局状态。
新局至少恢复初始水位、4 个街区、2 条路线、480 秒倒计时和未结算状态，同时清理：
- 上一局的触发器与事件监听器；
- NPC 的旧目标点与路径；
- 旧警报和界面提示；
- 未完成的水位动画或延迟任务；
- 上一局的 result_event_id。
一个常见错误是：第二局画面已经恢复，但后台变量仍认为主路处于封闭状态。开发阶段应记录每个状态的进入时间、触发原因和 run_id，不能只凭画面判断重开成功。
三轮实测与证据表
第一轮：正常撤离。 接收警报，观察三个水位下的道路变化，选择仍开放的路线，到达高地并核对唯一结算结果。
第二轮：错误路线与动态封路。 故意进入已封闭路线，并在即将涨水的道路边界停留，确认系统给出明确原因、替代路线或设计好的失败处理。
第三轮：暂停、退出与重开。 分别在水位变化、封路和结算时暂停或退出，再重新开始，确认新局没有继承旧水位、旧路线和旧结算事件。
建议每轮保存：
build_version、run_id、district_id、water_level、water_event_id、route_id、nav_state、remaining_time、result_event_id、final_result。
结果要写具体，例如“道路碰撞已验证，NPC 导航待验证”“高地结算只触发一次”“重开后 route_01 仍错误关闭”，不要笼统写“效果正常”。世界模型或场景生成工具可以作为城市与街区的视觉草稿入口，但不能替代角色操作、路线选择和多局重开证据。
发布前检查清单
- 是否为每次运行生成唯一 run_id，并在重开时清理上一局状态？
- 三级水位是否分别改变水面、碰撞、导航和开放路线？
- 警报、涨水动画与水位提交是否分开，重复输入会不会推进两次？
- 两条路线是否拥有独立入口、风险条件和可理解的失败原因？
- 高地结算是否检查有效区域、剩余时间与重复触发？
- 暂停、退出、失败与重开是否在每个关键节点恢复正确状态？
- 是否明确区分概念图、动画、单次操作与可重复闭环？
- 未经日志和录屏验证的功能是否标记为“待验证”？
海岸城市生成出来，只能说明场景具备了外观和主题方向。潮汐避难关卡是否成立，要看水位能否改变真实路线，玩家能否理解选择后果，结算是否只发生一次，以及重开后能否再次完成同一闭环。
建议固定按照“对象唯一—警报与水位分离—碰撞和导航同步—路线规则—唯一结算—状态清理”的顺序验收。没有运行日志或连续录屏支持的部分，应明确标记为“待验证”。
你会先验证涨水后道路是否真的不可通行，还是先检查两条避难路线能否在重开后恢复正确状态？
