赛马看板 × KOL 动态画像集成 · 产品需求文档

Curvature Labs · Trading Matrix
版本 v1.4 · 2026-07-01
状态：草稿 · 待评审（R4 候选池 DEV-01~07 工程已落地，见 §4.1 / §4.3.5 落地说明）
依赖：DH R1/R2/R3 生产部署完成（R10 收尾） + §6.1 业务前置条件清单全部闭环

v1.4 变更（2026-07-01，对齐 R4 候选池工程落地与联调结论，依据 docs/raceboard_candidate_dev_notes.md / raceboard_candidate_impl_plan.md）：

§4.1 新增 TM 候选包定义（五维画像聚合，≠ DH candidate_id / 标的行）

§4.1 推进验证重构：先跑批量回测 / 直接进入实盘 两条路径 + 验证进度侧栏 + 列表徽章（backtest_status / trader_status）

新增 §4.3.5 回测基线层（Layer 0）（原 v1.2 修订计划 R13）

§4.3.4 明确 Event 漏斗展示前提：kol.trader_id > 0（已有 trader 的 KOL Drawer）

§6.4 新增 DH Open API 字段契约（联调核实表）

§9 / §10.2 修正 R3 feedback_type 枚举（candidate_validation / candidate_backtest_result；废弃 candidate_admitted 等无效值）

§6.3 Q-FTYPE / Q-CSTATUS 标记已关闭；§12 验收标准对齐 DEV-07

v1.3 变更（2026-06-24，对齐 DH 动态画像进展复盘 + R4 任务书）：

§6.1 / §6.2 / §6.3：R3 生产状态同步——DB 表已创建 ✓、只读/写入/错误密钥冒烟已通过 ✓；Q-DB 标记已完成

§6.3 新增 Q-FTYPE（feedback_type 枚举确认）和 Q-CSTATUS（candidate_status 字段名确认）

§4.1 候选优先级：新增「当前生产快照状态说明」—— 当前无 action 候选，R4 pilot 全为 risk/observe

§十四开放问题：新增 Q11（R5 策略蒸馏路线）/ Q12（feedback_type 枚举）/ Q13（candidate_status 字段名）

新增关联文档引用：DH-TM-R4小批量验证接入任务书.md

v1.1 变更：在 DH 候选段增加候选管理工作流，运营人员可在 TM 内完成查看、标记决策、推进验证全链路，决策结果通过 R3 写回 DH，无需切换系统。新增章节：§4.1（候选管理工作流全量重写）、§4.8（候选状态机）、§4.9（TM→DH 写回映射）。

v1.2 变更（评审环节沉淀，参见 赛马看板-PRD-v1.2-修订计划.md）：

新增 §〇端到端业务流全景（5 段流水线 + 角色责任 + 两条数据回路 A/B）

重构 §6 为"业务前置条件 + 跨团队配合矩阵"，登记 5 项待确认事项

新增 §4.1.x 候选数据同步策略 / trader 配置创建闭环 / DH lifecycle 反向通知 / 阵容互补提示

新增 §4.3.4 单 KOL Event 漏斗（5 口径，TM 端本地计算不写回 DH） + W7 信号质量异常预警

新增 §4.5.4 预警优先级排序规则

§4.6 决策日志新增 effect_review_at（处置 14 天后强制效果回看）

§4.7 与 DH "R3 仅外部证据"原则对齐，新增 TM 端评估阈值表

§4.8 验证结果回流（drift 计算契约 + validation_completed 写回类型 + 60 天超时兜底）

§8 viewer 角色合规边界澄清，权限矩阵新增 §4.3.4 / §4.7 行

新增 §13 数据飞轮 KPI（双层：池治理层 + 单 KOL 信号质量层）

各功能模块末尾新增 SOP 速查（按 D1 周节奏：周一评审会 + 周五复盘）

§10 / §11 / §12 同步更新；修复 §9 内部子编号与目录硬伤

文档关系

文档	位置	用途
赛马看板基础产品需求文档	clabs `requirement/归因追踪/T1_赛马看板产品需求.md`	赛马看板基础 PRD（本文依赖其信息架构）
赛马看板需求清单与迭代计划	clabs `requirement/归因追踪/赛马看板需求清单与迭代计划.md`	R01–R19 排期（2026-07-01 对齐 v1.4）
赛马看板 PRD v1.2 修订计划	clabs `requirement/归因追踪/赛马看板-PRD-v1.2-修订计划.md`	v1.2 修订备忘录（R13 等已并入 v1.4）
赛马看板 × KOL 动态画像集成协同需求	Gov co-requests	跨团队接口契约与待确认项
DH-TM R4 验证任务书	Gov co-requests	工程验证层 T1–T8
赛马看板工程交付状态	Gov co-requests	T1.0–T1.3 工程事实摘要
候选池开发备忘	clabs `docs/raceboard_candidate_dev_notes.md`	联调踩坑与产品偏差上下文
DEV-01~07 技术规格	clabs `docs/raceboard_candidate_impl_plan.md`	候选池实现规格
整体工程进度	clabs `docs/raceboard_progress_summary.md`	T1.0–T1.3 进度快照
DH KOL 动态画像进展复盘	外部文档	DH 侧接口规格与生产状态
DH Provider 配置中心方案	Provider 配置中心 Review	DH 外部能力治理框架

〇、端到端业务流全景

赛马看板不是孤立产品，而是 DH 感知层与 TM 验证层之间一条完整的"信号→决策→验证→证据→画像迭代"业务流的中段枢纽。本节用一张全景图 + 角色责任表 + 两条数据回路说明，把所有跨团队配合方在业务流中的位置交代清楚。

〇.1 五段业务流全景

┌──────────────┐   ┌──────────────┐   ┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│ ① DH 画像产出 │ → │ ② DH 候选池   │ → │ ③ TM 候选段   │ → │ ④ TM 验证中   │ → │ ⑤ TM 赛马中   │
│  静态+动态画像 │   │  candidate-list│   │  运营决策     │   │  trader 配置  │   │  排行榜+漏斗  │
└──────┬───────┘   └──────┬───────┘   └──────┬───────┘   └──────┬───────┘   └──────┬───────┘
       │           R2 candidate  │                  │                  │                  │
       │           -list API ──► │                  │ (R3) admission   │ (R3) validation_│
       │                         │                  │ candidate_       │ completed +     │
       │                         │                  │ validation /     │ realized_drift   │
       │                         │                  │ backtest_result  │                  │
       │                         │                  └──────────┬───────┴──────────────────┘
       │                         │                             │
       │                         │                             ▼
       │                         │                  ┌──────────────────────┐
       │                         │                  │ DH 反馈账本（外部证据） │
       │                         │                  │ dn_kol_candidate_     │
       │                         │                  │ validation_feedback   │
       │                         │                  └──────────┬───────────┘
       │                         │                             │
       └─────────────────────────┴─────────────────────────────┘
                  DH 静态画像团队按周/月评估，迭代画像（不自动反推）

                                ┌─────────────────────────────────────┐
                                │ TM 本地：Event 漏斗 + 方向准确率       │
                                │ （TM 内部参考视图，不写回 DH）          │
                                │ 依赖 DH event 列表接口（D5 待确认）    │
                                └─────────────────────────────────────┘

〇.2 各业务环节说明

环节	输入	输出	责任系统	主责团队	下游接口 / 数据契约
① DH 画像产出	KOL 原始消息、证据事件	静态画像 + 动态状态（lifecycle / direction / data_sufficiency）	Data Horizon	DH 静态画像负责人 + DH maintainer	DH 内部流转，无外部接口
② DH 候选池	画像 + 状态聚合	candidate-list 接口数据 + 原始 event 列表	DH Open API	DH maintainer	→ ③ 通过 DH R2 `candidate-list API` 拉取（关键字段：candidate_type / lifecycle_status / direction_distribution / data_sufficiency / rejection_reasons）；TM 需注册为 Consumer（见 §6.1）
③ TM 候选段	DH 候选数据（TM 五维候选包聚合展示）	推进 / 观察 / 暂缓决策 + 可选批量回测 + R3 写回	TM 赛马看板	TM 产品/运营	→ DH 反馈账本，运营决策写 `candidate_validation`；回测结果写 `candidate_backtest_result`（完整映射见 §十.2）
④ TM 验证中	推进的 KOL + 手动创建的 trader 配置	回测/实盘结果 + R3 validation_completed 写回	TM 验证流程	TM 工程 + TM 运营	→ DH 反馈账本，通过 R3 `validation_completed` 类接口写回（含 realized_style_drift / validation_status / win_rate；完整映射见 §十.2）
⑤ TM 赛马中	验证通过的 KOL	排行榜 + 单 KOL Event 漏斗 + 预警	TM 赛马看板	TM 运营	依赖 DH `event 列表接口`（D5 待 @DH maintainer 选型，见 §6.1 / §十四 Q10）；漏斗结果不写回 DH（详见 §4.3.4）

〇.3 两条数据回路（必读）

本方案存在两条 TM→DH 数据回路，必须严格区分，避免混淆。

回路 A：R3 写回（飞轮主路）

路径：TM 候选段决策 / TM 验证结果 → R3 接口 → DH 反馈账本（dn_kol_candidate_validation_feedback）
内容：运营决策类（candidate_validation）+ 回测/验证结果类（candidate_backtest_result 等，含 realized_style_drift / validation_status / win_rate）
约束：受 DH R3 的 6 项保护机制约束（密钥校验、state_hash 校验、幂等、过期拒绝等）
影响：DH 工作台展示为外部证据；不改变 DH 画像可信度排序；DH 静态画像团队按周/月人工评估后决定是否迭代画像

本回路的完整字段定义与写回映射见 §十《TM→DH 写回映射》；保护机制与前置条件见 §6.1。

回路 B：TM 本地漏斗（不回传 DH）

路径：DH 原始 event + TM 内部数据 → TM 本地计算 → TM Drawer 与排行榜展示
内容：Event 漏斗 5 口径（信号方向准确率 / 信号采纳率 / 报单成功率 / 执行胜率 / 端到端命中率）
约束：完全在 TM 内部计算与消费，不进入 R3 写回，DH 不感知这些指标
目的：保持 DH 画像独立性，避免"TM 自评分→DH 自动反推画像"的封闭反馈环

本回路的 5 个口径定义与计算逻辑见 §4.3.4《单 KOL Event 漏斗》；所依赖的 DH event 列表接口待 D5 选型确认（见 §6.1 / §十四 Q10）。

〇.4 业务流跨团队责任速查

详细矩阵见 §六《业务前置条件与跨团队配合矩阵》。本节先给一张速查：

角色	在业务流中的位置	关键动作
DH 静态画像负责人	① 环节 + 反馈消费	维持画像语义稳定；按周/月评估外部证据
DH maintainer	① ② 环节 + R3 接口	API 可用性；密钥治理；原始 event 列表接口
DB 权限成员	② R3 表	执行迁移；表结构维护
DH Provider 配置中心管理员	跨环节凭据治理	TM Consumer 注册；额度策略
TM 工程	③ ④ ⑤ 环节	候选拉取、Drawer、R3 写回 client、Event 漏斗
TM 产品/运营	③ ④ ⑤ 环节	候选决策（周节奏）、trader 创建、预警处置
合规	⑤ viewer 角色	viewer 对外/对内边界审阅

一、背景与动机

1.1 当前赛马看板使用 DH 的状况

赛马看板已对接 DH，但使用深度极浅。当前从 DH 获取的只有：

dh_quality_grade（A/B/C/D 徽章）
content_type（信源类型描述）

且以上两个字段仍来自 kol_meta.json 过渡配置，而非 DH 生产接口。

1.2 DH 现已提供但未使用的数据

DH R1/R2/R3 完成后，以下数据均可读取，但完全没有进入赛马看板：

静态画像（每位 KOL 的长期特征）
  role              信源角色（混合型 / 信号型 / 分析型）
  activity_level    活跃度（高频 / 中频 / 低频）
  holding_period    持仓偏好（短线 / 中线 / 长线）
  strategy_styles   策略风格（突破 / 趋势跟随 / 回调低吸…）
  decision_driver   决策驱动（技术结构 / 消息面 / 情绪盘口）
  symbols           关注标的（BTC / ETH / SOL…）

动态画像（实时刷新的近期状态）
  lifecycle_status  当前生命周期（active / conflicted / stale）
  evidence_status   证据一致性（aligned / conflicting / insufficient）
  direction_distribution  近期多空方向分布
  data_sufficiency  证据丰富度（rich / moderate / sparse）
  candidate_type    候选类型（action / risk / observe）
  last_evidence_at  最新证据时间戳
  rejection_reasons 当前不宜推进验证的原因列表

R3 验证反馈（TM 回测结束后写回 DH）
  realized_style_drift  实际执行与画像描述的偏离度
  validation_phase      验证阶段（backtest / simulation / paper / live_review）
  validation_status     验证结论（received / pass / fail / unresolved）

1.3 问题定义

问题	表现
DH候选段没有优先级	PM 无法判断哪个候选"最值得现在推进"
无法感知信源状态变化	KOL 信源已经自相矛盾了，赛马排行榜仍在计分
验证风格错位	画像偏多的 KOL 用均等多空参数验证，结论失真
沉默预警误报	W3 只看 TM event_log，无法区分"信源停发"还是"AI 过滤率高"
运营决策缺上下文	PM 降级 KOL 时只有 TM 数字，不知道信源本身状态如何
无画像质量追踪	DH 画像是否准确，当前没有任何反馈机制

