跳到主要内容

Data Horizon -「KOL 动态画像方案」

日期：2026-06-19

状态：完整方案设计稿，等待团队 Review

可视化 Review Artifact：Data Horizon -「KOL 动态画像方案」

静态 Markdown 快照：KOL 动态画像方案 Markdown 快照

来源说明：本文由 Data Horizon 工程仓 DH-WP-002/kol-dynamic-profile-r1 设计产物同步到知识治理库，承接工程仓提交 46c21c98 的零上下文方案、可视化 artifact、模板和 Skill 草案更新。本页只发布 KOL 动态画像方案正文；公共模板和 Skill 草案仍保留在工程仓内作为后续试运行材料。

阶段说明：本文档文件名沿用首批落地工作包的 R1 命名。本文先定义完整「KOL 动态画像」链路，再明确 R1 冻结边界。R1 / R2 / R3 是分阶段实施顺序：R1 只落地 Workbench 内部动态画像、证据消费和只读 TM bridge overlay；R2 才设计 Trading Matrix 状态/候选交接和 strategy seed candidate；R3 由 TM / FinBayes 验证并升级为 strategy asset / agent template。

输入：

  • 当前 KOL 总控室 | KOL 工作台 前后端实现。
  • 早期 KOL 动态画像 MVP 设计。
  • KOL 总控室 R2.3 Dashboard snapshot-first 方案。
  • Trading Matrix 初始信源候选与样本交付需求。
  • Codex sub agents 专家评审：数据合同架构、Workbench UX、自动化交易/量化风险、策略蒸馏本体。
  • 本地 Claude Code Opus 4.8 外部评审。

模板说明：本文档已按跨团队技术设计 / Review 的阅读路径补齐“为什么做、做什么、怎么做、代价是什么”。由于本文档已经包含较多历史设计细节，保留原有章节编号，并在正文最前新增零上下文阅读导引和术语表。

0. 零上下文阅读导引​

0.1 为什么做这个功能​

Data Horizon 现在已经能收集和结构化 KOL 原始消息，也已经有 KOL 总控室 Dashboard 帮团队从全局角度看“哪些 KOL 在谈什么”。但团队成员如果想判断某一个 KOL 当前的风格、观点、策略线索、交易逻辑和操作变化，仍然需要回到原始消息逐条阅读，成本高、容易漏掉观点变化，也不利于把这些信息稳定交给 Dashboard 快照和 Trading Matrix。

「KOL 动态画像」要解决的是：团队成员和下游系统不读每条原始消息，也能知道某个 KOL 当前在关注什么、表达了什么立场、用了什么策略逻辑、有哪些操作提及、哪些证据支持或反驳这些判断，以及这些信息是否足够新鲜和可信。

这个功能有三重目的：

  1. A. 单 KOL 消费面：团队成员在看完全量 KOL “上帝视角” Dashboard 后，可以点击某个 KOL，直接消费该 KOL 当前动态画像、观点变化、策略/操作动态、可信度变化和证据链，而不需要逐条阅读该 KOL 的原始消息。
  2. B. Dashboard 数据支撑面：为全量 KOL Dashboard 提供动态实时的数据和快照支撑，让 Dashboard 的跨 KOL 聚合不只来自原始消息堆叠，而是来自可重算、可追溯、KOL scoped 的动态状态。
  3. C. Trading Matrix 标准输入面：为 FinTec AI Ecosystem 执行环节的 Trading Matrix 提供标准信息，使 TM 可以按 KOL 风格、策略类型、交易逻辑、交易技术和证据质量进行识别、分类、分批回测/模拟/实盘赛马，并在后续把有效 KOL 风格和策略线索蒸馏/克隆成长期运行的策略或 KOL Agent。

0.2 使用场景​

主要场景有三个。

  1. 人类团队成员在 KOL 总控室 | KOL 工作台 中点击某个 KOL，直接看到这个 KOL 的长期画像、当前动态画像、观点变化、策略/操作动态、可信度变化和证据链，不再逐条阅读原始消息。
  2. KOL 总控室 Dashboard 使用单 KOL 动态状态作为跨 KOL 聚合快照的底座，回答“全量 KOL 现在整体发生了什么、哪些状态变化值得下钻”。
  3. Trading Matrix 后续可以按标准信息理解这些 KOL 的风格、策略类型、交易逻辑、交易技术和证据质量，先做分类、回测、模拟和赛马，再把有效的 KOL 风格和策略线索蒸馏/克隆成系统自己的策略资产或 KOL Agent。

0.3 产品形态​

这个能力不新建一个孤立页面，也不是 Dashboard 的隐藏详情页。它落在现有 KOL 总控室 | KOL 工作台 里，与 Dashboard 是同级体验。

KOL 总控室
  - Dashboard：看全量 KOL 的聚合情报
  - KOL 工作台：点进某个 KOL，看这个 KOL 的当前动态画像和证据链

底层数据上，Dashboard 和 KOL 工作台共享 KOL scoped dynamic intelligence snapshot。区别是：Dashboard 聚合跨 KOL 状态，Workbench 展开单 KOL 状态、证据链和长期画像融合，Trading Matrix 后续消费稳定机器合同和 strategy seed candidate。

