工作成果 · 2026年11月7日 · 约 3644 字 · 8 分钟
客服副驾：给人工客服用的侧栏助手
在客服工作台旁边读懂当前会话，给出回复草稿、处理步骤、记录查询和会话分类；消息始终由客服本人发送。
本文为个人工作记录。文中的平台、用户、对话和数据均已去敏：对话为改写示例，数字只保留汇总比例，不含任何真实账号、域名、地址或客户内容。
一句话：一个装在浏览器侧栏里的客服助手。客服打开一个会话，它就读懂这段对话，给出一份可以直接改、直接填的回复草稿，告诉客服这次该怎么处理，并且把查记录、填 Bug 单、选分类这些重复动作做到只差最后一步。
背景：客服每天在做什么
服务的对象是一个在线配音与语音社交平台。用户会因为各种事情找人工客服：充值没到账、抽奖扣了钻石没出东西、账号被封想申诉、活动任务明明完成了却没算、关系位解除不了……
一位客服的日常大致是这样：
- 在后台工作台打开会话，读完用户前后发的几条消息；
- 去另一个后台页面，按用户 ID 查充值、流水、抽奖、封禁记录；
- 回忆或翻找对应的处理口径，组织一段回复；
- 如果是技术问题，再打开“创建 Bug”，挑聊天记录、写标题；
- 最后给会话选一个分类，方便后续统计。
每一步都不难，但会话一多，来回切页面、复制 ID、翻规则的时间就积起来了，回复口径也很难统一。
它是什么
一个 Chrome 侧栏扩展，加上一套内网部署的后端。
| 部分 | 做什么 |
|---|---|
| 侧栏扩展 | 读取工作台里当前打开的会话，展示草稿、处理步骤、分类建议和记录查询，所有按钮都只作用于当前会话 |
| 回复后端 | 部署在公司内网，用本地运行的开源模型生成草稿和处理计划，不调用外部服务 |
| 知识流水线 | 每两小时从历史会话和客服实际回复里整理知识包，交给后端使用 |
几条一开始就定下、后来一直没变的边界：
- 消息永远由客服本人发送。助手可以把草稿填进输入框，但不会替客服点发送、不会领取或结束会话。
- 草稿和会话强绑定。每份草稿都带着会话、用户、最后一条消息等标识；客服切到别的会话或用户又发了新消息，旧草稿就不能再填入，避免“把 A 的回复发给 B”。
- 查询只读、只查本人。记录查询固定为当前会话用户的最近 10 条，结果只显示在侧栏，不发给模型。
- 关键动作留最后一步给人。Bug 单自动填好，但“提交”由客服点。
一次会话里，客服看到什么
以一个改写过的例子说明。用户发来：
我昨晚抽了个十连，扣了 500 钻，结果啥都没出，是不是被吞了？
侧栏从上到下依次是：
1. 用户一行：昵称、等级、注册时长、情绪标记（例如“着急”），以及一排常用查询：钻石、充值、道具、抽奖、封禁、设备。
2. 分类建议：营收活动 › 抽奖与概率。客服点“提交分类”，助手在工作台里选好这个分类并保存；如果后台找不到完全对应的分类，就不保存，提示客服手动选。
3. 回复草稿（可直接编辑，显示字数）：
您好，十连抽奖每一次都会有对应结果，我这边先帮您核对一下昨晚的扣钻和抽奖记录，确认后马上回复您，请稍等一下哦。
4. 这次怎么处理，按问题拆成卡片，每一步旁边是能直接执行的按钮：
- 核对钻石流水里昨晚的扣费 →
查钻石流水 - 核对同一时间的抽奖记录和获得物品 →
查抽奖记录 - 如果扣了钻但没有任何结果，整理截图交技术核查 →
填好 Bug 单
点“查钻石流水”，侧栏里直接出现：
| 时间 | 内容 | 金额 |
|---|---|---|
| 11-05 21:14 | 抽奖消耗 · 余额 1,200 | −500 |
| 11-05 20:02 | 充值 · 余额 1,700 | +600 |
点“填好 Bug 单”，工作台里的创建 Bug 弹窗会被打开、相关的几条聊天被勾上、标题填成“十连扣钻无结果 · 用户×××”，客服检查后自己点提交。
几个细节设计
把“已经做了”改成“会去做”。模型很容易写出“已为您记录”“已帮您核实”，而客服其实还没做。这类句子会在草稿里被标出来，旁边一个按钮“改成‘会××’”，一键变成“会为您记录”。只在客服点了之后才改。
系统消息先翻译再分析。工作台里夹杂着排队、转人工、留言表单等系统消息，原样是一段 JSON。送去分析前先转成简短文字，例如：
[留言表单] 分类：充值问题；内容：充了 30 元没到账，附件 2 个
这样模型能读到用户真正的诉求，而不是一堆字段名。
二次进线自动标记。同一用户上一次会话结束后 24 小时内又来，标题前自动加“【二次】”。这比让客服手动选一个“二次会话”分类更准，也不占用分类本身。
魔法棒直接优化。草稿旁的魔法棒点一下就改写语气，可撤销；不弹面板、不让客服再做选择。
分类体系重做
旧的会话分类有 500 多个，层级混乱、同义重复，很多从没被用过。结合近两个月的会话诉求，重新设计成 12 个一级、36 个业务二级，另加一个“待人工确认”：
账号与安全 · 处罚与申诉 · 举报投诉 · 充值与权益 · 营收活动 · 内容活动 · 道具与装扮 · 社交关系 · 语聊房 · Pia戏与配音创作 · 技术问题 · 建议与其他
其中最关键的一刀是把“活动”拆成营收活动和内容活动：
- 送礼、充值、抽奖、返利类的问题，归营收活动；
- 杀青、走本、投稿、评选类的问题，比如“明明杀青了任务为什么没完成”，归内容活动；
- 两类之间不设“混合”，这是和业务方确认过的。
切换分两步走：
- 先保守：新树全部新建，旧分类只停用从没用过的；用关键词规则先把约 4 万个历史会话归到新树，能确定的才写，并保留逐条回滚台账。
- 再全量：抽查发现关键词规则有明显错分后，改为逐条语义判断，再用另一个模型独立复核一遍，对全部约 6.2 万个历史会话重新归类。拿不准的（只有图片、上下文不足、活动类型没有依据）统一放进“待人工确认”，约占 19%，不硬分。每条保存后立即回读，确认只改了分类、标题和状态没被动过。最后 500 多个旧分类全部停用但不删除，历史会话里已没有任何旧分类引用。
这一版解决了什么
这一版（扩展 0.2.23 / 后端 backend.3）是在接手项目后，先看数据再动手：
| 发现 | 处理 |
|---|---|
| 有一批分析请求在调用模型前就被拒绝（集中在两天里，一度占当时请求的相当比例）：坐席电脑时钟和服务器差几秒，后端零容差判定“消息时间晚于快照” | 后端允许 120 秒时钟误差，前端把快照时间对齐到最新消息 |
| 约 90% 需要修改的草稿里有“已记录 / 已核实”这类没做过的承诺 | 草稿内标出并一键改写 |
| 系统消息原样送给模型，干扰判断 | 7 类系统消息转成短文字 |
| 侧栏信息太多，小字说明堆叠 | 重新排版：用户一行 → 分类 → 草稿 → 处理步骤，诊断信息收进“更多” |
| 处理步骤只是文字，客服还得自己去查 | 步骤直接带上查询和填 Bug 单按钮，后台 21 类只读记录接入侧栏 |
后端部署只替换了两个文件、只重启了助手服务，部署前备份、部署后逐项核对哈希，并留好了一键回滚命令。
怎么判断它有没有用
客服不会去点“采纳 / 不采纳”，所以用的是事后对比：把助手当时给出的草稿和客服当天实际发出去的消息逐条比较。
第一次对比得到的几个数（汇总比例）：
- 轮到客服回复时，约 26% 的回复和草稿文字明显相似（这是文本相似度，只能算采纳的上限参考，不等于客服真的用了草稿）；
- 草稿中位长度约 98 字，客服实际发出的中位只有 27 字；
- 约 52% 的草稿是在客服已经回复之后才生成的，来得太晚。
这几个数直接决定了下一步：草稿要更短、更像客服本人的口吻；客服刚回复过的会话不再生成；把对比做成每天自动出的报告。
踩过的坑
- 批量改历史数据会连锁影响别的系统。一次性重分配几万个会话，会刷新它们的“更新时间”，导致知识流水线的增量导出超出上限、连续失败。之后所有批量操作都要先和流水线约好补跑方案。
- 关键词规则做分类，够用但不够准。抽查发现“麦克风道具”被分到“麦克风故障”、“举报别人”被分到“封号原因”。后来改为语义判断加独立复核，并给拿不准的会话留了“待人工确认”这个出口，而不是硬塞进某个分类。
- 停用分类也有副作用。旧分类一停用，历史会话的编辑弹窗里分类就显示为空，客服点保存可能把原分类清掉。所以先只停用“从来没被用过”的分类；等历史会话全部迁到新分类、旧分类不再被任何会话引用后，才全部停用。
技术栈
- 前端：Chrome MV3 扩展，React + TypeScript，基于开源项目 Page Assist 改造；内容脚本读取工作台，侧栏通过白名单命令与页面通信。
- 后端：Python HTTP 服务，内网部署，本地量化开源模型推理。
- 知识：定时流水线从历史会话生成知识包，带版本、哈希与发布回读。
- 质量：前端 158 项自动化测试，后端针对时钟容差和系统消息的回归测试，上线前用 560 条真实上下文离线回放对比新旧版本。
接下来
- 每日自动对比“草稿 vs 实际回复”，作为质量的主指标；
- 建一份人工标注的评测集，再迭代分类规则和草稿风格；
- 客服已经回复的会话不再生成草稿；
- 把没有找到口径的问题回流到知识库。
---
title: 客服副驾：给人工客服用的侧栏助手
summary: 在客服工作台旁边读懂当前会话，给出回复草稿、处理步骤、记录查询和会话分类；消息始终由客服本人发送。
date: 2026-11-07
category: 工作成果
featured: true
---
> 本文为个人工作记录。文中的平台、用户、对话和数据均已去敏：对话为改写示例，数字只保留汇总比例，不含任何真实账号、域名、地址或客户内容。
**一句话**：一个装在浏览器侧栏里的客服助手。客服打开一个会话，它就读懂这段对话，给出一份可以直接改、直接填的回复草稿，告诉客服这次该怎么处理，并且把查记录、填 Bug 单、选分类这些重复动作做到只差最后一步。
[打开网页演示 ↗](/uploads/demo/customer-copilot/)
## 背景：客服每天在做什么
服务的对象是一个在线配音与语音社交平台。用户会因为各种事情找人工客服：充值没到账、抽奖扣了钻石没出东西、账号被封想申诉、活动任务明明完成了却没算、关系位解除不了……
一位客服的日常大致是这样：
1. 在后台工作台打开会话，读完用户前后发的几条消息；
2. 去另一个后台页面，按用户 ID 查充值、流水、抽奖、封禁记录；
3. 回忆或翻找对应的处理口径，组织一段回复；
4. 如果是技术问题，再打开“创建 Bug”，挑聊天记录、写标题；
5. 最后给会话选一个分类，方便后续统计。
每一步都不难，但会话一多，来回切页面、复制 ID、翻规则的时间就积起来了，回复口径也很难统一。
## 它是什么
一个 Chrome 侧栏扩展，加上一套内网部署的后端。
| 部分 | 做什么 |
|---|---|
| 侧栏扩展 | 读取工作台里**当前打开的会话**，展示草稿、处理步骤、分类建议和记录查询，所有按钮都只作用于当前会话 |
| 回复后端 | 部署在公司内网，用本地运行的开源模型生成草稿和处理计划，不调用外部服务 |
| 知识流水线 | 每两小时从历史会话和客服实际回复里整理知识包，交给后端使用 |
几条一开始就定下、后来一直没变的边界：
- **消息永远由客服本人发送**。助手可以把草稿填进输入框，但不会替客服点发送、不会领取或结束会话。
- **草稿和会话强绑定**。每份草稿都带着会话、用户、最后一条消息等标识；客服切到别的会话或用户又发了新消息，旧草稿就不能再填入，避免“把 A 的回复发给 B”。
- **查询只读、只查本人**。记录查询固定为当前会话用户的最近 10 条，结果只显示在侧栏，不发给模型。
- **关键动作留最后一步给人**。Bug 单自动填好，但“提交”由客服点。
## 一次会话里，客服看到什么
以一个改写过的例子说明。用户发来：
> 我昨晚抽了个十连，扣了 500 钻，结果啥都没出，是不是被吞了？
侧栏从上到下依次是：
**1. 用户一行**：昵称、等级、注册时长、情绪标记（例如“着急”），以及一排常用查询：钻石、充值、道具、抽奖、封禁、设备。
**2. 分类建议**：`营收活动 › 抽奖与概率`。客服点“提交分类”，助手在工作台里选好这个分类并保存；如果后台找不到完全对应的分类，就不保存，提示客服手动选。
**3. 回复草稿**（可直接编辑，显示字数）：
> 您好，十连抽奖每一次都会有对应结果，我这边先帮您核对一下昨晚的扣钻和抽奖记录，确认后马上回复您，请稍等一下哦。
**4. 这次怎么处理**，按问题拆成卡片，每一步旁边是能直接执行的按钮：
1. 核对钻石流水里昨晚的扣费 → `查钻石流水`
2. 核对同一时间的抽奖记录和获得物品 → `查抽奖记录`
3. 如果扣了钻但没有任何结果，整理截图交技术核查 → `填好 Bug 单`
点“查钻石流水”，侧栏里直接出现：
| 时间 | 内容 | 金额 |
|---|---|---|
| 11-05 21:14 | 抽奖消耗 · 余额 1,200 | −500 |
| 11-05 20:02 | 充值 · 余额 1,700 | +600 |
点“填好 Bug 单”，工作台里的创建 Bug 弹窗会被打开、相关的几条聊天被勾上、标题填成“十连扣钻无结果 · 用户×××”，客服检查后自己点提交。
## 几个细节设计
**把“已经做了”改成“会去做”**。模型很容易写出“已为您记录”“已帮您核实”，而客服其实还没做。这类句子会在草稿里被标出来，旁边一个按钮“改成‘会××’”，一键变成“会为您记录”。只在客服点了之后才改。
**系统消息先翻译再分析**。工作台里夹杂着排队、转人工、留言表单等系统消息，原样是一段 JSON。送去分析前先转成简短文字，例如：
```
[留言表单] 分类：充值问题；内容：充了 30 元没到账，附件 2 个
```
这样模型能读到用户真正的诉求，而不是一堆字段名。
**二次进线自动标记**。同一用户上一次会话结束后 24 小时内又来，标题前自动加“【二次】”。这比让客服手动选一个“二次会话”分类更准，也不占用分类本身。
**魔法棒直接优化**。草稿旁的魔法棒点一下就改写语气，可撤销；不弹面板、不让客服再做选择。
## 分类体系重做
旧的会话分类有 500 多个，层级混乱、同义重复，很多从没被用过。结合近两个月的会话诉求，重新设计成 **12 个一级、36 个业务二级**，另加一个“待人工确认”：
账号与安全 · 处罚与申诉 · 举报投诉 · 充值与权益 · 营收活动 · 内容活动 · 道具与装扮 · 社交关系 · 语聊房 · Pia戏与配音创作 · 技术问题 · 建议与其他
其中最关键的一刀是**把“活动”拆成营收活动和内容活动**：
- 送礼、充值、抽奖、返利类的问题，归**营收活动**；
- 杀青、走本、投稿、评选类的问题，比如“明明杀青了任务为什么没完成”，归**内容活动**；
- 两类之间不设“混合”，这是和业务方确认过的。
切换分两步走：
1. **先保守**：新树全部新建，旧分类只停用从没用过的；用关键词规则先把约 4 万个历史会话归到新树，能确定的才写，并保留逐条回滚台账。
2. **再全量**：抽查发现关键词规则有明显错分后，改为逐条语义判断，再用另一个模型独立复核一遍，对全部约 6.2 万个历史会话重新归类。拿不准的（只有图片、上下文不足、活动类型没有依据）统一放进“待人工确认”，约占 19%，不硬分。每条保存后立即回读，确认只改了分类、标题和状态没被动过。最后 500 多个旧分类全部停用但不删除，历史会话里已没有任何旧分类引用。
## 这一版解决了什么
这一版（扩展 0.2.23 / 后端 backend.3）是在接手项目后，先看数据再动手：
| 发现 | 处理 |
|---|---|
| 有一批分析请求在调用模型前就被拒绝（集中在两天里，一度占当时请求的相当比例）：坐席电脑时钟和服务器差几秒，后端零容差判定“消息时间晚于快照” | 后端允许 120 秒时钟误差，前端把快照时间对齐到最新消息 |
| 约 90% 需要修改的草稿里有“已记录 / 已核实”这类没做过的承诺 | 草稿内标出并一键改写 |
| 系统消息原样送给模型，干扰判断 | 7 类系统消息转成短文字 |
| 侧栏信息太多，小字说明堆叠 | 重新排版：用户一行 → 分类 → 草稿 → 处理步骤，诊断信息收进“更多” |
| 处理步骤只是文字，客服还得自己去查 | 步骤直接带上查询和填 Bug 单按钮，后台 21 类只读记录接入侧栏 |
后端部署只替换了两个文件、只重启了助手服务，部署前备份、部署后逐项核对哈希，并留好了一键回滚命令。
## 怎么判断它有没有用
客服不会去点“采纳 / 不采纳”，所以用的是**事后对比**：把助手当时给出的草稿和客服当天实际发出去的消息逐条比较。
第一次对比得到的几个数（汇总比例）：
- 轮到客服回复时，约 **26%** 的回复和草稿文字明显相似（这是文本相似度，只能算采纳的上限参考，不等于客服真的用了草稿）；
- 草稿中位长度约 **98 字**，客服实际发出的中位只有 **27 字**；
- 约 **52%** 的草稿是在客服已经回复之后才生成的，来得太晚。
这几个数直接决定了下一步：草稿要更短、更像客服本人的口吻；客服刚回复过的会话不再生成；把对比做成每天自动出的报告。
## 踩过的坑
- **批量改历史数据会连锁影响别的系统**。一次性重分配几万个会话，会刷新它们的“更新时间”，导致知识流水线的增量导出超出上限、连续失败。之后所有批量操作都要先和流水线约好补跑方案。
- **关键词规则做分类，够用但不够准**。抽查发现“麦克风道具”被分到“麦克风故障”、“举报别人”被分到“封号原因”。后来改为语义判断加独立复核，并给拿不准的会话留了“待人工确认”这个出口，而不是硬塞进某个分类。
- **停用分类也有副作用**。旧分类一停用，历史会话的编辑弹窗里分类就显示为空，客服点保存可能把原分类清掉。所以先只停用“从来没被用过”的分类；等历史会话全部迁到新分类、旧分类不再被任何会话引用后，才全部停用。
## 技术栈
- 前端：Chrome MV3 扩展，React + TypeScript，基于开源项目 Page Assist 改造；内容脚本读取工作台，侧栏通过白名单命令与页面通信。
- 后端：Python HTTP 服务，内网部署，本地量化开源模型推理。
- 知识：定时流水线从历史会话生成知识包，带版本、哈希与发布回读。
- 质量：前端 158 项自动化测试，后端针对时钟容差和系统消息的回归测试，上线前用 560 条真实上下文离线回放对比新旧版本。
## 接下来
- 每日自动对比“草稿 vs 实际回复”，作为质量的主指标；
- 建一份人工标注的评测集，再迭代分类规则和草稿风格；
- 客服已经回复的会话不再生成草稿；
- 把没有找到口径的问题回流到知识库。