二、目标

ID	目标	衡量方式
G1	DH候选段有优先队列	PM 可根据候选优先级做接入决策，不靠感觉
G2	信源状态异常可感知	lifecycle_status = conflicted/stale 时 PM 在看板内可见
G3	决策有画像上下文	Drawer 内可看到 KOL 的静态 + 动态画像摘要
G4	沉默预警精准化	W3 误报率降低，能区分"信源沉默"vs"AI 过滤高"
G5	排行榜有画像一致性维度	`realized_style_drift` 进入排行榜可排序列
G6	形成画像质量闭环	R3 写回后能追踪 DH 画像准确率随时间的变化

三、信息架构变化总览

3.1 三段流水线各段变化

┌─────────────────────────────────────────────────────────────────────────┐
│  三段流水线  （变化部分加粗）                                             │
├──────────────────┬──────────────────────┬────────────────────────────────┤
│  DH候选池        │  TM验证中            │  TM赛马中                      │
│                  │                      │                                 │
│  原有            │  原有                │  原有                           │
│  ・KOL名称       │  ・进度条            │  ・排行榜（收益/胜率/回撤…）    │
│  ・DH初评        │  ・执行健康          │  ・综合评分                     │
│  ・策略风格      │                      │  ・BTC基准对比                  │
│                  │                      │                                 │
│  新增            │  新增                │  新增                           │
│  ・候选类型标签  │  ・画像对齐卡        │  ・风格漂移列（drift）          │
│  ・生命周期状态  │  ・方向预检          │  ・画像新鲜度提示               │
│  ・证据丰富度    │                      │  ・二维策略过滤                 │
│  ・候选优先级排序│                      │                                 │
└──────────────────┴──────────────────────┴────────────────────────────────┘

3.2 KOL Drawer 新增区域

原有 Drawer（4区）          升级后 Drawer（5区）
─────────────────           ──────────────────
1. 身份徽章                 1. 身份徽章
2. 阶段进度                 2. 阶段进度
3. 当周健康                 3. 当周健康
4. 历史表现                 4. 历史表现（新增方向一致率）
5. 决策日志                 5. 决策日志（新增画像上下文）
                            6. DH 画像摘要（新增）

四、功能规格

4.1 DH候选段：候选管理工作流（全量升级）

设计原则

运营人员只使用 TM 一个系统。TM 从 DH 拉取全量候选数据，运营在 TM 内完成"查看→判断→决策→推进"全链路。决策结果通过 R3 写回 DH，DH 侧同步更新候选状态，无需切换系统。

TM 候选包（列表展示单位）

DH 生产环境同一 kol_id 常对应多行 candidate_id（DH 按 state_hash = 标的 × 时间维度 × 动态状态区分，不是重复数据）。运营在 TM 列表中不按标的拆行，而按以下五维在 TM 端聚合为 「TM 候选包」：

维度	字段来源
KOL	`kol_id`
持仓偏好	`profile_thumb.holding_period`
风险偏好	`profile_thumb.risk_preference`
策略风格	`profile_thumb.strategy_styles`（排序后 canonical）
周期	`profile_thumb.time_horizon`

同五维、不同 symbol_bucket → 合并为一行；主键取组内 priority_score 最高的 candidate_id
列表副标题示例：持仓 · 周期 · 风险 · 风格 · N个DH状态（package_variant_count = 合并的 DH 状态数）
运营决策仍绑定具体 candidate_id（当前实现默认提交组内 priority 最高者；合并组内多 ID 选择 UI 为开放项，见 §十四 Q14）
KOL 名称来自 POST /v1/open/kol/list registry，不得从 static_style_summary 推断

工程参考：trading-matrix candidate_dedupe.go · 生产约 421 条 DH 候选 / ~32 个 kol_id（2026-07-01）

整体数据流

DH R2接口                  TM 候选管理段              DH R3写回
─────────────              ─────────────────          ──────────
candidate_type             [查看画像+方向]
lifecycle_status    ────►  [标记决策]          ──────► validation_status
direction_dist.            [推进验证]                  feedback_type
evidence_count             [填写理由]                  rejection/rationale
rejection_reasons          [确认]

候选优先级评分规则

优先级由以下四个维度合并评估，产出一个 3 级标签（推荐推进 / 可观察 / 待成熟）：

维度	字段	推荐推进	可观察	待成熟
接入意向	`candidate_type`	action	risk	observe
证据丰富度	`data_sufficiency`	rich	moderate	sparse
信源状态	`lifecycle_status`	active	—	conflicted / stale
证据新鲜度	`last_evidence_at`	≤7天	≤30天	>30天

规则：4个维度全部"推荐推进" → 高优先级；有1-2个降级维度 → 中等；关键维度（状态或证据）待成熟 → 待成熟。

当前生产快照说明（2026-07-01 基线）：DH 生产约 421 条候选、~32 个 kol_id；R4 pilot 原始 8 条快照仍适用验收方法，但运营日常面对的是全量池。当前仍以 risk/observe 为主，暂无 action 候选。运营 SOP 中「推荐推进」标签在 action 出现前应灵活调整。

候选池列表界面

┌─ DH 候选池 ──────────────────────────────────────────────────────────────┐
│  来源：DH生产 · 最后同步 5分钟前  [刷新]          共 ~250 个 TM 候选包       │
│                                                                           │
│  排序：[优先级↓▼]  筛选：[全部状态▼]  [搜索 KOL…]                         │
│                                                                           │
│  KOL          初评  优先级     信源状态     方向偏好     证据      操作    │
│  ──────────── ────  ────────   ──────────   ─────────    ──────    ───── │
│  Alpha X      [A]   ▲推荐推进  ● active     多 83%       rich·36   [操作]│
│               短线 · 日内 · 中风险 · 突破 · 3个DH状态                      │
│  Beta Y       [B]   ▲推荐推进  ● active     多 71%       mod·18    [操作]│
│  Gamma Z      [B]   ─可观察    ⚠conflicted  均衡52/48    rich·24   [操作]│
│  ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─  │
│  Sigma Q      [A]   ✓ 已推进   🔄 回测中    —            —         [查看]│
│  Omega P      [B]   ✗ 已暂缓   暂不接入     —            —         [重评]│
│                                                                           │
│  图例：▲推荐推进  ─可观察  ○待成熟  ✓已推进  ✗已暂缓  👁标记观察          │
└──────────────────────────────────────────────────────────────────────────┘

列表列说明（相对 v1.3 调整）：

不单独展示标的列：标的差异收敛到副标题「N个DH状态」；详情侧栏仍可看 DH 原始 symbol_bucket
已推进分区增加验证状态列（见 §4.1.y 列表徽章表）

「操作」下拉菜单展开后：

  [操作 ▼]
  ─────────────────
  📋  查看详情
  ─────────────────
  ▶  推进验证
  👁  标记观察
  ✗  暂不接入

候选详情侧边栏（点击「查看详情」展开）

右侧滑出，不跳转页面，分三区：

┌─ 候选详情：Alpha X ─────────────────────────────────────────── × ──────┐
│                                                                          │
│  ▌静态画像                                                               │
│  角色：混合型 · 高频 · 短线                                               │
│  擅长标的：BTC · ETH · SOL                                               │
│  策略风格：突破 · 回调低吸                                                │
│  决策驱动：技术结构 + 情绪盘口                DH评级 B · 画像2小时前      │
│                                                                          │
│  ─────────────────────────────────────────────────────────────────────  │
│                                                                          │
│  ▌动态状态（实时）                                                        │
│  信源状态：● active       证据：36条（rich）   最新证据：40分钟前          │
│  证据一致性：aligned                                                      │
│                                                                          │
│  近期方向分布（ETH）：                                                    │
│  ████████████████████░░░░  多 83%                                        │
│  ████░░░░░░░░░░░░░░░░░░░░  空 17%                                        │
│                                                                          │
│  候选类型：[action]  DH判断：当前可推进验证                               │
│  不适合原因：暂无阻碍项                                                   │
│                                                                          │
│  ─────────────────────────────────────────────────────────────────────  │
│                                                                          │
│  ▌TM 操作历史                                                            │
│  暂无操作记录                                                             │
│                                                                          │
│  ─────────────────────────────────────────────────────────────────────  │
│                                                                          │
│  [▶ 推进验证]          [👁 标记观察]          [✗ 暂不接入]               │
└──────────────────────────────────────────────────────────────────────────┘

信源状态为 conflicted 时，详情侧边栏变化：

│  信源状态：⚠ conflicted（已持续3天）    证据：24条    最新：3天前          │
│  证据一致性：conflicting（多空并存）                                      │
│                                                                          │
│  近期方向分布（ETH）：                                                    │
│  ████████████░░░░░░░░░░░░  多 52%                                        │
│  ████████████░░░░░░░░░░░░  空 48%                                        │
│                                                                          │
│  候选类型：[risk]                                                         │
│  不适合原因：                                                             │
│  · 信源方向自相矛盾                                                       │
│  · 多空证据各占约一半，无法判断方向                                       │
│  · 建议：等待 DH 状态恢复 active 后再决策                                │
│                                                                          │
│  [▶ 推进验证]          [👁 标记观察 ←推荐]     [✗ 暂不接入]              │
│  ⚠ 当前信源状态冲突，推进验证风险较高                                     │

三个操作动作的详细设计

动作一：推进验证

点击后弹出确认对话框：

┌─ 确认推进验证 ────────────────────────────────────────────────────────────┐
│                                                                            │
│  将 Alpha X 推进到验证流程                                                  │
│                                                                            │
│  起始阶段：                                                                 │
│  ● 先跑批量回测（推荐）                                                     │
│  ○ 直接进入实盘（须填写跳过原因）                                           │
│                                                                            │
│  判断依据（必填）：                                                          │
│  ┌────────────────────────────────────────────────────────────────────┐   │
│  │  方向明确，证据充分，短线突破风格符合当前市场节奏                     │   │
│  └────────────────────────────────────────────────────────────────────┘   │
│                                                                            │
│  ─────────────────────────────────────────────────────────────────────   │
│  ℹ 选「先跑批量回测」将提交 event-backtest 任务；                           │
│    选「直接进入实盘」须填跳过原因；                                         │
│    trader 配置仍需在 TM 后台手动创建。                                      │
│                                                                            │
│                                            [取消]    [确认推进]            │
└────────────────────────────────────────────────────────────────────────────┘

两条推进路径（DEV-07）：

路径	请求字段	后端行为	前端反馈
A · 先跑批量回测	`backtest_phase=run_backtest`	`tm_decision_status=admitted`；提交 TM `/api/event-backtest` 批量任务；`backtest_status=pending`	Toast「已推进，回测任务已提交」；侧栏不关闭，切换验证进度时间线
B · 直接进入实盘	`backtest_phase=skip_backtest` + `skip_reason`（必填）	`backtest_status=skipped`；`trader_status=awaiting`	Toast「已跳过回测，请创建 trader」；侧栏展示下一步引导

回测窗口：last_evidence_at 向前 12 个月，再 clamp 到 R4 数据范围 [2025-06-01, 2026-06-30]（见 §4.3.5.2）。event-backtest 时间戳单位 Unix 秒（非毫秒）。

推进后的状态变化：

系统	变化
TM 候选段	行进入「已推进」分区；展示 §4.1.y 验证徽章
TM 验证中	该 KOL 不会自动出现；须手动创建 trader 后由系统检测 `trader_status=created`
侧栏	admit 成功后保持打开，展示 `GET /candidate/:id/validation-progress` 时间线（30s 轮询）
DH R3 写回	`feedback_type=candidate_validation`，`validation_status=received`；跑回测时 `validation_phase=backtest`，跳过时 `validation_phase=live_review`；密钥缺失时本地 `r3_write_back_pending=true`，Toast「决策已保存，DH 写回待同步」
回测完成	callback 写入 `tm_kol_backtest_result`；样本 ≥10 时 R3 `candidate_backtest_result`

动作二：标记观察

点击后展开轻量输入框（不弹出全屏对话框）：

┌─ 标记观察 ────────────────────────────────────────────────────────────────┐
│                                                                            │
│  保持观察，暂不推进验证                                                      │
│                                                                            │
│  原因（可选）：[信源方向冲突，等 DH 状态稳定后再评估              ]         │
│  下次复查：   [2026-07-07]                                                  │
│                                                                            │
│                                            [取消]    [确认标记]            │
└────────────────────────────────────────────────────────────────────────────┘

标记后的状态变化：

系统	变化
TM 候选段	行状态变为「👁 已标记」，在列表中保留但标注
DH R3 写回	`validation_status=unresolved`，`feedback_type=candidate_validation`，`validation_result_summary` 含原因和复查时间

动作三：暂不接入

点击后弹出对话框，必填理由：

┌─ 暂不接入 ────────────────────────────────────────────────────────────────┐
│                                                                            │
│  决定暂不接入 Alpha X                                                       │
│                                                                            │
│  原因类型：                                                                  │
│  ○ 信源质量不符合验证标准                                                    │
│  ○ 信源方向不明确                                                            │
│  ○ 当前资源有限，优先其他 KOL                                               │
│  ● 其他原因                                                                  │
│                                                                            │
│  详细说明（必填）：                                                           │
│  ┌────────────────────────────────────────────────────────────────────┐   │
│  │  信源方向与当前市场环境存在冲突，等市场环境变化后重评               │   │
│  └────────────────────────────────────────────────────────────────────┘   │
│                                                                            │
│  [n] 天后重新提醒评估此候选：  [30] 天                                      │
│                                                                            │
│                                            [取消]    [确认暂不接入]        │
└────────────────────────────────────────────────────────────────────────────┘