0.4 读者应该先记住的三句话​

  • Dashboard 回答“全量 KOL 现在整体发生了什么”；KOL 工作台回答“这个 KOL 现在是什么状态，凭什么这么判断”；Trading Matrix 回答“哪些 KOL/策略线索值得验证、赛马和蒸馏”。
  • R1 / R2 / R3 不是三个不同方案，而是同一个完整方案的落地顺序。
  • R1 不做交易建议、胜率判断、收益预测或实盘准入，只做可追溯的信息层、Workbench 内部消费面和 Dashboard/TM 后续合同的原料准备。

0.5 名词术语​

术语一句话解释
KOL这里指会发布市场观点、策略线索或交易操作信息的外部个人、频道或信息源。
Data Horizon / DHCurvature 金融生态的信息感知层，负责采集、结构化和交付市场信息。
Trading Matrix / TM生态内交易验证和策略运行系统，负责回测、模拟、赛马、验证和策略资产化。
KOL 总控室Data Horizon 中用于观察全量 KOL 情报和单 KOL 工作台的产品入口。
DashboardKOL 总控室里的全局视角，用于看全量 KOL 的聚合情报。
KOL 工作台 / WorkbenchKOL 总控室里的单 KOL 工作区，用于筛选 KOL、打开画像详情和查看证据链。
静态画像 / 长期基线这个 KOL 通常是什么风格、覆盖什么市场、偏好什么周期和方法。
动态画像某个 KOL 在当前时间窗口内表达的观点、策略线索、操作提及、风险变化和证据状态。
证据链支撑或反驳某个动态判断的消息、事件、原文链接和引用片段。
dynamic state / 动态状态由多条 KOL 消息事件聚合出的当前状态，例如某 KOL 对 BTC 短线偏多但证据有限。
confidence / 置信本方案里只表示信息质量、证据充分度或来源可靠性，不表示胜率、收益或可实盘概率。
dry-runTrading Matrix 对样本或信号做非实盘验证，用于观察逻辑是否可回放和可评估。
赛马Trading Matrix 把多个 KOL、策略或候选规则放入同一验证框架中比较效果。
策略蒸馏从 KOL 风格和策略线索中提炼可被系统复用的策略假设、规则或 Agent 行为模板。
策略克隆策略蒸馏的一种结果表达，指把被验证的 KOL 风格、策略逻辑或操作模式沉淀为系统可长期运行的策略资产；不是复制 KOL 本人，也不是 R1 承诺。
KOL Agent后续可能由 TM / FinBayes 基于验证后的 KOL 策略逻辑生成的 Agent 行为模板或运行体；R1 只提供原料。
实时快照 / dynamic intelligence snapshot近实时、可重算、可追溯的 KOL 动态状态集合，用于 Workbench 展开、Dashboard 聚合和后续 TM 交接。
执行环节FinTec AI Ecosystem 中负责验证、回测、模拟、赛马和策略运行的环节，本方案中特指 Trading Matrix 及其后续策略资产化流程。
strategy seed candidateR2+ 可能交给 TM 的候选策略种子，来自已归因的 KOL 动态状态、证据链和策略模式线索；不是已验证策略资产。
TM bridgeData Horizon 页面中展示 TM 相关验证状态和反馈的只读连接层，不是交易执行接口。
R1 / R2 / R3实施阶段：R1 做 Workbench 内部消费，R2 做 TM 标准交接，R3 做策略资产化。

0.6 本方案不表示什么​

  • 不表示某个 KOL 可信、可跟单或能赚钱。
  • 不表示某个观点有胜率、alpha、收益概率或实盘资格。
  • 不表示 Data Horizon 会在 R1 生成自动交易策略。
  • 不表示 Trading Matrix 的 PnL 或胜率会反向改变 Data Horizon 的信息置信度。

1. 核心决策​

完整方案不新建孤立的“单 KOL 动态画像页”，也不把动态画像埋成 Dashboard drilldown 的附属详情。

产品定位是一个动态 intelligence snapshot 层支撑三个消费面：

KOL dynamic intelligence snapshot
  - Dashboard / KOL 情报中心：跨 KOL 聚合和上帝视角
  - KOL 工作台：单 KOL 动态画像、证据链和交易前筛选工作区
  - Trading Matrix：R2+ 标准状态/候选交接，支持验证、赛马和策略蒸馏

当前 KOL 工作台 已经具备左侧筛选、中央 KOL 列表、右侧画像 Drawer 的基本形态。完整方案复用这个形态，把它从“静态画像列表 + 静态详情”升级为“动态交易前筛选列表 + 单 KOL 动态工作区”。R1 是该完整方案的首批落地切片。

单 KOL 动态画像的定义：

某个 KOL 在当前时间窗口内，
围绕哪些对象表达了什么观点、策略模式线索、操作提及或风险变化，
这些状态由哪些消息证据支撑或反驳，
证据是否新鲜、充分、可解析、可作为 TM dry-run / 后续验证原料。

它不是交易建议，不是胜率判断，不是 KOL 绩效评分，也不是已经蒸馏完成的策略资产。

2. 目标和非目标​

