fix: 完成 doco src layout 重构,文件移至 src/doco/ 子目录
This commit is contained in:
simonkoson
@@ -0,0 +1,364 @@
|
||||
# 主 project 答复 — 分钟收视回放子板块
|
||||
|
||||
> 版本：v1
|
||||
> 日期：2026-06-11
|
||||
> 作者：TPS 主 project 顾问 (Claude Opus 4.7) + 制片人 刘通
|
||||
> 状态：已采纳，待秒级 chat 接收并按本文件推进实现
|
||||
> 上一版：无
|
||||
> 对应文档：秒级收视 project《军事科技_分钟收视回放_子板块需求规格.md》v1（2026-06-10）
|
||||
|
||||
---
|
||||
|
||||
## 一、本文件用途
|
||||
|
||||
回复秒级 chat 那份 PRD 第八节的 6 个对接问题，并把主 project 这边的**红线、修订建议、交付物期待**全部白纸黑字写下来。本文件是子板块继续推进的**最终输入**，秒级 chat 这边可基于此开干。
|
||||
|
||||
子板块结束前，要按本文件第九节的清单产出**五份交付物**给主 project。主 project 这边的 Cline 拿着五份交付物落代码，完成最终整合。
|
||||
|
||||
---
|
||||
|
||||
## 二、对 6 个对接问题的最终答复
|
||||
|
||||
### 1. TPS 工作台有没有"每期节目详情页"？
|
||||
|
||||
**没有。子板块需要附带把详情页骨架建起来。**
|
||||
|
||||
现状：仪表盘 (Dashboard) 是聚合视角，责编录入页 (EditorDesk) 是表单 + 列表，**没有"看单期 + 该期所有维度"的页面**。分钟收视回放需要这个容器，整个工作台早晚也需要这个页面，借这次一起做掉。
|
||||
|
||||
入口规划：
|
||||
- 仪表盘柱图每根柱子点进去 → 详情页
|
||||
- EditorDesk 列表行点进去 → 详情页
|
||||
- 路由建议：`/episodes/:id`，`:id` 用 `episodes.id`（SERIAL 主键）
|
||||
|
||||
详情页骨架要预留位置承载未来其他维度（审片意见、文稿、外拍信息等），分钟收视回放是其中**第一个模块**。
|
||||
|
||||
### 2. 数据库技术栈
|
||||
|
||||
**PostgreSQL 16 + pgvector（1536 维）**，ORM 是 **SQLModel（同步，非 async）**。
|
||||
|
||||
手写 SQL 走 `backend/sql/00X_*.sql`，不用 Alembic。
|
||||
|
||||
第五节那两张表的接入方式见第四节"数据模型修改建议"——简短版：**别新建"节目期次表"，复用现有 `episodes` 表**；分钟数据表新建，命名 `episode_minute_ratings`，外键挂到 `episodes.id`。
|
||||
|
||||
### 3. 视频和截图存储方案
|
||||
|
||||
**最终决策：视频不入工作台。**
|
||||
|
||||
- 视频本体由制片人在本地/百度网盘/极空间多渠道自存
|
||||
- 工作台只接收**截图**（27 张 jpg）
|
||||
- 不再讨论服务端 ffmpeg、视频压缩、转码删源片等服务端方案
|
||||
|
||||
截图处理走**本地切图工具**（子板块产出，详见第五节）：
|
||||
|
||||
- 责编本地双击工具 → 拖入源片 → 自动切 27 张 480p 截图 + 命名好
|
||||
- 责编打开工作台 → 一键多文件上传截图（~5 MB 一次传完）
|
||||
|
||||
截图存储：服务器文件系统 `/screenshots/{episode_id}/{分钟序号_两位数}.jpg`，数据库只存 URL。
|
||||
|
||||
### 4. 前端技术栈
|
||||
|
||||
**React 18 + Vite + Ant Design 5 + Zustand**，JavaScript（不用 TS），项目宪法锁定。
|
||||
|
||||
图表库选型：
|
||||
|
||||
- **优先 @ant-design/charts**：与现有 AntD 5 视觉血缘最近，配色和圆角自然贴合
|
||||
- **次选 ECharts**：自定义 tooltip 模板灵活成熟
|
||||
- **已用过 Recharts**：仪表盘柱图已采用
|
||||
|
||||
**不要再引第三方图表库**。三选一即可，最终选哪个由 Cline 在 Plan 阶段定。
|
||||
|
||||
### 5. 后台异步任务怎么跑
|
||||
|
||||
**在"视频不入工作台 + 本地切图工具"决策下，服务端没有重型异步任务。**
|
||||
|
||||
工作台后端只接收截图入库 + 跑数据校验（见第四节建议 E），都是毫秒级同步操作，**FastAPI BackgroundTasks 都用不上**。
|
||||
|
||||
如果未来某个新场景确实需要异步任务，再启用 FastAPI BackgroundTasks。**不引 Celery、不引 Redis 队列**——8 人栏目用这些是过度工程。
|
||||
|
||||
### 6. 录入身份/权限
|
||||
|
||||
**有完整用户系统**：Session + Cookie 认证，三角色拼音枚举锁定（`zhipianren` / `zebian` / `biandao`）。
|
||||
|
||||
写权限规则参照 `yearly_targets` 既有口径平移：
|
||||
|
||||
- **POST/PATCH/DELETE 录入分钟数据 + 上传截图**：`zhipianren` + `zebian` 可写，`biandao` 返回 403
|
||||
- **GET 查看分钟回放**：三角色均可读
|
||||
|
||||
**实现细节**：FastAPI 后端直接从 session 拿 user_id 写入 `created_by` 字段，**前端不要把"录入人"作为字段提交**。
|
||||
|
||||
字段命名用 `created_by INTEGER REFERENCES users(id)`，**不要用 string 类型的"录入人姓名"**——主 project backlog 里有一条 "操作留痕 schema"（待办池 B2），分钟收视这张新表作为落地先例。
|
||||
|
||||
---
|
||||
|
||||
## 三、视频/截图最终方案（决策落地）
|
||||
|
||||
### 责编一周一期的标准流程（最终版）
|
||||
|
||||
```
|
||||
周二 21:20-21:47 节目播出
|
||||
↓
|
||||
周二 22:00 后 责编到总编室账号抄 27 个份额数字（保留原方案）
|
||||
↓
|
||||
次日 责编打开本地切图工具
|
||||
↓
|
||||
拖入当期源片 mp4 → 工具自动切 27 张 480p jpg
|
||||
+ 自动命名为 01.jpg ~ 27.jpg
|
||||
↓
|
||||
责编登录工作台 → 进入"节目期次"管理
|
||||
→ 选择当期 episode（基于已录入的 episodes 记录）
|
||||
→ 进入分钟收视模块
|
||||
↓
|
||||
上传 27 张截图（多文件选择 / 拖拽）
|
||||
→ 服务器存到 /screenshots/{episode_id}/
|
||||
→ 数据库写入 27 条 episode_minute_ratings 记录
|
||||
↓
|
||||
录入 27 个份额数字
|
||||
（推荐："批量粘贴一列数字"输入框，
|
||||
从 Excel 复制 27 个数字粘贴后系统按行切分）
|
||||
→ 系统软校验（数据齐全？范围合理？均值与已录全期均值吻合？）
|
||||
→ 保存
|
||||
↓
|
||||
该期详情页里"分钟收视回放"模块即刻可看
|
||||
```
|
||||
|
||||
### 主 project 这边不做的事
|
||||
|
||||
- 服务端 ffmpeg（不需要）
|
||||
- 视频上传接口（不需要）
|
||||
- 视频压缩转码（不需要）
|
||||
- 异步任务队列（不需要）
|
||||
- 视频删除/清理脚本（不需要）
|
||||
|
||||
---
|
||||
|
||||
## 四、数据模型修改建议（主 project 在此明确给出）
|
||||
|
||||
> 任何 schema 改动**必须经主 project 顾问 (Opus) 审、配回补方案，Cline 不得自行动手**。这是项目红线。下面是建议方案，最终落地前还会过一遍审查。
|
||||
|
||||
### 建议 A：复用现有 `episodes` 表，**不新建"节目期次表"**
|
||||
|
||||
现有 episodes 表已涵盖你需要的全部"节目期次"信息：
|
||||
|
||||
| 你的字段 | 对应现有 episodes 字段 |
|
||||
|---|---|
|
||||
| 期次主键 | `id`（SERIAL） |
|
||||
| 期数显示 | 前端从 `air_date` + `episode_number` 拼，不入库 |
|
||||
| 节目名称 | `program_name` |
|
||||
| 播出日期 | `air_date` |
|
||||
| 播出时段 | 不入库，前端常量 "21:20-21:47" |
|
||||
| 备注 | `notes` |
|
||||
|
||||
理由：新建一张冗余表会割裂 episodes 与其他模块（收视成绩、外拍、未来选题、审片意见）的关联，破坏单一事实源。
|
||||
|
||||
### 建议 B：用 `episodes.id`（INTEGER）做外键，**不用"播出日期 string"做主键**
|
||||
|
||||
秒级 chat v1 文档建议"期次主键用 `2026-06-09` 字符串"。这与 `episodes.id SERIAL` 体系冲突。
|
||||
|
||||
最终方案：分钟数据表用 `episode_id INTEGER REFERENCES episodes(id)` 外键，所有展示字符串（"2026 年第 23 期 · 2026-06-09"）由前端从 episodes 数据拼出，不入库。
|
||||
|
||||
### 建议 C：`收视份额` 用 `NUMERIC(6,4)`，**不用 float**
|
||||
|
||||
与现有 `episodes.audience_share NUMERIC(6,4)` 类型对齐，避免浮点比较的怪事。
|
||||
|
||||
### 建议 D：新表 `episode_minute_ratings` 建议 schema
|
||||
|
||||
```sql
|
||||
CREATE TABLE IF NOT EXISTS episode_minute_ratings (
|
||||
id SERIAL PRIMARY KEY,
|
||||
episode_id INTEGER NOT NULL REFERENCES episodes(id) ON DELETE CASCADE,
|
||||
minute_index INTEGER NOT NULL CHECK (minute_index BETWEEN 1 AND 27),
|
||||
audience_share NUMERIC(6,4) NOT NULL,
|
||||
screenshot_url VARCHAR(500),
|
||||
created_by INTEGER NOT NULL REFERENCES users(id),
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
|
||||
updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
|
||||
UNIQUE(episode_id, minute_index)
|
||||
);
|
||||
|
||||
CREATE INDEX idx_minute_ratings_episode ON episode_minute_ratings (episode_id);
|
||||
```
|
||||
|
||||
P1+ 扩展（多期对比、批注/标签）：1.0 不建表，到 P1 触发时再说。当前 UNIQUE 复合键和外键设计已留好扩展空间。
|
||||
|
||||
### 建议 E：工作流补一个"软校验"环节
|
||||
|
||||
录入 27 个分钟份额时，系统应做**非阻塞**的合理性提示：
|
||||
|
||||
- 27 个数字是否齐？
|
||||
- 最大值/最小值是否在合理区间（如 0-3）？
|
||||
- 27 个数字的平均值是否与已录的 `episodes.audience_share`（该期全期均值）大致吻合？误差 > 30% 给"数据可能录错"提示
|
||||
|
||||
不阻塞保存，只是温柔提醒。理由：分钟数据是栏目考核依据，权重最高，录错一个小数点不发现就一直错。
|
||||
|
||||
### 建议 F：批量导入接口复用现有 ExcelService
|
||||
|
||||
23 期历史数据一次性导入：复用主 project 已有的 ExcelService 框架（Phase 2 Task 2 跑通），但单开一个 endpoint：
|
||||
|
||||
- 上传一份"期次 × 27 列分钟份额"的 Excel
|
||||
- 按行展开成 23 × 27 = 621 条 `episode_minute_ratings` 入库
|
||||
- 截图 URL 字段第一次导入时留空，后续走本地工具补传
|
||||
|
||||
### 建议 G：episodes 表是否要加视频 URL 字段？
|
||||
|
||||
**不加。**
|
||||
|
||||
因为视频不入工作台。如果未来某天想记录"这一期视频存在哪个网盘 / 哪个本地路径"，可以走 `episodes.notes` 字段写自由文本，不需要专门字段。
|
||||
|
||||
---
|
||||
|
||||
## 五、本地切图工具规格（子板块产出物之一）
|
||||
|
||||
子板块的 Claude 负责设计与实现这个工具。
|
||||
|
||||
### 5.1 形态
|
||||
|
||||
- 一个 Windows 上能跑的可执行文件（py 源码 + pyinstaller 打包成 exe）
|
||||
- 双击即用，无安装步骤
|
||||
- 不依赖网络，不依赖工作台，完全离线
|
||||
- 不需要责编装 Python 环境
|
||||
|
||||
### 5.2 用户界面
|
||||
|
||||
简洁到极致：
|
||||
|
||||
- 一个窗口，拖文件进去即可（或"选择文件"按钮）
|
||||
- 接收 mp4 / mov / mkv 等常见格式
|
||||
- 进度条显示切图进度
|
||||
- 完成后弹"已生成 27 张截图于 [输出文件夹]"
|
||||
- 自动打开输出文件夹
|
||||
|
||||
### 5.3 切图规则（与秒级 chat v1 文档保持一致）
|
||||
|
||||
```bash
|
||||
# 27 张截图，每分钟第 30 秒位置，480p (854 × 480)
|
||||
for i in $(seq 0 26); do
|
||||
sec=$((i*60+30)) # 0:30, 1:30, 2:30, ..., 26:30
|
||||
ffmpeg -i 源片.mp4 -ss $sec -vframes 1 -vf scale=854:480 \
|
||||
"$(printf "%02d" $((i+1))).jpg" -y
|
||||
done
|
||||
```
|
||||
|
||||
输出文件名规则：**`01.jpg` ~ `27.jpg`**（两位数，零填充，便于排序）。
|
||||
|
||||
### 5.4 输出文件夹组织
|
||||
|
||||
工具自动新建一个文件夹，命名建议：`截图_{源片文件名去后缀}_{日期}/`，里面 27 张 jpg。
|
||||
|
||||
### 5.5 ffmpeg 依赖
|
||||
|
||||
打包时把 ffmpeg.exe 一并塞进 exe，或者用 `imageio-ffmpeg` 包自动下载。**绝对不要让责编手动装 ffmpeg**。
|
||||
|
||||
### 5.6 错误处理
|
||||
|
||||
- 源片读不到 → 弹窗"文件无法读取，请检查格式"
|
||||
- 源片时长 < 26 分 30 秒 → 弹窗"视频时长不足 27 分钟，是否继续？"（允许跳过缺失分钟）
|
||||
- 输出文件夹已存在 → 自动加时间戳后缀
|
||||
|
||||
### 5.7 给责编的使用说明
|
||||
|
||||
子板块产出一份 `使用说明.md`，傻瓜级，要有截图。预期长度 200-400 字 + 3-5 张截图。
|
||||
|
||||
---
|
||||
|
||||
## 六、主 project 红线（不可越）
|
||||
|
||||
子板块设计与实现过程中，下面这几条是**主 project 宪法**，任何方案不得违反：
|
||||
|
||||
1. **改 schema 须主 project 顾问 (Opus) 审**：包括新建表、改字段、加字段。Cline / 子板块 Claude 不得自行动手。
|
||||
2. **角色枚举锁定拼音值**：`zhipianren` / `zebian` / `biandao`，不许新增枚举，不许用英文别名。
|
||||
3. **AI 给方向不给答案**：分钟收视回放的 P1+ 功能（多期对比找规律、批注 AI 建议等）若涉及 AI，必须保持"建议草稿 + 制片人审核"的三档置信度，不得 AI 直接拍板。
|
||||
4. **编导关联用"软引用 + 快照"**：本子板块如需展示编导信息，沿用 `episodes.editor_id` + `episodes.editor_name_snapshot` 双字段，不许新增编导关联字段。
|
||||
5. **收视颜色判定**：红=优秀（>摸高目标）/ 蓝=达标 / 绿=待提升（<基础目标）。反直觉规约，分钟收视回放折线图如果上色，按此规则。
|
||||
6. **AI 输出必须有"忽略 / 我来改写"否决权**：任何 AI 建议（如本子板块 P1+ 的 AI 找规律功能）必须给编导否决入口。
|
||||
7. **不引新依赖**：图表库三选一（@ant-design/charts / ECharts / Recharts），不引第四个；后端不引 Celery / Redis 队列。
|
||||
|
||||
---
|
||||
|
||||
## 七、子板块产出物清单（最终交付包）
|
||||
|
||||
子板块结束前，请凝结成以下**五份交付物**，作为整体交付给主 project：
|
||||
|
||||
### 产物 1：决策摘要 md
|
||||
|
||||
记录子板块全程的关键决策。每条决策三句话：
|
||||
|
||||
```
|
||||
决策 X：[一句话决策内容]
|
||||
- 背景：为什么需要这个决策
|
||||
- 拍板理由：选这条不选那条的理由
|
||||
- 拍板人：[制片人 / 主 project 顾问 / 子 project Claude 建议+制片人采纳]
|
||||
```
|
||||
|
||||
10-20 条决策足以讲清整个子板块"为什么这么做"。
|
||||
|
||||
### 产物 2：接口约定 md（最技术、最精确）
|
||||
|
||||
把子板块与主 project 接驳的所有"接口"白纸黑字写出来：
|
||||
|
||||
- **数据接口**：新建表 / 字段 / 类型 / 约束（细化到 SQL DDL 级别）
|
||||
- **API 接口**：新增 endpoint URL / 方法 / 请求体 / 响应体 / 错误码
|
||||
- **UI 接口**：在主 project 哪个页面挂载、入口、路由
|
||||
- **权限接口**：哪些角色可以做什么操作
|
||||
- **存储接口**：截图存到哪个目录、命名规则、URL 拼接规则
|
||||
|
||||
要具体到"主 project 的 Cline 拿着这份就能写代码"的程度。**这是子 project 给主 project 的"合同"**。
|
||||
|
||||
### 产物 3：本地切图工具完整包
|
||||
|
||||
- `screenshot_tool.py`：源码，注释齐全
|
||||
- `screenshot_tool.exe`：打包好的可执行文件，责编双击即用
|
||||
- `使用说明.md`：傻瓜级文档 + 截图
|
||||
|
||||
工具规格见本文件第五节。
|
||||
|
||||
### 产物 4：未尽事项 backlog
|
||||
|
||||
诚实写出"子板块讨论中提到但没做的事"。每条三行：
|
||||
|
||||
- 是什么
|
||||
- 为什么没做（暂缓 / P1+ / 等条件成熟）
|
||||
- 触发时机（什么时候应该捡起来）
|
||||
|
||||
放进主 project 的 backlog 池子里。
|
||||
|
||||
### 产物 5：给主 project Claude 的"接手提示词"
|
||||
|
||||
一两段话，告诉主 project 顾问"如果你是接手这件事的 Claude，最重要的三件事是 X、Y、Z"。
|
||||
|
||||
这次至少要包含：
|
||||
- 复用 episodes 表，不新建节目期次表
|
||||
- 权限沿用 yearly_targets 口径
|
||||
- 本地切图工具与工作台零耦合，不在工作台 UI 里给它留接口
|
||||
|
||||
---
|
||||
|
||||
## 八、跨 project 协作规矩（子板块这边也要遵守）
|
||||
|
||||
1. **不动主 project 代码**：子板块产出文档 + 独立工具，不写主 project 的实际代码。代码合入由主 project 的 Cline 完成。
|
||||
2. **遇到吃不准的事回主 project 问**：本次 v1 文档第八节就是好榜样，继续保持。
|
||||
3. **每份跨 project 文档顶部带元信息块**：版本、日期、作者、状态、上一版、主要变化（v2 以上必填）。
|
||||
4. **一份文档只谈一件事**：不要在分钟收视回放交付包里夹带其他议题。
|
||||
|
||||
---
|
||||
|
||||
## 九、给秒级 chat Claude 的明确动作清单
|
||||
|
||||
收到本文件后，请按下面顺序推进：
|
||||
|
||||
1. **吸收本文件所有决策与红线**，回到秒级 chat 的 PRD v1，把不一致处标注出来（如果有）
|
||||
2. **如有需要修订的地方，出 PRD v2**，顶部元信息块写明跟 v1 的变化点
|
||||
3. **设计本地切图工具**：与制片人讨论用户体验细节，定稿后凭工具规格让秒级 chat 的 Cline 实现（如果有）或制片人自己找 v0/Lovable 等工具生成 demo
|
||||
4. **凝结成最终五份交付物**（第七节清单）
|
||||
5. **交付给制片人**，由制片人带回主 project，主 project 顾问 (Opus) 审一遍，无冲突后主 project 的 Cline 落实施
|
||||
|
||||
---
|
||||
|
||||
## 十、附：版本演进规约
|
||||
|
||||
本文件未来如修订（v2+），顶部元信息块"主要变化"必须写清楚改了什么。
|
||||
|
||||
历史版本不覆盖，旧文件保留在 `docs/cross_project/` 目录（主 project 这边）以便回看决策史。
|
||||
|
||||
---
|
||||
|
||||
*本文件由主 project 顾问 (Claude Opus 4.7) 于 2026-06-11 基于与制片人刘通的两轮对话整理生成，供秒级收视项目接收使用。*
|
||||
@@ -0,0 +1,119 @@
|
||||
# 子项目立项备忘 — 分钟收视回放
|
||||
|
||||
> 文档类型：子项目立项备忘
|
||||
> 子项目名称：分钟收视回放
|
||||
> 立项日期：2026-06-11
|
||||
> 子项目所在：秒级收视 project（Claude.ai 网页版的另一个 project）
|
||||
> 当前状态：**推进中**（设计已收敛，进入子板块内部实现阶段）
|
||||
> 主 project 联系人：制片人刘通 + Claude Opus 4.7 顾问
|
||||
|
||||
---
|
||||
|
||||
## 一、文档用途
|
||||
|
||||
未来主 project 这边新开 chat 时（必然会发生 Claude 失忆），新 Claude 通过此文件快速恢复"分钟收视回放子项目"的上下文。**它不重复 v1 答复 md 里的细节，只留指针 + 关键决策摘要**。
|
||||
|
||||
---
|
||||
|
||||
## 二、立项缘由
|
||||
|
||||
制片人在另一个 project（秒级收视）里讨论分钟收视数据怎么进工作台、怎么呈现。那边 Claude 写了一份 PRD（需求规格 v1, 2026-06-10），向主 project 这边提了 6 个对接问题。
|
||||
|
||||
主 project 这边讨论两轮后采纳"以子项目模式独立推进"，并把答复凝结成正式 md 带回子项目。**这次是项目里第一次完整使用"子项目模式"**——既是分钟收视回放本身的立项，也是这套跨 project 协作工作流的首次实操。
|
||||
|
||||
---
|
||||
|
||||
## 三、关键决策摘要（已采纳，不要重复讨论）
|
||||
|
||||
1. **视频不入工作台**：制片人多渠道自存（极空间/百度网盘/本地），工作台只接收截图
|
||||
2. **本地切图工具**：子板块产出，py + exe + 使用说明，与工作台零耦合
|
||||
3. **复用现有 episodes 表**：不新建"节目期次表"，分钟数据表 `episode_minute_ratings` 外键挂到 `episodes.id`
|
||||
4. **录入人字段用 `created_by INTEGER REFERENCES users(id)`**：不用 string，顺手落地 backlog B2 操作留痕
|
||||
5. **后端不上 Celery/Redis**：异步任务在视频不入库后基本消失，必要时用 FastAPI BackgroundTasks
|
||||
6. **图表库三选一**：@ant-design/charts / ECharts / Recharts，不引第四个，最终由 Cline Plan 阶段定
|
||||
7. **详情页 `/episodes/:id` 骨架由本子板块附带建起来**：早晚要做，借这次一起
|
||||
8. **权限沿用 yearly_targets 口径**：zhipianren + zebian 可写，biandao 只读
|
||||
|
||||
---
|
||||
|
||||
## 四、子板块要交付什么（五份产物）
|
||||
|
||||
子项目结束时，那边凝结以下交付包带回主 project：
|
||||
|
||||
1. 决策摘要 md
|
||||
2. 接口约定 md（含 SQL DDL、API endpoint、UI 接入点、权限规则、存储路径规则）
|
||||
3. 本地切图工具完整包（py 源码 + exe + 使用说明）
|
||||
4. 未尽事项 backlog
|
||||
5. 给主 project Claude 顾问的"接手提示词"
|
||||
|
||||
详见《分钟收视回放_主project答复_v1.md》第七节。
|
||||
|
||||
---
|
||||
|
||||
## 五、主 project 要做的事
|
||||
|
||||
**现在（推进期）**：不做事，不接收过程文档，等收交付包。
|
||||
|
||||
**收到交付包后**：
|
||||
|
||||
1. 主 project 顾问 (Opus) 审一遍，看跟主项目红线有没有冲突
|
||||
2. 无冲突 → 主 project workspace 里让 Cline 落代码
|
||||
3. 有冲突 → 标出冲突点，回子项目修，循环
|
||||
|
||||
---
|
||||
|
||||
## 六、相关文档（指针）
|
||||
|
||||
**外部输入**（子项目发来的）：
|
||||
|
||||
- 秒级 chat 的 PRD v1：《军事科技_分钟收视回放_子板块需求规格.md》（2026-06-10）
|
||||
- 已在主 project files 中（制片人 2026-06-11 上传）
|
||||
|
||||
**主 project 输出**（咱们这边给子项目的）：
|
||||
|
||||
- 《分钟收视回放_主project答复_v1.md》（2026-06-11）
|
||||
- 建议归档位置：`docs/cross_project/分钟收视回放/分钟收视回放_主project答复_v1.md`
|
||||
|
||||
**配套文档**：
|
||||
|
||||
- 《跨project协作提示单_v1.md》（2026-06-11，制片人随身保存）
|
||||
- 不在主 project 仓库内，是制片人个人工作流手册
|
||||
|
||||
---
|
||||
|
||||
## 七、预计回归时间
|
||||
|
||||
未明确锁定。子项目那边的 Claude 表示"没有什么不清楚的了"，已在内部推进。
|
||||
|
||||
**触发主 project 这边介入的信号**：
|
||||
|
||||
- 子项目带交付包过来（正常路径）
|
||||
- 子项目过程中遇到吃不准的事 → 单点咨询主 project 顾问（不要整份过程稿上传）
|
||||
- 超过 4 周还没收敛 → 主动 ping 一下，看是不是要重新切分
|
||||
|
||||
---
|
||||
|
||||
## 八、给未来失忆接手 Claude 的提示
|
||||
|
||||
如果你是几周后接手主 project 的 Claude，看到这份备忘，请记住：
|
||||
|
||||
1. **分钟收视回放是一个独立推进的子项目**，主 project 不掺合其内部讨论
|
||||
2. **复用 episodes 表，不要新建节目期次表**——这是已经定死的决策，不重新讨论
|
||||
3. **改 schema 必须经 Opus 顾问审**，子项目交付包带 schema 修改建议时严守这条
|
||||
4. **本地切图工具与工作台零耦合**，工作台 UI 里不要给它留接口
|
||||
5. **视频不入工作台**——任何提议加视频上传接口的方案都已被否决
|
||||
6. **审查交付包是必经环节**，发现子项目设计违反主项目红线（如角色枚举、收视颜色判定）时直接打回
|
||||
|
||||
---
|
||||
|
||||
## 九、版本演进
|
||||
|
||||
本文件未来如需更新（v2+）：
|
||||
|
||||
- 子项目交付包接收后：更新"当前状态"为"已交付，整合中"
|
||||
- Cline 实施完成后：更新"当前状态"为"已完成"，加一节"实施回顾"
|
||||
- 实施过程中如有重大决策变更：v2 顶部"主要变化"写明
|
||||
|
||||
---
|
||||
|
||||
*本立项备忘由主 project 顾问 (Claude Opus 4.7) 于 2026-06-11 制片人立项动作后随手生成。轻量、精简，未来失忆接手时由此恢复上下文。*
|
||||
@@ -0,0 +1,65 @@
|
||||
# 寄存条:看板升级已外迁
|
||||
|
||||
> 留在主 project,让未来的 Claude 一眼知道:看板分析升级已经拉出去单独立项了。
|
||||
> 外迁时间:2026-06-12
|
||||
|
||||
---
|
||||
|
||||
## 外迁了什么
|
||||
|
||||
**TPS 看板分析升级**整体作为子项目,搬到独立 Claude project。
|
||||
|
||||
子项目聚焦:三层信息架构、双引擎象限图、AI 打标流水线、编导能力地图、本期诊断小结、看板 UI 设计。
|
||||
|
||||
子项目持有的核心资产:主项目签发的 Brief + 三份续接快照 + ground-truth 基准集 + 23 期文稿等。
|
||||
|
||||
---
|
||||
|
||||
## 主 project 不再讨论的话题
|
||||
|
||||
聊到下面这些词,**先问一句"这是子项目的事还是主 project 的事?"**——是子项目的事,提醒制片人切到子项目 chat。
|
||||
|
||||
关键词:看板升级 / 双引擎象限图 / 题材热度 / 叙事结构(作为字段)/ AI 打标 / Prompt 1/2/3 / ground-truth / episodes 加字段 / 23 期回填 / 能力地图 / 置信度三档 / 本期诊断小结
|
||||
|
||||
---
|
||||
|
||||
## 主 project 仍在管什么
|
||||
|
||||
- Phase 0-3 已落地的主干代码(episodes、editors、收视诊断基础)
|
||||
- backend 全部 schema、API、迁移脚本
|
||||
- 前端全部 React 代码实施
|
||||
- 主干 Bug、性能优化、新需求(看板升级以外的)
|
||||
- Cline 的全部 Plan + Act 操作
|
||||
|
||||
---
|
||||
|
||||
## 接收子项目交付物的接口
|
||||
|
||||
子项目交付物的具体接口约定,见**子项目主 Brief §六**(交付什么)。简要回顾:
|
||||
|
||||
- **Schema 变更**:子项目出字段定义文档 → 主 project Cline 切 Plan + Opus 审 + 制片人批准 Act → `pg_dump` 备份 → 跑迁移
|
||||
- **前端实施**:子项目出设计 token + HTML mock + 视觉规范 → 主 project Cline 落 React
|
||||
- **AI 打标**:沙盒 `ai-labeling/` 由子项目自治,主 project 不碰
|
||||
- **回填**:子项目出脚本设计 → 主 project 跑 + 制片人审 staging
|
||||
|
||||
**纪律**:
|
||||
- 只接稳定版,草稿不实施
|
||||
- 实施前 `pg_dump` 备份
|
||||
- 实施完成后回访子项目登记状态
|
||||
|
||||
---
|
||||
|
||||
## 开局口径
|
||||
|
||||
进主 project 新 chat:
|
||||
> "续接 TPS 主项目。读 `寄存条_看板升级已外迁.md`。当前要做 [具体任务]。"
|
||||
|
||||
---
|
||||
|
||||
## 万一子项目记录丢了
|
||||
|
||||
降级方案:
|
||||
1. 主 project 这边还保留资产副本(xlsx + 11 份 docx + 部分 UI 参考图)
|
||||
2. 决策史在 Gitea 有 git 历史(关键 commit `38f3728` 等)
|
||||
3. 制片人本地应有副本
|
||||
4. **主 project 这边不要凭记忆重建子项目内容**——找制片人或重建子项目
|
||||
@@ -0,0 +1,50 @@
|
||||
# 看板升级子项目 — 入口
|
||||
|
||||
> 这是 TPS 主 project 拆出来的子项目,聚焦"看板分析升级"。
|
||||
> 立项时间:2026-06-12
|
||||
> 顾问:Claude Opus 4.7 ｜ 制片人:刘通
|
||||
|
||||
---
|
||||
|
||||
## 开局必读(顺序)
|
||||
|
||||
1. `看板升级子项目_Brief.md` — 主项目签发的"交接宪法"(红线、技术栈、出入口接口)。**不在子项目内修改。**
|
||||
2. `续接快照_看板分析升级_设计讨论_v4.md` — 最新决策史(往前可回溯 v3 / v1)
|
||||
3. 上面两份读完,就有完整上下文了
|
||||
|
||||
---
|
||||
|
||||
## 已有资产
|
||||
|
||||
**决策史**:
|
||||
- 续接快照 v1 / v3 / v4 — 整个看板升级讨论的完整记录
|
||||
|
||||
**数据基础**:
|
||||
- `军事科技栏目收视诊断分析_v2.xlsx` — 双引擎模型源数据(主项目也留一份)
|
||||
- 11 份节目文稿 `.docx` — AI 打标基准集源稿(主项目也留一份)
|
||||
|
||||
**UI 参考**:
|
||||
- `dashiboard首页原版.jpg` — 首屏改造起点(主项目也留一份)
|
||||
- `dashiboard首页_拷贝.jpg` — 制片人批注稿
|
||||
- `色调字体倒角.webp` — 整体视觉资产(主项目也留一份)
|
||||
- `简洁风_清晰.jpg` — DataEase 风格参考
|
||||
|
||||
**协作纪律**:
|
||||
- `Claude协作原则.md` — 与主项目同源,沿用
|
||||
|
||||
**沙盒**:
|
||||
- `ai-labeling/` 工作区(物理上仍在 `E:\tps-dashboard\ai-labeling\`)
|
||||
- Prompt 2 v0.2 已锁,MiniMax M3 选定,ground-truth v0.2.1 锁定
|
||||
|
||||
---
|
||||
|
||||
## 子项目自由度
|
||||
|
||||
读完 Brief 你会注意到 §八"未决项"——那是子项目可自由发挥的部分。
|
||||
Brief 里没明确禁止、没在续接快照里拍板的事,都是讨论空间。
|
||||
|
||||
---
|
||||
|
||||
## 新 chat 开局第一句
|
||||
|
||||
> "续接 TPS 看板分析升级子项目。先读主 Brief 和续接快照 v4。本 project 是设计+PRD 产出,不动主 project 的 backend 代码。当前推进到 [具体任务]。"
|
||||
@@ -0,0 +1,143 @@
|
||||
# 看板升级子项目 Brief
|
||||
|
||||
> 主项目 → 子项目的"交接宪法":红线、技术栈、出入口接口
|
||||
> 起草日期:2026-06-12
|
||||
> 状态:子项目立项时由主项目顾问(Opus)签发,子项目内部不修改
|
||||
|
||||
---
|
||||
|
||||
## 一、为什么做
|
||||
|
||||
**痛点**:制片人和编导团队拿到的"收视成绩单"只能看到结果(均值、走势、单期高低),
|
||||
看不到结构性原因。每次复盘要靠人工拼诊断(21 期那次花了若干周),无法持续。
|
||||
|
||||
**升级目标**:把仪表盘从"看成绩"升级为"能分析"——
|
||||
让"双引擎模型(题材热度 × 叙事结构)"这个一次性人工产出的分析框架,
|
||||
变成一台**持续运转的诊断仪**。
|
||||
|
||||
---
|
||||
|
||||
## 二、做什么(功能边界,只列名)
|
||||
|
||||
| 模块 | 简述 |
|
||||
|---|---|
|
||||
| 三层信息架构 | 纯算 / 打标后 / AI 起草,分层呈现 |
|
||||
| 双引擎象限图 | 招牌视觉,题材热度 × 叙事结构 |
|
||||
| AI 打标流水线 | Prompt 1/2/3 + MiniMax M3 + ground-truth |
|
||||
| 编导能力地图 | 反排名,正反馈 |
|
||||
| 本期诊断小结 | AI 起草 + 制片人审改后发布 |
|
||||
| 时间选择器 | 实时脉搏 vs 周期复盘,边界永远可调 |
|
||||
|
||||
**具体怎么做,子项目内部讨论,本 Brief 不预设方案。**
|
||||
|
||||
---
|
||||
|
||||
## 三、怎么用(目标流程)
|
||||
|
||||
- **每周**:制片人看"实时脉搏"——核心指标卡 + 近 9 期走势
|
||||
- **每月**:制片人看"题材分析"——题材汇总,关注异动
|
||||
- **每季**:制片人看"双引擎象限图 + 本期诊断小结"——周期复盘
|
||||
- **新节目入库**:AI 打标草稿 → staging 表 → 制片人审 → 落库
|
||||
- **编导维度**:制片人查能力地图,把强项做成全组可复用模板
|
||||
- **离职编导**:历史保留,面向当下视图可筛掉
|
||||
|
||||
---
|
||||
|
||||
## 四、不做什么(红线)
|
||||
|
||||
子项目设计任何方案,**绝不**触碰以下:
|
||||
|
||||
- ❌ **不做深色大屏**(留给 2.0 数据大屏蓝本)
|
||||
- ❌ **不做编导排名**(团队视角走能力地图)
|
||||
- ❌ **AI 不自动盖章下结论**(永远是"AI 出草稿,人拍板")
|
||||
- ❌ **不引入新图表库**(继续 ECharts / @ant-design/charts)
|
||||
- ❌ **不引入主 project 没有的技术栈**
|
||||
- ❌ **不动主 project 已有的 schema**(改字段必须走 §六交付协议)
|
||||
- ❌ **不做"未审字段直接上看板"**(置信度三档必须可辨)
|
||||
- ❌ **不写 / 不改 AI 打标 Prompt 由 Cline 完成**(Cline 是执行者不是作者)
|
||||
|
||||
---
|
||||
|
||||
## 五、技术栈约束(继承主 project)
|
||||
|
||||
子项目所有设计必须能落在以下栈上,不引入新依赖:
|
||||
|
||||
- **前端**:React 18 + Vite + AntD 5 + Zustand + ECharts / @ant-design/charts
|
||||
- **后端**:FastAPI + SQLModel + PG 16 + pgvector
|
||||
- **配色**:米色底 `#fbf9f1` + 深绿主色 `#6b8e6b`
|
||||
- **三色色板**:红 `#c0584f` / 蓝 `#5b8db8` / 绿 `#7aa874`
|
||||
- **基准线**:基础线 0.6448 / 摸高线 0.8989(2026)
|
||||
- **AI 打标**:沙盒 `ai-labeling/`,生产模型 MiniMax M3,openai==1.55.0 锁版本
|
||||
- **部署**:腾讯云 4 核 8G(性能上限,凡是吃不动的方案直接否决)
|
||||
|
||||
---
|
||||
|
||||
## 六、交付什么(出口接口)
|
||||
|
||||
子项目产出最终要回到主 project 实施,**交付物必须满足以下接口**:
|
||||
|
||||
### 6.1 Schema 变更类
|
||||
- 子项目出:**字段定义文档**(命名 / 类型 / 枚举 / nullable / 约束 / 回滚方案)
|
||||
- 主 project 实施:**Cline 切 Plan → Opus 审 → 制片人批准 Act → `pg_dump` 备份 → 跑迁移**
|
||||
- 不接受:子项目自己改主 project schema 或 `backend/` 任何代码
|
||||
|
||||
### 6.2 前端实施类
|
||||
- 子项目出:**设计 token JSON + HTML mock + 视觉规范文档**
|
||||
- 主 project 实施:**Cline 按设计稿落 React 组件**
|
||||
- 不接受:子项目自己写主 project 的 React 代码
|
||||
|
||||
### 6.3 AI 打标类
|
||||
- 子项目在 `ai-labeling/` 沙盒自治,**沙盒内 Cline 可直接 Act**
|
||||
- 子项目出:**Prompt 文件 + ground-truth.json + 模型选型结论**
|
||||
- 主 project 实施:**episodes_staging 表 schema 落库 + 审稿 UI 落地**
|
||||
|
||||
### 6.4 回填类
|
||||
- 子项目出:**回填脚本设计文档 + 23 期回填策略**
|
||||
- 主 project 实施:**Cline 跑脚本 + 制片人审 staging**
|
||||
|
||||
### 6.5 通用约束
|
||||
- 子项目**不主动 push** 文件到主 project,**所有交付物由制片人决定时机**
|
||||
- 主 project 只接**稳定版**,子项目内部草稿不交付
|
||||
|
||||
---
|
||||
|
||||
## 七、入口接口(子项目要知道的主 project 现状)
|
||||
|
||||
- **Phase 0-3 已落地**:episodes / editors / 收视诊断基础数据,23 期 2026 年数据已入库
|
||||
- **现有视觉语言**:米色 + 深绿,卡片圆角 12px,AntD 5 默认行高
|
||||
- **现有 backlog**:主 project 这边的 backlog 已标注"看板升级条目已外迁"
|
||||
- **现有沙盒**:`ai-labeling/` 工作区已搭建,Prompt 2 v0.2 已锁,MiniMax M3 已选定
|
||||
- **现有 git**:Gitea 落库,关键 commit `38f3728`
|
||||
|
||||
---
|
||||
|
||||
## 八、未决项(归子项目自己拍板)
|
||||
|
||||
以下不在本 Brief 内预设,**由子项目和制片人讨论决定**:
|
||||
|
||||
- 横轴量化方法的具体公式
|
||||
- AI 打标 Prompt 1 / Prompt 3 的具体写法
|
||||
- 看板各屏幕的具体布局和交互
|
||||
- 双引擎象限图的具体视觉细节
|
||||
- 能力地图的具体可视化方案
|
||||
- episodes 新字段的最终命名 / 类型 / 是否多对多关联表
|
||||
- 置信度是单字段还是分字段
|
||||
- 时间窗口取多大 / 小样本怎么兜底等具体口径
|
||||
|
||||
---
|
||||
|
||||
## 九、决策史指向(不重复内容)
|
||||
|
||||
子项目讨论前应该读的:
|
||||
- `续接快照_看板分析升级_设计讨论.md`(v1,2026-06-09)
|
||||
- `续接快照_看板分析升级_设计讨论_v3.md`(v3,2026-06-11 上午)
|
||||
- `续接快照_看板分析升级_设计讨论_v4.md`(v4,2026-06-11 晚)
|
||||
- `军事科技栏目收视诊断分析_v2.xlsx`(双引擎模型源数据)
|
||||
|
||||
---
|
||||
|
||||
## 十、本 Brief 自身的修订规则
|
||||
|
||||
- 本 Brief 不在子项目内修改
|
||||
- 红线 / 技术栈如有变更,**主 project 这边发新版**,通过寄存条同步
|
||||
- 子项目可在自己的 chat 里讨论"建议主 project 调整某条红线",但调整动作只能在主 project 发生
|
||||
@@ -0,0 +1,95 @@
|
||||
# 迁移清单 — 主 project 操作指南
|
||||
|
||||
> 用途:看板升级子项目立项时,主 project 这边的文件操作清单
|
||||
> 操作完即可丢弃
|
||||
> 制定时间:2026-06-12
|
||||
|
||||
---
|
||||
|
||||
## 资产分两类处理
|
||||
|
||||
### 🔵 子项目独有(主 project 这边删)
|
||||
|
||||
纯决策记录性质,主 project 不再需要:
|
||||
|
||||
1. `续接快照_看板分析升级_设计讨论.md`(v1)
|
||||
2. `续接快照_看板分析升级_设计讨论_v3.md`
|
||||
3. `续接快照_看板分析升级_设计讨论_v4.md`
|
||||
4. `dashiboard首页_拷贝.jpg`(批注稿)
|
||||
5. `简洁风_清晰.jpg`(参考图)
|
||||
|
||||
### 🟢 两边都留(各保留一份)
|
||||
|
||||
资产类性质,主 project 将来也可能用得到:
|
||||
|
||||
1. `军事科技栏目收视诊断分析_v2.xlsx` — 数据基础
|
||||
2. 11 份节目文稿 `.docx`(硅基大脑、潜艇仿生 等) — 节目原始资料
|
||||
3. `dashiboard首页原版.jpg` — 主 project 实施 React 时要看
|
||||
4. `色调字体倒角.webp` — 整体视觉资产
|
||||
|
||||
---
|
||||
|
||||
## 主 project 这边的其他动作
|
||||
|
||||
### 新增
|
||||
|
||||
- 上传 `寄存条_看板升级已外迁.md`
|
||||
|
||||
### 更新
|
||||
|
||||
- `backlog_md_TPS_工作台待办池_不丢视野_非排期_.md` 顶部加一段:
|
||||
|
||||
```markdown
|
||||
> ⚠️ 更新(2026-06-12):看板分析升级相关待办(原 F1-F8)已整体迁移到
|
||||
> **TPS 看板分析升级子项目**。主 project 这边不再维护这部分待办。
|
||||
> 子项目状态见 `寄存条_看板升级已外迁.md`。
|
||||
```
|
||||
|
||||
### 保留(不动)
|
||||
|
||||
主干文档(README、Claude协作原则、phase 日志、doco 系列、git_workflow、_clinerules、_gitignore、001_init.sql、dev_plan、project_plan、Phase 3 续接快照系列)全部保留。
|
||||
|
||||
---
|
||||
|
||||
## 操作步骤
|
||||
|
||||
**Step 1 ─ 建子项目**
|
||||
1. 新建 Claude project,名为 `TPS看板分析升级`
|
||||
2. 上传 4 份新文件:`INDEX.md` + `看板升级子项目_Brief.md` + 拷贝一份 `Claude协作原则.md`
|
||||
3. 上传 🔵 5 份子项目独有的文件
|
||||
4. 上传 🟢 14 份资产文件(主 project 也保留同名副本)
|
||||
|
||||
**Step 2 ─ 清主 project + 寄存**
|
||||
5. 删除 🔵 5 份文件
|
||||
6. 上传 `寄存条_看板升级已外迁.md`
|
||||
7. 更新 `backlog` 顶部标注
|
||||
|
||||
**Step 3 ─ 验证**
|
||||
8. 进主 project 新 chat:"读寄存条" → 看 Claude 是否懂"这部分外迁了,不在我这里讨论"
|
||||
9. 进子项目新 chat:按 INDEX 开局口径 → 看 Claude 是否能正确进入顾问角色
|
||||
|
||||
---
|
||||
|
||||
## 操作后的拓扑
|
||||
|
||||
```
|
||||
TPS 主 project TPS 看板升级子项目
|
||||
───────────────────── ─────────────────────
|
||||
├─ 主干文档(README/协作原则/phase 等) ├─ INDEX.md ★
|
||||
├─ doco/migration/git/init/dev/plan ├─ 看板升级子项目_Brief.md ★
|
||||
├─ Phase 3 续接快照系列 ├─ Claude协作原则.md(拷贝)
|
||||
├─ backlog(顶部加标注) ├─ 续接快照 v1/v3/v4
|
||||
├─ 寄存条_看板升级已外迁.md ★ ├─ xlsx + 11 份 docx(副本)
|
||||
├─ xlsx + 11 份 docx(副本) ├─ dashboard 首页原版(副本)
|
||||
├─ dashboard 首页原版(副本) ├─ 色调字体倒角(副本)
|
||||
└─ 色调字体倒角(副本) ├─ dashboard 首页_拷贝.jpg
|
||||
└─ 简洁风_清晰.jpg
|
||||
```
|
||||
|
||||
★ = 新增
|
||||
|
||||
---
|
||||
|
||||
## 拿不准的就先不动
|
||||
|
||||
任何一份文件去留拿不准的,**先保留**。文件保留比误删容易处理。
|
||||
@@ -0,0 +1,151 @@
|
||||
# F3 横轴量化方法 PRD v1.0
|
||||
|
||||
> 子项目交付物 · 看板分析升级
|
||||
> 状态:**v1.0 已锁**(2026-06-12 通哥审过 §2/§3/§4 决策)
|
||||
> 起草时间:2026-06-12
|
||||
> 顾问:Claude Opus 4.7 ｜ 制片人:刘通
|
||||
> 类型:薄 PRD(只解 v2 之后留下的开放点,已锁部分仅引用)
|
||||
|
||||
---
|
||||
|
||||
## §1 引用已锁结论(不重述)
|
||||
|
||||
本 PRD 是对已有结论的**补丁/收敛**,不替换。已锁部分直接参见以下来源:
|
||||
|
||||
| 来源 | 已锁内容 |
|
||||
|---|---|
|
||||
| 续接快照 v2 §3 | 横轴公式 `X = 该题材在分析窗口内的均值份额 − 栏目均值份额`,零点 = 栏目均值,单位 = 收视份额绝对差 |
|
||||
| 续接快照 v2 §4 | 双引擎象限图视觉规格:气泡大小 = 收视份额、气泡颜色 = 收视判定三色、气泡边框 = 开篇钩子三档、重叠用 jitter 解 |
|
||||
| 主 project Claude 示意图(2026-06-10) | 23 期实际数据 + 模拟纵轴/钩子已可视化,制片人认可"不挤、不堆叠" |
|
||||
| 续接快照 v3 §1.1 / v4 §3 | 纵轴从 3 档收为 2 档(主线演进 / 并列结构),Prompt 2 v0.2 + ground-truth v0.2.1 M3 100% 锁定 |
|
||||
| 续接快照 v2 §2 字段二 | `equipment_domain` 多选 9 类:陆战装备 / 海军舰船 / 航空航天 / 导弹与反导 / 信息化 / 后勤保障 / 轻武器 / 跨域 / 其他 |
|
||||
|
||||
本 PRD 解决 v2 之后留下的三个开放点:**多标签横轴取值规则、小样本兜底、视觉规格刷新到 2 档纵轴**。
|
||||
|
||||
---
|
||||
|
||||
## §2 决策一:多标签 → 横轴单点取值规则(Path A 全额法)
|
||||
|
||||
`equipment_domain` 字段为多选(至少 1 项),但横轴一期只能落一个点。
|
||||
|
||||
### 2.1 规则
|
||||
|
||||
**每个 `equipment_domain` 标签独立维护自己的累计均值;一期节目标了 N 个标签,就把该期完整 share 直接记进**每一个**沾上的标签的均值池(全额、不瓜分、不加权)。**
|
||||
|
||||
### 2.2 数学定义
|
||||
|
||||
```
|
||||
对每个 equipment_domain 标签 i:
|
||||
base_i = 所有沾标签 i 的节目的 share 的算术平均
|
||||
= Σ(share_j, ∀ j 沾标签 i) / count(j 沾标签 i)
|
||||
|
||||
栏目均值:
|
||||
base_全栏目 = 所有节目的 share 的算术平均(单期单算)
|
||||
|
||||
每期 ep 的横轴位置:
|
||||
X(ep) = mean(base_i, ∀ i ∈ ep.equipment_domain) − base_全栏目
|
||||
```
|
||||
|
||||
### 2.3 示例
|
||||
|
||||
设当前 `海军舰船` 桶均值 = 0.69,`跨域` 桶均值 = 0.79,栏目均值 = 0.72。
|
||||
|
||||
- 一期标 `海军舰船 + 跨域`,share = 0.71
|
||||
- 该期 X 位置 = (0.69 + 0.79) / 2 − 0.72 = **+0.02**(略偏热)
|
||||
- 这期 share = 0.71 同时记入 `海军舰船` 均值池(下次 base 重算用)和 `跨域` 均值池
|
||||
|
||||
**两点说明**:
|
||||
|
||||
1. **均值更新方向自洽**:0.71 < 0.72(栏目均值),也低于"跨域 0.79"。记入两个桶后,两个桶的均值都会被这期略往下拉,符合"低于均值的样本拉低均值"的直觉。
|
||||
2. **不存在 ×N 放大**:之前讨论过的"按基值加权 × 标签数"方案因方向 bug(低于均值的样本可能反向拉高均值)被否决,详见 2026-06-12 续接讨论。
|
||||
|
||||
### 2.4 适用范围
|
||||
|
||||
本规则**仅用于横轴 X 值计算**。其他统计(能力地图、编导对比、scene_tags 分布等)的多标签处理另议。
|
||||
|
||||
---
|
||||
|
||||
## §3 决策二:小样本兜底规则
|
||||
|
||||
某 `equipment_domain` 桶若在当前分析窗口内样本量 n 较小,均值统计意义弱。视觉上需可辨。
|
||||
|
||||
### 3.1 兜底分档
|
||||
|
||||
| 桶样本量 | 视觉处理 |
|
||||
|---|---|
|
||||
| **n ≥ 3** | 正常显示,base 值直接入横轴坐标 |
|
||||
| **n = 1 或 2** | 桶名右侧显示 `(n=X)` 灰色小字;桶内气泡描边改为虚线浅灰;tooltip 警示"样本不足,横轴位置参考价值有限" |
|
||||
| **n = 0** | 桶不出现在横轴坐标系上(如 `陆战装备` 在 21 期场景下属此类,预留枚举值但暂不画) |
|
||||
|
||||
### 3.2 阈值出处
|
||||
|
||||
n = 3 阈值的取法:统计上方差估计起码需 2 自由度,记录方便取 3。**这是初值,后续看实际分布可调**。
|
||||
|
||||
### 3.3 当前 21 期场景的小样本桶预测
|
||||
|
||||
按 v2 §2 九类 + 我对 21 期的初步映射(见配套回填提案表):
|
||||
|
||||
- `导弹与反导` n=1(ep15 一期),**小样本桶**
|
||||
- `信息化` n=1 或 2(取决于 ep03 是否归这里 vs 跨域),**可能小样本**
|
||||
- `陆战装备` n=0,**不出现在坐标系**
|
||||
- `后勤保障` n=0,**不出现在坐标系**
|
||||
- `其他` n=0,**不出现在坐标系**
|
||||
|
||||
其余 4 个桶(`海军舰船` / `航空航天` / `轻武器` / `跨域`)预计 n ≥ 3,正常显示。
|
||||
|
||||
---
|
||||
|
||||
## §4 决策三:视觉规格刷新(纵轴 3 档 → 2 档)
|
||||
|
||||
v2 §4 视觉规格除以下差异外,**全部沿用**:
|
||||
|
||||
| 元素 | v2 §4(3 档,旧) | 本版(2 档,新) |
|
||||
|---|---|---|
|
||||
| 纵轴档位 | 强主线悬念 / 主线演进 / 并列结构 | **主线演进 / 并列结构**(v3 §1.1 收为 2 档) |
|
||||
| 纵轴坐标 | 三个水平基线 | 两个水平基线 |
|
||||
| 同档内 jitter | ±0.3 | ±0.4(档少了,jitter 可适当加大避免聚拢) |
|
||||
| 中线视觉 | 两条次级分隔 | **一条主分隔线显著加粗**,强调"主线 vs 并列"对照 |
|
||||
| 上下区视觉重点 | 三层等权 | **两区中性等权**——纵轴不暗示偏好方向,呈现客观对照(2026-06-12 通哥拍板) |
|
||||
|
||||
横轴部分全部沿用 v2 §4,无变化。
|
||||
|
||||
---
|
||||
|
||||
## §5 配套交付清单(子项目本轮其余产出)
|
||||
|
||||
- [✅ 本文件] `F3_横轴量化方法_PRD_v1.0草稿.md`
|
||||
- [⏳ 下批] `双引擎象限图_HTML_mock_v1.0.html`——基于本 PRD 的纵轴 2 档版可视化,可浏览器直开看交互
|
||||
- [⏳ 下批] `F3_算法验证脚本.py`——在子项目沙盒里跑通完整计算流程,输入 23 期 equipment_domain 多选 + share,输出各桶 base + 23 期 X 值表 + 数据校验报告
|
||||
- [⏳ 下批] `equipment_domain_字段定义文档.md`——按 Brief §6.1 格式,主 project Cline 拿去做 schema 迁移
|
||||
- [⏳ 下批] `23期_equipment_domain_回填提案表.md`——给制片人审,或转 Prompt 1a 的 ground-truth 输入
|
||||
|
||||
---
|
||||
|
||||
## §6 落地依赖(主 project Cline 工作清单)
|
||||
|
||||
子项目这边的 5 份交付物全部锁定后,主 project Cline 可接手以下工作(均需切 Plan + Opus 审):
|
||||
|
||||
1. **Schema 迁移**:`backend/sql/00X_add_equipment_domain.sql`(基于字段定义文档)
|
||||
2. **23 期回填**:Prompt 1a 跑批结果落库 + 制片人审过的 8 期标题推断低置信度样本
|
||||
3. **后端 API endpoint**:横轴聚合数据接口 `GET /api/v1/episodes/quadrant-data`(或类似)
|
||||
4. **前端 React/ECharts 组件**:基于本 PRD 的 HTML mock 1:1 翻译
|
||||
|
||||
---
|
||||
|
||||
## §7 后续可能调整项(本版不解,留入 backlog)
|
||||
|
||||
- **时间窗口选择**:滚动窗口 vs 全部历史 vs 季度,默认设"全部历史",后续 UI 加切换器
|
||||
- **n ≥ 3 阈值的实际验证**:用 23 期 + 新片陆续入库 6 个月后看分布,必要时调阈值
|
||||
- **多标签规则是否升级**:本版用全额路 A,运行半年若发现不妥(如某桶均值长期被高频跨域期数刷高)再议升级到带权或 1/N 守恒版
|
||||
- **n=1/2 视觉表达细节**:虚线浅灰 vs 描边淡化 vs 加图例,等 HTML mock 出来后定
|
||||
|
||||
---
|
||||
|
||||
## §8 修订规则
|
||||
|
||||
本 PRD 锁定 v1.0 后:
|
||||
|
||||
- v1.x 微调(视觉细节、阈值小动)在本子项目内修改
|
||||
- v2.0 重大变更(规则换路 B、取消纵轴 2 档等)需主 project 同步审,通过新一版续接快照固化
|
||||
|
||||
修订必留 changelog,谁、何时、改了什么、为什么改。
|
||||
@@ -0,0 +1,151 @@
|
||||
# F3 横轴量化方法 PRD v1.0(草稿)
|
||||
|
||||
> 子项目交付物 · 看板分析升级
|
||||
> 状态:**草稿**,等制片人审 + 锁定后转正式 v1.0
|
||||
> 起草时间:2026-06-12
|
||||
> 顾问:Claude Opus 4.7 ｜ 制片人:刘通
|
||||
> 类型:薄 PRD(只解 v2 之后留下的开放点,已锁部分仅引用)
|
||||
|
||||
---
|
||||
|
||||
## §1 引用已锁结论(不重述)
|
||||
|
||||
本 PRD 是对已有结论的**补丁/收敛**,不替换。已锁部分直接参见以下来源:
|
||||
|
||||
| 来源 | 已锁内容 |
|
||||
|---|---|
|
||||
| 续接快照 v2 §3 | 横轴公式 `X = 该题材在分析窗口内的均值份额 − 栏目均值份额`,零点 = 栏目均值,单位 = 收视份额绝对差 |
|
||||
| 续接快照 v2 §4 | 双引擎象限图视觉规格:气泡大小 = 收视份额、气泡颜色 = 收视判定三色、气泡边框 = 开篇钩子三档、重叠用 jitter 解 |
|
||||
| 主 project Claude 示意图(2026-06-10) | 23 期实际数据 + 模拟纵轴/钩子已可视化,制片人认可"不挤、不堆叠" |
|
||||
| 续接快照 v3 §1.1 / v4 §3 | 纵轴从 3 档收为 2 档(主线演进 / 并列结构),Prompt 2 v0.2 + ground-truth v0.2.1 M3 100% 锁定 |
|
||||
| 续接快照 v2 §2 字段二 | `equipment_domain` 多选 9 类:陆战装备 / 海军舰船 / 航空航天 / 导弹与反导 / 信息化 / 后勤保障 / 轻武器 / 跨域 / 其他 |
|
||||
|
||||
本 PRD 解决 v2 之后留下的三个开放点:**多标签横轴取值规则、小样本兜底、视觉规格刷新到 2 档纵轴**。
|
||||
|
||||
---
|
||||
|
||||
## §2 决策一:多标签 → 横轴单点取值规则(Path A 全额法)
|
||||
|
||||
`equipment_domain` 字段为多选(至少 1 项),但横轴一期只能落一个点。
|
||||
|
||||
### 2.1 规则
|
||||
|
||||
**每个 `equipment_domain` 标签独立维护自己的累计均值;一期节目标了 N 个标签,就把该期完整 share 直接记进**每一个**沾上的标签的均值池(全额、不瓜分、不加权)。**
|
||||
|
||||
### 2.2 数学定义
|
||||
|
||||
```
|
||||
对每个 equipment_domain 标签 i:
|
||||
base_i = 所有沾标签 i 的节目的 share 的算术平均
|
||||
= Σ(share_j, ∀ j 沾标签 i) / count(j 沾标签 i)
|
||||
|
||||
栏目均值:
|
||||
base_全栏目 = 所有节目的 share 的算术平均(单期单算)
|
||||
|
||||
每期 ep 的横轴位置:
|
||||
X(ep) = mean(base_i, ∀ i ∈ ep.equipment_domain) − base_全栏目
|
||||
```
|
||||
|
||||
### 2.3 示例
|
||||
|
||||
设当前 `海军舰船` 桶均值 = 0.69,`跨域` 桶均值 = 0.79,栏目均值 = 0.72。
|
||||
|
||||
- 一期标 `海军舰船 + 跨域`,share = 0.71
|
||||
- 该期 X 位置 = (0.69 + 0.79) / 2 − 0.72 = **+0.02**(略偏热)
|
||||
- 这期 share = 0.71 同时记入 `海军舰船` 均值池(下次 base 重算用)和 `跨域` 均值池
|
||||
|
||||
**两点说明**:
|
||||
|
||||
1. **均值更新方向自洽**:0.71 < 0.72(栏目均值),也低于"跨域 0.79"。记入两个桶后,两个桶的均值都会被这期略往下拉,符合"低于均值的样本拉低均值"的直觉。
|
||||
2. **不存在 ×N 放大**:之前讨论过的"按基值加权 × 标签数"方案因方向 bug(低于均值的样本可能反向拉高均值)被否决,详见 2026-06-12 续接讨论。
|
||||
|
||||
### 2.4 适用范围
|
||||
|
||||
本规则**仅用于横轴 X 值计算**。其他统计(能力地图、编导对比、scene_tags 分布等)的多标签处理另议。
|
||||
|
||||
---
|
||||
|
||||
## §3 决策二:小样本兜底规则
|
||||
|
||||
某 `equipment_domain` 桶若在当前分析窗口内样本量 n 较小,均值统计意义弱。视觉上需可辨。
|
||||
|
||||
### 3.1 兜底分档
|
||||
|
||||
| 桶样本量 | 视觉处理 |
|
||||
|---|---|
|
||||
| **n ≥ 3** | 正常显示,base 值直接入横轴坐标 |
|
||||
| **n = 1 或 2** | 桶名右侧显示 `(n=X)` 灰色小字;桶内气泡描边改为虚线浅灰;tooltip 警示"样本不足,横轴位置参考价值有限" |
|
||||
| **n = 0** | 桶不出现在横轴坐标系上(如 `陆战装备` 在 21 期场景下属此类,预留枚举值但暂不画) |
|
||||
|
||||
### 3.2 阈值出处
|
||||
|
||||
n = 3 阈值的取法:统计上方差估计起码需 2 自由度,记录方便取 3。**这是初值,后续看实际分布可调**。
|
||||
|
||||
### 3.3 当前 21 期场景的小样本桶预测
|
||||
|
||||
按 v2 §2 九类 + 我对 21 期的初步映射(见配套回填提案表):
|
||||
|
||||
- `导弹与反导` n=1(ep15 一期),**小样本桶**
|
||||
- `信息化` n=1 或 2(取决于 ep03 是否归这里 vs 跨域),**可能小样本**
|
||||
- `陆战装备` n=0,**不出现在坐标系**
|
||||
- `后勤保障` n=0,**不出现在坐标系**
|
||||
- `其他` n=0,**不出现在坐标系**
|
||||
|
||||
其余 4 个桶(`海军舰船` / `航空航天` / `轻武器` / `跨域`)预计 n ≥ 3,正常显示。
|
||||
|
||||
---
|
||||
|
||||
## §4 决策三:视觉规格刷新(纵轴 3 档 → 2 档)
|
||||
|
||||
v2 §4 视觉规格除以下差异外,**全部沿用**:
|
||||
|
||||
| 元素 | v2 §4(3 档,旧) | 本版(2 档,新) |
|
||||
|---|---|---|
|
||||
| 纵轴档位 | 强主线悬念 / 主线演进 / 并列结构 | **主线演进 / 并列结构**(v3 §1.1 收为 2 档) |
|
||||
| 纵轴坐标 | 三个水平基线 | 两个水平基线 |
|
||||
| 同档内 jitter | ±0.3 | ±0.4(档少了,jitter 可适当加大避免聚拢) |
|
||||
| 中线视觉 | 两条次级分隔 | **一条主分隔线显著加粗**,强调"主线 vs 并列"对照 |
|
||||
| 上下区视觉重点 | 三层等权 | 上区(主线演进)略亮、下区(并列结构)略灰,**视觉上暗示偏好方向**(可选,等通哥决) |
|
||||
|
||||
横轴部分全部沿用 v2 §4,无变化。
|
||||
|
||||
---
|
||||
|
||||
## §5 配套交付清单(子项目本轮其余产出)
|
||||
|
||||
- [✅ 本文件] `F3_横轴量化方法_PRD_v1.0草稿.md`
|
||||
- [⏳ 下批] `双引擎象限图_HTML_mock_v1.0.html`——基于本 PRD 的纵轴 2 档版可视化,可浏览器直开看交互
|
||||
- [⏳ 下批] `F3_算法验证脚本.py`——在子项目沙盒里跑通完整计算流程,输入 23 期 equipment_domain 多选 + share,输出各桶 base + 23 期 X 值表 + 数据校验报告
|
||||
- [⏳ 下批] `equipment_domain_字段定义文档.md`——按 Brief §6.1 格式,主 project Cline 拿去做 schema 迁移
|
||||
- [⏳ 下批] `23期_equipment_domain_回填提案表.md`——给制片人审,或转 Prompt 1a 的 ground-truth 输入
|
||||
|
||||
---
|
||||
|
||||
## §6 落地依赖(主 project Cline 工作清单)
|
||||
|
||||
子项目这边的 5 份交付物全部锁定后,主 project Cline 可接手以下工作(均需切 Plan + Opus 审):
|
||||
|
||||
1. **Schema 迁移**:`backend/sql/00X_add_equipment_domain.sql`(基于字段定义文档)
|
||||
2. **23 期回填**:Prompt 1a 跑批结果落库 + 制片人审过的 8 期标题推断低置信度样本
|
||||
3. **后端 API endpoint**:横轴聚合数据接口 `GET /api/v1/episodes/quadrant-data`(或类似)
|
||||
4. **前端 React/ECharts 组件**:基于本 PRD 的 HTML mock 1:1 翻译
|
||||
|
||||
---
|
||||
|
||||
## §7 后续可能调整项(本版不解,留入 backlog)
|
||||
|
||||
- **时间窗口选择**:滚动窗口 vs 全部历史 vs 季度,默认设"全部历史",后续 UI 加切换器
|
||||
- **n ≥ 3 阈值的实际验证**:用 23 期 + 新片陆续入库 6 个月后看分布,必要时调阈值
|
||||
- **多标签规则是否升级**:本版用全额路 A,运行半年若发现不妥(如某桶均值长期被高频跨域期数刷高)再议升级到带权或 1/N 守恒版
|
||||
- **n=1/2 视觉表达细节**:虚线浅灰 vs 描边淡化 vs 加图例,等 HTML mock 出来后定
|
||||
|
||||
---
|
||||
|
||||
## §8 修订规则
|
||||
|
||||
本 PRD 锁定 v1.0 后:
|
||||
|
||||
- v1.x 微调(视觉细节、阈值小动)在本子项目内修改
|
||||
- v2.0 重大变更(规则换路 B、取消纵轴 2 档等)需主 project 同步审,通过新一版续接快照固化
|
||||
|
||||
修订必留 changelog,谁、何时、改了什么、为什么改。
|
||||
@@ -0,0 +1,224 @@
|
||||
# 跨 project 协作 — 制片人随身提示单
|
||||
|
||||
> 用途：每次想在主项目之外单开子 project 讨论某个模块时，照此提示单走一遍，避免漏环节、避免版本错位、避免子项目设计违反主项目宪法。
|
||||
> 适用：刘通在 Claude 网页版多 project 工作流下的所有"主项目 + 子项目"场景。
|
||||
> 维护人：刘通 + 主 project 顾问 (Claude Opus 4.7)
|
||||
> 首版日期：2026-06-11
|
||||
|
||||
---
|
||||
|
||||
## 〇、什么是 PRD？
|
||||
|
||||
**PRD = Product Requirements Document，产品需求文档**。
|
||||
|
||||
把"我想要个东西"翻译成"工程师可以照着做的具体规格"。一份合格的 PRD 回答：
|
||||
|
||||
- 为什么做：解决谁的什么痛点
|
||||
- 做什么：功能边界、必做/不做
|
||||
- 怎么用：用户走完流程的样子
|
||||
- 数据形态：输入什么、输出什么、字段怎样
|
||||
- 不做什么：明确划红线，防止范围蔓延
|
||||
|
||||
子项目立项时，请那边的 Claude 写一份 PRD 跟主项目对接——这就是工程界的标准操作。
|
||||
|
||||
---
|
||||
|
||||
## 一、先判断：这事适不适合分子 project？
|
||||
|
||||
分之前先想三个问题。三条都满足才适合分：
|
||||
|
||||
1. **这个模块与主项目耦合深不深？** 耦合深的（改用户体系、改权限）就别分，分了沟通成本比省下的还高。
|
||||
2. **这个模块边界清不清？** 输入输出明确的（如分钟收视回放）分得开；边界模糊的（如"优化整体视觉风格"）分不开。
|
||||
3. **工作量够不够大？** 特别小的事（改个字段名）直接在主项目谈完即可。三五次对话讨论不完的，才值得分。
|
||||
|
||||
**反例**：未来想做"AI 自动生成报题单"——这件事跟主项目的 TPS 模块、知识库、收视数据、编导画像全打通，**强耦合**，分子 project 反而割裂上下文。这种就在主项目里推进。
|
||||
|
||||
**正例**：分钟收视回放、本地切图工具、外拍资源管理子模块——边界清晰，可独立设计。
|
||||
|
||||
---
|
||||
|
||||
## 二、流程（四步）
|
||||
|
||||
### 步骤 1：在主项目立"项"——先打招呼
|
||||
|
||||
子项目开干**之前**，先在主项目 chat 里跟 Claude 顾问说一声：
|
||||
|
||||
> "我要开一个子 project 讨论 X 模块，目标是 Y。"
|
||||
|
||||
主项目 Claude 会做两件事：
|
||||
|
||||
- 检查 X 是否真的适合分出去（参照第一节三问）
|
||||
- 把主项目跟 X 相关的红线、技术栈、宪法摘出来给你
|
||||
|
||||
**实操**：把这些"开局材料"打包好，作为子项目的 files 上传过去（至少包括 `.clinerules`、`project_plan.md`、`dev_plan.md`，必要时加相关的 phase log）。子项目 Claude 能读到这些，就能少犯错。
|
||||
|
||||
**这一步不能省**。子项目 Claude 看不到主项目宪法时，会本能地按自己的最佳实践设计——很可能违反主项目某条红线。
|
||||
|
||||
### 步骤 2：在子项目讨论、迭代、收敛
|
||||
|
||||
要点：
|
||||
|
||||
- 子项目**不写主项目的代码**，只输出文档、demo、独立小工具
|
||||
- 子项目**不改主项目的 schema**，所有涉及主项目数据库结构的提议，回主项目让 Claude 顾问审
|
||||
- 子项目**遇到吃不准的事，回主项目问**——以提问列表的形式（参考秒级 chat 那份 PRD 第八节的 6 问）
|
||||
|
||||
### 步骤 3：子项目凝结成"交付包"
|
||||
|
||||
讨论完不能就这么散了。要凝结成可以跨 chat、跨 project、被未来任何人接手的产物。**详见下面第四节五份交付物**。
|
||||
|
||||
**关键认知**：Claude 的 chat 越长，判断力越下降（上下文太满）；而且新 chat 一开就丢了。**md 文档才是真正的产物，chat 只是过程**。讨论一收敛，赶紧让子项目 Claude 凝结成 md。
|
||||
|
||||
### 步骤 4：回主项目整合
|
||||
|
||||
带着交付包回主项目：
|
||||
|
||||
- 主项目 Claude 顾问审一遍交付包，看跟主项目红线有没有冲突
|
||||
- 没冲突 → 在主项目 workspace 里让 Cline 落代码
|
||||
- 有冲突 → 标出冲突点，回子项目修，循环
|
||||
|
||||
**主项目顾问对子项目交付物有否决权**。听起来霸道，但必要——子项目 Claude 不知道主项目全部红线。这一步省不掉。
|
||||
|
||||
---
|
||||
|
||||
## 三、规范：跨 project 文档怎么写
|
||||
|
||||
做对四件事，文档传递不会乱。
|
||||
|
||||
### 规范 1：文件名带版本号
|
||||
|
||||
❌ `分钟收视需求规格.md`
|
||||
✅ `分钟收视需求规格_v1.md`
|
||||
|
||||
下次改了就 v2。**绝对不要原地覆盖**——历史版本要留着，方便回看"我们当时为什么这么定"。
|
||||
|
||||
### 规范 2：文档顶部固定"元信息块"
|
||||
|
||||
每份跨 project 文档第一段必须有：
|
||||
|
||||
```
|
||||
> 版本：v1
|
||||
> 日期：2026-06-11
|
||||
> 作者：[谁写的]
|
||||
> 状态：[草稿 / 待主项目审 / 已采纳 / 已作废]
|
||||
> 上一版：[v0 或"无"]
|
||||
> 主要变化：[v2 才需要写]
|
||||
```
|
||||
|
||||
这块 6 行，写起来不累，但是救命。**没有这个块的跨 project 文档，主项目这边可以拒收**。
|
||||
|
||||
### 规范 3：一份文档只谈一件事
|
||||
|
||||
不要在"分钟收视需求规格"里顺带讨论"用户管理优化"。串了就乱。
|
||||
|
||||
### 规范 4：主项目这边定期回收
|
||||
|
||||
子项目讨论完、文档传过来、整合完成后，把最终采纳的那份 md 放到主项目的 `docs/cross_project/` 目录里。这是主项目的"对外接口档案库"。
|
||||
|
||||
---
|
||||
|
||||
## 四、最终交付物：子项目结束时该产出什么（五份）
|
||||
|
||||
子项目结束时，告诉那边的 Claude：
|
||||
|
||||
> "请把所有讨论凝结成最终交付包，包含以下五份产物。"
|
||||
|
||||
### 产物 1：决策摘要 md
|
||||
|
||||
记录子项目全程的关键决策。每条三句话：
|
||||
|
||||
```
|
||||
决策 X：[一句话决策内容]
|
||||
- 背景：为什么需要这个决策
|
||||
- 拍板理由：选这条不选那条的理由
|
||||
- 拍板人：[制片人 / 主项目顾问 / 子项目 Claude 建议+制片人采纳]
|
||||
```
|
||||
|
||||
不需要"我们讨论了 47 轮"的过程，只要最终结论。10-20 条就把整个子项目的"为什么这么做"讲清。
|
||||
|
||||
### 产物 2：接口约定 md（最技术、最精确）
|
||||
|
||||
把子板块与主项目接驳的所有"接口"白纸黑字写出来。"接口"是广义的，包括：
|
||||
|
||||
- **数据接口**：要新建哪些表、哪些字段、字段类型、约束
|
||||
- **API 接口**：要新增哪些后端 endpoint、URL、方法、请求体、响应体、错误码
|
||||
- **UI 接口**：要在主项目哪个页面挂载这个模块、入口在哪、路由怎么走
|
||||
- **权限接口**：哪些角色可以做什么操作
|
||||
- **存储接口**：文件存到哪个目录、命名规则、URL 怎么拼
|
||||
|
||||
每一条都要具体到"主项目的 Cline 拿着这份就能写代码"的程度。**这份是子项目给主项目的"合同"**。
|
||||
|
||||
### 产物 3：实物交付（独立工具、demo、设计稿）
|
||||
|
||||
子项目特有的产物。视模块性质不同：
|
||||
|
||||
- 分钟收视回放子项目 → 本地切图工具 (py + exe + 使用说明)
|
||||
- 视觉重设计子项目 → 设计稿（Figma / HTML demo）
|
||||
- 数据分析子项目 → 离线分析脚本 + 示例输出
|
||||
|
||||
这些东西**与主项目零耦合**，自己能独立运行。
|
||||
|
||||
### 产物 4：未尽事项 backlog
|
||||
|
||||
诚实写出"子项目讨论中提到但没做的事"。每条三行：
|
||||
|
||||
- 是什么
|
||||
- 为什么没做（暂缓 / P1+ / 等条件成熟）
|
||||
- 触发时机
|
||||
|
||||
放进主项目的 backlog 池子里，未来某个 Phase 收尾时回看，决定哪条捞进下个 Phase。
|
||||
|
||||
### 产物 5：给主项目 Claude 顾问的"接手提示词"
|
||||
|
||||
一两段话，告诉主项目顾问"如果你是接手这件事的 Claude，最重要的三件事是 X、Y、Z"。
|
||||
|
||||
这段相当于一份"防止主项目这边犯傻"的备忘，往往是最有价值的一份。
|
||||
|
||||
---
|
||||
|
||||
## 五、操作过程中的实操注意点
|
||||
|
||||
### 注意 1：永远以 md 为准，不要口头转述
|
||||
|
||||
❌ "那边 Claude 说 XX"，然后跟那边说"主项目这边说 YY"
|
||||
✅ 所有跨项目沟通**以 md 文档为准**
|
||||
|
||||
口头转述会丢细节、会失真，连续转两次就跟最初的意思差很远。
|
||||
|
||||
### 注意 2：chat 是过程，md 是产物
|
||||
|
||||
子项目 chat 长了之后，Claude 自己的判断力会下降（上下文太满），换新 chat 就丢了。**讨论一收敛，赶紧让子项目 Claude 凝结成 md。chat 可以扔，md 不能扔**。
|
||||
|
||||
### 注意 3：主项目顾问的"审查"环节不能省
|
||||
|
||||
子项目 Claude 不知道主项目的全部红线，可能输出违规方案。**拿到子项目交付包后，先来主项目让顾问审一遍，再让 Cline 落实施**。这一步省不掉。
|
||||
|
||||
### 注意 4：每个子项目最长不要超过 3-4 周
|
||||
|
||||
时间越长，跟主项目脱节越严重（主项目可能在这期间已经迭代）。如果一个子项目超过 4 周还没收敛，应该停下来重新评估：是不是分得太大？要不要切成更小的子子项目？
|
||||
|
||||
### 注意 5：交付包归档到主项目仓库
|
||||
|
||||
交付完成后，五份交付物放到主项目的 `docs/cross_project/{子项目名}/` 目录里。**版本号文件全部保留**，未来回看决策史时会用到。
|
||||
|
||||
---
|
||||
|
||||
## 六、一句话总结
|
||||
|
||||
> **子项目专心做事不出主项目；主项目负责审查与整合，不掺合子项目讨论；md 文档是跨项目通信的唯一介质；版本号 + 元信息块永远不省。**
|
||||
|
||||
---
|
||||
|
||||
## 七、复盘提示（每次子项目结束后回看一次）
|
||||
|
||||
子项目结束，回过头来问自己：
|
||||
|
||||
1. 这次分子项目是不是真的提高了效率？还是反而增加了沟通成本？
|
||||
2. 主项目顾问审查时发现了多少个违规设计？说明子项目立项时给的"开局材料"够不够？
|
||||
3. 五份交付物齐了吗？哪份最有用？哪份没人看？
|
||||
4. 这次的经验，要不要加进本提示单的下一版？
|
||||
|
||||
**本提示单本身也按版本管理**。每次复盘有沉淀就出 v2。
|
||||
|
||||
---
|
||||
|
||||
*v1 由主 project 顾问 (Claude Opus 4.7) 协助刘通于 2026-06-11 整理成稿。下次修订时机：第一次完整跑完一个子项目（分钟收视回放）之后。*
|
||||
Reference in New Issue
Block a user