火锅店设备维修：报修远程分诊小工具——让编码代理做一个单文件页面，店员照着答，你在电话这头就知道带什么配件

你是一个编码代理。请为我做一个单文件 HTML 的「报修远程分诊」
工具，给火锅店维修工远程判断故障用，店员在手机浏览器打开，
不联网、不装依赖、不引任何外部资源。

一、核心流程
1. 店员选设备类型（列表由维修工维护：如 电磁灶 / 燃气灶 /
   四门冰柜 / 冻库 / 制冰机 / 洗碗机 / 排烟风机）
2. 工具按维修工预设的问题链逐题发问，每题只有三个按钮：
   是 / 否 / 不知道
3. 答完自动落到三档之一，展示对应内容：
   A 档【先自救】：零风险动作的分步说明（如 查插座、复位
   跳闸、等化霜），每步不超过三行；做完仍不行提示转入 B 档
   B 档【需上门】：自动拼好报修文本——设备名 / 现象链
   （店员的全部作答）/ 已做过的自救动作 / 需要拍的照片
   清单（维修工预设，如「铭牌特写」「报警代码屏」），一键
   复制，店员粘到微信发给维修工
   C 档【立即停机】：安全类现象（燃气味 / 漏电麻手 /
   异响冒烟 / 明显制冷剂泄漏）——先展示断电断气等紧急
   步骤，再展示报修电话（维修工预设）

二、规则结构（全部由维修工在「规则管理」页维护，工具不预填）
- 问题链：每台设备一串问题，每题两个分支（答「是」跳到
  哪题、答「否」跳到哪题），「不知道」永远走更保守的分支
- 终点三档：A / B / C，挂在问题链末端
- 维护界面要能新增设备、增删改问题与分支、指定终点档位
- 唯一例外：C 档的触发题（燃气味、漏电、冒烟类）在任何
  设备的问题链里都直接跳 C，且这个跳转规则维修工删不掉

三、防错
- 问题链存在环（跳来跳去到不了终点）：保存时检测并拒绝
- 存在答不到的孤儿题目：保存时列出提醒
- 店员中途退出不保存作答——分诊是一次性的，不留状态
- 「不知道」分支必须显式设置，未设置的题保存时按「跳到
  C 档的保守分支」强制兜底并在维护页提示

四、数据
- 设备列表、问题链、报修电话存 localStorage，维修工导出
  JSON 备份、可导入恢复（换手机不丢规则库）
- 店员页面与维护页面用同一个文件的两个标签页切换，维护
  页入口不显眼（店员不该误入）

界面：店员路径大按钮、大字、每屏一题（营业高峰单手可答）；
维护页桌面优先。交付一个完整 HTML 文件，内联全部 CSS 与
JS，附两百字以内的中文使用说明。

为什么这样写

分诊工具的价值全在「店员不需要表达，只需要回答」。报修电话里信息损失最大的环节是开放性提问——「什么样的不制冷？」这种问题在营业高峰得到的回答是「就是不制冷啊」。把维修工的追问固化成是/否题链，店员的回答成本压到一次点击，信息量反而上来了：每题都答了，路径就完整了。所以这个工具本质上不是「故障诊断器」，是把维修工的经验翻译成店员能走完的问卷——诊断还是维修工在做，工具只保证原料齐全。

问题链和规则库不预填、全部维修工自建，和成本卡、词表类工具的理由一致但更硬：故障树是长在具体设备型号上的。同样是「灶打不着」，商用电磁灶和燃气灶的分支完全不同，预填通用树的工具会把店员引向一个不存在的故障。维护成本换来的准确率，在报修这个场景是刚性需求——引错一次分支，维修工带错配件白跑一小时，工具的信用就清零了。

三档的顺序是安全设计：C 档触发题（燃气味、漏电、冒烟）在任何链路里直达且不可删，是给工具装的保险丝。设备问题的概率分布里安全类是小概率，但它的代价不对称——A、B 档判断错了浪费的是时间，C 档判断错了赌的是事故。所以宁可让「不知道」也走保守分支、宁可偶尔误触发停机，也不让安全类症状在问题链里排队等排查。这是全工具唯一不让维修工自定义的地方：可维护性在安全面前让位。

报修文本由工具自动拼装、店员一键复制发微信，是照顾中国门店的真实沟通路径——没有门店为报修装工单系统，微信就是工单系统。拼好的文本里「已做过的自救动作」这一段最值钱：它替维修工回答了「你复位了没」这个必问的问题，也让店员不再被反复追问同一个基础问题——双方都对这一次上门有准备。

变量