个人爆款监控系统：数据库设计与前端页面完整方案

爆款监控系统做到一定规模后，最先暴露的问题通常不是没有数据，而是数据太多却看不懂。

如果所有作品都堆在一张表里，当前点赞覆盖历史点赞，AI 分析直接写成一段长文本，最后得到的页面就会像一个更复杂的收藏夹。真正有用的系统，需要把稳定信息、变化指标、分析结果和人工沉淀分开，再用前端把“今天值得看什么”放在最前面。

本文围绕一个个人使用的监控系统，讲数据库表如何拆、前端页面如何分工，以及怎样让分析结果真正回到选题库。

一、先确定系统的核心对象

系统里至少存在六种对象：

创作者：来自哪个平台、平台 ID、粉丝规模和状态。
作品：标题、链接、发布时间、内容类型和作者。
指标快照：某个时间点的点赞、评论、收藏、分享和播放量。
评分事件：首次发现时使用的基线、粉丝快照和等级。
AI 分析：快评、深拆、逐字稿和提示词版本。
SOP 模式：从多个作品中沉淀出的可迁移结构。

这几个对象的生命周期不同。创作者可以被暂停监控，作品信息通常比较稳定，互动指标持续变化，AI 分析可能重新运行，SOP 则需要人工确认后才能进入知识库。

二、十张表够不够

个人系统不需要一开始设计几十张表。一个可用的起步模型可以包含：

creators
创作者和平台账号

creator_snapshots
每日粉丝快照

works
作品主体信息

work_snapshots
作品互动指标快照

grade_events
首次评级和阈值证据

analyses
L1/L2 分析结果、模型和版本

transcripts
字幕、ASR 结果和文本版本

sop_patterns
人工确认后的可复用模式

scan_log
平台扫描任务和失败记录

analysis_queue
待分析任务和重试状态

app_settings
扫描计划、阈值和系统配置

如果暂时不需要评分证据冻结，可以先不建 grade_events；如果还没有逐字稿，也可以让 transcripts 延后。但 works 和 work_snapshots 最好从一开始分开，否则后面很难补回历史增长曲线。

三、稳定信息和变化信息分开

works 适合保存：

CREATE TABLE IF NOT EXISTS works (
    id INTEGER PRIMARY KEY,
    creator_id INTEGER NOT NULL,
    platform TEXT NOT NULL,
    platform_work_id TEXT NOT NULL,
    title TEXT NOT NULL,
    url TEXT,
    content_type TEXT,
    create_time TEXT,
    cover_url TEXT,
    raw_payload TEXT,
    created_at TEXT NOT NULL,
    updated_at TEXT NOT NULL,
    FOREIGN KEY (creator_id) REFERENCES creators(id),
    UNIQUE(platform, platform_work_id)
);

work_snapshots 只保存某个采集时间点的指标：

CREATE TABLE IF NOT EXISTS work_snapshots (
    id INTEGER PRIMARY KEY,
    work_id INTEGER NOT NULL,
    captured_at TEXT NOT NULL,
    likes INTEGER,
    comments INTEGER,
    collects INTEGER,
    shares INTEGER,
    views INTEGER,
    FOREIGN KEY (work_id) REFERENCES works(id),
    UNIQUE(work_id, captured_at)
);

这样可以计算增长速度：

当天新增点赞 = 今天 likes - 昨天 likes
三天增长率 = (今天 likes - 三天前 likes) / max(三天前 likes, 1)

注意，平台可能修正数据、隐藏指标或返回延迟快照，所以增长曲线只能作为观察证据，不能假设每次差值都代表真实新增互动。

四、分析结果为什么不要拆成几十列

L1 和 L2 的字段可能不断增加。最开始可以把经过校验的 JSON 放在 result_json 中，同时把常用的筛选字段单独列出来：

CREATE TABLE IF NOT EXISTS analyses (
    id INTEGER PRIMARY KEY,
    work_id INTEGER NOT NULL,
    level TEXT NOT NULL,
    status TEXT NOT NULL,
    model TEXT,
    prompt_version TEXT,
    result_json TEXT,
    confidence REAL,
    error_message TEXT,
    created_at TEXT NOT NULL,
    updated_at TEXT NOT NULL,
    FOREIGN KEY (work_id) REFERENCES works(id)
);

这样列表页可以直接按 level、status 和 confidence 查询，详情页再展开完整 JSON。不要把模型生成的自由文本直接拼接到 HTML，也不要把未经校验的 JSON 当成可信配置执行。

五、索引要服务于实际查询

第一版通常需要这些查询：

最近发现的 T3/T2/T1 作品；
某个平台某个时间范围的作品；
某个创作者的历史作品和指标曲线；
等待 L1/L2 分析的任务；
没有逐字稿或分析失败的作品。

可以针对查询建立索引：

CREATE INDEX IF NOT EXISTS ix_works_creator_time
ON works(creator_id, create_time DESC);

