机务段现场语音作业助手 —— 设计方案 V1.0
- 编制日期:2026-10-22
- 状态:方案设计稿,用于评审;设备型号、性能指标待样机与现场实测确认
- 输入材料:《工业智能随身作业盒完整技术方案 V1.0》(下称"作业盒方案")、《DMR 数字对讲机 AI 个呼语音交互系统》(下称"DMR 方案")
0. 结论先行
定一套方案:安卓三防 PTT 终端 + 有线 PTT 肩咪 / 单耳耳机 + 段内部署的语音业务网关。
| 层 | 选定 | 一句话理由 |
|---|---|---|
| 终端 | 带实体 PTT 键的安卓三防终端(可选带扫码头) | 现成工业设备,三防、换电、WiFi+4G、蓝牙都有,只需写 App |
| 拾音/放音 | 有线 PTT 肩咪 + 单耳耳机(默认);蓝牙 PTT 肩咪(试点后可选) | 有线不配对、不充电、无 HFP 窄带问题;肩咪上的 PTT 键戴手套也能按 |
| 网络 | 段内 WiFi 优先,4G 专用 APN/VPN 兜底 | 不出段内网;检修库外也能用 |
| 服务端 | 段内机房部署:语音网关 + 流式 ASR(热词)+ 意图引擎 + 业务适配 + TTS + 审计 | 一套服务端,后续 DMR、作业盒都通过适配器接入,不重做 |
| 交互 | 按住说话;查询直接答;写操作复述确认后才落库 | 噪声环境不用唤醒词;识别必然有错,写操作必须人确认 |
为什么不直接选两份原方案之一:
- DMR 方案路线 A(开源 dmrtc + SDR + AMBE+2)的 5 个 P0 风险都卡在授权和无线电合规上,且 DMR 声码器是 8kHz 窄带有损压缩,专名识别会更难。它适合"全段大范围无 WiFi 覆盖"的诉求,不适合作为首选。
- 作业盒方案的单 ESP32 同时跑 HFP + BLE + WiFi 是已知高风险点,定制耳机依赖耳机 SoC 厂商开放 SDK,整体 76–196 万、28 周。它要解决的语音 + 扫码 + BLE + WiFi + 三防,安卓三防终端已经现成具备。
两份方案都没有作废:服务端统一设计,DMR 路线 B(厂商中继 + 授权个呼接口)和作业盒都作为后续"终端适配器"接入,见第 11 章。
1. 目标与边界
1.1 要解决的问题
作业人员在检修、整备现场,不离开工位、不摘手套,通过语音完成:
- 查询:检修任务、检修记录、机车故障、配件库存、作业流程等,服务端用语音回答;
- 提报:提票(故障提报)、作业记录等写操作,经复述确认后写入业务系统。
1.2 首版范围
| V1 纳入 | V1 不纳入 |
|---|---|
| PTT 按住说话、松开识别 | 唤醒词、持续监听 |
| 查询类意图(只读) | 修改工单状态、推进工步、质量放行 |
| 提票类写操作(必须复述确认) | 任何以语音为唯一依据的安全控制 |
| 屏幕同步显示识别文本和回答 | 视频、定位、BLE 量具(留作扩展) |
| 段内 WiFi + 4G 专用 APN | 公网云服务 |
| 录音、转写、调用、确认结果全量审计 | 凭声音识别人员身份 |
1.3 设计原则
- **语音是辅助入口,不是控制手段。**安全卡控、质量放行仍走既有流程(与作业盒方案 3.2、DMR 方案 6.2 一致)。
- **终端做薄。**终端只负责采集、播放、PTT 和显示;意图、权限、业务规则全在服务端。
- **写操作双重确认。**服务端复述关键字段,人明确说"确认"或按确认键才落库。
- **服务端只做一套。**终端差异全部压在适配层。
- **不出段内网。**语音、文本、业务数据均不经过公网。
2. 总体架构
┌──────────── 现场 ────────────┐ ┌─────────────────── 段内机房 ───────────────────┐
│ │ │ │
│ PTT 肩咪 / 单耳耳机 │ │ ┌──────────────┐ │
│ │ 有线 │ │ │ 终端适配层 │ App 适配器(V1) │
│ 安卓三防终端 + 作业助手 App │─WiFi──►│ │ │ DMR 适配器(扩展) │
│ · PTT 采集 / Opus 编码 │ 或 4G │ │ │ 作业盒适配器(扩展) │
│ · 播放 / 屏显 / 确认键 │ APN │ └──────┬───────┘ │
│ │ TLS │ ▼ │
└──────────────────────────────┘ │ ┌──────────────┐ ┌──────────┐ │
│ │ 会话与对话管理 │◄─►│ 流式 ASR │ 热词表 │
│ │ (状态机) │ └──────────┘ │
│ │ │ ┌──────────┐ │
│ │ │◄─►│ 意图引擎 │ 意图/槽位定义 │
│ │ │ └──────────┘ │
│ │ │ ┌──────────┐ ┌─────────┐ │
│ │ │◄─►│ 业务适配 │──►│MIMS/MESS│ │
│ │ │ └──────────┘ │知识库等 │ │
│ │ │ ┌──────────┐ └─────────┘ │
│ │ │◄─►│ TTS │ │
│ └──────┬───────┘ └──────────┘ │
│ ▼ │
│ 审计库(录音、转写、意图、调用、确认) │
│ 管理后台(终端、人员绑定、热词、意图、报表) │
└────────────────────────────────────────────────┘
2.1 组件职责
| 组件 | 职责 | 建议实现 |
|---|---|---|
| 作业助手 App | PTT 录音、Opus 编码上传、播放、屏显、确认键、登录绑定、离线提示音 | Android 原生(Kotlin) |
| 终端适配层 | 按终端协议收发音频,统一转换为内部 PCM 16kHz 单声道 | 与语音网关同进程,按终端类型插件化 |
| 会话与对话管理 | 会话状态机、多轮追问、确认流程、超时、打断 | Python(FastAPI + WebSocket) |
| 流式 ASR | 边说边出字,松开 PTT 后给最终结果;支持热词 | 本地部署、支持模型级热词的中文流式模型 |
| 意图引擎 | 意图分类、槽位抽取、槽位规范化、缺槽追问 | 规则 + 大模型函数调用,见第 6 章 |
| 业务适配 | 调用既有业务系统,做权限检查,结果转成适合播报的短句 | 每个业务系统一个适配器 |
| TTS | 回答文本转语音,按句流式输出 | 本地部署的中文 TTS |
| 审计库 | 全链路留痕,供追溯、统计和识别优化 | PostgreSQL + 对象存储(录音) |
| 管理后台 | 终端/人员绑定、热词和意图维护、使用报表、审计查询 | 复用既有 Spring Boot / JeecgBoot 后台 |
3. 终端与配件
3.1 终端:带 PTT 的安卓三防终端
不锁定品牌型号,按下表要求询价选型,P0 阶段取 2–3 款样机实测后定型。
| 项目 | 要求 | 必验/参考 |
|---|---|---|
| 系统 | Android 11 及以上,允许安装第三方 APK,可设置为专用模式(Kiosk) | 必验 |
| PTT | 机身实体 PTT 键,向 App 暴露按下/松开两个独立事件(广播或按键码) | 必验 |
| 外接音频 | 支持有线肩咪,肩咪上的 PTT 键同样能被 App 收到 | 必验 |
| 网络 | WiFi 5(2.4/5GHz)+ 4G,支持专用 APN 或 VPN | 必验 |
| 蓝牙 | 5.0 及以上(为蓝牙肩咪和后续 BLE 量具预留) | 参考 |
| 防护 | IP65 及以上,1.2m 以上跌落 | 参考 |
| 电池 | 可拆卸更换,满足一个班次 | 实测 |
| 扫码头 | 可选;需要扫码确认的场景再选带扫码头的型号 | 按需 |
| 管理 | 支持 MDM 或厂商管理平台,可批量安装和升级 App | 参考 |
| 现场规定 | 符合段安全科对现场无线终端的要求;如有防爆区域单独评估 | 必验 |
段里如果已经配发安卓现场作业记录仪或 PoC 对讲终端,先按上表核对,能满足"可装 APK + PTT 事件可读"即可直接复用。
3.2 拾音与放音:有线 PTT 肩咪 + 单耳耳机
默认方案:有线 PTT 肩咪,肩咪上接单耳空气导管耳机或骨传导耳机。
- 肩咪夹在肩部或领口,麦克风离嘴近,比终端自带麦克风抗噪好;
- 肩咪上的大 PTT 键戴手套可操作;
- 单耳佩戴,另一只耳朵保持对环境警示声的感知;需兼容安全帽;
- 有线连接:不配对、不充电、不受蓝牙通话协议的窄带限制。
**可选方案:蓝牙 PTT 肩咪。**市面上有面向 PoC 对讲的蓝牙肩咪,PTT 键通过 BLE 或 SPP 上报。蓝牙通话音频走 HFP,P0 阶段与有线方案做识别准确率对比后再决定是否放开。
**不选:**入耳式消费级蓝牙耳机(挡环境声、与安全帽冲突、按键不能区分按下/松开)。
3.3 P0 选型实测项
| 编号 | 实测项 | 通过标准 |
|---|---|---|
| D1 | 机身 PTT 和肩咪 PTT 的按下/松开事件 | App 能稳定区分,连按、长按、锁屏下均可用 |
| D2 | 有线肩咪录音 | 16kHz 单声道可录,增益可调,无明显底噪 |
| D3 | 现场噪声下识别 | 用现场录音测试集对比各款终端和配件,见 7.2 |
| D4 | 网络切换 | WiFi 和 4G 切换时会话不丢、App 自动重连 |
| D5 | 续航 | 按真实使用频率模拟一个班次,记录电量曲线 |
| D6 | 专用模式 | App 开机自启、不被系统杀后台、可锁定为单一应用 |
4. 作业助手 App
4.1 界面
一个主界面,大字号、高对比,戴手套可操作:
┌──────────────────────────────┐
│ 高压组 · 张三 WiFi ▂▄▆ 🔋 │
├──────────────────────────────┤
│ 你:查询和谐电一1901的近期故障 │
│ │
│ 助手:1901 近 3 个月有 2 条故│
│ 障。第一条,10 月 15 日,主断 │
│ 路器…… │
├──────────────────────────────┤
│ [ 重播 ] [ 取消 ] [ 确认 ] │
│ │
│ ( 按住 PTT 说话 ) │
└──────────────────────────────┘
- 识别文本实时显示,人可以边说边看对不对;
- 写操作待确认时,"确认"键高亮,屏幕列出要提交的字段;
- 状态用颜色和提示音同时提示:录音中、处理中、播放中、出错。
4.2 状态机
IDLE ──PTT按下──► RECORDING ──PTT松开──► WAITING ──收到回答──► PLAYING ──播完──► IDLE
▲ │ │ │
│ 超过最长时长 超时/出错 PTT按下(打断)
│ 自动结束 │ │
│ ▼ ▼ ▼
└──────────── 提示音 + 回 IDLE ◄────────┘ 停止播放 → RECORDING
CONFIRMING:服务端发起确认请求时进入;说"确认"/按确认键 → 提交;说"取消"/按取消键/超时 → 放弃
- 打断:播放中按下 PTT,立即停止播放并开始新一轮录音,同时通知服务端取消当前回答。
- 最长录音时长:可配置(建议初值 30 秒),超时自动结束并提示。
- 断网:PTT 按下时若无连接,播放本地提示音"网络未连接",不录音。
4.3 音频参数
| 方向 | 格式 |
|---|---|
| 上行 | 16kHz、单声道、16 bit 采集 → Opus 编码,每帧 60ms |
| 下行 | 服务端 TTS 按句合成 → Opus 编码下发 → App 解码播放 |
4.4 登录与绑定
- 作业人员用工号登录(或刷工卡、扫工牌二维码,按段里现有身份体系定);
- 服务端记录"终端 ID ↔ 工号 ↔ 班组 ↔ 领用时间",以此确定提问人,而不是凭声音判断(与 DMR 方案 4.1 的原则一致);
- 换班时登出,终端可交接给下一人。
5. 通信协议
终端与服务端之间:WebSocket over TLS,文本帧传 JSON 控制消息,二进制帧传 Opus 音频。
5.1 连接
wss://<段内服务器>/ws/terminal
Header: Authorization: Bearer <终端令牌>
X-Terminal-Id: <终端 ID>
连接建立后双方交换 hello,服务端返回会话参数(音频格式、心跳间隔、最长录音时长)。
5.2 消息定义
终端 → 服务端
| type | 说明 | 主要字段 |
|---|---|---|
hello | 连接握手 | terminalId、appVersion、audio(格式参数) |
ptt_start | 按下 PTT,开始一轮 | turnId(终端生成的 UUID)、ts |
| (二进制) | Opus 音频帧 | 帧头带 turnId 和序号 seq |
ptt_end | 松开 PTT | turnId、ts、frames(总帧数) |
confirm | 确认或取消写操作 | confirmId、decision:accept / reject |
cancel | 打断当前回答 | turnId |
ping | 心跳 | — |
服务端 → 终端
| type | 说明 | 主要字段 |
|---|---|---|
hello | 握手返回 | sessionId、会话参数 |
asr_partial | 中间识别结果 | turnId、text |
asr_final | 最终识别结果 | turnId、text |
reply_text | 回答文本(屏显) | turnId、text |
confirm_request | 请求确认写操作 | confirmId、summary(复述文本)、fields(结构化字段)、expiresAt |
tts_start / (二进制) / tts_end | 回答音频 | turnId |
result | 写操作结果 | confirmId、status:committed / rejected / expired / failed、ticketNo |
error | 出错 | turnId、code、message(可直接播报的提示) |
pong | 心跳回应 | — |
5.3 可靠性约定
- 幂等:
turnId、confirmId全局唯一;服务端对重复的confirm只执行一次,返回同一结果,防止弱网重发导致重复提票。 - 重连:断线后 App 自动重连,带上未完成的
turnId查询结果;录音中断线则本轮作废并提示重说。 - 心跳:默认 15 秒,可由服务端下发调整。
6. 服务端设计
6.1 一轮对话的处理流程
ptt_start
└─ 开 ASR 流 → 收音频帧 → 推送 asr_partial
ptt_end
└─ ASR 收尾 → asr_final
└─ 意图引擎:意图 + 槽位 + 规范化
├─ 缺必填槽位 → 追问("请问是哪台车?"),等下一轮补齐
├─ 查询类 → 权限检查 → 业务适配取数 → 生成播报短句 → TTS
└─ 写操作类 → 权限检查 → 生成复述 → confirm_request
└─ accept → 业务适配写入 → result → TTS 播报结果
└─ reject / 超时 → 放弃 → TTS 播报"已取消"
全程写审计记录
6.2 意图引擎
两段式:先规则,后大模型。
- 规范化(规则):把识别文本里的口语和别名转成标准值。
- 车型别名:如"和谐电一"→ 标准车型编码,别名表由管理后台维护;
- 车号:中文数字转阿拉伯数字("幺九零幺"→ 1901),节位"A 节 / B 节";
- 时间:"近三个月""九月上旬""第四季度"转成起止日期;
- 班组、部件名:按标准名录做模糊匹配。
- 意图与槽位(大模型函数调用):每个意图定义成一个函数,参数即槽位,标注必填/选填和默认值。大模型只负责选函数、填参数,不直接生成业务数据。
- 校验(规则):槽位值必须落在标准名录内;车型 + 车号必须在机车档案中存在;不合法的值转为追问,不猜测。
意图清单和槽位定义由业务方维护,作为服务端配置,不写死在代码里。
6.3 回答生成
耳朵听不了长文本,播报规则:
- 先结论后细节:"1901 近 3 个月有 2 条故障。第一条……";
- 单次播报控制在两三句,其余内容放屏幕,或提示"说'下一条'继续听";
- 数字逐位读:车号、票号逐位播报("幺九零幺"),避免"一千九百零一";
- 查不到要明确说:"没有查到 1901 近 3 个月的故障记录",不能沉默。
6.4 写操作确认
以提票为例:
人: 提票,韶四 1084 A 节,齿轮箱左 3 放油堵松动
助手:请确认提票。车型韶四,车号幺零八四,A 节,故障:齿轮箱左 3 放油堵松动。
确认请说"确认",或按确认键。
人: 确认
助手:已提交,票号……
- 复述所有关键字段,车号逐位读;
- 确认方式:语音说"确认/取消",或按屏幕确认键,两者等效;
- 确认有效期可配置(建议初值 60 秒),超时自动放弃;
- 提交带
confirmId做幂等,业务系统侧也以此去重。
6.5 业务适配
- 每个业务系统一个适配器,统一接口:
query(intent, slots, operator) → 结构化结果、commit(intent, slots, operator, idempotencyKey) → 结果; - 权限以人为准:按登录工号的角色和班组校验可查范围和可写操作;
- 适配器只读写既有系统的接口,不直连业务数据库;
- 业务系统超时或不可用时,返回可播报的错误提示,不阻塞会话。
6.6 审计
每一轮记录:
| 字段 | 说明 |
|---|---|
turnId、sessionId、terminalId、operatorId | 关联键 |
| 原始录音 | 按保留策略存对象存储 |
| ASR 中间/最终结果 | 用于评估识别质量 |
| 意图、槽位(规范化前后) | 用于排查理解错误 |
| 业务调用请求与结果 | 用于追溯数据来源 |
| 确认请求、确认决定、提交结果 | 写操作全链路 |
| 各环节时间戳 | 用于统计时延 |
录音的采集告知、保留期限和访问权限按段里的制度执行。
7. 识别准确率专项
识别准确率是这个系统的成败点,单独作为一条工作线。
7.1 热词与名录
- 车型、部件、班组、故障术语整理成名录,作为 ASR 热词;
- 热词表要小而精,只放真正的专有名词,不放常用词,否则会把没说的词硬塞进识别结果;
- 名录在管理后台维护,修改后热更新,不重启服务。
7.2 现场测试集
- P0 阶段在检修库、整备场等真实环境,用选型终端和配件录制测试语料;
- 覆盖:不同噪声环境、不同说话人、各意图的典型说法、车型车号组合;
- 每一条标注正确文本、意图和槽位。
7.3 评测指标
| 指标 | 说明 |
|---|---|
| 字错误率 | 整体识别质量 |
| 专名召回率 | 车型、部件、班组名识别正确的比例,比字错误率更关键 |
| 车号准确率 | 车号逐位完全正确的比例 |
| 意图准确率 | 意图分类正确的比例 |
| 槽位准确率 | 必填槽位全部正确的比例 |
每次换模型、改热词、改终端,都在同一测试集上回归。各项的验收阈值在 P0 跑出基线后,与业务方一起定。
8. 部署、网络与安全
8.1 部署
- 服务端部署在段内机房,与业务系统同网段或通过防火墙策略互通;
- ASR、TTS、大模型均本地部署;服务器配置按 P0 实测的并发和时延确定,不预先拍定;
- 管理后台复用既有平台。
8.2 网络
- 检修库、整备场等有 WiFi 覆盖的区域走段内 WiFi;
- 无覆盖区域走 4G 专用 APN 或 VPN 回到段内网,需与运营商及信息科确认;
- 全程 TLS;服务端只对终端开放 WebSocket 端口。
8.3 安全
| 方面 | 措施 |
|---|---|
| 终端身份 | 每台终端独立令牌或证书,后台可冻结、吊销 |
| 人员身份 | 工号登录,绑定终端;权限按人 |
| 数据 | 不出段内网;录音加密存储,按制度设定保留期 |
| 终端管控 | 专用模式锁定单一 App,MDM 统一升级 |
| 审计 | 全链路记录,后台可查 |
9. 非功能指标(拟定,待实测校准)
| 指标 | 拟定目标 | 说明 |
|---|---|---|
| 查询响应 | 松开 PTT 到开始播报,P95 ≤ 3 秒 | 以 WiFi 良好、业务系统正常为前提,P0 实测后修订 |
| 写操作误提交 | 0 | 未经确认不得写入;重复确认不得重复写入 |
| 可用时段 | 覆盖全部作业班次 | 含夜班 |
| 续航 | 终端满足一个班次 | 可换电池兜底 |
| 断网 | 断网时明确提示,恢复后自动重连 | V1 不做离线识别 |
10. 实施计划
| 阶段 | 参考周期 | 内容 | 闸口(不通过不进入下一阶段) |
|---|---|---|---|
| P0 选型与基线 | 第 1–3 周 | 2–3 款终端 + 配件样机实测(3.3);现场录制测试集;服务端骨架(协议、会话、ASR、TTS 打通) | 至少 1 款终端通过 D1–D6;测试集基线跑出,业务方认可识别水平可用 |
| P1 查询 MVP | 第 4–7 周 | 查询类意图上线;对接 1–2 个业务系统;1 个班组 3–5 人试用 | 试用人员愿意持续使用;查询类端到端可用;审计完整 |
| P2 写操作 | 第 8–11 周 | 提票上线(复述确认、幂等);扩到 2–3 个班组;4G 专网接入 | 试用期写操作 0 误提交;重复提交测试全部通过 |
| P3 推广 | 第 12 周起 | 按班组推广;管理后台和报表完善;按需启动扩展(第 11 章) | 由段里按试用效果决定 |
周期为资源到位前提下的参考值。P0 中最可能卡住的是终端 PTT 事件能否被 App 读取、以及 4G 专网的审批周期,应最先启动。
10.1 人员
| 角色 | 职责 |
|---|---|
| Android 工程师 | App、PTT 适配、音频、专用模式 |
| 服务端工程师 | 语音网关、会话、业务适配、审计 |
| 语音/算法工程师 | ASR 热词、测试集、意图引擎、评测 |
| 业务对接人(段里) | 意图清单、名录、业务系统接口、试用组织 |
| 测试 | 现场测试、弱网、重复提交、续航 |
10.2 采购清单(P0)
| 物品 | 数量 | 说明 |
|---|---|---|
| 安卓三防 PTT 终端样机 | 2–3 款,各 1–2 台 | 按 3.1 询价,优先可借测 |
| 有线 PTT 肩咪 + 单耳耳机 | 与终端配套,各 2 套 | 确认接口与终端匹配 |
| 蓝牙 PTT 肩咪 | 1–2 款 | 用于与有线方案对比 |
| 服务器 | 1 台 | 先用现有服务器跑 P0,按实测定正式配置 |
费用以询价为准,本文不列价格。
11. 扩展路线:两份原方案如何接入
服务端的终端适配层预留了接口,以下扩展不需要改动核心:
11.1 DMR 对讲接入(对应 DMR 方案路线 B)
- 触发条件:P1/P2 发现 WiFi 和 4G 都覆盖不到的作业区域,或段里要求统一用对讲机。
- 做法:采用厂商 DMR 中继 + 授权的第三方个呼接口,新增"DMR 适配器":
- 上行:接口给出的源 Radio ID + PCM → 映射到工号 → 进入同一会话流程;
- 下行:TTS 音频 → 按源 Radio ID 发起个呼回复;
- 信道忙闲、排队、超时、释放在适配器内实现(沿用 DMR 方案 5.4 状态机)。
- 采购前要求厂商实机演示:第三方实时收音频、按指定 Radio ID 下发语音、忙闲回报、异常释放。
- 注意:声码器窄带音质会降低识别准确率,接入前在 7.2 测试集上单独评测。
- DMR 方案路线 A(开源 SDR)不进入生产路径。
11.2 扫码与量具(对应作业盒方案)
- 选带扫码头的终端型号,扫码在 App 内完成;
- BLE 量具在 App 内接入,沿用作业盒方案 4.3 的协议适配器设计和附录 A 的事件格式;
- 事件队列、幂等、断网补传沿用作业盒方案的设计。
11.3 自研作业盒(对应作业盒方案)
- 触发条件:安卓终端在单价、体积、续航上不能满足量产要求。
- 调整建议:一开始就用双芯片(蓝牙通话交给专用音频芯片或模块,ESP32-S3 负责 WiFi、BLE 和业务);耳机先用商用产品;PTT 键放在盒子上。
- 接入时新增"作业盒适配器",协议沿用第 5 章。
12. 风险与应对
| 风险 | 影响 | 应对 | 等级 |
|---|---|---|---|
| 终端 PTT 事件 App 读不到 | 无法实现按住说话 | P0 首项实测;选型时要求厂商提供 PTT 开发说明 | 高 |
| 现场噪声下识别不准 | 用户放弃使用 | 肩咪近讲 + 热词 + 测试集回归;先从短指令意图开始 | 高 |
| 业务系统无接口或接口慢 | 查不到数据或响应慢 | P0 期间与业务系统负责人确认接口清单 | 高 |
| 4G 专网审批周期长 | 库外区域不可用 | 先在 WiFi 覆盖区域试点,审批并行推进 | 中 |
| 写操作误提交 | 数据错误 | 复述确认 + 幂等 + 审计;首版只开放提票 | 中 |
| 现场无线终端使用规定 | 部分区域不能用 | 选型前与安全科确认使用区域 | 中 |
| 作业人员使用习惯 | 推广困难 | 从高频查询场景切入,试用期收集反馈迭代话术 | 中 |
13. 需要确认的事项
| 编号 | 事项 | 找谁 |
|---|---|---|
| Q1 | 首批试点的班组和作业区域,WiFi 覆盖情况 | 段里业务方、信息科 |
| Q2 | 现场无线终端使用规定,是否有防爆区域 | 安全科 |
| Q3 | 首版要接的业务系统及接口文档 | 业务系统负责人 |
| Q4 | 首版意图清单(查询哪些、提报哪些) | 段里业务方 |
| Q5 | 人员身份体系(工号登录、工卡或扫码) | 信息科 |
| Q6 | 段里是否已有可复用的安卓终端或作业记录仪 | 设备管理部门 |
| Q7 | 4G 专用 APN/VPN 的办理途径 | 信息科、运营商 |
| Q8 | 录音的告知方式和保留期限 | 段里制度负责部门 |
Discussion
Comments
No comments yet. Be the first to start the discussion.