tps-dashboard/project_plan.md

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

---

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