CREATE INDEX IF NOT EXISTS ix_snapshots_work_time
ON work_snapshots(work_id, captured_at DESC);

CREATE INDEX IF NOT EXISTS ix_queue_status_priority
ON analysis_queue(status, priority DESC, created_at ASC);

不要看到一列就建一个索引。索引会增加写入和存储成本，具体是否生效要用 EXPLAIN QUERY PLAN 检查：

EXPLAIN QUERY PLAN
SELECT * FROM works
WHERE creator_id = 10
ORDER BY create_time DESC
LIMIT 20;

六、前端不是展示所有数据

前端页面应该按用户决策顺序设计，而不是按数据库表一一映射。一个个人监控系统可以有 8 个页面：

页面	解决的问题
Dashboard	系统是否正常，最近有什么值得看
Boom Feed	按等级、平台和日期筛选候选作品
Work Detail	这条作品为什么被筛出来
Creator Detail	这个作者的基线和长期变化
Creators	管理监控名单和暂停状态
SOP Library	查看已经确认的可复用模式
Settings	调整扫描计划、阈值和分析策略
API Docs	调试接口和确认服务状态

第一屏最重要的是“最近值得看什么”，不是把 10 张统计卡全部塞上去。Dashboard 可以只显示：最近扫描状态、失败任务数、最新 T3/T2、待处理 L2 数量和需要人工确认的项目。

七、Boom Feed 如何让筛选更快

爆款 Feed 的核心是减少点击。每条卡片至少显示：

平台和创作者；
标题、封面和发布时间；
当前指标和首次发现时的指标；
R 值、M 值、等级和样本量；
L1 状态和置信度；
是否有逐字稿、是否等待 L2。

筛选条件可以从最常用的开始：等级、平台、内容类型、发布时间、是否已深拆、时效/长青、作者粉丝层级。

不要只用红色表示“爆款”。红色应该只承担高优先级提示，普通状态、加载状态、失败状态和警告状态要有清楚的文字或图标，避免颜色成为唯一信息来源。

八、Work Detail 要把证据放在一起

单条作品详情页是最有价值的页面，因为它连接了数据和人工判断。推荐按以下顺序组织：

作品基本信息
    |
指标和增长曲线
    |
评分证据：基线、粉丝快照、R/M/Tier
    |
逐字稿和封面/抽帧
    |
L1 快评
    |
L2 深度拆解
    |
人工复盘：可迁移 / 不可复制 / 待验证
    |
保存为 SOP 或选题

“为什么被判成 T2”必须能展开看到依据；“爆款因素”也要能追溯到标题、逐字稿、画面或指标，而不是只有一段模型结论。

九、封面图和媒体资源怎么处理

第三方图片 URL 可能有防盗链、短期签名、格式不兼容和跨域限制。前端直接加载原始 URL，容易出现今天能看、明天破图的情况。

如果业务和授权允许保存，可以由后端下载后转换为统一格式、写入缓存目录，再通过自己的媒体接口提供：

/api/v1/media/covers/{work_id}

接口要检查当前用户和作品权限，不能因为知道 ID 就能访问所有媒体。缓存也要设置大小上限、过期策略和清理任务。对于没有必要长期保存的原图，只保存缩略图或临时分析文件，降低存储和版权风险。

十、SOP Library 不应该自动收录一切

AI 每分析一条作品，就自动生成一条 SOP，会很快产生大量重复和互相矛盾的模式。更稳妥的流程是：

作品分析
   |
   v
候选模式
   |
人工确认是否跨作品重复出现
   |
补充适用场景和限制
   |
进入 SOP Library

一条 SOP 至少要包含：模式名称、适用场景、结构步骤、成功证据、不可复制条件、风险和示例。SOP 是方法假设，不是“照抄就能成功”的承诺。

十一、数据库迁移和数据质量

个人项目也要有最小迁移纪律。不要直接在生产数据库里手工改表，然后忘记写回代码。每次表结构变化都记录迁移版本，并在备份副本上测试：

备份当前数据库
复制到临时目录
执行迁移
运行查询和应用测试
确认旧数据可读
再安排生产变更

数据质量检查也可以每天跑一次：创作者平台 ID 是否为空、作品是否重复、指标是否出现负数、时间是否解析成功、分析 JSON 是否能通过校验、快照是否连续。发现异常时优先标记，不要静默修正原始数据。

结论

数据库负责保存事实和历史，前端负责帮助你快速判断，AI 分析负责提供待验证的解释，SOP Library 负责沉淀经过人工确认的方法。四者边界清楚，系统才不会变成“一个页面里塞了很多数据”。

个人项目可以从 SQLite 和几个核心页面开始，但要从第一天就把作品主体、指标快照、分析版本和人工结论分开。这样以后增加平台、模型和页面时，才不需要推翻整个数据结构。

参考资料

SQLite 官方文档，用于核对表、索引、事务和迁移行为。
Vue 官方文档，用于核对组件和状态组织方式。
FastAPI 官方文档，用于核对 API 路由、校验和文档生成方式。