玩家输入“做一张有三个据点的雪山生存地图”，三秒后地图生成了，看上去很像样，只是出生点恰好落在一块山体内部，角色一出生就在原地抖动。这类错误不会被提示词修正，因为提示词里根本没有“出生点必须站在地面上”这句话。地图生成得越快，就越需要一套不依赖模型自觉的验证流程。
先把地图变成一张图
验证的起点是把地图抽象成图（Map Graph）：节点是区域、据点、出生点、资源点和任务目标，边是可通行的连接，边上带着距离、耗时和危险度。抽象之后，很多“感觉不对”的问题就变成了可以计算的图问题。这一步不需要看画面，只需要生成器在输出地图的同时输出一份结构化的节点与连接清单，验证器对着清单跑，速度足以在发布前完成。
连通性与可达性：不是能看到就能走到
最基础的检查是连通性：从每个出生点出发，能否走到所有任务目标和必需的资源点。这里有一个常见的陷阱，就是“几何上连通、能力上不可达”。一座桥需要绳索才能通过，一扇门需要钥匙，一处高台需要二段跳，如果玩家出生时并不具备这些能力，这条边就不该被算进去。所以边要带条件，验证时按玩家出生时的能力集合逐步“解锁”，看最终能否覆盖全部目标。这个流程就是：从出生点开始遍历，收集钥匙与工具，解锁新的边，再遍历，直到没有新的解锁。
出生点：安全、有事做、不被垄断
出生点的检查可以拆成三条。其一，落点合法：站在可通行地面上，周围没有碰撞体重叠。其二，安全窗口：出生后的最初一段时间里，半径范围内不应存在敌人或危险区域。其三，第一步有方向：从出生点走向第一个资源或目标的耗时，应当落在一个合理区间。举例来说，如果一款生存游戏希望新手在两分钟内完成第一次采集，那么最近的可采集资源就不该在五分钟脚程之外。多人地图还要检查公平：不同出生点到关键资源的距离差，不能悬殊到有人一出生就赢在起跑线。
资源点：看分布，而不是看数量
资源点最容易出现的问题不是太少，而是分布不合理。一张地图的木材总量看似足够，却全部堆在最远的角落；或者稀有资源紧挨着出生点，两分钟就被拿光。较有用的指标有三个：资源与出生点的距离梯度，是否随着推进逐渐变稀有；资源密度的空间方差，是否存在大片无资源的空白区域；关键资源是否可以被单个点位垄断。这些指标都可以直接由图上的节点权重算出。
距离与节奏：把路线换算成时间
任务路线的合理性，最终要落到“玩家会花多长时间”。把每条边的距离除以角色移动速度，再加上每个事件点的预计停留时间，就得到一条路线的节奏曲线：两次“有事发生”之间的间隔，是否出现长得离谱的空档，或者密集得来不及喘息。设想一张设计为二十分钟通关的地图，若关键事件全部集中在最后三分钟，前十七分钟就只是走路，这在曲线上一眼可见，不需要有人真的玩一遍才发现。
目标可完成性：最容易被忽略的一类
目标之间往往有先后依赖，比如“击败守卫得到钥匙，用钥匙开启仓库，在仓库里取得任务物品”。把依赖也画成图，就可以检查两类问题：循环依赖，A 需要 B，B 又需要 A；以及必需物品的来源不存在，比如任务要求交付的物品在地图里根本没有生成点。更隐蔽的是“软锁”：玩家做对了每一步，却因为某个物品被提前消耗掉而再也无法推进。软锁靠静态检查只能发现一部分，剩下的需要靠模拟真正跑一遍。
程序判定之外：交给试玩智能体
静态检查回答“结构上有没有问题”，回答不了“真实操作时会不会卡住”。这一部分由试玩智能体（Playtest Agent）负责：让它从出生点开始，按不同策略去完成任务，记录卡点、耗时和失败原因。试玩的更多细节可以看UGC 社区为什么需要 AI 自动试玩员。图检查与试玩互补，前者便宜、稳定、可解释，适合当发布前的硬门槛；后者昂贵、覆盖更广，适合对通过了硬门槛的地图再做抽样。
报告要让创作者看得懂
验证的产出不该是一个“合格/不合格”的标签，而是一份能定位到具体位置的报告，例如“任务目标 C 无法到达：需要钥匙，但钥匙所在房间被目标 C 所在区域封住”。同时，验证结果最好和地图的可玩性排序联动，未通过硬约束的地图不进入推荐，通过的地图再由可玩性排序去比较谁更值得玩。一个最简单的自检清单是：出生点可站立、目标全可达、资源分布有梯度、事件间隔无长空档、依赖图无循环。五项全过，才值得让别的玩家进来。
