PHASE 1 当前重点
精准控制
用户通过少轮对话，找到正确设备，完成控制，并获得明确可信的执行结果。
01
三期推演: 从精准控制走向全生命周期服务
三期不是三套独立系统，而是在同一套设备、能力、追踪和结果底座上逐步扩大用户价值。
PHASE 2
服务与联动
从单设备扩展到多设备联动、Service ID 调用设备，以及设备事件主动触发服务。
PHASE 3
配网与售后
向前覆盖设备入网与授权，向后覆盖故障诊断、工单创建和服务履约。
一期必须沉淀的公共底座
一期先回答三个问题：用户有哪些设备、设备属于什么品类、能够提供哪些能力。在此基础上，二期的服务联动和三期的配网、售后都可以直接复用并继续扩展。
02
一期定义: “精准”解决找谁，“控制”解决怎么做
一期不以 GUI 或 MCP 为起点，而以用户最终是否完成一次可靠控制为判断标准。
精准
从用户账号中找对那一台设备
完成授权设备清单获取、Device ID 定位和 Capability 校验。多设备时可澄清，不允许猜测。
控制
通过合适通道执行，并确认真实结果
GUI 和 MCP 只是两种执行方式。平台统一输入、追踪和结果语义，通道差异只留在执行与确认环节。
一期成功标准:
对一个已授权、能力已声明的设备，用户通过一次或少轮对话即可完成控制。平台能说明控制对象、执行动作和最终状态。
03
一期用户链路: 八个节点组成最小闭环
每个节点都要有明确动作和产物。只有第 6、7 步因 GUI 与 MCP 不同而分叉，其余环节共用。
01
用户 Query
小微理解用户想控制什么、目标设备线索是什么、动作参数是什么，例如“把卧室空调调到 24 度”。
关键产物意图、设备线索、Capability、参数
02
生成 Trace ID
为一次用户诉求生成全链路标识。后续设备定位、能力校验、执行请求和结果回传都挂在同一个 Trace 下。
关键产物trace_id
03
获取授权设备清单
用户进入 Query 对话框时，平台即基于 UIN 向品牌拉取授权 Device ID 集合。用户提交 Query 后优先复用对话框内已经返回的清单。
关键产物授权设备集合、更新时间、数据来源
04
定位 Device ID
用设备名称、品类、房间、别名等线索匹配具体设备。唯一命中直接执行，多台命中继续缩小范围，仍不唯一则向用户澄清。
关键产物device_id、category、匹配置信度
05
校验 Capability
确认该设备所属品类是否支持目标 Capability 及参数范围。不支持的诉求无需传给品牌云，平台直接给出明确反馈。
关键产物是否支持、Capability 编码、合法参数
06
发起执行
GUI: 打开目标设备页面或触发页面语义能力。
MCP: 调用 Skill Capability，并传递设备、能力编码、参数和幂等标识。
分叉节点GUI 页面调用 / MCP 原子调用
07
确认结果
GUI: 读取页面最终状态，但必须确认页面状态代表设备已执行。
MCP: 接收同步结果、异步回调或主动查询操作状态。
分叉节点页面可信状态 / 品牌云结果协议
08
反馈用户
将两种通道的结果统一为成功、失败、执行中、不支持、超时或未知，并用一句话或卡片给用户明确反馈。
关键产物统一状态、用户文案、可选下一步
核心判断: 这套最小闭环不会限制 GUI 或 MCP 的实际调用方式。它只统一调用前必须知道什么，以及调用后必须返回什么。
放进真实语境: 两个 Query 如何经过同一条链路
正常请求会完成设备控制，不支持的请求会在 Capability 校验处提前终止，避免无效调用设备。
链路节点
示例一 · 正常控制
“我想开客厅的空调”
示例二 · 不支持的诉求
“我想让我客厅的空调飞起来”
01 · 理解 Query
识别目标位置为“客厅”、品类为“空调”，目标 Capability 为“开机”。
识别目标位置为“客厅”、品类为“空调”，目标 Capability 为“飞行”。
02 · 生成 Trace ID
为本次“打开空调”的用户诉求生成唯一 Trace ID。
同样生成 Trace ID，后续可以追踪请求为什么没有进入设备执行。
03 · 获取设备清单
用户进入对话框时清单已经开始拉取，提交 Query 后发现用户有一台“客厅空调”。
复用对话框内返回的同一份设备清单，发现用户确实有一台“客厅空调”。
04 · 定位 Device ID
通过“客厅 + 空调”唯一定位到 Device ID: AC-LIVING-01。
同样可以准确定位到 Device ID: AC-LIVING-01，说明设备定位本身没有问题。
05 · 校验 Capability
空调品类的基础 Capability 集支持“开机”，参数合法，校验通过。继续执行
空调品类的 Capability 集中没有“飞行”。返回 unsupported，不进入设备侧
06 · 发起执行
GUI 打开对应设备页面并触发“开机”，或 MCP 调用该设备的“开机” Capability。
不发起 GUI 或 MCP 调用，也不把无效请求传给品牌云。
07 · 确认结果
GUI 页面返回设备已开机，或 MCP 回传 succeeded，平台确认真实结果。
无需等待设备结果。平台将“不支持”作为本次请求的明确结果。
08 · 反馈用户
反馈“客厅空调已打开”。控制完成
反馈“客厅空调不支持飞行，你可以让我开关空调或调节温度”。给出可执行建议
04
精准第一步: 授权与设备清单必须前置
当前已有部分核心商家具备设备清单接口，平台正在统一字段和回传规则。下一步重点是确认授权机制、同步时效和多设备定位规则。
进入 Query 对话框时拉取设备清单
用户进入小微 Query 对话框时，平台立即向品牌拉取授权设备清单。清单准备与用户输入同步进行，不等用户提交 Query 后才开始查询。
- 提前启动清单获取，缩短 Query 后等待
- 需要定义清单有效期和接口超时
- 超时后需给出明确 loading 或兜底反馈
授权后持续同步，进入对话框时校验
后续可在用户完成授权后持续同步设备清单，进入 Query 对话框时先读取已有清单，再按更新时间决定是否向品牌刷新。
- 进一步降低品牌接口对实时体验的影响
- 保留进入对话框时的增量刷新能力
- 支持用户查看、撤销和重新授权
一期建议口径
用户开通小微时完成设备数据授权，进入 Query 对话框后平台开始拉取授权设备清单。授权目的、数据范围、使用方式和撤回入口可纳入小微隐私说明与用户协议，最终需法务和隐私评审确认。
05
精准第二步: 一期先统一 Category 的 Capability 底线
一期先保证每个品类最应该支持的能力可用，不拆分型号差异。设备定位仍遵循最小原则，从 UIN 的授权设备集合中找到唯一 Device ID。
全文统一使用 Capability
Capability 表示平台可以调用的一项完整设备能力，包含能力编码、参数范围和结果定义。执行指令被收敛为 Capability 的内部实现，不再作为独立概念提供给商家。
UIN
当前用户
当前用户
→
授权 Device ID 集合
用户可控制的设备
用户可控制的设备
→
唯一 Device ID
本次控制对象
本次控制对象
唯一命中
直接进入能力校验和执行。
多台命中
用名称、品类、房间、别名继续缩小范围。
仍不唯一
向用户询问，不允许平台猜测。
一期 · Category
Capability 集由平台统一维护，商家从平台清单中选择并完成接入。不同品类有各自的必选 Capability，例如空调可包含查询设备、开关、调模式，具体以平台为该品类制定的准入要求为准。
平台定底线，商家选择实现
一期 · Device ID
Device ID 负责定位用户具体要控制的设备实例，并执行该品类已经通过准入的基础 Capability。
Device ID 负责定位与执行
二期 · Model ID
一个 Category 下可新增多个设备型号。商家填写型号名称，平台生成 Model ID，再逐步支持不同型号的差异 Capability。
二期再扩展型号差异
06
控制分叉: GUI 与 MCP 共用闭环，只在执行和确认处不同
用户链路仍兼容 GUI 与 MCP 两种通道。一期新增商家接入只要求完成 MCP 操作，GUI 沿用已有页面能力，不纳入本期 B 端建设范围。
GUI 通道
页面承载执行
怎么调用
通过设备深链打开指定页面，或触发已约定的页面语义能力。应携带 Trace、Device 和 Capability 上下文。
怎么确认
读取页面展示的最终状态。页面需明确区分“已发起”“执行中”“设备已确认”和“执行失败”。
平台约束
按钮或控件可识别、目标设备可确认、状态变化可读取、异常页面有统一返回方式。
页面显示“已关闭”只有在商家保证它来自设备或品牌云确认时，才能作为真实结果。仅在前端改了按钮状态，不算设备执行成功。
MCP 通道
Skill 承载执行
怎么调用
调用原子化 Skill Capability，传入设备、能力编码、参数和 idempotency_key。优先使用 setPower，不使用含义不稳定的 toggle。
怎么确认
同步返回受理结果，异步回传最终状态，或通过 operation_id 主动查询。不能把“已受理”当成“已执行”。
平台约束
统一 Capability 命名、参数 Schema、错误码、鉴权、链路字段、幂等、超时和安全重试规则。
Skill 描述应按品类拆分、按需加载并减少重复说明。字符上限只是技术边界，不应成为目标体量，需用选择准确率和 P95 推理时延验证优化效果。
统一结果出口
executing 执行中
succeeded 成功
failed 失败
unsupported 不支持
timeout 超时
unknown 未知
07
商家接入: 一期只完成品类 Capability 与 MCP 闭环
Capability 由平台统一维护。商家选择接入品类，确认必选能力，并完成对应的 MCP 操作和评测，无需在一期填写 Model ID。
STEP 01
选择品类
选择空调、灯、扫地机器人等平台标准 Category。
STEP 02
平台下发 Capability 集
平台展示该品类的统一能力集，并标记该品类必须实现的 Capability。
STEP 03
选择 Capability
必选能力不可取消，商家可继续选择该品类支持的其他可选能力。
STEP 04
完成 MCP 操作
为所选 Capability 配置 MCP 调用、参数和结果回传。
STEP 05
生成并完成评测
系统按本次选择的 Capability，逐项生成品类基础评测内容。
B 端申请必须填写的字段
一期字段只回答“接入什么品类、选择哪些平台能力、MCP 如何执行和回传结果”。
Category
选择平台标准品类。选择后，系统自动加载该品类的统一 Capability 集、必选项和参数模板。
必填 · 单选
Capability 选择
Capability 由平台维护。商家必须选择平台针对该品类标记的必选项，并可按需选择其他可选能力。
必填 · 多选
MCP 操作配置
为每项已选 Capability 配置对应的 MCP 操作、参数 Schema、鉴权方式和调用地址。
必填 · 按能力
结果确认方式
说明成功、失败、执行中的判断标准，以及同步返回、异步回调或状态查询的对应字段。
必填 · 按能力
平台维护 Capability
平台统一定义每个品类可选择的能力、参数模板和结果要求，商家不自行新增名称。
一期只做最低能力
不同品类分别设置最低 Capability，商家需完成当前 Category 对应的必选项，而不是使用一套跨品类固定清单。
商家完成 MCP 操作
商家只需把已选择的 Capability 通过 MCP 跑通，并返回平台规定的执行结果。
二期再引入 Model ID
二期支持在一个 Category 下填写多个设备型号。商家只填写型号名称和必要信息，由平台生成 Model ID，再逐步支持不同型号的差异 Capability 与评测。
评测结果分三层回传
每个申请的 Capability 都应形成对应评测项，并逐层提高对真实能力的确认强度。
LAYER 01
云端接口评测
校验 Capability 调用、参数合法性、结果状态、异常码和回调链路，先确认协议能跑通。
LAYER 02
功能视频举证
商家按品类标准用例录制设备真实响应，视频需同时展示用户操作、设备动作和最终结果。
LAYER 03
寄送样机实测
针对重点品类或高风险 Capability 寄送代表样机，由平台验证线上结果与设备真实表现一致。
平台负责
- 维护品类统一 Capability 集和准入必选项
- 为不同 Category 分别制定必选 Capability
- 自动生成品类 Capability 评测用例
- 完成云端校验、材料审核和样机验证
商家负责
- 选择接入 Category 和平台 Capability
- 完成所选 Capability 的 MCP 操作配置
- 按平台协议回传真实执行结果
- 提供云端环境、功能视频和代表样机
最终结论
一期先统一品类级 Capability 底线，并通过 MCP 跑通商家接入与结果闭环。
平台按 Category 统一维护基础 Capability 与准入必选项，商家选择并完成 MCP 操作。二期再引入平台生成的 Model ID，扩展一个品类下的多型号与差异能力。