“输入一句话自动生成一个能玩的平台关卡”真正困难的不是把文字变成几块平台而是让脚本中的对象、碰撞、输入、事件和结算在运行时连续对应。先给结论看到森林、平台和角色只能说明视觉内容可能已经生成看到角色能移动也只能说明输入链路的一部分存在。要证明“文字变游戏”成立至少要跑通一轮可重复闭环脚本被解析对象被唯一创建场景具备可用碰撞角色输入改变真实状态事件按条件触发结算写回任务新一局不继承旧状态。本文使用一段 60 秒的平台跳跃脚本作为固定案例1 名角色8 个平台3 枚光球1 个移动机关1 个出口。测试不把概念海报当作运行证据也不默认生成工具已经完成全部功能。没有操作录像、运行日志或可重复构建支持的环节一律标记为“待验证”。先把“生成画面”和“执行脚本”分开讨论一句话生成游戏时至少要区分四档证据证据等级能说明什么不能说明什么概念图视觉方向、题材和流程设想脚本解析、碰撞、输入和结算场景生成演示部分对象或场景可能被创建关卡一定可操作、可完成可操作单关角色能接受输入并执行部分动作事件去重、状态回写和重开可靠可重复闭环同一脚本可解析、运行、结算和重开仍不自动等于可发布成品或全平台稳定很多演示停留在前两档却直接使用“自动生成游戏”描述结果。真正需要核对的是脚本中的platform_05是否对应运行时的第五个平台收集光球后任务计数是否真的改变出口是否只有在收齐三枚光球后才解锁图注胶片画面依次展示 TEXT→WORLD、WORLD→GAME 和像素平台关卡适合表达转换流程。但静态图不能证明文本已被解析、角色可操作、平台存在碰撞、光球可以收集或出口能够结算“NO CODE NEEDED”也不是运行证据。本文统一使用三种结论已实现有可重复操作和运行记录支持未实现测试明确失败或结果不符合脚本条件待验证只有概念图、演示画面或缺少关键日志。节点一脚本字段是否生成唯一对象现象画面中出现了角色、平台和光球但无法确认它们是否真的来自当前脚本。修改一项参数后旧场景仍留在画面里看起来像“新版本也生成成功了”。怎么查先把脚本转成可核对的对象清单对象编号类型数量player_01玩家角色1platform_01—platform_08固定平台8orb_01—orb_03可收集光球3mover_01移动机关1exit_01关卡出口1解析完成后比较三份数据脚本对象清单、场景对象列表和运行时实例列表。它们不能只在数量上相近还要能通过object_id相互追溯。重点检查缺少位置、尺寸或移动周期时系统是否明确报错使用默认值时默认值是否写入日志同一个object_id是否被重复创建修改脚本后旧实例是否被替换或回收解析失败后画面是否仍在显示上一版场景。最危险的不是报错而是静默容错。例如脚本少了一枚光球系统没有说明原因却补了一个默认对象或者解析失败后继续显示旧关卡。这样的画面不能证明当前脚本已经执行。建议记录parse_start、parse_result、scene_version、object_id、object_type和instance_id。节点二对象创建后是否具备可用碰撞与合法位置现象平台已经显示角色却从中穿过移动机关有动画但玩家站上去后直接掉落角色出生时卡在平台内部。原因“对象已经创建”和“对象已经可以参与游戏”不是同一状态。一个平台至少需要视觉网格、碰撞体、位置、朝向和尺寸移动机关还需要视觉与碰撞同步运动。怎么查场景初始化不要只返回一个笼统的“生成完成”。至少拆成三个就绪信号scene_ready需要的实例已经创建collision_ready角色、平台和机关的碰撞可以使用player_spawn_ready出生点合法角色已经稳定放置。只有三项都满足才开放玩家输入。否则角色可能在碰撞尚未完成时提前移动造成初始掉落或位置不一致。最小测试很简单生成关卡后不输入任何操作观察角色能否稳定站在platform_01上随后只输入一次向右移动和一次跳跃记录实际位置与接触状态。按钮变色、脚步声和跳跃动画都不能替代碰撞证据。节点三输入是否改变角色的真实状态现象点击跳跃按钮后播放了动画角色却没有离地暂停界面已经出现移动机关和 60 秒计时仍在继续。怎么查分别测试移动、跳跃和暂停。每次输入至少记录input_id action_id player_state_before player_state_after position_before position_after result reject_reason一次输入只能被消费一次。如果设计只允许单次跳跃角色在空中连续按键时后续输入应被拒绝并说明“当前处于空中”等原因而不是静默叠加速度。暂停也不能只停住角色画面。需要按设计冻结关卡计时、角色物理、移动机关和事件推进。恢复后从原状态继续不能补执行暂停期间积压的动作。如果按钮有反馈、角色动画也播放了但位置、速度和碰撞状态没有变化只能说明界面或动画层存在不能证明可操作关卡已经成立。节点四脚本事件是否按条件触发并防止重复固定案例包含三类事件光球收集、移动机关和出口解锁。每类事件都必须有触发条件、状态变化和去重规则。1. 光球收集角色碰到orb_01后系统应依次完成确认对象、检查未收集状态、更新光球状态、增加数量、刷新界面并写入事件记录。快速连按、重复碰撞回调或角色在触发边缘抖动都不能让一枚光球被计算两次。建议为每次有效收集生成唯一collect_event_id。2. 移动机关mover_01应读取脚本中的起点、终点、周期和方向。测试时必须区分视觉网格是否移动碰撞体是否同步移动角色站在平台上时是否正确继承位移暂停和重开后机关状态是否正确。视觉动画正常、碰撞停在原地仍然属于未实现。3. 出口解锁exit_01只有在orb_count3时才能进入结算。未收齐时触碰出口应显示当前进度并记录拒绝原因例如exit_locked_orb_count_2不能直接播放胜利画面。这一节点至少覆盖重复碰撞、离开后再次进入、暂停恢复和重开后重新触发。动画、音效、粒子和 UI 都只是反馈真正的证据是状态与计数是否按照条件更新。节点五胜负结果是否回写任务而且只结算一次现象屏幕显示“胜利”任务状态却没有结果或者最后一秒触碰出口时胜利与超时同时弹出。规则本案例的胜利条件是收齐三枚光球并触碰出口。失败条件是 60 秒倒计时结束或角色坠落达到预设次数。无论胜利还是失败都要生成结算快照而不是只显示一行文字。快照至少包含字段含义run_id本局唯一编号scene_version当前脚本或场景版本object_state光球、机关和出口的最终状态orb_count已收集光球数量remaining_time结算时剩余时间fall_count本局坠落次数final_result胜利、失败或中止result_reason到达出口、超时或坠落次数耗尽结算只能写入一次。出口碰撞、计时结束和坠落回调可能在相近时间发生系统必须规定优先级并使用终态锁拒绝后续重复结算。测试时分别覆盖收齐三枚光球后触碰出口、少一枚时触碰出口、倒计时归零、坠落达到上限以及暂停恢复后再结算。如果只能看到结果弹窗却无法核对任务快照这一节点仍应标记为待验证。节点六修改脚本与重开能否得到可重复结果现象只修改了platform_05的高度重新生成后却多出一块旧平台新一局开始时光球数量仍然是 2移动机关也停在上一局结束的位置。怎么查先做一次最小修改只改变platform_05的高度。重新生成后检查是否只有目标平台的位置改变其他对象的编号和参数是否保持一致旧平台实例是否已经回收新日志是否绑定新的scene_version。随后执行完整重开确认8 个平台重新处于初始状态编号不重复3 枚光球全部恢复为未收集mover_01回到起点并使用初始周期exit_01恢复锁定60 秒倒计时重新开始旧实例、事件监听器和结算结果不再影响新局。还要明确区分三种操作热更新修改当前场景中的目标字段继续本局保留合法进度并恢复运行新开一局创建新的run_id清除所有局内状态。三者都被叫作“重新生成”时最容易产生状态污染。新版本如果还能收到旧版本的事件回调或者重开后光球计数不是 0应直接标记为未实现。用三轮测试覆盖正常、异常和中断流程只顺利通关一次不能证明转换链稳定。建议至少执行三轮测试。第一轮正常完成按照设计收集三枚光球经过移动机关触碰出口并完成结算。核对六个节点是否连续对应对象唯一创建、碰撞就绪、输入生效、事件更新、结算写入、重开清理。第二轮主动制造错误删除一个必填字段、制造重复object_id或在碰撞尚未就绪时尝试开放输入。观察系统是明确报错、使用有记录的默认值还是静默生成错误结果。异常处理越清楚越能说明系统是否适合实际使用。画面没有崩溃不等于结果正确。第三轮打断运行流程分别在收集光球、机关运动和结算瞬间暂停、修改脚本或重开。重点检查是否重复增加光球数量旧事件监听器是否继续触发结算是否写入两次旧场景对象是否残留新run_id是否仍引用上一局状态。每个检查项都写明预期结果、实际结果、证据位置和结论标签。没有运行证据时不要把“测试方案”写成“已经通过”。3D Agent 或其他游戏生成工具可以帮助搭建角色、平台与基础关卡原型减少初始配置工作但不能替代六个节点的日志验证。生成出一张可操作画面不等于碰撞、事件、结算和重开都已正确实现。最后的转换节点检查卡可以把全文压缩成下面这张检查卡脚本中的每个对象都能追溯到唯一运行时实例平台、角色和移动机关具备可用且同步的碰撞输入能改变真实位置、速度或玩家状态光球、机关和出口按条件触发并能防止重复提交胜负只结算一次并生成可核对的任务快照修改脚本只改变目标字段新局不会继承旧实例和监听器同一套测试在 Unity、Unreal 或目标运行环境的正式构建中能够重复通过。如果只能看到生成画面结论应停留在“概念或场景生成”如果角色能够操作却没有状态回写和重开验证最多可以称为“可操作单关”。只有对象、碰撞、输入、事件、结算和重开在实际游玩与日志中连续对应才可以称为“文字变游戏”的可重复闭环。如果只能先查一处你会先检查平台是否真的有碰撞还是先检查脚本修改后有没有旧对象残留