用 AI 提示词搭建非对称合作游戏

非对称合作游戏要成立，关键在于玩家掌握不同的信息，而且每个人都能执行另一方做不到的操作。先设定一个共同目标，明确每个角色能看到什么、能改变什么，并让结果对双方都清晰可见。随后只设计一个小型遭遇，并在扩展之前留出检查规则的方法。

下面的提示词以 Lantern Relay（灯火接力） 为例。这是一个供两名本地玩家通过语音沟通的原创洞穴救援教学概念，尚未制作或测试。Keeper（守望者）查看路线图并调整一个远程闸门；Delver（探路者）转动一面实体镜子，并报告自己看到的光束区段。这些只是示例设定，不代表 SEELE 的功能。

先设计依赖关系，再设计角色职业

给角色命名之前，先补完这句话：“只有一名玩家用 [私有信息] 执行 [操作]，另一名玩家再用 [不同的信息] 执行 [另一项操作]，我们才能达成 [共同目标]。”如果移除其中一项操作仍不影响解法，那么这些角色目前只是名字不同，还没有真正互相依赖。

编写非对称合作游戏的 AI 提示词时，先写共同目标，再为每个角色定义信息边界和专属操作。说明何时一名玩家需要另一人的报告，以及什么反馈能确认状态已改变。这样能让“能力不同”落实到实际的解谜循环，而不是变成两段彼此无关的角色介绍。

官方远程游玩指南中的 Keep Talking and Nobody Explodes 展示了一种信息拆分：拆弹者能看到炸弹却看不到手册，专家能查阅手册却看不到炸弹。Lantern Relay 的背景与规则不同；可借鉴的设计问题只是：行动成功之前，哪些信息必须在角色之间传递？

让两个角色都承担不可替代的任务

在 Lantern Relay 中，Keeper 知道固定的洞穴路线和远程闸门选项，却看不到当前亮起的光束区段。Delver 能看到实时光束和一面实体镜子，却看不到路线图，也不能操作闸门。Delver 调整镜子并报出观察到的区段；Keeper 根据报告选择对应的闸门设置。只有这样，光束才能抵达救援门。

这就是角色契约：每一方都有私有信息、基于该信息的操作，以及沟通的理由。写完整提示词之前，先用玩家能指认的名词和动词填好表格。“侦察兵速度很快”还不够；“侦察兵能看到压力板并一直压住它”才说明另一个角色需要依赖什么。

表格也能暴露常见问题：如果 Keeper 的地图已经显示实时光束区段，Delver 的报告就没有提供新信息；如果 Delver 单独转动镜子就能达成目标，Keeper 就只是旁观者。先补上这些规则缺口，再添加对白、更多房间或角色成长。

用三个提示词从规则推进到首个房间

把请求拆开，让每条提示词只负责一件事。先定义角色契约；再要求一个精简的可玩交互，或者在目标工具无法支持必要操作时，要求输出结构化设计交接；最后要求制定评估方案，并明确等待你提供真实观察结果。下面的非对称合作游戏 AI 提示词是模板：替换方括号中的内容，并记住示例尚未经过测试。

提示词 1：定义角色契约

为恰好 [玩家人数] 名玩家设计一个合作游戏概念。
共同目标：[用一句话说明团队必须完成什么。]
沟通方式假设：[玩家如何交换信息。]

请针对每个角色说明：
- 只有该角色能观察到哪些信息；
- 只有该角色能执行哪项操作；
- 执行后哪些状态会改变；
- 角色能向队友报告什么信号。

按顺序说明依赖链：信息、报告、队友决策、操作和共同反馈。设计一个简短遭遇，包含初始状态、合法操作、成功条件、失败条件和重置状态。然后依次移除每个角色，解释遭遇是否仍可解。如果没有某个角色也能得到相同解法，请修改依赖关系。暂时不要加入房间、进度或额外系统。

请返回角色表、一个状态转换表，以及仍需设计决策的规则。不要声称游戏已制作或测试。

第一条请求要的是设计契约，而不是精致世界观。检查每个角色是否都有需要发现的内容、可以执行的操作，以及会影响队友下一步决策的报告。如果回复擅自加入了你还没选定的实现细节，就把它留作待决问题，不要当成既定行为。

提示词 2：限定首个房间的范围

为一个名为 Lantern Relay 的洞穴救援谜题房间写一份设计方案。
这是供两名本地玩家通过语音沟通的虚构教学概念。本提示词尚未运行或测试。

共同目标：让信标抵达救援门。
Keeper 的视角和操作：Keeper 能看到固定路线图和远程闸门选项，但看不到洞穴实时画面或当前光束区段。只有 Keeper 能更改一个远程闸门设置。
Delver 的视角和操作：Delver 能看到实时光束和一面实体镜子，但看不到路线图或远程闸门状态。只有 Delver 能转动镜子，并报告亮起的光束区段。
路线图显示可能的路径；Delver 的报告指出当前光束区段。Keeper 需要这条报告来选择对应闸门。只有镜子和闸门都正确设置，光束才会抵达救援门。

