TikTok Analyzer：把短视频复盘变成可检索的内容资产

TikTok Analyzer 将短视频观看、理解与复盘沉淀为可检索、可复用的内容资产。

问题与定位

短视频复盘常见的问题不是没有观点，而是观点停留在“看完后凭感觉判断”。账号更新、视频指标、开场钩子、爆点和互动表现彼此分散，选题时仍要重新翻找。

TikTok Analyzer 的定位，是把观看转成可检索、可复用的运营流程。

先厘清服务边界，再定位故障

浏览器面对 React 与 Node，Python 侧承担抓取、分析、写库和任务状态。混成一层后，前端、抓取和模型故障难以区分，因此排障应按症状推进：

前端 API 失败：查 /api/py/*、health、CORS/端口。
抓取失败：查 CrawlTask、yt-dlp/Cookie/网络和数据库。
分析 pending：查 AnalysisTask、registry 与 provider。

核心方案

主链路是：

博主管理。
视频元数据爬取。
AI 内容理解。
结构化入库。
结果看板。

用户登录后维护博主，系统创建抓取任务并通过 yt-dlp 获取视频与互动指标；结果写入 MySQL/TiDB，用户选择 Skill，输出进入仪表盘、钩子库和脚本库。

核心原则是先保存博主、视频、任务和原始指标，再针对 Hook、爆点、流量结构和互动表现分析，最后沉淀可查询的 Hooks 与 Scripts。AI 是建立在视频事实之上的执行层。

关键工程实现

双服务边界与数据层

仓库采用 React 19 + TypeScript、Express/tRPC 与 FastAPI。Node 负责页面、共享类型和代理；Python 侧按 routers、services、models/schemas、db 分层；SQLAlchemy 模型承接 creators、videos、CrawlTask、AnalysisTask、hooks、scripts 及分析结果。

关键路径：Browser → React + Express/tRPC → /api/py/* → FastAPI → services/models → MySQL/TiDB。

外部侧连接 yt-dlp/TikTok 或 AI provider。页面改 client/，代理改 server/_core/index.ts，业务改 routers/services，数据库改 models 与 Alembic，分析能力改 backend/skills/ 并注册。

Skills 与结构化输出

AI 能力通过 BaseSkill、meta、execute() 扩展。资料列出以下五个 Skill：

hook_identifier
viral_moment
traffic_analysis
script_generator
hook_recommender

项目用 LangChain 编排，以 Pydantic 约束 schema，再由 React Query、Recharts 和 shadcn/ui 展示。

任务状态

CrawlTask、AnalysisTask 管理抓取与分析。服务启动会把残留 pending/running 标记为 failed，避免任务悬空，但不是自动恢复，幂等重放也未被资料证明。

分析缺失时应追踪任务和保存 service。

边界与验证

当前证据来自本地笔记对公开仓库的静态核验。资料明确本轮未安装依赖、建库、迁移、启动服务、抓取真实 TikTok、调用模型，也未运行测试、typecheck 或 build。

因此本文不声称用户数、规模、吞吐、延迟、成功率、成本、增长效果或正式上线。

TikTok 受地区、登录态、Cookie、yt-dlp 版本、网络和反爬影响；模型依赖 provider、代理、输出稳定性与成本。
Base.metadata.create_all 与 Alembic 并存，生产 schema 所有权待明确；部分依赖未在 requirements 中体现。
规模、样例、截图和 Demo 反馈均待补。

验证应按由窄到宽的顺序推进：