acquire-lead/产品手册.md

产品手册

1. 文档目的

本文档用于沉淀当前已确认的产品方案，面向后续产品、开发、测试和运营协作。

当前方案聚焦于：

• 使用 Playwright 做自动化采集与自动化私信操作
• 使用 AI 做线索筛选与聊天辅助
• 人工仅介入登录/验证，以及最终转平台对接

本文档只整理当前已经明确的方案和约束，不包含数据库字段设计细节。数据库表字段后续商榷后再定。

2. 项目目标

目标是从抖音行业关键词视频的评论区中找到高意向用户，进行私信沟通，并在合适时机将用户转到企业微信进行后续合作。

本期方案不依赖官方 API，主流程基于浏览器自动化实现。

3. 当前范围

3.1 本期包含

• 行业关键词视频搜索
• 评论区采集
• 用户信息识别
• 线索入库
• AI 线索筛选
• 自动私信触达
• 私信内容读取
• AI 会话辅助
• 人工转企业微信

3.2 本期不包含

• 抖音开放平台 API 对接
• 数据库字段最终定稿
• 反检测、反风控、绕过平台限制的实现细节
• 企业微信侧 CRM、SOP、销售流程细节

4. 总体方案

整体采用双 Playwright 架构，将采集与私信分离，降低相互影响。

4.1 角色划分

采集 Worker

负责：

• 搜索行业关键词视频
• 打开评论区
• 读取评论内容
• 进入评论用户主页
• 识别用户唯一信息
• 保存线索

私信 Worker

负责：

• 从线索池中取高价值用户
• 搜索用户并发起私信
• 轮询私信列表
• 读取聊天内容
• 调用 AI 生成回复
• 发送回复
• 在合适时机转人工

人工

负责：

• 登录账号
• 处理验证码、滑块、人机验证
• 账号异常时恢复登录态
• 对高意向用户转企业微信
• 处理投诉、封禁、异常会话

5. 登录态与调度策略

5.1 登录态策略

每次启动 Playwright 默认会打开一个新的、没有 Cookie 的浏览器环境。如果这样做，就会导致频繁重新登录，增加异常风险。

因此当前方案要求：

• 复用固定浏览器用户目录或固定登录态
• 由人工首次登录
• 登录态失效时暂停任务并通知人工
• 自动化流程不主动反复尝试重新登录

目标是让浏览器尽量表现为同一批长期使用的会话，而不是每天反复创建全新环境。

5.2 调度策略

自动化任务可以按每天指定时间范围运行，并在时间范围内随机触发。

例如：

• 上午工作时段内随机启动一次或多次
• 下午工作时段内随机启动一次或多次
• 单次任务内操作间隔带随机抖动

目的：

• 降低固定规律行为
• 让操作节奏更接近日常人工使用

说明：

• Playwright 负责执行操作
• 定时、随机、任务编排应由外层调度器负责

6. 主流程

本期主流程只保留“私信”路径，不包含“回复评论引导用户主动私信”路径。

6.1 主流程概述

1. 人工登录并完成验证
2. 采集 Worker 搜索行业关键词视频
3. 打开评论区并提取评论内容
4. 点击评论用户主页，识别该用户的抖音号
5. 将线索信息入库
6. AI 对线索做筛选和打分
7. 高价值线索进入私信队列
8. 私信 Worker 搜索该用户并发起私信
9. 私信 Worker 定时检查私信列表和会话
10. 读取用户消息并入库
11. AI 根据上下文生成回复
12. 发送回复
13. 用户表达合作意向后，转人工对接企业微信

7. 采集流程说明

7.1 采集来源

线索来源于行业关键词视频，不是自有视频评论区。

7.2 采集步骤

采集 Worker 的标准步骤如下：

1. 打开抖音
2. 搜索预设行业关键词
3. 进入目标视频
4. 打开评论区
5. 遍历评论
6. 读取评论正文
7. 点击评论者主页
8. 读取评论者抖音号
9. 返回评论区继续处理

7.3 为什么要点主页

因为后续系统需要识别“这个人到底是谁”。

仅使用昵称不可靠，原因包括：

• 昵称会修改
• 可能重名
• 头像会变化
• 会话列表不保证有稳定唯一标识

因此，当前确认的方案是：

通过再次点击该用户主页，读取抖音号，作为识别用户和关联会话的主要依据。

8. 会话识别的关键约束

这是当前方案最重要的约束之一。

8.1 已确认事实

在 Playwright 自动化点击私信列表中的某条会话时：

