Tanghj.
下载简历下载简历
MVP 已完成 · 试点运行中AI 质检质量运营人机协同

面向银行企微客服场景，将完整会话标准化后，协同统计、规则与大模型完成服务、营销和合规质检，并以证据、评分、复核与配置追溯形成质量运营闭环。

企微客服智能质检运营平台

把服务结束后的客服对话，转化为可解释、可复核、可持续运营的质量结果

项目承接既有 AI+RAG 的事中答复辅助能力，进一步解决服务结束后的质量管理问题：按业务日期组织会话，通过混合智能生成结构化事实，进入三级评分与人工复核，帮助管理者从结果下钻到问题、证据和责任边界。

项目周期
2026.04—2026.06
项目角色
AI 产品经理 / MVP 开发
服务对象
网络金融部企微客服管理团队
协作团队
业务部室、金融科技部、客服外包团队

产品截图来自匿名化合成演示数据，不包含真实客户身份、联系方式、证件信息、账户信息或内部域名。

项目主视觉为抽象示意，不包含真实客户对话或内部系统信息。
业务问题
事后质量管理仍依赖结果统计、少量抽查和投诉回看，真实服务过程与低频高风险难以持续看见。
核心方案
以标准化完整会话为中心，分层组合统计、规则、大模型、评分与人工复核，并用配置快照保证追溯。
项目结果
完成从会话获取、智能判断、评分展示到人工复核和配置管理的 MVP 产品闭环，进入业务部室试点。
个人贡献
负责问题建模、评价体系、产品与 AI 机制设计、MVP 开发验证，并协调业务与科技团队衔接正式建设。
01

项目概览

从答复辅助延伸到服务结束后的质量运营

项目不是再做一个客服问答助手，而是为服务、营销与合规质量建立可批量生产、可解释、可复核的运营机制。

MVP 已经完成，业务部室试点运行中，还有其他需求需要研发，暂时还没正式上线生产。

下方规模数据只用于解释人工管理压力和产品设计背景，不代表 MVP 已经全量处理对应数据，也不作为生产成效口径。

工作日平均会话量
4,562 次业务规模背景，不代表系统已全量处理。
工作日平均消息量
51,491 条业务规模背景，不代表系统已全量处理。
6—50 条消息会话占比
83.5%用于说明完整会话判断的必要性。
02

业务挑战

数据已经存在，但还没有变成可运营的质量资产

既有 AI+RAG 已能在服务过程中辅助答复；服务结束后，管理仍主要依靠结果统计、少量抽查和投诉回看。随着会话规模增长，金融场景又不能只靠关键词，新的质量机制成为必要条件。

数据条件与 AI 条件已经具备：完整企微对话能够按业务日期组织，统计、规则和大模型也可以承担不同类型判断。真正缺失的是把这些能力连接成稳定、可解释、可复核的管理闭环。

质检覆盖不足，真实质量和低频高风险不可见

人工抽查只能看到很小一部分服务过程，问题往往在投诉或结果异常后才被回看。

具体表现
抽查样本有限，难以持续覆盖日常会话与低频风险。
根本原因
会话规模超过人工逐条检查能力，缺少批量处理机制。
业务影响
管理者无法稳定判断真实质量分布，也难以及时发现风险。
支撑证据
工作日平均 4,562 次会话、51,491 条消息；仅作为业务背景。

评价偏向数量和结果，过程标准碎片化

原有管理更容易统计触达量、办理量和结果，服务过程中的专业度、态度与营销适当性缺少统一口径。

具体表现
同类问题依赖经验判断，服务、营销与合规标准分散。
根本原因
过程要求尚未映射为统一、可计算又可解释的评价体系。
业务影响
跨团队比较、问题归因和辅导改进缺少一致依据。
支撑证据
评价标准需同时覆盖客服视角、客户视角与合规否决口径。

对话价值、证据链和管理闭环没有形成

对话沉淀下来，但结论、证据、复核与配置迭代仍相互割裂。

具体表现
发现问题后需要重新翻查长对话，修正结果也难以反哺规则和模型。
根本原因
缺少贯通原始会话、智能判断、业务评分与人工复核的数据链路。
业务影响
问题难定位、结论难追溯、标准难持续优化。
支撑证据
83.5% 的会话包含 6—50 条消息，单条消息无法承载完整证据。
问题不是没有对话数据，而是缺少将对话转化为标准化、可解释、可运营质量数据的机制。
03

关键决策

五项决定共同约束结果的可信度与可运营性

这些不是功能清单，而是在规模、语义复杂度、金融合规和持续迭代之间做出的产品取舍。

完整会话，而不是单条消息

