写好了目前两个比较耗时的工作流程，考虑进行优化，需要的话做一些基础建设，如图数据库等。

先深度思考给我提一些下一步进行的建议。

然后从软件工程的角度思考，目前还缺的哪一些文档，我应该继续撰写哪几类文档？



下面‘---’包围的是是已经写好的两个 as-is 文档：

---
## 真人认证审核工作流

1. **流程名称**：女性用户真人认证申请审核
2. **流程目标**：
   - 验证申请者为真人且身份真实。
   - 阻止风险用户（例如被封禁账号、虚假身份或男性冒充女性等）进入平台。
   - 管理同一用户在多平台 / 跨平台的多账号认证。
   - 识别并尽量拦截“他人代认证”风险。
3. **触发条件**：
   - 用户在 App 端提交认证申请。
   - 审核人员按排班（目前每日早晚各一次）登录后台开始审核。
   - Airflow 定时调度 Python 脚本，自动扫描待审列表。
4. **频率与时效**：
   - 人工审核：每日早晚各一次。
   - 申请高峰：17:00 – 20:00。
   - 日均申请量：≈ 300 条。
   - 单条审核时长：10 秒 – 3 分钟（疑难或需手动关联查询的案例可 > 10 分钟）。
5. **参与角色**：审核 / 运营人员。
6. **依赖工具 / 系统**：
   - **后台管理系统**（Web）— 展示待审列表并执行操作。
   - **关联账号查询页** — 手动复制粘贴标识信息进行多库查询。
   - **Python 脚本** — 部署于 Airflow，用于自动拒绝无身份证申请。
   - **MySQL 数据库** — 多平台，多数据库，只读，需 SSH 隧道。
   - **支付宝 / 微信 App** — 辅助手机号实名与账号状态查询。
   - **客服通道** — 接收补充的手持身份证照片。
7. **输入信息**：
   - 待审核用户列表（按申请时间倒序）。
   - 用户上传的照片、身份证号等资料。
   - 用户关联标识（优先级：身份证 > 手机号 > 设备号 > IP）。
   - 用户渠道与上级（推荐人）信息。
8. **现行步骤**：
   1. **自动预处理**\
      Airflow 脚本自动拒绝未提交身份证号的申请。
   2. **访问列表**\
      审核人员登录后台，查看倒序排列的待审列表。
   3. **选择个体 & 信息收集**
      - 无固定顺序，通常优先处理资料完整易通过者。
      - 查看申请资料及上传照片。
   4. **人工关联账号排查**
      - 基于身份证号 / 手机号 / 设备号 / IP，在关联查询页手动搜索多平台数据。
      - 操作需多次复制粘贴，耗时，且通常仅在出现疑点时才对申请人执行完整排查。
   5. **人工审核决策**
      - **风险拦截**：\
        若申请人的 *任一* 关联账号处于 **封禁 / 黑名单** 状态，且无备注特殊情况，**挂起** 申请。
      - **同平台账号处理**：
        - 如果同一身份证已绑定 **活跃且已认证** 的账号 → **挂起** 当前申请，避免重复认证；
        - 如果同一身份证仅绑定 **已认证但不活跃** 的账号 → 先在旧账号页面 **撤销认证**，再 **通过** 当前申请；
        - 始终确保一个身份证在本平台仅对应 **一个** 有效认证账号。
      - **跨平台账号处理**：\
        若同一身份证已在 *其他平台* 完成认证，应查看其活跃度、违规记录与运营备注：如存在风险，则 **提高审核门槛**；若未见异常，可 **直接通过**。
      - **资料核对**：根据身份证推算年龄，结合上传照片的年龄特征，确认人证一致。
      - **策略性调整**：
        - **合作头子下级**：在无封禁 / 重大风险记录的前提下，可适度放宽。
        - **有上级用户**：参考上级用户的历史表现及风险记录，酌情收紧或放宽审核标准。
        - **可疑渠道或异常流量**：从严审核。
        - **普通用户**：结合当期整体风险水平，动态调整审核松紧度。
      - **外部信息辅助**：必要时通过支付宝 / 微信校验手机号实名与账号状态。
      - **存疑处理**：
        - 无明确拒绝理由 → 添加 **备注** 并保留观察；
        - 难以确认真实性 → **拒绝**，并要求用户提交手持身份证照后再复审。
   6. **执行操作**\
      在后台对用户执行 **通过 / 拒绝 / 挂起 / 备注**，或取消旧账号认证。
   7. **记录**\
      可以通过后台备注功能记录审核操作理由、重点观察标记等。
   8. **循环**\
      返回第 3 步，直至列表清空。
9. **输出结果**：
   - 用户认证状态更新（通过 / 拒绝 / 挂起）。
   - 向用户发送补充材料通知（如需）。
   - 更新账号备注
   - （如适用）已对旧账号执行 **取消认证** 操作。
