Главная Обзор Помощь
Вход
18307996893
/
QIWEI-skill
1
0
Ответвить 0
Файлы Задачи 0 Запросы на слияние 0 Вики
Дерево: 60b3a717ce
Ветки Метки
QIWEI-skill
/
docs
/
specs
/
qiwei-group-operations-product-development-spec.md

qiwei-group-operations-product-development-spec.md 23 KB
История Исходник

企微客户群标准化运营与督导——产品开发文档

文档状态：方案初稿 版本：v0.1 日期：2026-07-18 适用项目：claude-code/claude-code-qiwe-assistant

1. 背景与问题

企业客户群目前缺少公司级运营标准，群运营依赖门店员工个人经验，导致：

  • 没有统一的群运营 SOP、服务话术和内容节奏；
  • 总部无法知道门店是否执行、执行质量如何；
  • 没有专门运营团队，店员需要从零策划和撰写内容；
  • 客户问题、购买信号和投诉可能无人响应；
  • 不同门店服务质量差异大，无法复制优秀经验；
  • 群数量增长后，管理者无法逐群查看和督导。

现有系统已具备群发现、群确认、群消息同步、单聊 Agent、人工审核、任务、预警和审计能力，但尚未形成以下业务闭环：

flowchart LR
  A["总部制定标准"] --> B["按群生成运营计划"]
  B --> C["门店审核并执行"]
  C --> D["同步群消息与执行结果"]
  D --> E["自动质检与风险识别"]
  E --> F["生成整改任务与管理看板"]
  F --> A

2. 产品目标

建设“企微社群运营中心”，把总部运营标准转化为门店每天可执行的任务和话术，并通过群消息证据自动监督执行质量。

首期目标：

  1. 总部可以统一定义、发布和更新群运营 SOP、话术模板与运营节奏。
  2. 门店可以通过 Agent 对话快速获得“今天该做什么、该怎么说”。
  3. 所有外发内容默认经过人工确认，发送结果全程留痕。
  4. 系统按群自动检查执行、响应、风险和活跃度，生成有原消息依据的预警。
  5. 管理者可以在 Dashboard 查看跨门店、跨群的执行率、健康度、风险和待办。

2.1 成功指标

MVP 试点建议使用 3 家门店、20 个客户群、连续运行 14 天：

指标 目标
每日计划生成成功率 ≥ 95%
到期运营任务执行率 ≥ 85%
话术人工一次采纳率 ≥ 70%
高风险消息召回率 ≥ 85%
高风险误报率 ≤ 10%
未回应问题识别准确率 ≥ 90%
质检结论可追溯到原消息比例 100%
门店日均群运营准备时间下降 ≥ 50%
未经人工确认的外发消息 0 条

2.2 非目标

MVP 暂不包含：

  • 完全无人监管的自动群聊机器人；
  • 自动决定促销价格、退款、赔偿或对客户作出业务承诺；
  • 替代企业微信官方权限、合规审批和员工管理制度；
  • 以 AI 主观判断销售业绩或员工绩效；
  • 未经授权采集或长期保存客户敏感信息；
  • 一开始建设复杂的营销自动化平台或多渠道 CRM。

3. 产品形态与功能拆分

建议对用户呈现一个统一产品模块“社群运营”，内部由四项能力组成。MVP 先建设一个 qiwei-group-operations skill，避免多个 skill 重复加载群上下文和产生路由冲突；规模扩大后再按职责拆分。

3.1 功能一：SOP 与话术标准中心

解决“公司无统一指导和标准”。

总部可维护：

  • 群类型：新客群、成交服务群、售后群、会员群、活动群等；
  • 生命周期：建群欢迎、需求了解、持续服务、活动转化、售后维护、沉默唤醒；
  • 运营节奏：星期、时间段、频次、任务类型；
  • 话术模板：欢迎、提醒、知识内容、活动、答疑、回访、投诉安抚；
  • 必做项、禁止项、升级人工条件和响应 SLA；
  • 适用门店、适用群标签、版本、生效日期和发布状态。

