AI-Trader/change.md

AI-Trader 金融能力扩展设计稿

1. 文档目的

本文档用于记录 AI-Trader 后续要增加的金融能力扩展方案。

本次方案的来源是参考 ./worldmonitor 中与金融市场相关的产品能力，但 不复制任何代码，不移植任何源文件，不直接复用其架构实现。AI-Trader 中新增的所有能力都需要在当前仓库内重新设计、重新实现，以保持当前项目的 MIT 路线。

本文档当前只做规划，不开始开发。

---

2. 许可与边界

2.1 基本结论

• worldmonitor 本地仓库许可证为 AGPL-3.0-only
• AI-Trader 目标保持 MIT 路线
• 因此不能把 worldmonitor 的源码直接抽取到 AI-Trader 中

2.2 明确禁止事项

以下行为不允许：

• 直接复制 worldmonitor 的后端实现文件
• 直接复制 worldmonitor 的前端组件、配置、proto、seed 脚本、Redis 快照逻辑
• 在 AI-Trader 中保留能明显识别为 worldmonitor 派生实现的代码结构
• 把 worldmonitor 的整套金融 variant 逻辑搬进 AI-Trader

2.3 允许的参考方式

以下行为允许：

• 参考其产品分层方式
• 参考其金融能力拆分方式
• 参考其字段设计和页面组织思路
• 参考其“哪些能力值得做、如何组合成用户价值”
• 参考其数据更新节奏和缓存思路

2.4 实施原则

所有新增功能必须满足：

• 在 AI-Trader 内部重新设计接口
• 在 AI-Trader 内部重新实现后端逻辑
• 在 AI-Trader 内部重新设计数据结构
• 单独核查所依赖的数据源和第三方服务条款

2.5 性能与刷新硬约束

这是本次金融能力扩展的强约束，后续实现不得违反：

• 所有金融能力都必须基于统一快照
• 所有快照只能由服务器后台任务统一刷新
• 前端页面只能读取已有快照
• 对外 API 只能读取已有快照
• 禁止任何用户触发型更新
• 禁止任何“请求到达时顺手刷新外部数据”的逻辑
• 禁止任何“用户点击某按钮后实时抓外部数据并计算结果”的逻辑

换句话说：

• 用户只能读
• 服务器后台统一写
• 前端和 API 一律只做只读展示

---

3. 总体目标

AI-Trader 当前的核心是：

• 讨论
• 策略
• 实时交易
• 跟单
• Agent 注册与 heartbeat 通知

后续金融扩展的目标，不是把 AI-Trader 做成另一个 worldmonitor，也不是做成宏观情报地图，而是把 AI-Trader 从“社交纸上交易平台”升级成“社交交易 + 金融智能辅助平台”。

3.1 新目标能力

扩展后，AI-Trader 应该具备：

• 在下单前提供更强的市场上下文
• 在发策略前提供更强的标的分析能力
• 为 crypto / stock agent 提供更好的结构化金融信号
• 将分析结果沉淀成可复用的快照，而不是一次性展示
• 让分析结果能流入讨论、策略、交易、跟单、通知和 heartbeat
• 提供一个独立的“金融事件看板”页面，让用户统一查看所有金融快照模块

3.2 不追求的目标

本轮不追求：

• 世界地图可视化
• 大规模地缘政治 OSINT 平台
• 复杂地图图层和 variant 系统
• worldmonitor 那种大而全的多领域情报产品

---

4. 建议抽取的能力范围

4.1 第一阶段：优先做、收益最高

A. 宏观信号面板

目标：

• 为交易员和 agent 提供一个简洁的市场状态摘要
• 让用户在下单前先看到市场处于 risk-on / risk-off / neutral 哪种状态

建议输出：

• 总体结论：bullish / neutral / defensive
• 细分指标：
  • BTC 趋势
  • QQQ 相对防御资产的表现
  • 流动性代理指标
  • 市场情绪（Fear & Greed）
  • 可选：美元强弱、黄金风险偏好对照

使用场景：

• 交易页下单前提示
• 策略页发帖前参考
• agent 在 heartbeat 后决定是否继续开仓

B. 个股分析快照

目标：

• 给 AI-Trader 增加“分析这个标的”的能力
• 不只显示价格，而是给出结构化交易判断

建议输出：

• 当前价格
• 最近涨跌幅
• MA5 / MA10 / MA20 / MA60
• 趋势判断
• 支撑 / 压力位估计
• 总结性信号：buy / hold / watch / sell
• 多头因素
• 风险因素

使用场景：

• 交易页展示该 symbol 已生成分析快照
• 策略页发帖时附带分析结果
• 讨论页围绕某个 symbol 发起讨论

C. 个股分析历史

目标：

• 将分析结果沉淀为可追踪历史，而不是只做即时结果

建议作用：

• 展示某个 symbol 最近几次分析
• 支撑“过去怎么看、现在怎么看”的对比
• 后续为 backtest 和 agent 绩效复盘打基础

D. 金融新闻聚合

目标：

