1. 问题背景为什么AR场景的设备适配会让提示设计挠头1.1 AR场景里“设备适配”到底在适配什么先聊个真实的场景你在手机上看AR导航虚拟箭头叠加在街面上屏幕是竖着的距离人脸大概30厘米只要你稍微转动手机就能看到不同角度的引导信息。同样是这个功能换成智能眼镜之后用户的视线是水平的画面始终占据视野中心没有“拿起手机转换视角”这个过程屏幕的另一半还要留给现实环境。再换到平板设备上画面大了但用户手部动作更多虚拟物体可能悬停在桌面上而不是贴在马路上。表面上看都是“AR导航”但体验细节完全不同设备适配的难点就在这。我把AR场景里的设备适配拆开看大致是几个维度显示模式是手机/平板的Video See-Through视频透视还是头戴设备的Optical See-Through光学透视前者画面是摄像头实时画面后者看到的是真实世界叠加虚拟图层。这两种渲染渲染路径决定了模型输出的是“覆盖式提示还是沉浸式指令”。交互输入手机靠触摸屏、传感器旋转眼镜靠手势、眼动追踪、语音。输入方式不同UI组件的尺寸、位置、交互层级全都得变。算力与功耗手机扛得住大模型推理或复杂渲染轻量眼镜可不行。你不可能在低端设备上让模型生成一大堆重绘指令。环境感知能力有些设备带深度传感器LiDAR有些只有单目RGB摄像头有些带IMU惯导模块有些连陀螺仪都没校准好。模型如果不知道设备感知到什么就没办法判断该不该给出“前方有障碍物”这类提示。很多人把设备适配理解成前端工程师写的CSS媒体查询但这只是体验层的事。在AR场景里适配不只是界面缩放而是“设备能力到内容生成的映射”。设备该展示什么、不展示什么涉及语义决策从用户位置判断是否显示提示或者根据传感器置信度决定提示的详细程度。一旦把适配逻辑接入大模型生成流程——这就是提示工程要解决的问题。1.2 提示工程为什么能插手AR适配传统做法是写死规则相关逻辑会按设备型号和场景分支输出对应文案。一两个设备还行设备列表膨胀到几十种规则组合会爆炸同样的场所、不同的设备能力、不同的用户上下文排列组合就把代码库堆满。提示工程的思路不一样。你把设备能力、场景语义、用户意图都写成可被模型理解的文本上下文让模型基于这些上下文动态生成适配方案。也就是说设备适配从“硬编码映射”变成“语义生成”模型的泛化能力替你处理那些没提前想到的设备组合。举个例子用户戴着一款没有深度传感器的AR眼镜走到室内你想让模型判断是否显示“距离目标物体还有2米”的提示。传统逻辑必须先判断设备有没有深度传感器再决定要不要展示测距提示。用提示工程的方式你在系统提示里写明设备能力档位并附上一句“如果设备缺少深度传感器请不要生成依赖测距的提示”模型自己就会拒绝或降级处理。这就是把适配逻辑下放给模型的开始。需要提醒的是提示工程不是万能仙丹。AR适配里有些硬约束——比如设备GPU扛不住、渲染管线不支持——这些靠提示解决不了。提示能解决的是“语义层面的适配”和“呈现方式的动态选择”。这也是文章后面所有方案的前提先说清边界再讲怎么用提示不然你会把提示当代码使出事的时候又怪提示不靠谱。2. 设备适配问题的提示建模先别急着写模板2.1 把设备信息翻译成提示上下文我们需要设计一个地方存放设备档案。设备档案本质上就是把设备的硬件、软件、交互能力结构化供模型调用。它和代码里的配置文件很像只是最终会被格式化成一个文本上下文交给模型处理。设备档案建议按下面的结构整理device_profile设备基础设备类型、屏幕尺寸、分辨率、刷新率、处理器档位。这部分决定生成内容的视觉密度和复杂度。sensor_profile感知能力是否支持深度检测、是否支持平面识别、是否有IMU、摄像头数量与视角。这部分决定空间推理的置信度。interaction_profile交互能力支持触摸、点击、语音、手势、眼动其中的哪些。这部分决定你让用户怎么做。constraint_profile约束条件内存限制、最大渲染面数、网络带宽、电池模式。这部分决定模型避免生成的资源开销类型。这里可能有人问为什么不用JSON直接用我试过给模型喂JSON结构单个数据结构没问题但多设备多场景堆叠后JSON嵌套层级太深模型在长上下文里抓取关键字段的能力会下降。换成“紧凑字段列表自然语言描述”结合的方式会更稳。其实代码侧传输的仍然是结构化数据但在组装提示时要把它转成模型容易读取的文本形式这个转换步骤很多人容易忽略。直接看一个设备档案的提示片段基于常见实践整理当前设备档案 设备类型智能眼镜光学透视 显示能力单眼分辨率 640x480视角 30 度不支持高密度文字 感知能力单目 RGB 摄像头无深度传感器含 6 轴 IMU 交互能力语音输入单击确认无键盘 强制约束电池容量有限避免持续高算力渲染渲染面数建议低于 2000 面这段文本比一个嵌套的JSON对象更直白模型能快速对齐“我该以什么模式输出”。你没描述的信息模型会按通用AR设备推断而通用设备的默认值很可能和实际场景不匹配。2.2 提示分层系统层、场景层、设备层我建议把提示拆成三层。核心思路是系统提示保持全球统一场景与设备信息随调用时时注入。如果混合在一起每次设备变更都需要重写系统提示维护成本直线上升。第一层是系统提示层这个层级定义模型角色和硬性边界。系统提示提示持续存在于整个对话会话中放一些不能轻易变化的内容比如“你是一名AR场景内容生成引擎”、“不管任何情况下都不能生成虚拟物体遮挡用户视野的引导方案”等。第二层是场景层描述用户当前所处的环境语义。包括室内还是室外、光照条件、人数、用户目标。这层通常来自AR引擎的实时感知每次场景切换都会更新。第三层是设备层也就是前面的设备档案。根据当前运行的设备组装并注入。正因如此设备层是每次运行都能动态调整的。为什么要分层我踩过一个坑一开始把所有设备参数都塞进系统提示系统提示越维护越冗长最后连模型自己都不知道以哪段逻辑为准。分层之后模型在特定运行时刻只会看到与本次调用相关的组合决策干扰明显变少。拆分后的提示组装逻辑示例系统角色你是AR实时场景助手基于用户所在环境和设备能力生成适配方案。 场景层用户位于商场一层中庭环境光照充足目标为寻找最近的咖啡店。 设备层手持手机后置双摄支持平面识别屏幕竖屏支持触摸。 请求请给出当前路线引导方案输出限制在三行以内。看这个地方的差别。系统层没有说“必须是手机”或“必须竖屏”它保持绝对通用设备层只描述“当前运行环境”让模型即时调整引导方案的文案、长度、信息密度。2.3 上下文窗口与Token预算AR适配的隐形瓶颈AR实时场景有一个致命约束就是延迟。提示工程普遍关心回答质量但在AR里回答速度同样是核心评价指标。模型推理是吃内存和GPU的而token越多推理越慢输出越慢AR里的悬浮提示就越显得迟钝。一个运动着的用户不会等你5秒钟自然会质疑这个AR系统是否卡顿。所以你要把上下文消耗严格控制住。控制手段有三个。第一是裁剪设备档案。设备档案别事无巨细全丢进去。优先保证带“对输出决策有影响”的字段。比如你要模型决定是否生成测距提示那么没有深度传感器是必填字段如果你只做UI文案生成传感器细节可以直接省略。第二是控制历史对话。AR场景里的对话往往是短任务用户问一句“咖啡店在哪”模型给一句答案任务结束。那就少放历史会话。很多架构师习惯把历史消息全量塞给模型这种做法在AR场景里是灾难。建议用滑动窗口只保留最近三轮对话或干脆单轮状态生成。第三是压缩输出格式。AR设备上用户不需要长篇大论适配后的内容应该短小精悍。你在提示里明确“输出不超过20个字不要生成Markdown列表不要使用多余标点”既能降低推理耗时也能减少UI渲染负担。如果输出结构是JSON用紧凑模式不要带缩进和多余字段。3. 核心实现一套可落地的AR适配提示模板3.1 设备能力档位让模型一眼读懂硬件差异与其让模型从一堆文本里推断设备性能不如你直接告诉它“当前设备属于哪个档位”再给一个该档位下通用的输出策略。这就像外科医生拿到一份病历摘要摘要起头先写“患者无过敏史”后面的一切决策都以此为基准。我按实际项目经验把AR设备大致分了几档供参考档位典型设备输出策略A档旗舰手机、高端平板允许复杂视觉引导、可以输出较长的多步骤指令、可使用更多虚拟辅助元素B档中端手机、基础平板输出简洁指令、避免过多虚拟元素、单步提示为主C档轻量AR眼镜、老款手机短提示、大字、少元素、依赖语音反馈避免高渲染负担D档基础AR眼镜、低算力设备仅文本/语音提示不做复杂的空间标注减少特效叠加在设备档案字段里加入一列名为device_tier值为A/B/C/D再对应提示写一句“你是X档设备请按X档输出策略生成内容”。模型不用再自己揣摩你的手机到底几斤几两。你可能会担心某个设备档位划分不准确实际上在业务里先粗分用一阵子再根据线上召回率和用户反馈逐步细分完全可行。3.2 提示模板与变量定义能直接抄作业的那种因为场景多种多样我下面给出一个相对通用、可以直接改造使用的模板。关键是对齐变量占位符不能直接抄完后缺少变量引起解析错误。system 你是一名AR增强现实场景助手。你的工作是根据用户的实时环境和设备能力生成可用于AR叠加层的引导内容。 无论如何你都遵守以下硬性规则 1. 不生成与事实不符的空间描述。若感知信息不完整如无深度传感器拒绝给出精确距离预判。 2. 输出内容必须适配在AR设备的显示范围内。不得生成超过屏幕显示能力的密集布局或过小字号文字。 3. 所有引导必须采用面向行动的句式例如“直走8步后左转”不要使用说明文句式。 4. 若设备档位较低减少虚拟元素的描述优先使用语音和简单的方向箭头。 5. 输出默认使用JSON结构{type:guidance,action:...,distance:...,display_priority:high|normal|low}任何额外的解释都不要输出。 user单轮注入 设备档案开始 - 设备档位{device_tier} - 显示模式{display_mode} - 传感器能力{sensor_capabilities} 设备档案结束 场景信息开始 - 位置{location_context} - 当前目标{user_goal} - 环境条件{environment_condition} - 用户运动状态{movement_state} 场景信息结束 请根据以上信息生成最适合当前设备与场景的AR引导内容。仔细讲解几个字段的含义display_mode区别很大。如果是“手机竖屏”你最好生成指向性箭头和简洁文案如果是“AR眼镜”就要减少完全覆盖视野的元素多用边缘位置提示或语音引导。sensor_capabilities如果包含“depth”或“plane_detection”模型可以放心生成“前方1.2米处右转”这类带距离的提示如果不包含生成“前方路口右转”而非距离描述会更安全。movement_state对生成时序很重要用户站立时你没有必要生成连续性的运动指令能从容地提供多步引导用户移动中内容得短促有力。模型输出示例{type:guidance,action:直行并通过前方入口后右转,distance:无需测距,display_priority:high}整个输出干净利落无需解析成本低直接映射成AR叠加层字段。3.3 与Skill Agent的分工不是所有事都靠提示堆再说一个网上经常被问到的问题系统提示词和skill agent到底有什么区别我在AR适配里面正好用到过两者的分工。我的理解是系统提示词解决“同一职责下所有输入的整体决策边界”它就像是公司总部的规章制度——所有岗位都要遵守。skill agent类似专职外包团队它承接具体的、独立的子任务只在主流程需要时被调用。在AR场景中设备适配这个整体任务是系统提示主导的判断设备能力、做输出限制。但“识别用户当前位置附近有没有咖啡店”这种具体的空间检索任务属于外部能力。它会调一个地图或商家数据的工具那部分可以由skill agent承担。两者不冲突。拆分方式值得参考系统提示只干三件事定义角色、规定输出格式、制定设备适配策略。Skill agent则封装特定功能二维码识别、地标识别、商家搜索、路线检索、语音指令解析。主流程在设备A或设备B上运行时系统提示不变不同的功能需求动态挂载不同的skill agent。设备适配策略与外部技能互不相扰。这也是为什么我把系统提示设计成“始终存在且变化极小”。如果你把商家搜索逻辑写进系统提示提示就越来越长变更越来越频繁最后你根本分不清哪个设备适配问题是由哪个改动引起的。4. 实操过程从零搭建一套能跑的AR提示系统4.1 第一步采集极端设备环境动手写提示之前先把边界案例列出来。很多人上来就写一大段提示看着啥都覆盖一落地就翻车。边界情况反而不在多在于“极端且常见”。我建议至少采集下面几类低端设备复杂场景。比如一款低配手机在拥挤的地铁站做AR导航。硬件扛不住满屏渲染用户运动状态又频繁变化。高配设备冷门场景。比如高端MR眼镜在一个光线极暗的地下停车场。设备性能没问题但环境感知弱模型可能生成错误的距离提示。设备能力与场景目标冲突。比如用户戴眼镜逛博物馆想看清展品的细节文字但设备和显示模式不适合呈现长文本说明。输入方式受限的设备。比如纯语音交互的AR眼镜模型输出了一串需要点击的按钮列表这就是典型的适配失败。把这些边界条件整理成表格每行包含设备档案、场景信息、期望输出、可接受输出、失败输出。后面调试时你就拿这些案例来验证提示质量而不是凭感觉测试。4.2 第二步设计条件性指令条件性指令是提示工程里最实用的技巧意思就是让模型基于设备能力逐层判断该做什么、不做什么。用一个大段落描述所有规则不如拆成一连串清晰的条件分支。模型做判断比做综合推理稳定得多。示例条件逻辑如果传感器能力中不包含平面识别则 - 不要生成基于地面平面的虚拟物体放置指示。 - 若用户询问“放在哪里”回应“将该物品对准前方地面可见区域”不要提供坐标偏移值。 如果设备档位为C或D则 - 引导输出必须以语音和箭头为主。 - 虚拟叠加元素不得超过3个。 - 取消文本段落展示改为单行短文本。 如果display_mode为光学透视则 - 虚拟指引必须保持在用户视野中心30度范围内不能设计成需要低头看的界面。我看到很多人的提示里全是“应该”“可以”“尽量”这种软性词。在AR这种低容错场景中要敢于使用“必须”“取消”“不得”。模型对强约束指令的遵从率明显高于弱约束。这也是提示工程里容易被忽略的一点措辞的强度本身就是可利用的输入设定。4.3 第三步搭一个最小验证流程不用一步到位接真实AR渲染可以先做提示的离线回归验证。这也是我在实际项目里的做法在真实设备联调之前先把提示放到一套模拟输入集上跑通。最小验证流程包括准备一组模拟输入格式就是第3节的user模版填上不同的设备档案和场景信息。准备好一个评测数据表记录每次输出是否符合预期不符合的打标记。批量轮询模型把输出结果和预期结果做对比统计通过率。针对失败案例逐条归类是设备理解错误、输出格式错误还是场景语义错误。离线回归验证最重要的是反馈速度快。改一次系统提示30秒内能看到十几条案例的输出变化。比反复去真机调试高效得多。真机调试有很多干扰因素光线、网络、传感器噪声不适合做提示词迭代。当离线回归的通过率达到80%以上再去真机连调。真机连调阶段主要观察交互舒适度、响应时延、视觉布局这些离线测不出来。4.4 第四步把提示接入AR引擎上下文被频繁追问的一件事是提示里的场景信息从哪里来它来自你当前的AR引擎。一般常见做法是在AR会话帧循环里把引擎算好的语义结果按照固定格式塞进用户消息。不要直接逐帧调用大模型会爆时延。我自己的做法是设定一个触发条件比如“用户静止超过2秒”或“用户主动询问”才发起模型调用。当用户在连续移动时模型调用频率要降下来因为运动场景下精度本来就低还不如不做预测。具体代码层面把上文的user模板变成一个函数每次进入触发条件时重新组装参数并调用。参数来源device_tier来自设备能力配置中心display_mode来自渲染引擎的显示模式sensor_capabilities来自感知模块location_context来自定位模块user_goal来自意图识别模块environment_condition来自实时环境感知movement_state来自位姿估计这套参数组装逻辑本身就是设备适配的核心提示词只是把参数转换为输出决策。只调提示不动参数是不行的。做设备适配不要只盯着提示词文本本身还要把上游参数的实时性和准确性一起抓起来。5. 高频问题与调试经验实录5.1 常见问题速查表下面这几个问题我在几个项目里反复碰到整理成表格方便查阅。现象可能原因对策模型在无深度传感器设备上依然输出精确距离设备档案里没有写清楚传感器缺失或提示里没做条件禁止在设备档案强制加入“无深度传感器”在条件指令中加“不得输出精确距离”输出内容超出AR眼镜视野之外提示中的显示能力限制缺少具体数值或方向提示在设备档案中加入“画面始终保持在视野中心30度内”等明确限制低端设备渲染卡顿提示允许了过多虚拟元素或复杂视觉布局针对C/D档位明确“虚拟元素不超过3个”“取消阴影和高光描述”用户移动过程中提示滞后调用频率过高导致链路时延堆积降频改移动触发控制仅在静止或主动请求时调用模型模型输出格式频繁变更没有给输出示例模型自由发挥tag结构在系统提示里加入固定JSON结构示例甚至可以加few-shot示例5.2 调试提示词时踩过的一些坑第一个坑是提示里堆设备参数堆得过多。一开始我以为把能想到的参数全放进去最安全结果模型在长上下文里把次要参数当成了主要决策依据。举个例子模型看到设备支持无线充电居然在AR引导卡片上生成了一条“建议你到充电区为眼镜充电”完全脱离当前导航任务。所以我现在只保留与当前任务强相关的设备参数其余一概不进上下文。第二个坑是让模型自己去推断设备能力。曾经想偷懒只写“设备某品牌AR眼镜”让模型自己查。模型确实能说出这个品牌的一些功能但描述不完整遇到边角型号就瞎编。现在设备档案永远明确描述能力不让模型做第二手猜测。这个教训说白了就是提示里凡是你能说清的绝不让模型自己猜。第三个坑是忽略输出消费端的要求。有一次提示词生成效果很好文本合适但前端解析JSON时发现字段命名不统一不得不加一堆解析兼容。后来我把输出JSON结构直接写死在线模型调用前增加一道格式强制校验不合法就自动重试一次。总比前端兼容判断强得多。第四个坑是盲目追求“更长的提示”。提示变长会让模型注意力分散到次重要规则上。我的体会是提示精简到每一个字都有作用能删就删。如果某个规则在20轮测试里从未触发说明这个规则描述的交互根本没出现或者已经丢出决策范围直接删掉。5.3 提示设计与真机联调的个人心得真机联调和离线回归是两个完全不同的感受。离线看提示词输出格式整齐、逻辑清晰一到真机上会觉得所有反应都慢半拍。这是因为AR场景里用户的耐心窗口极短模型推理时间被感知放大。能优化的空间不只在提示本身还要从业务上做功能降级。比如低档设备遇到复杂任务不必追求一次把完整引导做出来而是采用渐进式引导先给一个动作用户执行后再给下一个。这个思路也完全可以指示模型“分成逐步引导一次只输出一步”。第二个感受是设备适配不是一次性动作。手机系统更新会增加新感知能力同一款AR眼镜在不同系统版本上的接口可能不同。设备档案要像代码配置一样纳入版本管理设备变、提示跟着变。但系统提示应该保持稳定因为它是模型的角色理解基础频繁改动会让模型言行不一致。第三个感受是不要把所有都押在提示工程上。比如设备间距估算这件事如果你手里有精确的深度传感器数据那直接代码算出来填进提示里即可不需要模型猜模型做的应该是信息合并与呈现决策。提示工程负责让模型理解“当前设备能感知到什么、该呈现什么”硬精度交给系统计算两者配合好才能真正解决AR设备适配。6. 最后分享一个小技巧在系统提示最后加一句回收语会让你调试省一半力气比如“当你判断当前任务无法在给定设备上安全完成时只需输出{type:fallback,action:建议使用语音引导}即可”。这句话其实是给模型留了一个安全出口。很多适配失败不是模型不懂规则而是规则之间的优先级没说清模型在矛盾中只能硬着头皮输出。给一个明确的降级方案模型反而敢做判断这里不满足条件我先安全退出。这类出口在多设备场景下特别有价值因为总会遇到你事先没料到的设备组合。AR场景的提示工程跟普通聊天提示最大的差别在于线上每秒钟都在消耗你的模型预算和用户耐心你设计提示不只是为了“答得好”更是为了“在特定设备上能以最短路径完成适配”。把设备能力、场景语义、模型决策三者串成一条线适配体验就自然顺了。