simonkoson/tps-dashboard
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
31fb490b6d186f7656de09c1324052de67a54737
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-14 拍板)

角色 模型 职责
制片人 刘通(人) 拍板、审核、领域知识权威、视觉把关
高级技术顾问 Claude Opus 4.7(claude.ai 网页) 架构指导、方案审核、风险预警、Cline 卡壳兜底
架构师 MiniMax M2.7(Cline Plan 模式) 项目内方案设计、Act 改动审查
执行者 MiniMax M2.7(Cline Act 模式) 实际写代码
备选执行者 DeepSeek v4 flash 仅日常小改(改字段、加字段、改文案)

为什么全程 MiniMax M2.7:

  • 家用机已退役,唯一开发环境为单位 4090D
  • Plan + Act 双角色统一使用,降低模型切换开销
  • 成本为 Sonnet 的 1/50,性能对标 Claude Opus,中文理解好
  • DeepSeek v4 pro 备选,仅在 MiniMax 连续两次质量下降时临时启用

接入信息:base_url = https://api.minimaxi.com/v1,Model ID = MiniMax-M2.7(标准版,非 highspeed),API Key 已由制片人申请就绪。

十一、风险与应对

风险 概率 应对
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
v4 2026-05-14 家用机退役,唯一开发环境为单位 4090D;Phase 2 起 MiniMax M2.7 正式日常使用;更新版本演进记录

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

Reference in New Issue View Git Blame Copy Permalink