核心规则：

  • 草稿版本不影响已执行计划；
  • 发布新版本必须记录发布人、变更说明和生效时间；
  • 每个计划项必须保存所依据的 SOP 版本，便于审计；
  • 话术模板支持变量，但变量缺失时禁止发送，不允许把 {{customer_name}} 原样发出；
  • 禁止词、敏感承诺和高风险场景采用确定性规则兜底，不仅依赖模型。

3.2 功能二：群运营 Copilot

解决“没有运营团队、店员不会策划和写话术”。

Agent 根据群类型、生命周期、最近消息、历史执行情况和当前 SOP，生成：

  • 今日/本周运营计划；
  • 每个计划项的建议时间、目标、话术草稿和执行说明；
  • 针对当前群上下文改写后的个性化话术；
  • 发送前风险检查和需要人工补充的变量；
  • 门店员工的待办清单。

执行状态：

draft → pending_review → approved → sending → sent/failed → verified

另有 skipped 和 cancelled，必须记录原因。

发送策略：

  • MVP 默认“Agent 生成草稿 → 人工编辑/确认 → 执行发送”；
  • 批量发送必须逐项展示目标群、最终内容、发送时间和风险检查；
  • 同一计划项使用幂等键，避免重试导致重复发送；
  • 高风险话术、投诉、退款、法律、隐私和价格承诺只能生成建议，不提供自动发送；
  • 若真实发送接口未完成 live smoke，可退化为“复制话术 + 标记已执行”，不虚报已发送。

3.3 功能三：群质检与智能督导

解决“没有监督、服务质量参差不齐”。

系统基于同步的群消息和计划执行记录检查：

  1. 节奏执行：当天必做运营动作是否按时完成。
  2. 客户响应：客户的明确提问是否在 SLA 内得到有效回应。
  3. 服务风险：投诉、负面情绪、退款、敏感词、错误承诺和冲突升级。
  4. 运营质量：连续机械刷屏、重复内容、模板变量未替换、内容与群阶段不匹配。
  5. 群活跃信号：发言人数、互动率、连续沉默和异常退群；数据不完整时明确标记“暂不可评估”。

每条质检发现必须包含：

  • 规则/模型判定类型；
  • 严重程度；
  • 原消息 ID、时间、发送者和证据片段；
  • 采用的规则或 SOP 版本；
  • 建议动作、负责人和截止时间；
  • 处理状态与处理结果。

系统不直接用一个不可解释的总分评价员工。Dashboard 可以展示“群健康分”，但必须同时展示分项得分、数据覆盖率和证据。

建议初始评分：

分项 权重 计算原则
SOP 执行 30% 到期必做项按时完成比例
客户响应 30% 明确问题在 SLA 内获得有效回应比例
服务风险 25% 未处理高风险事件扣分，已闭环事件减轻扣分
群互动 15% 活跃成员和有效互动趋势，不鼓励单纯刷消息量

若某分项缺少可靠数据，应从有效权重中排除并显示覆盖率，不按 0 分处理。

3.4 功能四：总部运营 Dashboard

解决“无法规模化管理客户关系”。

新增一级导航“社群运营”，包含五个页签：

A. 运营总览

  • 今日应执行、已完成、逾期、待审核数量；
  • 运营任务执行率、响应 SLA 达标率、高风险未闭环数；
  • 门店/账号/群类型对比；
  • 群健康分布和数据覆盖率；
  • 本周趋势与异常群 Top N；
  • 只展示能够下钻到群、计划或原消息的数据。

B. 今日工作台

  • 按紧急程度排列待审核话术、到期任务、失败发送和风险处理；
  • 支持编辑、批准、拒绝、重新生成、复制和发送；
  • 批量操作前展示影响范围和风险；
  • 门店员工默认只看自己负责的群。

