DH-TM R4 小批量验证接入任务书

Curvature Labs · Trading Matrix
版本 v1.1 · 2026-07-01
状态：草稿 · 进行中
Owner：TM 工程（主），DH maintainer（协查）

与赛马看板 PRD 的边界
赛马看板 PRD v1.4 覆盖运营 UI 层：候选管理、五维候选包、推进（回测/跳过）、R3 candidate_validation 写回。
本文覆盖工程验证层：TM 接入 DH 候选读取、持久化、受控验证、candidate_backtest_result 写回、集成测试与 R4 验收。

一、R4 目标

证明 Trading Matrix 能稳定读取 Data Horizon 的 KOL 动态画像候选，完整保存身份字段，对少量受控候选完成验证，写回人和系统都能理解的真实反馈，并给出是否进入 R5 策略蒸馏的 go/no-go 判断。

R4 不证明：某个 KOL 策略已经可盈利；R4 不进入实盘。

二、前置条件（DH 侧已完成）

项	状态	证据
`dn_kol_candidate_validation_feedback` 表	✓ 生产已创建	`id=1` smoke 记录已写入
候选读取接口 `POST /v1/open/kol/dynamic-state/candidate-list`	✓ 已通过	smoke 输出 `OK: read-only R3 contract smoke passed`
反馈写入接口 `POST /v1/open/kol/candidate-validation/feedback`	✓ 已通过	`accepted=true`
错误密钥保护（Open API Key）	✓ 已通过	—
过期状态保护 / 重复写入保护	DH 自动化已覆盖	待 TM 集成复测
Woods 工作台回归	✓ 已通过（smoke 记录）	R4 真实反馈写回后需再次复核

三、R4 Pilot 候选批次

来源：DH 生产只读快照（2026-06-23）。当前生产无 action 候选，全为 risk/observe。

#	KOL	KOL ID	标的	类型	DH 状态	证据数	选择理由
1	所长	11	BTC	risk	conflicted	4	BTC 日内冲突样本，验证风险路径
2	Johnny	24	SOL	risk	conflicted	10	SOL 高证据风险样本，避免只测 BTC
3	Muzzagin	29	BTC	risk	conflicted	22	高冲突跨市场样本，验证分歧处理
4	Woods	32	ZEC	risk	conflicted	6	复用 Woods 上下文（不用之前 BTC smoke 候选）
5	P总	47	ETH	observe	active	15	ETH 高证据观察样本，验证正常消费路径
6	美股研究社	55	MSFT	observe	active	2	美股个股样本，验证非加密标的处理
7	美股投资网	58	SPY	observe	active	2	美股指数 / 宏观样本，验证周期和宏观范围
8	985学长	71	GOLD	observe	active	3	黄金样本，验证商品类标的处理

R4 不伪造 action 候选，等 DH 生产出现真实 action 候选后由运营在赛马看板操作。

四、TM 侧任务清单

T1 接入候选读取接口

目标：TM 后端能调用 DH 候选列表接口并解析返回结构。

通过标准：

使用已批准的 X-API-Key 调用 POST /v1/open/kol/dynamic-state/candidate-list
正确识别 candidate_contract_version 字段（用于版本兼容检测）
解析返回的候选列表，打印每条 candidate_id + kol_id + candidate_type + lifecycle_status
调用日志可审计

Owner：TM 工程

T2 持久化候选身份字段

目标：TM 本地完整保存每条候选的 DH 颁发身份字段，写回时必须原样带回。

必须持久化的字段：

字段	说明
`candidate_id`	DH 生成的候选稳定 ID
`state_id`	对应的动态状态 ID
`state_version`	状态版本号（写回时防止版本错位）
`state_hash`	状态内容哈希（写回时防止旧状态覆盖）
`kol_id`	KOL 在 DH 的稳定 ID
`source_ids`	信源 ID 列表
`symbol_bucket`	标的分组（如 `BTC`、`ETH`、`MSFT`）

通过标准：

上述 7 个字段全部存入 TM 本地表，不允许丢弃或覆盖
读取候选时 → 存入；写回时 → 原样携带（不重新生成）

Owner：TM 工程

T3 小批量验证 Runner