业务约束
客服问题、回复、追问与结果分散在多轮上下文中，单条消息无法确认语义、责任和证据。
产品决策
以完整会话作为最小质检对象，按业务日期获取消息后完成角色、顺序与会话边界标准化。
选择原因
让分类、判断、评分和复核共享同一上下文，证据能够回到具体轮次。
代价与边界
上下文更长、处理成本更高；必须控制会话拼接、超长文本和异常边界。
01完整会话，而不是单条消息
业务约束
客服问题、回复、追问与结果分散在多轮上下文中，单条消息无法确认语义、责任和证据。
产品决策
以完整会话作为最小质检对象，按业务日期获取消息后完成角色、顺序与会话边界标准化。
选择原因
让分类、判断、评分和复核共享同一上下文，证据能够回到具体轮次。
代价与边界
上下文更长、处理成本更高；必须控制会话拼接、超长文本和异常边界。
02混合智能，而不是一个大模型包办
业务约束
统计事实、明确规则、开放语义和合规责任对稳定性、成本与解释性要求不同。
产品决策
统计程序处理确定性事实，规则引擎处理明确口径，大模型处理语义判断，人工承担争议复核。
选择原因
把每类任务交给最合适的机制，兼顾稳定执行、语义理解与责任确认。
代价与边界
路由与结果融合更复杂，需要统一输入、输出协议和失败状态。
03模型判断、业务评分和合规治理分层
业务约束
模型擅长判断事实与语义，但业务分值、权重、不适用和一票否决属于可配置管理口径。
产品决策
模型只输出结构化事实、理由和证据；评分层映射业务口径；合规风险独立治理。
选择原因
评价标准变化时无需重新定义模型任务，也避免高风险被其他得分平均掉。
代价与边界
需要维护判断字段与评分配置的稳定映射，并进行发布校验。
04普通会话合并判断，复杂样本条件式精检
业务约束
逐指标调用成本高、链路长；完全合并又会削弱复杂场景的判断质量和证据颗粒度。
产品决策
普通会话合并完成同类判断，命中特定场景或复杂条件时再路由到精细质检任务。
选择原因
在日常覆盖效率与复杂样本判断深度之间取得平衡。
代价与边界
需要持续校验分类与路由条件；误路由可能造成漏检或不必要成本。
05配置绑定任务快照，人工修正不覆盖 AI 原始结果
业务约束
规则、模型、提示词和评分配置会迭代；若历史任务读取最新配置或覆盖原始结果，就无法复现。
产品决策
任务启动时绑定配置快照，同时分别保留 AI 原始结果、人工复核结果与最终有效结果。
选择原因
支持历史追溯、版本比较、争议复盘和后续评测。
代价与边界
增加版本、存储和状态治理复杂度，但这是金融质量结果可解释的必要成本。
04

评价与方案

先统一如何评价，再定义系统如何承担责任

评价体系回答什么是好服务，整体方案回答不同机制如何生产、校验和治理这个结果。

双视角三级评价体系

客服视角衡量专业执行，客户视角衡量感受与接受度；两者并行，避免只看员工动作或只看结果。

双视角三级评价体系图；图中为评价配置口径，不是项目效果数据。

评价体系将客服执行与客户感受同时纳入同一结构，用三级指标承接服务、营销与合规要求；网页不重复铺开图中的全部指标。

  • 不适用项不进入该会话评分，避免把没有发生的场景当作零分。
  • 零分表示适用但未达到要求，与不适用严格区分。
  • 合规风险采用否决口径，不被服务或营销得分抵消。
05

产品与系统

先看产品能力全景，再进入三个核心闭环

总体架构呈现稳定的产品能力层；完整功能树通过二级 Tab 渐进展开，正文重点保留结果生产、问题复核和配置优化三个闭环。

产品能力全景架构

从用户任务出发理解质检中心、驾驶舱、复核与配置能力如何协作。

产品总体架构图；点击可放大，移动端可横向查看。

架构从管理者、质检人员与配置人员的任务出发，组织质检生产、质量分析、对话复核和持续配置能力。

当前闭环

质检结果生产闭环

把原始消息稳定转化为可评分、可解释的质检结果。
  1. 按业务日期取数
  2. 标准化完整会话
  3. 任务路由与混合判断
  4. 结构化结果入评分

核心能力

  • 任务创建与运行状态
  • 会话标准化与分类
  • 统计 / 规则 / 模型协同
  • 失败记录与结果入库
运行机制图展示任务、会话、智能判断、评分与结果入库如何连接。
06

AI 与数据

五步把原始消息变成可治理的质量结果

每一步明确输入、处理、输出和可信机制；AI 原始结果、人工复核结果与最终有效结果在第五步统一治理。

当前机制

数据获取与标准化

按业务日期获取企微消息，关联为角色、顺序和边界明确的完整会话。

输入

  • 业务日期
  • 消息记录
  • 会话关联信息

处理

  • 清洗无效记录
  • 识别客服与客户角色
  • 排序并聚合完整会话

输出

  • 标准化会话
  • 原始消息关联
  • 处理状态
07

推进与协同

从评价标准建模到业务部室试点