2.1 完整方案目标​

  1. 让人直接理解单 KOL 当前状态：团队成员从 Dashboard 下钻到 Workbench 后，可以直接看到该 KOL 当前风格、观点变化、策略/操作动态、可信度变化和证据链，不需要逐条读原始消息。
  2. 让 Dashboard 有动态快照底座：全量 KOL Dashboard 的聚合视角应由 KOL scoped dynamic states / snapshots 支撑，能从单 KOL 证据链回溯到跨 KOL 趋势、共识、分歧和异常变化。
  3. 让 Trading Matrix 获得标准输入：TM 可以据此理解每个 KOL 的风格、策略类型、交易逻辑、交易技术、证据质量和状态新鲜度，用于 KOL 分类、分批回测/模拟/实盘赛马。
  4. 让策略蒸馏有可追溯原料：后续即便没有这些 KOL 的实时信息，也能基于已验证的 KOL 风格和策略逻辑沉淀/蒸馏/克隆出长期运行的策略资产或 KOL Agent。
  5. 让人类 Review 和 AI Agent Review 可对齐：方案、模板和 Skill 都要先解释场景、目的、产品形态、术语和边界，再进入表、字段、API 和实施阶段。

2.2 R1 冻结目标​

  1. 团队成员在不逐条阅读原始消息的前提下，能从单 KOL 工作区理解：
    • 当前风格和长期画像是否一致。
    • 当前关注标的、市场、周期和主题。
    • 当前表达状态、策略模式线索、操作提及、风险动作和观点修正。
    • 哪些结论有证据，哪些证据不足、陈旧或冲突。
  2. Dashboard 到 Workbench 的下钻保留上下文：
    • 从热门标的、多空分布、策略操作、机会候选等组件进入 Workbench 时，列表和详情应知道来自哪个对象、哪个窗口、哪些筛选。
  3. 在 Workbench 内展示标准、可追溯、可重算的信息原料，同时保持 TM 对外边界：
    • KOL/source identity。
    • 动态状态读模型作为 R1 内部 Workbench/UI contract。
    • 证据事件和原文引用。
    • 数据质量、解析质量、新鲜度、样本可回放 / 可进入 dry-run 复核前置判断。
    • TM seed / validation / feedback 状态和反馈只作为 bridge overlay 展示。
    • 对外给 TM 的新增 state feed、candidate feed 和 strategy seed contract 延后到 R2；R1 对外仍以现有 event-level dry-run feed 为准。
  4. 明确策略蒸馏路径：
    • DH R1 提供可蒸馏原料。
    • DH 不在 R1 内宣称可交易策略、可运行 Agent 或收益能力。

2.3 R1 非目标​

R1 不做：

  • 不把 confidence_score 解释成胜率、alpha、收益概率或执行置信。
  • 不在主 UI 裸露 confidence_score 小数；主 UI 只展示“证据充分/有限/不足”“状态稳定/波动/冲突”等业务标签。
  • 不把 TM 的 PnL、胜率、profit factor 等表现指标反向写入 DH 主画像置信。
  • 不把单条消息直接升级为 strategy asset。
  • 不在 DH 内生成可实盘执行的 Agent 或交易策略。
  • 不在 R1 内生成可长期运行的 KOL Agent、策略克隆或 strategy asset。
  • 不在 R1 新增对外 TM state feed、strategy seed candidate 表、validation run 写入或 strategy asset promotion。
  • 不承诺严格实时，只承诺近实时、可重算、可追溯。
  • 不把 presentation prose 当作 TM 稳定合同。
  • 不重做 KOL 工作台整体 IA，不做大规模视觉重构。

3. 当前实现事实​

3.1 Workbench 形态​

现有前端页面：

  • web/src/views/datahorizon/kol-control-room/index.vue
  • 路由：/datahorizon/kol-control-room
  • Tab：dashboard 与 workbench 同级。
  • Workbench 现有结构：
    • 左侧筛选与观察清单。
    • 中央 KOL 表格。
    • 顶部 context bar，用于展示 Dashboard 下钻筛选上下文。
    • 右侧 ProfileDetail Drawer。

现有 API：

  • POST /kol-control-room/workbench/list
  • POST /kol-control-room/workbench/facets
  • POST /kol-control-room/workbench/profile-detail
  • POST /kol-control-room/evidence/list

当前 Workbench 已经能展示静态画像字段，包括角色、评级、周期、资产类别、标的、市场、策略风格、交易逻辑、操作方法、画像时间等。

当前不足是：动态画像在详情里主要压缩成 dynamicState.dataStatus + dynamicState.summary 字符串，结构化状态、冲突证据、freshness、TM bridge 没有成为一等 UI/API contract。

3.2 动态画像底座​

现有后端已经有两层动态画像底座：

  • dn_kol_signal_event：append-only KOL 动态事件账本。
  • dn_kol_dynamic_state：从事件账本 fold 得到的动态状态读模型。