• 为交易、讨论和策略提供统一的新闻上下文
• 让用户和 agent 能快速看到当前最值得关注的市场事件

建议范围：

• 美股新闻
• 宏观新闻
• crypto 新闻
• 商品新闻

建议输出：

• 分类后的重点新闻列表
• 每条新闻的标题、时间、来源、摘要
• 关联 symbol / market 标签
• 情绪或方向标签（若数据源可提供）

限制：

• 第一阶段不做成大新闻门户
• 只做交易相关高价值聚合
• 所有新闻都必须来自后台统一快照，不允许前端按需抓取

D.1 第一阶段主数据源

第一阶段默认使用：

• Alpha Vantage NEWS_SENTIMENT

官方能力范围（按当前文档）支持：

• tickers
• topics
• time_from
• time_to
• sort
• limit

设计结论：

• 第一阶段新闻聚合以 Alpha Vantage 为主
• 暂不引入 CoinGecko
• 暂不做用户点击后即时抓取
• 若后续需要更广的新闻覆盖，再补 RSS / 新闻聚合层

D.2 分类方式

第一阶段统一分成 4 类：

1. equities

• 使用 topics=financial_markets
• 目标：股票、ETF、公司市场新闻

2. macro

• 使用 topics=economy_macro
• 目标：宏观、政策、总体经济环境

3. crypto

• 使用 tickers=CRYPTO:BTC,CRYPTO:ETH
• 目标：crypto 主市场新闻

4. commodities

• 使用 topics=energy_transportation
• 目标：能源、运输、商品链路相关新闻

说明：

• 第一阶段以“简单稳定”优先，不追求最细分类
• 每个分类独立抓取、独立存快照
• 前端看板只读展示这 4 个分类

D.3 后台抓取策略

后台任务统一执行：

• 每 10 到 15 分钟刷新一次
• 每个分类单独请求 Alpha Vantage 一次
• 默认 sort=LATEST
• 默认只抓近 48 小时窗口
• 每类限制 limit=12

这样做的原因：

• 控制请求量
• 保持新闻时效性
• 避免把历史长尾新闻混进看板

D.4 快照结构

每个分类快照建议保存：

• 分类名
• 快照键
• 新闻列表
• 分类摘要
• 生成时间

每条新闻建议保留：

• title
• url
• time_published
• source
• summary
• banner_image
• overall_sentiment_score
• overall_sentiment_label
• ticker_sentiment
• topics

D.5 聚合与去重规则

必须在后台聚合阶段做清洗，不把原始源数据直接透传给前端。

建议规则：

• 同一分类内按 url 去重
• 若 url 缺失，退化为按 title + source 去重
• 去掉标题为空的记录
• 去掉明显缺失发布时间的记录
• 按发布时间倒序保留最新结果

D.6 分类摘要规则

每个分类快照除新闻列表外，还应生成一个轻量摘要：

• item_count
• top_headline
• top_source
• sentiment_breakdown
• highlight_symbols

前端和 heartbeat 默认优先读摘要，而不是一次性消费整批新闻正文。

D.7 前端展示约束

金融事件看板中的新闻模块应：

• 每类默认显示 3 到 5 条
• 可展开查看更多，但仍只读已有快照
• 显示来源、发布时间、情绪标签
• 不做无限滚动
• 不做“刷新”按钮

D.8 未来扩展边界

后续若 Alpha Vantage 新闻广度不足，可继续扩展：

• RSS 聚合层
• 更广的新闻供应商

但仍需保持不变的原则：

• 统一后台抓取
• 统一快照存储
• 前端和 API 只读

---

4.2 第二阶段：中等复杂度

E. 稳定币健康监控

目标：

• 为 crypto 交易员和 agent 提供快速风险状态

建议输出：

• 每个稳定币当前价格
• 相对 1 美元的偏离幅度
• 24h 成交量
• 市值
• 总体健康状态：healthy / caution / warning

建议首批资产：

• USDT
• USDC
• DAI
• FDUSD
• USDe

F. BTC ETF Flow 估计

目标：

• 给 crypto agent 增加一个“资金流向温度计”

说明：

• 不需要追求官方级精度
• 但必须明确标注为估计值

建议输出：

• ETF 列表
• 当日涨跌
• 估算流入 / 流出方向
• 汇总净方向

G. 个股分析回测

目标：

• 评估历史分析结论在未来若干天窗口内是否有效

建议输出：

• 胜率
• 平均模拟收益
• 最近一次信号结果
• 历史评估列表

4.3 第三阶段：可选高级能力

H. 商品 / 供应链扰动

目标：

• 如果后续 AI-Trader 需要更强的大宗商品智能，可加入轻量版供应链扰动提示

但限制：

• 只做与交易直接相关的信号
• 不做 worldmonitor 那种全局运输监控平台

I. 制裁 / 贸易政策金融影响

目标：

• 为部分宏观、商品和全球市场策略提供政策冲击背景

限制：

• 必须和市场交易直接相关
• 不做泛政治分析产品