四个阶段围绕一个主线推进：先证明判断链路成立，再补齐运营能力，并与正式研发建设衔接。

  1. 阶段一

    业务问题与评价标准建模

    梳理现有管理方式、对话规模与质检目标，把服务、营销和合规要求转换为双视角三级评价体系。阶段输出：问题定义、评价口径与 MVP 边界

  2. 阶段二

    主链路 MVP 验证

    验证从消息获取、会话标准化、混合判断到结构化评分和证据回看的核心链路。阶段输出：可运行的端到端主链路

  3. 阶段三

    从 Demo 升级为运营产品

    补齐任务状态、失败处理、质量驾驶舱、人工复核、规则评分配置与版本管理。阶段输出：可供业务持续使用的 MVP 产品

  4. 阶段四

    业务部室试点与正式建设衔接

    在代表性会话中验证产品机制、收集后续需求，并与业务和科技团队衔接正式研发建设。阶段输出：试点运行、需求清单与正式建设输入
08

成果与复盘

清楚区分已完成成果、真实边界与个人贡献

本章不使用尚未发生的生产指标包装结果，而是呈现已交付的产品闭环、试点阶段边界、个人关键动作和可复用复盘。

已完成成果

端到端质检主链路

完成消息获取、完整会话标准化、分类路由、混合判断、结构化评分与结果展示。

质量运营产品闭环

形成质检中心、质量驾驶舱、对话证据、人工复核与配置管理相互连接的 MVP。

正式建设输入

沉淀评价体系、产品架构、AI 与数据机制及后续需求，支持业务与科技团队继续研发。

真实边界

  • MVP 已经完成，业务部室试点运行中，还有其他需求需要研发，暂时还没正式上线生产。
  • 当前成果证明的是产品链路与运营机制可运行，不代表已形成生产环境的全量处理、准确率、降本或业务改善结论。
  • 页面中的会话规模是问题背景；原始系统截图含敏感信息，完成脱敏前不作为公开证据发布。

个人核心贡献

业务与评价体系建模

把抽查、投诉回看和结果统计背后的管理问题，抽象为双视角三级评价体系及不适用、零分、否决口径。

产品与 AI 机制设计

设计完整会话、混合智能、判断与评分分层、条件式精检、配置快照和三层结果治理。

MVP 开发与跨团队推进

完成核心产品链路的 MVP 开发验证，协调业务部室、金融科技部与客服外包团队衔接试点和正式建设。

关键复盘

先建评价语言，再建 AI 任务

如果业务对什么是好服务没有一致口径，模型输出再丰富也无法进入稳定管理。评价体系应先于提示词和模型调用设计。

证据与失败状态必须是一等产品对象

金融质检不能只展示一个分数；证据、解析失败、跳过原因和人工责任确认决定结果是否可用。

试点重点是验证机制，不是提前包装成效

MVP 阶段应优先验证链路、标准、路由和复核是否成立，生产规模、准确率与降本结论必须等待正式上线后的真实数据。

产品证据

产品证据与截图

截图只用于证明产品机制；页面数据与对话内容均为匿名化合成素材。
产品能力全景架构

产品能力全景架构

页面说明产品总体架构图，展示用户入口、核心产品能力和智能数据底座。

用户任务快速理解质检生产、分析、复核与配置能力如何协作。

证明机制证明产品不是单一模型能力，而是覆盖结果生产、运营分析和持续治理的系统。

双视角三级评价体系

双视角三级评价体系

页面说明服务、营销与合规评价结构的抽象图。

用户任务理解客服执行与客户感受如何进入同一套评价口径。

证明机制证明模型判断与业务评分之间存在明确、可配置的评价层。

企业级智能质检整体解决方案

企业级智能质检整体解决方案

页面说明标准化会话、智能判断、评分复核与运营应用的总体架构。

用户任务理解不同机制的责任边界及结果如何形成。

证明机制证明统计、规则、模型、人工和配置追溯被组织在同一条处理链路中。

质检中心

质检中心

页面说明质检计划与任务运行总览页面。

用户任务按业务日期创建或查看任务，并识别运行中、成功与失败状态。

证明机制证明质检结果具备批量生产、状态追踪和失败处理机制。

质检驾驶舱7 张截图

质检驾驶舱

页面说明质量总览与维度下钻页面。

用户任务从质量分布定位服务、营销或合规问题，再进入异常会话。

证明机制证明质检结果能够进入管理分析和问题定位，而不只停留在单条结论。

对话详情与证据3 张截图

对话详情与证据

页面说明完整会话、指标判断、理由和证据片段的关联页面。

用户任务沿时间线阅读上下文，并定位某项结论对应的具体证据。

证明机制证明完整会话是质检对象，结论可以回到上下文和证据。

人工复核2 张截图

人工复核

页面说明待复核列表与单条复核处理页面。

用户任务查看 AI 原始结果和证据，追加修正意见并确认最终有效结果。

证明机制证明人工修正不覆盖 AI 原始结果，复核动作可追溯。

评分体系配置2 张截图

评分体系配置

页面说明三级指标、权重与客服 / 客户双视角配置页面。

用户任务查看一级模块、二级指标与三级指标的权重和评价视角。

证明机制证明模型判断通过可配置评分体系映射为业务评价结果。