代聊系统 · 创作者端 24 小时关闭代聊冷静期 · 设计说明

文档版本：v1.1（v1.0 → v1.1 增补 RT-0106 挽留动作 + GR-04 防滥用 + RT-05 双通道触发） 文档类型：从 PRD v2.0 提取的专项设计说明 + 原型 v1.0v1.6 设计沉淀 来源文档：PRD_代聊系统_产品需求文档 (1).md + PRD_代聊系统_技术落地版 (1).md + 高保真原型 v1.6 PRD 版本：v2.0 | 2026-04-08 整理日期：2026-05-23 → 更新于 2026-05-25 整理人：PM 助手 + 张一章 关联条款：CP-01 ~ CP-05、GR-02、GR-04（v1.1 新增）、EX-08、AC-27 ~ AC-32、RT-01 ~ RT-06（v1.1 新增）、AC-55 ~ AC-57（v1.1 新增）

一、核心设计哲学

对代聊员撒谎，保护创作者。 代聊员对冷静期完全不知情。

如果代聊员知道"24 小时后这个号就不属于我了"，极有可能疯狂发低俗内容、引流竞品、拉黑粉丝，进行同归于尽式毁号操作。

二、状态机定义

Off（关闭） ─→ On（开启） ─→ CoolingDown（冷静期） ─→ Off / On（撤回）

三、规则清单（CP 系列 + GR-02）

四、双端体验对照（关键差异）

4.1 创作者端（全程透明可见）

4.2 代聊员端（绝对静默 · 严禁告知）

五、数据库字段

users 表新增 2 个字段：

六、API 接口

七、完整流程

graph TD
A["创作者点击'关闭代聊'"] --> B["弹出挽留弹窗（CP-04）"]
B --> C{"创作者坚持关闭？"}
C -->|"被挽留，取消"| D["保持开启"]
C -->|"确认关闭"| E["设置 agent_chat_disabled_at = NOW()<br/>agent_chat_enabled 保持 true（CP-01）"]
E --> F["创作者端：显示24h倒计时（CP-02）<br/>+ 一键撤回按钮"]
E --> G["代聊端：零提示<br/>一切照常工作（GR-02）"]

F --> H{"创作者24h内撤回？"}
H -->|"撤回（CP-03）"| I["清除 disabled_at<br/>恢复正常"]
H -->|"未撤回，24h到（CP-05）"| J["agent_chat_enabled = false<br/>所有 agent_session 关闭"]

J --> K["创作者端：<br/>所有对话恢复可见"]
J --> L["代聊端：<br/>弹出'用户已离线'<br/>会话消失"]

style G fill:#d4edda,stroke:#28a745
style L fill:#f8d7da,stroke:#dc3545
style E fill:#e8daef,stroke:#8e44ad

八、相关页面规格

页面 C-P03：创作者中心 → 代聊设置（CreatorAgentScreen）

Tab1 代聊设置包含：

• 代聊开关：Switch 组件
• 关闭流程：点击关闭 → 弹挽留弹窗（显示"代聊帮你赚了 ¥xxx，关闭后粉丝互动将无人响应"）→ 确认关闭 → 显示 24h 倒计时 + 蓝色"撤回关闭"按钮
• 人设卡片配置

九、验收标准（AC-27 ~ AC-32 共 6 项）

十、异常场景

EX-08：创作者反复开关代聊

场景：频繁开 → 关 → 开

系统处理：

• 关闭有 24h 冷静期，冷静期内可撤回不消耗次数
• 到期后再开启，系统重新遍历粉丝做 72h 判定
• 不做额外限制，但运营可监控该创作者行为

优先级：P1

十一、关键要点速记表

十二、设计风险与防护

风险 1：代聊员蓄意破坏

风险描述：如果代聊员知道冷静期存在，可能在 24h 内进行毁号操作（发低俗内容、引流竞品、拉黑粉丝）。

防护机制：

• GR-02 静默冷静期：代聊端零提示
• 数据库字段 agent_chat_enabled 在冷静期内保持 true，代聊端无法通过状态判定
• 到期切断使用通用文案"用户已离线"，与正常用户流失无差异

风险 2：创作者不安导致离开平台

风险描述：完全黑箱让创作者怀疑"平台是不是拿着我的账号搞诈骗""我的死忠粉是不是被洗走了"。

防护机制：

• 配套代聊战报面板（GR-03）：创作者看不到聊天内容，但能看到脱敏的收入/互动数据
• 挽留弹窗（CP-04）：用具体收入数字（如"¥2,380"）让创作者意识到关闭代价
• 撤回按钮（CP-03）：给创作者后悔的余地

风险 3：创作者反复开关骚扰系统

风险描述：频繁开关代聊会触发多次粉丝重新分配，可能影响代聊员效率。

防护机制：

• EX-08：不做开关次数限制，但运营后台监控异常行为
• 24h 冷静期本身就是一道速率限制——关闭后必须等 24h 才能真正生效

十三、v1.1 增补：挽留动作 RT-01~06 系统

13.1 设计动机

CP-04 挽留弹窗只在"关闭瞬间"触发一次。如果创作者点击确认关闭后开始进入 24h 冷静期，期间可能因为情绪冷静下来想撤回，但没有外部刺激提醒"代聊还在赚钱"。流失率分析显示：仅靠 CP-04 单点挽留，撤回率 < 8%。

v1.1 引入 RT 系列挽留动作（Retention） ，把挽留链路从"单点击穿"扩展到"全程渗透"，覆盖：关闭瞬间 → 冷静期间 → 撤回成功 → 最后 1 小时强提醒。预期撤回率提升至 25-35%。