---

5. 与 AI-Trader 当前架构的结合方式

5.1 总体实现原则

新增能力应该作为 AI-Trader 当前交易流的一部分存在，而不是另起一套“情报产品”。

即：

• 分析是为了帮助下单
• 历史是为了帮助讨论和策略
• 信号是为了帮助 agent 决策
• 通知是为了让 agent 持续迭代判断

同时增加一个独立入口：

• 金融事件看板页

这个页面不是新的独立产品，而是 AI-Trader 内部的统一观察层，用来把已经生成好的快照模块按“小图层”方式集中展示。

5.2 后端模块建议

建议在 service/server/ 下新增独立金融能力模块，例如：

• market_intel.py
• market_intel_tasks.py
• market_intel_providers.py
• market_intel_models.py

职责建议：

• market_intel.py
  • 对外提供查询函数
  • 负责统一数据拼装
• market_intel_tasks.py
  • 定时刷新快照
  • 更新缓存
  • 生成通知触发条件
• market_intel_providers.py
  • 统一封装外部数据源访问
  • 做限流、缓存、降级
• market_intel_models.py
  • 定义内部结构化返回格式

不建议：

• 把大量逻辑继续塞进 routes.py

---

6. 数据库设计草案

当前数据库已有：

• signals
• signal_replies
• positions
• profit_history
• agent_messages
• agent_tasks

建议新增以下表，避免与现有交易表混杂。

6.1 macro_signal_snapshots

用途：

• 保存宏观市场状态快照

建议字段：

• id
• snapshot_key
• verdict
• bullish_count
• total_count
• signals_json
• meta_json
• source_json
• created_at

说明：

• signals_json 保存各项子信号
• meta_json 保存可视化辅助数据
• source_json 保存数据来源和版本

6.2 stock_analysis_snapshots

用途：

• 保存某个 symbol 的分析快照

建议字段：

• id
• symbol
• market
• analysis_id
• current_price
• currency
• signal
• signal_score
• trend_status
• support_levels_json
• resistance_levels_json
• bullish_factors_json
• risk_factors_json
• summary_text
• analysis_json
• news_json
• created_at

说明：

• analysis_json 保留完整结构
• summary_text 用于快速展示

6.3 stock_backtest_snapshots

用途：

• 保存某个 symbol 的回测汇总结果

建议字段：

• id
• symbol
• market
• window_days
• evaluations_run
• actionable_evaluations
• win_rate
• avg_return_pct
• cumulative_return_pct
• latest_signal
• summary_json
• created_at

6.4 stablecoin_health_snapshots

用途：

• 保存稳定币健康状态快照

建议字段：

• id
• summary_json
• coins_json
• created_at

说明：

• 该表保留为第二阶段预留
• 第一阶段不实现

6.5 market_news_snapshots

用途：

• 保存金融新闻聚合快照

建议字段：

• id
• category
• snapshot_key
• items_json
• summary_json
• created_at

说明：

• category 可为 equities / macro / crypto / commodities
• items_json 保存新闻列表
• summary_json 保存该分类的摘要与高亮事件

6.6 etf_flow_snapshots

用途：

• 保存 ETF 流向估计快照

建议字段：

• id
• summary_json
• etfs_json
• created_at

6.7 可选：signal_intel_links

用途：

• 把分析快照挂到策略帖 / 讨论帖 / 实时交易上

建议字段：

• id
• signal_id
• intel_type
• intel_snapshot_id
• created_at

用途说明：

• 某条策略可引用一个个股分析快照
• 某条讨论可引用一个宏观快照

---

7. API 设计草案

以下接口均为建议草案，最终以实现时再细化为准。

7.1 概览接口

GET /api/market-intel/overview

作用：

• 返回首页或交易页需要的金融智能摘要

建议返回：

• 最新宏观信号
• 最新金融新闻摘要
• 最新 ETF 流估计
• 最近更新时间

7.2 宏观信号接口

GET /api/market-intel/macro-signals

作用：

• 获取最新宏观市场状态

建议返回：

• verdict
• signals
• meta
• created_at

7.3 金融新闻接口

GET /api/market-intel/news

作用：

• 获取金融新闻聚合摘要

建议返回：

• categories
• items
• created_at

7.4 稳定币健康接口

说明：

• 保留为第二阶段接口
• 第一阶段不实现

GET /api/market-intel/stablecoins

作用：

• 获取稳定币健康摘要

建议返回：

• summary
• coins
• created_at

7.5 ETF 流接口

GET /api/market-intel/etf-flows

作用：

• 获取 ETF 方向估计

建议返回：

• summary
• etfs
• created_at
• is_estimated

7.6 个股分析接口

POST /api/market-intel/stocks/analyze

说明：

• 该接口设计需要调整为只读模式
• 最终不应允许用户通过请求触发分析生成
• 应改为只读取最新已有快照

建议改名为：

• GET /api/market-intel/stocks/{symbol}/latest

建议返回：

• analysis_id
• symbol
• signal
• signal_score
• summary
• analysis

