工具仓库：~/Coding/MultiMedia/（GitHub 独立仓，Bob 主导）
工具定位：iGaming Multi-Channel Broadcast Tool —— 自动化每天 70+ 次跨 14 品牌发帖
当前阶段：Sprint 8 进行中（V1 灰度验收）
生产地址：mytools.zycenter.one/broadcast/（作为 MyTools 子工具运作）
本文档目的：把 KB 文案模板库与 MultiMedia 工具之间的关系拉通，明确联动路径与改进方向
一、工具核心定位
是什么
| 维度 |
说明 |
| 本质 |
跨渠道发帖基础设施（infrastructure，不预置业务文案） |
| V1 渠道 |
Telegram（成熟）/ Facebook Page（成熟）/ Viber Channel（基础） |
| V1.5 等待 |
WhatsApp（feature flag 关闭，Meta 官方 API 成熟后再上） |
| 差异化 |
Telegram Premium emoji 原生编辑（MTProto + Lottie .tgs 渲染） |
| 架构 |
Go API + Python telethon sidecar（gRPC）+ React 前端 + PG/Redis/MinIO |
| 多租户 |
单层 Team 软隔离 by team_id，与 MyTools collab 通过 mytools_team_ref 桥接 |
不是什么
- ❌ 不是文案库（KB 才是文案库的源头）
- ❌ 不是合规审核工具（合规规范在 KB，工具只内置违禁词过滤机制）
- ❌ 不是市场调研工具（市场情报在 KB 的市场调研目录）
二、与本 KB 的协作关系
┌─────────────────────┐ ┌─────────────────────┐
│ igaming-kb │ │ MultiMedia │
│ (文案库 + 策略源) │ ──→ │ (执行引擎) │
├─────────────────────┤ ├─────────────────────┤
│ 01-市场调研 │ │ Channel Drivers │
│ 02-频道搭建/合规 │ │ Template/Variable │
│ 03-文案模板库 ⭐ │ ────→ │ Schedule/Dispatcher │
│ 04-工具集成 ⭐⭐ │ │ Account/Channel │
└─────────────────────┘ └─────────────────────┘
策略 / 内容 执行 / 自动化
| KB 提供 |
工具消费 |
03-文案模板库/ 占位符模板（[品牌] [code] [金额] 等） |
模板系统全通用，无硬编码占位符列表 |
02-频道搭建/ 合规避雷词清单 |
internal/profanity/ 违禁词列表（手工同步） |
01-市场调研/ 各渠道 PH 数据 |
不直接消费，但指导渠道优先级配置 |
02-频道搭建/ 多账号/备份策略 |
account/ + dispatcher/ 支持 failover |
三、各渠道工具支持现状（对照 KB 战略）
| 渠道 |
KB 战略定位 |
工具实现 |
Gap |
| Telegram |
主战场，每天 5-8 条 |
✅ 完整（Premium emoji + inline button + scheduler） |
无 |
| Facebook Page |
品牌曝光 + 引流 TG，不直发码 |
✅ 完整（Graph API v19 + token 加密 + 错误分类） |
引流到 TG 的话术变量未模板化 |
| Viber |
备用 + 区域覆盖，2-3 条/天 |
⚠️ 基础（/pa/send_message，未实现 broadcast API） |
需 subscriber 列表，规模化前需补 |
| WhatsApp |
1 对 1 精准 + Utility 应急 |
❌ 占位（ErrDisabled，全 stub） |
官方 Cloud API 等 2026 Q3 上 |
关键差异：工具的 WhatsApp NO-GO 判断（Sprint 0 决策）与 KB 的"Cloud API 是唯一合规路径"判断完全一致——两边都认为 Meta Cloud API 才是合规规模化的唯一可行方案。
四、痛点诊断（来自代码 + Sprint retro）
A. 用户体验（运营人员卡壳点）
| 痛点 |
症状 |
优先级 |
| Emoji picker 卡顿 |
选 emoji 等 2-3s（Lottie 包大） |
🟡 改善中 |
| 首次设置 5 步流程 |
登账号 → 同步 emoji → 建模板 → 建调度 → 发送 |
🔴 缺向导 |
| 跨渠道预览不同步 |
编 TG emoji 时 FB 预览可能显旧 entity |
🟡 中 |
| 调度时区错乱 |
"11:00 Manila" 在本地调度器看是几点不直观 |
🟡 中 |
| 账号健康度不透明 |
不知道账号是否过期 / 被限流 / 被 ban |
🔴 风控关键 |
| 错误消息不可读 |
API 返回 code 4 / code 190 运营不懂 |
🟢 低 |
B. 架构 / 集成（前置依赖）
MyTools SSO 集成的 G1-G7 改造（docs/ops/2026-05-15-mytools-integration-status.md §5）：
| Gap |
状态 |
紧急度 |
| G1 · Cookie 反向校验 |
占位 stub |
🔴 紧急（无法校验 cookie，能冒充用户） |
| G2 · 前端 cookie 模式 |
dev localStorage 注入 |
🔴 紧急（生产 SSO 无法生效） |
| G3 · 废弃本地 users 表 |
旧表仍在 |
🟡 重要 |
| G4 · Team 归属校验 |
RequireTeam() 只检 header 存在 |
🟡 重要（跨 team 访问漏洞） |
| G5 · Viewer 写拦截 |
缺失 RequireWrite() |
🟡 重要（viewer 能发文） |
| G6 · TeamSwitcher 改造 |
localStorage 硬编码 |
🟢 协调 |
| G7 · 集成验收 |
待办 |
🟢 协调 |
这 7 项是 Sprint 8 V1 验收的唯一前置依赖，建议 1-2 周内闭环。
C. 部署 / 运维（脆弱性）
- 依赖 ghcr.io（国际网络敏感）→ goose 工具改打进镜像
- node 18 在 dhv6 超时 → 改 node 20-slim
- MinIO 跨域 → nginx 反代方案才能解决
- 每次部署前需 preflight check（
docs/ops/2026-05-14-dhv6-preflight.md），CI/CD 自动化不足
五、改进建议（按优先级排序）
P0 · 必须做（V1 灰度前）
- 完成 G1-G7 SSO 集成（前置依赖）
- 修 emoji picker 卡顿（已在迭代中，需加虚拟化 + 预加载）
P1 · 应该做（一个月内）
- 快速开始向导（New User Onboarding）
- 从 12 tab 平铺 UI 中抽象出"5 步设置"向导
- 每步必填项 + 帮助文案 + KB 链接
- 账号健康度仪表盘
- Dashboard 加 account 健康卡片（token 状态 / 最近错误 / 限流状态）
- 失败前预警，不等被 ban 才知道
- KB 文案库一键导入（重点 ⭐）
- 后端：已有
POST /api/v1/teams/{team}/templates/presets（最近 commit 36b7e6b）
- 前端：加「导入预设」UI，支持上传 JSON
- KB 端：补一个
scripts/export-broadcast-presets.py 把模板转 JSON
- 时区参考线
- ScheduleEdit 显示「你的时区」+ 倒计时预览
- "11:00 Manila" 转 "你的本地 13:00（+2h）"
P2 · 可以做（下个季度）
- 软告警（异常检测）
- 当某账号发送量 vs 7 天均值偏离 >50% → 告警
- 钉钉 / Slack webhook 集成
- 错误消息 i18n + KB 链接
- driver 错误码映射到可读描述 + 跳 KB 合规避雷文档
- MinIO 资产 lifecycle
- emoji pack 30 天未用自动归档
- 跨渠道预览实时联动
- 编辑 TG entity 时 FB/Viber 预览实时调
/render 端点
P3 · 长期规划
- WhatsApp Cloud API 接入（等 Meta 官方 API 2026 Q3 成熟）
- sidecar 分布式化（14 品牌 × 2 账号 = 28 session 当前够，5 倍增长后才需）
- 双向同步 webhook（KB 改动 → 自动触发工具更新）
六、KB ↔ 工具 联动路径（建议实施）
短期（1-2 周可落地）
[运营] 在 KB 编辑 [品牌]/[code]/[金额] 占位符模板
↓
[运营] 手工复制粘贴到工具 TemplateEdit
↓
[工具] 模板系统全通用，自动识别占位符 → 注入变量
↓
[工具] dispatcher 多账号 failover → 渠道发送
现状：手工搬运，但已可用。
中期（1 个月）
[KB] 加 export-broadcast-presets.py 脚本
→ 把 03-文案模板库/ 下的模板转 JSON
↓
[工具] 前端加「导入预设」按钮
→ POST /api/v1/teams/{team}/templates/import-presets
↓
[工具] 模板入库，可在 12 tab UI 中编辑/复用
长期（下个季度）
[KB] git push 触发 webhook
↓
[工具] 自动拉取最新预设 → diff 现有模板 → 提示运营审批
↓
[运营] 一键 merge 或拒绝
七、运营协同 SOP（推荐）
| 角色 |
在 KB 做什么 |
在工具做什么 |
| 运营/文案策划 |
编辑 03-文案模板库/ 下 .md，提交占位符模板 |
复制到工具 TemplateEdit，配渠道/变量 |
| 运营/调度负责人 |
参考 02-频道搭建/ 选定渠道 + 节奏 |
在工具配 Schedule 规则 + Pool 轮换 |
| 合规/审计 |
维护 02-频道搭建/*合规避雷* 文档 |
在工具维护违禁词列表 + 审批 gate |
| 风控/技术 |
看 01-市场调研/ 评估渠道风险 |
在工具看 Dashboard + 账号健康度 |
| 新品牌起步 |
走 KB → P222 实施路线图（README §五） |
用工具 Phase 1-6 落地 |
八、关联文档
KB 内部
| 关键文档 |
路径 |
| 完整 Spec |
~/Coding/MultiMedia/docs/superpowers/specs/2026-05-13-igaming-broadcast-tool-design.md |
| Master Plan |
~/Coding/MultiMedia/docs/superpowers/plans/2026-05-13-igaming-broadcast-tool-master.md |
| MyTools 集成状态 |
~/Coding/MultiMedia/docs/ops/2026-05-15-mytools-integration-status.md |
| WhatsApp NO-GO 决策 |
~/Coding/MultiMedia/docs/superpowers/research/whatsapp-channels-decision.md |
| dhv6 部署预检 |
~/Coding/MultiMedia/docs/ops/2026-05-14-dhv6-preflight.md |
核心代码入口
| 文件 |
作用 |
backend/cmd/api/main.go |
Go API 入口 |
backend/internal/driver/interface.go |
Channel Driver 接口 |
backend/internal/dispatcher/fanout.go |
调度 dispatch 逻辑 |
backend/internal/template/model.go |
模板 + entity 数据模型 |
sidecar-tg/main.py |
Telegram MTProto sidecar |
web/src/App.tsx |
前端主入口 + 12 tab |
九、Roadmap（KB 视角）
| 优先级 |
内容 |
触发条件 |
| P0 |
等 MultiMedia G1-G7 完成 → 工具可在生产用 |
1-2 周内 |
| P1 |
写 KB → 工具的 JSON 导出脚本（在 KB 仓库） |
工具加导入 UI 后 |
| P1 |
KB 违禁词清单同步到工具 profanity 表（手工） |
立即可做 |
| P2 |
写"运营操作手册"（在 KB），把工具 12 tab 流程化 |
工具 V1 稳定后 |
| P3 |
双向 webhook（KB 改 → 工具 sync） |
工具 V2 |
变更记录
| 日期 |
变更 |
维护人 |
| 2026-05-16 |
首版，含工具定位 + 痛点诊断 + 改进建议（P0-P3）+ 联动路径 + SOP |
Bob |