• 不会自动传入“对话 id”
• 不会自动传入“会话唯一参数”
• 不会自动传入“消息唯一参数”

也就是说，系统不能指望在点击某条会话时，页面天然把该会话的唯一标识交给我们。

8.2 当前确认的唯一性方案

查询对话唯一性时，只能再次点击该用户主页，通过抖音号来确定该用户与该会话的唯一性。

这条规则适用于：

• 采集阶段识别用户
• 私信阶段确认目标用户
• 读取会话前做身份校验
• 发送消息前再次确认当前会话对象

8.3 通俗理解

不要把“当前点开的聊天窗口”直接当成可信对象。

必须理解成：

• 列表里看到的是一个聊天入口
• 点进去后，还要再核实“这是不是数据库里那个人”
• 核实手段是：进入该用户主页，看抖音号是否一致

也就是说，系统认人的依据不是“聊天列表第几条”，也不是“昵称看起来像”，而是“主页里的抖音号”。

9. 私信流程说明

9.1 私信前置条件

只有经过 AI 筛选后的高价值线索，才进入私信队列。

9.2 私信步骤

私信 Worker 的标准步骤如下：

1. 从高价值线索池中取一个用户
2. 取到该用户在采集阶段识别到的抖音号
3. 在抖音中搜索该用户
4. 进入该用户主页
5. 核对主页抖音号与数据库记录是否一致
6. 若一致，则尝试打开私信入口
7. 若可私信，则生成首条私信文案
8. 发送首条私信
9. 记录发送结果

9.3 若无法私信

可能存在以下情况：

• 找不到用户
• 抖音号变化
• 无私信入口
• 需要互关
• 账号权限限制
• 页面异常

这些情况都不应直接忽略，而应标记为“无法触达”或“待人工判断”。

10. 私信消息读取

10.1 能读取什么

Playwright 可以读取当前页面上已经渲染出来的聊天内容，主要包括：

• 文本消息
• 左右气泡方向
• 页面显示的时间文字
• 顶部会话对象信息

10.2 读取方式

私信 Worker 需要定时执行以下动作：

1. 打开私信列表
2. 检查是否存在疑似未读会话或预览变化
3. 点击目标会话
4. 再次进入该用户主页
5. 核对抖音号是否和数据库中的目标用户一致
6. 一致后，读取当前可见的消息气泡
7. 将新消息写入数据库

10.3 关于“未读消息”

私信列表可以作为“是否可能有新消息”的参考，但不能作为绝对依据。

原因包括：

• 列表未读提示可能延迟刷新
• 会话列表可能有虚拟滚动
• 界面结构可能变化
• 排序可能变化

因此，本方案中：

• 未读提示仅作为触发信号
• 是否真的有新消息，以会话页面中读取到的新气泡为准

11. 会话与聊天记录如何关联

这是系统落地时最关键的一部分。

11.1 核心原则

先认人，再存话。

也就是：

1. 先确认当前聊天对象是谁
2. 再把读取到的消息挂到该对象对应的会话下

11.2 会话的本质

通俗理解：

• 一个用户，对应一场会话
• 一场会话下面，挂很多条消息

当前已确认的关联逻辑不是“按会话列表顺序”，而是：

按用户主页中的抖音号，去找到数据库中对应的那个人，再把消息存进去。

11.3 不能怎么做

不能按下面这些方式关联：

• 按聊天列表第几条
• 按昵称
• 按头像
• 按未读顺序

因为这些信息都不稳定，容易串会话。

11.4 应该怎么做

建议流程如下：

1. 系统准备处理某个聊天对象
2. 在数据库中先找到这个对象对应的线索记录
3. 打开私信列表并点击候选会话
4. 点击该用户主页
5. 读取主页抖音号
6. 与数据库中保存的抖音号做比对
7. 若一致，认定“当前窗口就是这个人的会话”
8. 再读取消息并写入该对象的会话记录中

11.5 发送消息前也要再确认一次

为了避免串号，系统在真正点击发送前，仍需要再做一次身份确认：

• 当前聊天窗口对应主页抖音号
• 是否仍等于数据库中该线索记录的抖音号

只有一致时才允许发送。

如果不一致，应立即停止发送并记录异常。

12. 聊天记录存储原则

当前不展开数据库字段设计，但产品层面已明确以下存储原则。

12.1 存储层级

聊天数据至少要分成两层理解：

第一层：会话

表示“我们和哪一个用户在聊天”。

第二层：消息

表示“在这场聊天中，说过哪些话”。

12.2 每条消息入库时至少要明确