7.7 个股分析历史接口

GET /api/market-intel/stocks/{symbol}/history

作用：

• 返回该 symbol 的分析快照历史

建议参数：

• limit
• market

7.8 个股回测接口

POST /api/market-intel/stocks/{symbol}/backtest

请求：

• window_days
• market

作用：

• 返回该 symbol 的历史分析回测结果

7.9 策略 / 讨论挂载接口

不建议第一版就新增独立大接口。

建议第一版在已有接口中扩展字段：

• 发策略时可附带 intel_refs
• 发讨论时可附带 intel_refs

后端统一在 signal_intel_links 中建立关联

---

8. 后台任务与缓存设计

8.1 为什么要做快照

这些能力不应在每次请求时都实时打外部 API。否则会带来：

• 高延迟
• 外部限流风险
• 前端打开页面卡顿
• 后端成本不可控

所以建议以“快照 + 缓存 + 定时刷新”为主。

并且这里增加硬约束：

• 不允许用户请求触发刷新
• 不允许 API 请求触发刷新
• 所有刷新都必须由后台统一任务执行

8.2 建议刷新策略

宏观信号

• 刷新周期：15 分钟
• 存库：是
• 缓存：内存 + 数据库双层

稳定币健康

• 刷新周期：2 到 5 分钟
• 存库：是
• 缓存：短 TTL

说明：

• 该模块推迟到第二阶段
• 第一阶段不进入后台任务排程

金融新闻聚合

• 刷新周期：10 到 15 分钟
• 存库：是
• 缓存：中 TTL
• 数据来源：后台统一抓取并聚合

ETF 流估计

• 刷新周期：15 分钟
• 存库：是
• 缓存：中 TTL

个股分析

• 刷新方式：
  • 由后台统一任务按 watchlist / 热门 symbol / 已持仓 symbol 生成
  • 不允许用户请求时触发生成
• 存库：是
• 缓存：按 symbol + market 缓存短 TTL

回测

• 刷新方式：
  • 由后台批任务统一生成
  • 结果可缓存更久

8.3 降级策略

任何外部数据源异常时，应返回：

• unavailable: true
• reason
• last_snapshot_at

不要静默失败。

---

9. 前端接入设计

9.1 总体原则

不单独做一个新产品，不造第二套 dashboard。

所有新金融能力都应采用“双入口”方式：

• 第一入口：嵌入现有交易流
• 第二入口：集中展示于“金融事件看板”

9.2 页面挂载点

新页面：金融事件看板 FinancialEventsBoardPage

建议新增独立路由：

• /financial-events

页面定位：

• 统一查看市场智能快照
• 不承担实时更新职责
• 不允许用户在此页触发刷新
• 所有内容都来自统一后台快照

建议呈现方式：

• 一个页面
• 多个小图层模块
• 每个模块独立成卡片或面板
• 按重要性和关联性编排，而不是做成单列表

建议模块布局：

1. 顶部总览层

• 最新快照时间
• 当前宏观市场状态
• 当前新闻热度摘要
• ETF 方向摘要

2. 宏观信号层

• 宏观结论
• 子信号列表
• 关键解释

3. 金融新闻层

• 按类别聚合的重点新闻卡片
• 宏观 / equities / crypto / commodities 分类摘要

4. ETF 流层

• ETF 方向分布
• 汇总净方向

5. 个股分析层

• 热门或重点 symbol 的最新分析快照
• 可点击进入历史

6. 个股分析历史层

• 某些重点 symbol 的历史分析列表
• 支持快速查看“最近几次怎么看”

7. 稳定币健康层

• 第二阶段再加入
• 若后续接入，仍只展示后台统一快照

8. 可选扩展层

• 商品/供应链扰动
• 制裁/贸易政策影响

页面交互原则：

• 只读
• 可切换查看不同模块
• 可展开详情
• 可跳转到交易页、讨论页、策略页
• 不允许点击后触发后台重算

页面价值：

• 给人类交易员一个集中观察面
• 给 agent 提供一个统一可读的前端面板
• 让用户不必在多个页面间来回寻找金融上下文

页面与交易流页面的关系

两者并存：

• 交易页、策略页、讨论页继续显示嵌入式摘要
• 金融事件看板负责集中展示全局金融上下文

即：

• 交易流页面解决“做当前动作前要知道什么”
• 金融事件看板解决“我想系统性看一遍当前金融状态”

交易页 TradePage

新增：

• 分析结果卡片
• 宏观信号摘要
• 相关 symbol 或 market 的新闻摘要

作用：

• 让交易不是只查价，而是读取已有分析快照再下单

仓位页 PositionsPage

新增：

• 宏观市场状态摘要
• 金融新闻摘要
• ETF 流摘要

作用：

• 帮用户理解当前持仓环境

策略页 StrategiesPage

新增：

• 发布策略时可引用分析快照
• 策略卡片中展示引用的分析摘要

讨论页 DiscussionsPage

新增：

• 发讨论时可引用分析快照
• 讨论中可展示“基于某次分析发起”

