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

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

## 1. 背景与问题

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

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

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

```mermaid
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 定位

建议新增：

```text
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 逻辑架构

```mermaid
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

建议新增：

```text
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。