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

22 KiB
Raw Blame History

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

项目:TPS(Topic Planning System)中台 — 央视《军事科技》栏目内部工作台 仓库:tps-dashboard 修订版本:v5 · 2026-05-27 制片人:刘通 协作大模型:Claude Opus 4.7(顾问)+ MiniMax M2.7(Plan + Act,Cline 内双角色物理隔离)

一、文档定位

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

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

这三份文件是宪法,改动应慎重,但不是不可变——随着开发推进、制片人对系统的理解越来越具体,宪法会迭代升级(如 v5 把 TPS 从"结果列表"升级为"对话式策划助手")。每周执行细节进 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 建议改"的设计都要重做。

TPS 的产品定位(v5 明确):TPS 选题策划系统是一个**"带着栏目全部家底的策划助手"**,不是"主编的数字分身"。这半格之差是产品的命:

  • 主编会说"我建议你这么做"——带判断倾向,替编导拿主意。
  • 助手会说"顺着你这个思路,栏目里有这些相关家底,要不要我帮你理一理"——把判断的原料和脉络铺好,人来拍板。

TPS 做后者。它可以对话、可以加工、可以给有依据的分析("这个角度历史上收视偏低,可能和切入点有关"),但分析永远是摆事实 + 给关联,不是下结论("所以别做")。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 核心入口)

痛点:编导有一个创意或灵感,担心做过、想知道历史成绩;新编导面对一堆历史节目,不知道怎么用、看不出"so what"。

形态(v5 升级——从"结果列表"升级为"对话式策划助手"):

界面采用左右双栏:

  • 左栏:编导与 TPS 的对话区。编导输入只言片语的灵感,可持续追问、逐步把思路聊清楚。
  • 右栏:一份由 AI 加工的策划参考报告,随对话深入而越来越贴合。

报告内容(全部基于栏目自己的知识库,有依据、可追溯):

  • 这个选题方向之前有没有人做过、是谁做的、收视成绩怎么样(联动 episodes,颜色判定见第 6.1 节)
  • 当时领导有什么点评、审片意见(联动模块 D / review_comments)
  • 有没有可参考的往期节目(提供节目链接/索引)
  • 若涉及外拍,是哪个单位、联系人是谁(联动模块 E / shooting_resources)
  • 相关的往期文稿 / 专业期刊 / 权威资料(联动模块 C / knowledge_items)

三条不可动摇的交互红线(经业界研究验证,见 v5 起草说明):

  1. 求助式,不是投喂式:报告默认是编导"叫出来"的,而非编导刚敲半句就自动甩一整屏盖住。展开与深入由编导主动触发——主动权握在"要不要展开"这个动作上。
  2. 脚注式锚定引用:报告里每个结论后挂一个不打扰阅读的小角标,点开才看到依据(哪期节目/哪篇期刊)。不大面积平铺引用,仿纸质图书脚注。此设计既让编导能一键核实、不盲信,也经研究证明能降低对 AI 的过度依赖。
  3. 持续对话沉淀编导的判断:编导每聊一轮都在投入自己的思路,聊到最后报告里有编导自己的烙印,而非 AI 一次性吐出的成品。聊定后,可一键转入模块 G 生成报题单。

AI 哲学:不告诉编导"建议放弃 / 建议做",只摆事实、给关联、做有依据的分析,让编导自决。

落地顺序(重要):此对话式形态属 Phase 4a,且必须在知识库笔记 + 收视数据真实灌入之后才上线。库空时此助手"无米下锅",依据全空会毁掉第一印象。Phase 3 内先做朴素语义检索(输入灵感→返回最相关的几条带相关度、原文片段、来源),作为此形态的第一块积木。

模块 B — 编导画像建议

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

功能:

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

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

模块 C — 知识库参考(策划报告的依据来源)

痛点:写选题时缺背景资料,需要去翻往期文稿、军报、专家观点;更进一步,编导希望 AI 给的策划建议是"有出处的",不是凭空说。

形态(v5 升级):模块 C 是模块 A 右栏报告的知识库依据供给侧。

  • 编导在对话中表达灵感时,系统语义检索 knowledge_items(往期文稿 + 军报 + 专业期刊 + 内部资料)
  • 检索到的条目不再是孤立"列 3-5 条让编导自己翻",而是融入右栏报告,作为报告里相关论断的脚注式引用依据(见模块 A 红线 2)
  • 编导可点开任一脚注查看原文摘要 + 关键词,可选择性引用,引用关系入库(为 2.0"知识溯源"打基础)

关键技术:pgvector + MiniMax embo-01 embedding + 1536 维向量(embedding 服务已于 Phase 3 Task 1 确定为 MiniMax embo-01,见 phase3_log)。

朴素检索先行:Phase 3 内先把"输入文本→返回最相关知识库条目"这条朴素检索链路接通(带相关度、原文片段、来源),它是模块 A 对话式报告的检索底座。

模块 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 — 报题单生成与下载

痛点:报题单格式各编导各异,审核耗时;水平参差的编导写的报题单结构残缺、要素不全、漏洞百出。

形态(v5 明确):编导与 TPS 在模块 A 里聊定选题后,点一个按钮,把编导已定的内容按《军事科技》报题单格式一键生成 .docx,提供下载。

  • 模板由 docxtpl 渲染,严格遵守"双段结构"(引子 + 列举,见 .clinerules 第 5.4 节)
  • AI 通过学习成熟报题单范本,帮助生成的报题单更规范:补齐结构、统一格式、提示遗漏要素、校对装备名/概念名——专治"漏洞百出"
  • 编导可下载、修改、打印