Landing Page

补充：

• AI-Trader 不只是社交交易，也包含金融智能辅助

Sidebar / 导航

建议新增导航项：

• 金融事件看板 / Financial Events

位置建议：

• 放在市场页和排行榜之后
• 作为统一金融上下文入口

---

9.3 金融事件看板页面结构细稿

页面头部

建议包含：

• 页面标题：金融事件看板
• 副标题：统一查看 AI-Trader 的市场智能快照
• 最新刷新时间
• 数据声明：所有数据均为后台统一快照，非用户实时触发

模块组织方式

建议使用“小图层”组织，而不是大表格：

• 每个模块一张卡
• 每张卡专注一种金融信号
• 卡片间可以按栅格排列
• 桌面端优先 2 到 3 列
• 移动端单列堆叠

模块优先级

第一批页面中建议出现：

1. 宏观信号
2. 金融新闻摘要
3. ETF 流向
4. 热门 symbol 分析

第二批再加入：

5. 分析历史
6. 稳定币健康

第三批再加入：

7. 商品扰动
8. 制裁/贸易政策影响

模块行为约束

所有模块必须满足：

• 首次打开只读已有快照
• 页面切换时不触发后端刷新
• 卡片展开时不触发外部数据抓取
• 最多只发起内部只读 API 请求

视觉方向

建议延续当前 AI-Trader 的终端式设计语言：

• 深色/浅色主题都支持
• 每个金融模块像一个轻量信息图层
• 突出信号，而不是堆满文字
• 可以有状态色，但避免做成夸张告警墙

与 agent 的关系

虽然这是前端页面，但其数据结构应与 agent 可读结构尽量一致。

原因：

• 同一份快照既要给人看，也要给 agent 读
• 前端只是其中一个展示层
• 后续 skill 和 heartbeat 应共享相同数据模型

9.4 金融事件看板精确页面规格

页面标识

• 路由：/financial-events
• 页面组件建议名：FinancialEventsBoardPage
• 导航名称：
  • 中文：金融事件看板
  • 英文：Financial Events
• 页面类型：只读聚合页

页面目标

该页面要解决的问题不是“完成交易”，而是“在 10 到 30 秒内完整扫一遍当前金融状态”。

因此页面需要满足：

• 第一眼能看到总体状态
• 第二眼能看到主要风险来源
• 第三眼能下钻到某个 symbol 或某类事件

页面信息层级

建议采用三层结构：

第一层：总览层

用途：

• 让用户打开页面后立即知道市场大致处于什么状态

建议内容：

• 最新快照时间
• 宏观状态总览
• 新闻热度总览
• ETF 流方向总览
• 数据完整度状态

第二层：核心事件层

用途：

• 展示当前最值得看的 3 到 6 个金融模块

建议模块：

• 宏观信号模块
• 金融新闻摘要模块
• ETF 流模块
• 热门 symbol 分析模块

第三层：扩展观察层

用途：

• 展示历史、附加上下文和扩展金融事件

建议模块：

• 分析历史模块
• 金融新闻摘要模块
• 商品扰动模块
• 制裁/贸易政策模块

页面布局规则

桌面端

建议使用 12 栏网格，但在视觉上保持“小图层”感。

建议布局：

• 第一行：4 个概览卡
  • 每张占 3 栏
• 第二行：宏观信号大卡 + 金融新闻卡
  • 宏观信号占 7 栏
  • 金融新闻占 5 栏
• 第三行：ETF 流卡 + 热门 symbol 分析卡
  • ETF 流占 5 栏
  • 热门 symbol 分析占 7 栏
• 第四行及以后：历史 / 新闻 / 扩展模块按 6 栏或 4 栏编排

平板端

建议布局：

• 第一行：2 列概览卡
• 后续主体卡片按 2 列排列

移动端

建议布局：

• 全部单列
• 概览卡放最前
• 重点模块折叠展开

模块尺寸建议

小卡

适合：

• 总览值
• 健康状态
• 小型摘要

内容限制：

• 1 个核心指标
• 1 到 2 行说明
• 1 个时间信息

中卡

适合：

• ETF 流
• 金融新闻摘要
• 热门 symbol 分析摘要

内容限制：

• 1 个小表或列表
• 3 到 6 条项目

大卡

适合：

• 宏观信号
• 历史分析
• 新闻摘要

内容限制：

• 结构化内容
• 可展开更多内容

关键模块精确规格

模块 A：总览卡组

建议包含 4 张卡：

1. 宏观状态卡

• 标题：宏观状态
• 主值：bullish / neutral / defensive
• 次级信息：bullish_count / total_count
• 状态色：绿 / 黄 / 红

2. 新闻热度卡

• 标题：金融新闻
• 主值：calm / active / elevated
• 次级信息：高价值事件数量

3. ETF 流方向卡

• 标题：ETF 流方向
• 主值：inflow / mixed / outflow
• 次级信息：净方向说明

4. 数据刷新卡

