一、场景痛点与需求分析

先说说医院导诊台那个画面：护士小姐姐一天要被问几百遍“XX科室怎么走”，口干舌燥不说，还容易耽误正事儿。患者呢？拿着挂号单一脸懵，楼上楼下乱转。

那咱们的解决思路挺直接的——把语音播报能力交给系统自动触发。患者在自助机取号或挂号时，系统自动让附近的音箱“开口说话”，告诉患者去哪、找谁。

20W的功率在医院走廊、大厅这种半开放环境，音量够用。关键是它走HTTP接口，意味着你的软件项目（不管是Web、小程序还是后台系统）发个请求就能让它说话。

二、硬件与接口基础认知

2.1 设备长啥样

这款20W智能语音壁挂音箱有几个关键特点

• 联网方式：有线以太网 + 无线WiFi双保险，医院网络环境复杂，两条腿走路稳当

• 音频支持：支持音频播放（基础版有的不支持，这个款支持）

• 安装：壁挂式，175mm宽×175mm长×90mm厚，不占地儿

• 核心能力：不用上传录音，不用后台预设，直接HTTP推文本就播报

2.2 接口调用核心逻辑

芯步的开放接口走的是标准HTTP，签名校验有点儿小讲究

请求地址

签名算法（稍微绕了一下，但照抄就行）：

——也就是说：把你的AppSecret先MD5一次，然后拼上当前时间戳ts，整个再MD5一次。

请求体

三、逐步对接实战

3.1 前期准备

先去芯步开放平台注册一个开发者账号，拿到：

• AppID：你的应用标识

• AppSecret：你的密钥（别乱给人，也别写死在代码里）

然后在控制台添加设备，拿到每个音箱的device（设备ID）。如果是一层楼装好几个，可以按位置命名管理。

3.2 下发播报命令

最常用的命令就是让音箱开口说话：

那冒号后面的16是什么？是语速，范围0-9。5是中间值，医院场景6-7，清晰、不拖沓。

完整调用示例（伪代码思路）

3.3 控制音量和音色

医院场景有噪音，音量得够。拿到设备后先调一次音量，让它固定在一个合适值：

音色可以选女声（0）或男声（1），一般导诊用女声更亲切：

：设备上电后先发一组配置命令，设好音量和音色，之后再只发播报命令就行。

3.4 多设备同时控制

如果导诊台左右各挂一个音箱，或者走廊上每隔一段装一个，想同时播报？device参数支持逗号分隔：

3.5 查询设备状态

下发命令前想确认一下设备在线不？调获取设备详情接口

返回里看online.status，1是在线，0是离线。另外还能看到信号强度、IP地址这些信息，方便排查问题。

四、集成到不同软件项目的方案

4.1 Web端（H5/管理后台）

浏览器不能直接调用API（跨域、密钥暴露问题），所以得走后端中转。

流程：前端点按钮 → 调你自己的后端接口 → 后端去调芯步API → 音箱播报。

4.2 医院自助机终端

自助机一般跑Windows或Android，可以直接发HTTP请求。适合场景：患者取号成功后，自助机发指令让附近的音箱播报指引。

注意：签名密钥放自助机上有泄露风险，还是走一个小型后端代理。

4.3 排队叫号系统对接

这是最核心的应用场景。叫号系统叫到某个患者时，同步触发音箱播报：

因为音箱走HTTP，播报指令是即发的，基本感觉不到延迟。

4.4 低代码/SaaS平台接入

很多医院用简道云、明道云之类的低代码平台做流程管理。这些平台一般支持“Webhook”或“HTTP请求”节点，可以直接配置调用芯步API，甚至不需要写代码。

五、医院场景实战

5.1 导诊台标准话术设计

播报文本要短、清晰、信息完整。举个例子：

❌ “那个，内科的话往这边走然后左拐再右拐” ——太长，记不住✅ “内科门诊，请前方直行20米，左侧” ——20字以内，一步一指引

几种典型话术模板

技术提示：命令里的文本用GBK编码（play:gbk:16里写明了），中文没问题。文本最长50个字符以内，超过可能播不完或被截断。

5.2 部署位置

20W功率，实测在50-100平米范围内清晰可闻。部署时注意：

• 导诊台正上方：装一个，覆盖挂号/咨询区域

• 走廊转角：如果医院走廊是L型或T型，转角处需要补一个

• 分诊台：各科室分诊台独立装一个，做科室级语音指引

5.3 错误处理

接口调用可能失败的情况：

1. 设备离线：API会返回非200状态码，你得捕获异常并记录日志，同时给出备选方案（比如让护士手动引导）

2. 签名过期ts时间戳是秒级，服务器时间误差太大会验签失败，确保服务器时间同步

3. 文本过长：超过限制会被截断甚至不播，前端做长度校验

六、一句话总结

芯步这个20W音箱对接的核心就三步：拿AppID和密钥 → 算签名 → POST请求带device和order。集成到导诊系统里，相当于给你的软件装上了一张“能说话的嘴”，患者问路这件事儿，交给代码自动触发就行。