C. 群运营详情

  • 群基本信息、负责人、门店、群类型、生命周期和标签；
  • 当前 SOP 版本和未来 7 天运营日历；
  • 消息时间线、执行记录、未回应问题和风险事件；
  • 分项健康指标、数据覆盖率和原消息证据；
  • “让 Agent 生成计划”“生成下一条话术”“立即质检”入口。

D. SOP 与话术库

  • SOP 列表、版本、适用范围、启停和发布；
  • 可视化节奏编辑器；
  • 话术模板、变量、禁用词和风险规则；
  • 发布前预览“哪些群会受到影响”；
  • 版本 diff 和回滚。

E. 质检与预警

  • 按严重程度、门店、群、负责人、类型、状态筛选；
  • 查看证据、确认误报、分配负责人、创建待办、处理和关闭；
  • 误报反馈进入评测集，不能直接无审计地修改历史结论。

4. Agent 对话能力设计

4.1 Skill 定位

建议新增：

skills/qiwei-group-operations/
├── SKILL.md
├── agents/openai.yaml
└── references/
    ├── data-model.md
    ├── quality-rules.md
    └── output-contracts.md

SKILL.md 只保留核心工作流、权限边界和工具选择；详细字段、质检规则和输出结构放入 references/，避免主 skill 过长。

建议触发场景：

  • “给新建的客户群做一个 7 天运营计划”；
  • “根据公司 SOP 写今天下午的群话术”；
  • “检查这 20 个群昨天有没有按要求运营”；
  • “找出超过两小时没人回复的客户问题”；
  • “汇总三家门店本周群运营情况”；
  • “把这条优秀话术保存为公司模板草稿”。

4.2 MCP 工具

首期建议提供 7 个面向业务的工具：

工具 作用 是否产生外部写操作
qiwei_group_ops_get_context 获取群、SOP、近期消息、计划和风险上下文 否
qiwei_group_ops_generate_plan 生成单群或批量群运营计划草稿 否
qiwei_group_ops_generate_copy 为指定计划项生成或改写话术 否
qiwei_group_ops_review_messages 对指定群和时间范围执行质检 否
qiwei_group_ops_daily_brief 汇总今日任务、逾期和风险 否
qiwei_group_ops_manage_playbook 创建草稿、更新、提交发布或回滚 SOP 发布/回滚需确认
qiwei_group_ops_execute_item 批准、拒绝、发送、重试、跳过计划项 发送需明确确认

工具返回继续沿用项目的标准结果信封，并增加稳定的业务字段：operationId、accountKey、roomId、evidence、requiresConfirmation、idempotencyKey 和 auditId。

4.3 对话工作流示例

用户：“给所有新客群安排明天的运营内容。”

Agent 应执行：

  1. 确认当前企微账号和用户可管理的群范围。
  2. 筛选 groupType=new_customer 且已绑定已发布 SOP 的群。
  3. 读取最近消息和未完成计划，防止内容重复或与群状态冲突。
  4. 生成计划草稿和每群话术，标出变量缺失与风险。
  5. 返回摘要：目标群数、跳过群数、待补信息、预计发送项数。
  6. 用户明确批准后才创建可执行计划；再次确认发送目标和最终内容后才外发。
  7. 写入发送结果和审计日志；失败可安全重试，不重复发送成功项。

5. 技术方案

5.1 可复用现有能力

现有能力 复用方式
qiwei-group-management 发现群、确认客户群、读取群详情、同步群消息
qiwei-customer-ops 客户档案、自动建群和欢迎语能力
Agent Workbench SQLite 复用任务、预警、审计和人工审核设计模式
Dashboard 复用账号切换、异步 job、Toast、筛选、分页和审计交互
Fmode 网关与 endpoint catalog 复用登录设备、鉴权、错误信封和群消息接口
Webhook / polling 复用增量消息入口，作为质检事实来源