暂不接入后的状态变化：

系统	变化
TM 候选段	行状态变为「✗ 已暂缓」，默认折叠到「已处理」分区底部
DH R3 写回	`validation_status=unresolved`，`feedback_type=candidate_validation`，`validation_result_summary` 含详细说明

候选池分区展示

┌─ 待决策（18 个）───────────────────────────────────────────────────────────┐
│  ▲ 推荐推进（3个）  Alpha X · Beta Y · Zeta M                              │
│  ─ 可观察（9个）    ...                                                      │
│  ○ 待成熟（6个）    ...                                                      │
└────────────────────────────────────────────────────────────────────────────┘

┌─ 已处理（折叠，点击展开）──────────────────────────────────────────────────┐
│  ✓ 已推进（3个）  👁 已标记观察（4个）  ✗ 已暂缓（2个）                    │
└────────────────────────────────────────────────────────────────────────────┘

复查到期提醒

当运营设置了"标记观察"的复查时间，到期当天在候选段顶部展示：

┌─ 复查提醒 ─────────────────────────────────────────────────────────────────┐
│  ⏰ 今日有 2 个候选到达复查时间：Gamma Z · Delta W              [查看]      │
└────────────────────────────────────────────────────────────────────────────┘

候选类型与不适合原因展示规则

DH字段值	展示标签	含义文案
`action`	可推进验证	DH判断当前状态适合推进 TM 验证
`risk`	风险候选	有信号价值，但存在冲突或证据不充分
`observe`	仅观察	当前不适合推进验证，继续积累证据

原因字段值	展示文案
`state_conflicted`	信源方向自相矛盾
`evidence_status_conflicting`	支持与反向证据并存，无法判断方向
`stale_evidence`	证据过旧（超过30天无新内容）
`needs_review`	需人工复核

候选优先级关键维度权重

四个维度并非等权，按以下优先级影响最终标签（高优维度降级直接拉低整体等级）：

关键维度优先级：lifecycle_status  >  candidate_type  >  data_sufficiency  >  evidence_freshness
                  （信源状态）        （接入意向）        （证据丰富度）        （证据新鲜度）

判定规则：

lifecycle_status 为 conflicted 或 stale → 不论其他维度如何，直接降为「待成熟」
candidate_type 为 observe → 不论其他维度如何，不能为「推荐推进」（最多「可观察」）
data_sufficiency 为 sparse → 不能为「推荐推进」
evidence_freshness > 30天 → 在原标签上降一档

此规则避免了 §4.1 候选优先级评分表的"维度等权"误读，特别是 candidate_type=observe 与 lifecycle_status=stale 同时出现时不会重复降级。

4.1.x 候选数据同步策略

项	配置
轮询周期	默认 5 分钟（可配，建议范围 3-15 分钟）
全量分页	DH `candidate-list` 当前 `page_size=100`；生产 ~421 条时需 TM 循环分页或 DH 侧扩展（R10）
增量优先	优先按 `state_version` 增量拉取；遇 version 不连续时退化为全量同步
热路径	DB 已有数据时列表直读；缓存命中跳过同步 upsert（避免 >120s 超时）
失败降级	DH 接口连续 3 次失败 → 候选段顶部 banner 提示「DH 暂不可达，展示缓存数据（最后同步：N 分钟前）」；运营操作仍可用；R3 密钥缺失时标记 `r3_write_back_pending`
同步审计	每次同步写入 `tm_dh_candidate_sync_log`（同步时间 / 拉取数 / 新增 / 变更 / 失败原因），运维可追溯

4.1.x trader 配置创建闭环

D1 决策已确认推进验证后 trader 配置由运营手动创建。本节定义"待创建 → 已创建"的状态闭环，避免运营遗漏：

状态	触发	候选段行展示
待创建 trader 配置	回测 pass 或 skip 后 `trader_status=awaiting`	行末「🟢 回测通过 ⚙ 待建 trader」或「⏭ 已跳过 ⚙ 待建 trader」
已创建 trader 配置	(a) 后端轮询 `tm_trader` 检测到 `kol_id` 存在 → `trader_status=created`；(b) 运营点击「标记已创建」（P1 待做）	徽章变为「✓ 已进入验证」；KOL 进入验证中 / 赛马 Tab
创建超时预警	`admitted` 且 `trader_status=awaiting` 超过 7 天	候选段顶部红色 banner「N 个候选超过 7 天未创建 trader」（banner 已接统计；逾期文案与人工标记按钮 P1 待做）

┌─ Trader 配置闭环预警 ────────────────────────────────────────────────────┐
│  ⚠ 2 个候选超过 7 天未创建 trader 配置：Alpha X（9天）· Zeta M（7天）   │
│                                                          [查看待办]      │
└──────────────────────────────────────────────────────────────────────────┘

4.1.y 验证状态机与进度展示（DEV-07）

两个正交状态字段（避免单一大枚举）：

字段	枚举值	说明
`tm_decision_status`	`pending / admitted / observing / deferred`	运营决策
`backtest_status`	`not_started / pending / pass / fail / unresolved / skipped`	批量回测进展
`trader_status`	`not_required / awaiting / created`	Trader 创建进展

状态流转（摘要）：

DH 同步 → pending / not_started / not_required

admit + run_backtest → admitted / pending / not_required
  → callback pass  → admitted / pass / awaiting
  → callback fail  → admitted / fail / not_required（运营可豁免 → awaiting）
  → callback unresolved → admitted / unresolved / not_required

admit + skip_backtest → admitted / skipped / awaiting

trader 存在 → trader_status=created → 进入验证中 / 赛马段

已推进分区 · 列表徽章：

backtest_status	trader_status	行末显示
pending	not_required	🔄 回测中
pass	awaiting	🟢 回测通过 ⚙ 待建 trader
pass	created	🟢 回测通过 ✓ 已进入验证
fail	not_required	🔴 回测失败 [豁免][放弃]
unresolved	not_required	⚪ 回测待定 [豁免]
skipped	awaiting	⏭ 已跳过 ⚙ 待建 trader
skipped	created	⏭ 已跳过 ✓ 已进入验证

候选侧栏 · 验证进度时间线（tm_decision_status=admitted 时替换底部操作区）：

接口：GET /api/raceboard/candidate/:id/validation-progress（侧栏展开时 30s 轮询）
展示：已推进 → 回测中/完成（胜率·回撤·样本）→ 待建 trader → 进入验证中
fail 路径：提供「豁免进入实盘」「放弃该候选」操作（豁免写入 ops 日志）

设计原则：

回测提交失败不阻断推进：仍写 admitted，backtest_status=pending，定时重试
回测 fail 不强制阻断：运营可豁免进入
R3 写回失败不阻断操作流程：本地 pending，密钥就绪后补写

工程落地（2026-07-01 · trading-matrix main @ b7367fe）：

模块	状态
列表/详情/推进·观察·暂缓/RBAC	✅ DEV-01~05
验证状态机 + event-backtest + validation-progress + 列表徽章	✅ DEV-07 主体
KOL Drawer Layer 0 回测基线	⏳ DEV-07 剩余
Event 漏斗游标日聚合	⏳ DEV-06
DH lifecycle 反向通知 banner	⏳ 未做
7 天逾期 banner 文案 +「标记已创建」	🟡 统计已接，UI 待完

4.1.x DH lifecycle 反向通知

"标记观察"和"已暂缓"的候选在 DH 端 lifecycle_status 发生变化时（如 conflicted → active、stale → active），需要主动提示运营重新评估，避免错过窗口。

项	实现
触发条件	已处理分区（标记观察 / 已暂缓）的候选近 24h 内 DH `lifecycle_status` 有变化
通知形式	候选段顶部「DH 状态变化通知」banner，列出变化的 KOL 及新旧状态
去重策略	同一 KOL 的同一变化在 24h 内仅推送一次，避免刷屏
行级标识	变化的候选行末显示「⟳ 状态已变化」可点击图标 → 重新打开详情侧边栏

┌─ DH 状态变化通知（近24h）──────────────────────────────────────────────┐
│  ⟳ 3 个已处理候选的 DH 状态发生变化：                                    │
│      · Gamma Z   conflicted → active   建议重评                          │
│      · Omega P   stale → active        建议重评                          │
│      · Beta Y    active → conflicted   建议复核观察决策                  │
│                                                              [全部查看]   │
└──────────────────────────────────────────────────────────────────────────┘

4.1.x 候选阵容互补性提示（P2）

避免运营推进同质化 KOL，造成赛马阵容风格集中。判定规则：

与现有 TM 验证中 / TM 赛马中 KOL 集合的策略风格 Jaccard 重合度 > 0.6 → 详情侧边栏顶部展示「⚠ 阵容相似度高」提示
提示文案：「当前阵容已有 N 个相似风格 KOL（突破型 · 短线），建议优先推进互补风格的候选」
不阻止推进，仅作为运营参考

运营 SOP 速查（候选管理 · 周节奏）

D1 决策：候选段按周处理，避免日级频繁切换。

【周一 10:00 - 12:00 · 候选评审会】
1. 进入候选段，先看顶部 "DH 状态变化通知" banner + "复查到期提醒" banner
2. 处理「已处理」分区中状态变化的候选（⟳ 标记），按需重评
3. 处理「待决策」分区中「推荐推进」标签的候选：
     a. 点击「查看详情」→ 看 DH 画像 + 不适合原因 + 阵容互补提示
     b. 决策动作三选一：推进验证 / 标记观察 / 暂不接入
     c. 填写理由（推进/暂缓必填，观察可选）
     d. 确认提交后等待 R3 写回 accepted=true
4. 当周所有推进的候选记下 kol_id 列表，会后在 TM 配置中心手动创建 trader 配置
5. 检查「⚠ N 个候选超过 7 天未创建 trader」banner，处理逾期项

【周五 15:00 · 候选段周度复盘】
1. 查看本周「已处理」分区，确认 R3 写回均成功
2. 查看本周推进的 trader 创建情况（4.1.x 闭环表），确认转化率
3. 在 §4.6 决策日志中追加本周决策摘要 + 下周复查计划

4.2 TM验证中：画像对齐卡

目标

当 KOL 进入 TM 验证阶段后，展示"期望行为（DH画像）vs 实际观测（TM执行）"的对比，帮助 PM 及早发现验证配置与信源特征不匹配的问题。

画像对齐卡位置

在 KOL Drawer 的"当周健康"区下方新增"画像对齐"折叠卡，默认展开。

对齐卡内容

┌─ 画像对齐（DH 期望 vs TM 实际）────────────────────────────────────────┐
│                                                                          │
│  维度          DH 画像期望               TM 实际观测      对齐          │
│  ──────────────────────────────────────────────────────────────────── │
│  持仓风格      短线（短线偏好）          avg 持仓 42min   ✓ 吻合         │
│  主要标的      BTC / ETH                 BTC 78% ETH 22%  ✓ 吻合        │
│  方向偏好      多偏多（83% 多）          多单胜率 61%     ✓ 方向一致     │
│  活跃度        高频                      周均 34 条信号   ✓ 正常         │
│  策略风格      突破 / 趋势跟随           close_reason:    ⚠ 待积累        │
│                                          trend 41%                      │
│                                          reversal 38%                   │
│                                                                          │
│  整体对齐评估：基本一致，持仓与标的符合预期；策略风格分布还需更多样本    │
└─────────────────────────────────────────────────────────────────────────┘

对齐图标说明：✓ 吻合  ⚠ 轻微偏离  ✕ 明显不符

对齐判断规则

维度	吻合条件	偏离警示条件
持仓风格	`avg_hold_min` 与 `holding_period` 描述一致（短线<120min，中线120-1440min）	实际持仓时长与画像描述差异 >2×
方向偏好	DH `direction_distribution` 多方向 > 60%，且 TM 多单胜率 > 空单胜率	方向完全相反
活跃度	周均信号量与 `activity_level` 描述对应（高频 >20条/周）	实际量与预期差距 >50%
主要标的	TM 实际成交标的 Top2 与 DH `symbols` 有重叠	主力标的完全不在 DH `symbols` 列表内

方向预检（进入验证时）

当 KOL 首次从 DH候选进入 TM验证中时，触发一次性方向预检通知：

┌─ 方向预检提示 ──────────────────────────────────────────────────────────┐
│                                                                          │
│  KOL「Alpha X」的 DH 画像显示：近期 ETH 方向偏多（多空比 83:17）         │
│                                                                          │
│  建议验证配置参考：                                                       │
│  · 多单信号置信度阈值可适当低于空单（偏多信源，多单更可信）               │
│  · 重点关注多单执行质量，空单作为对冲辅助                                 │
│                                                                          │
│  （这是参考建议，最终配置由运营确认）                        [知道了]     │
└─────────────────────────────────────────────────────────────────────────┘

4.3 TM赛马中：排行榜新增画像一致性维度

4.3.1 新增列：风格漂移（Style Drift）

数据来源：R3 写回字段 realized_style_drift（TM 回测后写入 DH，范围 0-1，越低越一致）

列展示规则：