现有语义：

  • 事件层包含 event_id/raw_news_id/source_id/kol_id/schema_version/extractor_version/msg_kind/targets/topic_scope/time_horizon/evidence_status/evidence_span/clarity/parseability/payload_hash/published_at 等字段。
  • 状态层包含 state_id/state_version/kol_id/symbol_bucket/time_horizon/topic_scope/evidence_status/lifecycle_status/stance_distribution/confidence_type/confidence_score/data_sufficiency/evidence_count/supporting_event_ids/contradicting_event_ids/freshness/last_evidence_at/valid_from/valid_to/aggregation_rule_version/replay_run_id/state_hash 等字段。confidence_score 是信息侧质量字段，R1 UI 不应裸露数值。

这说明 R1 不需要重造动态画像底座，重点是把现有读模型接入 Workbench 的单 KOL 消费体验。

3.3 TM 交接底座​

现有 TM 相关能力：

  • dn_tm_source_meta：source 运营状态、推荐状态、手动覆盖。
  • dn_tm_source_feedback：TM seed / validation / asset 状态和绩效反馈。
  • dn_kol_validation_feedback：TM 对 KOL event 的验证反馈账本。
  • OpenKolDryRunSignalList：开放给 TM 的 KOL dry-run event feed。
  • OpenKolValidationFeedback：TM validation feedback 回写。

这些能力说明 DH/TM 已经有“事件样本交付 + 反馈回写”的接口基础。单 KOL 动态画像 R1 应该把这些状态作为 Workbench 详情的 bridge overlay，而不是把 TM performance 混入 DH dynamic state。

4. 概念分层​

R1 文档和实现都必须使用以下分层，避免本体混淆。

4.1 Static Baseline​

来源：

  • dn_kol_profile
  • dn_kol_profile_summary

回答：

  • 这个 KOL 通常是谁。
  • 通常覆盖哪些市场、标的和资产类别。
  • 通常是什么角色、评级、风险偏好、交易周期、交易方法和决策驱动。

R1 UI 中应标为“长期画像”或“长期基线”，不能和当前动态状态揉成同一事实。

4.2 Dynamic Event Ledger​

来源：

  • dn_kol_signal_event
  • raw message evidence

回答：

  • 单条消息是否包含观点、策略模式线索、操作提及、风险、复盘或闲聊。
  • 涉及哪些对象、周期、方向、证据片段、可解析性和清晰度。

它是 append-only 事实账本。修订不能覆盖旧事件，只能通过 correction/supersedes/tombstone 语义表达。

4.3 Dynamic Read Model​

来源：

  • dn_kol_dynamic_state
  • fold(KOLSignalEvent, aggregation_rule_version)

回答：

  • 当前某 KOL 对某个 symbol_bucket x time_horizon x topic_scope 的状态。
  • 支撑证据和反驳证据分别是什么。
  • 状态是否 active、stale、conflicted、reversed 或 closed。
  • 证据是否充分、新鲜、可解析。

这是 R1 的核心 machine-readable contract，但 R1 只把它作为 Workbench/profile-detail 内部合同；对外给 TM 的新增 state feed 延后到 R2。

4.4 Evidence Chain​

来源：

  • supporting_event_ids
  • contradicting_event_ids
  • raw news / original URL
  • evidence span

回答：

  • 这个动态结论凭什么成立。
  • 哪些消息在支撑它。
  • 哪些消息在反驳或修正它。
  • 是否存在迟到、重复、低质量或不可解析证据。

R1 必须把“支撑证据”和“冲突证据”显式区分。冲突不是异常，它是金融观点可信度的一部分。

4.5 TM Bridge / Feedback Overlay​

来源：

  • dn_tm_source_meta
  • dn_tm_source_feedback
  • dn_kol_validation_feedback
  • TM source / dry-run / feedback logic

回答：

  • 这个 KOL/source 是否已进入 TM seed、validation 或其他外部反馈流程。
  • 当前 TM 验证状态是什么。
  • 是否有 reject reason、feedback reason、last feedback。
  • 如存在来自 TM 的表现摘要，是否需要作为外部反馈独立展示。

约束：

  • TM performance 只展示为外部反馈，不参与 DH dynamic state confidence、列表排序或 DH quality 评分。
  • TM bridge 是 overlay，不是动态状态本体。

4.6 Presentation Snapshot​

来源：

  • oneLineProfile
  • currentViewSummary
  • dynamicState.summary
  • matchContext.reason
  • reportMarkdown
  • fullReportMarkdown

回答：

  • 给人看的可读摘要。

约束：

  • 这些字段可以保留，但必须标记为 presentation-only。
  • 不能作为 TM 稳定解析字段。
  • 不能替代结构化状态和证据链。

5. R1 UX 设计​

5.1 Workbench 左侧筛选​

现有静态筛选保留：

  • 关键词。
  • 画像状态。
  • KOL 角色。
  • 评级。
  • 资产类别。
  • 标的。
  • 市场。
  • 策略风格。
  • 持仓周期。
  • 观察清单。

R1 增加动态筛选组：

  • 当前方向：偏多、偏空、观望、分歧、不确定。
  • 生命周期：新出现、活跃、陈旧、冲突、反转、关闭。
  • 证据状态：充分、有限、不清晰、冲突、需复核。
  • 新鲜度：1h、6h、24h、7d，或与当前 Dashboard time window 对齐。
  • TM 状态：未交接、dry-run 复核、validation 中、外部反馈、被拒绝、需人工复核。

