铁路管理游戏设计
围绕客运容量、货运期限和一段共用轨道区间进行平衡的聚焦设计流程，并附纸面核算过的时刻表改动，可用于未来构建测试。
从一条走廊、两项运输任务和一块调度板开始，让列车出发前的所有占用安排清晰可见。这个小循环能给玩家真正的规划选择：让两列车在共用轨道时间窗中错开，或调整一趟发车时间，再检查货物能否按时到达。
范围说明：“潮璃枢纽”是虚构的设计练习。车站、时间、容量和区间规则都是本例设定，并非真实铁路数据或运营建议。本文没有运行游戏生成提示词，也没有可玩构建或实测迭代；下方时刻表只做了纸面核算。
从一项运输目标开始
当首个界面只要求玩家通过受限网络调度少量列车时，铁路管理游戏更容易分析。“潮璃枢纽”的首个切片只有两个相连车站：枢纽站和港口站，两站间共用一段轨道区间。一列客运慢车必须将 4 名乘客从枢纽站送到港口站；一列货运列车则要把 6 个货箱从港口站运回枢纽站，并在规定期限前到达。
玩家需要安排容量足够的列车、选择发车时间窗，并在发车前解决区间冲突。首个切片不需要庞大的地图、城市经济或几十种列车。它需要一条易读的路线、两项不同的运输目标，以及能解释时刻表为何有效或被阻止的反馈。
这就给原型提出了一个清楚的问题：两项运输任务能否在不同时占用同一轨道区间的情况下通过走廊，同时满足各自的运输目标？
绘制车站和运输需求
设计时刻表界面前，先写明需要运输的内容。容量与调度是两项独立检查。四座客运车厢可以满足乘客人数，但仍需要一个空闲的区间时间窗。六格货运车厢可以装下货物，但发车过晚仍会错过期限。
虚构首个切片中的两项运输任务
| 任务 | 路线 | 所需容量 | 时刻表目标 |
|---|---|---|---|
| 客运慢车 | 枢纽站 → 港口站 | 4 名乘客，4 个座位 | 08:02 至 08:04 预订共用轨道区间 |
| 货运列车 | 港口站 → 枢纽站 | 6 个货箱，6 个货位 | 在虚构的 08:10 截止时间前抵达枢纽站 |
在同一决策流程中显示路线方向、列车容量、区间占用和截止时间。玩家不应靠猜测回答四个问题：任务从哪里出发、运载什么、需要多大空间，以及必须何时抵达？
编写首个时刻表切片提示词
第一条请求应描述调度循环，而不只是主题。写明车站、两项运输目标、共用区间、放行规则、冲突反馈和重置行为。请求一个紧凑的可玩界面，让你能在移动任一列车之前检查时刻表。
可复制的首轮构建提示词
创建一款名为“潮璃枢纽”的小型铁路管理游戏，作为虚构设计原型，而非真实铁路模拟器。使用清楚的四分之三俯视图，展示枢纽站和港口站这两个车站，并由一段共用轨道区间连接。玩家管理一列四座客运慢车，运载四名乘客从枢纽站前往港口站；以及一列六货位货运列车，运载六个货箱从港口站返回枢纽站。每趟列车占用共用轨道区间两个虚构的游戏分钟。在易读的调度板上显示两项运输任务、列车容量、各自的发车和到达时间、货物或乘客需求，以及货运列车 08:10 的截止时间。任何时刻只能有一列车占用共用轨道区间。发车前，明确标出相互重叠的预订时间，并阻止放行，直到玩家修改某个发车时间。允许玩家调整货运发车时间，再显示更新后的区间窗口及货物是否按时送达。提供重置功能，恢复原始时刻表。保持单走廊规划循环；不要添加额外车站、真实信号规则、碰撞、路线建造或没有依据的铁路说法。构建后，让我检查状态变化，并说明下一步应测试什么。这条请求让预期输出可供检查：路线图、运输任务数据、区间预订、阻止放行的状态、可编辑发车时间和重置。它不能保证游戏制作工具会正确实现规则。任何版本生成后，都应检查时刻表逻辑，而不能仅凭视觉调度板就认定机制有效。
解决单轨时间窗冲突
纸面示例规定每列车占用共用轨道区间两分钟。客运慢车预订 08:02 至 08:04。货运列车的基准时段为 08:03 至 08:05。两段时间在 08:03 到 08:04 之间重叠，因此按虚构的调度规则，调度板应标出冲突，并阻止放行，直到玩家调整其中一趟列车的发车时间。
发车前应让冲突一目了然。调度板可以在地图上高亮共用区间，并在同一条时间轴上对齐各运输任务的预订条。玩家应能看到两列车的容量都足够，但走廊不能同时供两车使用。这是虚构游戏模型中的调度约束，不是对真实铁路信号系统的描述。
不要把无效时刻表变成模拟撞车。玩家正在发车前做规划；预期反馈应是阻止操作并提供明确的修改方式。这样原型讨论的是网络容量和时刻选择。
纸面检查一次发车改动
只改变货运列车发车时间：从 08:03 移到 08:05。路线、两分钟区间占用、六个货箱、客运时段和 08:10 的送达目标都保持不变。这样货运列车在 08:05 至 08:07 占用共用轨道区间。客运预订于 08:04 结束，货运进入区间前留有一分钟空档。
基准冲突与单变量纸面修订
| 时刻表 | 客运区间 | 货运区间 | 检查结果 |
|---|---|---|---|
| 基准版 | 08:02–08:04 | 08:03–08:05 | 08:03 到 08:04 有重叠；调度放行被阻止 |
| 货运改到 08:05 | 08:02–08:04 | 08:05–08:07 | 客运结束后留出一分钟空档；货运比 08:10 截止时间提前 3 分钟到达 |
这是手工计算的设计情境，不是实测迭代。它展示了玩家应能检查的内容：只更改一项发车时间，消除一次冲突，同时在虚构的两分钟规则下满足同一货运期限。
游戏完成后，应测试同一个状态，而不是依赖图片判断。确认基准时段在发车前被拒绝；把货运改到 08:05 后会形成不重叠的 08:05–08:07 窗口；六个货箱会在 08:10 前抵达。还要确认重置会恢复原来的 08:03 冲突。
检查构建结果并决定下一步
首个版本可用后，逐项检查循环：
- 地图是否恰好显示两个车站和一段共用区间？
- 能否区分客运需求和货运容量？
- 调度板是否在发车前显示两个预订时间窗？
- 出现重叠时，是否阻止放行并说明哪项运输任务需要新时段？
- 调整一次发车时间后，容量、到达时间和截止时间反馈是否一起更新？
- 重置会否恢复原始状态，且不保留修改后的时刻表？
SEELE 公开的 Free AI Game Maker 页面介绍了通用流程：用日常语言描述构想、查看可玩的 2D 或 3D 版本、通过后续提示继续改进，并在生成前检查显示费用。这说明了如何开始并检查原型，但不保证铁路调度、冲突检测或时刻表算术正确。
首个提示词应范围精简，然后寻找所关注规则的可见证据。如果调度板显示了时间，却不会阻止冲突时段的列车放行，就明确要求该状态变化，并用相同场景再测试一次。标签本身不能证明底层规则生效。
常见问题
首个轨道容量规则可以怎样设定？
在这个虚构原型中，同一段共用区间一次只允许一列火车预订。这样在发车前就容易看见并测试时刻冲突。这只是游戏设计假设，不是现实铁路信号指导；实际铁路运营必须遵循合格的运营和安全规则。
游戏应该怎样显示重叠的预订？
让两项运输任务显示在同一条时间轴上，在地图上高亮共用区间，清晰标出时间重叠，并在发车时间调整前禁用放行。玩家应能指出冲突的两个时间窗，并在放行任一列车前看到修改后的区间。
货运列车 08:05 发车能证明现实中的时刻表安全吗？
不能。枢纽站、港口站、区间时长和截止时间都是虚构的。把货运改到 08:05 只消除了本纸面示例中的重叠。这不是现实列车时刻数据、铁路操作规程，也不能证明生成的游戏经过测试。
首个铁路游戏提示词应包含什么？
写明车站、路线、列车容量、乘客或货物需求、共用区间预订规则、期限、冲突反馈、可编辑发车时间和重置状态。要求界面显示这些数值，再检查游戏是否真正执行了所要求的规则。
首个版本构建好后应测试什么？
检查重叠的基准时段是否被阻止、改为 08:05 后货运窗口能否放行、两项运输容量是否足够、截止时间是否始终可见，以及重置是否恢复原始状态。这些是未来构建的检查项，本文的虚构示例尚未运行这些测试。
围绕一条路线、一项容量选择和一条可见的时刻表规则编写简短简报。随后先检查实际状态变化，再增加车站或运输任务。