drift 值	显示颜色	含义标签
< 0.15	绿色	高度一致
0.15 - 0.30	黄色	轻度漂移
> 0.30	红色	明显漂移
无数据	灰色 `—`	尚未有 R3 写回记录

排行榜列扩展预览：

┌─ TM 赛马排行榜 ─────────────────────────────────────────────────────────────────────────────────────┐
│  时间范围：[累计] [近7D]   策略：[全部 ▼]   风格：[全部 ▼]   排序：综合分↓                           │
│                                                                                                      │
│  排名  KOL名称    综合分  收益率  胜率   最大回撤  盈亏比  稳定性   持仓周期  超额收益  风格漂移       │
│  ────  ─────────  ──────  ──────  ─────  ────────  ──────  ───────  ────────  ────────  ──────────  │
│  #1   峰哥        87.3    +8.2%   64%    -3.1%     2.4     1.21     38min     +2.1%    0.08 ●       │
│  #2   信号王      81.5    +6.9%   58%    -4.7%     1.9     0.98     55min     +0.8%    0.19 ●       │
│  #3   趋势达人    76.2    +5.1%   61%    -2.8%     2.1     1.05     102min    -1.2%    0.34 ⚠       │
│  #4   Alpha短线   71.8    +4.3%   55%    -5.2%     1.7     0.87     28min     +0.1%    —            │
│                                                                                                      │
│  ● 高度一致（drift<0.15）  ● 轻度漂移（0.15-0.30）  ⚠ 明显漂移（>0.30）  — 待积累                  │
└─────────────────────────────────────────────────────────────────────────────────────────────────────┘

列标题 Tooltip：
「风格漂移：TM 实际执行与 DH 画像描述的一致性。漂移越低，信源行为与画像越一致。高漂移在 §4.6 决策日志中标注，由 DH 静态画像团队按周/月评估。」

drift 趋势 spark line（新增）：

drift 单点值容易被阶段性波动误导，列内追加最近 3 次回测的趋势：

排名  KOL名称   ...  风格漂移
#1   峰哥       ...  0.08 ●   ▁▂▁    （稳定低位）
#2   信号王     ...  0.19 ●   ▂▃▄    （略升趋势，需关注）
#3   趋势达人   ...  0.34 ⚠   ▂▄▆    （持续走高，建议复核）

趋势取最近 3 次 R3 写回的 drift 值，按时间顺序绘制 spark line
单值悬浮 tooltip：「最近 3 次回测 drift：0.18 / 0.24 / 0.34（按时间倒序）」
趋势比单点更能反映"是临时波动还是持续偏离"

4.3.2 策略风格过滤升级（二维）

现状：单维过滤（default / altcoin / mixed / highfreq），来自 trader_name 解析。

升级后：双维过滤，第二维来自 DH style_profile。

┌─ 过滤器区域 ────────────────────────────────────────────────────────────┐
│                                                                          │
│  市场类型：[全部 ▼]              策略风格：[全部 ▼]                      │
│  · 全部                          · 全部                                  │
│  · BTC主导（default）            · 突破型                                │
│  · 山寨主导（altcoin）           · 趋势跟随                              │
│  · 混合（mixed）                 · 回调低吸                              │
│  · 高频（highfreq）              · 消息面驱动                            │
│                                  · 技术结构                              │
│  持仓偏好：[全部 ▼]                                                      │
│  · 全部                                                                  │
│  · 短线（<2小时）                                                        │
│  · 中线（2-24小时）                                                      │
│  · 长线（>24小时）                                                       │
└─────────────────────────────────────────────────────────────────────────┘

二维过滤的业务价值：

按风格比较：同是"突破型"的 KOL 横向比较，比混排更公平
按持仓比较：高频短线与中长线不应在同一排行榜竞争稳定性指标
Phase 3 Alpha 剥离的前置：按持仓周期分组是条件化指标的基础

4.3.3 画像新鲜度提示

在排行榜 KOL 行尾，如果 DH 画像超过 30 天未更新，展示小图标提示：

  #2   信号王   81.5   +6.9%   58%   ...   ⏰ 画像已 35 天未更新

悬浮展开：「DH 画像上次分析于 35 天前。KOL 长期行为可能已发生变化，建议结合近期动态画像判断。」

4.3.4 单 KOL Event 漏斗（operator / admin 可见）

D2 决策落地。本节定义单 KOL 信号质量的可视化漏斗，是 §13.2 单 KOL 信号质量 KPI 在产品上的呈现位置。

漏斗位置

在 已有 trader（kol.trader_id > 0）的 KOL Drawer 中新增「Event 漏斗」折叠区，位于"当周健康"区下方。点击 KOL 行展开 Drawer 时默认展开本区。

实现说明（2026-07-01）：候选池侧栏详情不含 Event 漏斗；DEV-06 API/组件已就绪，展示入口绑定赛马/验证段 Drawer。候选段早期决策依赖 Layer 0 回测基线（§4.3.5）与验证进度时间线（§4.1.y）。

漏斗结构（5 口径）

┌─ Event 漏斗（峰哥 · 近30天）  [时间窗口: 7天 | 30天▼ | 90天 | 全周期]──────┐
│                                                                            │
│  原始信号           ████████████████████████████  142 条                    │
│      ↓  AI 采纳率 73%                                                       │
│  AI 决策 open       █████████████████████░░░░░░░  104 条                    │
│      ↓  报单成功率 84%                                                      │
│  实际开仓           ██████████████████░░░░░░░░░░   87 条                    │
│      ↓  执行胜率 64%                                                        │
│  盈利 position      ███████████░░░░░░░░░░░░░░░░░   56 条                    │
│                                                                            │
│  端到端命中率：39.4%   ← 142 条原始信号最终 56 条赚钱                       │
│  信号方向准确率：68%   ← 不论 TM 执不执行，方向本身预测准确率（4h K线判定） │
│  平均单 event 盈亏：+0.42%                                                  │
│                                                                            │
│  对比同风格 KOL 中位数：端到端 31% · 方向 62%        [✓ 高于中位数]        │
└────────────────────────────────────────────────────────────────────────────┘

5 个口径定义

口径	公式	数据来源
信号方向准确率	方向预测正确的 event / KOL 原始 event 总数	DH 原始 event（待 D5 接口）+ TM K 线价格库
信号采纳率	AI 决策 open 的 event / KOL 原始 event 总数	TM event_log + DH event 计数
报单成功率	executed_open / (triggered + rejected)	TM decisions（沿用现有"周报单率"口径）
执行胜率	盈利 position / executed_open	TM position（沿用现有"胜率"口径）
端到端命中率	盈利 position / KOL 原始 event 总数	TM position + DH event 计数

方向准确率判定逻辑（D3 落地）

基准：以 event.ts 对应 K 线收盘价 P0 为基准
比对：4 小时后 K 线收盘价 P1
命中条件：(P1 − P0) 方向与 event.direction 一致（多 → 上涨；空 → 下跌）
例外处理：中性方向（无明确多空）不计入分子分母；event 时间窗口跨越无交易时段（如周末）顺延至下一个 4h K 线收盘

时间窗口选择器

默认近 30 天；可切换 7 天 / 30 天 / 90 天 / 全周期。切换时所有 5 个口径同步重新计算（基于 TM 本地聚合表）。

同风格 KOL 横向对比

取 §4.3.2 "策略风格 + 持仓偏好"二维过滤下的 KOL 集合中位数作为参照基准。

高于中位数 → 绿色 [✓ 高于中位数]
接近中位数（±5%） → 灰色 [≈ 与中位数相当]
低于中位数 → 黄色 [↓ 低于中位数]

计算与存储职责（D4 落地）

项	说明
计算端	TM 后端
数据输入	DH 原始 event 列表（待 D5 接口确认）+ TM event_log / decisions / position + TM K 线价格库
存储	TM 本地聚合表（建议 `tm_kol_event_funnel_daily`，按 KOL × 日期 × 时间窗口聚合）
写回 DH？	不写回。本漏斗所有指标完全在 TM 内部消费，DH 不感知（§〇.3 回路 B 原则）
刷新频率	每日凌晨 02:00 重算前一天；展示时实时聚合可选窗口

在排行榜（§4.3.1）中的延伸

排行榜新增「端到端命中率」列（P2，置于"风格漂移"列右侧）：

排名  KOL名称   综合分  收益率  胜率   ...  风格漂移   端到端命中率
#1   峰哥      87.3    +8.2%   64%   ...  0.08 ●      39.4% ●
#2   信号王    81.5    +6.9%   58%   ...  0.19 ●      28.1% ⚠
#3   趋势达人  76.2    +5.1%   61%   ...  0.34 ⚠      —（样本不足）

列标题 tooltip：「端到端命中率：KOL 原始信号最终转化为盈利的比例（仅 TM 内部参考指标，不构成对 KOL 信号源的官方评估）。」

与现有「胜率」列并存，tooltip 中说明差异：「胜率（成交后赚钱概率）」vs「端到端命中率（信号到利润的整体转化率）」。

新增 W7：信号质量异常预警

属性	内容
ID	W7
触发条件	端到端命中率 < 25% 或方向准确率 < 50%；且样本（原始 event）≥ 30 条
徽章文案	信号质量异常
展示位置	KOL 行预警列 + Drawer 头部 + Event 漏斗顶部
建议操作	进入 §4.6 决策日志记录处置；考虑暂停或降级
是否通知 DH	不通知（W7 仅 TM 内部预警，符合 §〇.3 回路 B 原则）
与其他预警关系	可与 W1/W2/W6 并存；§4.5 优先级排序中位列第 4

样本量门槛

原始 event < 30 条 → 整个漏斗显示「样本不足，需积累更多 event」，所有比率不计算
原始 event ≥ 30 但 < 100 → 漏斗正常显示，但顶部标注「样本量偏少，结论仅供参考」

4.3.5 回测基线层（Layer 0）（operator / admin 可见）

对应 v1.2 修订计划 R13。填补 Event 漏斗样本不足阶段的量化依据；与 §4.1.y 验证状态机衔接。

三层漏斗架构（§4.3 引言）

Layer 0  回测基线（批量 event-backtest / signal_quality）  ← 候选推进时触发
    ↓
Layer 1  实盘 Event 漏斗 5 口径（§4.3.4，需 trader）
    ↓
Layer 2  排行榜实盘结果（§4.3.1）

4.3.5.1 触发与集成

触发：运营 admit + backtest_phase=run_backtest（§4.1）
执行：复用 TM 已有 /api/event-backtest 批量任务（非独立微服务）；callback POST /api/raceboard/internal/backtest/result（内网，X-Internal-Token）
存储：tm_kol_backtest_result（kol_id × backtest_window 唯一）
R3 写回：样本 ≥10 且结论 pass/fail → feedback_type=candidate_backtest_result

4.3.5.2 回测窗口与判定

end   = last_evidence_at（DH，Unix 秒）；为 0 则用当前时间
start = end - 12 个月
clamp 到 [2025-06-01, 2026-06-30]（R4 小批量验证数据范围）

validation_status	条件（与 §4.8.4 对齐）
pass	`win_rate ≥ 0.55` 且 `max_drawdown < 0.20` 且 `sample_trade_count ≥ 10`
fail	`win_rate < 0.45` 或 `max_drawdown ≥ 0.20`（样本 ≥ 10）
unresolved	样本 < 10 或指标介于 pass/fail 之间

4.3.5.3 KOL Drawer 展示（待 DEV-07 收尾）

在 Event 漏斗（§4.3.4）上方新增「回测基线」折叠区；接口 GET /api/raceboard/kol/:id/backtest。

┌─ 回测基线（2025-06-01..2026-06-30 · 187条）────────────── [🟢 pass] ──────┐
│  回测胜率 61% · 最大回撤 12% · 策略漂移 0.18（未实现前可显示 —）            │
│  Layer 1 有数据时展示「回测 → 实盘」对比箭头                                │
└────────────────────────────────────────────────────────────────────────────┘

4.3.5.4 与 §13.2 健康度对接

阶段	健康度参考
实盘 event < 30	以 Layer 0 回测 win_rate / max_drawdown 为临时参考，标注「实盘数据不足」
实盘 event ≥ 30	以 Layer 1 为主，Layer 0 作历史基准对比

4.3.5.5 P2 · 回测 pass/fail 入场门控

暂不强制。启用后进入 TM 赛马中须 Layer 0 pass 或运营豁免（决策日志 + effect_review_at）。

运营 SOP 速查（赛马排行榜 · 周节奏）

【周一 13:00 · 排行榜健康检查】
1. 排行榜按"综合分"默认排序，扫一眼 Top10 与 Bottom5
2. 关注"风格漂移"趋势 spark line：上升趋势的 KOL → 进入 §4.7 一致性面板深查
3. 关注"端到端命中率"列：低于同风格中位数 10pp 以上的 → 点击 Drawer 看 §4.3.4 漏斗
4. 处理预警徽章（W2 / W6 / W7 联动）

【周五 14:30 · 单 KOL 深度复盘（每周选 2-3 个 KOL）】
1. 优先选：本周新触发预警的 KOL / drift 上升趋势的 KOL / 端到端命中率突降的 KOL
2. 进入 Drawer 打开 §4.3.4 Event 漏斗
3. 看哪一层转化率最差，识别瓶颈：
     - AI 采纳率低 → 排查 prompt 解析规则
     - 报单成功率低 → 排查 RuleEngine 拒绝原因
     - 执行胜率低 → 排查市场环境匹配度
     - 方向准确率低（不论执行） → 信源本身质量问题，进入 §4.6 处置
