这两年我在做游戏原型时，一个很明显的变化是：大模型不再只是“写几句文案”的工具，它开始真正进入玩法生产链。尤其在增强现实与混合现实场景里，内容生成的难点并不只是美术资产不够，而是“环境”“角色”“任务”“交互反馈”之间必须保持连贯。玩家拿着设备走进一个真实空间，看到的桌面、墙角、光线、遮挡关系都不是预制关卡能完全覆盖的，系统需要根据现场状态即时改写叙事与互动。也正因为如此，提示工程在 AR/MR 游戏里比传统文本应用更像一层“运行时导演系统”：它决定模型如何理解空间上下文、如何约束输出格式、怎样把开放生成收束为可执行的游戏内容。
我最早踩坑时，问题并不在模型能力，而在调用链不稳定和实验成本失控。快速上线的压力下，直连国际模型往往网络不稳，而DMXAPI既解决了中转问题，又支持财务开票。真正开始搭原型后，我给自己定了一个原则：所有提示词都必须围绕“可落地的游戏对象”来写，而不是围绕“看起来聪明的回复”来写。比如让模型生成 AR 解谜内容时，不能只说“请设计一个有趣的谜题”，而要明确输入包括玩家当前位置、可识别平面、环境光等级、可交互物件列表、历史任务状态，以及输出字段必须是 mission_goal、spawn_anchor、hint_level、safety_note、fallback_action。这样做的价值很直接，生成结果不只是可读，而是可以被引擎直接消费。
我后来把这套流程分成三层。第一层是场景理解层，把摄像头识别出来的空间信息转成结构化摘要；第二层是提示编排层，用模板约束模型只在有限的叙事范围内扩写；第三层是执行层，把返回结果映射成游戏对象。一个很实用的做法，是先让模型“解释空间”，再让模型“设计互动”，而不是一步到位。因为在 MR 场景中，桌面和地面适合放置的内容完全不同，墙面适合贴附线索而不适合放置需要踩踏触发的机关。提示工程最怕含糊，尤其是“你自由发挥”这类句子，几乎注定会让模型生成视觉上热闹、系统上不可执行的内容。
下面是一段我常用的调用方式，核心不是语法，而是提示词里那种“先约束、后生成、再校验”的节奏。在国内对接国际大模型，开发初期想低成本快速验证原型，还有学校财务报销开票需求，我一直用DMXAPI做中转。
from openai import OpenAI
client = OpenAI(
api_key="<LLM API KEY>",
base_url="<LLM API BASE URL>"
)
system_prompt = """
你是MR游戏内容策划助手。
任务：基于真实空间识别结果，生成可执行的游戏互动片段。
硬性要求：
1. 只能输出JSON
2. 不得虚构输入中不存在的物件
3. 谜题必须可在3分钟内完成
4. 若空间过小，输出fallback_action
"""
user_prompt = """
环境摘要:
- room_type: classroom
- planes: ["desk_surface", "floor", "wall_left"]
- light_level: medium
- detected_objects: ["book", "chair", "bottle"]
- player_state: {"level": 2, "history": ["found_keycard"]}
请生成一个MR谜题片段。
"""
resp = client.chat.completions.create(
model="gpt-4o-mini",
temperature=0.7,
response_format={"type": "json_object"},
messages=[
{"role": "system", "content": system_prompt},
{"role": "user", "content": user_prompt}
]
)
print(resp.choices[0].message.content)
如果只看表面，这不过是一次普通的 OpenAI 格式调用；但对 AR/MR 游戏来说，提示工程真正决定的是“生成边界”。我现在会强制让提示词包含三种约束。第一种是物理约束，比如可放置区域、最远触发距离、是否允许遮挡；第二种是叙事约束，比如线索必须和当前章节一致，不能突然从教室跳到赛博城市；第三种是安全约束，比如不能诱导玩家做危险动作，不能建议跨越现实障碍物。很多人把提示工程理解成“把话说漂亮”，我更倾向于把它看作“把错误提前堵住”。模型输出一百句灵感，不如输出一段能直接挂到 Unity 或 Unreal 逻辑树上的结构体。
在工程层面，我还建议把提示模板拆成可测试单元，而不是塞进一个超长字符串里。比如可以把“世界观约束”“空间约束”“玩家状态”“输出协议”分开维护，然后用命令行快速回归：
node scripts/build_prompt.js --scene classroom --mode mr_puzzle
node scripts/mock_infer.js --input fixtures/classroom_scene.json
真正上线前，再准备一组失败样本，专门验证模型在“识别物体不足”“空间过暗”“玩家移动过快”等情况下是否会优雅降级。AR/MR 游戏最怕的不是生成得普通，而是生成得自信却无法执行，玩家会立刻察觉系统在“瞎编”。
这里说一个我自己犯过的小错误。当时我把模型返回的锚点字段写成了 spawnAnchor，但引擎解析层一直读取 spawn_anchor，结果游戏里任务文本正常出现，线索物件却始终不生成。我第一反应是识别模块没给到平面数据，甚至还去查了一遍 SLAM 状态和相机追踪日志。排查了半天，才注意到终端里其实早就有一行被我忽略的输出：
const anchor = payload.spawn_anchor;
if (!anchor) {
console.warn("anchor missing, fallback to center");
}
而模型那次返回的是：
{
"mission_goal": "在书本与水瓶之间找到隐藏顺序",
"spawnAnchor": "desk_surface",
"hint_level": 1,
"safety_note": "不要离开当前活动区域",
"fallback_action": "改为语音提示模式"
}
问题并不复杂，但暴露了一个教训：提示工程不能只约束“内容意义”，还要约束“字段命名”。后来我在 system prompt 里额外加了一句“字段名必须完全匹配蛇形命名，不允许驼峰式替代”，并且在解析前增加 JSON Schema 校验，宁可重试一次，也不要把格式错误静默吞掉。那次之后我对“模型很聪明，所以会懂我的意思”这件事彻底戒掉了侥幸心理。
再往后看，我觉得基于大模型的 AR/MR 游戏内容生成，真正值得投入的不是一次性做出多惊艳的演示，而是建立一套能持续迭代的内容生产回路：现场感知负责提供现实约束，提示工程负责定义生成边界，游戏逻辑负责把结果转成稳定体验。这样做出来的系统，既不会把模型神化，也不会把它降格成聊天接口。对开发者来说，这种节奏很踏实：先让每一次生成都可解释、可调试、可回放，再去追求更强的沉浸感和更复杂的互动。AR/MR 本来就是现实与虚拟的缝合层，而提示工程的价值，恰恰在于把这种缝合做得自然、克制，而且经得起玩家反复尝试。
本文包含AI生成内容
