simonkoson/tps-dashboard
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
061e07f84213a718e788b6afb9b61bdd1050b309
tps-dashboard/project_plan.md
T

14 KiB
Raw Blame History

project_plan.md — TPS 中台项目策划书

项目:TPS(Topic Planning System)中台 — 央视《军事科技》栏目内部工作台 仓库:tps-dashboard 修订版本:v3 · 2026-05-06 制片人:刘统 协作大模型:Claude Opus 4.7(顾问)+ Sonnet 4.6(Plan,Phase 2 起切 MiniMax M2.7)+ DeepSeek pro(Act,全程)

一、文档定位

本文是项目产品宪法——讲"做什么、为谁做、为什么这么做"。

技术实施细节、阶段时间线在姊妹文档 dev_plan.md;协作规则在 .clinerules。

这三份文件长期不变;每周执行细节进 logs/phase{N}_log.md,不进本文。

二、项目背景

2.1 谁在用

央视《军事科技》栏目核心团队,共 8 人:

  • 制片人(刘统):管理员,产品决策
  • 责编(1 人):维护排期、收视、知识库
  • 编导(6 人):核心生产者,选题策划与节目执行

2.2 现存痛点

栏目目前的工作流散落在多个工具里——Excel(收视数据 + 排期)、Word(报题单 + 文稿)、微信群(线索沟通)、个人电脑(往期节目素材)、师傅徒弟口口相传(选题判断经验)。具体痛点:

  1. 历史选题查重靠脑子:编导提一个选题,没人能快速回答"这个我们做过没有、做的几次什么收视、有没有踩过坑"。新编导尤其吃力。
  2. 报题单格式与质量参差:每个编导写的报题单结构、详略、专业度都不一样,制片人审起来费劲。
  3. 知识库碎片化:往期文稿、军报材料、专家库、外拍线索都在各自电脑/微信里,新编导接手等于从零开始。
  4. AI 时代焦虑:看到同行开始用 AI,但栏目缺一个懂栏目业务、又不替代编导主权的工具。
  5. 数据没有沉淀:每年都做 100+ 期节目,但收视成绩、审片意见、外拍资源都没结构化沉淀,经验靠人不靠系统。

2.3 项目核心价值主张

辅助而不替代,AI 给方向不给答案,保护编导创作主权。

这一条贯穿所有模块设计、所有 AI Prompt、所有 UI 决策。任何让 AI 替编导拍板的功能都不要做;任何把编导逼向"按 AI 建议改"的设计都要重做。

三、项目目标

3.1 短期目标(2-3 个月,Phase 5 末)

交付一个 8 人团队真的会用起来的 MVP,涵盖:

  • 登录与权限
  • 公共仪表盘(收视成绩 + 排期一目了然)
  • 历史数据导入(责编可一次性导入 300+ 期 Excel)
  • 知识库(往期报题单 / 文稿 / 军报)
  • TPS 选题策划(查重 + 知识库参考 + 报题单生成)
  • 编导个人首页 + 热点雷达

Week 6 末必须有团队可用版本上线——这条比"功能齐全"更重要。

3.2 中期目标(2.0,半年至一年)

向 Karpathy LLM Wiki 形态演进:从"原始资料堆 + 检索"升级到"概念卡片 + 关联网络 + 自动综述"。

1.0 不做,但 1.0 设计时预埋兼容接口(知识库存储格式、tags / related_entities / related_concepts 字段、embedding 维度 1536 等)。

3.3 远期目标(2-3 年)

文稿写作辅助系统、AI 配音深度联动(借用蓝皓 TTS 2.0)、多栏目复用工作台底座。

四、用户与权限

角色 中文 拼音值(代码) 主要权限
管理员 制片人 zhipianren 全部权限,可创建账号、修改全局设置
责编 责编 zebian 维护仪表盘 / 知识库 / 排期,不能改全局设置
编导 编导 biandao 使用 TPS / 查看知识库 / 生成报题单 / 个人热点雷达,不能改他人内容