列出初始状态、每个合法操作、无效操作反馈、成功状态、失败或超时状态，以及恢复到初始状态的方法。只保留一面实体镜子和一个远程闸门。不要添加战斗、物品栏、战役进度、在线联网、语音聊天软件或第二个房间。方案中的视角必须继续区分两个角色各自掌握的信息。

如果现有制作工具无法表达两名本地玩家的输入或独立视角，请返回结构化机制与界面交接方案，不要把这个概念说成可玩的作品。返回状态表和简短验收清单。

收到回复后，先读状态表，再判断美术方向。错误的闸门选择是否会产生清楚且可恢复的结果？Delver 是否能在看不到 Keeper 地图的情况下报告光束状态？Keeper 是否能据此做出有意义的下一步选择？如果工具或运行环境表达不了这些限制，设计交接仍然有用，但不能当作合作游戏已经成功制作的证据。

提示词 3：根据你实际记录的观察来评估

请根据我提供的观察，审阅这个单房间合作设计。
不要编造玩家操作、试玩记录或成功结果。

设计契约：[粘贴双方认可的角色表和初始状态。]
观察到的过程：[只粘贴你记录的操作和响应。]
预期结果：[说明按规则应该出现什么结果。]
实际结果：[说明玩家或作品实际显示了什么。]
最早的困惑点：[引用或描述第一个不明确的地方。]

逐步比较观察到的过程和设计契约。指出第一个不一致，解释它涉及哪条规则或信号，并提出一项范围有限的修订。保留房间、角色和所有无关规则。如果观察缺失或含糊，请询问接下来应该记录什么。
不要声称设计通过验证，除非提供的观察支持这一结论。
请返回修改的具体条目、修改后应能观察到的现象，以及下一次测试要检查的一项内容。

输入内容比“评估”这个词更重要。没有实际过程记录，模型只能提出设计检查建议，不能报告玩家的行为。记录观察时，写明预期结果和第一个让人困惑的时刻，修订就能针对最小的不一致，而不是把两个角色全部重写。

检查两个玩家是否都发挥作用

角色表描述的是设计意图；房间仍需可观察的检查方法。从初始状态开始走一遍遭遇，并在每一步询问双方各自知道什么。以下检查是供你审阅自己设计的一种拟议方法，不是 Lantern Relay 的试玩结果。

一次只改一件事。如果报告含糊，先把信号说清楚，再添加提示系统。如果角色空闲，缩短它观察到信息和采取行动之间的步骤。如果目标不明显，先改善光束或闸门反馈，再增加新谜题。范围有限的修订能保留你仍想评估的部分。

根据真实观察进行修订

当你能和玩家一起观察设计时，记下四件事：采取的操作、预期结果、实际结果，以及有人首次犹豫或误解的位置。不要只写“Keeper 很无聊”这类缺少检查点的结论。“Delver 报告光束前，Keeper 就能在两个闸门之间任选其一”指出了具体依赖关系，后续可以据此修改和复测。

修订该规则时固定房间里的其他内容。然后从同一初始状态再试一次，观察这条报告是否改变了队友的决定。这不能证明设计已经平衡或适用于所有玩家；它只会给你一个可追溯的下一步问题。没有真实观察之前，应把问题写成待检查的风险，而不是试玩结论。

将聚焦后的简报带入创作流程

纸面上的角色契约清楚之后，你可以在游戏创作流程中尝试这个聚焦后的构想，并检查它生成的内容。SEELE 当前的 Free AI Game Maker 页面介绍了用自然语言描述游戏、查看可玩的 2D 或 3D 结果，以及在 Workspace 中迭代等一般流程。页面也提醒用户查看所显示的生成费用和账户选项。这些通用流程信息无法证明它支持本地合作、两名玩家同时输入、语音交流或这个虚构房间。

把共同目标、玩家的首个操作、场景状态和反馈带入请求。然后检查结果是否真的呈现了每种控制方式和角色，再把它称作合作游戏原型。如果现有流程无法表达两个玩家的视角或输入，就把输出当作设计起点，并另行规划适合的实现方式。对于谜题本身，AI Puzzle Game Maker 页面适合用来说明单条规则、可见线索、解谜操作和结果；它并不能证明支持多人游戏。

好的首个结果应当小到可以对照契约检查。只有每个角色都贡献了信息或操作、无效选择能说明原因、成功状态确实由双方的行动共同产生时，才保留这个房间。如果检查不通过，就修改一条规则，或先要求设计交接，再扩展到第二个房间。