• 标题：数据刷新
• 主值：最近更新时间
• 次级信息：是否完整

模块 B：宏观信号大卡

内容结构：

• 顶部：结论 + 更新时间
• 中部：4 到 7 个子信号格
• 底部：一句自然语言解释

每个子信号格包含：

• 指标名
• 当前状态
• 简短解释
• 可选小 sparkline

允许点击：

• 展开详细说明

禁止：

• 点击后触发后台重算

模块 C：金融新闻摘要卡

内容结构：

• 顶部：新闻摘要
• 中部：按类别分组的短列表

建议类别：

• equities
• macro
• crypto
• commodities

每条建议字段：

• 标题
• 来源
• 发布时间
• 摘要
• 关联标签

限制：

• 每类 3 到 5 条
• 不显示无限滚动长流

模块 D：ETF 流卡

内容结构：

• 顶部：总方向摘要
• 中部：ETF 列表

每行建议字段：

• ETF 名称
• 当日方向
• 估算流量
• 成交量强度

需要明确标注：

• 估算值

模块 E：热门 Symbol 分析卡

内容结构：

• 顶部：热门分析
• 中部：3 到 6 个 symbol 快照

每个 symbol 卡建议字段：

• symbol
• 当前价格
• signal
• signal_score
• 一句总结

点击行为：

• 跳转到该 symbol 的分析历史详情
• 或跳转到交易页并带上 symbol

模块 F：分析历史卡

内容结构：

• 顶部：最近分析历史
• 中部：按 symbol 分组的最近快照

每条历史建议字段：

• symbol
• created_at
• signal
• summary

点击行为：

• 可查看完整历史

模块 G：稳定币健康卡

内容结构：

• 顶部：整体健康状态
• 中部：稳定币列表

每一行建议字段：

• 名称
• 当前价格
• 偏离幅度
• 24h 成交量
• 状态标签

限制：

• 默认显示前 5 个稳定币
• 第二阶段再实现

卡片交互规则

所有卡片通用规则：

• 鼠标悬浮有轻微强调
• 点击只跳内部页面或展开详情
• 不触发实时抓取
• 不出现“刷新”按钮

数据状态设计

每个模块需要支持 4 种状态：

1. ready

• 有完整快照

2. stale

• 有旧快照，但已超过建议刷新时间

3. partial

• 快照存在，但数据缺失

4. unavailable

• 当前没有可展示快照

前端表现要求：

• stale 要明确显示“数据可能不是最新”
• partial 要明确显示“部分数据缺失”
• unavailable 不要显示空白块，应该显示说明文案

看板页与其他页面的跳转关系

建议跳转关系：

• 金融事件看板 → 交易页
  • 带 symbol
• 金融事件看板 → 策略页
  • 带 intel_ref
• 金融事件看板 → 讨论页
  • 带 intel_ref
• 金融事件看板 → 某 agent 市场页
  • 若某分析或事件与特定交易员相关

看板页的只读 API 映射

建议页面使用以下只读接口：

• GET /api/market-intel/overview
  • 供顶部概览层使用
• GET /api/market-intel/macro-signals
  • 供宏观模块使用
• GET /api/market-intel/news
  • 供金融新闻模块使用
• GET /api/market-intel/etf-flows
  • 供 ETF 模块使用
• GET /api/market-intel/stocks/{symbol}/latest
  • 供 symbol 分析卡使用
• GET /api/market-intel/stocks/{symbol}/history
  • 供历史模块使用

页面加载策略

建议策略：

• 首屏只请求 overview
• 页面可见后再按模块懒加载其余只读接口
• 每个模块独立失败，不阻塞全页

禁止策略：

• 首屏一次性请求全部详细数据
• 打开页面时顺手触发后台生成

页面与通知系统的关系

未来可考虑：

• 当宏观状态变化明显时，在看板页顶部出现“新变化”提示
• 当高价值新闻聚合发生显著变化时，看板页对应模块高亮

注意：

• 这仍然只是展示新的后台快照
• 不是用户点击后实时计算

9.5 金融事件看板实施顺序

建议顺序：

1. 先实现基础路由和空页面
2. 接入顶部概览层
3. 接入宏观信号与金融新闻模块
4. 接入 ETF 流模块
5. 接入热门 symbol 分析模块
6. 接入历史模块
7. 最后再接入稳定币与其他扩展模块

---

10. Agent 接入设计

10.1 Skill 更新方向

未来实现后，需要更新：

• skills/ai4trade/SKILL.md

增加能力说明：

• 如何请求市场智能概览
• 如何调用个股分析
• 如何获取宏观信号
• 如何读取金融新闻聚合快照
• 如何把分析引用到策略和讨论中

10.2 Heartbeat 未来可扩展通知

建议未来增加以下消息类型：

• macro_regime_changed
• market_news_digest_ready
• stock_analysis_ready
• etf_flow_shift

这些消息应做到：

• 写入 agent_messages
• 可通过 websocket 实时推送
• 可通过 heartbeat 拉取

---

11. 分阶段实施顺序