5.2 必须先修正的底层问题

  1. 账号隔离：当前 outputs/groups/rooms-latest.json 等路径没有显式账号命名空间，多账号切换存在覆盖风险。新模块所有数据必须包含 account_key，文件缓存也应按账号分目录。
  2. 增量同步：当前按每个 room 从消息流起点扫描会重复消耗请求。应改为“每账号只增量拉取一次 → 按 fromRoomId 分流入库 → 保存游标”。
  3. 群会话模型：现有 conversations.contact_id 面向单聊。群运营应有独立群实体和群消息关系，不能把群 ID 伪装成客户 ID。
  4. 发送接口实测：catalog 中 /msg/sendGroupMsg 的摘要存在明显错配，不能仅凭 catalog 宣称可用。必须先对 /msg/sendText 和 /msg/sendGroupMsg 分别完成 sample/live smoke，并确认频控、回执和失败语义。
  5. 权限模型：Dashboard 当前主要是本地账号切换，新模块需要最小角色模型：总部管理员、区域/门店经理、执行员工、只读审计者。

5.3 逻辑架构

flowchart TB
  UI["Dashboard / Agent 对话"] --> API["Group Operations Service"]
  API --> PB["SOP 与话术版本服务"]
  API --> PLAN["计划与执行服务"]
  API --> QA["质检规则与 LLM 分类器"]
  API --> SEND["发送审批与幂等执行器"]
  SYNC["Webhook / 增量消息同步"] --> STORE[("Group Operations SQLite")]
  PB --> STORE
  PLAN --> STORE
  QA --> STORE
  SEND --> GATEWAY["Fmode WeCom Gateway"]
  GATEWAY --> SYNC
  STORE --> API
  API --> AUDIT["统一审计日志"]

MVP 可继续使用 Node 内置 SQLite，保持本地可部署；但数据访问必须封装为 service/store，不允许 Dashboard 路由直接拼 SQL，以便以后迁移 PostgreSQL 或多租户服务。

5.4 建议数据模型

表 关键字段 说明
group_ops_groups id, account_key, room_id, store_id, owner_id, group_type, lifecycle_stage, playbook_id, status 群运营主档，account_key + room_id 唯一
group_ops_playbooks id, name, group_type, status, current_version_id, scope_json SOP 主记录
group_ops_playbook_versions id, playbook_id, version, content_json, change_note, created_by, published_at 不可变版本快照
group_ops_templates id, version_id, scene, title, content, variables_json, risk_level 话术模板
group_ops_plans id, account_key, room_id, plan_date, playbook_version_id, status, generated_by 每群每日/每周计划
group_ops_plan_items id, plan_id, scheduled_at, type, objective, draft_content, final_content, status, idempotency_key 可审核、可执行任务
group_ops_messages id, account_key, room_id, external_message_id, sender_id, sender_role, content, message_type, sent_at, raw_json 标准化群消息，外部消息 ID 唯一
group_ops_findings id, account_key, room_id, type, severity, evidence_json, rule_version, status, assignee, due_at 质检发现与处理闭环
group_ops_daily_scores account_key, room_id, score_date, component_json, coverage, total_score 可解释的日健康指标
group_ops_send_attempts id, plan_item_id, target_room_id, request_hash, status, external_message_id, error, created_at 发送幂等、重试与回执
group_ops_audit_logs id, actor, action, entity_type, entity_id, before_json, after_json, created_at 发布、审批、发送和关闭记录

索引至少覆盖：

  • (account_key, room_id)；
  • (account_key, plan_date, status)；
  • (account_key, severity, status, created_at)；
  • (account_key, room_id, sent_at)；
  • idempotency_key 和 external_message_id 唯一索引。

5.5 Dashboard API

建议新增：

GET    /api/group-ops/overview
GET    /api/group-ops/workbench
GET    /api/group-ops/groups
GET    /api/group-ops/groups/:roomId
POST   /api/group-ops/groups/:roomId/generate-plan
POST   /api/group-ops/groups/:roomId/review

GET    /api/group-ops/playbooks
POST   /api/group-ops/playbooks
POST   /api/group-ops/playbooks/:id/versions
POST   /api/group-ops/playbooks/:id/publish
POST   /api/group-ops/playbooks/:id/rollback

