2026-05-27 19:51:41 +08:00
|
|
|
|
# backlog.md — TPS 工作台待办池（不丢视野，非排期）
|
|
|
|
|
|
|
|
|
|
|
|
> 维护人：刘通 + 顾问 Opus
|
|
|
|
|
|
> 用途：记录"暂不做但不能漏"的事项。区别于 phase 计划，这里是池子，
|
|
|
|
|
|
> 每个 Phase 收尾时回看一遍，决定捞哪条进下个 Phase。
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## A. 定位澄清（认知，非待办）
|
|
|
|
|
|
|
|
|
|
|
|
- 本系统对外称"中台/工作台"，实质是**单栏目业务系统**（一条业务线、8 用户）。
|
|
|
|
|
|
- 不套真中台那套（多租户/服务网格/配置中心/跨线统一权限）——对 8 人是纯负担。
|
|
|
|
|
|
- 真正定位：把散在 Excel/Word/微信/个人电脑/师徒口传的工作流，收拢成
|
|
|
|
|
|
有沉淀、有权限、可检索的系统。核心价值 = 经验从"靠人"变"靠系统"。
|
|
|
|
|
|
- 现有克制选择（不用 TS / 不用 Alembic / pgvector 不用独立向量库 /
|
|
|
|
|
|
Session 不用 JWT）方向正确，保持。
|
2026-06-12 17:13:32 +08:00
|
|
|
|
- ⚠️ 更新(2026-06-12):看板分析升级相关待办(原 F1-F8)已整体迁移到
|
|
|
|
|
|
**TPS 看板分析升级子项目**。主 project 这边不再维护这部分待办。
|
|
|
|
|
|
子项目状态见 `寄存条_看板升级已外迁.md`。
|
|
|
|
|
|
- doco 相关条目已外迁
|
2026-05-27 19:51:41 +08:00
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## B. 工作台核心能力缺口（按优先级）
|
|
|
|
|
|
|
|
|
|
|
|
### B1. 选题状态流转【优先级：高】
|
|
|
|
|
|
- 现状：episodes 存收视+元数据，但"提报→立项→排期→拍摄→制作→播出→复盘"
|
|
|
|
|
|
这条状态线是散的。
|
|
|
|
|
|
- 建议：给 topics/episodes 加状态机字段，制片人一眼看到每个选题卡在哪环。
|
|
|
|
|
|
- 与模块 F 甘特图区别：甘特是排期视角，这是业务状态视角，两回事。
|
|
|
|
|
|
- 触发时机：Phase 4b（TPS 闭环时一并补最自然）。
|
|
|
|
|
|
|
|
|
|
|
|
### B2. 操作留痕 / 审计【优先级：高，成本极低，建议早埋】
|
|
|
|
|
|
- 现状：谁改收视、谁删选题、谁换题图，全靠信任，无记录。
|
|
|
|
|
|
- 建议：核心业务表（episodes/topics/yearly_targets）加
|
|
|
|
|
|
created_by / updated_by / updated_at 字段即可，不必做复杂日志系统。
|
|
|
|
|
|
- 触发时机：越早埋越好，建议 Phase 3 起手时顺带加（改表成本最低）。
|
|
|
|
|
|
|
|
|
|
|
|
### B3. 数据导出 / 备份【优先级：中】
|
|
|
|
|
|
- 现状：Phase 2 做了 Excel 导入，导出是它的镜像，迟早要。
|
|
|
|
|
|
- 收视、选题是栏目资产，将来要能导出 Excel、能定期备份。
|
|
|
|
|
|
- 触发时机：Phase 5 上线前后。
|
|
|
|
|
|
|
|
|
|
|
|
### B4. 通知 / 待办提醒【优先级：低】
|
|
|
|
|
|
- "选题被审了""该交稿了"这类。小团队可能微信/Mattermost 群就解决了。
|
|
|
|
|
|
|
|
|
|
|
|
- 若 B 见下方与 Mattermost 打通，可借 IM 发通知，不必自建。
|
|
|
|
|
|
|
|
|
|
|
|
- 触发时机：看实际使用反馈再定，可能不做。
|
|
|
|
|
|
|
|
|
|
|
|
### B5.关联【优先级：低】
|
|
|
|
|
|
|
|
|
|
|
|
题图"自动算近5期最高份额提示"本期做的是静态文案占位, 自动计算挪二期(原计划)。
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## C. 跨系统整合（与现有其他系统合服务器、打通）
|
|
|
|
|
|
|
|
|
|
|
|
### C1. 蓝皓配音 TTS 2.0 合服务器【待商议】
|
|
|
|
|
|
- 背景：TTS 2.0 现为独立网站/服务器，单租服务器费钱。
|
|
|
|
|
|
- 设想：与 TPS 中台挪到同一台服务器，省一份租金。
|
|
|
|
|
|
- 待办：制片人把 TTS 2.0 源代码给 Opus → 一起评估
|
|
|
|
|
|
①技术栈是否冲突（端口/依赖/数据库）②Nginx 反代能否共存
|
|
|
|
|
|
③资源够不够（4核8G 轻量服务器跑两套+PG+pgvector 要算内存账）。
|
|
|
|
|
|
- 注：dev_plan 部署章已写"Nginx 反代整合 TPS / 蓝皓 TTS / MMIM"，本条是落实。
|
|
|
|
|
|
- 触发时机：Phase 5 部署规划时。
|
|
|
|
|
|
|
|
|
|
|
|
### C2. Mattermost(内部 IM) 打通【待商议】
|
|
|
|
|
|
- 背景：团队内部 IM 用 Mattermost，部署在与 TTS 2.0 同一服务器。
|
|
|
|
|
|
- 设想：TPS 的通知/待办（见 B4）可推到 Mattermost，不必自建通知系统。
|
|
|
|
|
|
- 待办：评估 Mattermost incoming webhook 接入成本（通常很低）。
|
|
|
|
|
|
- 触发时机：B4 真要做时一并考虑。
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## D. 已知技术隐患（从 phase log 汇集，不漏）
|
|
|
|
|
|
|
|
|
|
|
|
- backend/ 补 venv（全局依赖搬进去）。
|
|
|
|
|
|
- 隐患 A：ImportError 与 Python 内置同名（低优）。
|
|
|
|
|
|
- 隐患 B：ExcelService 返回 Pydantic 化（低优）。
|
|
|
|
|
|
- Phase 5 部署安全：SECRET_KEY 换真随机、same_site=strict + https_only=True、
|
|
|
|
|
|
上 SSL、关 /docs。
|
|
|
|
|
|
- Phase 5 上线前数据清理：清测试数据（期次 8888/8889、年度目标 2027/2028
|
|
|
|
|
|
占位等），录真数据。
|
|
|
|
|
|
- logo 路径用 /src/assets/...(Vite开发模式),生产打包会失效,Phase5部署改。 - reset_password.py 能改任意用户密码,Phase5部署前不能暴露在生产环境。 - 柱图设计为取最近12期,当前真实数据仅7期故显7根;Phase5录真数据后自动补齐,届时确认满12根正常。 - 完成率用 new Date().getFullYear() 取当前年:每年初需录入当年 yearly_targets, 否则跨年后两项完成率显"—"。(运营提醒,非bug)
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## E. 明确不做（防止被"中台"概念诱导加功能）
|
|
|
|
|
|
|
|
|
|
|
|
- 多租户、服务网格、配置中心、跨业务线统一权限平台 —— 8 人单栏目纯负担。
|
|
|
|
|
|
- 任何让 AI 替编导拍板的功能 —— 违背"AI 给方向不给答案"。
|