• 这条消息属于哪个用户
• 这条消息属于哪场会话
• 这是对方说的，还是我们说的
• 这条消息的内容是什么
• 页面上显示的时间是什么
• 系统什么时候读到并写入了这条消息

12.3 存储原则

原则一：按用户归属会话

消息必须挂在“该用户对应的会话”下面，而不是挂在“刚刚打开的那个窗口”下面。

原则二：自己发出的消息也要入库

不只是对方发来的消息要存，我们自己通过自动化发出去的消息也必须记录。

否则后续 AI 看上下文时会不完整，容易重复回复或答非所问。

原则三：只做增量写入

每次打开聊天窗口，不应把整页内容全部重复写一遍，而应只写入数据库里没有的新消息。

原则四：时间要区分两种

消息时间要区分：

• 页面上显示的时间
• 系统实际抓取并入库的时间

因为页面上可能显示“刚刚”“昨天”“上午”等相对时间文本，而系统入库时间是绝对可记录的。

13. AI 使用方式

13.1 AI 在线索阶段

AI 用于对评论区采集到的线索做判断，例如：

• 是否具有合作意向
• 是否与业务相关
• 是否值得进入私信阶段

13.2 AI 在聊天阶段

AI 用于生成私信回复，目标是：

• 根据上下文进行简短回复
• 判断是否继续聊
• 判断是否应转人工
• 判断是否适合引导到企业微信

13.3 AI 的边界

AI 只负责辅助判断与生成回复，不负责：

• 判断当前窗口是否点对人
• 决定是否越过身份校验直接发送
• 处理账号验证、封禁、投诉

这些仍由自动化规则和人工兜底共同负责。

14. 人工介入点

当前方案中，人工介入点明确如下：

14.1 登录与验证

人工负责：

• 首次登录
• 验证码
• 滑块
• 二次校验
• 登录态失效恢复

14.2 企业微信转接

当系统识别到用户有明确合作意向后，交由人工接手：

• 查看聊天摘要
• 查看最近上下文
• 决定如何转企业微信
• 做后续商务沟通

14.3 异常处理

人工负责处理：

• 用户投诉风险
• 页面结构变化导致的失败
• 账号封禁
• 会话身份无法确认
• 高价值线索的特殊跟进

15. 风险与现实约束

当前方案虽可做产品原型，但存在明确风险和限制：

15.1 账号风险

• 私信频率过高容易异常
• 重复登录会增加异常概率
• 自动化行为本身存在平台识别风险

15.2 消息读取限制

• 无官方 API 时，消息读取依赖页面渲染
• 不保证能拿到稳定的会话 id
• 不保证能拿到稳定的消息 id
• 图片、表情、历史消息读取可能不稳定

15.3 会话识别限制

• 必须依赖再次进入用户主页核对抖音号
• 会比直接用官方会话 id 更慢
• 但这是当前不调官方 API 前提下最稳妥的识别方案

15.4 产品策略限制

本期只保留“私信触达”路径，不走“评论区答疑引导私信”路径。

原因是当前优先验证：

• 能否稳定找到目标用户
• 能否稳定读取消息
• 能否稳定将消息和用户正确关联
• 能否完成从私信到企微的转接

16. 当前已确认结论

截至当前，已确认的关键结论如下：

1. 本期主路线为：关键词评论采集 -> AI 筛选 -> 自动私信 -> 读取聊天 -> AI 回复 -> 人工转企微
2. 采用双 Playwright 架构，采集与私信分离
3. 人工只负责登录验证、异常恢复、企微转接
4. 不依赖官方 API
5. 自动化点击会话时，不会天然拿到对话 id 或会话唯一参数
6. 会话唯一性确认必须通过再次点击用户主页，读取抖音号完成
7. 聊天记录的归属必须按“用户唯一身份”关联，而不是按列表顺序或昵称关联
8. 自己发出的消息也必须入库
9. 私信列表中的未读提示只能作为参考，不能作为唯一判断依据
10. 数据库字段暂不在本文档中展开，后续单独商议

17. 后续待商议事项

以下内容当前尚未定稿，后续需要单独讨论：

• 数据库表结构
• 消息去重规则
• AI 评分规则
• 首条私信文案策略
• 多轮聊天策略
• 转企微时机
• 调度窗口与频控参数
• 失败重试策略
• 人工审核比例

18. 文档说明

本文档是当前阶段的产品方案沉淀稿，用于统一认知，不代表所有技术细节已经完全确定。

后续若方案调整，应优先更新本文档，再推进详细设计和开发实现。