AI 游戏主持人设计
当 AI 角色扮演游戏出错时，提示词真的是问题所在吗？
以 GPT-6 Astra 和 Claude Opus 5.5 指南为例，排查 AI RPG 掷骰场景中的上下文、API、执行与保存状态，再决定是否修改提示词。
从实际出错的回合开始
更好的提示词无法修复每一个损坏的 AI 角色扮演回合。设想这个示意场景：你的游侠试图穿越一座腐烂的桥梁，游戏要求进行一次检定，而可见的骰子显示 9 加 3，目标值为 15。总和是 12，但下一段却说游侠安全地穿过了桥梁。在加入更强硬的指示之前，先找出分歧是在回合的哪个环节进入的。这是一个诊断范例，而非 Playworlds 记录在案的失败案例。
写下玩家的动作、要求的检定、记录的掷骰结果、预期后果、叙述后果，以及重新加载后显示的状态。这些观察能让问题可重现。玩家可以将场景与可见的骰子结果和角色卡进行比对，如果它影响下一个选择，就能直接描述矛盾。
将任务措辞与缺失的上下文分开
措辞层面询问模型是否收到明确的工作。请求是否要求它叙述一个已解决的失败，或是决定穿越是否成功？它是否说明要停在哪里、什么留给玩家处理？如果这些边界模糊，就明确说明工作、必要输出以及必须遵守的事实。
上下文层面询问提供了哪些事实。一个从未收到 12 总和、目标值 15 或桥梁状况的叙述者，无法忠实地交代它们。检查实际的请求负载或追踪记录。它应包含地点、相关能力、已结算的检定以及确立的后果。如果输入信息过时，先修正其组装方式，再评判文本。
检查设置与 API 路径
模型升级可能会改变支持的控制项和工具行为，即使提示词保持不变。针对目前文档检查模型、端点、推理设置、输出限制、结构和工具。例如，OpenAI 的 GPT-6 指南指出 Astra 工具调用需要 Responses API。将 Chat Completions 工具工作流程拷贝到该设置中，是集成问题。这并未宣布 Astra 为 Playworlds 的游戏主持人选项。
在编辑指示之前，先寻找错误、截断回应、不完整的工具调用或解析器拒绝。使用相同的模型和端点测试一个最小化的支持请求。如果该请求成功而完整回合失败，就比较负载。如果它也失败，先修正兼容性或设置。
先检查执行过程，再归咎于叙述者
一个角色扮演回合可能涉及掷骰请求、工具结果、叙述和保存。询问这些步骤中哪些实际完成了。掷骰是否产生了结果，该结果是否传递给叙述者？叙述是否在掷骰解决之前到达？一次保存失败是否后来被误认为已完成的回合？流畅的句子是文本已生成的证据；它不是游戏记录了预期状态的证明。
这个区分也适用于无人监督的代理。Anthropic 的 Opus 5.5 指南警告，仅文本的回合结束可能是进度报告，而非多步骤任务完成的证明。通过应用程序事件定义 RPG 回合完成：已结算的检定、被接受的后果，以及持久保存。不要从模型的结尾词推断全部三项。
检查状态并验证结果
假设第一个回应说游侠滑倒并抓住钢索，但重新加载后游侠却在桥的另一侧。这指向状态或保存问题。将被接受的掷骰结果和允许的状态变更与已保存的冒险进行比对，然后从新会话重新打开。如果保存状态正确但文本错误，检查叙述。如果文本正确但保存错误，检查提交路径。
验证应使用可观察的条件。在此范例中，成功意味着显示的 12 在选定的规则下仍是一次失败的检定，叙述描述可游玩的后果而不捏造成功，且重新打开冒险保留相同的地点和结果。如果重试或刷新会改变结果，单一看似良好的回应是不够的。在变更后运行相同的小型场景，并记录预期和观察到的状态。
用于下一次不匹配的六层检查清单
当游戏主持人回应看似错误时，使用此顺序：(1) 任务措辞——叙述者是被要求描述已解决的结果，还是决定一个？(2) 上下文——它是否收到相关的掷骰和场景事实？(3) 设置——模型控制项和限制是否受支持？(4) API——端点和工具协议是否与模型相符？(5) 运行与状态——每个步骤是否完成并保存？(6) 验证——重新加载并重复验证后，结果是否保持一致？在第一个被证实的失败处停止，修复它，并重新测试该回合。
当那些检查之后任务或期望回应仍不清楚时，再修改提示词。Playworlds 将骰子、角色信息和持续的冒险集成到一个浏览器游戏中；这些可见的部分让玩家在叙述感觉不对时有事实可比较。使用我们的指南练习撰写清晰的动作，然后选择一个世界去探索。