simonkoson
30931d4446
- ground-truth.json 新增 4 分类字段骨架（program_format/equipment_domain/scene_tags/tech_tags） - equipment_domain 类型修正为数组（对齐 v2 快照多选定义） - run_labeling.py 新增 --field 参数，文件名含 field 标记 - summarize.py 新增 --field 参数 + 老文件向后兼容 - CLAUDE.md 补入 v1-v4 快照精华：象限图规格、6 字段枚举、三层交付策略 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
354 lines
23 KiB
Markdown
354 lines
23 KiB
Markdown
# 看板升级子项目协作主控文件 (CLAUDE.md)
|
||
|
||
<!--
|
||
Claude Code 每次开 session 自动读取。
|
||
本文件是看板升级子项目（ai-labeling/）的全局指导文件。
|
||
通用协作原则、主项目技术栈、角色定位、Git 红线等
|
||
已在上一级 tps-dashboard/CLAUDE.md 中覆盖，不重复。
|
||
维护原则：增量更新，不整篇重写。
|
||
-->
|
||
|
||
---
|
||
|
||
## 🔖 状态栏（每次结束 session 前必须更新这三行）
|
||
|
||
- **最后更新**：Claude Opus（顾问）｜ 2026-06-24
|
||
- **当前状态一句话**：全貌已对齐——看板升级 = 数据沉淀 + AI 打标 + 分析引擎 + 诊断报告生成。Prompt 2（叙事结构）已锁定，生产模型 mimo-v2.5-pro。下一步写 Prompt 1 + Prompt 3，同时启动分析引擎架构设计。
|
||
- **下一个动手的人从这里开始**：见下方「⏩ 交接备注」
|
||
|
||
---
|
||
|
||
## 🤖 子项目专属工作约定（READ FIRST）
|
||
|
||
- **先读上一级 `tps-dashboard/CLAUDE.md`**，那里有通用协作原则和主项目全局信息。本文件只补看板升级自己的事。
|
||
- **沙盒自治**：`ai-labeling/` 内改动允许 Cline 直接 Act（改坏重跑就是）。但 `backend/` 任何改动必须切 Plan + Opus 审——这是宪法红线。
|
||
- **Prompt 内容不让 Cline 创作**——Cline 是执行者不是作者。Prompt 由 Opus/Claude Code 写，Cline 只负责落文件。
|
||
- **改 ground-truth 必须留 changelog**（谁、何时、改了什么、为什么改），不能悄悄改。
|
||
- **长文件（Prompt / ground-truth）让制片人手工替换最稳**——Cline 的 `write_to_file` 对长内容会截断，别让它反复 workaround。短文件（<200 行）用 `write_to_file` 整体写，老文件用 `replace_in_file` 局部改。
|
||
|
||
---
|
||
|
||
## 1. 子项目全貌（核心，所有开发决策的锚点）
|
||
|
||
### 1.1 定位与终极目标
|
||
|
||
看板升级是 TPS-Dashboard 项目中**最重要、最首页**的工程。
|
||
|
||
**终极目标**：在 TPS 工作台上建立**持续运行的收视诊断分析能力**——栏目每做完一期节目，系统自动消化选题单、文稿、收视成绩，按策划周期输出诊断报告，让制片人和全体编导都能看到"我们做得怎么样、问题出在哪、下一步怎么调"。
|
||
|
||
**质量标杆**：`example/` 目录下的 PPT（14 页诊断报告）和 Excel（8 个分析 Sheet）是制片人与 Opus 4.8 手工做出的 21 期阶段性分析成果。看板升级要达到**同等分析深度**，并把"一次性手工分析"变成"累积持续自动分析"。
|
||
|
||
### 1.2 核心理论框架——"双引擎 + 开篇钩子"
|
||
|
||
> 收视 ≈ 题材热度（横轴）× 叙事结构（纵轴）+ 开篇钩子（独立维度，叠加显示）
|
||
|
||
- **引擎 1 题材热度（地基）**：热点/新装备/大舰/节日天然有人看。即使叙事并列，热点也能撑住收视（如防空网 0.875、X-76 0.873）。
|
||
- **引擎 2 叙事结构（放大器）**：有没有贯穿全片的主线悬念。强主线能把冷题材拉到高收视（如仿生潜艇 0.92、组装武器 0.85）。
|
||
- **开篇钩子（独立维度）**：前 1-2 分钟决定观众换不换台。功能与叙事结构不同（开篇=留住，结构=留住之后的体验），AI 打标也分开判。
|
||
|
||
**两条腿至少占一条**：冷题材 + 并列结构 = 必然低分（如枪械图鉴 0.533）。
|
||
|
||
**"话题性"已拆解消化**（v2 快照确认）：题材稳态热度→横轴承接，时机加成→scene_tags 承接，切口话题感→program_format"横切类比"部分承接。话题性不独立立维。
|
||
|
||
这个模型是所有 AI 打标、分析计算、诊断结论的理论基础。开发任何功能都要回到这个公式上来。
|
||
|
||
### 1.3 招牌视觉——双引擎象限图（v2 快照定稿）
|
||
|
||
| 元素 | 编码 |
|
||
|------|------|
|
||
| 横轴 | 题材热度（= 该题材类别窗口内均值 − 栏目均值，零点=栏目自身平均线） |
|
||
| 纵轴 | 叙事结构 2 档 |
|
||
| 气泡大小 | 收视份额 |
|
||
| 气泡颜色 | 收视判定三色（红 `#c0584f` 优秀 / 蓝 `#5b8db8` 达标 / 绿 `#7aa874` 待提升） |
|
||
| 气泡边框 | 开篇钩子（粗实线=强 / 细实线=中 / 虚线=弱） |
|
||
| 悬停 tooltip | 节目名 + 期次 + 份额 + 钩子档 |
|
||
| 重叠处理 | 横轴 jitter + 垂直 jitter；同点聚集本身就是诊断信号 |
|
||
|
||
这张图是整个看板升级的**核心视觉交付物**。制片人已认可视觉方向。
|
||
|
||
### 1.4 6 字段完整枚举定义（v2 快照锁定，v3 修订叙事结构）
|
||
|
||
**字段一：`program_format` 主题材（单选）** — 节目内容切口，不是播出形态
|
||
|
||
| 枚举值 | 含义 |
|
||
|--------|------|
|
||
| `装备深解` | 围绕一款/一型具体装备深度剖析 |
|
||
| `横切类比` | 用某切口（趣味/功能/技术）跨装备类比 |
|
||
| `历史纵深` | 沿时间线讲装备/战术演进 |
|
||
| `前沿科技` | 新技术在军事装备上的应用 |
|
||
| `事件战例` | 围绕某次行动、战役、冲突 |
|
||
| `人物牵引` | 用人物作叙事入口和牵引线 |
|
||
|
||
**字段二：`equipment_domain` 装备域（多选，至少 1 项）**
|
||
|
||
`陆战装备` / `海军舰船` / `航空航天` / `导弹与反导` / `信息化` / `后勤保障` / `轻武器` / `跨域` / `其他`
|
||
|
||
注：原"枪械"升级为"轻武器"；原"空军防空"改为"导弹与反导"；"无人作战"从装备域剥离到 tech_tags。
|
||
|
||
**字段三：`scene_tags` 场景标签（多选，可空）** — 回答"为什么这周播"
|
||
|
||
`节点策划`（纪念日/周年/节庆/装备节点）/ `热点跟进`（突发新闻）/ `装备首发`（新装备亮相）/ `展会`
|
||
|
||
注：原"节日策划"从 program_format 移到 scene_tags 并改名"节点策划"。
|
||
|
||
**字段四：`tech_tags` 技术线标签（多选，可空）** — 新质新域追踪
|
||
|
||
`无人作战` / `智能化`（AI/算法/智能决策）/ `有人无人协同`
|
||
|
||
**字段五：`narrative_structure` 叙事结构（单选，2 档）**
|
||
|
||
`主线演进` / `并列结构`（v3 从 3 档收为 2 档）
|
||
|
||
**字段六：`opening_hook` 开篇钩子强度（单选，3 档）**
|
||
|
||
`强`（新闻/反差/画面震撼/悬念）/ `中`（背景铺陈/装备亮相/历史溯源）/ `弱`（直接讲技术/概念/平铺直叙）
|
||
|
||
### 1.5 系统四层架构
|
||
|
||
| 层 | 名称 | 做什么 | 当前状态 |
|
||
|----|------|--------|----------|
|
||
| L1 | **数据沉淀** | 每期节目的收视数据、文稿全文、编导、选题单持续入库 | 主项目已有 episodes 表基础结构 |
|
||
| L2 | **AI 打标** | 读文稿自动判别：题材分类(4字段)、叙事结构(2档)、开篇钩子(3档) | Prompt 2 已锁定，Prompt 1/3 待写 |
|
||
| L3 | **分析引擎** | 基于双引擎模型，计算走势、编导对比、题材对比、高低样本对照等多维分析 | 待设计 |
|
||
| L4 | **诊断报告** | 调用 LLM 生成文字诊断结论 + 改进建议（对标 PPT 第 8-10 页水平） | 待设计 |
|
||
|
||
### 1.6 三层分步交付策略（v1 快照定稿）
|
||
|
||
| 层 | 解锁条件 | 交付物 |
|
||
|----|---------|--------|
|
||
| 第一层"纯算的" | 只需题材字段（program_format + equipment_domain） | 核心指标卡、走势图（含基础/摸高目标线+滚动3期均值）、阶段对比、题材对比、编导维度 |
|
||
| 第二层"打标后才能算的" | 叙事结构 + 开篇钩子标完 | **双引擎象限图**（招牌视觉）+ 高低样本下钻 |
|
||
| 第三层"算不出只能写的" | L3 数据就绪 + LLM API 配通 | AI 季度诊断小结（制片人审改后发布）+ 一句话诊断 + 病因 + 提振方案 |
|
||
|
||
**编导视角：能力地图，不是排名榜**（v1 §2.7）。团队视角看"谁擅长哪种结构/哪类题材"，把强项做成全组可复用模板。制片人视角可看完整排名+下钻。底层同一套数据，锁可后开。
|
||
|
||
### 1.7 分析周期策略
|
||
|
||
- **默认轨：季度报告**（Q1/Q2/Q3/Q4）。对标台里考核节奏，每季约 12-13 期，数据量合适。
|
||
- **灵活轨：自定义周期**。所有栏目人员均可自由选择时间范围查看诊断（如"暑期档 7-8 月"、"最近 10 期"）。
|
||
- 系统按季度自动生成，用户也能手动选范围——两不误。
|
||
|
||
### 1.8 受众与权限
|
||
|
||
- **不只给制片人看**——全栏目人员（制片人、责编、6 名编导）都能查看分析结果、自由选择周期、调用 LLM 查看诊断。
|
||
- AI 打标结果仍须制片人审核后才正式落库（设计哲学红线：AI 给方向不给答案）。
|
||
- 但分析报告（L4）是基于已审核数据生成的，可直接展示。
|
||
|
||
### 1.9 样板文件参照表（`example/` 目录）
|
||
|
||
| 文件 | 内容 | 对标系统层 |
|
||
|------|------|-----------|
|
||
| PPT 第 2-5 页 | 收视走势、阶段对比、月度均值 | L3 分析引擎（走势分析模块） |
|
||
| PPT 第 6 页 | 题材结构饼图 + 各题材均值 | L3 分析引擎（题材分析模块） |
|
||
| PPT 第 7 页 | 高分 vs 低分样本对照 | L3 分析引擎（样本对照模块） |
|
||
| PPT 第 8-10 页 | 5 大病因、双引擎发现、提振方案 | L4 诊断报告（LLM 生成） |
|
||
| PPT 第 11 页 | 标题"3秒可懂"原则 | L4 诊断报告（建议模块） |
|
||
| PPT 第 12-13 页 | 选题日历、复盘会议程 | 超出系统范围，供人工参考 |
|
||
| Excel 8 个 Sheet | 核心指标卡、数据明细、走势图、编导对比、题材对比、阶段对比、高低样本、诊断结论 | L3 分析引擎的完整数据底稿 |
|
||
|
||
### 1.10 范围边界
|
||
|
||
- ✅ 做：Prompt 撰写与迭代、模型选型基准测试、ground-truth 维护、打标脚本、分析引擎设计与实现、诊断报告生成、前端看板页面
|
||
- ❌ 不做：选题日历自动编排、复盘会自动组织、标题自动改写（这些是人的工作）
|
||
- ❌ 不用旧 21 期数据冷启动——文稿和数据已重新整理清洗，拿新数据重新做
|
||
|
||
---
|
||
|
||
## 2. 技术栈与运行方式（稳定）
|
||
|
||
### 2.1 AI 打标沙盒（当前工作区）
|
||
|
||
- **语言**：Python 3.x
|
||
- **依赖锁定**（`scripts/requirements.txt`）：
|
||
- `openai==1.55.0` — **不能升级**，新版自动转 developer 角色，部分兼容接口不支持
|
||
- `python-dotenv>=1.0.0`
|
||
- `python-docx>=1.1.0`
|
||
- **生产模型**：mimo-v2.5-pro（通过 OpenAI SDK 兼容接口调用）
|
||
- **备选模型**：DeepSeek V4 Pro（命中率 80%，MiMo 中断时备用）
|
||
- **工作目录**：`E:\tps-dashboard\ai-labeling\`
|
||
|
||
### 2.2 诊断报告生成（L4 层，待实现）
|
||
|
||
- **多 LLM 共识机制**：配置多个 LLM API（如 MiMo + GLM 5.2 + 其他），分析相同数据、遵守相同规定，取共识结果。目的：弥补单一非顶级模型洞察力不足的问题，用"多家独立一致"提高诊断可信度。
|
||
- **模型候选**：mimo-v2.5-pro、GLM 5.2（智谱）、其他国产合规模型。具体阵容待选型测试。
|
||
- **与 AI 打标的区别**：打标是结构化判别（JSON 输出），诊断是开放式分析（自然语言输出）。两者用不同的 Prompt、可能用不同的模型。
|
||
|
||
### 2.3 关键目录
|
||
|
||
```
|
||
ai-labeling/
|
||
├── example/
|
||
│ ├── 军事科技栏目收视复盘与提振方案_v2.pptx ← 质量标杆（14 页诊断报告）
|
||
│ └── 军事科技栏目收视诊断分析_v2.xlsx ← 质量标杆（8 个分析 Sheet）
|
||
├── benchmark-set/
|
||
│ ├── transcripts/ ← 10 期文稿 .md（基准卷子）
|
||
│ └── ground-truth.json ← 基准答案 v0.2.1（核心资产，入 git）
|
||
├── prompts/
|
||
│ └── prompt2_narrative.md ← 叙事结构判别 v0.2（已锁定，入 git）
|
||
├── experiments/ ← 跑批结果 .json（不入 git）
|
||
├── scripts/
|
||
│ ├── import_transcripts.py ← docx → md 解析清洗
|
||
│ ├── run_labeling.py ← 调模型 + 写结果
|
||
│ └── summarize.py ← 汇总命中率
|
||
├── .env ← 真 Key（不入 git）
|
||
├── .env.example ← Key 占位模板（入 git）
|
||
├── .gitignore ← 拦 .env / experiments/ / __pycache__/
|
||
└── README.md
|
||
```
|
||
|
||
### 2.4 常用命令（PowerShell）
|
||
|
||
```powershell
|
||
# 单期打标
|
||
cd E:\tps-dashboard\ai-labeling
|
||
python scripts/run_labeling.py --ep 4 --model mimo-v2.5-pro
|
||
|
||
# 批量跑 10 期基准
|
||
3, 4, 5, 7, 10, 11, 12, 13, 14, 15 | ForEach-Object {
|
||
python scripts/run_labeling.py --ep $_ --model mimo-v2.5-pro
|
||
}
|
||
|
||
# 汇总命中率
|
||
python scripts/summarize.py --model mimo-v2.5-pro
|
||
```
|
||
|
||
### 2.5 模型配置（`scripts/run_labeling.py` 内 MODEL_CONFIG）
|
||
|
||
| key | base_url | model_name | env key |
|
||
|------------------|---------------------------------------|------------------|------------------|
|
||
| `mimo-v2.5-pro` | `https://api.xiaomimimo.com/v1` | mimo-v2.5-pro | MIMO_API_KEY |
|
||
| `deepseek-v4-pro`| `https://api.deepseek.com` | deepseek-v4-pro | DEEPSEEK_API_KEY |
|
||
|
||
### 2.6 环境变量
|
||
|
||
放 `.env`，**不进 git、不写进本文件**。需要：`MIMO_API_KEY`、`DEEPSEEK_API_KEY`。
|
||
|
||
---
|
||
|
||
## 3. 当前进度（动态，核心交接区）
|
||
|
||
- **已完成**：L2 层 Prompt 2（叙事结构）锁定 + ground-truth v0.3.0（4 分类字段骨架预留）+ 脚本扩展支持 --field classification + 生产模型 mimo-v2.5-pro 确定
|
||
- **正在做**：Prompt 1（4 分类字段）撰写中
|
||
- **卡点/待解**：L3/L4 架构设计尚未启动；诊断报告多 LLM 共识机制待选型测试
|
||
|
||
---
|
||
|
||
## 4. 已完成（只追加，最新在上）
|
||
|
||
- [2026-06-24 ｜ Opus+Cline] ground-truth v0.3.0 结构扩展（4 分类字段骨架预留）+ run_labeling.py / summarize.py 扩展 --field 参数支持 classification。脚本可直接跑 Prompt 1，等 prompt 文件就位即用。
|
||
- [2026-06-24 ｜ Opus] CLAUDE.md 二次更新：精读 v1-v4 四份续接快照，补入双引擎象限图视觉规格、6 字段完整枚举定义、三层分步交付策略、编导能力地图设计、v1-v4 关键决策。
|
||
- [2026-06-24 ｜ Opus] 全貌对齐：精读 PPT+Excel 样板、明确四层架构（数据沉淀→AI打标→分析引擎→诊断报告）、确认多 LLM 共识机制方向、确认季度+自定义双轨周期、确认全员可见。CLAUDE.md 从打标沙盒文档升级为全局指导文件。
|
||
- [2026-06-24 ｜ Opus] 模型配置统一更正：M3 配置移除，生产模型改为 mimo-v2.5-pro，更新 run_labeling.py / summarize.py / CLAUDE.md / README.md / .env.example。
|
||
- [2026-06-11 ｜ Opus+Cline] AI 打标流水线跑通：Prompt 2 v0.2 锁定、ground-truth v0.2.1 锁定、M3 100% 命中率、模型选型完成。Git commit `38f3728` + `edfb298`。
|
||
- [2026-06-11 ｜ Opus+Cline] 叙事结构 3 档收为 2 档（主线演进/并列结构）、10 期基准答案集 v0.1 锁定。
|
||
- [2026-06-11 ｜ Cline] 工作区目录结构搭建、三个脚本（import_transcripts / run_labeling / summarize）编写完成、10 期文稿导入。
|
||
<!-- 新条目往上加 -->
|
||
|
||
---
|
||
|
||
## 5. 开发路线图（按层级展开，层内按优先级排序）
|
||
|
||
### L2 — AI 打标（当前主战场）
|
||
|
||
- [ ] **Prompt 1（4 分类字段）撰写** — program_format / equipment_domain / scene_tags / tech_tags。Opus 写 → MiMo 跑基准 → 制片人审 → 锁定。
|
||
- [ ] **Prompt 3（开篇钩子）撰写** — 只看前 1-2 分钟判强/中/弱。同上套路。
|
||
- [ ] **opening_hook AI 验证** — ground-truth 里 opening_hook 是人工标的，等 Prompt 3 上线后跑一次看 MiMo 命中率。
|
||
- [ ] **示例集月度更新机制** — 上线后启用，每月集中替换，不碎片化（吃 prompt 缓存红利）。
|
||
- [x] Prompt 2 v0.2 撰写 + 锁定
|
||
- [x] ground-truth v0.2.1 锁定
|
||
- [x] 模型选型（mimo-v2.5-pro 生产）
|
||
|
||
### L1 — 数据沉淀（与主项目交界，需 Opus 审）
|
||
|
||
- [ ] **episodes schema 加字段** — `program_format / equipment_domain / scene_tags / tech_tags / narrative_structure / opening_hook` + `confidence`。**必须先切 Plan + Opus 审迁移方案，Cline 不许直接 Act。**
|
||
- [ ] **文稿入库流程** — 每期文稿全文入知识库（主项目 Phase 3 已有知识库基础设施）。
|
||
- [ ] **收视数据导入** — 真实收视 Excel 批量导入 + 清测试数据。
|
||
|
||
### L3 — 分析引擎（待设计）
|
||
|
||
- [ ] **分析维度定义** — 对标 Excel 8 个 Sheet：核心指标卡、走势图、编导对比、题材对比、阶段对比、高低样本对照、诊断结论。
|
||
- [ ] **计算逻辑实现** — 滚动均值、达标率、分组统计、样本排序等。
|
||
- [ ] **API 设计** — 支持按季度/自定义周期查询，返回结构化分析数据。
|
||
|
||
### L4 — 诊断报告（待设计）
|
||
|
||
- [ ] **多 LLM 共识选型测试** — 用样板数据测试 MiMo / GLM 5.2 / 其他模型的诊断分析能力，确定阵容。
|
||
- [ ] **诊断 Prompt 撰写** — 输入结构化分析数据，输出自然语言诊断结论 + 改进建议。需融入双引擎理论框架。
|
||
- [ ] **共识聚合逻辑** — 多家结果如何合并/投票/呈现。
|
||
- [ ] **UI 置信度三档** — AI 草稿/制片人确认/标题推断一眼可辨。
|
||
|
||
### 跨层
|
||
|
||
- [ ] **横轴量化方法落地** — 栏目均值偏离，需算具体数值。
|
||
- [ ] **prompt 缓存月度更新纪律** — AI 打标上线后第 1 个月起执行。
|
||
|
||
---
|
||
|
||
## 6. 关键决策（跨 session 最易丢）
|
||
|
||
### 项目全貌（v1-v4 快照 + 2026-06-24 对齐）
|
||
|
||
- [2026-06-24] **看板升级 ≠ AI 打标**。AI 打标只是 L2 层，完整系统是四层：数据沉淀 → AI 打标 → 分析引擎 → 诊断报告。目标是把 PPT+Excel 样板里的阶段性手工分析变成累积持续自动分析。
|
||
- [2026-06-24] **双引擎模型是理论基础**：收视 = 题材热度 × 叙事结构。所有打标维度、分析计算、诊断结论都围绕这个公式展开。
|
||
- [2026-06-24] **全员可见**：看板不只给制片人，所有栏目人员都能查看分析、自选周期、调用 LLM 看诊断。
|
||
- [2026-06-24] **分析周期双轨**：默认季度 + 自定义范围。
|
||
- [2026-06-24] **不用旧 21 期冷启动**：数据已重新整理清洗，拿新数据重新做。
|
||
- [2026-06-24] **诊断报告用多 LLM 共识机制**：因合规限制无法用顶级模型（Opus），改为多个国产模型（MiMo / GLM 5.2 / 待定）分析相同数据取共识，弥补单模型洞察力不足。
|
||
- [2026-06-09] **配色走浅色**：沿用 App 米色底 `#fbf9f1` + 深绿 `#6b8e6b`，不做深色大屏（留 2.0 独立数据大屏蓝本）。
|
||
- [2026-06-09] **DataEase 不进 1.0**：栈冲突 + 资源不够。图表用 ECharts / @ant-design/charts 在 React 栈直接复刻。
|
||
- [2026-06-09] **编导板块不做排名**（团队视角走"能力地图"），制片人视角可看完整排名+下钻。
|
||
- [2026-06-09] **"活的边界"**：实时脉搏（走势/滚动均值）永远滚动；周期复盘（象限/病因/提振）按周期生成。每张图都要有显式时间选择器。
|
||
- [2026-06-10] **话题性不独立立维**：稳态热度→横轴，时机→scene_tags，切口→横切类比形态。
|
||
- [2026-06-10] **6 字段枚举锁定**（见 §1.4）：program_format 6 值 / equipment_domain 9 值多选 / scene_tags 4 值 / tech_tags 3 值 / narrative_structure 2 档 / opening_hook 3 档。
|
||
|
||
### 叙事结构判别
|
||
|
||
- [2026-06-11] **3 档收为 2 档**：`主线演进` / `并列结构`。原"强主线悬念 vs 主线演进"实操中区分不开，合并。
|
||
- [2026-06-11] **判别心法**：先列全片大章节（3-5 个）→ 做"打乱测试"（调换顺序观众是否懵）。**段内承接 ≠ 全片骨架**——看到"递进""演进"字样先别急，回到大章节之间判断。
|
||
- [2026-06-11] **关键边界**：命名共性、装备域共性、空间方位共性均不构成主线。
|
||
|
||
### 模型选型
|
||
|
||
- [2026-06-11] 初始选型 MiniMax M3（Prompt 2 v0.2 命中率 100%）。DeepSeek V4 Pro 80%（备用）、MiMo v2.5 Pro 70%。
|
||
- [2026-06-24] **生产模型改为 mimo-v2.5-pro**（Cline 统一配 MiMo），M3 配置移除。DeepSeek V4 Pro 保留为备用。
|
||
- [2026-06-11] **好 Prompt 不为单家定制**——v0.2 同时提升了三家命中率，说明判别规则讲清楚就是最好的优化。
|
||
|
||
### ground-truth 版本史
|
||
|
||
- v0.1：10 期初始标注
|
||
- v0.2：改 2 期（ep12 逆袭战局改为并列→后经复议改回主线演进、ep14 X76 确认并列）
|
||
- **v0.2.1（当前锁定）**：改 1 期（ep12 经制片人复读稿 + 三家模型独立一致，最终定为并列结构）。**边界期用"多家独立一致 + 人工复审"双重证据机制**，未来扩展示例集时沿用。
|
||
|
||
### Prompt 设计原则
|
||
|
||
- [2026-06-11] **三个 Prompt 独立**（分类 / 叙事结构 / 开篇钩子），不合并成一个大 Prompt。
|
||
- [2026-06-11] **示例集"慢慢长大"**：10-30 期全塞 prompt → 30-80 期 pgvector 检索相似 → 80+ 期固定 5 + 动态 5-8。栈里 pgvector 已就位，第二阶段不新增依赖。
|
||
|
||
### 技术约束
|
||
|
||
- [2026-06-11] MiMo / M3 等 reasoning model 输出带 `<think>...</think>` 前缀。脚本用 `extract_json_from_response` 正则剥掉后再 `json.loads`。**换其他 reasoning model（R1、o1 系列）同样适用。**
|
||
- [2026-06-11] `openai==1.55.0` 锁版本——新版自动转 developer 角色，部分兼容接口不支持。
|
||
- [2026-06-11] API 调用不用 `response_format={"type": "json_object"}`——部分模型不完整支持，改为在 Prompt 末尾加输出强约束。
|
||
- [2026-06-11] `experiments/*.json` 不入 git（结果不固化）；`prompts/*.md` + `benchmark-set/` 入 git（核心资产）。
|
||
|
||
---
|
||
|
||
## 7. ⏩ 交接备注（换人/换工具 0 摩擦续上）
|
||
|
||
- **全貌已对齐**（2026-06-24）：看板升级四层架构（L1-L4）、双引擎理论、多 LLM 共识机制、季度+自定义双轨周期、全员可见——这些方向已与制片人确认。新来的人先读完第 1 节「子项目全貌」再动手。
|
||
- **当前主战场是 L2（AI 打标）**：Prompt 2 已锁定，下一步写 Prompt 1（4 分类字段）→ Prompt 3（开篇钩子）。流程：Opus/Claude Code 写 Prompt → MiMo 跑 10 期基准 → 制片人审 → 锁定。
|
||
- **Prompt 1 前置**：4 分类字段枚举需与制片人收敛口径（v1 快照 §三.1 已列草案）。
|
||
- **L3/L4 待设计**：分析引擎和诊断报告的架构尚未展开。建议 Prompt 1/3 锁定后启动，可与 schema 加字段并行。
|
||
- **schema 加字段是跨层硬前置**：episodes 表加 6+1 字段，必须 Plan + Opus 审 + 制片人批准 + `pg_dump` 备份。这是主项目的事，不在沙盒内做。
|
||
- **ep12 逆袭战局**是标志性边界期：制片人 v0.1 标主线演进 → 三家模型独立判并列 → 制片人复读稿后改并列（v0.2.1）。这个案例是"双重证据机制"的范例。
|
||
|
||
---
|
||
|
||
## 8. 待确认 / 开放问题（需制片人拍板）
|
||
|
||
- [x] ~~Prompt 1 的 4 分类字段枚举最终口径~~ → 已在 v2 快照锁定（见 §1.4）
|
||
- [ ] 多 LLM 共识机制的模型阵容（MiMo + GLM 5.2 + ?）待选型测试后定
|
||
- [ ] L3 分析引擎是否需要超出 Excel 8 Sheet 的额外分析维度
|
||
- [ ] 下一步优先级：先推 Prompt 1 还是先推 schema 加字段方案？
|
||
- [ ] 示例集扩充策略：当前 5 个示例（含 2 个陷阱反例），是否需要补更多？
|