UCD × AI 产品研究 / 2026.04.09
CBG 技术服务专家
调研报告
阿在智能体 · 机会场景发现与假设验证
组织结构与分层
CBG 无 L1，统称 L2，采用直服模式（无渠道）。归属二部，下设两个小组：
400 接入组（设定 0）
承接所有来电，不能拒绝任何客户；负责转接/分派到对应工程师。按产品线导接后拉群或转人。
大客户组
运营商重客（二部）和互联网重客（一部）；不接电话，由一线或 400 转入。腾讯/阿里等可绕过 400 直达。
业务类型与服务链路
工单分三类（均属运维类，非交付类）：
咨询
占比最高（约 80%）。一线或客户直接问。平均 0.35h 处理，底层问题提品控单拉研发。
故障
约 20%。按四级/三级/二级/一级/SOS 分类，处理链路差异显著。严重故障全程飞书群协同。
变更
量不小（4月前9天24单）。需方案→评审→实施三步，一级变更须拉 L3 测试打卡。
SLA 时效要求（故障）
| 级别 | 定位时限 | 闭环时限 | 特殊要求 |
|---|
| 四级 | 1h | — | 能远程搞定，一般不现场 |
| 三级 | 约 3 天 | 10–14 天 | 可能需要测试介入 |
| 二级 | — | 17h | 一线必须现场安抚客户 |
| 一级 | 1h 定位 | 28h | 组长直接拉通，大客户接管 |
| SOS | 同一级 | 1h 业务恢复 | 每小时通报进展；质量人员旁听 |
工具生态（多系统分散）
工单与流程系统
CSN 工单系统（变更流程打卡）
业务看板系统（绩效/人效数据）
导接系统（400 接入分配）
知识与 AI 工具
飞书知识库（案例沉淀）
晓光（咨询 AI，参数查询）
晓贤（故障 AI，排障推演）
协作与操作
飞书群（内部协同）
微信/电话（对外一线）
小瑞云桥（远程登录设备）
质量与绩效表格
KCP 遵从性 Excel
软件组件定位率 BI 系统
非软升级率 BI 系统
质量积分 Excel（每月邮件）
痛点：无统一入口，"懒得找就忘了，忘了就被扣分"——这是受访者明确表达的工作摩擦。
考核指标体系（个人）
时效达标率 · 定位准确率（故障原因分类正确）· 组件定界准确率（须到具体模块）· 非软升级率（不该找研发而找了）· 客户满意度（质量部每季度抽样回访）· 案例产出数 · AIDC 专项绩效（占 20%）
Job 1 · 故障排障（核心 Job，影响最大）
1
收到工单
一线服务经理转入（主路径）或 400 接入。一线已做初步排查，问题仍未解决。
2
实锤故障现象 卡点
客户口述不够，必须要截图/抓包/流统作为证据。"他说丢了 3 个包，我不信，截个图来。"
3
自行排除环境/配置问题
靠经验过一遍：登录设备检查配置、版本、端口状态。远程操作为主（小瑞云桥）。
4
查已知案例和预警系统
用晓贤 AI 输入异常现象，查相似案例；再用关键字搜预警系统（端口/ARP/MAC 等）。晓贤准确率目前偏低，仍以自身经验为主。
5
定界到组件级 考核点
须精确到具体模块（如 OSPF、PBR、MAC 学习异常等）。"你要把流量模型梳理出来，把疑点提炼给研发。"定界不准直接扣分。
6
提品控单上升研发 卡点
在飞书群填写品控单（故障现象、排查步骤、定界结论），拉研发进群。宇航习惯"打包提交"后可做其他事，但零容错——判断错则被扣非软升级率。
7
研发协同（按需拉测试 L3）
研发有时需要测试 L3 搭环境模拟，特殊报文须抓包导入。群内 PIN 关键信息方便交接。
8
关单
确认问题修复或提供解决方案，告知一线，关闭工单。
Job 2 · 变更评审（风险最高）
变更大多在凌晨 0 点后实施，操作失误即断网。宇航认为这比故障处理"更心惊胆战"。
1
一线发起，CSN 开变更单
变更级别由一线评估（规模/业务重要度/复杂度），二三级由 400 接入组分派给值班工程师，一级给大客户组。
2
二线评审方案（20+ 检查项）核心 Job
逐项检查：是否充分识别风险、打卡时间是否早于授权时间、回退方案是否完备等。CSN 系统逐步打卡。
3
一级变更须拉 L3 测试打卡
流程强制卡点，不拉 L3 打不过去。
4
评审通过 → 返回一线实施
一线凌晨现场实施（或客户自行操作）。时间节点由客户确定，无固定 SLA，但不能超过客户要求日期。
Job 3 · 咨询答复（量最大，80%）
1
接收咨询
400 接入或一线直接问。晓光 AI 可查参数/配置注意事项，给出明确结论和查询过程。
2
直接答复（能力范围内）
平均 0.35h 处理，快的几秒，难的几小时。
3
底层问题提品控单（超出范围）卡点
手册未写、涉及代码层面时找研发。同样需要品控单。
Job 4 · 案例沉淀与 AIDC 建设（专项任务）
每季度产出 30+ 篇故障案例（复制粘贴排查过程 → 飞书知识库 → 提交学习空间，3.5 积分/篇）。只有新故障或新颖排错思路才能通过审核，重复故障不算。
SOP 沉淀成本远高于案例撰写——案例是"复制粘贴"，SOP 需要跨案例提炼标准化动作。宇航明确：现有故障树文档量远不足以支撑 AI 达到组件级定位。这是核心瓶颈。
| 编号 |
假设 |
结论 |
访谈依据与关键发现 |
| H1 |
客户重复解释 → SLA 压力 |
不成立 |
CBG 直服模式，L2 只和一线对接，客户只说一遍。宇航："一线让我们直接问客户，我会屌他，你在中间起到什么？"转接现象不存在。 |
| H2 |
不懂业务背景 → 首轮判断不准 |
部分成立 |
CBG 客户技术能力强，背景信息主要靠一线传递。但"信息不实锤"是常见问题——客户口述丢包无截图，导致无法准确判断。 |
| H3 |
一线得不到支持 → 专家被打断 |
部分成立 |
宇航个人会主动屏蔽"传声筒"，但转接率是组级指标，存在搭便车心理——没人愿意主动接别人的电话，但自己也不会主动上。 |
| H4 |
重复低价值工作 → 人效下降 |
成立 |
多系统、多表格（质量Excel/BI系统/飞书）分散，无统一入口。"懒得找就忘了，忘了就被扣分。"这是受访者最直接表达的工作摩擦。 |
| H5 |
服务难兑现 → 管理层经营问题 |
待访管理层 |
宇航不掌握管理层视角。但质量部全量逐单审查、指标体系完整，说明已有系统性关注。建议单独访谈 TL/主管验证。 |
| H6 |
成本高 / 堆人 → 不可持续 |
部分成立 |
规模化诉求（TDC 推自服材料、降量讨论）存在，但工程师缺乏个人动力——降量指标不背在自己身上。 |
| H7 |
经验无法沉淀 → 能力难复制 |
成立 |
案例沉淀靠积分驱动尚可，但 SOP 沉淀成本极高，现有故障树文档远不足以支撑 AI 做组件级定位。宇航自己指出这是核心瓶颈。 |
| H8 |
高改造成本 → 新方案难推进 |
部分成立 |
晓贤强制用率指标说明靠自愿推广很难，但宇航本人态度积极开放，同意试用阿在飞书接入方案。CBG 已有 SOP 基础文档可作为起点。 |
最重要的差异：H1 在 CBG 完全不成立——直服模式决定了切入点不在客户侧体验，而在工程师侧效能（品控单撰写、多系统分散、SOP 缺失）。
候选机会场景
故障定界辅助
宇航明确说："能定位到组件就解决 80% 问题。"晓贤当前准确率低，严重依赖 SOP 输入量。阿在可在 SOP 逐步积累过程中填补这个缺口，并辅助工程师提炼定界结论。
优先级：高
品控单 / 飞书群信息整理
手动撰写品控单（描述现象、排查步骤、定界结论）耗时且要求严谨，出错直接影响非软升级率考核。阿在可辅助起草或结构化整理，减少"打包提交"带来的容错风险。
优先级：高
多系统统一看板 / 提醒
质量表/BI系统/飞书表格分散，工单超时提醒虽然有但常漏看。阿在可作为统一入口，在关键节点主动 @ 提醒，"懒得找就忘了"的问题可以直接解决。
优先级：中
SOP 辅助生成
SOP 沉淀是"前人种树"逻辑，当前成本太高无人愿做。阿在可从已有案例半自动生成 SOP 草稿，大幅降低门槛。宇航已有 30+篇/季的案例积累，是最佳种子数据。
优先级：中
后续行动
可立即跟进
宇航同意试用"阿在"飞书接入方案，可作为 CBG 内测种子用户。
对接内部已有故障树/SOP 文档（宇航已展示），评估能否导入现有平台做 CBG 线试点。
聚焦：品控单辅助起草作为最小可验证场景，频次高（~100单/月）且有直接考核压力。
待补充访谈
访谈 CBG 团队组长/TL：验证 H5/H6（管理层是否将运营成本视为经营问题）。
追访变更流程：凌晨实施环节的心理压力与辅助工具接受度（这个场景宇航认为"比故障更心惊胆战"）。
访谈 SBG 对比：确认服务模式差异是否影响相同切入点的优先级。
核心结论：阿在在 CBG 的切入点应聚焦于工程师效能而非客户侧体验。最清晰的机会是品控单撰写辅助 + 定界辅助，最大的结构性障碍是 SOP 缺失——这个基础不建好，排障 AI 的能力上限会很有限。