目标：对 T1 + T2 完成后的 8 条 pilot candidates，通过批量回测系统对历史信号做离线重放，各生成一个可解释的量化验证结果。

与赛马看板三层漏斗的关系：T3 的回测结果将作为 Layer 0（回测基线层）呈现在 KOL Drawer 中（见主 PRD v1.4 §4.3.5）。T3 已通过 DEV-07 与 /api/event-backtest 集成；R4 系统化验收记录待补。

约束：

结果不要求盈利，只要求结果可解释（知道 TM 对这条候选做了什么、学到了什么）
不进入实盘
不做全量 KOL 自动赛马
不把策略种子直接升级为策略资产

信号数据来源（D5 已解除阻塞，批量回测系统直接可用）：

接口	用途	状态
`GET /v1/open/profile/signals`	含 `direction / symbol / published_ts` 的结构化信号，回测方向准确率计算基础	✅ DH main 已上线
`POST /v1/open/event-stream`	原始事件总量（端到端命中率分母）	✅ DH main 已上线
TM K 线库（已有）	历史价格，验证 direction 是否准确（4h K 线收盘）	✅ 已有

批量回测接口契约（TM 赛马后端 → 批量回测系统）：

回测系统由 TM 工程独立开发/对接，与赛马看板后端通过以下契约解耦。R4 Pilot 阶段可用异步 callback 或 TM 主动轮询，正式集成后确认最终方式。

输入（TM 发送给回测系统）：

{
  "kol_id": 47,
  "source_ids": [101, 102],
  "symbol_bucket": "ETH",
  "backtest_window": "2025-06-01..2026-06-30",
  "candidate_id": "csc_001",
  "callback_url": "http://tm-api/internal/backtest/result/{task_id}"
}

输出（回测系统回传给 TM）：

