助手面板
贴在客服 IM 聊天页右侧，跟着当前客户走。设备号、套餐、卡状态、规则建议、快捷操作常驻，不用切屏。
常驻 / 跟随客户
2026.06 — 至今 · 30–50 人生产使用
售后客服工作台
从一线客服的真实工作里长出来的自动化工具
从每天 380 个客户、5,800 条消息的真实工作出发，把跨 5 个后台的查询、判断、登记与跟进，收敛成一个桌面工作台。支撑 30–50 名客服日常使用。
会话 12
陈
陈先生设备连不上，重启也…
2
李
李女士套餐到期了怎么续？
王
王先生我换了个新手机
你好，我这张卡突然上不了网了
设备号 6500 8320
收到，我看一下您的套餐状态
助手正在查询运营商后台…
97.7%自动执行成功
25.7万进线消息已处理
示意界面 · 数据虚构
30–50名客服日常使用
257,320条进线消息
21,230条规则建议
4,700次自动执行
97.7%执行成功率
453笔业绩成功登记
一分钟了解
一个注入客服后台的助手面板 + 一套本地服务 + 一个确定性规则引擎：把跨 5 个系统的查询、判断、登记与跟进，收敛成一次点击。
本页覆盖：背景与痛点 · 功能 · 架构 · 技术栈 · 运行数据
痛点
一人一班 380 位客户；5 个后台；每单 30+ 次点击，大量时间花在搬运信息。
方案
Electron 壳 + 页面注入 + 本地 FastAPI + YAML 规则引擎；AI 只做理解与措辞。
结果
4,700 次自动执行、97.7% 成功；469 笔业绩单、453 笔成功落库。
01 / 背景
起点不是技术，
起点不是技术，
是一张每天重复 300 次的表
2026 年 6 月，我在随身 WiFi 售后岗。一个班约 380 位客户、5,800 条消息；真正用于判断的时间很少，大部分时间在五个后台之间复制、切换、截图、填表。
原来的一单
- 01客户进线先问设备号，常常要问两次问
- 02查运营商后台套餐、卡状态、是否达量、是否限速复制
- 03查售后系统订单、登记状态、能不能退/换切屏
- 04做判断部门、跨月、双记、重复登记脑内
- 05做登记截图 + 22 个字段 + 提交填表
- 06回聊天窗发话术、解释、安抚切回
- 07记跟进等下一位客户手记
5个后台
30+次点击
2–3分钟/单
我看到的三个机会
信息都在系统里，只是没有被聚合
做事实翻译层：每项事实带来源与采集时间，取不到就说“未确认”。
判断其实有固定规则，只是没写成代码
做 YAML 判断表：业务能读、测试能跑、结论能追溯到具体规则。
操作其实可以重放，只是没人把链路串起来
做端到端自动化：收集、筛查、出图、提交、复核，一条链跑完。
“如果一件事每天要做 300 次，它就不该由人来做。”
2026.06，第一版脚本之前
02 / 产品
一个壳，三种工作形态
形态不是先设计出来的，是被场景逼出来的：客服要一边聊天一边看信息，所以有面板；登记要填长表单，所以有弹窗；批量登记不能打断接待，所以有独立自动化窗口。
业务弹窗
业绩登记、退费结算、换货/补发/芯片/出省、订单查询。表单口径对齐官方后台，提交体由服务端拼。
对齐官方 / 少填字段自动化窗口
独立 BrowserWindow，同一登录态、不注入插件。批量业绩登记时主窗口照常接待，互不打断。
同账号 / 不打断
真实运行界面
377 个客户一批，
377 个客户一批，
逐行给出依据与结局
业绩登记自动化：收集 → 筛查 → 读会话 → 出图 → 提交 → 复核。每一行都能看到判定依据、当前状态、登记人与证据图；客户姓名、设备号与人员信息已脱敏。
为什么单独开窗：注入是页面级的，两个窗口会各跑一份插件；自动化窗口不注入，避免重复采集、重复执行。
03 / 架构
把登录态、判断与写操作关进本机
页面只负责展示与采集；需要凭据、需要写操作的事，全部收在 Electron 主进程与两个本地服务里。两个服务分工明确：9901 管“这个账号能用什么”，9900 管“具体做什么”。下面先看整体分层，再展开规则引擎与自动业绩两条核心链路。
用户本机 · 127.0.0.1 回环信任边界
01接入层
客服 IM 页面
注入面板 · plugin.bundle.js
聊天 / 客户 / 历史消息
自动化独立窗口
同账号 · 不注入插件
切客户 · 读 store · 截图
壳页
工具包 / 每日数据 / 网页页卡
独立分区 · 登录记忆
↓注入 / 执行 / 截图 / IPC
02壳层
Electron 主进程
窗口 / 页签 / 协议代理 / 注入幂等 / Python 守护 / 自动更新 / 通知
凭据由本机服务保管；页面拿不到上游 tokenexecuteJavaScriptcapturePagedaemonIPC / preload
↓localhost + 本机令牌 · 授权状态
03本地服务
本地业务 API · 9900
FastAPI · 按域拆包：运营商后台 / 售后 / 订单 / 业绩 / 物流
事实翻译提交体拼装幂等去重图片代理
只绑 127.0.0.1 · SQLite 台账 · 证据图留档
授权服务 · 9901
登录 · 权限快照 · 离线判定 · 身份同步
内存态不落盘设备绑定
本机权限的唯一权威
9900 ↔ 9901 · 本机令牌互认；权限快照 TTL 60s，面板以注入时的快照为准。
↓HTTPS / Cookie · 业务系统 × 云端联签
04外部与云端
外部系统
登录态由本机服务保管；页面不直接持有上游 Cookie。
客服 IM 平台运营商后台售后系统订单系统物流查询
云端策略服务器
账号 · 设备上限 · 功能开关 · 版本门禁 · AI 配置
Docker + Nginx + SQLite写操作路径：面板 → 主进程 / 9900 → 外部系统；页面永远不直接持有上游凭据。
页面零令牌
9900 / 9901 用本机令牌互认，令牌不写进网页；面板只调 localhost。
权限在内存
授权快照不落盘，改本地文件不能自授权；设备上限与版本门禁在云端决策。
凭据加密
DPAPI / Keychain；登出＝换人，一次清干净售后身份与分区存储。
写操作单点
提交体由服务端拼，面板只传设备号/订单号/截图；重复提交由三层幂等兜底。
03.1 / 规则引擎
事实 → 判断 → 建议 → 执行
不是让大模型自由发挥：事实来自真实系统，判断写在 YAML，执行有开关与回退。
输入
业务事实
运营商后台 · 售后系统 · 订单系统
卡状态套餐达量 / 限速订单登记状态
↓查询 + 事实翻译
事实层
事实目录
把不同系统的返回翻译成统一事实；每项带来源与时间，取不到就标“未确认”，不用默认值猜。
↓facts（缺失 = 未确认）
判断层
YAML 判断表
四类工作流：续费复机 / 新用户激活 / 套餐到期或用超 / 无线定向限速；输出 decision + reason codes。
↓decision + reason codes
执行层
Python 计算器 / 执行器
人工批准或自动开关放行；写操作幂等；结果回写建议状态与执行记录。
↓action
输出
业务动作
发话术 / 复机 / 登记 / 跟进；失败转人工，不把猜测当结论。
AI 的边界
只做理解与措辞
大模型可以理解口语、改写客服话术；但不决定是否付款、是否复机、是否退款。AI 不可用时回退固定模板。
运行数据
可解释、可追溯
21,230条建议
4,700次自动执行
97.7%成功率
每次命中都能追到规则版本、事实来源与执行结果。
放行方式
影子 → 批准 → 有限自动
先只展示建议，再开放人工批准，最后只对低风险场景开启自动执行；任何异常回退人工。
03.2 / 自动业绩
一条可复核的批量登记链
主窗口照常接待，自动化窗口在后台完成收集、筛查、读会话、出图与提交；每一步都可回查。
01
收集
待办队列
星标客户 / 佣金台账；100 个一批，自动接批。
02
筛查
订单事实
按设备号查运营商后台；判定可登记 / 待观察 / 无效。
03
读会话
语义核对
切客户、读聊天记录；确认引导与订单锚点。
04
出图
证据
独立窗口截图；证据图留档，可人工复查。
05
提交
售后系统
服务端拼 22 字段提交体；三层幂等防重复。
06
复核
清星标
查登记状态；成功清星标，失败分类处理。
↺ 一批跑完自动接下一批；复查池 / 捡漏从旁路进入收集。
参与方
客服主窗口人工接待，不受影响
自动化窗口同账号 · 不注入插件
Electron 主进程执行 JS · 截图 · 开关窗口
本地 9900编排 · 判定 · 台账 · 门禁
外部系统运营商后台 · 售后系统 · 云端
关键保障
三层幂等证据图留档两个复查池断点续跑主窗口不受影响
1,328客户入库
4,305条任务
469笔登记单
453笔成功落库
04 / 功能
从进线到结案，
从进线到结案，
八个高频动作
不是把按钮堆在一起，而是把一条真实工作流拆成可复用的段：监听、识别、查事实、给判断、做动作、留痕迹。
进线监听
WebSocket 主通道，过滤同事、已回复、非客户方向消息；后台标签页用只读 Vuex 快照 + WS 心跳补漏，不增加接口轮询。
257,320 条事件 · 9,664 会话设备号识别
备注/昵称 → 当前消息 → 今日历史 → 图片识别；多设备号手动选择；识别后缓存 openid → 设备号并预取后台信息。
4 级来源 · 自动索要最多 2 次事实聚合
运营商后台的单卡/设备/订单/复机停机；每项事实带来源与采集时间，取不到就是“未确认”，不用默认值猜。
来源 + 时间可追溯规则诊断
续费复机、新用户激活、套餐到期/用超、无线定向限速四类工作流；YAML 判断表 + 计算器 + 事实翻译三层。
21,230 条建议 · 4,700 次执行业绩自动化
收集 → 筛查 → 读会话 → 出图 → 提交 → 复核；100 个一批自动接批；两个复查池 + 捡漏 + 订单系统双记。
1,328 客户 · 469 笔登记单售后登记
换货、补发、芯片、出省、代申请、电客工单、工单跟进；地址校验、收件人识别、重复登记核对。
7 类登记 · 一条表单链退费与收款
4 种定价模型试算；线上退款；线下退费（图片、multipart、重复核对）；自定义收款文案与支付链接。
试算 → 提交 → 追踪运营与体验
好评引导按话术 ID 判定；跟进列表、响应统计、快递查询、9 个自定义网页页卡 + 登录记忆。
好评 / 跟进 / 统计 / 页卡
05 / 难点
真正难的不是写功能，
真正难的不是写功能，
是让它在真实系统里可靠
没有文档、会改版、有限流、有交接班、有上游缺陷。下面六个点，是系统落地时最难、也最值得说明的部分。
没有文档的后台，怎么接？
目标系统只有网页，没有开放 API；登录态是 HttpOnly cookie，提交体有 22 个字段，还带重复登记校验。
- 抓包 + 读前端 chunk 还原字段与顺序
- 本机服务复用登录态并代理，页面不接触凭据
- 提交体由服务端拼，面板只传设备号/订单号/截图
- 提交前查重、失败分类、撞 400 补建档自愈
结果：售后 7 类登记全部可提交；469 笔业绩单，453 笔成功落库。
为什么不让大模型直接判？
大模型能理解口语，但不能决定客户是否付款、能不能复机、该不该退款。错一次就是业务事故。
- 三层：YAML 判断表 / Python 计算器 / 事实翻译层
- 事实必须带来源与时间；取不到就标“未确认”
- AI 只做理解与措辞；写操作必须人工批准或规则放行
- 影子模式 → 人工批准 → 有限自动化，逐级放开
结果：4,700 次自动执行，97.7% 成功；每次命中都能追到规则与事实。
在别人的页面里跑代码，怎么不被拖垮？
页面会改版、后台标签页会降频、重复注入会出现两份互不感知的实例。
- 标记 + bundle 哈希做幂等注入，同版本不重复 eval
- 功能开关缺省拒绝；页面只保留按需片段
- 后台补漏只读 Vuex 快照 + WS 心跳，不轮询接口
- 自动化放主进程/独立窗口，不跟接待抢页面
结果：25.7 万条事件稳定处理，历史“双查/双发”事故不再出现。
为什么业务日定在 7:30，
还留 15 分钟窗口？
客服四班倒，通宵班在早上交接。0 点清缓存会打断正在处理的会话；随时清，早班又接不上上一段。
- 业务日 7:30 结算，运行期跨过 7:30 刻意不清
- 7:15–7:30 启动：把上一业务日续进新的一天
- 窗口外启动：丢弃上一个业务日
- 标签表 / 诊断缓存 / 设备快照三处同口径
结果：交接时段不丢状态；这是用户最在意的体验之一。
2248 行的上帝函数，怎么拆？
面板 ui.ts 2248 行，AR_createPanel 一个函数 2018 行、46 个嵌套闭包；每次改弹窗都怕碰坏别的弹窗。
- 先写 883 条 CSS 基线 + 114 条无头 Electron 断言
- 再拆 11 个模块：外壳 / 面板 / 功能 / 工具
- 宿主 798 行，函数 171 行；每次提交跑基线
结果：AR_createPanel −92%，视觉零变化，后续加弹窗不再牵一发动全身。
30–50 人的安装与升级，
怎么管？
账号在业务系统，功能权限在自建云，版本发布也在业务系统；客户端要能离线判定，又不能被本地改文件自授权。
- 三方联签：业务系统账号 × 云端策略 × 版本门禁
- 权限只存 9901 内存；改本地文件无效
- 自签证书 SHA-256 指纹钉扎 + 更新包 sha256 校验
- NSIS 安装、静默更新、强制更新、设备上限/解绑
业务系统账号→云端策略→版本门禁→本机内存快照
结果：客户端 2.4.9，云端 v38；人员变动可回收账号，不依赖本机。
06 / 数据
近半年，系统实际跑出了什么
以下数字来自本机 SQLite（agent_observe.sqlite / claim_automation.sqlite），统计截至 2026-10-28；不是估算，也不是演示数据。
source: agent_observe.sqlite · claim_automation.sqlite自动执行成功率
4,700 次97.7%success
成功 4,591
失败 109
自动执行按工作流
21,230 条建议 · 4,700 次自动执行业绩自动化：从客户到落库
43 轮 · 单批 100 个1,328客户入库
43轮自动化
4,305条任务
469笔登记单
453笔成功落库
453 = 414 笔单记 + 39 笔双记；其余 16 笔为上游拒绝、异地已登、状态不符/无证据。成功提交均留有证据截图与判定依据。
工程体量
独立开发 · 近半年9.8万行 Python + TS
121个测试文件
284次提交
67篇文档
Python 5.0 万 + TypeScript 4.8 万；不含依赖与构建产物。文档按总览 / 接口契约 / 桌面端 / 客服 Agent / 云端与发布分类。
07 / 场景
三个关键落地场景
真实业务里的三个关键取舍，决定了系统今天的形态。
把 300 次点击变成 1 次
背景
每个客户要截图、填 22 个字段，还要判断部门、跨月、双记、重复登记。人工一天只能登几十单，且容易漏。
动作
把流程拆成五步状态机；订单事实改运营商后台原站直查，10 台筛查从 28.2s 降到 4.7s；100 个一批自动接批；三层幂等 + 证据截图 + 两个复查池 + 捡漏。
结果
1,328 个客户、4,305 条任务、469 笔登记单、453 笔成功落库；主窗口不受影响，客服照常接待。
反思
全自动的前提不是“敢点”，而是可回滚、可复核、可追责。
10 台筛查 28.2s → 4.7s单批 100 个证据图留档双记 39 笔
给飞行中的飞机换发动机
背景
面板 ui.ts 2248 行，一个函数 2018 行；线上每天几十人在用，不能停机重写。
动作
先补 883 条 CSS 基线和 114 条无头 Electron 断言，再拆 11 个模块；宿主只做装配，模块各自负责；每次提交跑基线。
结果
宿主 798 行、函数 171 行（−92%）；视觉零变化；后续新增弹窗不再改一处崩三处。
反思
重构的勇气来自测试，不是来自“我觉得没问题”。
2248 → 798 行2018 → 171 行883 条 CSS 基线114 条 Electron 断言
东莞没有区
背景
东莞、中山是直筒子市（不设区县的地级市）；上游地址校验把这种结构判成“地址冲突”，提交被拦。
动作
没有硬绕校验：把冲突降级为一次人工确认（“我已核对”），保留原始校验证据；同时把问题提给后端并行修复。
结果
真机可提交，操作从多次来回降到一次点击；后端修复不阻塞业务。
反思
遇到上游缺陷，先分清“我能安全降级”与“我必须推动修复”，不要用绕过换短期顺利。
直筒子市一次人工确认保留校验证据推动上游修复
08 / 工程
独立开发，也要有发布纪律
独立开发最容易欠的是发布纪律。这个项目的做法是：把检查写成命令，把口径写进文档，把版本收成一个来源。
提交前的质量门
npm run check✓
tscTS strict · 0 any✓
eslint0 warning✓
ruffPython 静态检查✓
test:modules38 个 TS 模块测试✓
test:python45 个 Python 测试✓
test:desktop35 个 Electron 测试✓
smoke:panel261 / 267 通过✓
NSISWindows 安装包面板冒烟有 6 条既有的展开动画断言未通过，作为已知基线单独跟踪，不计入业务回归。
近半年，从脚本到规模化使用
2026.06 — 2026.102026.06 · 原型脚本
查设备、回话术；先让每天少点 100 次重复操作。
2026.07 · Electron 壳
注入面板进同窗；首位外部用户开始使用。
2026.08 · 规则引擎
事实 / 判断 / 执行分层；售后登记与云端授权上线。
2026.09 · 业绩自动化
469 笔登记；面板重构 −92%；视觉基线建立。
2026.10 · 规模化使用
30–50 人使用；v2.4.9；云端交接与每日数据。
平台口径Windows EXE 是唯一验收平台；macOS 只用于开发。
契约先行接口契约来自真实抓包，脱敏后固化为 fixture；测试不连生产。
改动纪律新功能必须带文档与测试；版本号单一来源 launcher.py。
交付安全自签证书指纹钉扎；更新包 sha256；云端版本门禁。
09 / 技术栈
选型围绕三个约束：
选型围绕三个约束：
Windows 交付、本机安全、页面稳定
没有为了技术而技术。每一项选型，都能对应到一个具体的交付约束或踩过的坑。
Electron + Vue 3
需要同时托管多个登录态、注入客服页面、管理本地服务与自动更新；Electron 是能同时满足 Windows 交付与浏览器能力的方案。
Electron 33TypeScript strictVue 3Viteesbuild
FastAPI + SQLite
凭据、上游请求与写操作收在本机；FastAPI 轻量、类型友好，PyInstaller 可以把整个服务打进 Windows 安装包。
Python 3FastAPISQLitePyInstallerhttpx
单文件 Bundle
不依赖浏览器扩展安装；esbuild 产出单文件 IIFE，壳按内容哈希幂等注入，页面只保留按需片段。
TypeScriptesbuildWebSocketXHR 补丁Vuex 只读快照
YAML 规则表
业务判断必须可解释：规则用 YAML 写、Python 计算、事实带来源；AI 只做理解与措辞，不碰写操作。
YAMLPython 计算器事实目录云端 AI影子模式
Docker + NSIS
云端只做授权与配置下发，权限判断在内存；客户端用 NSIS 安装、自动更新、版本门禁与证书指纹钉扎。
Docker ComposeNginxSQLiteLet's EncryptNSISelectron-builder
测试基线先行
重构和发布都依赖可重复的检查：契约 fixture、视觉基线、无头 Electron 断言、Python 单测与面板冒烟。
ESLintRuffNode testheadless Electroncontract fixturespanel smoke
10 / 总结
三个设计原则
01 / REAL
从真实业务出发
不是 demo，是 30–50 人每天用的生产工具；每个功能都能追到一个具体的人、班次或单据。
02 / CONTROL
把不确定性关进笼子
事实有来源，判断有规则，写操作有批准、证据与回退；AI 只做它擅长的事。
03 / END-TO-END
独立完成端到端交付
调研 → 架构 → 编码 → 测试 → 打包 → 部署 → 推广；遇到不会的就拆小、验证、再落地。
项目状态
已交付 30–50 名客服使用；客户端 v2.4.9；云端策略服务已做交接准备。
适用场景
售后客服团队；需要跨多个后台查询、判断与登记的岗位；批量业绩/工单登记；新人培训与口径统一。
后续规划
规则可视化编辑；多租户云端配置；更细的权限与审计；可观测性看板。
经验总结
更早建立契约 fixture；更早把 UI 与业务逻辑分层；更早做结构化日志与看板，少靠 grep。
项目说明
项目介绍；已隐去客户个人信息、账号凭据与接口密钥。界面为示意或脱敏截图。