11.1 Phase 0：准备阶段

先做：

1. 补齐 AI-Trader 仓库实际许可证文件
2. 明确 README 与 LICENSE 一致
3. 设计数据库迁移方案
4. 明确将使用的数据源

11.2 Phase 1：第一批上线能力

建议顺序：

1. 新增快照表
2. 实现宏观信号
3. 实现金融新闻聚合
4. 实现个股分析
5. 实现统一后台刷新任务
6. 交易页接入只读分析结果

说明：

• 稳定币健康模块整体后移，不在第一批上线范围内

11.3 Phase 2：第二批增强

建议顺序：

1. 分析历史
2. 策略/讨论引用分析
3. ETF 流估计
4. heartbeat 智能通知

11.4 Phase 3：第三批验证型能力

建议顺序：

1. 个股分析回测
2. 商品/供应链扰动
3. 制裁/贸易政策冲击

---

12. 风险清单

12.1 许可证风险

风险：

• 开发过程中如果有人直接复制 worldmonitor 代码，会污染当前项目许可证边界

要求：

• 所有实现必须重新编写
• Review 时特别检查是否出现直接拷贝痕迹

12.2 数据源风险

风险：

• 某些数据源可能免费额度有限
• 某些数据源不允许商用或高频分发
• 当前已知 Alpha Vantage 已订阅 premium，但仍需核查具体套餐条款与调用上限

要求：

• 每接入一个数据源前单独核查条款

12.3 前端复杂度风险

风险：

• 金融能力加太多后，会让 AI-Trader 变成另一个信息过载平台

要求：

• 所有能力先服务于交易流
• 不做脱离交易流的大而全信息面板

12.4 后端性能风险

风险：

• 如果分析逻辑直接挂在请求链路，页面会变慢

要求：

• 优先使用快照与缓存
• 请求时只做轻量查询
• 请求路径中禁止刷新外部数据
• 请求路径中禁止临时生成分析结果

---

13. 当前结论

结论如下：

• 可以参考 worldmonitor 的金融产品能力
• 不能复制其代码
• AI-Trader 应保持 MIT 路线
• 最值得先做的是：
  • 宏观信号
  • 金融新闻聚合
  • 个股分析
  • 个股分析历史
• 所有新增能力都必须采用统一快照模式
• 所有新增能力都应服务于：
  • 讨论
  • 策略
  • 下单
  • 跟单
  • agent 心跳通知

---

14. 当前状态

当前状态：

• 已完成规划
• 尚未开始实现
• 尚未修改数据库
• 尚未新增接口
• 尚未修改前端页面逻辑

---

15. 数据源矩阵

本节用于明确：

• 每项金融能力需要什么数据源
• 当前项目是否已经接入
• 是否需要 API Key
• 是否可能需要额外订阅
• 推荐用途与注意事项

15.1 总体结论

当前项目已具备的外部市场数据源：

• Alpha Vantage（已订阅 premium）
• Hyperliquid
• Polymarket 公共 API

要完成本设计稿中的金融能力，建议保留上述数据源，并新增：

• 新闻聚合源或 RSS 聚合层（第一阶段）
• CoinGecko 或同类 crypto 市场聚合源（第二阶段，如需稳定币模块）

其中最需要额外关注新增订阅成本的是：

• 新闻聚合源的商用条款与分发限制
• CoinGecko 或同类 crypto 市场聚合源

15.2 数据源矩阵表

功能模块	建议数据源	当前是否已有	是否需要 API Key	是否可能需要额外订阅	说明
美股当前价格	Alpha Vantage	是	是	否（已订阅 premium）	当前已在项目中使用
美股历史 K 线	Alpha Vantage	否（未完整使用）	是	否（已订阅 premium）	个股分析与回测需要更稳定历史数据
ETF 当前价格/成交量	Alpha Vantage	否	是	否（已订阅 premium）	ETF 流估计主要依赖这类数据
股票新闻/情绪	Alpha Vantage News & Sentiment	否	是	否（已订阅 premium）	可用于个股分析摘要
财报日历	Alpha Vantage Earnings Calendar	否	是	否（已订阅 premium）	可作为后续扩展能力
宏观指标（利率/CPI/就业等）	Alpha Vantage Economic Indicators	否	是	否（已订阅 premium）	宏观信号面板的核心来源
商品基础序列（金/油/铜等）	Alpha Vantage Commodities	否	是	否（已订阅 premium）	宏观和商品扰动模块可复用
Crypto 实时价格	Hyperliquid	是	否	否	当前已在项目中使用
Stablecoin 市值/24h量/偏离	CoinGecko 或同类	否	视供应商而定	可能需要	第二阶段稳定币健康模块推荐使用
Polymarket 市场元数据	Polymarket Gamma API	是	否	否	当前已使用
Polymarket orderbook / mid price	Polymarket CLOB API	是	否	否	当前已使用
Fear & Greed 指数	第三方情绪源	否	视供应商而定	可能需要	Alpha Vantage 不直接提供该指数本身
金融新闻聚合（宏观/市场/商品/crypto）	Alpha Vantage News & Sentiment + RSS / 新闻聚合源	否	部分需要	视供应商而定	第一阶段优先做高价值摘要，不做大新闻门户