筛选区文案应服务交易前筛选，而不是抽取调试。比如显示“证据不足”而不是内部 data_sufficiency=false。

5.2 Workbench 列表​

列表定位：

当前哪些 KOL 值得打开看，为什么值得看，风险在哪里。

R1 列表建议字段：

  • KOL：名称、source、角色、评级。
  • 当前对象：主要 symbol / market / topic。
  • 当前观点：由 stance_distribution 显示为偏多、偏空、观望、分歧、不确定。
  • 策略模式线索 / 操作提及：策略分析、操作提及、风险动作、观点修正；没有明确操作提及时显示“暂无明确操作提及 / 不可直接执行”。
  • 周期：scalping、intraday、swing、position、multi_horizon、unclear。
  • 状态：active、stale、conflicted、reversed。
  • 证据：evidence_count、supporting/contradicting count、last_evidence_at。
  • 新鲜度：fresh、decaying、stale、late_arrival。
  • TM：not_handed_off / dry_run_review / validation / external_feedback / rejected / needs_review。

列表不展示完整证据流，也不展示大段 Markdown 报告。列表是筛选索引，详情是消费工作区。

5.3 单 KOL 动态工作区​

打开方式：

  • 从 Workbench 列表点击 KOL。
  • 从 Dashboard widget 下钻到 Workbench 后再点击 KOL。
  • 从 Watchlist 点击 KOL。

右侧 Drawer 继续使用，但默认 tab 从“长期画像”改为“当前动态画像”。

Drawer 顶部应固定一个 summary strip，始终显示：

  • KOL identity 和 source。
  • 当前状态结论。
  • Dashboard 下钻 context：来源 widget、时间窗、对象和筛选。
  • 证据状态与 freshness。
  • TM bridge 状态。
  • 下一步动作：查看证据、标记复核、复制上下文链接。

建议 tab：

  1. 当前动态画像
  2. 证据链
  3. 长期画像
  4. TM 交接
  5. 完整报告

当前动态画像​

首屏展示：

  • 一句话动态摘要，标记为 presentation-only。
  • 当前状态卡片列表，按 symbol_bucket x time_horizon 分组。
  • 每张状态卡显示：
    • 标的/主题。
    • 周期。
    • stance distribution。
    • lifecycle status。
    • evidence status。
    • confidence type 和人类可读证据充分度 / 状态稳定性标签；裸 confidence_score 只允许进入技术溯源折叠区。
    • evidence count。
    • freshness 和 last evidence time。
    • supporting / contradicting evidence 入口。

卡片文案要避免“建议开多”“可实盘”“胜率高”等交易承诺。使用“当前表达偏多”“证据有限”“状态冲突”“需复核”等感知层语言。

证据链​

证据链按状态组织，而不是简单列出最近消息：

动态状态
  - 支撑证据
  - 反驳/修正证据
  - 原文链接
  - evidence span
  - raw_news_id / event_id
  - published_at / captured_at / extracted_at / available_at

R1 时间口径：

  • freshness 默认以 available_at 或等价的系统可用时间计算，避免 late-arrival 消息用旧 published_at 刷新当前状态。
  • published_at 用于展示原文发布时间。
  • captured_at / extracted_at 用于审计采集和抽取延迟。
  • late-arrival 证据必须在证据条目中显式标记。

证据条目需要展示：

  • 消息类型：观点、策略模式线索、操作提及、风险、复盘、闲聊。
  • 标的与周期。
  • 方向或 stance。
  • 解析质量：machine_parseable / semi_nlp / manual_only / none。
  • 证据状态。
  • 是否迟到、重复、低质量、attachment-only 或 identity ambiguous。

长期画像​

长期画像继续展示已有字段：

  • 角色。
  • 评级。
  • 活跃度。
  • 资产类别。
  • 标的。
  • 市场。
  • 持仓周期。
  • 风险偏好。
  • 决策驱动。
  • 交易方法。
  • 长期画像摘要。

需要明确标注它是“长期、低频更新”的 baseline。

TM 交接​

展示：

  • source identity 和 source active status。
  • DH quality grade / status。
  • TM seed status。
  • TM validation status。
  • TM external feedback status。
  • last sample at。
  • sample count 90d。
  • TM feedback reason。
  • TM last feedback at。
  • 样本可回放 / 可进入 dry-run 复核状态和 reason。

如果存在绩效字段，必须位于“TM 外部反馈”区块，不得和 DH confidence 并列成同一质量分。

完整报告​

保留当前 fullReportMarkdown 能力，但降级为报告阅读，不作为 R1 主工作流。

6. API Contract 设计​

6.1 R1 选择​

R1 推荐扩展现有：

POST /kol-control-room/workbench/profile-detail

原因：

  • 当前 Workbench 和 Drawer 已经使用这个接口。
  • 它天然是单 KOL scoped。
  • 兼容现有静态画像、证据样本和 Dashboard filter context。
  • 避免新增一个孤立“动态画像详情”接口导致前端重复拼装。

R1 不新增写路径。

