为合作生存制作游戏编写明确分工的 AI 提示词

增加系统前先定义生存规则

合作生存制作游戏的提示词不能只有场景设定和配方清单。还要说明每位玩家能做什么、物资如何进入共享库存、哪些行动会消耗物资、危险何时推进，以及本轮如何结束。然后用一个短场景检查两种角色是否都对同一结果有贡献。

下文的“芦苇守望营地”是原创的纸面教学示例。双人同屏设置、回合顺序、资源数量和温暖值都是为说明提示词工作流而拟定的规则。没有运行提示词，也未提供可玩构建或游戏过程；没有测试真实的多人行为。把这些数值当作示意输入，而非平衡建议。

先用一句话写下共同目标：收集两种材料，把两个角色的工作合成一道挡风墙，并在共享温暖值降到零之前完成。这句话给提示词一个读者能识别的结果，也说明了后续规则各自存在的理由。

这份约定让“合作”可以被观察：每名玩家负责一种必需资源和建造环节。它也避免把生存压力做成没有后果的装饰计时器。

明确资源归属和共享库存

在芦苇守望营地，木工携带短柄斧，每次可以恰好采集 2 份木材，或立起挡风墙的两根木桩。芦苇工携带手镰，每次可以恰好采集 2 份芦苇，或编织并固定屏障。任何一名玩家都不能执行另一角色的采集或建造行动。没有私人库存、额外材料或隐藏移动成本。

两种材料都放进起始为空的同一个共享背包。每次合法采集行动加入完整数量；每项建造行动消耗其对应材料并设置一个持续保留的施工标记。两个建造行动可以按任意顺序，或分布在不同回合完成。只有两个标记都设置后，挡风墙才算搭好。如果玩家尝试角色锁定的行动，或缺少材料时仍尝试建造，该行动栏位照常使用，但状态不变。

在提示词中把采集和制作分开写。如果一个行动既能采集又能建造，回合推演就无法看出另一位玩家的贡献是否重要。“一次只能做一项”的规则让取舍清楚可见：现在采集、材料足够时建造，或等待。

按固定顺序结算寒潮

在举例之前先写明时序：玩家 A 行动，玩家 B 行动，然后检查寒潮。如果挡风墙在本回合内完成，就能抵挡本回合的温暖损失；否则温暖减少 1。降到 0 时，本轮在下个回合开始前结束。挡风墙完成后不会恢复已经损失的温暖。

下面的基准流程从第 1 回合开始：温暖为 3，共享背包为空，建造没有进度。所有数值都来自拟定规则；这是手工计算，并非实际观察到的游玩结果。

延迟采集的情形能展示同一约定如何处理恢复。如果芦苇工在第 1 回合等待，回合结束后团队损失一点温暖。第 2 回合木工可以立桩，芦苇工则采集芦苇；温暖再次下降到 1。第 3 回合芦苇工可以编织，木工等待。挡风墙在检查前完成，因此示例以温暖值 1 获胜，而且没有恢复温暖。如果芦苇工再次选择等待，第 3 回合结束时温暖会降到 0，团队失败。

这里的决策来自行动顺序，而不是臆造的奖励：先收集两种材料是较安全的基准；如果一名玩家延迟，则要接受第二次寒潮检查。若希望游戏有更长的恢复时间，应明确修改初始温暖值或结算规则，再重新计算每一行结果。

编写可检查的场景提示词

先请求一个小场景，不要一开始就增加天气类型、工具、食物、战斗或生产链。写清输入、行动限制、状态更新、失败处理和预期结果。下面可直接粘贴的提示词只描述芦苇守望的纸面设计；它没有在 SEELE 或其他游戏制作工具中运行。

设计一个小型、双人同屏、回合制的合作生存制作场景，名为“芦苇守望营地”。
这是设计规格，不是宣称存在已完成构建。每回合玩家 A 先行动，玩家 B 后行动，
随后结算一次寒潮检查。

重置时的共享状态：温暖为 3；木材为 0；芦苇为 0；尚未立桩；尚未编屏；第 1 回合；
玩家 A 先行动。挡风墙完成且温暖至少为 1 时团队获胜。如果挡风墙未完成前温暖在
回合结束检查时降至 0，团队失败。重开时恢复全部初始状态。

玩家 A 是木工。每回合恰好选择一项行动：采集木材，使共享背包增加恰好 2 份木材；
或立起木桩，恰好消耗 2 份木材并设置“木桩就绪”标记。A 不能采集芦苇或编织屏障。