15.3 推荐数据源组合

方案 A：尽量少新增数据源

适用于：

• 第一阶段快速落地
• 控制服务器负载
• 控制订阅成本

推荐组合：

• Alpha Vantage
• Hyperliquid
• Polymarket 公共 API
• 新闻聚合源 / RSS

覆盖能力：

• 宏观信号
• 金融新闻聚合
• 个股分析
• 个股分析历史
• ETF 流估计
• crypto / polymarket 当前市场上下文

方案 B：极限压缩数据源数量

适用于：

• 尽量不新增供应商

推荐组合：

• Alpha Vantage
• Hyperliquid
• Polymarket 公共 API

问题：

• 金融新闻广度会受限
• 更适合作为第一阶段过渡方案

15.4 哪些是额外订阅 API

以下数据源最需要明确标记为“订阅状态与新增成本边界”。

1. Alpha Vantage

状态：

• 当前项目已接入
• 已订阅 premium
• 但现有只用了一小部分

现在的设计含义：

• 后续方案默认可以使用 premium 覆盖的时间序列、宏观、ETF、新闻情绪等能力
• 仍需核查当前套餐的速率限制、商用条款和并发上限
• 后端任务设计仍应按统一快照、批量刷新、避免无谓调用来控制成本和稳定性

结论：

• 这是已具备的核心付费数据源
• 后续无需再把 Alpha Vantage 视为“待订阅风险”，而应视为“已采购能力，需要合理使用”

2. CoinGecko 或同类

状态：

• 当前项目未接入

为什么可能需要额外订阅：

• 稳定币健康模块需要：
  • 当前价格
  • 24h volume
  • market cap
  • 多币统一快照
• 免费方案可能在频率、商用条款或并发上受限

结论：

• 这是第二阶段才需要考虑的新增订阅数据源

3. 第三方情绪指数源（可选）

状态：

• 当前项目未接入

为什么可能需要额外订阅：

• 如果坚持加入 Fear & Greed 指数，而不想用替代指标，就需要额外情绪源

结论：

• 属于可选新增订阅，不是第一阶段必须

15.5 哪些不一定需要额外订阅

Hyperliquid

• 当前已用
• 公共读接口
• 可继续用于 crypto 实时价格

Polymarket Gamma / CLOB

• 当前已用
• 公共读接口
• 可继续用于预测市场元数据与订单簿价格

RSS / 自建新闻聚合

• 不一定需要订阅
• 但维护成本高、噪音也高
• 第一阶段可以做，但必须严格控制抓取频率、来源数量和展示范围

15.6 每项功能对应的数据源建议

宏观信号

建议数据源：

• Alpha Vantage

建议使用的数据类型：

• ETF / 指数时间序列
• 经济指标
• 商品时间序列
• 可选新闻情绪

是否能由现有项目完全支撑：

• 不能
• 需要扩展 Alpha Vantage 使用范围

个股分析快照

建议数据源：

• Alpha Vantage

建议使用的数据类型：

• 当前价格
• 日线/历史数据
• 技术指标或自算技术指标
• 新闻情绪

是否能由现有项目完全支撑：

• 不能
• 当前只接了价格，不足以支撑完整分析

个股分析历史

建议数据源：

• Alpha Vantage + 本地快照存储

是否能由现有项目完全支撑：

• 不能直接支撑
• 需要新增后台生成与存储逻辑

稳定币健康

建议数据源：

• CoinGecko 或同类

是否能由现有项目完全支撑：

• 不能
• 但第一阶段暂不做

ETF 流估计

建议数据源：

• Alpha Vantage

是否能由现有项目完全支撑：

• 不能直接支撑
• 但新增后端快照逻辑后可以支撑

金融新闻摘要

建议数据源：

• 第一阶段：Alpha Vantage News & Sentiment（偏个股）
• 后续阶段：RSS / 新闻聚合

是否能由现有项目完全支撑：

• 不能

15.7 数据源建议优先级

建议优先接入顺序：

1. 扩展 Alpha Vantage premium 使用范围
2. 新增新闻聚合层或 RSS 聚合
3. 保持 Hyperliquid 不变
4. 保持 Polymarket 不变
5. CoinGecko 放到第二阶段

15.8 当前推荐结论

目前最现实的组合是：

• 继续使用：
  • Alpha Vantage premium
  • Hyperliquid
  • Polymarket 公共 API
• 新增：
  • 新闻聚合层 / RSS 聚合

第二阶段再考虑：

• CoinGecko

其中需要重点标红的新增订阅风险：

• 新闻源的商用分发条款
• CoinGecko 或同类付费 plan（第二阶段）

补充说明：

• Alpha Vantage 已确认订阅 premium，因此后续设计默认可用
• 但所有实现仍应避免把 premium 当作无限资源使用