同一个业务需求，Web端要求信息密度高、表格化展示，小程序端却要卡片式短文案，App端还多出一层原生交互组件。如果提示词里没有端侧信息，大模型只能按照最通用的方式输出，结果就是每端都要人工再改一遍。要解决这个问题，核心思路是把“端”变成提示词里的一等公民变量，让模型根据变量切换输出策略。
一、为什么单一提示词无法满足多端需求
大模型在生成界面文案、布局建议或组件代码时，依赖的是上下文中明确的约束。当提示词只写“生成一个商品详情模块”时，模型会给出一个折中的通用方案：文案长度中等、布局假设为中等屏幕、交互假定为鼠标点击。这种输出在Web上勉强能用，在手机小程序里就会出现文字超长、按钮堆叠、图标缺失等问题。
三端的差异主要体现在三个维度。第一是屏幕与信息密度：Web通常1080像素以上宽度，可以容纳多列布局；App和小程序以375到414逻辑像素为主，信息必须纵向堆叠。第二是组件能力：Web可以用任意HTML标签，小程序只能用官方组件库，比如<view>、<text>、<picker>，而App可能对应原生控件。第三是交互习惯：Web支持hover状态，移动端完全不存在悬停，只有点按和长按。
所以多端适配的提示词设计，本质上不是写三份提示词，而是写一份带条件分支的结构化提示词，通过变量注入让模型在生成时自行选择对应分支的规则。
二、提示词的结构分层设计
推荐把提示词拆成四个稳定区域：全局角色区、端侧变量区、条件规则区、输出格式区。全局角色区定义模型身份和任务边界；端侧变量区声明可用的变量及取值；条件规则区针对不同变量值给出差异化指令；输出格式区约束最终产出的结构，保证下游程序可以稳定解析。
一个可用的骨架示例如下：
你是一名资深多端UI内容设计师。
【端侧变量】
target_platform: web | app | miniprogram
【全局规则】
- 文案必须准确，不得编造数据
- 输出为JSON格式
【条件规则】
当 target_platform = web 时：
- 标题不超过20字，正文段落每段不超过120字
- 可使用多列布局建议，信息密度可偏高
- 允许包含hover交互说明
当 target_platform = miniprogram 时：
- 标题不超过12字，正文每段不超过60字
- 仅建议纵向卡片布局，一屏不超过2个信息块
- 禁止出现hover相关描述，交互只用点按
- 按钮文案不超过4个字
当 target_platform = app 时：
- 标题不超过14字，正文每段不超过80字
- 布局建议需兼容iOS与Android的导航习惯
- 交互需区分单击、长按、下拉刷新
【输出格式】
{
"title": "...",
"blocks": [{"type": "...", "content": "..."}],
"interaction_notes": ["..."]
}这种写法的好处是维护成本低。当某个端的规范变化时，只需修改对应条件块，不影响其他端。而且条件规则用自然语言枚举，模型对这种结构的遵从度明显高于散落在段落里的零散要求。实测中，把规则按区域归拢后，格式错误率能下降一半以上，因为模型更容易定位“当前应该遵守哪一组约束”。
三、条件分支与组件映射表
光有文案长度约束还不够，涉及生成代码或组件描述时，需要一个组件映射表来防止模型输出端侧不存在的组件。做法是在提示词中显式声明三端组件的对应关系，并要求模型输出统一的中立描述，由下游转换层渲染成各端真实组件。
【组件映射表】 中立描述 | Web对应 | 小程序对应 | App对应 container | div | view | 原生ScrollView/Stack text | p/span | text | TextView image | img | image | ImageView button | button | button(open-type)| 原生Button list | ul/li | view + wx:for | RecyclerView input | input | input | EditText 【要求】 生成界面描述时，请使用"中立描述"列的组件名， 不要直接输出任何端特有的标签名。
这套映射机制的巧妙之处在于解耦。模型只负责产出语义正确的界面结构，不关心各端实现细节；转换逻辑由工程侧统一维护，映射表更新时不需要重新调试提示词。如果没有这层映射，直接让模型生成小程序代码，它大概率会混入HTML标签，因为训练语料中Web内容占比远高于小程序内容，这是模型偏置导致的典型错误。
另一个实践建议是在变量区加入屏幕宽度上下文，比如注入“当前目标宽度375逻辑像素”，模型对字号、每行字数的判断会明显更贴近真实效果。这类环境变量最好由程序在请求前动态拼接，而不是让调用方手填，避免人为遗漏。
四、输出校验与降级策略
即使提示词写得再严谨，模型偶尔越界也难以完全避免，所以工程侧必须有校验和降级。校验分两层：结构校验检查JSON是否可解析、字段是否齐全；内容校验检查文案长度是否超限、是否出现了禁用标签。以小程序端为例，可以用正则快速拦截HTML标签混入：
function validateMiniprogramOutput(result) {
// 结构校验
let data;
try {
data = JSON.parse(result);
} catch (e) {
return { ok: false, reason: "JSON解析失败" };
}
// 检查是否混入HTML标签
const htmlTagPattern = /<\/?(div|span|p|img|button|ul|li)\b/gi;
const serialized = JSON.stringify(data);
if (htmlTagPattern.test(serialized)) {
return { ok: false, reason: "输出中包含HTML标签" };
}
// 文案长度校验
if (data.title && data.title.length > 12) {
return { ok: false, reason: "标题超过12字" };
}
return { ok: true, data };
}校验失败后的处理策略建议分两级：轻度违规（比如标题超了两个字）做自动截断或本地重写，不重新请求，节省成本和时间；重度违规（结构错误或混入错误组件）携带错误原因回传给模型重试，提示词中追加一句“上次输出因某原因被拒绝，请修正”。这个反馈机制相当于轻量的自我修正循环，通常一次重试就能达标。
最后提醒一点，多端提示词要纳入版本管理，和代码一起评审发布。提示词的每次改动都可能同时影响三个端的产出质量，建立一套简单的回归用例集（每个端准备十个典型请求），在改动后跑一遍对比输出，可以避免“改好了小程序、弄坏了Web”这种隐蔽问题。多端适配不是一次性的设计动作，而是随着端规范演进的持续迭代过程。