浮岛、桥梁和蓝紫色发光轨迹连成一张网络，很容易让人觉得一局供能解谜已经完成。但“线路会发光”只能证明视觉效果存在，不能证明玩法成立。
真正可玩的系统至少要回答这些问题：节点是谁，线路从哪里连到哪里，连接是否有方向，每条线路损耗多少，环路会不会重复计算能量，过载后如何恢复，稳定供能15秒后是否还要返回控制台结算，以及重开时旧网络是否已经清除。
本文固定一个最小案例：1名玩家、5座浮岛、1个输出120点能量的核心、3个需求分别为20、30、40点的目标设施、6条合法连接和10分钟时限。玩家需要选择端点、预览并确认连线，在每条连接损耗5点的条件下，让3个设施稳定供能15秒，最后返回主控制台完成结算。
图注：浮岛、城堡、桥梁与发光轨迹能够建立供能网络的视觉设想；端点编号、连接方向、能量损耗、过载和结算仍需运行日志验证。
发光连线出现，不等于供能解谜成立
常见的“假完成”有四种：
- 线路连上了，却没有起点、终点和方向；
- 动画变亮了，设施状态却没有真正提交；
- 出现环路后，同一份能量被重复计算；
- 重新打开关卡后，旧连线、端口占用和计时器仍然残留。
因此，提示词不能只写“生成几座浮岛，并用发光线路连接”。它至少要描述以下闭环：
选择端点 → 预览连接 → 校验合法性 → 正式提交 → 计算损耗与负载 → 保持稳定 → 返回控制台 → 结算结果。
这条闭环的重点，是把视觉连线改写成可以计算、可以失败、也可以恢复的状态规则。预览线可以发光，但不能参与供能计算；非法连接可以显示原因，但不能修改网络；稳定计时可以显示进度，但不能代替返回控制台后的最终结算。
由于当前只有概念图，没有运行录像、日志或可复现构建，后文涉及实际功能的结论统一标记为“待验证”。
第一条：节点、设施和10分钟时限必须唯一
问题：设施断电后，无法追溯是哪条线路造成的
先建立固定对象和编号：
- 浮岛：
island_01至island_05； - 能量核心：
core_01； - 目标设施：
facility_01至facility_03； - 主控制台：
console_01； - 合法连接：
link_01至link_06； - 每次运行：唯一的
run_id。
核心输出固定为120点，3个设施的需求分别为20、30、40点，总需求为90点。关卡总时限为600秒。界面至少显示剩余时间、核心输出、当前可用能量、总负载、线路损耗和已稳定供能的设施数量。
唯一编号不是形式工作。没有它，就无法判断某次过载由哪条连接引起，也无法确认重开后看到的是新网络还是旧网络。比如facility_02断电时，日志必须能回溯它依赖的线路、当时的输入和最后一次网络修改。
重开后应恢复为空网络、核心基础输出120点、0个设施供能和600秒剩余时间，同时生成新的run_id。旧连接、端口占用、过载事件和稳定计时不能被继承。
通过标准：每个节点、设施、连接和运行实例都有唯一编号，界面与日志使用同一套身份。
当前状态：待验证。概念图没有提供节点编号、运行实例或计时器证据。
第二条：连线预览与确认提交必须分开
问题：玩家只是拖出预览线，能量却已经被扣除
玩家选择起点和终点后，系统应先进入预览状态。预览只显示连接方向、预计损耗、提交后的负载和是否合法，不应占用端口、扣除能量或写入正式网络。
例如，玩家从island_02拖向facility_01时，界面可以显示预计损耗5点、预计总负载以及“可提交”或具体拒绝原因。只有点击确认后，系统才生成唯一的connection_event_id，把预览线转换为正式连接。
取消预览时，线路要完全消失，不能留下透明残影、端口锁定、碰撞对象或操作历史。还应测试快速连续确认、确认后立即取消、输入设备失焦，以及取消后重新选择。
颜色可以作为反馈，但不能代替状态。最终是否修改网络，应以network_state和事件日志为准。
通过标准：预览线不参与供能、碰撞和保存；一次确认只生成一个连接事件；取消不改变网络。
当前状态：待验证。静态图无法证明预览与提交已经分离。
第三条：只能连接合法端点，并遵守方向和容量
问题：两座浮岛离得很近，系统就自动允许连接
视觉距离近，不代表逻辑上存在合法线路。6条允许使用的边应预先记录from_node、to_node、direction和capacity。玩家只能连接表内存在的端点，不能临时创造第7条边。
方向也必须明确。若link_02规定为island_01 → island_03，从island_03反向连接回island_01应被拒绝，而不是静默翻转。单向中继不能被当成双向电缆使用。
端口还要有占用规则。同一输出端口已经连接时，再次操作应提示“端口已占用”或要求先替换旧连接。重复提交同一条合法边，也不能创建两条视觉相同、数据却不同的线路。
至少测试4类请求：合法连接、不在边表中的连接、反向连接和重复端口连接，并记录reject_reason。失败请求不得修改网络、能量余额和操作历史。
通过标准：所有正式线路都能映射到合法边表，方向、容量和重复连接规则一致。
当前状态：待验证。概念图没有提供合法边表、端口状态或拒绝日志。
第四条：输出、需求和线路损耗必须使用统一公式
问题：线路亮了，但数值面板无法解释供能结果
供能玩法最容易出错的地方，是视觉动画和数值计算各自运行。建议把公式直接写进提示词，并要求每次网络变化都输出计算记录。
本案例使用以下简化口径：
available_output = 120 - active_link_count × 5 total_demand = 20 + 30 + 40 只有正式启用的连接计入 active_link_count 预览连接不计入损耗 total_demand 不得超过 available_output3个设施总需求为90点。若6条合法连接全部启用，线路总损耗为30点，可用输出正好为90点，处于临界平衡状态。因此，任何一条线路被额外计数、同一连接被重复提交，或其他规则继续增加损耗，都会造成供能不足。
这个例子也说明：连线数量多不代表网络更稳定。只有正式承担供能路径职责的连接，才能参与损耗计算；同一连接也不能被重复计数。
每次网络变化至少记录energy_before、active_link_count、link_loss、facility_demand和energy_after。当总需求超过可用输出时，设施进入unpowered或brownout状态，并显示明确原因。不能用“设施亮了”代替稳定供能的数值证据。
通过标准：相同网络状态得到相同结果；预览线不扣能量；线路损耗、设施需求和剩余输出能在日志中互相对应。
当前状态：待验证。概念图没有能量面板、计算日志或设施状态证据。
第五条：环路不能复制能量，过载不能重复结算
问题：A→B→C→A后，能量越算越多
当网络出现A → B → C → A这样的环路时，系统不能让同一份能量沿环路被重复计入。视觉上可以允许玩家尝试连接，但供能计算必须以一次网络版本为单位完成。
每次正式增删线路后，生成新的network_revision。在同一轮计算中，使用visited_node或等效机制记录已访问节点，同一节点不能因为环路被重复计能。
过载也不能每帧重复结算。超过端口容量或核心输出时，应生成唯一的overload_event_id，将问题线路断开或禁用，并保留上一版合法网络作为恢复基础。同一个过载状态持续30帧，不能写入30条相同事件。
至少测试以下3种情况：
A → B → C → A的闭环；- 同一节点拥有多条入边；
- 总需求或端口负载刚好达到容量上限。
失败后应回到最近一版合法网络，而不是清空玩家已经完成的全部连接。
通过标准：环路不会复制能量，过载事件只结算一次，失败后可以恢复到最近的合法网络。
当前状态：待验证。静态发光轨迹无法证明网络计算不存在重复计能。
第六条：稳定15秒与返回控制台结算必须分开
问题：设施亮起后，计时器和控制台各结算一次
只有3个设施同时进入powered，系统才启动15秒稳定计时。稳定期间，只要线路断开、核心过载或关键端点失效，计时就应归零或按预先写明的规则暂停，同时保留可恢复的网络状态。
稳定时间达到15秒后，也不应立即判定胜利。玩家还要返回console_01，由控制台触发最终结算。这样可以把“供能条件满足”和“玩家完成关卡”分成两个状态，避免设施亮起、计时结束和控制台触发器分别提交结果。
超时、核心过载或关键端点无法恢复时，系统要进入失败状态并说明原因。final_result只能写入一次，并绑定当前run_id。玩家离开控制台再返回时，不能重复发放奖励或写入第二条结算记录。
通过标准：3个设施同时供能并稳定15秒后，玩家返回控制台才胜利；中断可以按规则恢复或失败；结算只发生一次。
当前状态：待验证。概念素材没有稳定计时、返回控制台或结算日志证据。
第七条：暂停、撤销和重开必须清除旧网络
问题：重开后，旧端口仍显示被占用
暂停时应冻结关卡倒计时、稳定计时和相关玩法动画。不能出现界面时间停止，后台网络事件却继续提交的情况。
撤销只回退最近一次合法网络修改，并重新计算线路损耗、设施状态和端口占用。非法请求本来就不应写入正式历史，因此也不应占用一次撤销操作。
重开时必须清除旧连接、端口占用、过载事件、稳定计时、弹窗和事件监听器，并生成新的run_id。建议连续重开3次，核对对象实例数、事件数、计时器数量和网络状态是否保持稳定。若每次重开都多注册一个监听器，后续一次点击就可能触发多次提交。
可以使用3D Agent搭建浮岛、设施和发光线路的视觉原型，但能量计算、环路检测、暂停恢复和结算仍需运行日志支持。视觉原型完成，不等于供能玩法已经成立。
通过标准：暂停冻结正确的计时和事件范围；撤销恢复完整网络状态；重开后没有旧网络与重复监听器残留。
当前状态：待验证。当前素材没有暂停、撤销、重开或事件清理证据。
可直接复制的浮岛供能解谜提示词
下面这段提示词的重点，不是要求模型“描述一个好看的浮岛关卡”，而是让它同时输出固定数据、状态规则、失败处理和测试日志：
请生成一局单人浮岛供能解谜，不加入战斗、开放世界、联网多人或无限随机。 固定数据：1名玩家、5座浮岛island_01至island_05、能量核心core_01、3个目标设施facility_01至facility_03、6条合法连接link_01至link_06、主控制台console_01、总时限600秒。core_01基础输出120点能量，3个设施需求分别为20、30、40点，每条正式启用的连接损耗5点。 请逐条实现并输出以下7项规则。每项必须写明数值、触发条件、可见反馈、失败处理和实现状态；实现状态只能填写“已实现”“未实现”或“待验证”。没有运行日志、录屏或可复现构建证据的功能，必须标记为“待验证”。 1. 每局、节点、设施、连接和事件都有唯一编号。重开生成新的run_id，并恢复空网络、120点基础输出、0个设施供能和600秒剩余时间。 2. 选择端点只进入预览。预览显示方向、预计损耗、预计负载和是否合法；确认后才生成唯一connection_event_id并占用端口；取消不改变网络、能量、碰撞和保存数据。 3. 只能使用预定义合法边，并遵守from_node、to_node、direction和端口容量。非法、反向和重复连接不改变状态，并记录reject_reason。 4. available_output = 120 - active_link_count × 5；设施总需求不得超过可用输出。只有正式启用的连接参与损耗，预览线不计损耗。每次计算记录energy_before、active_link_count、link_loss、facility_demand和energy_after。 5. 网络计算不得在环路中重复计算能量。使用visited_node或等效机制，并按network_revision计算。过载只生成一次overload_event_id，断开或禁用问题线路，并保留上一版合法网络用于恢复。 6. 3个设施同时powered后稳定15秒，再由玩家返回console_01结算胜利。超时、核心过载或关键端点不可恢复时失败；final_result只写一次并绑定run_id。 7. 暂停冻结总计时和稳定计时；撤销回退最近一次合法修改并重新计算；重开清除旧连接、端口、事件、计时器、弹窗和监听器，并生成新的run_id。 请同时输出节点表、合法连接表、网络状态机和测试日志。日志至少包含run_id、node_id、connection_event_id、energy_before、active_link_count、link_loss、facility_demand、energy_after、network_revision、overload_event_id、stable_time、return_state和final_result。提示词写得完整，只代表需求描述更清楚，不代表规则已经运行。模型、材质、发光轨迹和空间布局可以较快形成，但端点选择、网络拓扑、状态机、事件去重和重开清理，仍需要人工检查或工程实现。
三轮验收：从正常供能测到状态生命周期
第一轮：正常连接
按照合法边为3个设施供能，让它们同时进入powered，稳定15秒后返回控制台。记录启用线路数量、总损耗、设施总需求、稳定开始与结束时间，以及最终结算事件。
第二轮：非法与边界输入
依次测试非法边、反向连接、端口占用、重复提交、A → B → C → A环路和临界容量。确认失败请求不会修改合法网络，同一失败状态也不会重复生成事件。
第三轮：状态生命周期
分别在预览、稳定计时和过载处理阶段执行暂停、撤销与重开。连续重开3次，检查旧连接、端口、事件、计时器、弹窗和监听器是否已经清除。
建议每项只标记“通过”“未通过”或“待验证”，并绑定构建版本、录像时间点和日志编号。
可直接收藏的检查卡
- 节点、设施、连接、事件和每次运行都有唯一编号；
- 预览线不会提交、扣能量或占用端口；
- 合法边、方向和容量拥有明确的数据表；
- 线路损耗遵守统一公式，且只有正式连接参与计算；
- 环路不会复制能量，过载只结算一次；
- 3个设施稳定15秒后，仍需返回控制台才能结算；
- 暂停、撤销和重开分别恢复正确状态；
- 连续重开后没有旧网络和重复监听器；
- 每个功能结论都有日志、录像或可复现构建证据。
重点不是连线会发光，而是规则能够闭环
浮岛供能解谜的重点不是发光线路有多少，而是每条边都遵守同一套方向、容量、损耗和结算规则。提示词应把节点身份、预览与提交、合法边、能量公式、环路防重复、过载恢复、稳定计时和重开清理写成明确的可验收条目。
AI生成3D场景可以帮助用户快速建立浮岛、城堡、设施和发光轨迹的视觉基础，但不能自动证明能量守恒、状态机和结算链路已经成立。没有运行日志、录像或正式构建回读时，最准确的结论仍然是“待验证”。
你写供能解谜提示词时，更容易漏掉线路损耗、环路防重复，还是稳定完成后仍需返回控制台结算？
