对于以经济、模拟或相互关联的系统为核心的游戏，先测试一个决策循环，再考虑生成庞大的世界。明确资源、改变资源的行动、玩家看到的反馈，以及让下一次决策更困难或更有趣的条件。AI 可以帮助拟定不同方案，但必须通过原型观察这些规则是否带来有意义的选择。这让团队关注 Hunicke、LeBlanc 和 Zubek 在MDA 框架中描述的游戏机制与玩家体验之间的联系；该框架只是设计背景，并不能证明生成器能够验证结果。
系统复杂的游戏在纸面上可能显得丰富，实际玩起来却像一组互不相连的菜单。一个小场景比完整的进度树或大量精修资产更早暴露这一问题。
关键要点 - 在设计完整经济系统之前，先选择一个循环，比如收集、花费和恢复。 - 在原型中让资源变化和后果可见。 - 在玩家能够解释为什么一个选择优于另一个选择之后再进行扩展。
将循环定义为一系列决策
用通俗语言写出循环：玩家收集资源，花费资源改善一个系统，然后面对新的限制。定居点游戏可以使用食物、劳动力和住所；工厂游戏可以使用投入、吞吐量和存储。第一个场景只需要足够产生取舍的规则。
让模型提出替代规则、边界情况和一个精简场景，并将假设与需求分开列出。然后选择一个能用小地图或少数回合测试的版本。不要让庞大的功能列表掩盖原型应回答的核心问题：玩家是否面临一个后果清晰可见的决策？
构建一个能揭示权衡的场景
有用的初始场景包含起始状态、限制、玩家行动和反馈信号。例如，如果分配工人生产会减少可用于维修的人数，原型应在玩家作出决定之前显示这一代价。测试者应该能够说出发生了什么变化以及原因。
提供的僵尸射击游戏材料不能证明经济或模拟系统的表现。它们只能说明一个更一般的制作检查点：生成任务有一个可供人打开和评估的构建预览。截图记录的是构建完成状态和预览入口，而不是任何资源循环的质量。
使用包含三列的简短测试记录：提供的决策、显示的反馈和仍未解决的问题。如果玩家说不清选择为何重要，应在添加更多系统前修改规则或反馈。
用 AI 改变规则，而不是隐藏依赖关系
AI 可以提出更困难的起始条件、资源短缺或不同的奖励安排。让它一次只改变一个变量，并预测变化可能如何影响玩家选择，然后测试该变体。不要在未检查哪些规则导致哪些结果的情况下接受庞大的依赖网络。
提示词应要求一个精简的交付物，例如：
为一款定居点游戏设计单屏原型。包含三种资源、两个玩家行动、一项可见的取舍、一个胜利条件和一个失败条件。解释每次行动后的变化，将假设单独列出。除非测试取舍所必需，否则不要添加额外系统。
目的在于让一个小系统可供检查。AI 的解释可以指导测试，但运行中的原型才是其实际表现的证据。
保持生成、预览和发布阶段分开
提供的 2026 年 10 月测试记录展示了另一种游戏类型示例的生成工作区、构建预览面板和发布设置对话框。这些画面可以帮助团队讨论工作流程阶段：生成请求、检查构建和审查分享设置。它们并未展示系统类游戏的功能，发布对话框也不能证明项目已发布。
对于自己的游戏，应将验收标准与场景一起记录。只有有人测试决策循环并记录结果之后，构建才准备好进入下一次迭代。更大的地图、更多资源或额外的进度内容应回答后续设计问题，而不是仅仅让项目显得更完整。
一次扩展一个维度
当第一个循环形成清晰可理解的选择后，再谨慎扩展。只有第二种资源会改变决策时才添加它；只有事件能有效地对循环施加压力时才添加事件。等玩家能通过现有反馈理解规则后，再增加视觉修饰。
如果需要范围明确的从需求说明到构建的流程，请参阅如何将游戏需求说明转化为原型。有关人工测试和验收关卡，请阅读游戏原型评审工作流程。独立团队交接指南说明了如何为每次评审指定负责人。
用 AI 制作系统复杂的游戏，一个实用方法是先保持第一个可玩循环精简，观察其后果，再通过测试决定是否增加每个新系统。
实例：在完整模拟之前先测试一个经济循环
设想一款包含食物、劳动力和维修的定居点游戏。玩家一开始只有少量工人，必须决定在下一回合之前收集更多食物还是修理受损的住所。原型只需要一张地图、几个回合和清晰可见的资源变化，不需要技术树、几十座建筑或漫长战役，就能回答第一个问题：这种取舍是否产生玩家能够理解的决策？
记录每次行动之前的状态和行动后可见的后果。例如，如果分配一名工人维修意味着少一人收集食物，界面应在玩家确认前显示这两种影响。测试者应能解释选择某个选项的原因，以及预期接下来发生什么。如果他们无法判断代价是立即产生还是延后产生，就需要在添加更多系统之前修改规则或反馈。
让 AI 提出同一循环的几种变体，而不是整个模拟系统。对每种变体，要求列出起始状态、行动选项、资源变化、失败条件和假设。让设计师选择一个变体并检查数值是否自洽。模型生成的表格可能包含算术或逻辑错误；用于构建前应重新计算状态转换。
将系统规则与内容生成分开
实用的系统规范包含几个清晰的层次：
- 状态：影响决策的资源、条件和数值。
- 行动：玩家可以做什么，以及每项行动的代价。
- 转换：操作或回合后状态如何变化。
- 反馈：游戏如何传达变化及其后果。
- 边界：哪些是不可能的、有上限的、延迟的或可逆的。
将这份规范与生成的名称、描述、事件文本和视觉装饰分开。规则变化时，团队应知道需要修改代码、数据还是内容。将这些全部混在一条提示词中，会让失败测试的原因更难定位。
状态表有助于评审者检查边界情况：资源归零、玩家负担不起任何行动、回合重复以及两个效果同时发生时会怎样。原型不需要包含所有最终规则，但不应隐藏会改变主要决策的条件。
用 AI 探索替代方案，再审慎选择
AI 有助于生成可能的事件、规则变体和边界情况，但不应由它通过生成看似合理的数值来决定游戏平衡。要求提供多个选项及各自产生的取舍，然后在原型中评估。如果模型提出新机制，应将其标记为候选方案，而不是悄悄加入设计。
测试变体时保持场景稳定，一次只改变一项代价、一条规则或一个反馈提示。记录起始状态和玩家选择，以便团队比较各次测试。非正式试玩可以暴露令人困惑的规则或无趣的选择，但不能证明经济系统在完整游戏中仍会保持平衡。
一次沿一个方向扩展
初始循环运行后，选择下一个需要解决的不确定问题。只有第二种资源能带来不同的决策时才添加它；只有新建筑的代价和效果可以理解时才添加它；只有短场景证明玩家能理解后果后才增加更长的场景。每次扩展都应有一个验收问题和相应的观察方式。
变更引入错误时，缩小示例直至问题可复现。保留一个已知正常的构建或场景作为对照。构建记录应说明哪些内容发生变化、哪些内容已重新测试，尤其是当系统影响多种资源或回合转换时。
如何判断策略循环是否有意义？
请玩家描述他们面临的选择、选择原因和预期后果。如果在测试场景中所有选项都感觉可以互换，或某个行动总是明显更优，就应重新审视代价和反馈。答案可能因游戏目标而异，因此应将其视为设计信号，而不是普遍的平衡规则。
应该让 AI 生成资源数值吗？
AI 可以提出候选数值供探索，但应由人检查计算、假设、边界情况和游戏体验。生成的数值是提案，不是经过验证的平衡数据。