6.2 Profile Detail Response 分层​

建议响应结构按以下逻辑分层：

{
  "kolId": 0,
  "kolName": "",
  "filterContext": {},
  "staticBaseline": {},
  "dynamicProfile": {
    "status": "",
    "states": [],
    "presentation": {}
  },
  "evidenceChain": {
    "items": []
  },
  "tmBridge": {},
  "reports": {}
}

staticBaseline：

  • role
  • rating
  • activityLevel
  • holdingPeriod
  • assetClasses
  • symbols
  • tradingMarkets
  • riskPreference
  • decisionDriver
  • tradeMethod
  • oneLineProfile
  • profileAnalyzedAt
  • sourceProfileUpdatedAt

dynamicProfile.states[]：

  • stateId
  • stateVersion
  • symbolBucket
  • timeHorizon
  • topicScope
  • evidenceStatus
  • lifecycleStatus
  • stanceDistribution
  • confidenceType
  • confidenceScore: technical/provenance only; 主 UI 和业务 Review 使用 confidenceLabel / dataSufficiencyLabel
  • confidenceLabel
  • dataSufficiency
  • dataSufficiencyLabel
  • needsReview
  • evidenceCount
  • supportingEventIds
  • contradictingEventIds
  • freshness
  • freshnessBasis: available_at | extracted_at | captured_at | published_at
  • lastEvidenceAt
  • validFrom
  • validTo
  • aggregationRuleVersion
  • replayRunId
  • stateHash

dynamicProfile.presentation：

  • summary
  • matchReason
  • displayBadges
  • displayOnly = true

evidenceChain.items[]：

  • eventId
  • rawNewsId
  • sourceId
  • stateId
  • relation: supporting | contradicting | neutral
  • msgKind
  • targets
  • topicScope
  • timeHorizon
  • evidenceStatus
  • evidenceSpan
  • clarity
  • parseability
  • publishedAt
  • capturedAt
  • extractedAt
  • availableAt
  • lateArrival
  • rawUrl

tmBridge：

  • sourceId
  • sourceType
  • activeStatus
  • recommendStatus
  • activeStatusOverride
  • dhQualityGrade
  • tmSeedStatus
  • tmValidationStatus
  • tmExternalFeedbackStatus
  • tmFeedbackReason
  • tmLastFeedbackAt
  • sampleCount90d
  • lastSampleAt
  • replayEligibilityLevel: replayable | dry_run_review | observe_only | reject
  • replayEligibilityReasonCodes

reports：

  • reportMarkdown
  • fullReportMarkdown
  • displayOnly = true

6.3 Backward Compatibility​

R1 可以保留旧字段：

  • summary
  • fullReport
  • evidence
  • dynamicState.dataStatus
  • dynamicState.summary

同时新增结构化块。前端先读结构化块，旧字段作为 fallback。

Fallback 规则：

  • dynamicState.summary 只能作为 presentation/report 文案展示，不能作为“当前状态”事实回填。
  • 结构化动态状态为空时，不得用旧动态摘要伪造当前观点。

如果结构化动态状态为空：

  • 显示静态画像。
  • 展示“暂无当前窗口动态状态”。
  • 展示最近证据样本。
  • 不伪造动态观点。

6.4 Evidence List 修正​

当前 evidence list 已有 stateId 请求字段，但逻辑需要确保它真正按 state 下钻，而不是只按 KOL/source 列最近消息。

R1 要求：

  • 如果传入 stateId，优先用 supporting_event_ids 和 contradicting_event_ids 查证据。
  • 如果没有 stateId，按 KOL/source/window 返回最近 evidence，并标记为 fallback evidence，不得给出 supporting/contradicting 结论。
  • 返回证据时带 relation。

7. 与 Dashboard 的边界​

Dashboard 仍然负责全局聚合：

  • 全量 KOL 多空、热门标的、共识分歧、策略操作、机会候选、变化反转。
  • 使用 snapshot-first 读模型。
  • 输出跨 KOL intelligence components。

KOL 工作台负责 KOL scoped 消费：

  • 按 Dashboard filter context 筛选 KOL。
  • 对单个 KOL 展示静态 baseline、当前 dynamic states、证据链和 TM bridge。
  • 让团队可以从“全局情报”落到“这个 KOL 当前为什么值得看”。

边界规则：

  • Dashboard 可以生成对象级机会候选，但不做单 KOL 完整画像。
  • Workbench 可以显示某 KOL 的动态状态，但不生成跨 KOL 总览。
  • 两者共享 filter context、evidence IDs、dynamic state IDs 和 TM bridge overlay，但不共享对外 TM 机器合同。

8. 面向 TM 的边界​

8.1 DH 输出​

R1 对外给 TM 的稳定输出仍以现有 event-level dry-run feed 为准。profile-detail 中的动态状态是 Workbench 内部合同，不是 R1 对外 TM state feed。

DH 可以在 R1 Workbench 内展示：

  • KOL/source identity。
  • 事件账本。
  • 动态状态读模型。
  • 证据链。
  • 数据质量、解析质量、新鲜度。
  • 样本可回放 / 可进入 dry-run 复核前置判断。
  • TM seed / validation / external feedback 状态展示。

