如何设计一款具备清晰规则、记忆与玩家选择的 AI 机器人游戏
要设计一款可玩性强的 AI 机器人游戏，需定义一个简短可循环的核心闭环，将游戏状态保存在对话之外，并为玩家的每个动作赋予明确的结果。让机器人负责解释请求和描述事件；由明确的规则决定消耗、进度和结局。本指南适用于使用 AI 角色或旁白构建文字类游戏的游戏开发者。其目标是创建一个简短、可测试的游戏流程，让玩家能够理解自己的选项，看到决策产生的影响，并走向有效的结局。下文中的送货游戏仅为示范性设计，并非经过测试的产品或真实案例研究。
从无需 AI 即可玩的核心循环开始
用一句话写出这个循环：展示情境 → 接收动作 → 检查规则 → 更新状态 → 展示结果及下一步选项。每一个回合都应完成该循环，或说明无法继续的原因。
在编写个性提示词（prompt）之前，先明确目标、可用动作、动作消耗和结束条件。你应该能够仅用索引卡或电子表格就能运行该游戏。这样可以在生成对话增加变化之前，先检验游戏机制本身。
以一款名为《节日包裹》（*Festival Parcel*）的小游戏为例。玩家有 5 个时间单位来递送包裹。他们可以选择直达路线或花园路线，并且可以在出发前选择收集一根装饰丝带。由一个机器人扮演节日信使，负责解释路线并对递送过程进行点评。
拟定的规则特意保持紧凑：
在做出第一个选择之前展示这些规则。向玩家说明送货动作会结束游戏流程，因此玩家必须事先收集丝带。即便一次递送刚好耗尽最后一个时间单位，也依然算作成功，因为成功检查优先进行。
这个原型拥有完整的开端、决策空间和结局。新增角色或地点只有能为该循环增加有价值的决策时，才有存在的必要。
将明确的状态作为判定结果的唯一依据
将状态视为游戏真实情况的权威记录。对话文本可以解释该记录，但绝不应擅自更改它。
Robert Nystrom 在《游戏编程模式》（*Game Programming Patterns*）中的“状态”一章（https://gameprogrammingpatterns.com/state.html）通过状态、输入和允许的转换来描述有限状态机。书中还展示了松散组合的布尔标志可能会产生无效组合。将这一原则应用到你游戏的生命周期中：使用单一的会话状态（例如 active、delivered 或 missed），并配合明确定义的转换。
对于送货原型，简明扼要的状态规范就足够了：
从所选路线派生出花园明信片，而不是另外存储一个可能与之冲突的值。同样，根据当前状态和规则来动态计算目前可用的动作。
使用固定的处理顺序：解释请求、验证动作及其参数、计算结果、提交状态更改，然后进行叙述。将已提交的结果和允许的后续动作提供给旁白角色。旁白不应擅自进行二次计算。
例如，在收集丝带后，权威结果是：剩余 4 个时间单位，已收集丝带，且两条路线时间均足够。机器人可以描述丝带的颜色（只要该颜色没有任何机制上的影响），但它不能凭空增加未说明的时间消耗，也不能再多给一根丝带。
你可以使用现有的互动叙事工具来构建这些条件的原型。Inkle 的官方互动小说教程（https://www.inklestudios.com/ink/web-tutorial/）讲解了条件分支、追踪已访问内容、变量以及明确的结局。这些功能在加入 AI 旁白之前，为测试预设游戏内容提供了绝佳的基础。
赋予玩家能够理解并能产生影响的选择
在此设计中，判断玩家自主权（agency）的标准在于：玩家能否预见到有意义的差异，并在最终结果中观察到该差异。几个措辞不同但导向完全相同结果的按钮，对检验自主权毫无帮助。
在《节日包裹》中，路线决策满足了不同的玩家偏好：
这些是根据既定规则进行的示范性推算。它们提供了一个简单的决策参考：选择直达递送可以更早完成，收集丝带可以获得装饰，或者走花园路线换取明信片。这里的剩余时间只是结局的一个细节，并不会在暗中增加得分。
如果游戏之后会对某种特定结果给予奖励，请在玩家决策前公开该计分规则。否则，玩家将无法评估你所设想的权衡取舍。
在可见的选项动作之外，同时支持自由文本输入。“我们走风景好的那条路吧”可以映射为花园递送。“把它弄得特别一点”则比较模糊：它可能意味着收集丝带、走花园路线，或者两者兼有。此时应向玩家简短确认，且不消耗时间。
在第一个原型中，每条消息只接受一个游戏动作。如果玩家请求了一连串动作，应展示其具体步骤，并请他们先选择第一个动作。这样可以避免先执行了一部分计划，随后却发现后面的步骤无法进行。
对不支持的请求要给出信息明确的回复。如果玩家要求飞行，请说明目前可用的路线只有直达和花园路线，并附上各自的消耗。自由文本可以拓宽表达空间，而动作系统则保持了一组可预测的能力边界。
明确机器人的记忆范围与认知边界
将记忆划分为三层，每层具有不同的用途。
权威会话状态（Authoritative session state）存储资源、进度、所选路线和结局。它在存档和读档后依然保留，并且只能通过经过验证的动作发生改变。
会话事件日志（Session event log）记录已提交的动作及其后果。一条记录可能会说明“动作 2 收集了丝带，并将时间从 5 减少到 4”。这有助于调试和准确的剧情回顾。为动作分配唯一标识符，避免重复的请求导致同一事件被应用两次。
叙事上下文（Narrative context）包含近期的对话和简短的回顾，用于保持语气和连贯性。它可以被精简，而不会影响到底层的实际游戏状态。
Anthropic 的高效上下文工程指南（https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents）探讨了总结对话历史以及在上下文窗口之外保存持久记录的方法。指南同时警告说，过于激进的总结可能会丢失重要细节。在设计上的启示是：将精准的机制数据保留在结构化存储中，而将摘要用于保持对话连贯性。
划定知识边界以及存储边界。角色应该只接收它被允许知晓的事实。如果后续版本加入了隐藏路线，在该路线的发现条件满足之前，不要将其放入该角色的上下文。游戏引擎可访问的状态，并不需要全部向旁白公开。
对于这个小型游戏，将进度保存在会话存档中，并在开始新一局游戏时清空。避免根据一次路线选择就去推测玩家持久的偏好。如果要添加保存的偏好设置（例如更短的描述），请使其明确且可修改。
用一个具体的序列来测试记忆：收集丝带、存档、重新加载、询问状态，然后选择花园递送。丝带必须保持已收集状态，递送前必须剩余 4 个时间单位，最终时间必须为 0。
针对游戏内失败和系统故障设计不同的响应方案
未达成目标属于游戏体验的一部分。而生成请求失败则是系统实现上的问题。这两者应当产生不同的后果。
对于游戏内失败，指出导致本局结束的规则。在三次等待之后，时间仅剩 2 个单位，此时任何一条递送路线的时间都不够。应立即结束游戏，给出清晰的解释并提供重新开始的选项，而不是让玩家留在一个无法获胜的进行中会话里。
对于系统实现故障，在添加复杂的叙述之前，先定义好恢复行为：
不要静默地用新游戏替换无法读取的存档。这会掩盖进度丢失的问题，并导致下一次响应产生误导。
为每个动作构建一条简明的纯文本结果消息：发生了什么、有什么改变以及接下来有哪些可用操作。机器人的丰富叙述可以作为这条结果的补充。当遇到超时或前后矛盾的回复时，简明消息依然能让玩家继续游戏。
在结局处附上准确的回顾。只有在收集了丝带时才提及丝带，只有走花园路线时才提及明信片。生成的文本应当忠实呈现玩家在整局游戏中所做出的取舍差异。
先测试规则，再测试机器人的理解能力
首先使用固定文本测试游戏。覆盖每个动作、结局和边界条件。然后再引入机器人，并使用多样的措辞重复这些测试。这样可以将规则本身的漏洞与对请求的误解区分开来。
邀请有代表性的玩家在无指导的情况下完成一次递送。让他们在做决定前说明自己的预期，并在做完决定后说明他们认为发生了什么变化。尼尔森诺曼集团（Nielsen Norman Group）的有声思维可用性测试指南（https://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/）建议选择代表性用户和代表性任务，同时让参与者主导发言；指南还提醒道，引导者的提示可能会对用户行为造成干扰。
将观察记录与动作日志结合使用。记录尝试的动作、澄清请求、意外结果，以及叙述与已提交状态之间的任何不一致。将“玩家是否理解选项”与“玩家是否享受在其中做出选择”分开询问。
紧凑的测试检查清单。在扩展游戏世界之前，先修复规则和状态处理中的缺陷。如果玩家理解选项但觉得无趣，调整其中的权衡设计。如果他们喜欢这些选择但无法预测消耗，改进呈现方式。只有当现有选项在不同的措辞表达、存档读取以及故障路径下都能保持易懂时，再对原型进行扩展。