13.2 RT-01~06 规则总览

13.3 RT-05 双通道触发机制（v1.6 升级 · 本次更新核心）

13.3.1 触发条件

13.3.2 双通道动作（同步触发）

onLastHour() → ① setShowLastHourModal(true)         （全局弹窗）
              + ② setInboxItems(prev => [{          （站内信推送）
                    type: 'chat',
                    title: '⚠ 冷静期最后 1 小时',
                    body: '代聊将在 1 小时内正式停止。如需保留代聊服务，请在到期前撤回关闭操作',
                    time, read: false
                  }, ...prev])

双通道目的：弹窗保证当前在线创作者立即感知；站内信保证创作者离线/关闭弹窗后仍能回看，不漏失。

13.3.3 弹窗本身的设计原则（创作者端不暴露规则编码）

LastHourModal 弹窗 JSX 不展示任何 RT-XX/规则编码标注：

• ❌ 不写"RT-05 最后 1 小时强提醒"小字
• ❌ 不写"双通道 / 站内信推送"功能说明
• ✅ 仅展示业务内容：损失数据 + 撤回 / 坚持关闭双按钮

设计编码（RT-XX）只在沙盒右侧 DocPanel 文档面板出现（开发/产品文档化用），创作者侧绝对干净。

十四、v1.1 增补：GR-04 防滥用规则（创作者端隐藏）

14.1 设计动机

EX-08 在 PRD v2.0 明确"不做额外限制，但运营可监控该创作者行为"。但运营监控是事后处置，无法防止：

• 创作者一周内反复开关 5 次（每次产生 24h 服务断点）
• 频繁切换造成代聊员资源调度浪费
• 部分创作者用关闭代聊作为"试探流失"工具

GR-04 是前置硬约束：30 天内仅允许关闭一次代聊，让"关闭"成为创作者必须深思熟虑的高代价决策。

14.2 规则细节

关键细节：撤回也消耗次数

撤回操作（CP-03）虽然没有真正切断代聊服务，但仍消耗本次 30 天关闭额度。设计理由：

• 防止创作者"无成本试探"：开关 → 撤回 → 再开关，形成行为骚扰
• 与 24h 冷静期对齐：冷静期是"反悔窗口"，30 天是"反悔之后再次行使权利的窗口"

14.3 创作者端隐藏（v1.5 设计决策）

业务规则保留 + 前端展示全清：

设计哲学：让创作者只感受到"按钮点不动"的物理性阻碍，不解释为什么不能点。理由：

• 明确告知规则会让创作者警觉/反感（"平台限制我的权利"）
• 完全隐藏后，创作者会归因为"系统繁忙/版本更新"等中性判断
• 配合 CP-04 挽留弹窗的收入挽留 + RT-04 撤回正反馈，让"不关闭"成为创作者的自主选择

14.4 数据库字段（users 表新增）

判定公式：

isRestricted = (Date.now() - lastClosedAt) < (30 × 24 × 3600 × 1000)
restrictionDaysLeft = Math.ceil((RESTRICT_MS - elapsed) / 86400000)  // 仅业务计算用，不暴露给创作者

14.5 与现有规则的协同

| 与 CP-01 关系 | CP-01 触发瞬间，同步写入 lastClosedAt = NOW()（与 disabled_at 写入同步） | | 与 CP-03 关系 | 撤回时 disabled_at 清空但 lastClosedAt 保留（消耗次数核心） | | 与 CP-05 关系 | 到期切断时同样不重置 lastClosedAt | | 与 EX-08 关系 | EX-08 原文"不做额外限制"被 GR-04 替代，原文需更新为"受 GR-04 约束" |

十五、v1.1 增补：API 接口扩展

十六、v1.1 增补：验收标准 AC-55 ~ AC-57

十七、v1.1 增补：设计风险与防护

风险 4：RT-05 双通道重复触发

风险描述：TopCoolingBar 每秒检测一次剩余时间，到达阈值后若不锁定，每秒触发 1 次会推送 60 条站内信。

防护机制：

• lastHourFiredRef.current 布尔锁，触发后置 true 永不再触发
• ref 而非 state，避免状态更新导致组件重渲染
• 即使页面刷新，因 lastClosedAt 恢复但 ref 重置，理论上可能重触发——这是已知边界，原型可接受（后端实现需配合幂等校验）

风险 5：GR-04 创作者归因不当

风险描述：完全隐藏后，创作者发现 Toggle 点不动可能去客服投诉"系统坏了"。

防护机制：

• 客服话术准备：明确告知"30 天内仅可关闭一次"是平台规则，避免一线客服困惑
• 后台监控创作者点击 disabled Toggle 的事件，统计困惑分布
• 若投诉率 > 阈值，考虑改为方案 B：保留 Toggle disabled 但加模糊 toast"系统暂不可关闭"

风险 6：撤回消耗次数引发争议

风险描述：创作者撤回后想再次关闭被拒，可能投诉"我又没真正关闭怎么算我用过了"。

防护机制：

• 设计原则文档化：撤回 = 行使过本次决策权，本质上消耗了一次"关闭意图表达"
• 客服 SOP：解释 30 天窗口是"决策表达"窗口，不是"实际服务断点"窗口
• 与 CP-04 挽留弹窗呼应：弹窗内可考虑加一行"想清楚再关闭，30 天内只有一次机会"——但 v1.5 已决定创作者端不展示，待运营反馈再决定是否回退

十八、v1.1 增补：原型与文档对应关系

修订记录