"一键生成"的分寸线(死规矩,不可越):

这个按钮做的是**"按范本规范化呈现编导已定的内容"**——排版 + 校对 + 结构补齐 + 遗漏提示。 AI 不替编导生产选题立意、不代写内容。规范化只作用于"格式、结构、要素齐全、字词准确"这一层;选题的内容和立意永远是编导的创作。 一旦 AI 在内容立意上动手,就从"助手排版"滑回了"代写",违背创作主权红线。

落地顺序:属 Phase 4a。

模块 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 序号,每条以 **加粗关键词** 开头)。 备选:纯叙述,仅当编导明确指定才用。

6.5 AI 摆牌不出牌(创作主权红线,v5 新增)

TPS 是"策划助手"不是"主编数字分身"(见第 2.3 节)。落到每一处 AI 交互:

  • 摆事实、给关联、做有依据的分析——可以。
  • 下结论、给倾向、替编导拿主意("建议放弃/建议这么改")——不可以。
  • AI 的所有输出都是**"摆给编导看的牌"**,牌由编导自己出。
  • 凡 AI 输出处,UI 必须给编导"忽略 / 我来改写"的否决权。
  • 报题单"一键生成"只做规范化呈现,不代写选题立意(见模块 G 分寸线)。

自检口诀:这句 AI 的话,是"把原料铺给你看",还是"替你做了决定"?后者一律改掉。

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

详细请见 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 知识库基础设施 + 报题单导入 进行中(已完成至 Task 3 知识库树形视图;语义检索尚未做)
Phase 4a Week 5-6 MVP 上线(对话式 TPS + 报题单生成 + 知识库参考) 未开始
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 flash 备选,仅在小改任务(改字段、改文案)且 MiniMax 不可用时使用;复杂任务遇到 MiniMax 连续失败 → 切 Opus 4.7 重新规划,不在 Cline 里换 Act 模型

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

注意:上表是开发期的模型分工(谁帮我们写代码)。下文第十一章讲的是产品运行期的 AI 调用成本(系统上线后,编导每天用 TPS 烧的钱),两者是两笔账。

十一、AI 成本与额度原则(v5 新增)

TPS 升级为对话式策划助手后,编导每用一次都要调大模型。8 人长期高频使用,这笔运行成本不小,且对话式产品有个特点:用户聊得越爽烧得越多,而自己往往不知道在烧钱。本节定原则,具体收费方式待 MVP 能用后再拍。

11.1 成本归属(待确认,但方向先定)

  • 优先争取栏目报销:TPS 是栏目的生产力工具,理应走栏目经费。系统未上线前无法确认能否报销,先记为待办,不要现在自己垫钱去设计收费系统。
  • 不向编导收费(明确反对):让编导自己充值或填个人 API Key,等于给"用不用这个工具"装了计价器,跟"对用户像对客户、鼓励新编导多用多练"的初心直接打架。新编导越该多用,越不能让他舍不得花钱而不敢用。

11.2 1.0 必须预埋的三件事(不贵,但必须从第一天就埋,事后补极难)

以下为业界对 LLM 应用控成本的共识做法,已用大白话翻译;取其神,弃其形——下面"不要做"那条尤其重要。

  1. 按"用量(token)"记,不是按"次数"记:同样问一次,随口问一句和把整篇文稿贴进去追问,成本差几十倍。所以计量与限额都要按真实消耗的量,而不是"今天能问几次"。
  2. 按"人 + 选题"归因:每次调用都打上"是谁、为哪个选题"的标签。这是"费用不能都制片人出"的技术前提——将来无论报销、分摊还是台里统一付,账都清楚。
  3. 保守上限 + 超额提醒管理员:上线时给每人先卡一个偏紧的月度额度,超了提醒管理员(制片人),看真实用量再松绑。绝不允许"某编导一个通宵烧光全月预算"。

11.3 不要做的(防止 Cline 上重型武器)

业界控成本的文章常提"AI 网关 / OpenTelemetry / 可观测性平台"——那是给几百上千人、多团队大公司用的重武器,8 人小项目完全不需要。我们要的就是最朴素的:每次调用往一张表记一行(谁、何时、烧多少、为哪个选题),管理员页面看汇总、设上限。Cline 若提议引入网关或可观测性框架,一律驳回。

落地 Phase:额度机制随对话式 TPS(Phase 4a)一起做;Phase 3 朴素检索只调 embedding(每篇几厘钱量级),暂不涉及此机制。

十二、风险与应对

风险 概率 应对
MiniMax M2.7 切入 Plan 后方案质量下降 中 临时切回 claude.ai 找 Opus 4.7 重新规划,不在 Cline 里换模型
历史 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 正式日常使用;更新版本演进记录
v5 2026-05-27 TPS 定位升级:模块 A/C/G 从"结果列表"升级为"对话式策划助手"(左对话右报告、脚注式锚定引用、求助式不投喂);新增第 2.3 节产品定位、6.5 节"AI 摆牌不出牌"红线、第十一章"AI 成本与额度原则";明确朴素语义检索(Phase 3)→ 对话式 TPS(Phase 4a,数据灌入后)的落地顺序;清理过期风险项

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

Reference in New Issue View Git Blame Copy Permalink