关键约束:

  • 不开放公开注册——账号一律由管理员创建
  • 离职编导不删除——保留其历史作品的姓名快照,见 .clinerules 第 5.3 节
  • 角色英文枚举值不再改(已锁定为拼音)

五、产品功能模块(8 个)

模块 A — 选题查重(TPS 核心入口)

痛点:编导提一个选题,担心做过、想知道历史成绩。

功能:

  • 编导输入选题简介 → 系统语义检索往期 topics + episodes
  • 列出 5 条相似度最高的历史节目,展示原文 + 当年收视成绩 + 颜色标识(红蓝绿)
  • 点开任一相似节目 → 联动模块 E,展示外拍联系人 / 联系方式 / 线索来源
  • 编导自行判断:"这选题做过但收视很高可以重做"或"这个角度我们没碰过"

AI 哲学:不告诉编导"建议放弃 / 建议做",只展示事实让其自决。

模块 B — 编导画像建议

痛点:新编导不知道自己擅长什么、容易在哪类选题上栽跟头。

功能:

  • 在 AI 反馈中插入一段画像建议(如:"小张过去 12 期偏向装备评测,这次涉及历史人物可能需要更多顾问支持")
  • 画像数据来源:users.profile_text 字段 + 该编导历史选题/收视统计
  • 永远显式标注"仅供参考",且有"忽略"按钮

1.0 形态:粗框架,文字一段。 2.0 形态:动态画像,根据每期作品自动迭代。

模块 C — 知识库参考

痛点:写选题时缺背景资料,需要去翻往期文稿、军报、专家观点。

功能:

  • 提交选题时,系统语义检索 knowledge_items(往期文稿 + 军报 + 内部资料)
  • 列出 3-5 条最相关条目,展示摘要 + 关键词,可点开查看原文
  • 编导可选择性引用,引用关系入库(为未来"知识溯源"打基础)

关键技术:pgvector + DeepSeek embedding(或 OpenAI 兼容 embedding API)+ 1536 维向量。

模块 D — 历史审片意见展示

痛点:制片人审过的稿子有些反复出现的意见(比如"开头节奏太慢"),编导写新稿时不知道要避开。

功能:

  • 不做 AI 预测,只展示事实
  • 当编导在 TPS 中提交相似选题时,系统检索往期 review_comments,展示 2-3 条相似选题的原始审片意见原文
  • 编导自己读、自己消化

为什么不做 AI 预测:数据量太小,预测容易胡说;原文展示让编导自己判断,符合"AI 不替决策"哲学。等数据累积充分后再考虑 2.0 加预测能力。

模块 E — 拍摄资源关联

痛点:外拍找谁问、找哪个单位、上次怎么联系上的——栏目没有结构化记录。

功能:

  • 独立的拍摄资源库(shooting_resources 表,存联系人 / 单位 / 专长 / 上次合作期次)
  • 与 episodes 表的 outdoor_contact_person / outdoor_contact_info / lead_source 联动
  • 模块 A 查重命中相似节目时,自动展开"找谁能问到"提示

模块 F — 时间可行性 + 甘特图

痛点:选题提了不知道排期能不能赶上;制片人不知道哪几期已经塞满了。

功能:

  • 编导提选题时显示"距离最近一个空档还有几天"
  • 制片人页面有甘特图视图(frappe-gantt),拖拽调整排期

模块 G — 报题单生成与下载

痛点:报题单格式各编导各异,审核耗时。

功能:

  • 编导填好选题信息 + 选好相似参考 + 选好知识库引用 → 一键生成 .docx 报题单
  • 模板由 docxtpl 渲染,严格遵守"双段结构"(引子 + 列举,见 .clinerules 第 5.4 节)
  • 编导可下载、修改、打印

模块 H — 编导个人首页 + 热点雷达