POST   /api/group-ops/plan-items/:id/approve
POST   /api/group-ops/plan-items/:id/reject
POST   /api/group-ops/plan-items/:id/send
POST   /api/group-ops/plan-items/:id/skip

GET    /api/group-ops/findings
POST   /api/group-ops/findings/:id/assign
POST   /api/group-ops/findings/:id/resolve
POST   /api/group-ops/findings/:id/false-positive

通用约束：

  • 所有请求从当前登录账号解析 accountKey，不接受浏览器任意伪造；
  • 写接口要求操作者身份、角色校验和审计；
  • 发布、回滚、批量批准和发送返回变更摘要；
  • 长任务复用现有 /api/jobs/:id 异步进度机制；
  • 所有列表支持分页，禁止一次把全部群消息返回前端；
  • 原始 raw_json 默认不返回 Dashboard，仅在受控调试中使用。

6. 质检规则与模型边界

6.1 规则优先

确定性规则处理：

  • 计划是否逾期、是否已执行；
  • SLA 时间差；
  • 模板变量未替换；
  • 明确禁用词和必备免责声明；
  • 重复发送和频次上限；
  • 发送失败、账号离线和消息同步中断。

模型处理：

  • 客户消息是否构成真实问题；
  • 回复是否有效回答，而非仅有员工发言；
  • 投诉、购买意向、负面情绪和潜在升级风险；
  • 话术是否符合指定语气和当前群阶段。

模型结果必须带 confidence、分类理由和证据消息；低置信结果进入“待确认”，不能直接形成员工违规结论。

6.2 证据与隐私

  • Dashboard 默认只展示必要证据片段，手机号等敏感字段脱敏；
  • 数据保留期限可配置，默认建议消息正文 90 天、聚合指标 1 年；
  • 员工只能查看职责范围内的群；
  • 模型输入按最小上下文原则截取，不发送无关群历史；
  • 导出、查看完整原文和修改规则均写审计日志。

7. 关键异常与降级策略

异常 产品行为
账号离线或 token 失效 停止发送，保留草稿，提示恢复登录
消息同步中断 看板标记数据延迟，暂停生成确定性健康结论
SOP 未绑定 允许创建绑定任务，不生成“合规率”
模板变量缺失 阻止发送并列出缺失变量
模型不可用 继续执行确定性规则，模型类质检标记“未评估”
发送超时 先查询或同步回执，再决定是否重试，不能直接重复发送
批量任务部分失败 成功项保持成功，仅重试失败项
规则版本更新 历史结论保留原版本，新消息使用新版本
群被解散或无权限 停止计划并生成管理员处理项

8. 开发阶段与优先级

Phase 0：验证底座（3～5 个开发日）

  • 修复群数据的账号隔离；
  • 将消息同步改为账号级增量分流；
  • 实测单群发送、群发助手、回执、频控和错误语义；
  • 确认客户群数据授权、保留期限和角色范围；
  • 准备 1,000 条脱敏群消息和 20 个群的试点样本。

退出条件：增量消息无重复入库，跨账号数据不可见，发送接口边界得到真实回执验证。

Phase 1：MVP 闭环（8～12 个开发日）

  • 新建 qiwei-group-operations skill 和 MCP 工具；
  • 建设 SOP/话术版本、计划、计划项、发送尝试和审计表；
  • 完成“运营总览、今日工作台、群详情、SOP 话术库”基础页面；
  • 支持单群 7 天计划、话术生成、人工审批、复制/发送和失败重试；
  • 支持节奏执行、未回应问题、投诉风险三类质检；
  • 建立 sample 模式和 smoke test。

退出条件：一个总部管理员可发布 SOP，一个门店员工可完成每日执行，一个管理者可从预警下钻到原消息并闭环。

Phase 2：规模化督导（5～8 个开发日）

  • 批量计划、跨门店对比和每日管理简报；
  • 分配负责人、整改待办和官方企微待办同步；
  • 误报反馈集、质检评测脚本和阈值配置；
  • 活跃趋势、生命周期建议和优秀话术沉淀；
  • 发布影响预览、版本 diff 和回滚。

