01项目目标
让客服电话在无人值守时段也能被接起并给出有数据依据的答复，让报修从 Excel 变成可追踪、可统计的工单闭环。
| 指标 | 现状 | 一期目标 |
|---|---|---|
| 7×24 电话接通率 | 夜间依赖手机转接，存在漏接 | 100%（AI 秒级接起） |
| AI 独立解决率 | 无 | 阶段一约 10–15%，阶段二逐步升至 40% |
| 报修工单留痕率 | 依赖 Excel，大量散落在微信与口头 | 100% 系统留痕 |
02现状与约束
方案的每项取舍都建立在下列事实上，其中第 5 条是最有价值的条件。
| 现状 | 带来的问题 | 对方案的约束 |
|---|---|---|
| 对外有 400 总机和客服手机，无专门后台 | 通话无录音、无法质检、无法统计 | 一期先建通话通道 |
| 月通话量不足 100 次 日均约 3 通 | 重资产语音机器人单通成本过百元 | 云服务按量付费，不做私有化 |
| 报修主要靠 Excel | 问题散落在微信群、销售转达、现场口头 | 工单系统优先级高于电话功能 |
| 知识资产需从零建设 | AI 无内容可说 | 知识库建设独立推进，不阻塞上线 |
| 充电运营平台自研且已部署阿里云，可提供 API | —— | 本方案成立的关键条件，AI 能查数据而非念话术 |
| 需 7×24 服务 | 夜间人力成本高、响应慢 | AI 定位为补夜班，不替代白天坐席 |
| 售后工程师兼接电话 | 工程师在场时无法接听 | 转接目标为值班手机，留单回呼为主路径 |
03四条核心判断
判断一：AI 的定位是补夜班，不是替代坐席
日均约 3 通，夜间通常 0–2 通。但夜间谷电充电集中，车停在桩边充不上电是客户焦虑最高的场景。AI 在夜间时段的价值远高于白天：秒级接起、能查数据、不会不耐烦。
判断二：主要矛盾不是接不过来，而是问题没被收拢
150 座以上自营站加大量已售设备，真实故障量远超日均 3 通电话，其余走的是微信群、销售转达、现场口头。工单系统是本项目最有长期价值的产出，电话只是其中一个入口。
判断三：知识库不应阻塞技术上线
AI 的第一价值不是「回答一切」，而是永不漏接、完整记录、准确分流，这三件事不依赖知识库。因此采用两阶段交付。
判断四：全部能力收敛在阿里云内
运营平台已在阿里云，语音、模型、接口、存储同账号同区域，走 VPC 内网。数据不出境，且接口延迟可控。
04总体架构
四层结构
| 层 | 组成 | 说明 |
|---|---|---|
| 接入层 | 400 总机、客服手机（不并入）、微信 | 400 号不变，只改转移目标 |
| 会话层 | 阿里云云呼叫中心、智能语音交互、通义千问 | 语音识别含粤语，模型境内调用 |
| 能力层 | 设备状态、订单查询、工单创建、知识检索 | 工程量所在，把平台数据与对话接起来 |
| 数据层 | 充电运营平台、工单模块、OSS 录音、条目库 | 全部在既有阿里云账号内 |
组件选型
| 能力 | 阿里云产品 | 要点 |
|---|---|---|
| 电话接入、IVR、录音 | 云呼叫中心 / 语音服务 | 分配接入号；录音存 OSS（境内） |
| 语音识别 | 智能语音交互 | 必须选 8k 电话场景模型，通用模型效果差；粤语需实测 |
| 语音合成 | 智能语音交互 | 内置音色 |
| 大模型 | 百炼 / 通义千问 | 境内调用，数据不出境 |
| 接口服务 | ECS 或函数计算 | 与运营平台同 VPC，内网调用 |
| 存储 | RDS + OSS | 工单数据与通话录音 |
| 告警 | 企业微信群机器人 + 电话外呼 | 双通道，用同一云呼叫中心发起外呼 |
电话链路
一、转移目标替换，而非新建通道。400 号、转移功能、场站标识牌、官网、公众号上的号码全部不变，改动面最小，效果不好可随时关掉转移恢复现状。
二、回落必须自动。AI 平台是新增环节，一旦不可达而无人接管，电话就彻底打不通。回落至工程师手机是必要的保险。
05一期范围：两阶段交付
阶段一（W1–W5）：规则型 AI
不依赖知识库，只用规则与接口即可运行。
| 能力 | 说明 |
|---|---|
| 接起与意图识别 | 识别充电失败、支付、场站咨询、B 端业务等意图 |
| 查设备状态 | 按桩编号取实时状态、故障码、最近告警 |
| 查订单 | 按来电号码关联最近一笔充电订单 |
| 智能分流 | 能答直接答，需人工转值班手机，接不了留单 |
| 留单回呼 | 自动建工单、短信告知工单号、承诺次日 18:00 前回呼 |
| 安全类硬规则 | 冒烟、漏电、起火等命中即转人工并双通道告警，不经模型判断 |
| 低置信度兜底 | 连续两次识别置信度低自动转人工，兼作英语来电兜底 |
阶段二（W5–W7）：知识库接入
- 知识检索：AI 答不上时先检索知识库，再决定是否转人工
- 条目治理：200 条起步，按产品线与场景打标签，持续回流
明确不做
| 不做 | 理由 |
|---|---|
| 前置按键导航（IVR 菜单） | 急单客户多点一次键就多一分流失；月话务 100 通没有排队，分流无意义。改用 AI 直接接起 + 低置信度转人工 |
| 客服手机号并入 AI | 本质是管理问题：客户存了工程师号码就会一直打，强行并入会引发抵触。根本解法是把 400 做好让客户回流 |
| 海外多语种 | 一期只做中文，海外来电靠低置信度兜底转人工 |
| 微信 / APP / 官网全渠道 | 渠道越多运营成本线性上升，一期做不完也养不起 |
| 私有化部署 | 话务量不支持重资产投入 |
| 与电网客户工单系统对接 | 涉及合规加严，需单独立项评估 |
06关键设计
带数据的客服
来电时通过号码自动关联最近订单，AI 开口前已知道上下文：
「您好，奥特迅充电服务。看到您刚才在月亮湾大道站充电，是遇到什么问题了吗？」
这一句话的体验差距远大于任何话术优化，前提是平台提供按手机号查订单的接口。
同理，车主说「充不上电」时，AI 必须先查该桩实时状态与故障码再判断，查不到就转人工，不允许推测。
安全类事件硬规则
触发词：冒烟、起火、着火、漏电、触电、爆炸、焦味、冒火花、烧了。命中即执行，不经模型判断：
- 立即中断 AI 对话，转接值班手机
- 同时向值班负责人推送告警（企业微信群 + 电话外呼）
- 通话结束前播放安全提示：远离设备、不要触碰枪线、必要时拨打 119
深夜群里一条消息没人看到，等于没做。必须有「响」的通道，所以采用双通道。
留单回呼
AI 无法处理时（夜间、或工程师接不了）：
客户听到「没人接」和听到「已记录、明天 18 点前回复您」，感受完全不同。但售后接不住就不能承诺，建议先保守后收紧。
07接口需求
以下接口由研发中心在充电运营平台上提供，供 AI 平台调用。
| # | 接口 | 用途 | 关键字段 | 时效 |
|---|---|---|---|---|
| 1 | 按手机号查最近订单 | 来电自动关联上下文 | 订单号、桩编号、站点名、起止时间、电量、金额、结束原因、失败码 | < 500ms |
| 2 | 按桩编号查实时状态 | 判断是否为设备故障 | 在线状态、当前功率、故障码、最近告警时间、所属站点 | < 500ms |
| 3 | 按站点查信息 | 位置、价格、空闲枪数 | 地址、收费标准、空闲枪数、营业时间、停车费 | < 1s |
| 4 | 创建设备工单 | 替代 Excel | 客户信息、桩编号、故障现象、录音 ID、来源渠道 | < 2s |
| 5 | 查设备告警历史 | 排查间歇性故障 | 告警码、告警时间、恢复时间 | < 1s |
接口 1、2 是通话中同步调用的，超过 1 秒客户会感到明显停顿，因此需单独提供轻量查询接口，不复用后台管理页面的重查询。
统一约定
| 项 | 约定 |
|---|---|
| 鉴权 | 独立 API Key 与配额，不与后台管理 Session 共用 |
| 限流 | 超出返回 429，AI 侧需能降级为转人工 |
| 超时 | 服务端 3 秒；AI 侧 1 秒未返回即转人工，不允许在通话中干等 |
| 幂等 | 建单接口按 call_id 去重，重复调用返回同一工单号 |
| 脱敏 | 手机号、车牌在出参层脱敏，不依赖 AI 侧配置 |
| 日志 | 每次调用返回 trace_id，可回溯耗时与返回内容 |
08知识库建设
素材来源（按价值排序）
| 序 | 来源 | 价值说明 |
|---|---|---|
| 1 | Excel 历史报修记录 | 真实客户问法与真实处置结论，可直接转成问答对，比从产品手册抄 FAQ 有效得多 |
| 2 | 故障代码表 | 「充不上电」类问题的判断依据 |
| 3 | 产品与安装调试手册 | 参数、安装与操作类咨询 |
| 4 | 资深工程师访谈 | 手册里没写的现场处置技巧 |
每条知识的结构
四段，缺一不可。第四段最容易被忽略，但恰恰是防止 AI 乱答的关键。
| 字段 | 内容要求 |
|---|---|
| 客户原话 | 客户实际怎么说，保留口语、方言表达、错别字 |
| 判断条件 | 什么情况下适用，需要哪些数据佐证 |
| 处理动作 | 标准处置步骤 |
| 边界 | 什么情况下不能这样答，必须转人工 |
规模与节奏
首批 200–300 条，覆盖 Top 20 高频问题即可上线，剩余靠转人工兜底。
| 周次 | 目标 |
|---|---|
| W1 | 模板定稿、资料盘点、安全话术定稿 |
| W2 | 故障码表整理过半、工程师访谈完成、报修记录清洗过半 |
| W3 | 50 条 P0 条目初稿（安全 + 充电失败） |
| W4 | 约 200 条编写完成并通过技术审核 |
| W5 | 入库、标签化与索引完成 |
| W6 | 检索接入对话流程，命中率达标 |
| W7 | 运营机制跑通，周新增条目 ≥ 5 条 |
09实施计划
| 周次 | 里程碑 | 验收标准 |
|---|---|---|
| W1 | 通道打通 | 资质确认完成；400 转移改造与回落验证通过；接口契约冻结 |
| W2 | 接口就绪 | 接口 1、2 可调；鉴权与沙箱可用；工单模型与流转规则定稿 |
| W3 | 对话与工单可用 | 规则版对话流程完成；安全词与低置信度兜底上线；工单模块完成 |
| W4 | 联调通过 | 端到端通话、故障演练、安全事件双通道演练全部通过 |
| W5 | 阶段一交付 | 夜间灰度运行；知识条目入库与索引完成 |
| W6 | 知识库接入 | 检索命中率达标；白天切换 AI 前置 |
| W7 | 运营跑通 | 看板可用；录音复盘机制运转 |
月话务 100 通，夜间一周仅 5–7 通样本，解决率没有统计意义。灰度期不以解决率做决策，改看是否出事故：有没有漏接、有没有答错导致投诉、转人工是否成功、留单是否闭环。灰度周期拉长至 3 周。
三项任务同时到期：接口可调、语音实测达标、工单流转规则定稿。这一周过不去，后面全部顺延。
10成本估算
按当前话务量测算，云上运行的技术成本很低，主要投入是人力。
| 项目 | 计费方式 | 量级 |
|---|---|---|
| 云呼叫中心（接入号、坐席、录音） | 按坐席/月 | 千元级/年 |
| 智能语音交互（识别与合成） | 按时长 | 百元级/年 |
| 百炼 / 通义千问 | 按 token | 百元级/年 |
| ECS / RDS / OSS | 共用现有资源 | 增量很小 |
| 企业微信机器人 | 免费 | 0 |
| 电话外呼 | 按次 | 极少量 |
| 实施服务费（语音对话搭建与调优） | 一次性 | 数万元级，待询价 |
| 研发与知识库人力 | 内部 | 一次性约 751 人时（约 94 人日） |
云资源成本低是因为话务量小；实施服务费与人力才是真正的成本。本表为量级估算，依据是当前话务量与公开计费口径推算，最终以询价与合同为准。
11风险与对策
| 风险 | 影响 | 对策 |
|---|---|---|
| 呼叫中心业务资质不具备 | 可能无法申请接入号码，M1 卡死 | 开通前向阿里云确认要求，同时核查公司证照范围 |
| 400 转移为无应答转移 | AI 排在工程师之后，永远接不到电话 | 开通前问清转移类型，必要时改为无条件 |
| 8k 语音模型与粤语识别不达标 | 夜间体验比现在更差 | W1 用真实场站录音实测，不达标立即调整方案 |
| 知识库不足导致答错 | 损害品牌信誉，引发投诉 | 严格执行「查不到就转人工」，宁转不猜；首月每日复盘录音 |
| AI 误判桩故障为车辆问题 | 直接引发投诉 | 充电失败类判断必须先查设备状态与故障码 |
| 工程师抵触电话不再直达 | 上线即遇阻力 | 提前沟通：只过滤简单问题，复杂问题照样转来且带完整背景 |
| 接口性能达不到 500ms | 通话中明显停顿 | W0 预研实测，不达标则加缓存层或异步查询 |
| 400 转移链路不稳定 | 电话打不进来 | 保留原号码，AI 不可达自动回落工程师手机 |
| 安全事件被 AI 淡化处理 | 人身安全风险 | 安全词硬编码，命中即转人工并双通道告警 |
| 数据合规 | 客户隐私与录音安全 | 全链路境内，录音存 OSS；接口出参层脱敏 |
| 外部实施方未询价 | 预算无法确定，项目停摆 | 基于阿里云生态找 2–3 家询价，范围限定在语音对话部分 |
12待确认事项
| # | 事项 | 影响 | 负责 |
|---|---|---|---|
| 1 | 呼叫中心业务资质要求 | 决定接入号能否申请 | IT + 法务 |
| 2 | 400 转移类型 | 决定 AI 能否接到电话 | IT |
| 3 | 8k 语音模型与粤语实测 | 决定方案是否需调整 | IT + 实施方 |
| 4 | 售后对转移改造的接受度 | 影响上线阻力 | 项目牵头人 |
| 5 | 值班工程师轮值表 | 决定转接目标与响应速度 | 售后 |
| 6 | 工单流转规则 | 决定工单模块能否按时开工 | 售后 |
| 7 | 安全事件第一责任人与备岗 | 决定双通道告警是否有效 | 售后 |
| 8 | 回呼承诺时效最终值 | 影响客户体验与 SLA | 售后 |
| 9 | 外部实施商询价 | 决定预算与工期 | 采购 + IT |
| 10 | 一期 4 周交付边界 | 决定对外承诺口径 | 项目牵头人 |