做提示工程这一年我经常被问到一个很现实的问题AR场景的设备适配为什么不用代码写死反而要靠优化提示词说实话最早我也不信Prompt能解决适配问题。直到我连续两个项目都栽在“同一套叠加层逻辑在不同眼镜上表现天差地别”这件事上才意识到设备适配的数据通路里模型对设备能力的理解比渲染管线更早成为瓶颈。提示工程在AR场景里要做的不是让模型把内容写得更漂亮而是让模型在生成叠加层之前就知道自己正在为一台什么设备工作从而自动规避不支持的交互、调整信息密度、改变渲染复杂度。这篇文章是我在实际项目中沉淀下来的一套方法论设备能力画像、上下文工程、提示词模板、skill agent 的取舍以及一路上踩过的坑。适合正在做“大模型AR眼镜/空间计算”的工程师、提示词开发以及想搞清楚“为什么单纯把提示词写长解决不了问题”的同学。1. AR设备适配为什么变成了提示工程问题1.1 设备碎片化让“写死配置”越写越贵普通手机App适配你处理的是屏幕宽高比、系统版本、权限差异最多再加一个刘海屏。AR眼镜完全不是这个画风。同一套内容跑到不同眼镜上你要同时考虑视场角FOV、跟踪精度6DoF还是3DoF、交互方式手势、语音、按键、眼动、显示类型BirdBath、光波导、视网膜投影、算力预算能不能跑实时渲染……这些参数的任意组合都能产生一种新设备。如果全部在代码里硬编码成if判断维护成本是指数上升的。我见过一个真实项目设备型号从3个涨到8个的时候配置代码膨胀到几千行的switch结构新增一个型号要么把老型号的配置复制一遍要么在多个入口同时修bug。提示工程当然不能替代渲染引擎和硬件抽象层它能解决的是“分支出得太快、前置信息太散”的问题把设备能力固化成一份机器可读的画像交给模型去理解、去决策分支逻辑不再由人类逐条维护而是由模型基于画像自行生成适配方案。1.2 提示优化的三种介入层次我习惯把AR场景里的提示优化分成三个层次对应三种不同的优化目标。第一层是内容层。模型生成叠加层的文字描述时信息密度、语气、篇幅可以根据设备能力调整。轻量眼镜上不要输出长篇大论桌面级AR设备可以展示更丰富的说明。第二层是交互层。约束模型只能输出当前设备支持的交互指令。设备不支持手势识别就禁止模型在结果里出现“手指点击”之类的动作只支持语音和按键就把交互链路收敛成语音确认加按键导航。第三层是渲染层。让模型输出结构化的渲染建议比如字体缩放系数、背景透明度、最大叠加元素数量这些直接变成渲染引擎的输入。三层通常一次性全做但内容层最简单渲染层的杠杆最大。后面第三部分给出的模板就是把三层一起处理。2. 设备能力画像先把“设备长什么样”说清楚2.1 画像字段选择枚举值为王大模型没有感官它根本不知道设备长什么样。你如果不在上下文里主动告诉它它默认版本永远是“最好的那台眼镜”啥交互都支持、屏幕永远足够大、渲染性能无上限。结果就是模型自信满满地生成一串手势指令实际设备根本执行不了。这个问题和模型聪明不聪明没有关系纯粹是信息供给不足。要解决信息供给首要动作是给模型一份“设备能力画像”而且字段必须标准化。我最开始用的是一段自然语言描述比如“这是一台轻量级AR眼镜支持语音和头部转动”实际效果很不稳定。模型经常会自由发挥把“头部转动”理解成“手势滑动”。后来我把所有字段收敛成固定枚举值准确率立刻上了一个台阶。下面是一份我在项目中实际使用的画像结构你可以直接抄走再按需删减{ device_id: AR-Lite-1, display: { type: birdbath, fov_degrees: 28, resolution: [1280, 720] }, tracking: { dof: 3, slam: false, accuracy_cm: 5 }, interaction_modes: [voice, gaze, button], performance: { level: low, gpu_available: false, memory_mb: 4096 }, sensors: [camera, imu, microphone] }这里的关键不是字段多而是字段值的候选集合固定。display.type 只能取 birdbath、waveguide、retinal、screen 四种tracking.dof 只能是3或6interaction_modes 只能从预设好的枚举里选。模型一旦拿到有限的选择集合就不会在那个维度上胡编。你甚至可以模仿JSON Schema的方式把每个枚举值的含义附在字段后但不要写成自然语言故事模型对结构化数据的跟随能力远好于对长篇描述的跟随能力。2.2 画像信息放哪里上下文工程的取舍有了画像第二个问题是把它放在提示词的哪个位置。这里其实是上下文工程的核心问题。很多人的第一反应是塞进系统提示词理由是“系统提示词权重高”。但我在实测中发现一个反直觉的现象设备画像放在系统提示词里放到中后段时出错的概率明显增加。这个现象和上下文注意力分布有关模型对一段超长上下文的首尾内容记忆最好夹在中间的信息容易被忽略。系统提示词里如果已经写了大段的人设和功能规则设备画像再挤进去就成了“中间内容”。所以我的做法是把长期不变的规则和角色定义放在系统提示词把动态变化的设备画像放在每轮用户消息的末尾紧挨着用户意图。这样模型在决策时会先看到“用户想干什么”再看到“这台设备能干什么”生成的适配结果明显稳定。你可以理解成给设计师递需求时不要先甩五百页设备说明书而是先讲清这次要做什么再附一张能力红线的单页备注。2.3 看不到的设备能力也要写进画像还有一类能力不会出现在官网参数表里但直接影响模型输出比如散热限制、持续高负载下的降频策略、屏幕亮度上限。这类软性约束我用能力标记capability flags的方式塞进画像比如flags: [no_sustained_high_load, outdoor_low_visibility]。有了这些标记模型在生成复杂3D素材时会主动降低密度在户外场景会提高文字亮度对比度。这类细节一开始很容易漏但恰恰是AR体验从“能跑”到“好用”的分水岭。第3章开始之前建议你先把设备画像的字段和枚举值固定下来。这是整个提示工程的基础设施后面所有模板和skill都依赖这份画像。画像不稳定后面改多少次提示词都是白费。3. 实战一套可落地的AR适配提示词模板3.1 模板结构与设计意图直接上模板。这套模板我用了大半年在多个项目里验证过不依赖特定大模型的特殊功能普通对话模型也能跑出可用的结构化结果。系统提示词部分你是一个AR场景适配引擎。你只做一件事根据设备能力画像和用户意图输出一份严格JSON格式的AR叠加层配置。 规则 1. 先评估设备能力再生成配置评估过程写在输出JSON的assessment字段中。 2. 不得包含设备不支持的交互方式。 3. 信息密度必须符合设备的显示限制。 4. 输出必须是可以被json.loads直接解析的JSON不要输出任何多余文字。用户消息部分设备画像 {设备画像JSON} 用户意图{用户意图文本}这里看起来很简单但有两个设计点极其关键。一是“先评估再生成”强制模型在输出config之前先输出assessment等于逼它做一次约束检查。我对比过有assessment和没有assessment的版本输出不合法交互的比例差不多降低了一半。二是“输出必须能被json.loads直接解析”这句是让模型收敛到标准JSON、避免给解释性文字的保命符。对应的输出结构{ assessment: { supported_interactions: [voice, button, gaze], display_constraints: { max_overlay_items: 3, max_text_length: 80 }, performance_budget: low }, overlay_specs: { layout: single_card_bottom, content: { title: 星巴克咖啡厅, description: 前方30米右侧二楼 }, interactions: { primary: voice_confirm, secondary: button_navigation }, render_hints: { font_scale: 1.4, background_opacity: 0.7, max_elements: 1 } } }overlay_specs里的layout、interactions、render_hints是给渲染引擎消费的。我建议渲染引擎只认这个JSON结构不要直接读LLM输出的自然语言。这样既隔离了大模型的输出不确定性也方便后续做回测和日志归因。3.2 参数灌入与输出解析模板确定后参数灌入是一个工程问题。最朴素也最稳定的方案是用模板字符串拼装。我平时用Python核心代码就一个函数import json ADAPT_TEMPLATE 设备画像 {device_profile} 用户意图{user_intent} def build_adapt_prompt(device_profile: dict, user_intent: str) - str: profile_json json.dumps( device_profile, ensure_asciiFalse, separators(,, :) ) return ADAPT_TEMPLATE.format( device_profileprofile_json, user_intentuser_intent )这里有个细节separators(,, :)是把JSON压缩成紧凑格式。设备画像如果没必要给人看就不要保留空格换行能省一点是一点。AR场景经常跑在端侧上下文窗口可能并不宽裕。输出解析建议加一层容错。模型偶尔会多输出几个字哪怕你提示词里写了“不要输出多余文字”。我一般会先尝试json.loads(raw)如果失败就发一条纠正消息给模型“你刚才的输出不是合法JSON请重新输出完整JSON”这样通常一次就能救回来。真正的生产系统里我会在上一轮就把原始输出存进日志后续用于回测分析。3.3 一个真实样例的完整链路看一个具体例子。用户在城市漫游场景下说“帮我找一家附近的咖啡店要环境安静适合办公。”同一个意图分别跑在高端设备A和中低端设备B上输出差异非常明显。设备A的画像双目、6DoF SLAM、高清透视、支持手势、高性能GPU。模型生成的overlay_specs里interactions.primary 可能是pointer_anchor_and_hand_click模型会给出一个悬浮的3D指示箭头支持用户用手指点选远处咖啡店的外卖菜单render_hints里会允许显示三张卡片和实景标注的自由移动。设备B的画像单目、3DoF、无手势识别、低性能。模型会把overlay_specs收敛成底部单卡片只保留“店名、距离、方向箭头”这三要素interactions.primary 变成voice_select确认方式变成语音确认或按键切换。render_hints里明确max_elements: 1避免画面过载。同样一句用户意图模型根据画像做出的渲染决策完全不同而且整个过程零硬编码if判断。这就是设备画像切入提示工程的价值。4. 从系统提示词到skill agent适配逻辑该装在哪一层4.1 系统提示词和skill agent到底有什么区别很多人把系统提示词当万能容器什么东西都往里塞等到提示词超过8000字、改动一次牵一发动全身时才开始怀疑人生。这就引出一个很实际的问题设备适配逻辑应该写在系统提示词里还是做成一个独立的skill agent我的标准很简单。系统提示词适合放全局不变的规则和角色设定比如“你是一个AR助手”“你说话必须简洁”。而设备适配这个任务它有确定性输入输出、有独立的枚举约束、需要频繁升级天然适合拆出来做成skill。两者的区别可以用一张表说清楚维度系统提示词skill agent职责范围全局角色与行为规则单一一类子任务的完整执行流程上下文占用每一轮都携带按需调用不进入主对话时零占用维护成本改一处影响全部场景独立版本单独回滚调试方式日志混杂难定位可单独注入固定输入测试复用性捆绑在主对话里可在多个主对话、多个产品间复用设备适配属于高频变化、确定性强的逻辑如果直接做成skill新增设备型号时候只要改skill内部维护的设备画像库主对话提示词一行都不用动。主对话只负责理解用户意图碰到需要AR渲染的场合调用skill拿回一份配置再继续往下聊。逻辑上干净工程上也好维护。老实说项目初期直接用系统提示词加模板够用但一旦设备型号超过5个建议立刻拆skill。4.2 把适配做成独立skill的改造路径从提示词迁移到skill不需要大动干戈。你可以把第三部分的那个适配模板直接封装成一个可调用的接口内部结构就是“设备画像库 模板 输出校验”。接LLM的自然语言理解出去的就是标准化JSON。改造后的调用链路大概是这样的用户说“帮我找咖啡店”主对话识别出需要空间叠加层。主对话抽出用户意图调用adapt_overlay(device_id, user_intent)这个skill。skill内部查设备画像库拿到当前设备的JSON画像灌入适配模板。LLM输出JSONskill做schema校验不合规就重试一次。校验通过后把overlay_specs交给渲染引擎执行同时把结果摘要返回主对话继续会话。这个链路的好处是故障隔离。渲染出问题、交互不对只需要单独测试skill主对话的人设、语气、知识问答不会受影响。我在公司内部甚至直接给这个skill设计了独立的回测集每次改模板都能自动跑一遍回归。另外很多人纠结“agent要不要有工具调用”。我的看法是设备适配这个场景不太需要联网搜索、也不需要数据库查询它的核心是把静态画像和动态意图组合出决策。所以skill的内部动作比想象中简单最重要的反而是输出校验这一环。不要为了“有agent味”而强行给skill加一堆用不上的工具。5. 常见问题排查与验收实录5.1 高频雷区与对应解法这个部分全是实操里踩过的坑。整理成速查表遇到问题直接对号入座。雷区一模型输出了设备根本不支持的交互比如设备画像里明明没有手势识别模型还是给出hand_click这种动作。根因一般是两个一是画像字段不够显眼被埋在了长上下文里二是输出约束没给够。解法是双重保险把interaction_modes提到设备画像的最上方同时在输出模板里明确写出“interactions.primary只能从设备画像的interaction_modes枚举中选择否则视为非法输出”。如果还出现就在few-shot里加一条反例样本。雷区二适配结果时好时坏同一台设备同一句话两次输出不一样除了模型本身温度参数的问题最常见的原因是上下文里设备画像的位置不固定。我见过有人先拼用户意图、再拼设备画像下一轮又把画像提到最前面模型的表现就会飘。解法是把消息拼装顺序完全固定设备画像固定放用户消息末尾、意图之前一个项目里永远不变。雷区三设备画像太长把上下文塞爆AR设备动辄几十个字段放大模型上下文里确实心痛。解法很简单做两级画像。一级是给模型看的能力摘要只保留会影响生成决策的字段二级是完整的设备配置库存在本地数据库里渲染引擎要用完整参数时再查。模型从来不需要知道设备的所有技术细节它只需要知道“哪些能做、哪些不能做”。雷区四改了一行提示词某个设备型号的适配反而倒退这个问题几乎每改必现根源不是提示写错了而是没有回测。提示词是全局生效的你在修复设备A的某个bug时很可能顺带改坏了设备B的交互逻辑。没有自动回测之前我平均要花三到四天才能意识到一次改动影响了哪些老场景。后面做了回测集这种回归问题最快半小时就能发现。5.2 用回测集代替拍脑袋调参做提示工程不能靠感觉一定要把验收变成自动化任务。我的回测集规模不大但覆盖要全。一般准备20到30条构造样本设备类型覆盖高端、中端、轻量三级意图覆盖导航、信息查询、娱乐消费、无障碍辅助四个常用场景。每条样本标注期望行为比如“不允许输出手势交互”“允许最多两个叠加层”“必须包含语音确认”。打分规则也很朴素模型输出里出现设备不支持的交互该条直接0分。输出的JSON可以被标准解析器解析加1分。overlay_specs信息密度符合设备限制加1分。渲染建议与设备性能匹配加1分。满分3分及格线2.5分低于及格线不允许发布。这个回测集不追求面面俱到目的只是拦截明显坏档。我甚至不会让LLM自己给自己当裁判直接写规则脚本检查JSON里是否出现禁用枚举即可。等到规则脚本跑到绿了才代表这次提示词改动可以放心上线。回测集建立之后还有一个额外收益它逼着你把设备画像的枚举彻底定义清楚模型的输出候选集稳定了后面所有优化都变得可量化、可验证。坦白说如果只能从这篇文章里带走一句话我希望是这一句提示工程解决AR设备适配问题的核心不是把提示词写得更长而是把设备差异压缩成一份稳定画像再用一套固定模板让模型基于画像做决策。设备画像、上下文位置、输出校验、回测集这四件事做扎实适配问题就已经解决了一大半。