Trading Matrix · 第一阶段执行总结
文档定位：本文以 Gov 业务闭环为参照坐标，总结第一阶段实际完成的内容、踩过的坑，以及可复用的 KOL 筛选与归因框架。Gov 是方向，不是约束——凡本地实践与 Gov 描述有出入的地方，均以真实执行数据为准，并说明原因。
0. 主方向：用最低成本跑通一条可扩展的 KOL 信号→策略资产 闭环
Gov 定义的业务闭环
信号输入 → 策略种子整理 → AI 交易员验证 → 赛马筛选 → 策略资产沉淀 → 反馈回流
本阶段实际跑通的路径
KOL 信号（Discord）
↓ DH 采集（dn_raw_news）
↓ dn_raw_news_direct 路由推送
↓ TM 接收（tm_event_log）
↓ AI 决策（tm_decision + cot_trace）
↓ 交易执行（tm_position / tm_order）
↓ 归因脚本（Python → 8 张报表）
↓ PM 复盘（接入/降级/剔除决策）
[未跑通] 策略资产状态机 → [未跑通] TM 反馈回写 DH
核心结论
本阶段最重要的发现不是哪个 KOL 胜率高，而是：
- 85% 的随机 KOL 对自动交易没有实质贡献。信源筛选是杠杆率最高的环节，比调 prompt 重要得多。
- 归因链路的精确性决定了赛马公平性。早期的时间窗口匹配方案会导致串数据；精确 ID 穿线是基础设施。
- 门槛控制比排名更重要。5 条 position 不排名，10 条做初评，30 条做正式评级——这个约束防止了大量误判。
1. 本地工作总结
1.1 信源筛选（对应 Gov DH-1 ~ DH-5）
已完成
| 任务 | 完成情况 |
|---|---|
| DH-1 信源名单 | ✅ 65 个 KOL 完成 AI 辅助初筛；dn_kol + dn_crawler_source 已有稳定 source_id |
| DH-2 样本记录保真 | ⚠️ dn_raw_news 保存原始内容 + MD5 hash；缺 sample_id / captured_at / parse_status |
| DH-3 信源画像 | ⚠️ content_type 已标注；缺 market_scope / signal_style / active_status 动态标签 |
| DH-4 质量初评 | ✅ dh_quality_grade A/B/C/D 已建立，基于样本证据而非主观印象 |
| DH-5 候选推荐与交接 | ✅ DH→TM 直推已配置（dn_raw_news_direct）；缺 TM 反馈回写 DH |
| DH-6 动态后台 | ❌ 无动态候选列表，信源变更依赖人工配置 |
筛选结果（65 个 KOL，截至 2026 年 4 月）
| dh_quality_grade | 主导 content_type | 数量 | 占比 | 接入状态 |
|---|---|---|---|---|
| A 优先验证 | 明确交易信号为主（≥40%） | 10 | 15% | 已接入 TM，8 个运行中 |
| B 继续观察 | 混合内容为主 | 8 | 12% | 4 个已接入 TM，参数差异化 |
| C 低优先级 | 信号稀疏 / 格式不稳 | 15 | 23% | 维持 DH，暂不接入 TM |
| D 暂不适合 | 观点分析 / 复盘 / 非交易内容为主 | 32 | 49% | 维持 DH 展示，不接入 TM |
关键发现：不做筛选直接接入的代价是 85% 的 API 调用被纯噪音消耗。筛选卡在「信源」层比卡在「prompt 过滤」层便宜 10 倍。
1.2 执行层（TM System Prompt 迭代）
| 版本 | 核心解决的真实问题 |
|---|---|
| v2 → v3.0 | 基础执行结构建立；确定 6 种 action 边界 |
| v3.1 → v3.2 | 坑：KOL 复盘播报被误识别为新信号开仓。修复：加强 progress_recap 拦截规则 |
| v3.3.1（详细规则版） | 坑：cancel_and_replace / adjust_stop_loss 等非标 action 导致整单 validation failed。修复：Validator 白名单对齐；新增回归用例库防止回归 |
| v3.4.2（当前生产） | 改为口语化逻辑体叙述，去掉枚举清单；降低维护成本，提升泛化能力 |
prompt 两部分拆分（工程实践）
第一部分（进 system prompt，约 270 行）
└── 执行逻辑：角色 / 频率 / 上下文 / 风控 / JSON 输出格式
第二部分（不进 prompt，内部文档）
└── KOL 个性化说明 + 回归测试用例 + 技术待办 + 能力缺口对照
这个拆分方式防止了 prompt 越迭代越臃肿的问题，并保留了完整的回归用例库用于版本升级验证。
反幻觉硬约束（v3.3 起写入 prompt）
- context_event_ids 只能引用输入中确实存在的 event_id，严禁编造
- 不允许跨 KOL 继承上下文
- 不允许从已平仓 / 复盘 / 旧单截图继承开仓参数
- 若无 Recent Event History，强制 context_used=false
1.3 归因链路（端对端验证 + 历史问题修复）
精确穿线路径（当前生效）
tm_position.id
→ tm_order.related_position_id
→ tm_order.event_id
→ tm_event_log.event_id
→ tm_decision.id
→ tm_decision.event_id = "dh-direct-{N}"（提取 N）
→ dn_raw_news.id = N
→ dn_raw_news.source_id → dn_crawler_source.kol_id → dn_kol.id
踩过的坑
| 问题 | 旧方案 | 新方案 | 教训 |
|---|---|---|---|
| position → event 断链 | 时间窗口 ±30 秒匹配 | tm_order.related_position_id + event_id | 时间窗口在高频场景下必然串数据 |
| KOL 删帖证据消失 | 无 | tm_decision.input_prompt 嵌入原文 + dn_raw_news.news_id MD5 hash | 不做保全就是幸存者偏差 |
| AI 决策失败分类模糊 | 人工阅读 | failure_category / failure_subtype 自动枚举 | 问题不分类就无法系统性修复 |
已识别的失败类型分类
API 429（上游饱和） → 最常见（2026-05-05~18 期间占 78.3%）
校验失败：非法 action → 需 Validator 白名单对齐
校验失败：JSON 解析 → prompt JSON 格式约束问题
校验失败：SL/TP 无效 → 止损止盈反推边界问题
1.4 归因自动化（替代每周 3–4 小时人工）
8 张报表（Python + Jinja2 自动生成）
| 报表 | 内容 |
|---|---|
| 1. Position 主表 | 每条持仓的完整链路：KOL → 信号 → 决策 → 执行 → 结果 |
| 2. 原始信号明细 | event_log + decision + 原始信号内容 |
| 3. KOL 漏斗 | triggered / rejected / failed 分层漏斗 |
| 4. AI 决策分析 | action 分布、置信度、wait/hold 原因分类 |
| 5. 失败明细 | 按类型 + KOL + 时间段分类的失败清单 |
| 6. Wait/Hold 分析 | 关键词分类（Phase 2 升级为 LLM 分类） |
| 7. 汇总看板 | 本周概览 + KOL 持仓结果 + 样本进度条 |
| 8. 功能效果评估 | AI 个性化功能对执行质量的影响评估 |
三层 Agent 分工（设计完成，工程实现进行中）
Layer 1 完全自动化 → 数据采集 / 指标计算 / 失败检测 / 报表草稿
Layer 2 半自动辅助 → Wait/Hold LLM 分类 / 信号质量评分（PM review）
Layer 3 纯人工保留 → KOL 接入/降级/剔除决策 / 新型异常模式首次判断
1.5 赛马积分板（设计完成，运营化待建）
两阶段指标体系
| 阶段 | 状态 | 核心指标 |
|---|---|---|
| Phase 1–2（当前） | 简化版已跑通 | 胜率 / 平均 pnl_u / 执行率 / 置信度 / 样本进度 |
| Phase 3（规划） | 依赖气候打标 | Alpha（pnl_pct − btc_pct_in_window）/ 条件化胜率 / 气候矩阵 |
公平性约束（已执行）
- 跨 KOL 参数（杠杆 / 仓位比例 / 信心度）强制统一，防止赛马基准错位
custom_prompt只允许差异化解析提示，不允许差异化执行参数- 阶段门槛：
initial_eval（10 条）→formal_eval（30 条）→race（200 条）
现状问题：当前赛马数据只能从报表 7 + CSV 手工拼读，PM 无法直接从单一界面做运营决策。
1.6 实盘运行证据（多轮归因）
| 轮次 | 日期 | 关键数字 | 关键发现 |
|---|---|---|---|
| 第一轮 | 2026-04-07 | 5 条 position | P0 Bug 发现：API key 废弃（44 条信号全失败）+ 最小开仓金额不一致 |
| 第二轮 | 2026-04-13 | 45 条 failed 分析 | Bug 修复后补数据，identified failed 类型分类方案 |
| 第三轮 | 2026-04-22 | KOL 漏斗对比 | Wait/Hold 原因分布首次系统化 |
| 第四轮 | 2026-04-27 | 8 张报表首次全自动 | 自动化脚本上线，人工耗时从 3–4h → < 30 分钟 |
| 第五轮 | 2026-05-01–10 | 人工标注 + 归因框架修订 | v3.3 prompt 修订依据 |
| 第六轮 | 2026-05-05–18 | 131 条决策 / 23 条失败（17.6%）/ 2 条 position | API 429 是当前主要失败原因 |
2. 对照 Gov 业务闭环：完成度 + 差距
2.1 TM 产品定义 P0/P1 验收
| Gov P0/P1 | 本地状态 | 说明 |
|---|---|---|
| P0：DH 两类核心输入稳定进入系统 | ✅ 已跑通 | KOL 信号 + 事件新闻，链路端对端验证 |
| P0：AI 交易员可绑定账户并运行策略 | ✅ 已跑通 | 13 个 AI 交易员，100U 实盘运行 |
| P0：小资金真实实盘验证可持续 | ✅ 已跑通 | 6 轮归因，数据持续积累 |
| P0：赛马看板可用于运营决策 | ⚠️ 部分 | 数据有，看板不成产品；PM 每次都要手工合并 CSV |
| P0：策略候选池 / 观察池 / 失败案例库形成 | ❌ 未完成 | 失败有分类，但无状态机；无法资产化 |
| P1：其他外部信源接入能力 | ⚠️ 架构保留 | dn_raw_news_direct 可接多源，但无标准化多源接入文档 |
| P1：核心策略库入库复核流程 | ❌ 未完成 | 无策略入库机制 |
2.2 DH 任务书（DH-1~6）验收
| DH 任务 | 完成度 | 主要缺口 |
|---|---|---|
| DH-1 信源名单（可导入、去重、状态化） | 85% | 缺稳定 source_id ↔ dn_kol.id 对外暴露；无 active_status 状态字段 |
| DH-2 样本原始记录保真 | 60% | 缺 sample_id / captured_at（抓取时间）/ parse_status |
| DH-3 信源画像动态标签 | 50% | content_type 已有；缺 market_scope / signal_style / active_window |
| DH-4 质量初评（A/B/C/D） | 90% | 已建立；初评理由记录在文档，未写进 dn_kol 字段 dh_quality_reason |
| DH-5 候选推荐与 TM 交接 | 70% | 交接已完成；TM 反馈（tm_seed_status / tm_validation_status）未回写 DH |
| DH-6 动态后台与接口 | 0% | 完全依赖人工配置；无增量机制 |
2.3 真实执行 vs Gov 描述的出入
Gov 描述的是理想流程；以下是实际执行中有意不一样的地方，以及原因：
| 出入点 | Gov 描述 | 本地做法 | 原因 |
|---|---|---|---|
| 策略种子显式化 | 每个输入被整理成「策略种子」对象 | 每条 event_log 是隐式种子，无独立对象 | 当前规模不需要独立对象，信号即种子 |
| 信源自动发现 | DH 负责发现 + 登记 | PM 人工维护候选名单 | 当前信源质量比规模更重要；规模化后再自动化 |
| 回测 / 模拟盘 | 进真实实盘前先跑回测 | 直接小资金实盘（100U） | KOL 信号时效性强，回测数据难以还原；用小资金实盘替代 |
| 策略工厂批量化 | 批量创建 AI 交易员 | 手动配置每个 trader | 当前信源数量在 10~15 个，不值得建批量工厂 |
3. 可复用的 KOL 筛选与归因框架
本节是本阶段实践的核心产出，可直接用于新信源接入，也可在生态内其他产品复用。
3.1 四步信源筛选 SOP
适用场景：任何需要从一批 KOL / 分析师 / 信号源中筛出可接入自动交易系统的信源。
Step 1：内容类型统计（30 条样本）
├── 明确交易信号占比 ≥ 40% → 进 Step 2
└── 否则 → dh_quality_grade = B 或 D，停止
Step 2：解析测试（10 条样本，逐条 AI 模拟解析）
├── 通过率（可执行决策 / 总条数）≥ 70% → 进 Step 3
└── 否则 → dh_quality_grade = B，停止
Step 3：噪音比例评估
├── 推广 / 情绪 / 非加密 / 截图内容 ≤ 30% → 进 Step 4
└── 否则 → dh_quality_grade = B，停止
Step 4：接入配置
├── 通过全部三步 → dh_quality_grade = A，配置 dn_raw_news_direct + trader
└── 停在 Step 3 → dh_quality_grade = B，可配置「混合内容」trader（保守参数）
关键经验：
- Step 2 的解析测试比内容统计更重要；KOL 口语化表达差异大，统计数字好看但解析率低的不罕见
- Step 3 的噪音阈值 30% 是真实实盘数据反推出来的；超过此比例时 API 成本上升明显
- 不要跳过门槛直接接入「试试看」——首轮数据证明，系统性 Bug + 样本不足会让数据完全无意义
3.2 两阶段实盘验证门槛
适用场景：对已接入 TM 的信源进行信号质量评级。
initial_eval（1~10 条 position）
└── 目标：验证系统兼容性（信号能被解析执行）
└── 输出：执行率、AI 决策评分、失败类型
└── 不做：胜率排名（样本量无统计意义）
formal_eval（11~30 条 position）
└── 目标：初步信号质量评级
└── 输出：简化胜率、平均 pnl_u、wait/hold 原因分布
└── 可做：初步接入/继续/降级判断
race（31~200 条 position）
└── 目标：跨 KOL 赛马比较
└── 输出：条件化指标（Phase 3 需气候打标支持）
└── 可做：升级到核心策略候选 / 淘汰 / 进失败案例库
关键经验：
- 首轮 5 条 position 时做排名是错的；我们有两个 KOL 零数据不是因为信号差，是因为 API Bug
- 10 条是最低可信阈值；30 条才能区分运气和真实信号质量
- 不同 KOL 参数（杠杆、仓位比例）必须一致，否则赛马没意义
3.3 精确归因链路（防止数据断链和幸存者偏差）
核心原则：每一条 position 必须能追溯到 KOL 原始发言原文。
必须有的穿线字段：
tm_position.id → tm_order.related_position_id（新增字段，非时间窗口）
tm_order.event_id → tm_event_log.event_id
tm_event_log.decision_id → tm_decision.id
tm_decision.event_id = "dh-direct-{N}" → dn_raw_news.id = N
必须有的原始证据：
dn_raw_news.news_id = MD5(content) # 内容唯一标识，防重复
tm_decision.input_prompt # 嵌入 KOL 原始发言，防删帖
tm_decision.cot_trace # AI 推理链，可审查
反模式：
- ❌ 用时间窗口 ±30 秒匹配 position 和 event（高频场景必然串数据）
- ❌ 只保存 AI 决策，不保存原始信号（删帖后无法还原）
- ❌ 用 KOL 名称字符串关联（名称可能重复或变更）
3.4 归因报表的可规模化结构
当前 8 张报表的生成逻辑可以作为模板复用：
输入（6 条 SQL → Pandas DataFrame）
├── 1. position 主表（含 realized_pnl、close_reason、trader_id）
├── 2. event_log（triggered / rejected / failed）
├── 3. decision（action、confidence、cot_trace）
├── 4. order（entry_price、status、related_position_id）
├── 5. dn_raw_news（原始信号内容、source_timestamp）
└── 6. dn_kol（KOL 名称、市场、风格）
处理层（Python）
├── 穿线合并（精确 ID 路径）
├── 失败分类（failure_category / failure_subtype）
├── 指标计算（执行率、简化胜率、wait/hold 分布）
└── 样本进度（距离 initial_eval / formal_eval / race 门槛）
输出（Jinja2 → Markdown）
├── 汇总报表（人读）
├── 主表 CSV（可导入 Excel 二次分析）
└── 结构化 JSON（可对接看板或 API）
扩展到更多信源时需要改动的地方：
- 调整 SQL 的
trader_id过滤范围（支持批量信源） - 增加按
dh_quality_grade分组的统计视图 - Phase 3 增加
market_climate_at_signal分组
3.5 失败问题库（避免重复踩坑）
| 问题 | 根因 | 修复方案 | 已修复？ |
|---|---|---|---|
| API key 废弃导致整批信号失败 | 没有 API key 健康检测机制 | 接入前先验 key 有效性；失败立即告警 | ✅ |
| 最小开仓金额不一致 | AI 决策层和执行层对最小金额定义不同 | 统一 prompt 和 Validator 中的金额下限 | ✅ |
cancel_and_replace 等非法 action | Validator 白名单未覆盖 KOL 自然语言中的操作意图 | 明确列举合法 action 白名单；非白名单不进 prompt | ✅ |
| 进度播报被识别为新开仓信号 | 「已涨 8.7%，移止损」含方向信息，AI 误判 | 加强 progress_recap 拦截；含「已」「移」「达成」的归为复盘 | ✅ |
| 跨 KOL 上下文继承 | AI 复用了同 session 中其他 KOL 的历史消息 | 硬约束：context_event_ids 只能引用当前 KOL 的历史 | ✅ |
| API 429 批量失败 | 高频 KOL（峰哥）+ 同一窗口多个 trader 同时调用 LLM | 增加 rate limit 队列 / 降低触发频率 | ⚠️ 部分 |
| position 和 event 断链 | 时间窗口匹配在并发场景下失效 | tm_order 新增 related_position_id + event_id | ✅ |
| 止盈待定不开仓 | KOL 发出方向+入场但未给止盈时，AI 等待止盈确认 | 明确规则：有止损可开仓；止盈允许 AI 按 RR≥3:1 反推 | ✅ |
4. 本地实践中值得保留的方法（不依赖 Gov 描述）
这些是 Gov 文档没有详细描述，但在实际执行中证明有价值的实践：
4.1 「信号质量先于 prompt 优化」原则
Gov 描述了信源初评，但没有强调这个优先级。实际证明：
- 用 10 倍时间优化 prompt 处理低质量信号，不如用 1 倍时间把低质量信源剔除
dh_quality_grade D的信源不是 prompt 能救活的- 筛选是 scalable 的；prompt patch 是 case-by-case 的
4.2 「删帖证据保全」方案
Gov 要求保留原始记录，但没有说怎么做。本地做法：
dn_raw_news.news_id = MD5(content)：防重复计数tm_decision.input_prompt：AI 收到的原始完整 prompt（含 KOL 发言全文）- 即使 KOL 删帖，TM 侧仍有原文存档，归因不会断
4.3 「参数统一才能赛马」约束
Gov 说要赛马，但没有说怎么保证公平。本地做法：
- 所有 KOL 的杠杆、仓位比例、信心度阈值在启动前统一配置
custom_prompt只允许差异化解析规则，不允许差异化资金参数- 这个约束在 v3 系列 prompt 中已经写入执行规范
4.4 「分层 Agent + 人工保留决策」架构
Gov 的 DH Agent 设计侧重输出接口，本地归因 Agent 侧重执行与审核分离：
- 机器做生成、统计、分类（Layer 1–2）
- 人做判断：接入/降级/剔除，以及首次出现的新型异常（Layer 3）
- 这个边界防止了 Agent 自我验证自己的分析结论
4.5 「门槛控制」而非「排名优先」
实际碰过的问题：首轮 5 条 position，团队本能地想看哪个 KOL 「赢了」。数据证明这没有意义——有 KOL 零数据是因为 API Bug，不是信号质量问题。
原则：initial_eval 阶段不做排名，只做系统兼容性验证；10 条以下数据标注「样本不足」。
5. 后续执行方案
5.1 近期任务（W1–4，不依赖新开发）
T1 · 赛马看板运营化（P0 缺口，优先级最高）
目标：PM 每周复盘有单一入口，不依赖手工拼 CSV。
- 将报表 7 结构升级为 Web 可读静态看板
- 增加 KOL 阶段状态 + 距离下一档进度条
- 运营决策动作（升级 / 降级 / 暂停）可在界面中标注
T2 · 策略资产状态枚举（P0 缺口）
目标：为 KOL/AI 交易员挂上「观察中 / 候选 / 暂停 / 失败案例」状态。
- 在
dn_kol或tm_trader增加asset_status枚举字段 - 不需要完整策略工厂；先用轻量状态字段补完 Gov P0 缺口
T3 · DH-3 信源画像补全
- 在
dn_kol补充market_scope/signal_style/active_status - 基于现有 65 KOL 初筛数据回填
- 对齐 Gov DH-3 验收标准
5.2 中期任务（W5–12）
T4 · TM → DH 反馈回写（闭环最关键缺口）
目标：DH 能看到 TM 对每个信源的验证结论。
最小实现：
dn_kol / dn_crawler_source 新增字段：
tm_seed_status # 是否已生成策略种子
tm_validation_status # 是否进入实盘验证
tm_asset_status # 观察/候选/暂停/失败案例
tm_feedback_reason # 反馈原因
tm_last_feedback_at # 最近反馈时间
第一阶段：PM 人工填写（对照归因报表）
第二阶段：归因脚本自动写回
第三阶段：API 接口（POST /dh/trading-matrix-feedback）
T5 · 样本字段扩展（DH-2 对齐）
dn_raw_news补充sample_id/captured_at/parse_status- 为后续 DH-6 动态接口提供字段基础
T6 · Wait/Hold LLM 自动分类（Phase 2 归因）
- 当前关键词分类产生 30–40% UNKNOWN，需人工标注
- 升级为 LLM 读取
cot_trace→ 输出分类 + 置信度 - PM 只 review 低置信度条目
5.3 阶段三（W12+）
T7 · Alpha + 市场气候打标（Phase 3 赛马）
- 接入 BTC 4H 行情，计算
btc_pct_in_window - 实现气候状态分类（
market_climate_at_signal） - 赛马指标从简化胜率升级为条件化 Alpha
T8 · DH 动态后台与接口（DH-6）
- 信源候选动态列表（不依赖人工复制）
- 增量拉取 + TM 反馈字段回写位置
GET /dh/trading-sources/GET /dh/trading-signals/POST /dh/trading-matrix-feedback
5.4 执行优先级矩阵
| 任务 | 对应 Gov 缺口 | 业务影响 | 实施难度 | 优先级 |
|---|---|---|---|---|
| T1 赛马看板运营化 | P0 看板缺口 | 高 | 中 | 🔴 立即 |
| T2 策略资产状态枚举 | P0 资产库缺口 | 高 | 低 | 🔴 立即 |
| T3 DH-3 画像补全 | DH-3 缺口 | 中 | 低 | 🟠 近期 |
| T4 TM→DH 反馈回写 | DH-5 缺口 / 业务闭环 | 高 | 中 | 🟠 近期 |
| T5 样本字段扩展 | DH-2 缺口 | 中 | 低 | 🟠 近期 |
| T6 LLM Wait/Hold 分类 | 归因自动化 | 中 | 中 | 🟡 中期 |
| T7 Alpha / 气候打标 | Phase 3 赛马 | 高 | 高 | 🟢 长期 |
| T8 DH 动态后台 | DH-6 缺口 | 中 | 高 | 🟢 长期 |
附录：核心文档索引（clabs）
| 文档 | 路径 | 内容 |
|---|---|---|
| 信源术语定义 | requirement/KOL信号源分类/术语与Gov对齐.md | content_type + dh_quality_grade 权威定义 |
| 信源接入 SOP | requirement/KOL信号源分类/KOL信源接入标准_v2.md | 四步筛选 + 两阶段验证门槛 |
| 65 KOL 初筛结果 | requirement/KOL信号源分类/KOL全量初筛分类报表.md | 分类结果 + 接入状态 |
| 归因链路框架 | requirement/归因追踪/KOL归因追踪框架.md | 穿线路径 + 字段验证 + SQL 示例 |
| 赛马积分板需求 | requirement/归因追踪/赛马积分板需求.md | Phase 1–3 指标体系 + 公平性约束 |
| 市场气候打标 | requirement/归因追踪/市场气候打标需求.md | Phase 3 Alpha 前置依赖 |
| 归因 Agent 设计 | requirement/归因追踪/归因分析自动化Agent设计方案.md | 三层分工 + 生成-审核分离原则 |
| TM 生产 prompt | requirement/TM event trading/system_prompt_v3.4_完整版.md | 当前线上版本（口语逻辑体） |
| TM 回归 prompt | requirement/TM event trading/system_prompt_v3.3_完整版.md | 详细规则 + 回归用例库 |
| Gov 对照差距表 | docs/GOV_VS_CLABS_KOL_ATTRIBUTION.md | 完整差距审计 |
本文为 clabs 内部工作文档，可作为 Gov projects/trading-matrix/execution/ L1 草稿依据，正式回写须按变更协议提议。