4. 处置决策写入 §4.6 决策日志

4.4 KOL Drawer 升级：DH 画像摘要区

位置

新增第六区，位于"决策日志"下方，折叠态展示，可点击展开。

展示内容

┌─ Drawer 右侧面板（点击 KOL 行后展开）────────────────────────────────────┐
│                                                                          │
│  【一】身份                                                               │
│  峰哥  [A] initial_eval  ▰▰▰▱▱ 5/10  还差 5 条                          │
│                                                                          │
│  【二】进度                                                               │
│  （进度条）                                                               │
│                                                                          │
│  【三】当周健康                                                            │
│  报单率 54%  执行开仓 87  触发 120  拒绝 45                               │
│                                                                          │
│  【四】历史表现                                                            │
│  胜率 —（样本不足）  avg持仓 42min                                        │
│                                                                          │
│  【五】决策日志                                                            │
│  2026-05-20 · 暂停 · API 429 故障期，数据不可信                          │
│                                                                          │
│  【六】DH 画像摘要  ▼                     （新增区域）                     │
│  ┌────────────────────────────────────────────────────────────────────┐ │
│  │  静态画像                               动态状态（实时）            │ │
│  │  ─────────────────────────────────────────────────────────────── │ │
│  │  角色：混合型 · 高频 · 短线 · 合约      当前状态：● active          │ │
│  │  擅长标的：BTC / ETH / SOL             证据状态：aligned            │ │
│  │  策略风格：突破 · 回调低吸             证据数量：36 条（rich）       │ │
│  │  决策驱动：技术结构 + 情绪盘口         近期方向：多 83% · 空 17%    │ │
│  │  评级：B                               画像更新：2 小时前            │ │
│  │                                         证据更新：40 分钟前           │ │
│  │  ─────────────────────────────────────────────────────────────── │ │
│  │  候选状态：[action] 可推进验证                                     │ │
│  │  验证协议：TM 可按 kol_id/标的/时间维度批量验证；                   │ │
│  │           验证结果不得改写 DH 的可信度排序                          │ │
│  └────────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────┘

异常状态展示

当 lifecycle_status 为 conflicted 或 stale 时，状态区颜色变化并增加说明：

│  当前状态：⚠ conflicted                                                  │
│  DH 说明：信源近期 ETH 多空信号矛盾（多 52% 空 48%），建议等待方向确认   │
│  不适合原因：信源方向自相矛盾 · 证据冲突                                 │

4.5 预警体系增强

4.5.1 W3 改进：双源沉默判断

现状：W3 仅依赖 TM event_log.triggered = 0，无法区分"信源本身停发"和"AI 过滤率高导致信号未到 TM"。

升级方案：增加 DH 侧校验。

W3 触发逻辑（升级后）：

情况 A（信源沉默）：
  条件：DH last_evidence_at > 14天 AND TM triggered = 0 连续 2 周
  文案：「信源沉默」· 建议：检查 KOL 是否停止发布内容
  置信度：高

情况 B（AI 过滤率高）：
  条件：DH last_evidence_at ≤ 7天（信源仍在活跃发布）
         AND TM triggered = 0 连续 2 周
  文案：「信号未触达 TM」· 建议：检查 prompt 解析或 DH→TM 信息流链路
  置信度：高

情况 C（数据不足，原有行为）：
  条件：无法获取 DH last_evidence_at 数据
  文案：「疑似沉默」· 原有逻辑保留

业务价值：情况 A 和 B 的运营动作完全不同。A 需要联系信源侧，B 需要排查 TM 技术链路。混在一起不仅误导 PM，还浪费排查时间。

4.5.2 新增 W5：信源状态异常预警

属性	内容
ID	W5
触发条件	DH `lifecycle_status` = `conflicted` 且持续 > 3 天
徽章文案	信源观点冲突
展示位置	KOL 行预警列 + Drawer 头部
建议操作文案	「信源近期多空信号矛盾，建议暂停新增赛马判断，等 DH 状态恢复 active 后继续。」
与已有预警关系	可与 W1/W2 同时存在，独立显示

┌─ W5 预警卡片（Drawer 头部展示）─────────────────────────────────────────┐
│  ⚠  信源观点冲突 （DH 动态画像 · 2026-06-21 起）                         │
│                                                                          │
│  信源近期 ETH 多空信号矛盾：近 24 条证据中，多方向 52%，空方向 48%，     │
│  DH 判断为 conflicted 状态。                                              │
│                                                                          │
│  建议：暂缓依赖本 KOL 的新信号做赛马决策；等待 DH 状态恢复 active。      │
│  已持续：3 天                                                  [记录处置] │
└─────────────────────────────────────────────────────────────────────────┘

4.5.3 新增 W6：风格漂移预警

属性	内容
ID	W6
触发条件	R3 写回 `realized_style_drift` > 0.30
徽章文案	画像偏离
展示位置	仅在 TM赛马中段有效
建议操作文案	「TM 实际执行结果与 DH 画像描述存在明显偏离。建议复核 TM 端 prompt 解析规则；在 §4.6 决策日志中标注 drift 异常，由 DH 静态画像团队按周/月批量评估是否需要画像迭代。」
是否通知 DH	不通过 W6 主动通知 DH；R3 写回的 drift 已作为外部证据进入 DH 工作台，由 DH 静态画像团队消费

4.5.4 预警优先级排序规则

多个预警同时存在时，按以下优先级排序展示徽章（高优在前）：

W5（信源观点冲突） > W3（信源沉默/未触达） > W2（胜率偏低） > W6（画像偏离） > W7（信号质量异常） > W1（其他基础预警）

判定依据：

W5 信源本身有问题，影响后续所有判断 → 最高优
W3 信号链路问题，影响所有指标可靠性 → 次高优
W2 / W6 / W7 偏向"已有数据看出问题"，按运营动作可逆性排序
同优先级多预警 → 按触发时间倒序

排行榜行预警列最多显示 2 个徽章，其余在 Drawer 头部完整展示。

运营 SOP 速查（预警处置 · 周节奏）

【周一 14:00 · 预警批处理 / 周三 14:00 · 预警批处理（每周两次）】
1. 进入排行榜，按"预警数倒序"看本批新增预警的 KOL
2. 优先处理 W5 / W3（信源端问题，需通报相关方）
     a. W5 → 暂缓依赖本 KOL 的赛马决策，记录处置 + 设 next_review
     b. W3 情况A（信源沉默）→ 联系 DH 静态画像团队确认信源状态；W3 情况B（信号未触达）→ 报 TM 工程排查 prompt
3. 处理 W2 / W6 / W7（TM 内部指标问题）
     a. W2 → 进入 §4.3.4 Event 漏斗诊断瓶颈层
     b. W6 → 在 §4.7 一致性面板看维度偏离 → 在 §4.6 决策日志标注
     c. W7 → 看是端到端命中率低还是方向准确率低；前者排查 prompt/执行，后者考虑暂停
4. 所有处置在 §4.6 决策日志中记录 + 设 effect_review_at

4.6 运营决策日志增强

新增：决策上下文快照

在 PM 点击「记录处置」时，自动填入当时的 DH 画像状态作为只读上下文，保存在决策日志中。

决策日志 Schema 扩展：

{
  "at": "2026-06-23T14:00:00+08:00",
  "by": "pm",
  "trigger": "signal_silent",
  "decision": "paused",
  "rationale": "信源已停止发布内容，等恢复后重评",
  "next_review": "2026-07-07",
  "effect_review_at": "2026-07-07T10:00:00+08:00",
  "dh_context_snapshot": {
    "lifecycle_status": "stale",
    "last_evidence_at": "2026-06-10T07:00:00Z",
    "candidate_type": "observe",
    "data_sufficiency": "sparse",
    "note": "DH 画像状态，决策时自动记录，只读"
  }
}

字段说明：

字段	含义
`next_review`	下一次主动复查时间（运营手工填写或系统按预警类型默认填充）
`effect_review_at`	决策效果回看提醒（默认处置后 14 天）。到期当天日历提醒运营进入 §4.7 / §4.3.4 检查该 KOL 在处置后是否改善
`dh_context_snapshot`	决策当时的 DH 状态快照，只读

业务价值：

dh_context_snapshot：3 个月后回看当时的处置决策时，可以看到当时 DH 的状态，理解决策依据的完整背景，而不只是 TM 的数字
effect_review_at：闭合"处置 → 效果"环路。每个处置决策都强制配一次效果复盘，避免决策后无人追踪、问题反复出现

运营 SOP 速查（决策日志 · 周节奏）

【每次处置时（即时）】
1. 在 KOL Drawer 中点击「记录处置」
2. 系统自动注入 dh_context_snapshot（只读）
3. 填写 trigger / decision / rationale（必填）
4. 设 next_review（默认 7 天）和 effect_review_at（默认 14 天）
5. 提交

【周五 16:00 · 决策效果回看（按 effect_review_at 提醒触发）】
1. 系统弹出本周到期的 effect_review_at 列表
2. 对每个待回看决策：
     a. 对比处置前后该 KOL 的 §4.3 排行榜指标 + §4.3.4 漏斗
     b. 在原决策日志条目追加 effect_summary（改善 / 无变化 / 恶化）
     c. 决策"恶化"且当时是"暂停" → 维持；当时是"观察" → 升级为暂停
3. 月度汇总：每月最后一周，统计本月所有处置的 effect 分布，作为 §13.1 KPI 输入

4.7 画像质量追踪面板（operator / admin 可见）

副标题：TM 内部参考视图（不构成对 DH 画像的官方评估）

概述

随着 R3 写回数据积累，赛马看板新增一个「DH-TM 一致性」标签页，展示 DH 画像与 TM 实际执行结果之间的一致性追踪。

面板定位：本面板是 TM 用于内部决策的辅助参考工具。DH 画像的正式评估责任由 DH 静态画像团队按周/月承担（参见 §6.2 跨团队配合矩阵）。

位置：排行榜顶部标签页 → 新增「DH-TM 一致性」Tab（viewer 不可见）。

面板内容

┌─ DH-TM 画像一致性（TM 内部参考视图）─────────────────────────────────────┐
│  更新时间：2026-06-23  数据基于：已完成 R3 回测的 KOL                    │
│                                                                          │
│  全局指标                                                                 │
│  ┌──────────────────┬─────────────────┬───────────────────────────────┐ │
│  │  平均风格漂移     │  方向一致率      │  画像有效 KOL 占比             │ │
│  │  0.18            │  71%            │  7 / 10                        │ │
│  │  轻度漂移        │  多空方向与实     │  drift < 0.30                  │ │
│  │                  │  际盈亏方向一致  │                                │ │
│  └──────────────────┴─────────────────┴───────────────────────────────┘ │
│                                                                          │
│  各 KOL 详细一致性                                                        │
│  KOL名称      风格漂移   方向一致   持仓一致   TM 端评估                  │
│  ─────────────────────────────────────────────────────────────────────  │
│  峰哥          0.08 ●    ✓ 是       ✓ 是       高度一致                  │
│  信号王        0.19 ●    ✓ 是       ✓ 是       基本一致                  │
│  趋势达人      0.34 ⚠    ✗ 否       ✓ 是       TM 端待复核                │
│  Alpha短线     —         —         —          等待 R3 写回数据           │
└─────────────────────────────────────────────────────────────────────────┘

● 良好（<0.15）  ● 可接受（0.15-0.30）  ⚠ 偏高（>0.30）

数据来源

指标	计算方式
风格漂移	R3 写回 `realized_style_drift` 最新值（计算契约见 §4.8.2）
方向一致率	DH `direction_distribution` 主方向 vs TM 同方向胜率对比（多方向占比高 → 多单胜率应高于空单胜率）
持仓一致率	DH `holding_period` 文字描述 vs TM `avg_hold_min`（短线 < 120min，中线 120-1440min，长线 > 1440min）

TM 端评估判定阈值

「TM 端评估」列基于三个一致性维度（风格漂移 / 方向一致 / 持仓一致）的三票判定：

评估结果	判定条件
高度一致	三项全通过（drift < 0.15 + 方向一致 + 持仓一致）
基本一致	两项通过
TM 端待复核	一项或全部不通过；TM 内部触发复核流程；不直接通知 DH
等待 R3 写回数据	sample_trade_count < 10，drift 未计算

判定边界：本评估仅作为 TM 用于内部决策（如调整 prompt、调整验证参数）的辅助参考。判定结果「TM 端待复核」不等于 "DH 画像有问题"——DH 画像的正式评估责任在 DH 静态画像团队，TM 端的偏离可能源于 prompt 解析、市场环境变化、样本偏差等多种原因。

运营 SOP 速查（一致性面板 · 周节奏）

【周五 15:30 · 一致性周度复盘】
1. 进入 DH-TM 一致性 Tab，先看全局指标卡片
     a. 平均风格漂移 > 0.25  → 进入"各 KOL 详细一致性"表，按 drift 倒序
     b. 画像有效 KOL 占比 < 70%  → 标记本周为"画像质量偏差周"，加入 §4.6 决策日志
2. 对 TM 端待复核 KOL：
     a. 进入对应 KOL Drawer，对照 §4.3.4 Event 漏斗找瓶颈层
     b. 在 §4.6 决策日志中标注 drift 异常 + 复核结论
     c. 设置 effect_review_at = T + 14天