10. **现状痛点**：
    - **效率瓶颈**：列表按时间倒序，人工挑选顺序随意；无批量操作，高峰期压力大；存疑案例需客服配合，流程中断且周期长。
    - **信息割裂**：关联账号查询需频繁切换页面并手动复制粘贴，多库查询不彻底。
    - **风险敞口**：
      - 关联排查不完整，易被封禁用户“换壳”重过认证。
      - **他人代认证** 难以及时发现，特别是审核当下。
    - **操作繁琐**：处理同平台不活跃旧账号需多次跳转；外部查询全靠人工且结果不稳定。
    - **标准主观**：审核顺序、松紧度和查询深度依赖个人经验，缺乏统一标准。
    - **日志不足**：仅简单备注，缺乏完整审核链条与证据。

整理 Google AI Studio kingfall\
润色 o3

## 用户违规核查工作流

1. **流程名称**：用户行为与内容违规核查处理
2. **流程目标**：
   - 识别并定位聊天内容及行为模式中的违规点。
   - 对违规用户及时施以惩处并保留记录。
3. **触发条件**：
   - **LLM 内容审核系统**告警（主要来源）。
   - 其他用户举报。
   - 人工巡查发现（少量）。
   - 识别到疑似竞争平台拉人行为。
4. **频率与时效**：
   - 按需触发。
   - 日均封禁量：≈ 10 个账号。
5. **参与角色**：审核 / 运营人员。
6. **依赖工具 / 系统**：
   - **LLM 服务** — 生成违规告警。
   - **Python 脚本** — 查询数据库。
   - **SSH 隧道** — 连接 MySQL。
   - **MySQL 数据库** — 存储聊天记录（只读）。
   - **代码编辑器 / 终端** — 查看脚本结果。
   - **后台管理系统** — 查看未过期图片 / 语音，并可执行封禁、禁言、警告、调整健康度或备注等操作。
7. **输入信息**：
   - 触发信息：LLM 告警 / 举报 / 巡查定位的用户 ID。
   - 查询参数：目标用户范围与时间范围。
   - 待审核内容：查询得到的文本消息、未过期的图片和语音条。
8. **现行步骤**：
   1. **接收触发信号**\
      收到 LLM 告警、用户举报，或人工巡查发现线索。
   2. **准备查询**
      - 确认 SSH 隧道正常。
      - 根据场景修改 Python 脚本参数（用户 ID 或群组、时间范围等）。
   3. **获取并查看记录**
      - 运行脚本，从 MySQL 拉取目标文本消息。
      - 在编辑器 / 终端查看脚本输出的纯文本聊天记录（结构化低，可视化差）。
      - 如有必要，切换后台系统查看相关的未过期图片 / 语音条。
   4. **定位与判断**
      - **人工通读** 或利用告警关键词在大量文本中搜索违规片段及上下文。
      - 辅以图片 / 语音内容的人工查看。
      - 重点识别违规类型：
        1. 引导第三方联系方式、引流、三方平台如语音厅（≈ 90%）。
        2. 欺诈行为、无脑索要礼物。
        3. 出售淫秽图片 / 视频。
        4. **竞争平台拉人**：男性账号批量发送引流消息。
      - 语音通话、视频通话及已过期多媒体暂无法审核。
   5. **决策**
      - 根据违规情节严重程度 → **封禁 / 禁言 / 警告 / 调整女性账号健康度**。
   6. **执行操作**
      - 在后台搜索目标账号。
      - 执行相应处罚。
   7. **记录**
      - 在后台添加简单备注。
      - 不保留原始违规内容（隐私考量）。
   8. **反馈 / 结案**
      - 目前无正式申诉通道，误判情况暂无统计。
9. **输出结果**：
   - 用户账号状态变化（封禁 / 禁言）。
   - 女性账号健康度调整。
   - 用户收到警告。
   - 账号备注更新。
10. **现状痛点**：
    - **定位困难**：纯文本量大，缺乏可视化和检索能力，告警难以快速定位；且文本与图片 / 语音条分离，排查耗时。
    - **效率低下**：脚本查询、跨窗口切换繁琐；操作界面分离。
    - **审核盲区**：无法处理语音 / 视频通话及已过期多媒体；图片 / 语音条全靠人工。
    - **证据缺失**：未留存脱敏违规内容，不利于复核与申诉。
    - **协同困难**：基于个人脚本与编辑器，难以多人协作。
    - **效果难评估**：无申诉流程，无法量化 LLM 与人工误判率。
    - **LLM 利用不足**：LLM 仅发告警，未用于定位、高亮、分类及数据追踪。

整理 Google AI Studio kingfall\
润色 o3

---