12 · 自动化路线图¶

定位:运营副组长工作流自动化需求书 + API 机会盘点 —— 这是向技术团队发起 API 开发请求的前置材料 目标读者:运营副组长(自己用)、技术团队(评审 API 请求)、架构师(做优先级排序) 核心价值:把重复性、规则明确、数据在后台的人工审核工作,通过"Telegram 机器人 + 后台查询 API"自动化掉 最后更新:2026-04-11

一、为什么要有这个区段¶

运营副组长的工作有相当一部分是"跳 N 个后台页面 → 按规则判断 → 下结论"的套路化劳动。典型例子:

  ┌──────────────────────────────────────────────────────┐
  │  原人工流程(现状)                                    │
  │                                                        │
  │  值班人接单 → 后台 A 页面查 → 后台 B 页面查            │
  │           → 后台 C 页面查 → 按规则判断 → 下结论       │
  │                                                        │
  │  耗时:5-15 分钟/单 × 几十单/天 = 2-3 小时/天         │
  └──────────────────────────────────────────────────────┘
                            ↓
  ┌──────────────────────────────────────────────────────┐
  │  自动化后(目标)                                      │
  │                                                        │
  │  值班人接单 → 发订单号给 Telegram 机器人               │
  │           → 机器人调后台 API → 直接给处理建议         │
  │                                                        │
  │  耗时:10 秒/单 × 几十单/天 = 10 分钟/天              │
  └──────────────────────────────────────────────────────┘

为什么可行: - 后台所有数据本来就在数据库里 - 规则已经被值班人长期验证过,可明文代码化 - Telegram 机器人已经是团队标配沟通工具 - 安全风险可控:API 走 IP 白名单,只允许 Telegram Bot 所在服务器访问

二、文档索引¶

自动化需求书(给技术团队)¶

#	文档	核心内容	优先级
01	代理提现审核 API 需求书	IP 去重(v4/v6)·余额溯源·小号识别·彩金扣除算法·完整 API schema	P0

机会盘点与规划¶

#	文档	核心内容
02	自动化机会盘点	全工作流扫描·优先级矩阵·实施建议

三、使用方式¶

3.1 给运营副组长自己¶

日常踩到"这破事又要来一遍"的时候,在本区段对应文档末尾补充场景
每个文档的"用户反馈"章节是给你留的

3.2 给技术团队¶

每篇"API 需求书"都包含:
业务背景
当前人工流程(痛点量化)
完整的判定算法(可直接翻译成代码)
API schema(Input / Output / 错误码)
安全方案
测试用例
你可以把这份文档当作 PRD 直接开工

3.3 给架构师 / 部门经理¶

02-自动化机会盘点.md 里有完整的优先级矩阵
按 频率 × 耗时 × 判定清晰度 × 数据源 / 错误代价 打分
一目了然知道哪些是 quick win,哪些要慎重

四、架构模式(通用)¶

所有自动化 API 都遵循下面这个统一模式:

  ┌─────────────────┐
  │ 运营副组长       │
  │ (在 Telegram)   │
  └────────┬────────┘
           │ /check 订单号
           ▼
  ┌─────────────────┐
  │ Telegram Bot    │
  │ (部署在 VPS)    │
  └────────┬────────┘
           │ HTTP GET/POST (带 token)
           ▼
  ┌─────────────────┐
  │ 后台 API 网关    │  ← IP 白名单(只允许 Bot 服务器)
  │ (新开发)        │  ← Token 认证
  └────────┬────────┘
           │
           ▼
  ┌─────────────────┐
  │ 数据库 / 原后台   │
  │ (只读)          │
  └────────┬────────┘
           │
           ▼
  ┌─────────────────┐
  │ 判定引擎         │  ← 业务规则代码化
  │ (按 API 需求书)  │
  └────────┬────────┘
           │
           ▼
  ┌─────────────────┐
  │ 机器人回复       │
  │ "建议 XXX,原因"  │
  └─────────────────┘

五、安全设计(通用)¶

所有 API 必须满足以下四条:

层	措施	说明
网络层	IP 白名单	后台 API 只接受 Telegram Bot 服务器 IP 访问,防止泄漏后被滥用
认证层	Bearer Token	API 请求头带 `Authorization: Bearer <secret>`,定期轮换
权限层	只读 API	所有查询 API 只读,不允许任何写操作(修改/删除/转账)
审计层	全量日志	每次请求记录:调用方 IP、时间、参数、返回值;对接 Grafana 做异常检测

为什么坚持"只读":一旦 API 有写权限,即使只是"驳回订单",被滥用/注入的风险就上一个量级。判定结果返回给人,由人决定是否执行。

六、未来的扩展¶

本区段会持续增长。每发现一个"重复性高 + 规则明确 + 数据在后台"的工作流,就: 1. 在 02-自动化机会盘点.md 加一行 2. 如果优先级高,单独开一篇 0N-xxx-API.md 3. 提交给技术团队评审

七、与其它区段的关系¶

区段	关系
09-岗位指南与SOP/02-运营线/01-副组长-工作指南	主来源 —— 本区段所有机会都是从这份指南里扫出来的
11-平台手册/非凡包网/	数据源 —— 每个 API 的数据都来自对应的后台功能
02-技术体系/16-firebase/	同属"自动化"主题 —— Firebase 自动化推送也是类似思路