3. 每月最后一周 → 把"TM 端待复核"列表批量导出 → 转发给 DH 静态画像团队作为月度评估输入

4.8 验证结果回流（RF 飞轮验证环闭合）

4.8.1 目的

补齐 RF 飞轮"下半圈"：TM 在回测/实盘验证完成后，把综合一致性结果通过 R3 写回 DH 作为外部证据。本节定义计算契约、写回触发器、字段映射以及写回边界——明确哪些指标写回 DH、哪些只在 TM 内部消费。

4.8.2 realized_style_drift 计算契约

由 TM 后端在回测 job 完成 / 实盘验证周期结束时计算，公式与 §4.7 画像质量面板维度统一：

realized_style_drift = 0.4 × (1 − 持仓一致度)
                     + 0.4 × (1 − 方向一致度)
                     + 0.2 × (1 − 标的一致度)

取值范围：0.00（完全一致）~ 1.00（完全偏离）

各维度一致度定义：

维度	一致度定义
持仓一致度	实际 `avg_hold_min` 落入 DH `holding_period` 对应区间则为 1.0；偏离 1 档为 0.5；偏离 2 档为 0.0
方向一致度	DH `direction_distribution` 主方向胜率 ≥ 反方向胜率为 1.0；持平为 0.5；反向为 0.0
标的一致度	TM 实际成交标的 Top2 与 DH `symbols` 列表的 Jaccard 系数

最小样本量门槛：sample_trade_count ≥ 10 才计算 drift；不足时写回 validation_status=received 但 realized_style_drift 字段留空。

4.8.3 新增 R3 写回类型：验证阶段结果（`candidate_*_result`）

属性	内容
`feedback_type`	批量回测：`candidate_backtest_result`；模拟/纸面/实盘：`candidate_simulation_result` / `candidate_paper_result` / `candidate_live_review_result`（按阶段）
触发时机	批量回测 callback（§4.3.5）/ 实盘验证周期结束（默认按周）
`validation_phase`	`backtest` / `simulation` / `paper` / `live_review`（按实际阶段填写）
`validation_status`	`pass` / `fail` / `unresolved`（详见 4.8.4 判定规则）
必填字段	`realized_style_drift`、`backtest_window`、`sample_trade_count`、`win_rate`、`max_drawdown`
可选字段	`profit_factor`、`expectancy`、`validation_result_summary`

4.8.4 pass / fail 判定规则

默认由 TM 验证流程基于阈值自动产出，运营不介入：

结论	判定条件（默认阈值，可在 trader 配置中调整）
pass	`win_rate ≥ 45%` AND `max_drawdown ≤ 15%` AND `sample_trade_count ≥ 30`
fail	`win_rate < 35%` OR `max_drawdown > 20%`（满足任一）
unresolved	不满足 pass 也不满足 fail，或 `sample_trade_count < 30` 长尾未完成

超时兜底：推进后 60 天仍无 validation_completed 写回 → 系统自动写一条 validation_status=fail，reject_reason=validation_timeout，确保飞轮 KPI 分母不会被长尾稀释。

4.8.5 写回边界（D4 决策落地）

类别	写回 DH？	说明
`realized_style_drift`（综合一致性）	✓ 写回	作为外部证据展示，DH 不依此自动调整画像
`validation_status` / `win_rate` / `max_drawdown` 等结果指标	✓ 写回	R3 反馈账本字段
Event 漏斗 5 口径（信号采纳率 / 报单成功率 / 执行胜率 / 端到端命中率 / 方向准确率）	✗ 不写回	TM 本地参考视图，避免污染 DH 画像独立性（参见 §〇.3 回路 B）
W7 信号质量异常预警	✗ 不写回	TM 内部预警，不通知 DH

写回字段的完整映射见 §十《TM→DH 写回映射》。

4.8.6 与 §4.7 画像质量面板的关系

§4.7 面板展示 R3 写回的 drift，但本身不发起写回；写回责任在 §4.8 定义的 TM 验证流程内自动触发。

五、非目标（本文明确不做）

修改 DH 画像数据的权重或排序规则（DH 侧数据只读展示）
基于 DH 画像自动调整 TM 验证参数（只做参考建议，人工确认）
画像数据驱动的自动升降级（运营决策仍由 PM 手动执行）
基于飞轮数据的 DH 画像自动重训（Phase 3 以后）；本期 §4.7 / §4.8 写回内容仅供 DH 静态画像团队按周/月人工评估，不会自动反推画像

六、业务前置条件与跨团队配合矩阵

本节把工程依赖升级为"业务前置条件 + 跨团队配合矩阵"，覆盖业务流（§〇）中每个环节启动所需要的前置准备。"待确认"项不是问题，而是 PRD 评审通过后需要相应角色在 N 天内回复的明确登记。

6.1 业务前置条件清单（按业务流环节组织）

业务环节	前置条件	负责方	当前状态
② → ③ TM 拉取 DH 候选	TM 在 DH Provider 配置中心注册为 Open API Consumer	@DH Provider 配置中心管理员	待确认
③ ④ TM→DH R3 写回	DH 生产库存在 `dn_kol_candidate_validation_feedback` 表	@DB 权限成员	✓ 已完成
② → ③ TM 拉取 DH 候选	TM 持有有效 `X-API-Key` 且额度策略满足轮询频率（建议 5 min）	@DH maintainer	✅ 联调通过 · 生产全量分页 ⏳（page_size=100，~421 条）
⑤ TM 端 Event 漏斗	DH `event-stream` + `profile/signals` 可用	@DH maintainer	✅ 接口已上线 · DEV-06 游标日聚合 ⏳
③ ④ TM→DH R3 写回	TM 持有有效 `X-TM-Validation-Key`（DH 配置 `KolCandidateValidationFeedback.ApiKey`）	@DH maintainer	🚧 生产未注入 · Phase A 本地 pending 已支持
③ ④ TM→DH R3 写回	6 项 R3 冒烟测试全部通过（只读 / 写入 / 错误密钥 / 过期状态 / 重复写入 / 工作台回归）	@DH maintainer + @TM 工程	部分已通过：只读 ✓ · 写入 ✓ · 错误密钥 ✓ · 工作台回归 ✓；过期/重复待 TM 集成复测（R4 T5）
③ TM 候选段上线	候选池 Tab 从 DH `candidate-list` + `kol/list` 拉取	@TM 工程	✅ DEV-01~07 主体 · 赛马 roster 仍部分 kol_meta（R10）
① DH 画像迭代	DH 静态画像团队周/月评估周期承诺	@DH 静态画像负责人	待确认

6.2 跨团队配合矩阵

团队 / 角色	在本方案中的职责	关键交付物	当前状态
DH 静态画像负责人	提供画像语义边界与典型样本；按周/月评估 R3 外部证据并迭代画像	画像语义说明文档；§4.7 反馈闭环周期承诺	待确认
DH maintainer	DH Open API 可用性；R3 写回 6 项保护机制；密钥下发与轮换；原始 event 列表接口选型与上线（D5）	R3 冒烟测试通过；密钥治理流程文档；event 列表接口契约	进行中
DB 权限成员	执行迁移；确认表结构与索引；配合密钥配置；R4 结束后按需清理 smoke 记录	`dn_kol_candidate_validation_feedback` 表上线；密钥已配置	✓ 表已完成；密钥配置待闭环；待配合 R4 集成复测
DH Provider 配置中心管理员	把 TM 纳入"下游推送/TM"与"Open API Consumer"双身份治理	TM 已注册 + 额度策略	待确认
TM 工程	实现候选拉取、Drawer 升级、R3 写回 client、密钥轮换检测、运营管理界面、Event 漏斗本地计算与存储（§4.3.4）	第一层功能上线；密钥过期告警；Event 漏斗指标可用	进行中
TM 产品/运营	制定运营 SOP（周节奏）、复查节奏、决策日志规范、阵容互补判断	候选段周度运营 SOP；周度阵容复盘机制	待制定
合规	审阅 viewer 角色对外/对内的可见数据边界	viewer 角色合规审阅意见	待确认

6.3 待确认事项责任登记（评审通过后跟踪）

#	事项	Owner	期望回复期限
Q-D5	原始 event 列表接口形式三选一（新增 endpoint / 扩展 candidate-list / DH→TM 推送）	@DH maintainer	T+7 天
~~Q-DB~~	~~R3 反馈账本表的生产迁移窗口~~	@DB 权限成员	✓ 已完成：生产表已创建并通过 smoke 测试（2026-06-23）
Q-FTYPE	~~`feedback_type` 正式枚举~~	@DH maintainer	✅ 已关闭（2026-06-25 源码核实）：DH 白名单 6 值；运营决策用 `candidate_validation`，回测结果用 `candidate_backtest_result`；见 §10.2
Q-CSTATUS	~~DH 候选类型字段名~~	@DH maintainer	✅ 已关闭：动态类型读 `candidate_type`（`action/risk/observe`）；`candidate_status` 固定 `observe_only`，TM 忽略
Q-KEY	`X-TM-Validation-Key` 通过哪种渠道下发到 TM（secret manager / 环境变量 / 配置中心）	@DH Provider 配置中心管理员	T+5 天
Q-EVAL	DH 静态画像团队的评估周期（周 / 月 / 季度）	@DH 静态画像负责人	T+7 天
Q-VIEWER	viewer 角色对外/对内边界与合规口径	@合规	T+10 天

跟踪表实际维护建议放到协作工具（Linear / Notion）中，本节仅作为 PRD 内的产品级登记。

6.4 DH Open API 字段契约（R4 联调核实）

开发前须与 DH 源码对齐；完整类型见 raceboard_candidate_impl_plan.md DEV-01。

#	常见草稿写法	DH 实际行为
1	`feedback_type=candidate_admitted` 等	白名单仅 6 值；运营决策应写 `candidate_validation`
2	`candidate_status` 表示动态类型	`candidate_status` 固定 `observe_only`；动态值在 `candidate_type`
3	`direction_long` / `direction_short`	`direction_distribution: [{direction, count}]` 数组
4	响应容器 `contracts`	实际字段名 `list`（可能无 `{code,data}` 包装，需 direct JSON fallback）
5	R3 写回缺 `time_horizon` / `topic_scope`	DH 严格校验必填
6	`StateVersion` 为 int	实际 int64