痛点:编导想知道"今天有什么军事新闻可能值得做",目前靠各自刷微博/微信。

功能:

  • 个人首页(每位编导自己一份)
  • 今日热点雷达:RSS 抓取 + AI 摘要 + 风格化改写(用栏目历史文稿 few-shot)
  • 每条热点有"深入了解 / 收藏 / 忽略"三个按钮
  • 点"深入了解"自动跳转 TPS,预填选题简介

为什么放最后做(Phase 4c):需要 Phase 3 积累的稿子作为风格学习样本,数据量越大,模仿越像。

六、关键业务规则(死规矩,务必死守)

这一节内容跟 .clinerules 第五章重复——双份保险,任一文件被改都不会丢。

6.1 收视颜色判定(色彩规约反直觉)

只对收视份额(audience_share)上色:

  • 🔴 红色 = 超过当年摸高目标 = 优秀(不是警告)
  • 🔵 蓝色 = 在基础与摸高之间 = 达标
  • 🟢 绿色 = 低于当年基础目标 = 待提升(不是安全)

通用习惯红警绿安,栏目反过来。

6.2 年度目标只增不改(时间不变性)

yearly_targets 每年新增一行,绝不覆盖历史年份。每期节目按其播出年份的目标判颜色,2024 年的节目永远按 2024 年的目标判,2026 年回看也不会变色。

6.3 编导关联用"软引用 + 快照"

episodes.editor_id(可空)+ episodes.editor_name_snapshot(必填)。离职编导不删档,只置空 editor_id、保留快照。

6.4 报题单内容概要的双段结构

默认:引子(200-300 字)+ 列举(3-5 条 Markdown 序号,每条以 **加粗关键词** 开头)。 备选:纯叙述,仅当编导明确指定才用。

七、技术栈与红线(精简版)

详细请见 dev_plan.md,本节给非技术读者一个全貌。

层级 选型
前端 React 18 + Vite + Ant Design 5(JavaScript,不用 TypeScript)
状态 Zustand
后端 FastAPI + SQLModel(同步,不用 async)
数据库 PostgreSQL 16 + pgvector(1536 维,统一)
认证 Session + Cookie(不用 JWT)
AI MiniMax M2.7 编程主力 + DeepSeek embedding
Word 生成 docxtpl
部署 Nginx 反向代理(整合 TPS / 蓝皓 TTS / MMIM)

八、双服务器整合架构

                  ┌────────────────────┐
   主域名访问 →   │  腾讯云 4核8G 新机  │  ← TPS 中台主体
                  │  (Nginx + FastAPI │
                  │   + PostgreSQL +  │
                  │   React 前端)     │
                  └─────────┬──────────┘
                            │
                       Nginx 反代
                            │
                            ▼
                  ┌────────────────────┐
                  │  老服务器 2核2G    │  ← 蓝皓 TTS 2.0 + MMIM
                  │  101.42.29.217     │     (已上线运行中)
                  └────────────────────┘

用户体验:从主域名进,在 TPS 工作台菜单里能跳转到 TTS,无感知是另一台服务器。

反代路径规划(Phase 5 部署时实施):

主域名/        → TPS 前端 (本机)
主域名/api     → TPS 后端 API (本机)
主域名/tts     → 反代到 101.42.29.217 (蓝皓 TTS)
主域名/mmim    → 反代到 101.42.29.217 (MMIM)

九、项目阶段总览

详细每周里程碑见 dev_plan.md,本节给一个全局视图。

Phase 时间 核心交付 完成度
Phase 0 Day 1-2 环境搭建(Python/Node/PG/Git) 家用机已完成,单位机重启
Phase 1 Week 1 后端 + 前端骨架 + 登录跑通 家用机后端已完成,前端待
Phase 2 Week 2-3 仪表盘 + 用户管理 + Excel 导入 未开始
Phase 3 Week 4 知识库基础设施 + 报题单导入 未开始
Phase 4a Week 5-6 MVP 上线(报题单生成 + 查重 + 知识库参考) 未开始
Phase 4b Week 7-9 画像 + 甘特图 + 资源 未开始
Phase 4c Week 10-11 热点雷达 未开始
Phase 5 Week 11-12 部署上线 + 反向代理整合 + Buffer 未开始

