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

413 lines
22 KiB
Markdown
Raw Permalink 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