AI 游戏主持人设计
AI 游戏主持人该用结构化输出，还是叙事文本？
了解结构化 AI 输出如何协助角色扮演游戏、叙事文字为何仍然重要，以及为什么游戏引擎必须验证掷骰、权限与已保存状态。
让结构化数据与叙事各司其职
AI 游戏主持人需要理解玩家尝试了什么，并就发生之事说出一个引人入胜的故事。这些是相关的工作，但同一段文本不该同时成为规则与已保存状态的唯一来源。结构化输出可让程序更容易检查模型提出的决定。叙事文字则提供玩家氛围、对话与明确的下一步选择。两种格式本身都不能让生成的陈述自动为真。
设想一个示意场景：一名游荡者来到一座密封的金库前，说：“我用一面小镜子先检查符文，再碰锁。”游戏可能识别出一个调查尝试、决定是否需要掷骰、处理任何骰点，并描述游荡者学到了什么。如果模型在结算前就写下“你找到解除标记并打开金库”，叙事便已超越机制。这是一个设计范例，并非 Playworlds 生产环境的实际行为记录。
为建议决定使用小型 schema
结构化提案可包含尝试的动作、目标对象、可能的检定、相关规则参考，以及需要决定的不确定性。就金库而言，它可能将“用镜子检查”识别为尝试动作，并建议进行感知或调查检定。它不该断言骰点、授予物品、移动角色，或将金库标记为已打开。
OpenAI 区分 function calling（将模型连接到应用程序工具）与结构化回应格式（塑造模型返回的内容）。其 Structured Outputs 指南指出，受支持的 strict schema 可强制遵守 schema，但也警告结构化结果仍可能包含错误。就游戏设计而言，这表示像“check_required: false”这样的有效字段仍是需要对照规则与状态审查的陈述。解析器通过只是第一道关卡。
让骰点与状态由游戏控制
引擎应掌握决定结果的事实：角色能力、物品栏、可用动作、骰点、目标值，以及被接受的游戏世界状态变更。在建议的工作流程中，模型可请求检定或说明其可能重要的原因。应用程序验证该请求、运行或记录掷骰，并返回已结算的结果。然后叙事才描述后果。同伴角色可以对已完成的检定作出反应，而不必产生另一次掷骰或改写它。
假设被接受的结果是骰点 11 加 2，低于目标值 16。叙事者可以说标记在镜中模糊、锁仍密封，而游荡者可以查看草图、询问同伴，或尝试另一件工具。它不该悄悄把 13 变成成功。如果规则允许部分结果，引擎应先授权，再让叙事文字将其呈现为事实。
在结果已知后撰写叙事文字
叙事输出的验收标准与结构化提案不同。它应承认尝试的方法、尊重已结算的结果、保留 NPC 的知识，并停在有用的决策点。它可以描述黄铜靠近游荡者手掌时的寒意，但除非状态更新允许，否则不该声称添加了新的伤口、状态或物品。场景可以保持生动，同时引擎仍是机制的权威。
这种分离让修正更容易。如果建议的检定有误，就修改解读或规则对应。如果检定与状态正确但场景乏味，就改善叙事摘要。如果叙事文字与掷骰矛盾，就检查叙事输入与后处理。将输出与同一个已保存场景进行比较。
处理无效与不确定的回应
Schema 需要一条明确的不确定性路径。模型可能无法判断玩家是在提问规则、采取世界内动作，还是一次描述多个动作。让它返回有界的“需要澄清”或“未提出检定”结果，而不是强迫它做出自信的规则选择。验证所参考的角色 ID 与场景对象是否符合当前状态，并拒绝超出允许动作的变更。Schema 无法证明某个对象确实存在于冒险中。
拒绝、不完整回应、不受支持的 schema、缺少工具结果，或过期的场景版本，都不该悄悄变成被接受的叙事事件。记录一个安全原因并在定义的限度内重试；否则要求更明确的动作，或显示可恢复的错误。
实用验收清单
在接受生成的回合之前，请检查：(1) 建议动作是否符合玩家的话？(2) 每个被参考的角色与对象是否存在于当前场景中？(3) 引擎是否决定是否需要掷骰并记录结果？(4) 状态变更是否经过验证且只保存一次？(5) 叙事文字是否符合这些被接受的事实，并将下一步选择留给玩家？(6) 重新加载是否能重现相同的位置、掷骰与后果？这些检查是设计配方，而非对 Playworlds 实际性能的陈述。
玩家需要看到自己的角色尝试了什么、规则如何结算，以及还剩哪些选择。Playworlds 将世界、角色卡、骰点与持续的冒险集中在一处。先尝试一个小动作，然后将回应与可见的游戏状态比较。我们的动作指南有助于让该动作更具体。