DH 对外给 TM 的新增 state feed、candidate feed、strategy seed contract 和 validation package 必须作为 R2+ 独立合同设计、评审和验收。

8.2 DH 不输出​

DH 不输出：

  • 交易执行建议。
  • 方向胜率。
  • 预期收益。
  • 资金分配建议。
  • 可实盘状态。
  • 已完成蒸馏的策略资产。
  • live eligibility。

8.3 Strategy Seed 路线​

策略蒸馏应拆成后续阶段：

R1: dynamic profile + evidence chain + TM bridge overlay
R2: strategy seed candidate = frozen evidence package + strategy hypothesis + rule candidate + parameter spec + validation protocol
R3: TM/FinBayes validates and promotes seed to strategy asset / agent template / execution policy

成熟度阶梯：

DH R1 拥有 KOLSignalEvent、KOLDynamicState、EvidenceChain 和描述性的 StyleIndicator / StrategyPatternSignal。StrategyHypothesis 之后的对象由 R2+ 与 TM / FinBayes 共同定义，DH R1 不生成、不注册、不承诺。

R2 的 strategy seed candidate 可以包含：

  • candidate_id
  • as_of_cutoff
  • available_at
  • kol_id
  • source_id
  • symbol_bucket
  • time_horizon
  • state_hash
  • supporting_event_ids
  • raw_news_ids
  • payload_hashes
  • stance
  • risk_control_presence
  • parseability
  • evidence_status
  • candidate_type: action | risk | beta | alpha | observe

但 R1 只在文档和 UI 中预留概念，不落表、不承诺。

9. 后端实施建议​

9.1 小步实施顺序​

  1. 定义 ProfileDetailResp 的新增结构化字段。
  2. 在 kol_control_room logic 中添加 dynamic state assembler。
  3. 复用现有 KOL dynamic-state mapper，避免发明第二套字段语义。
  4. 加入 state-scoped evidence assembler。
  5. 加入 TM bridge assembler，读取 source meta / feedback / sample stats。
  6. 保留旧字段 fallback。
  7. 添加相关 Go 单元测试。
  8. 在 server/ 执行相关测试和 make lint。

9.2 代码边界​

建议新增或调整的逻辑集中在：

  • server/api/kol_control_room.api
  • server/internal/logic/kol_control_room/workbench.go
  • server/internal/logic/kol_control_room/dynamic_state.go
  • server/internal/logic/kol_control_room/evidence.go 或现有 evidence 逻辑文件。
  • 可能新增 server/internal/logic/kol_control_room/tm_bridge.go。

不建议 R1 修改：

  • 动态事件抽取器核心算法。
  • dynamic state rebuild job 的聚合规则。
  • TM performance feedback 写路径。
  • 对外 TM state feed 或 strategy seed candidate 表。
  • validation run ingest / write path。
  • Dashboard snapshot builder。

9.3 数据查询原则​

  • 单 KOL 详情可以做 bounded query，但必须分页或限制 evidence 数。
  • 优先使用 state_id 和 event IDs 查证据，避免请求时大范围扫 raw news。
  • TM bridge 不应在单 KOL 详情里循环多次查表，尽量按 source/KOL 一次批量组装。
  • 如果 dynamic states 为空，返回明确空状态，不降级生成假摘要。

10. 前端实施建议​

10.1 工作台列表​

在现有表格基础上改造：

  • 把 当前总览 从一段摘要改成结构化信号区。
  • 增加动态状态 badges。
  • 增加 evidence / freshness / conflict indicator。
  • 增加 TM status indicator。

10.2 Drawer​

把 Drawer 默认 tab 改成 当前动态画像。

建议组件拆分：

  • DynamicProfileOverview
  • DynamicStateCard
  • EvidenceChainPanel
  • StaticBaselinePanel
  • TmBridgePanel
  • PresentationReportPanel

组件只消费前端 API type，不在组件里解析 Markdown 文案获得业务字段。

10.3 文案原则​

使用：

  • 当前表达偏多。
  • 证据有限。
  • 状态冲突。
  • 需要复核。
  • 可进入 dry-run 验证。
  • 样本可回放。
  • 暂无可执行操作。

避免：

  • 建议开多。
  • 高胜率。
  • 可实盘。
  • 已验证赚钱。
  • 该 KOL 可靠。
  • 应跟单。

11. 验收标准​

R1 完成后必须满足：

  • Workbench 仍是 KOL 总控室 内与 Dashboard 同级的 tab。
  • Dashboard 下钻到 Workbench 的 filter context 不丢失。
  • 单 KOL Drawer 默认展示 当前动态画像。
  • 每个动态状态能展示 lifecycle_status、stance_distribution、confidence_type、证据充分度/状态稳定性标签、evidence_count、freshness。
  • 每个动态状态能下钻到 supporting 和 contradicting evidence。
  • 静态 baseline 与动态 state 在 UI 上明确分区。
  • TM bridge 与 DH dynamic state 明确分区。
  • UI/API 不把 confidence_score 写成胜率、收益概率或执行置信。
  • 主 UI 不裸露 confidence_score 小数。
  • TM performance fields 不参与 DH confidence 排序。
  • R1 对外不新增 TM state feed 或 strategy seed contract。
  • 无动态状态时不伪造当前观点。
  • 后端相关 Go 测试通过。
  • 修改 server 后，server/ make lint 零告警。
  • 前端构建或相关 type check 通过。