玩家 B 是芦苇工。每回合恰好选择一项行动：采集芦苇，使共享背包增加恰好 2 份芦苇；
或编织屏障，恰好消耗 2 份芦苇并设置“屏障固定”标记。B 不能采集木材或立木桩。
两项建造行动可以按任意顺序，或在不同回合发生。两个标记都设置后立即完成挡风墙。

任一角色都可以等待。不可用或角色锁定的行动仍会占用该玩家的行动栏位，但不改变资源或建造状态。
两人行动后，如果挡风墙仍未完成，温暖恰好减少 1。如果本回合内挡风墙已完成，则跳过本回合
寒潮损失，不恢复之前失去的温暖。

显示当前回合、活动角色、每人所选行动、共享木材和芦苇数量、两个建造标记、温暖、回合结束检查，
以及胜负结果。场景保持紧凑：一个木料采集区、一个芦苇滩和一处中央营地。不要增加私人库存、
额外配方、生命值、食物、战斗、耐久度、制作队列、生产建筑、移动成本、在线联网或其他生存系统。

返回角色/行动表，以及基准流程和一次芦苇延迟情形的逐回合状态轨迹，并列出重置、无效行动、
寒潮时序和两种终局状态的简短检查清单。若规则有歧义或无法呈现，请指出，不要悄悄更改。

检查输出是否保留了操作顺序。尤其是第二位玩家的行动必须能在本回合寒潮检查之前完成避难所；否则书面约定中的第 2 回合胜利就无法发生。如果输出改了时序，应先修正提示词或规则表，再扩展场景。

用固定案例检查双方角色

先验证每项书面行动是否产生预期状态，再判断场景是否足够紧张。每个案例都从同一重置状态开始，一次只改变一个行动；只有构建完成后，才能将预期结果和实际结果比较。下表是拟定的验收计划，不是测试报告。

数值不符时，先定位违反的是哪条书面规则：资源数量、行动归属、行动顺序、建造完成条件，还是温暖时序。一次只改一条规则，并重新计算基准和延迟案例。通过纸面检查只证明规则内部一致；它不能说明操作是否清楚、实现是否遵循提示词，或挑战是否有趣。

用多人游戏制作工具规划场景

SEELE 官方多人游戏页面介绍了围绕玩家人数和模式、有用的角色分工、共同目标、交互规则及一个短场景来规划的工作流。页面也指出，在线游玩仍依赖实现、网络、同步、托管和测试。该页面不能证明这里这套精确的同屏双控制器场景已经实现或验证。

带上规则约定，而不是宣称游戏已经完成：写清玩家设置、各角色可做什么、如何使用共享背包、何时结算寒潮，以及如何定义胜利。把任何结果与状态表比较。产品页面介绍的是规划方式，因此精确规则仍应以提示词和手工检查为准。

准备构思多人游戏时，可以打开Multiplayer game maker，并根据计划中的场景调整提示词。确认当前工作流并自行检查任何输出；本文不声称示例已生成或测试。

确定下一项检查，再逐步扩展

第一轮规则应小到可以手工推演：两个角色锁定行动、一份共享配方、一条压力规则、一种重置方式和两种终局状态。所有规则一致后，再选一个问题，例如第三回合是否过于严苛，然后只修改控制该问题的规则。还没明确新系统要创造什么决策前，不要加入它。

芦苇守望营地是带概念插图的原创教学纸面模型，不是经过测试的游戏、SEELE 生成结果，也不是本地或在线合作功能可用的证据。

常见问题

芦苇守望营地是可玩或测试过的示例吗？

不是。芦苇守望营地是根据规则手工推演的原创教学场景。页面中的行动和温暖值在规则内部可以计算，但没有提供提示词执行、生成构建、游玩过程或用户测试。把它当作规格练习；描述自己实现中的观察结果前，先验证实际版本。

两名玩家都需要一项独特任务吗？

每人都应对共同目标作出有意义的贡献，但不一定非要拥有完全专属的能力。在本例中，木工负责木桩，芦苇工负责屏障，两种材料缺一不可，因此双方贡献清楚可见。如果任一角色可以独自完成配方，就应判断这是否是有意设计，并更新规则约定和验收案例。

多人游戏制作工具能保证本地或在线合作吗？

不能。官方页面介绍玩家人数、模式、角色、目标、交互规则和短场景的规划方式。页面指出在线游玩仍需要实现、网络、同步、托管和测试。不要把这些规划细节当作生成结果已支持某种特定本地或在线模式的证据。

可以调整温暖值或配方数量吗？

可以。这些数值只是教学输入，并非平衡建议。如果调整温暖、采集数量、配方成本、回合顺序或寒潮检查时机，应重新计算基准案例和延迟案例。保持重置、胜利和失败条件不变，并一次只改一项，这样才能看出是哪条规则改变了结果。