十、AI 模型分工(2026-05-06 拍板)

阶段 Plan 模式 Act 模式 备注
Phase 0-1(骨架期) Sonnet 4.6 DeepSeek v4 pro 骨架期 Plan 用 Sonnet 保质量
Phase 2 起 MiniMax M2.7(标准版) DeepSeek v4 pro Sonnet 余额耗尽后切换
顾问层 Claude Opus 4.7(claude.ai 网页) — 关键决策、架构审核、卡壳兜底

为什么换的是 Plan 不是 Act:

Plan 模式(出方案 / 审改动)的调用频次远高于 Act 模式,Sonnet 单次调用又比 DeepSeek 贵 50 倍——钱主要花在 Plan 上。把 Plan 从 Sonnet 换成 MiniMax M2.7,单次成本降至原来的 1/50,Act 不动。

DeepSeek pro 在家用机 Phase 1 后端骨架阶段已验证可用,搭配稳定,没必要换。

MiniMax M2.7 选型理由:

  • 性能对标 Claude Opus(SWE-bench 78%、Agent 工具调用稳定)——胜任 Plan 出方案的复杂推理
  • 价格仅 Claude Opus 的 1/50
  • 中文原生,理解栏目术语优势明显
  • OpenAI 兼容接口,Cline 切换成本几乎为零
  • 制片人此前用 MiniMax 做过蓝皓 TTS 2.0,有合作经验

接入信息:base_url = https://api.minimaxi.com/v1,Model ID = MiniMax-M2.7(标准版,非 highspeed)。

十一、风险与应对

风险 概率 应对
Phase 1 前端骨架延期 中 单位机有家用机的代码 zip 可参考,降低重写成本
MiniMax M2.7 切入 Plan 后方案质量下降 中 临时切回 Sonnet 顶住,Phase 2 末复盘是否回切
历史 Excel / docx 导入解析失败 高 解析失败的文件单独列出,提示责编手工修正后重传
编导抗拒使用新工具 中 "辅助不替代"的产品哲学贯穿,绝不强制;先让最积极的 1-2 位编导先用,产生口碑
收视目标变化导致颜色判定混乱 低 时间不变性原则保护历史(yearly_targets 只增不改)
单位 4090D Gitea 故障 低 制片人本地 Git 仓库 + 远程备份,不全部押在 Gitea 上

十二、不在 1.0 范围内的事

明确不做、留到 2.0 或更远的:

  • TypeScript 改造
  • Alembic 数据库迁移
  • async SQLAlchemy
  • AI 模型配置 UI(模型 / API Key 配置写在 .env)
  • 模块 D 的 AI 预测(只展示原文)
  • 文稿写作辅助系统
  • Karpathy LLM Wiki 知识形态(仅预埋接口)
  • 移动端 App
  • 多栏目复用(架构上预留可能,1.0 不实现)

十三、版本演进

版本 日期 主要变化
v1 2026-04 初版,定模块 A-G(7 个)
v2 2026-05-04 加模块 H 热点雷达,增 2.0 兼容预埋说明
v3 2026-05-06 加 MiniMax M2.7 接班 Plan 模式分工(第十章)、Git 仓库信息、单位机重启路径、风险表中 Gitea 项;DeepSeek pro 全程在岗 Act

本文件最高优先级中的"产品宪法"。技术与协作详见姊妹文档。 下次修订建议时机:Phase 5 末(MVP 上线后,根据真实使用反馈修订 2.0 路线图)。

Reference in New Issue View Git Blame Copy Permalink