12. 风险清单​

12.1 产品风险​

  • 把动态画像做成大段报告，团队仍然无法快速筛选。
  • 列表展示过多证据，破坏 KOL 间比较效率。
  • Drawer 信息分层不清，长期画像和当前状态混在一起。
  • TM bridge 过早显性化 performance，导致用户误读为 DH 质量分。

12.2 数据风险​

  • matchDynamicSignalKol 类型的名称匹配可能误绑定 KOL。
  • 24h rolling state 可能让用户误解为连续有效状态。
  • attachment-only / chart-only 消息解析不完整。
  • late-arrival 样本可能污染回测时间。
  • 转发、重复消息或团队频道被误认为独立 KOL。
  • broad macro view 被误升级为 symbol-level trade seed。

12.3 合同风险​

  • presentation summary 被 TM 当作稳定字段解析。
  • confidence_score 被下游误读为胜率。
  • 样本可回放 / dry-run 复核标签被误读为 live eligible。
  • TM PnL 回填污染 DH quality/confidence。
  • R1 外部接口过早承诺实时状态 feed，后续难以收回。

13. 最小实施计划​

Milestone 0: 设计冻结​

  • 本文档完成 review。
  • 用户确认 R1 scope。
  • 冻结 DH/TM 边界：R1 profile-detail 是内部 Workbench 合同，不是外部 TM state feed。
  • 冻结 confidence、freshness、replay eligibility 术语。
  • 做生产只读验证：确认 dn_kol_dynamic_state、supporting/contradicting event ids、dn_tm_source_meta、dn_tm_source_feedback、dn_kol_validation_feedback 覆盖度。

Milestone 1: R1-Backend-Contract​

  • 扩展 kol_control_room.api 的 profile-detail response。
  • 生成 API types。
  • 保留 legacy fallback，但禁止旧动态摘要伪造当前状态。

Milestone 2: R1-Dynamic-State-Assembler​

  • 实现 dynamic state assembler。
  • 单元测试覆盖 empty states、conflicted states、stale states、late-arrival states。

Milestone 3: R1-State-Evidence-Chain​

  • 实现 stateId 下钻。
  • 返回 supporting / contradicting / fallback relation。
  • 单元测试覆盖 state-scoped evidence 和 no-state fallback。

Milestone 4: R1-TM-Bridge-Overlay​

  • 实现只读 TM bridge assembler。
  • 不接写路径、不合并 PnL、不影响 DH confidence。
  • 单元测试覆盖 TM bridge empty/fill。

Milestone 5: R1-Workbench-UI​

  • API type 更新。
  • 列表动态状态字段接入。
  • Drawer 默认 tab 和 dynamic profile panel。
  • Evidence chain panel。
  • Static baseline / TM bridge 分区。
  • 保留旧字段 fallback。

Milestone 6: R1-Verification-Package​

  • Go 相关包测试。
  • server/ make lint。
  • 前端构建或 type check。
  • 浏览器手动验证：
    • Dashboard -> Workbench context。
    • Workbench list -> single KOL Drawer。
    • 动态状态 -> supporting/contradicting evidence。
    • 无动态状态 fallback。

14. 专家团结论汇总​

共识：

  • R1 应从 Workbench 当前形态出发，不新建孤立页面。
  • 动态画像必须结构化，不应压成 summary 文案。
  • 事件账本和动态读模型是正确地基。
  • confidence_score 必须保持信息侧语义。
  • TM performance 与 DH quality 必须分离。
  • 策略蒸馏需要后续分层：R1 evidence/event/state 原料，R2 hypothesis/rule/parameter/validation protocol，R3 asset/template/execution policy。

分歧或需要谨慎处：

  • Claude 建议 R1 对 TM 只交事件，不交聚合状态；架构评审认为 Workbench profile-detail 可以返回结构化状态。综合建议：R1 的 UI/内部 contract 可以展示状态；对外开放给 TM 的新增 state feed 延后到 R2。
  • UX 希望默认 Drawer 展示完整动态工作区；量化评审提醒“操作提及”必须标记不可执行或待验证。综合建议：UI 可以展示操作提炼，但必须使用感知层文案和样本复核标签。
  • Claude Opus 二次 review 明确要求先修文档边界再拆 issue；直接进入实现会把未决语义带入代码。

15. Spec 自检​

  • R1 边界明确：Workbench/profile-detail 是内部合同；对外 TM state/candidate feed 延后到 R2。
  • 待冻结字段已标出：confidence 展示、freshness basis、replay eligibility、fallback evidence。
  • 无实现越界：R1 不新增写路径，不修改交易反馈规则。
  • 无承诺越界：不承诺实时、收益、可实盘、策略资产。
  • Scope 可实施：后端 profile-detail 扩展 + Workbench UI 增强，可拆成小步提交。
  • 兼容现有实现：旧字段保留 fallback，新结构渐进接入。