1. 为什么第五个实验我选了天气模板而不是从零手写做到天猫精灵开放平台系列实验第五期的时候我已经不太想做那种新建技能、填死话术、测试通过就结束的流水账操作了。语音技能如果只停留在用户问一句、机器人答一句的阶段本质上和一张静态问答表没有区别。所以这一次我给自己定了两个硬指标第一必须有后端实时数据参与第二必须让结果呈现在带屏设备的屏幕上。按这个标准去翻平台模板天气查询模板几乎是唯一一个把所有环节都串起来的选项。先说结论这个模板的完成度比我想象中高得多。它不是给你一个空壳让你自己填逻辑而是直接给了一套能跑的完整链路——从用户的语音输入到意图解析、槽位填充再去请求天气数据源最后把结果同时变成一句播报文本和一个屏显页面。你要做的不是从零发明,而是理解这条链路里的每一个数据契约然后把模板替换成自己的东西。整个过程走下来我最大的感受是新手做带屏技能真没必要从空白工程开始模板就是最好的老师。这篇内容适合三类人正准备在天猫精灵开放平台上发布带屏技能但不知道从哪下手的开发者已经做过纯语音技能、想进一步了解屏显页面开发逻辑的进阶玩家以及那些手边正好有一台带屏音箱、想自己折腾一个看起来能用的技能的动手派。下面所有操作步骤和避坑经验都以我当时实验时的平台版本为准。平台更新迭代很快界面文字可能不完全一致但只要核心逻辑没变思路就都能套用。1.1 带屏技能和纯语音技能差的不是一块屏幕带屏语音技能和纯语音技能的交互链路乍看只差了一个页面展示,实际上对开发者提出的要求是成倍增加的。纯语音的闭环是用户说话平台解析意图技能后端返回一段文本音箱把文本读出来。带屏技能则变成用户说话平台解析意图技能后端返回结构化的JSON数据一部分数据用于生成语音播报另一部分数据被渲染成屏幕上的卡片、列表或图表。这一变化带来的直接问题是页面数据缺失时怎么兜底用户说下一页或者放大地图这类指令时页面要不要响应不同屏幕尺寸的设备上同一个页面会不会出现错位这些问题在纯语音技能里根本不存在但到了带屏技能里每一个都可能成为上线前的拦路虎。天气查询模板的优势恰恰是把这些最麻烦的页面部分用一套通用方案做好了。你要做的不是从零开发页面而是搞清楚模板页面的数据从哪来、需要什么格式然后把自己的数据源安全地接进去。1.2 为什么天气偏偏适合当模板天气几乎是所有语音助手的标配技能这一点不是偶然。它有几个天然适合做模板的特性信息时效性强用户对今天要不要带伞明天降温多少度有真实需求答案结构化城市、温度、天气现象、风级、湿度这些字段可以非常整齐地填进一个预设的页面框架交互模式清晰用户问天气时说的话通常都很直接意图和槽位都非常好提取。更重要的是天气数据天然适合可视化。温度可以映射成一个数字天气现象可以映射成太阳、云朵、雨滴图标空气质量可以映射成颜色等级。这些映射关系做出来之后页面不需要复杂设计用户一眼就能看到重点。平台选天气做模板实际上是在给你演示一个合格的带屏技能应该长什么样语音层有清晰的追问逻辑数据层有规范的结构展示层有直观的视觉表达。把这个模板吃透后面再做其他领域的带屏技能只是换数据源和换页面布局的问题。2. 动手前的平台准备账号资质、技能类型与模板入口这部分内容看起来基础但我发现不少人在最开始就卡住了。卡住的原因不是不会注册账号而是没搞清楚不同类型的技能分别用来做什么迷迷糊糊选了入口结果后面开发到一半发现能力不对。2.1 开发者账号与实名认证天猫精灵开放平台使用阿里账号体系登录个人开发者和企业开发者都能注册。注册本身不麻烦麻烦的是实名认证这步绕不过去。我当时用的是个人开发者身份实测个人主体也能发布带屏技能只是个别需要特殊资质的类目会有权限限制。天气这种高频生活类目不属于高危类目个人身份完全够用。这里有一个建议如果你想做的是带屏相关技能注册完之后先在平台设备管理或调试设备区域确认自己名下有没有可用的带屏设备。如果没有个人技能开发和测试会很别扭因为你只能依赖模拟器到不了真机验证这一步。市面上有很多带屏智能音箱型号按平台要求的绑定方式操作即可。2.2 技能类型先分清自定义技能与内容技能平台的技能类型划分里自定义技能和内容技能是最容易搞混的。这两者的本质区别我用一句话就能讲清楚自定义技能的核心是你提供一个后端服务平台把用户的语音请求转成结构化数据发给你再由你的服务决定返回什么内容内容技能则是把平台已经聚合好的内容源直接挂载到你的技能名下你不需要开发后端只需要做配置。做天气查询这种实时数据交互、又要自定义屏显页面的技能只能走自定义技能。我当时在控制台创建技能时选择自定义技能创建方式里再选使用模板创建之后才在模板库里找到了天气查询模板。如果你选错了入口进了内容技能的后台会发现根本没有页面渲染相关的配置项。2.3 找到模板并先跑一遍默认效果在模板市场里搜天气会看到不止一个结果。我选择的是名称里带有屏显标识的天气查询模板因为普通纯语音模板不包含页面部分选了等于白选。创建完成后平台会把模板自带的一套代码和配置复制到你的技能下其中包含交互模型、后端函数、页面模板文件。这一步我强烈建议先不要改任何东西直接在平台的模拟器里运行一遍默认技能。我当时跑完的第一反应是页面设计非常朴素但朴素恰恰说明模板把复杂度都封装掉了。默认技能会展示一句播报文案和一个完整的天气卡片页面包括城市名、温度、天气图标、湿度、风力。跑完这一遍你就有了一个基线认知:默认情况下这个技能是什么表现。后续你改了哪里、改得有没有问题拿这个基线一比就出来了。3. 把模板改造成自己的技能调用词、意图与槽位调整模板创建完成接下来才是真刀真枪的改造。我建议按固定顺序来先改技能信息和调用词再改交互模型里的意图和槽位最后动后端逻辑和页面。顺序一旦颠倒很容易出现后端已经改了但前端意图还没对上的混乱状态排查起来特别费力。3.1 技能名称与调用词设计技能名称是展示在技能市场里的正式名字要起一个用户一看就懂的名称我起的是每日天气助手。调用词决定了用户在天猫精灵上怎么唤起你的技能比如打开每日天气。平台对调用词有一套审核标准核心原则是不能设计成过于通用的日常短语避免和系统内置技能冲突。这里的经验是调用词不要太长用户在真实环境里说打开每日天气助手和打开每日天气识别成功率差距很大。我在实验里先把调用词定为打开每日天气测试发现用户更容易脱口而出的是查天气这样的短词但由于查天气太通用存在和系统技能撞车风险最后还是保留了带技能名的调用词这算是一种安全取舍。3.2 意图与槽位天气查询的核心是槽位填充模板自带的天气查询意图不同版本里的命名可能不一样有的叫QueryWeather有的叫SearchWeather功能大同小异。这个意图里最关键的是两个槽位城市槽位和日期槽位。城市槽位一般绑定系统预置的行政区划实体类型用户说上海天气怎么样平台能自动把上海识别成城市。日期槽位类似用户说明天后天周六平台会解析成标准日期表达。实际操作中我发现模板默认把城市设为必填、日期设为可选这个配置是合理的。如果日期也设成必填用户说上海天气怎么样时技能会追问请问你要查哪天的天气凭空多一轮对话体验反而变差。日期设为可选后后端会把缺省日期当成今天来处理用户在大多数场景下的表述都是一句指令直接命中目标。如果你想把天气技能做得更细还可以自己新增槽位比如穿衣建议紫外线强度等。但这会带来一个问题用户不说这些信息时槽位就是空的页面相应位置也会空着。我后来选择不在交互模型里新增这些槽位而是让后端根据天气数据自动生成穿衣提示放在返回字段里页面照常渲染。同样是多了一段信息后者对用户的语音表达没有任何额外要求。3.3 多轮追问与兜底话术在平台的交互模型配置里每个必填槽位都可以设置追问话术。模板默认的追问是请问查询哪个城市我改成了你要看哪个城市的天气呀。不要小看这句话语音交互和文字交互不一样用户听不到你温柔的目光注视只能靠话术的完整性和自然度来获得引导。改完之后我还顺手加了几个兜底回答用于用户反复不给出有效城市的场景。这里分享一个测试技巧在开放平台的对话测试工具里输入我不知道或者随便这类无效指令观察技能会不会死循环。好的兜底话术应该能在两轮追问之后主动结束对话并提示用户你可以换个方式说比如直接告诉我城市名。这个细节在产品文档里很少被强调但真实用户里真的会有人对着音箱说随便看看你要是没做兜底用户的体验就是技能突然沉默了。改完交互模型先用测试工具跑几组句子覆盖北京天气上海明天天气我不知道这三种典型输入。确认意图解析和槽位填充符合预期再进入后端与页面环节。4. 屏显页面背后的数据契约后端服务和页面渲染逻辑这个部分是整篇文章的核心也是我认为最容易让开发者一头雾水的地方。很多人以为屏显页面开发就是像写网页一样写一个静态页面然后和技能绑定就行。实际上完全不是这样屏显页面的内容不是写死的它跟随技能响应数据动态变化。理解这两者的关系是掌握带屏技能开发的分水岭。4.1 后端服务返回什么技能响应数据结构模板创建时平台会提供一个默认的后端服务你可以在网页端直接编辑简单的逻辑也可以把它替换成自己的HTTP服务。天气数据的获取模板默认接了一个第三方天气数据源拿到数据后模板后端会拼装成平台规定的技能响应格式。响应数据里除了纯文本的播报内容之外还有一块专门给屏显页面用的数据区域结构上是任意JSON。平台会把整块JSON传给前端页面页面根据自己的渲染逻辑决定哪些字段显示在哪。我当时拿到模板后没有急着改代码而是先把完整的返回结构打印出来看了一眼。简化后的结构大概是这样的{ outputSpeech: 上海今天多云气温25摄氏度东南风3级, display: { city: 上海, weather: 多云, temperature: 25, high: 28, low: 21, humidity: 60%, wind: 东南风3级, tips: 天气不错适合出门走走 } }这里outputSpeech是音箱播报的文案display是页面渲染要用的数据块。这个结构对后面所有改动都至关重要。如果你改了后端却没有保持返回字段结构的稳定屏幕上的天气卡片就会像被人抽掉了骨头东缺一块西缺一块。4.2 页面模板与数据绑定改样式和改数据是两回事天气查询模板自带的屏显页面是一个典型的天气卡片顶部是城市名和更新时间中间是大号温度和天气图标下方是湿度、风力、空气质量。这个页面是用HTML加平台提供的组件库写的模板已经预留好了渲染逻辑它会去读取上面那个JSON结构里的display字段。关键在于模板页面代码里有明确的数据绑定标记比如某个区块会绑定data[temperature]。你要做的是保证自己的后端返回结构里也有同名同结构的字段。如果你改了字段名页面不会蹦出任何报错提示而是直接在对应位置留下一片空白。这种静默失败是所有数据绑定类开发里最让人抓狂的问题因为整个链路看起来完全正常没有异常也没有崩溃只有你仔细盯屏幕才会发现少了内容。如果你嫌模板页面不好看想改成自己的风格可以直接修改页面的HTML和CSS。但这里有一个带屏设备特有的约束屏幕尺寸和普通手机网页完全不同页面宽度、字体大小、点击热区都需要重新适配。平台提供的组件库本身已经适配了不同设备的屏幕尺寸所以我建议优先用组件来拼页面不要自己用绝对定位乱写。自己写布局在模拟器上看着挺美到了真实设备上很容易出现边缘裁切、控件错位的问题。4.3 把默认数据源换成自己的天气数据源模板默认接的天气数据源在开发阶段用于验证链路完全够用。但如果你的目标是发布上线建议把数据源换成有稳定服务保障的天气数据服务商并且做一层后端适配。我实验的时候先用了模板默认数据源确认全链路没问题之后再申请了一个天气数据服务商的开发账号修改了后端请求地址和参数配置。换数据源时有个非常隐蔽的坑不同天气服务商的字段命名差异很大。同一个温度有的叫temp有的叫temperature天气状况有的返回中文文本有的返回气象代码甚至多云和阴这种相近的天气现象在不同数据源里的定义也不同。所以后端必须做一层适配转换把第三方数据源的原始返回重新映射成模板页面认识的结构。这一步没有技术含量但非常考验细心程度我当时因为没做阴天的映射导致页面连续几天把阴天显示成云朵图标用户看着就有点莫名其妙了。5. 联调阶段最容易踩的坑从模拟器到真机的体验落差模板开发完接下来是测试。我认为这个阶段才是整个实验里最有价值的环节因为只有到了真机测试这一步你才会真正理解带屏技能和带屏网页之间的区别。前者是声控优先的用户不会在屏幕上点来点去而是用嘴指挥页面变化。模拟器再方便也无法给你一个满状态的设备端体验更没法暴露那些藏在真实网络环境下的性能问题。5.1 模拟器能测什么测不了什么平台的模拟器可以完整测试语音对话链路、意图解析、槽位填充、后端请求和返回数据解析还能在右侧预览框里看到近似的屏显页面效果。对开发阶段的链路联调来说模拟器是完全够用的。但它再好用也只能算预览级的工具。模拟器无法反映真机上的画面渲染帧率、字体显示效果、页面滚动流畅度更模拟不出用户那种语音已经播报了但屏幕还在转圈的割裂感。我当时在模拟器上所有测试都是完美的页面显示也正常一度觉得可以提审了。结果真机上一跑发现首屏加载明显偏慢——用户说完打开每日天气音箱都开始播报了屏幕上的内容还在加载动画里打转。这种体验问题模拟器几乎不可能暴露出来因为模拟器的网络环境和渲染环境都太理想了。5.2 真机测试的具体操作真机测试需要在开放平台后台绑定带屏设备。大致流程是在设备调试配置区域添加测试设备然后在带屏音箱上登录同一个账号在调试模式下打开你的测试版本技能。注意要用测试版本地址不要用线上正式版否则你可能测着测着把线上流量也带进来了。测试时建议准备一套覆盖边界场景的指令集。我当时的指令集包括只说城市名的短句北京天气、带日期和城市的长句上海明天天气怎么样、查询不支持的城市三四线小地方有时不在库、查询一个完全不存在的城市。这几类在我测试时都出现了不同程度的槽位解析失败但原因各不相同。有的是语音识别就把地名听错了有的是地理实体库里确实没有这个地区还有的是用户口音问题导致识别结果反复横跳。针对最后一种情况我在意图配置里补充了同义词和说法模板效果才有所改善。5.3 几个典型的真机问题及排查方法踩坑踩多了之后我整理了一张排查参考表给后面做带屏技能的朋友省点时间现象可能原因排查方向真机屏幕不显示页面技能类型或设备端版本不支持该页面方案检查设备固件版本、技能配置里的设备形态页面显示了但数据空白后端返回字段与页面数据绑定不一致逐项对比模板返回JSON结构与页面引用字段语音播报和页面内容对不上播报文案与页面数据来自不同的逻辑分支统一两者都从同一个后端函数返回说打开技能后没有任何反应调用词冲突或技能未绑定测试设备检查调用词是否重复、设备是否绑定测试版本首屏加载明显偏慢后端服务响应慢或页面资源过大查看平台日志中的响应耗时优化后端接口逻辑这些坑我几乎全踩了一遍。其中最让人抓狂的是页面显示了但数据空白因为链路整体不报错、不走异常分支你只能一个个字段去比对最后发现是返回JSON里一个单词的大小写和页面绑定不一致。这个教训让我养成了一个习惯每次改后端返回结构第一件事就是去页面模板里搜索对应的绑定字段是不是完全一致。6. 提审发布与上线后的观察实验的终点是另一个起点如果只是做实验前面的步骤已经足够让你跑通一个完整的带屏天气技能。但如果你想把技能发布到技能市场后面还有一段流程要走。我把提审阶段的心得也一并分享这部分内容在实际开发中经常被忽略但恰恰是决定一个技能能不能落地的关键。6.1 提交审核前的自查清单提交审核时平台会让你填写技能描述、隐私说明、调用词说明、测试账号备注等材料。我当时因为技能描述里没有写明需要带屏设备才能完整体验被驳回了一次所以这块流程不复杂但很容易因为粗心造成反复。几个自查点我列一下调用词是否明显区别于系统内置技能技能描述里是否如实写清楚数据来源和功能边界隐私说明是否覆盖了用户位置和城市信息的处理方式页面展示内容与语音播报内容是否保持一致。最后一点尤其重要审核人员会专门核对如果语音说晴而页面显示多云大概率会被打回。这些细节在开发时很容易被忽略因为你自己测试时往往只关注有没有结果而审核人员关注的是结果是否准确一致。6.2 上线后的数据观察与迭代技能发布后开放平台的数据统计后台可以看到调用量、用户留存、意图命中率、槽位填充率这些指标。我第一次发布后观察到的现象有点打击人大量用户直接对音箱说天气怎么样而不是先打开每日天气再查询导致我的技能根本没被唤醒。这说明我精心设计的调用词虽然通过了审核却不符合真实用户的使用习惯。后来我做了两个方向的迭代一是扩充说法模板和近义表达尽可能让技能在用户不按固定句式说话时也能被正确理解二是在页面展示上加了空气质量板块因为我在数据观察里发现用户反复查询明天天气的比例挺高意味着他们对空气质量和通勤建议有强需求。做带屏技能的一个乐趣就是语音层和页面层可以分别迭代优化你总能在数据里找到一个小点去改进。6.3 一个实验做完之后的理解回到最开始的问题用一个天气模板做带屏技能到底值不值我的答案是非常值。这个实验的价值不在于做出来的技能本身有多复杂而在于它把语音识别、语义理解、后端服务、前端页面、设备适配这条完整链路压缩在一个项目里让新手能用最短的时间建立对带屏技能开发的全景认识。做这个实验之前我对屏显页面的理解只是一个好看的界面做完之后我才明白页面只是链条的最后一环前面的每一个环节都会影响它在屏幕上的表现。我建议你做完这个实验后不要急着把项目删掉。试试把模板页面改造成其他场景比如查课表、查社区活动、查限行尾号思路会一下子打开。技能开发的核心能力不是手写某一段代码而是把用户一句随口的诉求变成屏幕上看得见、听得着的完整反馈。这套能力一旦建立你做任何领域的带屏技能起步速度都会快很多。