退出条件：20 群连续运行 14 天达到第 2.1 节验收指标。

Phase 3：受控自动化（试点指标达标后再立项）

  • 仅对白名单群、低风险模板、固定时间窗开放自动执行；
  • 配置每日/每周频控、熔断、灰度范围和一键停用；
  • 自动化仍保留审批策略版本、执行回执和全量审计。

9. 测试与验收

9.1 必测场景

  1. 同一群同一天重复生成计划，不产生重复可执行项。
  2. SOP 发布后旧计划仍引用旧版本，新计划引用新版本。
  3. 变量缺失、禁用词、高风险意图会阻止发送。
  4. 发送成功后网络超时，重试不会产生第二条消息。
  5. 客户提问后员工只发送无关内容，仍判定为未有效回应。
  6. 投诉在一分钟内产生可追溯预警，人工可确认误报或关闭。
  7. 消息同步延迟时健康分显示数据不足，不错误扣分。
  8. 两个企微账号的群、SOP、消息和报表完全隔离。
  9. 门店员工不能发布总部 SOP，也不能查看其他门店完整消息。
  10. 所有批准、编辑、发送、跳过、误报和关闭动作都能审计。

9.2 Demo 闭环

建议销售 Demo 控制在 30 秒：

  1. 展示总部已发布“新客群 7 天 SOP”。
  2. 对一个新客群说：“按公司 SOP 生成明天计划和话术。”
  3. Agent 返回计划和风险检查，员工在工作台确认一条话术。
  4. 切换管理视角，看到执行已完成；另一个群因客户问题超时未答产生预警。
  5. 点击预警查看原消息、负责人和建议动作。

10. 工作量拆分建议

工作包 主要交付 估算
群消息与账号底座 账号隔离、增量分流、游标、回执 smoke 3～5 人日
数据层与服务层 表结构、迁移、store/service、审计、幂等 3～4 人日
Skill 与 MCP skill、7 个工具、上下文装配、输出契约 3～4 人日
SOP/计划 Dashboard 总览、工作台、群详情、SOP 页面 5～7 人日
质检引擎 规则、模型分类、证据、评分、预警闭环 4～6 人日
测试与试点 sample、smoke、评测集、20 群试点支持 3～5 人日

合计约 21～31 人日，可由后端/Agent 与前端并行；以上为方案阶段估算，需在 Phase 0 接口实测后校准。

11. 风险与待确认事项

开发前必须由业务负责人确认：

  1. 首批试点的 3 家门店、20 个群和具体负责人是谁？
  2. 首个群类型是新客群、成交服务群、售后群还是会员群？建议只选一种做 MVP。
  3. 公司已有可整理的优秀话术、禁用词、服务承诺和响应 SLA 吗？若没有，谁负责审核 AI 生成的第一版？
  4. 门店允许系统直接发送，还是首期只允许“生成 + 复制 + 人工标记已执行”？
  5. 投诉、价格、退款、医疗/法律等哪些场景必须升级人工？
  6. 总部、区域、门店的查看和发布权限如何划分？
  7. 群消息允许保存多久，哪些字段需要脱敏，是否取得内部合规授权？
  8. 用什么业务结果证明成功：响应速度、运营工时、到店/成交、复购，还是投诉下降？

12. 最终建议

不要把本需求只做成“话术生成器”或“群数据看板”。前者仍然依赖门店自觉，后者只能看问题不能推动执行。首个可售、可验收的闭环应是：

总部发布标准 → Agent 为每个群生成每日计划和话术 → 门店人工确认执行 → 系统自动质检 → 总部查看执行率和风险并下发整改。

技术上首期采用一个统一 qiwei-group-operations skill，加一个“社群运营”Dashboard 模块；在数据规模、角色和自动化策略稳定后，再拆分 SOP 管理、群运营 Copilot 和质检督导 skill。