鉴权两层：① 所有 /v1/open/* → X-API-Key；② 仅 candidate-validation/feedback → 额外 X-TM-Validation-Key。

七、分层交付建议

按业务流推进价值与依赖关系分三层，详细工作量与功能映射见 §十一。

八、用户权限配置（新增）

8.1 角色定义

赛马看板设三个角色，沿用 TM 现有 JWT 鉴权体系，在 TM 用户管理中配置。

角色	英文标识	业务身份与适用范围
普通用户	`viewer`	项目内部 stakeholder / 数据查阅角色（如团队成员、内部产品经理、数据分析师）。只读访问排行榜，无任何操作权限。不适用于外部投资者或合作方——对外展示的看板版本属另一个产品，超出本 PRD 范围。
运营人员	`operator`	全流程操作：候选管理、预警处置、决策记录、推进验证。
管理员	`admin`	等同运营人员 + 用户角色分配权限。

合规边界（待 @合规审阅）：viewer 简化 Drawer 中保留的"超额收益"等指标是否需要额外合规复核，详见 §十四开放问题 Q8。

8.2 权限矩阵

页面与模块可见性

模块	viewer	operator	admin
TM赛马中 · 排行榜（基础列）	✓ 可见	✓ 可见	✓ 可见
排行榜「风格漂移」列（§4.3.1）	✗	✓	✓
排行榜「端到端命中率」列（§4.3.4）	✗	✓	✓
TM验证中 · 进度段	✗ 不可见	✓ 可见	✓ 可见
DH候选段 · 候选管理	✗ 不可见	✓ 可见	✓ 可见
KOL Drawer（排行榜下钻）	✓ 简化版	✓ 完整版	✓ 完整版
Drawer 内「Event 漏斗」区（§4.3.4）	✗	✓	✓
DH-TM 一致性 Tab（§4.7）	✗	✓	✓
用户管理	✗	✗	✓

操作权限

操作	viewer	operator	admin
查看排行榜数据、指标、BTC基准	✓	✓	✓
切换时间范围（累计/近7D）	✓	✓	✓
使用策略风格过滤器	✓	✓	✓
查看 KOL Drawer（性能数据区）	✓	✓	✓
查看 KOL Drawer（DH画像摘要区）	✗	✓	✓
查看预警徽章（只读）	✗	✓	✓
处置预警 / 记录决策日志	✗	✓	✓
候选详情查看	✗	✓	✓
推进验证 / 标记观察 / 暂不接入	✗	✓	✓
TM→DH R3 写回	✗	✓（自动触发）	✓（自动触发）
分配用户角色	✗	✗	✓

8.3 导航与 UI 差异

viewer 看到的赛马看板

┌─ /raceboard ────────────────────────────────────────────────────────────┐
│                                                                          │
│  TM 赛马看板                                                              │
│                                                                          │
│  （无 Tab 切换，直接进入排行榜）                                           │
│                                                                          │
│  时间范围：[累计] [近7D]   策略：[全部▼]   风格：[全部▼]   排序：综合分↓  │
│                                                                          │
│  排名  KOL名称   综合分  收益率  胜率  最大回撤  盈亏比  稳定性  超额收益  │
│  #1   峰哥       87.3    +8.2%  64%   -3.1%     2.4    1.21    +2.1%    │
│  #2   信号王     81.5    +6.9%  58%   -4.7%     1.9    0.98    +0.8%    │
│  ...                                                                     │
│                                                                          │
│  （点击行可展开简化 Drawer：仅展示性能数据区，无画像摘要、无操作按钮）      │
└──────────────────────────────────────────────────────────────────────────┘

operator / admin 看到的赛马看板

┌─ /raceboard ────────────────────────────────────────────────────────────┐
│                                                                          │
│  TM 赛马看板                                       [用户管理] (仅admin)  │
│                                                                          │
│  [DH候选池]  [TM验证中]  [TM赛马中]    ← 三段 Tab 全部可见               │
│                                                                          │
│  （当前 Tab 内容 + 完整操作按钮 + 预警 + 决策日志）                       │
└──────────────────────────────────────────────────────────────────────────┘

viewer 的简化 Drawer

viewer 点击排行榜某 KOL 后，展开简化版 Drawer，仅显示：

┌─ KOL 详情（只读）─────────────────────────────────────────────────────── ×  │
│                                                                              │
│  峰哥  [A]  TM赛马中                                                          │
│                                                                              │
│  性能数据                                                                     │
│  ─────────────────────────────────────────────────────────────────────────  │
│  综合分   收益率    胜率    最大回撤   盈亏比   稳定性    avg持仓   超额收益   │
│  87.3    +8.2%     64%     -3.1%      2.4      1.21      38min     +2.1%    │
│                                                                              │
│  BTC基准同期：+6.1%   策略风格：default · 短线                               │
│                                                                              │
│  （不展示：DH画像摘要 · 预警徽章 · 决策日志 · 操作按钮）                      │
└──────────────────────────────────────────────────────────────────────────────┘

8.4 权限实现说明

鉴权方式：沿用 TM 现有 JWT 鉴权，在 JWT payload 中增加 raceboard_role 字段（viewer / operator / admin）
默认角色：新用户默认赋予 viewer，由管理员手动升级为 operator
前端权限门控：Tab 可见性、Drawer 区域显示、操作按钮渲染均在前端按 role 判断；后端同时对写入接口（ops/log、R3写回）做 role 校验，拒绝 viewer 的写请求
现有接口影响：GET /api/raceboard/snapshot 无鉴权保持不变（内网访问）；POST /api/raceboard/ops/log 和 R3 写回需增加 role 校验（operator 以上才可调用）

8.5 页脚公平性说明的权限

页脚公平性说明对所有角色均可见，不受权限控制。

九、候选状态机（新增）

9.1 候选在 TM 侧的状态流转

                        TM 候选管理 - 决策 + 验证子状态
                        ───────────────────────────────

             DH 候选池（首次读取）
                      │
                      ▼
              ┌───────────────┐
              │   待决策       │  pending / not_started / not_required
              └───────┬───────┘
                      │  运营操作
          ┌───────────┼───────────────┐
          │           │               │
          ▼           ▼               ▼
   ┌────────────┐ ┌──────────┐ ┌──────────────┐
   │  已推进验证 │ │ 标记观察  │ │  已暂缓      │
   │  + 回测/   │ │           │ │              │
   │  trader 子状态│ │ 设有复查  │ │ 设有重新     │
   └──────┬─────┘ └────┬──────┘ └──────┬───────┘
          │            │               │
          │  run_backtest → backtest pending → pass/fail
          │  skip_backtest → skipped → awaiting trader
          │  pass/skip → awaiting → created（检测到 trader）
          │            │               │
          │       到期复查              │ 到期重评
          │            │               │
          │            ▼               ▼
          │     ┌─────────────────────────┐
          │     │     重回「待决策」       │
          │     └─────────────────────────┘
          │
          ▼
    TM验证中 / TM赛马中（trader_status=created 后脱离候选管理）

9.2 状态说明

TM侧状态	触发方式	是否写回DH	DH写回内容
待决策	自动（DH拉取 → TM 候选包）	否	—
已推进验证	运营 admit（含 run/skip 回测路径）	是	`candidate_validation`，`validation_status=received`
标记观察	运营 observe	是	`candidate_validation`，`validation_status=unresolved`
已暂缓	运营 defer	是	`candidate_validation`，`validation_status=unresolved`
回测完成	event-backtest callback	是（样本≥10）	`candidate_backtest_result`，`validation_status=pass/fail/unresolved`
进入 TM 验证中	`trader_status=created`	否	—
验证完成（实盘周期）	TM 验证流程结束（§4.8）	是	`candidate_live_review_result` 等（按阶段）
重回待决策	复查/重评时间到期	否	—

9.3 注意事项

"已推进验证"后，该候选的 TM 侧管理结束，后续跟踪在赛马流水线（TM验证中 / TM赛马中）
TM 侧状态与 DH 侧 candidate_type / lifecycle_status 相互独立：TM 标记"已暂缓"不影响 DH 继续更新画像；DH candidate_type 变为 action 不自动改变 TM 的"已暂缓"状态
DH lifecycle_status 变化时，"标记观察"和"已暂缓"的候选应收到提示（状态变化通知），让运营重新评估

十、TM→DH 写回映射（更新）

10.1 写回接口

所有 TM 候选管理与验证操作均通过 R3 接口写回： POST /v1/open/kol/candidate-validation/feedback

需要两个认证头：

X-API-Key：DH Open API Key（已有）
X-TM-Validation-Key：候选验证专用写入密钥（详见 §6.3 Q-KEY 待确认）

10.2 操作动作 → R3 字段映射（v1.4 · 对齐 DH 白名单）

DH 允许的 feedback_type（6 值）：candidate_validation · candidate_backtest_result · candidate_simulation_result · candidate_paper_result · candidate_live_review_result · candidate_validation_result
⚠️ v1.3 及以前文档中的 candidate_admitted / observation_deferred / admission_deferred / validation_completed 均为无效值，勿再使用。

【第一类】运营决策（feedback_type=candidate_validation）

TM 操作	`validation_phase`	`validation_status`	`validation_result_summary`	来源
推进 · 先跑回测	`backtest`	`received`	运营 rationale	§4.1
推进 · 跳过回测	`live_review`	`received`	含 skip_reason + rationale	§4.1
标记观察	—	`unresolved`	原因 + 复查时间	§4.1
暂不接入	—	`unresolved`	详细说明（必填）	§4.1

【第二类】批量回测结果（feedback_type=candidate_backtest_result）

触发	`validation_phase`	`validation_status`	附加字段
event-backtest callback（样本 ≥10，pass/fail）	`backtest`	`pass` / `fail` / `unresolved`	`win_rate` · `max_drawdown` · `sample_trade_count` · `backtest_window` · `realized_style_drift`（≥10 笔）· `validation_result_summary`（人类可读句子）

【第三类】实盘验证完成（§4.8，R4 之后）

触发	`feedback_type`	说明
回测/模拟/纸面/实盘阶段结束	`candidate_simulation_result` 等（按实际阶段）	原 §4.8 `validation_completed` 概念；枚举以阶段对应 `candidate_*_result`

R3 两阶段交付（密钥缺失时）：

阶段	条件	行为
Phase A	`CandidateValidationFeedbackKey` 为空	决策写本地 DB + ops 日志；`r3_write_back_pending=true`；前端 Toast「DH 写回待同步」
Phase B	密钥注入后	实时写回 + 可批量补写 pending

必填公共字段（来自 DH 候选包，写回时原样携带）：

candidate_id：来自 DH R2 候选包（TM 候选包主键，见 §4.1）
state_id、state_version（int64）、state_hash：来自 DH 候选包
kol_id、source_ids、symbol_bucket、time_horizon、topic_scope、candidate_type：来自 DH 候选包
feedback_id：TM 生成，格式 tm_{type}_{candidate_id}_{timestamp}，保证幂等
tm_run_id：TM 生成，标识本次操作会话

validation_completed 类附加必填字段：

realized_style_drift：综合一致性，公式见 §4.8.2（sample_trade_count ≥ 10 才写）
backtest_window：例 2026-06-01..2026-06-21
sample_trade_count：成交次数
win_rate：胜率
max_drawdown：最大回撤

10.3 写回边界（D4 落地，v1.2 新增）

仅以下 R3 字段属于本写回映射的范围：

上表中列出的 admission 类 + validation 类指标
DH 反馈账本（dn_kol_candidate_validation_feedback）已定义字段

以下指标明确不进入 R3 写回（TM 内部参考视图）：

Event 漏斗 5 口径（信号方向准确率 / 信号采纳率 / 报单成功率 / 执行胜率 / 端到端命中率）
W7 信号质量异常预警
§4.7 一致性面板的 TM 端评估（高度一致 / 基本一致 / TM 端待复核）

详见 §〇.3 两条数据回路说明。

10.4 幂等与重试原则

同一个 feedback_id，30 秒内重复提交 → DH 返回幂等接受（accepted=true, reason=duplicate），TM 视为成功
DH 返回 accepted=false（内容冲突 / 过期 state）→ TM 提示运营"写回失败"，记录本地日志，刷新 candidate 后重新尝试
网络错误 → TM 最多重试 3 次（指数退避），失败后在操作历史中标注"写回待同步"，下次刷新时自动重试
X-TM-Validation-Key 返回 401 → 触发密钥过期告警（参见 §6.1 业务前置条件），TM 工程人员需协调 @DH Provider 配置中心管理员重新下发密钥

十一、分层交付建议（v1.3 更新）

本节提供两个视角：技术就绪视角（原三层，按技术前置条件分层）和 R4 对齐视角（按 R4 pilot 验证目标分优先级）。两个视角互补，建议在排期时以 R4 对齐视角为主，技术就绪视角作为依赖检查。

视角一：R4 对齐优先级（推荐排期依据）

背景：R4 目标是让 TM 对 8 条 pilot 候选（全为 risk/observe，无 action）完成受控验证并写回真实反馈。赛马看板是运营执行这一流程的操作界面。

P0 — R4 期间必须上线（直接阻塞 pilot 候选运营决策）

功能	章节	工作量	阻塞原因
DH 候选段完整列表（优先级 / 状态 / 方向 / 证据展示）	§4.1	M	运营需要看到 8 条 pilot 候选
候选详情侧边栏	§4.1	M	查看 DH 画像 + 不适合原因，辅助判断 risk/observe
三个操作动作（推进 / 观察 / 暂缓）+ 确认对话框	§4.1	M	对 pilot 候选执行决策
R3 运营决策写回（`candidate_validation`）	§十.2	M	R4 T4 前置；密钥 🚧
推进验证 + 批量回测状态机（DEV-07）	§4.1.y / §4.3.5	M	✅ 主体已落地
R3 回测结果写回（`candidate_backtest_result`）	§十.2	M	callback 已接 · 生产密钥待验
候选数据同步策略 + 失败降级 banner	§4.1.x	S	确保 8 条候选数据实时可见
决策日志 + dh_context_snapshot + effect_review_at	§4.6	S	R4 要求每条候选有可追溯判断理由
用户权限（viewer / operator / admin）+ 接口鉴权	§八	M	没有权限门控，操作无法被审计

P1 — R4 期间强烈建议上线（提升 pilot 决策质量，减少误判）

功能	章节	工作量	建议原因
W5（lifecycle = conflicted 持续 >3 天）	§4.5.2	S	R4 的 4 条 risk 候选全是 conflicted，W5 帮助运营识别风险
W3 升级（双源沉默：信源沉默 vs AI 过滤率高）	§4.5.1	S	pilot 候选观测期需要区分沉默原因
DH 画像摘要区（Drawer 第六区）	§4.4	M	pilot 全为 risk/observe，运营必须看到 DH 静态 + 动态画像才能负责任地决策
Trader 配置创建闭环（推进后 7 天超时提醒）	§4.1.x	S	追踪推进的 pilot 候选是否完成 trader 创建
DH lifecycle 反向通知（已处理候选状态变化提示）	§4.1.x	S	pilot 候选 lifecycle 在观测期内可能变化（conflicted → active）

P2 — R4 写回数据积累后上线（依赖 validation_completed）

功能	章节	工作量	前置条件
validation_completed 写回 + 60 天超时兜底	§4.8	M	R4 T4 完成后产生真实验证结论
排行榜风格漂移列 + drift spark line	§4.3.1	S	需要 realized_style_drift 数据
W6（drift > 0.30）+ 预警优先级排序	§4.5.3 / §4.5.4	S	同上
TM 验证中画像对齐卡	§4.2	M	pilot 候选进入「TM 验证中」后才有意义
排行榜策略风格第二维过滤	§4.3.2	M	赛马中 KOL 积累到一定数量后才有过滤价值
DH 候选段复查提醒	§4.1.x	S	依赖已处理候选积累
飞轮 KPI 第一层（池治理层）面板	§13.1	M	需要足量 admission 类写回记录

P3 — R4 结束后 / 长期（依赖 DH event 接口或大量数据积累）

功能	章节	工作量	前置条件
单 KOL Event 漏斗（5 口径）+ W7	§4.3.4	M	依赖 DH event 列表接口（Q-D5 待选型）
排行榜端到端命中率列	§4.3.4	S	同上
DH-TM 画像质量追踪面板 + 评估阈值表	§4.7	L	需要 60+ 天 R3 写回积累
飞轮 KPI 第二层（单 KOL 信号质量层）面板	§13.2 / §13.3	M	同上
候选阵容互补性提示	§4.1.x	M	需要现有赛马阵容，R4 初期阵容为空
画像新鲜度提示	§4.3.3	S	需要赛马中 KOL 积累
方向预检入验证通知	§4.2	S	需要 pilot 有足够样本后评估价值

视角二：技术就绪视角（原三层，作为依赖检查）

第一层：R10 完成 + R3 接口可用后即可上线

对应 R4 对齐视角的 P0 + P1 全部功能（见上表）。

第二层：R3 写回数据开始积累 + DH event 接口（D5）确认后

对应 R4 对齐视角的 P2 全部功能，以及 P3 中依赖 DH event 接口的：单 KOL Event 漏斗 / W7 / 排行榜端到端命中率列。

第三层：积累 60+ 天写回数据后

对应 R4 对齐视角的 P3 中依赖长期数据的功能：DH-TM 画像质量追踪面板、飞轮 KPI 第二层、候选阵容互补性提示。

十二、验收标准（更新）

ID	标准	验证方式
AC-1	DH候选段按优先级排序；同一 KOL 多 DH 行按五维合并为 TM 候选包	对照 DH API + 列表 dedupe
AC-2	点击「推进验证」+ run_backtest 后，侧栏展示回测进度，列表行显示「回测中」；不会自动进入 TM验证中 Tab	全流程测试
AC-2b	skip_backtest 后 `trader_status=awaiting`，无 batch 任务	操作 + DB 核查
AC-3	推进/观察/暂缓写回 `candidate_validation`；回测完成写 `candidate_backtest_result`；DH 返回 accepted=true（或 Phase A pending）	查 feedback 表 / pending 标记
AC-4	候选详情侧边栏展示实时 DH 画像数据（通过 profile_analyzed_at 时间戳核查）	对照 DH API 原始返回
AC-5	lifecycle_status = conflicted 的候选，详情侧边栏高亮显示不适合原因，操作按钮给出风险提示	测试数据触发
AC-6	lifecycle_status = conflicted 的 KOL 有 W5 预警徽章	测试数据触发
AC-7	W3 触发时能区分"信源沉默"vs"信号未触达 TM"	分别模拟两种场景
AC-8	有 R3 写回的 KOL，排行榜风格漂移列有数值；无写回的显示 —	对照 DB 表数据
AC-9	决策日志写入时自动附带 dh_context_snapshot + effect_review_at	查看 ops_decisions.json
AC-10	重复提交相同操作不产生重复写回（幂等测试）	连续点击确认，查看 feedback_id 是否唯一
AC-11	批量回测 callback 后写 `candidate_backtest_result`；样本≥10 含 drift；超时 60 天兜底（§4.8）	模拟 callback + DB
AC-11b	admit 后侧栏 validation-progress 30s 更新；pass 后「待建 trader」徽章	侧栏 + 列表截图
AC-11c	event-backtest 时间戳为 Unix 秒；回测窗口按 §4.3.5.2	联调日志
AC-12	单 KOL Event 漏斗的 5 个口径均能在 Drawer 中正确展示；样本不足时显示文案	测试数据驱动
AC-13	方向准确率以 4h K 线收盘价比对 event.direction，TM 本地计算，未在 R3 写回中出现	抽样核查计算 + 检查 DH R3 payload
AC-14	推进 KOL 7 天未创建 trader 配置时，候选段顶部出现预警 banner	模拟推进 + 7 天后核查
AC-15	DH lifecycle 变化时，已处理候选行出现「⟳ 状态已变化」标识，24h 去重	模拟 DH 状态切换
AC-16	viewer 角色访问 §4.3.4 漏斗 / §4.7 一致性 Tab / DH候选段接口均返回 403	三类接口分别用 viewer JWT 调用
AC-17	viewer 简化 Drawer 中不包含 DH 画像摘要 / 预警 / 决策日志 / 操作按钮	viewer 视角截图

十三、数据飞轮 KPI（新增）

把 RF 飞轮从概念升级为可衡量目标。分两层：

13.1 KOL 池治理层 KPI（产品视角）

回答的问题：运营选候选准不准？飞轮主路是否健康？

数据源：DH R3 反馈账本 + TM 决策日志

指标	启动期目标（1-60 天）	稳态期目标（60-180 天）	说明
候选段周决策数	≥ 15 / 周	≥ 10 / 周	按 D1 周节奏统计；累计推进 + 观察 + 暂缓
R3 写回成功率	≥ 95%	≥ 99%	DH 返回 accepted=true 占比
推进→trader 创建转化率	≥ 60%	≥ 90%	推进后 7 天内创建 trader 的比例
决策日志附 dh_context_snapshot 率	100%	100%	强制要求（前端校验）
validation_completed 写回率	—	≥ 90%	进入 TM 验证的 KOL 完成 validation_completed 写回比例（含超时兜底）
推进→pass 命中率	—	≥ 40%	窄口径：写回 `validation_status=pass` 的 KOL / 推进的 KOL（90 天滚动窗口）
推进→赛马入场率（辅助）	—	≥ 60%	中口径：进入 TM 赛马中的 KOL / 推进的 KOL
决策 effect_review 完成率	≥ 80%	≥ 95%	设了 effect_review_at 的决策中按时完成回看的比例

KPI 触发动作：连续 2 周低于目标值 → 触发 PM 复盘，可能调整优先级规则或预警阈值。

13.2 单 KOL 信号质量层 KPI（KOL 视角）

回答的问题：这个 KOL 信号本身好不好？是否值得继续跑？

数据源：TM event_log + position + DH 原始 event 列表（待 D5 接口确认，参见 §6.1）

核心指标（详细计算见 §4.3.4）：

指标	用途	在 PRD 中的位置
信号方向准确率	评估信号本身质量，不论 TM 执行	§4.3.4 漏斗 + Drawer
信号采纳率	评估 AI 对 KOL 的信任度	§4.3.4 漏斗
报单成功率	评估 TM RuleEngine 与信号匹配度	§4.3.4 漏斗
执行胜率	评估成交后的市场表现	§4.3.4 漏斗
端到端命中率	评估信号到利润的整体转化	§4.3.4 漏斗 + 排行榜列
平均单 event 盈亏	评估信号的期望值	§4.3.4 tooltip

单 KOL 健康度判定：

健康度	判定条件	运营动作
优秀	端到端命中率 ≥ 35% 且方向准确率 ≥ 60%	维持，可考虑提升仓位权重
待优化	端到端命中率 25-35% 或方向准确率 50-60%	进入 §4.6 决策日志记录观察
异常	端到端命中率 < 25% 或方向准确率 < 50%；样本 ≥ 30	触发 W7 预警；考虑暂停或降级
样本不足	原始 event < 30 条	不计算，显示「样本不足」

关键边界（D4 落地）：本层全部 KPI 完全在 TM 端计算与消费，不写回 DH，符合 §〇.3 回路 B 原则。

13.3 双层 KPI 的联动消费

池治理层 KPI 异常（如推进→pass 命中率 < 40%）→ 看是哪些候选 fail → 进入 §4.3.4 漏斗看是不是同类信号质量问题 → 调整 §4.1 候选优先级规则
信号质量层 KPI 异常（多个 KOL 端到端命中率走低）→ 检查是不是市场环境变化 → 若是，记录在 §4.6 决策日志；若不是，PM 复盘候选推进策略
月度复盘：把两层 KPI 同时呈现在 PM 月度会议，识别"决策对了但执行失败"vs"决策本身有偏差"

十四、开放问题

#	问题	建议
Q1	候选优先级评分是否需要 PM 手动调整权重？	第一版固定规则，收集反馈后再看是否配置化
Q2	~~"推进验证"后，TM 是否自动创建 trader 配置？~~	已确认：第一版仅记录决策状态，trader 配置由运营手动创建；后续迭代为半自动化
Q3	DH 画像 30 天未更新时，候选段是否展示提示？	建议展示，但不推送通知
Q4	"标记观察"到期后，是否自动拉取最新 DH 画像并高亮变化部分？	建议是，提升复查效率
Q5	DH-TM 画像质量面板是否需要历史趋势图？	第一版只展示最新值，有数据积累后再加趋势
Q6	飞轮稳态期推进→pass 命中率长期低于 40% 是否需调整候选优先级评分规则？	连续 2 周低于则触发 PM 复盘；首选调整 §4.1 关键维度权重
Q7	DH 静态画像团队评估周期建议（周 / 月 / 季度）？	待 @DH 静态画像负责人确认（参见 §6.3 Q-EVAL）
Q8	viewer 简化 Drawer 中保留"超额收益"是否需合规复核？	待 @合规审阅（参见 §6.3 Q-VIEWER）
Q9	方向准确率判定时窗 4h 是否需要按 KOL 持仓周期分层（短线 4h / 中线 1d / 长线 3d）？	P2 增强，先沉淀数据再决策
Q10	DH 暴露原始 event 列表的三种接口形式（新增 endpoint / 扩展 candidate-list / DH→TM 推送）哪种最合适？	待 @DH maintainer 选型确认（参见 §6.3 Q-D5）
Q11	R4 验收通过后，R5 策略蒸馏路线如何衔接 TM / FinBayes？赛马看板需要新增"策略资产化"入口还是另建页面？	R4 go/no-go 判断后讨论；本期 PRD 不覆盖 R5
~~Q12~~	~~`feedback_type` 枚举~~	✅ 已关闭，见 §10.2 / §6.4
~~Q13~~	~~`candidate_type` vs `candidate_status`~~	✅ 已关闭：`candidate_type` 为动态类型；`candidate_status` 忽略
Q14	TM 候选包合并组内多 `candidate_id`，admit 时是否允许运营选择具体包？	当前取 priority 最高者；PM 确认是否可接受
Q15	五维画像字段均为空时合并键碰撞	PM + 工程：fallback 策略

版本历史：v1.0 初稿（2026-06-23）· v1.1 候选管理工作流 + 状态机 + 写回映射 · v1.2 端到端业务流 + Event 漏斗 + 双层 KPI · v1.3 R4 对齐 + Q-FTYPE/Q-CSTATUS 登记 · v1.4 R4 候选池工程落地回填（TM 候选包、DEV-07 验证状态机、Layer 0、R3 枚举修正、DH 契约表 · 2026-07-01）

文档关系​

〇、端到端业务流全景​

〇.1 五段业务流全景​

〇.2 各业务环节说明​

〇.3 两条数据回路（必读）​

〇.4 业务流跨团队责任速查​

一、背景与动机​

1.1 当前赛马看板使用 DH 的状况​

1.2 DH 现已提供但未使用的数据​

1.3 问题定义​

二、目标​

三、信息架构变化总览​

3.1 三段流水线各段变化​

3.2 KOL Drawer 新增区域​

四、功能规格​

4.1 DH候选段：候选管理工作流（全量升级）​

设计原则​

TM 候选包（列表展示单位）​

整体数据流​

候选优先级评分规则​

候选池列表界面​

候选详情侧边栏（点击「查看详情」展开）​

三个操作动作的详细设计​

候选池分区展示​

复查到期提醒​

候选类型与不适合原因展示规则​

候选优先级关键维度权重​

4.1.x 候选数据同步策略​

4.1.x trader 配置创建闭环​

4.1.y 验证状态机与进度展示（DEV-07）​

4.1.x DH lifecycle 反向通知​

4.1.x 候选阵容互补性提示（P2）​

运营 SOP 速查（候选管理 · 周节奏）​

4.2 TM验证中：画像对齐卡​

目标​

画像对齐卡位置​

对齐卡内容​

对齐判断规则​

方向预检（进入验证时）​

4.3 TM赛马中：排行榜新增画像一致性维度​

4.3.1 新增列：风格漂移（Style Drift）​

4.3.2 策略风格过滤升级（二维）​

4.3.3 画像新鲜度提示​

4.3.4 单 KOL Event 漏斗（operator / admin 可见）​

漏斗位置​

漏斗结构（5 口径）​

5 个口径定义​

方向准确率判定逻辑（D3 落地）​

时间窗口选择器​

同风格 KOL 横向对比​

计算与存储职责（D4 落地）​

在排行榜（§4.3.1）中的延伸​

新增 W7：信号质量异常预警​

样本量门槛​

4.3.5 回测基线层（Layer 0）（operator / admin 可见）​

三层漏斗架构（§4.3 引言）​

4.3.5.1 触发与集成​

4.3.5.2 回测窗口与判定​

4.3.5.3 KOL Drawer 展示（待 DEV-07 收尾）​

4.3.5.4 与 §13.2 健康度对接​

4.3.5.5 P2 · 回测 pass/fail 入场门控​

运营 SOP 速查（赛马排行榜 · 周节奏）​

4.4 KOL Drawer 升级：DH 画像摘要区​

位置​

展示内容​

异常状态展示​

4.5 预警体系增强​

4.5.1 W3 改进：双源沉默判断​

4.5.2 新增 W5：信源状态异常预警​

4.5.3 新增 W6：风格漂移预警​

4.5.4 预警优先级排序规则​

运营 SOP 速查（预警处置 · 周节奏）​

4.6 运营决策日志增强​

新增：决策上下文快照​

运营 SOP 速查（决策日志 · 周节奏）​

4.7 画像质量追踪面板（operator / admin 可见）​

概述​

面板内容​

数据来源​

TM 端评估判定阈值​