{
  "kol_id": 47,
  "candidate_id": "csc_001",
  "win_rate": 0.61,
  "profit_factor": 1.8,
  "expectancy": 0.023,
  "max_drawdown": 0.12,
  "sample_trade_count": 187,
  "realized_style_drift": 0.18,
  "backtest_window": "2025-06-01..2026-06-30",
  "validation_status": "pass",
  "computed_at": 1751234567000
}

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`	`sample_trade_count < 10`，或指标居于 pass/fail 之间

R4 Pilot 建议回测窗口：2025-06-01..2026-06-30（近 12 个月，DH 候选数据覆盖范围）

通过标准：

8 条 pilot candidates 各生成一条回测结果，含 win_rate / profit_factor / max_drawdown / sample_trade_count / backtest_window
validation_status 按上表规则判定，非人工填写
回测结果已写入 TM 本地 tm_kol_backtest_result 表（供 T4 写回 DH 使用）
不能把 smoke 记录当作真实验证结论

Owner：TM 工程（批量回测系统）

T4 写回真实非 smoke 反馈

目标：对 T3 完成的验证结果，通过 R3 接口写回 DH（非 smoke 记录）。

写回规范：

字段	规范
`tm_run_id`	前缀使用 `tm_r4_pilot_`，格式 `tm_r4_pilot_{kol_id}_{timestamp}`
`feedback_id`	格式 `tm_r4_{candidate_id}_{timestamp}`，全局唯一，保证幂等
`feedback_type`	`candidate_backtest_result`（对齐主 PRD v1.4 §10.2；非 `validation_completed`）
`validation_phase`	`backtest`
`validation_status`	`pass` / `fail` / `unresolved`（按§4.8.4 阈值判定，或标注无法判定原因）
`validation_result_summary`	必须是人类可读句子（见 T6 要求），不能只写数字
`realized_style_drift`	按§4.8.2 公式计算，`sample_trade_count < 10` 时留空
`backtest_window`	实际验证时间段，例如 `2026-06-01..2026-06-23`
`sample_trade_count`	成交次数（0 时仍写回，但 drift 留空）
认证头	`X-API-Key` + `X-TM-Validation-Key` 均需携带

通过标准：

8 条 pilot candidates 各写回 1 条真实反馈，DH 返回 accepted=true
写回记录可在 DH 工作台看到（作为外部验证证据）

Owner：TM 工程（密钥由 DH maintainer 下发）

T5 集成测试覆盖

目标：确保 TM R3 客户端对 DH 的边界保护情形有明确处理。

必须覆盖的测试场景：

场景	预期行为
错误 `X-API-Key`	DH 返回 401，TM 记录 auth 错误，不重试
错误 `X-TM-Validation-Key`	DH 返回 401/403，TM 触发密钥过期告警（参见赛马看板 PRD §10.4）
过期状态（`state_hash` 不匹配）	DH 返回 `accepted=false`，TM 标注"写回失败，state 已过期"
重复 `feedback_id`（同内容）	DH 返回幂等接受（`accepted=true, reason=duplicate`），TM 视为成功
重复 `feedback_id`（不同内容）	DH 返回 `accepted=false`，TM 标注冲突，不覆盖
网络错误	TM 最多重试 3 次（指数退避），失败后标注"写回待同步"

通过标准：以上 6 个场景有测试记录（日志 / 单测 / 集成测试均可）

Owner：TM 工程

T6 validation_result_summary 规范

目标：每条候选的验证总结必须是人类可读的描述，供 DH 工作台展示和 DH 静态画像团队消费。

格式要求：

# 示例（observe 候选，ETH，P总）
"在 2026-06-01 至 2026-06-23 期间对 ETH 候选进行模拟验证，
共触发 12 次信号，执行 8 次，胜率 62%。
KOL 观察型候选，ETH 方向偏多，与 DH 画像描述基本一致。
当前结论：unresolved，样本不足以判断长期有效性，建议继续观察 30 天。"

# 示例（risk 候选，BTC，所长）
"在 2026-06-01 至 2026-06-23 期间对 BTC 风险候选进行 dry-run，
KOL lifecycle=conflicted，多空方向冲突，TM 执行 4 次信号，胜负各 2。
验证结论：fail（win_rate 50%，未达阈值且方向信号不稳定）。
建议：等 DH 状态恢复 active 后重新进入候选评估。"

禁止：只写指标数字（如 win_rate=0.62, drawdown=0.08），没有任何文字说明。

Owner：TM 工程（理解每条候选后撰写）

T7 联合复核 DH 工作台展示

目标：T4 写回后，DH + TM 联合确认 DH 工作台仍然只把 TM 反馈展示为外部验证证据，不影响 DH 可信度、排序或生命周期。

检查清单：

验证结果只出现在"外部验证证据"区，不出现在 DH 候选推荐排序中
validation_result_summary 文字在工作台可读
realized_style_drift 以 TM 外部数据形式展示，不影响 DH 画像可信度排序字段
工作台不显示"已可实盘"或"已成为策略资产"等字样
Woods（KOL 32）smoke 记录与 R4 真实记录在工作台能区分

Owner：DH maintainer（工作台）+ TM 工程（提供 feedback_id 列表）

T8 R4 验收记录 + R5 go/no-go

目标：输出 R4 结束后的联合验收记录，明确是否进入 R5 策略蒸馏。

验收记录包含：

# DH-TM R4 验收记录

日期：____
版本：____

## 候选处理结果

| # | KOL | candidate_id | feedback_id | validation_status | summary |
|---|---|---|---|---|---|
| 1 | 所长 | ksc_xxx | tm_r4_xxx | pass/fail/unresolved | __ |
...

## 集成测试结果（T5）

| 场景 | 结果 |
|---|---|
| 错误密钥 | ✓/✗ |
...

## 工作台展示复核（T7）

[ ] 通过 / [ ] 发现问题：____

## R5 go/no-go 判断

go：条件 ______
no-go：原因 ______
下一步：______

通过标准：记录已填写并由 DH + TM 双方确认

Owner：DH maintainer + TM 工程联合输出

五、任务优先级与建议顺序

T1（接口集成）→ T2（身份持久化）→ T3（验证 runner）
     ↓
T4（写回真实反馈）+ T5（集成测试）+ T6（summary 规范）
     ↓
T7（工作台联合复核）→ T8（验收记录 + R5 判断）

T1 + T2 是硬前置，不完成则后续无法推进。
T5 集成测试可与 T4 并行进行。
T6 summary 在 T3 完成后立即撰写，不要等 T4。

六、与赛马看板 PRD 的接口说明

R4 工程接入与赛马看板 UI 共享以下契约，需保持一致：

接口 / 字段	赛马看板 PRD 引用	R4 任务使用
`POST /v1/open/kol/candidate-validation/feedback`	§十 TM→DH 写回映射	T4 写回真实反馈
`feedback_type=candidate_backtest_result`	主 PRD v1.4 §10.2	T4
`candidate_validation`（运营 admit/observe/defer）	主 PRD v1.4 §10.2	赛马看板 UI（DEV-03）
`realized_style_drift` 计算公式	§4.8.2	T4
`pass/fail/unresolved` 判定阈值	§4.8.4	T3 + T4
`X-API-Key` + `X-TM-Validation-Key` 双认证	§10.1	T4 + T5
`feedback_id` 幂等格式	§10.4	T4 + T5

赛马看板 PRD 不覆盖的内容（本文负责）：

TM 后端候选读取的集成实现（非 UI）
候选身份字段本地持久化表结构
验证 runner（T3）的具体实现方式
validation_result_summary 内容标准（T6）
R4 验收记录格式（T8）

七、开放问题

#	问题	Owner	期望
Q1	~~`feedback_type` 枚举~~	@DH maintainer	✅ 已关闭：见主 PRD v1.4 §10.2 / §6.4
Q2	~~`candidate_status` vs `candidate_type`~~	@DH maintainer	✅ 已关闭：读 `candidate_type`；忽略 `candidate_status`
Q3	批量回测集成方式	@TM 工程	✅ callback + event-backtest 批量任务（DEV-07 @ 2026-07-01）
Q4	R4 结束后，smoke 记录（`feedback_id=tm_r3_smoke_ksc_…`）是否需要从生产表中清理	@DB 权限成员	T8 前确认
Q5	批量回测系统是否直接接入 DH `profile/signals` 接口自行拉信号，还是 TM 赛马后端预处理后传给回测系统？建议：回测系统直接用 `source_ids` 调 DH，避免 TM 中间层成为瓶颈	@TM 工程（批量回测）+ @DH maintainer	T3 前确认
Q6	R4 `backtest_window`：统一固定 vs 按 `last_evidence_at` 动态	@TM 工程	✅ 动态 12 个月 + clamp `[2025-06-01, 2026-06-30]`（主 PRD §4.3.5.2）

八、参考文档

文档	位置
DH KOL 动态画像进展（2026-06-23）	外部文档
DH KOL 静/动态画像方案（2026-06-19）	外部文档
赛马看板 KOL 画像集成 PRD v1.4	Gov co-request
赛马看板工程交付状态	Gov co-request
赛马看板 PRD v1.2 修订计划	clabs `requirement/归因追踪/赛马看板-PRD-v1.2-修订计划.md`
候选管理技术实施方案	clabs `docs/raceboard_candidate_impl_plan.md`
R4 验收记录模板（T8）	本文 §四 T8

一、R4 目标​

二、前置条件（DH 侧已完成）​

三、R4 Pilot 候选批次​

四、TM 侧任务清单​

T1 接入候选读取接口​

T2 持久化候选身份字段​

T3 小批量验证 Runner​

T4 写回真实非 smoke 反馈​

T5 集成测试覆盖​

T6 validation_result_summary 规范​

T7 联合复核 DH 工作台展示​

T8 R4 验收记录 + R5 go/no-go​

五、任务优先级与建议顺序​

六、与赛马看板 PRD 的接口说明​

七、开放问题​

八、参考文档​

一、R4 目标

二、前置条件（DH 侧已完成）

三、R4 Pilot 候选批次

四、TM 侧任务清单

T1 接入候选读取接口

T2 持久化候选身份字段

T3 小批量验证 Runner

T4 写回真实非 smoke 反馈

T5 集成测试覆盖

T6 validation_result_summary 规范

T7 联合复核 DH 工作台展示

T8 R4 验收记录 + R5 go/no-go

五、任务优先级与建议顺序

六、与赛马看板 PRD 的接口说明

七、开放问题

八、参考文档