hmo/MoFin
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

MoFin 初始提交

Browse Source 
完整数据采集+分析管道：
- market_watch.py：90行业板块采集（同花顺/东方财富）
- 市场精选推荐 cron：全市场分析+候选池+星级推荐
- price_monitor.py：持仓/自选高频价格监控
- refresh_mtf_cache.py：多周期K线缓存
- 策略评估/知识萃取管道

文档：docs/ 含完整需求+架构设计
注意：尚未配置 git remote，笑笑接手后自行配置
This commit is contained in:
知微 (MoFin)
2026-06-20 12:04:21 +08:00
commit aa0f740381
950 changed files with 189006 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/REQUIREMENTS.md
+189
View File
@@ -0,0 +1,189 @@
---
title: MoFin 系统数据库统一 - 需求与实施计划
tags: [MoFin, 数据库, 需求文档, 当前工作]
status: 活跃
priority: P0（当前）
created: 2026-06-20
---
# MoFin 系统数据库统一 - 需求与实施计划
## 一、当前状态
### 已完成的管道
```
market_watch.py（每30分，no_agent）
→ 拉取同花顺90个行业板块数据
→ 写入 market.json（最新快照，仅存当前值，无历史）
市场精选推荐-每日（16:00，LLM cron）
→ 读 market.json → 全市场分析
→ 选热门行业 → 查个股实时价 → 候选池 → 星级推荐
→ 写入 candidate_pool.json + 输出报告给老爸
```
### 核心问题
所有数据以 JSON 文件散落存储，**无历史记录、无关联查询能力**：
| 问题 | 影响 |
|------|------|
| market.json 只存最新快照 | 看不到板块涨跌趋势、资金流向变化 |
| 个股不知自己所属板块，板块不知有哪些成分股 | 无法 SQL join 持仓→板块→趋势 |
| 评分/策略变更无历史 | 看不到候选评分变化趋势 |
| 各 JSON 之间无外键约束 | 数据一致性全靠代码保证 |
---
## 二、目标
**将 MoFin 全部数据纳入统一 SQLite 数据库（mofin.db），实现：**
- 数据关系化（持仓 ↔ 板块 ↔ 趋势，一条 SQL 直连）
- 历史可追溯（板块快照、评分变更、策略版本全部时序存储）
- 操作 no_agent 化（常用查询/告警用脚本完成，不消耗 LLM）
- 增量无损迁移（JSON 双写 → 验证 → 切换）
---
## 三、数据库设计（详细见 docs/mofin-database-architecture.md）
### 8 组表
| 表 | 替代的 JSON | 核心字段 |
|----|------------|---------|
| market_snapshots | —（新增） | timestamp, up_ratio, mood |
| sector_snapshots | market.json sectors[] | snapshot_id, name, change_pct, net_inflow |
| stocks | multi_tf_cache.json 的 key | code, name, exchange |
| stock_daily / weekly / monthly | multi_tf_cache 内容 | code, date, ohlcv |
| stock_fundamentals | multi_tf_cache fundamentals | code, pe, pb, eps |
| stock_sectors | **新表（目前无）** | code ↔ sector_name 映射 |
| holdings | portfolio.json holdings | code, shares, cost |
| holding_strategies | decisions.json 策略 | code, stop_loss, tp, entry 区间 |
| watchlist_stocks | watchlist.json | code, name |
| candidates | candidate_pool.json | code, star, promoted |
| candidate_score_history | candidate_pool 内嵌 history | code, score, source |
| price_events | price_events.json | code, event_type, price |
---
## 四、实施计划
### 阶段1：市场快照入库（当前，P0）
改动文件：`market_watch.py`
```
market_watch.py 修改：
1. 采集 90 个板块数据后
2. 写 market.json（保留，兼容现有管道）
3. 同时 INSERT INTO market_snapshots + sector_snapshots
```
**验证标准：**
- market_watch 跑完后，mofin.db 中 market_snapshots 增加一条
- sector_snapshots 有 90 行对应数据
- 现有 pipeline 不受影响（继续读 market.json）
### 阶段2：个股K线入库（P1）
改动文件：`refresh_mtf_cache.py`
- 将 multi_tf_cache.json 的数据同时写入 stock_daily / weekly / monthly
- 补填 stocks 表和 stock_fundamentals 表
### 阶段3：板块成分映射（P1）
新建脚本或集成到 market_watch：
- 从同花顺板块数据中提取成分股（ak.stock_board_industry_cons_em）
- 写入 stock_sectors 表
- 建立个股 ↔ 板块的可查询关系
### 阶段4：业务表迁移（P2）
- holdings / watchlist / candidates / price_events 逐表迁移
- 每表：JSON+SQLite 双写 → 验证 → 切到 SQLite
### 阶段5：no_agent 查询脚本（P3）
- mofin_query.py "SELECT ..." → 输出格式化的报告
- 定时预警：SQL 条件满足时推送通知
- 示例查询见数据库架构文档
---
## 五、接口说明
### market_watch.py 数据格式
输入：同花顺（akshare）90 个行业板块
输出字段（写入 sector_snapshots）：
| 字段 | 来源 | 说明 |
|------|------|------|
| name | 板块名称 | 中文名，如"半导体" |
| change_pct | 涨跌幅 | 百分比，THS 源直接可用，EM 源需÷100 |
| up_count | 上涨家数 | 仅 THS 源有 |
| down_count | 下跌家数 | 仅 THS 源有 |
| net_inflow | 资金净流入(亿) | 仅 THS 源有 |
| lead_stock | 领涨股 | 仅 THS 源有 |
| lead_stock_change | 领涨股涨跌幅 | 仅 THS 源有 |
### 腾讯 API 个股查询
```bash
curl -s --noproxy '*' "http://qt.gtimg.cn/q=sh688981"
# 返回 v_sh688981="1~中芯国际~688981~140.50~...~...~...~字段32=涨跌幅"
# 第4字段 = 当前价，第32字段 = 涨跌幅(%)
```
---
## 六、文件清单
### 项目文件
| 路径 | 说明 |
|------|------|
| /home/hmo/web-dashboard/market_watch.py | 市场数据采集（本阶段改动） |
| /home/hmo/web-dashboard/market_screener.py | 已暂停，暂不涉及 |
| /home/hmo/web-dashboard/refresh_mtf_cache.py | 下一阶段改动 |
| /home/hmo/web-dashboard/data/mofin.db | 目标数据库（待创建） |
### 文档
| 路径 | 说明 |
|------|------|
| docs/mofin-database-architecture.md | 完整数据库架构设计 |
| docs/market-screening-pipeline.md | 当前筛选流程与提示词 |
| docs/market-screening-system-design.md | 筛选系统设计过程 |
| docs/market-data-requirements.md | 原始需求（部分已实现） |
| docs/strategy-evaluation-requirements.md | 策略评估需求 |
---
## 七、当前任务（笑笑接手）
**第一件事：阶段1 - market_watch.py 改双写**
1. 在 data/ 下创建 mofin.db（SQLite）
2. 执行建表 SQL（CREATE TABLE market_snapshots + sector_snapshots + 索引）
3. 修改 market_watch.py 的 main()：
- 采集板块数据后
- 写 market.json（已有逻辑，不动）
- 新增：INSERT market_snapshots（获取 id）
- 新增：逐板块 INSERT sector_snapshots
4. 验证：手动跑一次 market_watch.py，检查数据库有数据
5. 编写验证脚本 `mofin_query.py`，支持：
```bash
python3 mofin_query.py "半导体最近5次采集的涨跌幅"
# 输出：时间 | 涨跌幅 | 净流入
```
**第二件事：搭建开发环境**
- 项目在 /home/hmo/web-dashboard/
- Python 3.12，标准库 sqlite3
- 需要申请访问 Samba 共享 \\192.168.1.246\hmo-home
- 读 docs/ 下的全部文档了解全貌
docs/market-data-requirements.md
+387
View File
@@ -0,0 +1,387 @@
---
title: 市场数据体系 + 小果情报分析需求文档
tags: [需求文档, 知微, 市场数据, 小果, 行业热点]
created: 2026-06-18
status: 活跃
priority: 高
---
# 市场数据体系 + 小果情报分析需求文档
## 一、痛点现状
### 1.1 MoFin 市场模块三个子页面全部失效
| 页面 | 状态 | 问题 |
|------|------|------|
| 行业热点 | 数据虚假 | 行业涨幅为编造（如塑料+389%），数据源是 LLM cron 凭空生成，不是真实API |
| 知微洞察 | 空白 | "暂无洞察"，没有分析流程 |
| 潜力股挖掘 | 空白 | "暂无挖掘"，没有挖掘流程 |
根因：原 cron `b818e2bfd8d1`（市场数据采集）是 LLM 驱动的，不是真正的数据采集脚本。LLM 没有真实数据源，只能编造。该 cron 已失效，但 market.json 中的假数据还在。
### 1.2 行业数据割裂
- `stock_profiles.json` 中 16/38 只有行业数据（仅覆盖持仓股），22只自选股行业为空
- 行业分类无标准化体系（各行业中文名不一致）
- 无自动化行业补全流程
- `market_watch.py`（东方财富API行业采集脚本）已开发但未接入 Dashboard
### 1.3 小果本地 LLM 可用但未被利用
- 小果（192.168.1.122:18003, MLX Qwen3.6-27B, API port 8645）
- 免费（本地运行），适合做不需要高推理能力但费 token 的重复活
- 当前未被整合到知微的情报分析流程中
---
## 二、总体设计原则
### 2.1 数据来源唯一铁律
**所有 MoFin Dashboard 展示的数据，必须来自真实API，禁止 LLM 编造。**
LLM 只能分析真实数据，不能生成伪数据。
### 2.2 分类规范
- **市场模块展示内容 = 真实API数据 + 知微(智)分析 + 小果情报**
- 数据层（纯脚本）→ 分析层（LLM/知微）→ 展示层（Dashboard）
- 每条展示数据的来源必须可追溯
### 2.3 小果定位
- **不是用来替代知微的**，是辅助工具
- 跑在本地 Mac Mini，免费，但慢且推理能力弱
- 适合：分类/标注/情感分析/简单判断
- 不适合：复杂推理/多步决策/需要深度分析
- 输出给知微参考，知微做最终判断
---
## 三、模块一：行业热点（行业数据采集体系）
### 3.1 核心流程
```
东方财富 push2 API
↓ (market_watch.py, no_agent 纯脚本, 每30分钟)
行业原始数据 (涨跌/成交量/资金流向/上涨家数/下跌家数)
↓ (清洗+标准化)
market.json (标准化数据，写入 Dashboard data/)
↓ (供各模块使用)
MoFin 行业热点 | 知微D2行业分析 | 小果情报参考
```
### 3.2 API 规范
**首选：东方财富 push2 API**
行业板块：
```
GET https://push2.eastmoney.com/api/qt/clist/get
?pn=1&pz=15&po=1&np=1
&fields=f2,f3,f4,f12,f14
&fs=m:90+t:2
```
返回字段：f2(最新价), f3(涨跌幅%), f4(涨跌额), f12(代码), f14(名称)
概念板块：
```
GET https://push2.eastmoney.com/api/qt/clist/get
?pn=1&pz=10&po=1&np=1
&fields=f2,f3,f4,f12,f14
&fs=m:90+t:3
```
**降级：akshare（同花顺数据）**
```
ak.stock_board_industry_summary_ths()
→ 涨跌幅, 上涨家数, 下跌家数, 净流入资金
```
**三级降级：web_search 兜底**
当前两个API都失败时，web_search 搜索当日行业涨跌排行补充
### 3.3 行业分类标准化
建立一级/二级行业分类体系（参考申万/Swift行业分类）：
| 一级 | 二级 | 对应持仓/自选 |
|------|------|-------------|
| TMT/科技 | 半导体/消费电子/互联网/通信设备 | 中芯/德明利/丘钛/腾讯/阿里/博创/长飞 |
| 新能源 | 新能源汽车/储能/新能源材料 | 比亚迪/宁德/海博思创/中科电气/信义光能 |
| 金融地产 | 银行/保险/房地产 | 招商银行/中银香港/中国平安/万科/人寿 |
| 医药 | 创新药/医药流通 | 百济神州/辽宁成大 |
| 工业材料 | 有色金属/复合材料/电子元器件/新材料 | 紫金矿/法拉电子/中科/诺德 |
| 资源 | 黄金/贵金属 | 黄金ETF |
| 消费 | 汽车/消费电子 | 小鹏/TCL |
| ... | ... | ... |
**存量补全规则**：
- 持仓股：补全行业 + 业务描述（优先级高）
- 自选股：补全行业（优先级中）
- 新入自选：创建时即补全行业（规范）
补全方法：优先查腾讯 API 的行业字段，次选 akshare，最后 web_search
### 3.4 market.json 输出结构
```json
{
"timestamp": "2026-06-18 14:30",
"total_sectors": 56,
"up_ratio": 45.2,
"mood": "neutral",
"sectors": [
{
"name": "半导体",
"code": "BK0477",
"price": 5287.63,
"change_pct": 2.35,
"volume": 325.6,
"turnover": 528.4,
"up_count": 68,
"down_count": 12,
"net_inflow": 12.5
}
],
"concepts": [...],
"top_gainers": [前5],
"top_losers": [末3],
"source": "eastmoney"
}
```
字段规范：
- `change_pct`: **百分数**（如+2.35表示涨2.35%），不是绝对点数
- `price`: 板块指数点，不是股票价格
- `up_count/down_count`: 板块内上涨/下跌家数（仅 ak 降级时才有）
- `net_inflow`: 资金净流入（亿元，仅 ak 降级时才有）
- `source`: 数据来源标识（eastmoney/ths/web）
### 3.5 stock_profiles.json 行业数据维护
**自动补全流程**（每周/每月）：
```
第1步：筛选 stock_profiles.json 中 sector 为空的条目
第2步：查腾讯 API 的行业分类字段（港股/A股）→ 匹配申万行业
第3步：腾讯没有 → 查 akshare 股票基本信息
第4步：都不行 → web_search 查公司主营业务，提取行业关键词
第5步：写入 stock_profiles.json
第6步：记录补全日志（谁补的、依据来源、置信度）
```
**人工审核流程**：
- 自动补全的行业标记为"待审核"
- 知微在分析中遇到缺失/错误时手动修正
- 老爸也可以直接编辑
---
## 四、模块二：知微洞察 + 潜力股挖掘
### 4.1 知微洞察
定义：基于行业数据和持仓分析，每日输出 1-3 条有操作价值的洞察。
**数据来源**：
- market.json 行业热点（当日涨跌幅+资金流向）
- decisions.json 策略评估结果
- 小果情报分析（见第五部分）
- web_search 新闻
**洞察类型**：
| 类型 | 触发条件 | 示例 |
|------|---------|------|
| 行业轮动预警 | 持仓行业连续3天跑输大盘>2% | 新能源材料连续3天跑输，需关注 |
| 资金异动提醒 | 行业资金净流入/出异常>5亿 | 半导体单日净流入12亿，板块转强 |
| 策略调整建议 | 某行业趋势反转，影响持仓策略 | 银行板块跌破MA60，万科止损需收紧 |
| 新机会发现 | 非持仓行业连续强势>3天 | 军工板块连涨3天，值得关注 |
| 风险预警 | 行业政策突变/突发事件 | 美国关税政策影响光伏行业 |
**输出位置**：
- MoFin Dashboard → 知微洞察
- XMPP 推送（有实质内容才推）
- 关联到策略评估的 D5 消息面
### 4.2 潜力股挖掘
定义：从行业热点中筛选出与现有持仓/自选相关的潜力标的。
**挖掘流程**：
1. 每日从行业热点中找出最强势的 1-3 个行业
2. 从强势行业中筛选出：基本面+技术面+估值 都符合标准的个股
3. 对比现有持仓/自选，去重
4. 写入 watchlist.json（如果符合买入条件）
5. 输出到 MoFin 潜力股挖掘
**筛选标准**：
- 所属行业排名前20%（当日涨幅）
- PE/估值合理（非亏损股）
- 技术形态向好（近期有放量突破）
- 与现有持仓/自选不重复
**输出形式**：
- 每只标的名 + 行业 + 选取理由（一句话）
- 建议关注级别（高/中/低）
- 建议买入区间（可选）
---
## 五、模块三：小果情报分析
### 5.1 小果能力概述
| 能力 | 适用场景 | 精度要求 | 频率 |
|------|---------|---------|------|
| 新闻情感分类 | 个股新闻/行业新闻 → 正面/负面/中性 | 70%+ 即可 | 每日 |
| 量价异常标注 | 当日成交量/换手率/量比异常识别 | 80%+ | 每日20:00 |
| 行业热词提取 | 行业新闻关键词提取 | 可接受 | 每日 |
| 简单问答 | 替代知微做低精度任务 | 看情况 | 按需 |
**调用方式**：
- 知微通过 Hermes delegate_task 向 xiaoguo profile 派发任务
- 或通过 API 直调（http://192.168.1.122:8645）
- 小果的结果作为知微分析的输入参考
### 5.2 新闻情感分析
**输入**：从 web_search 搜索到的个股/行业新闻标题+摘要
**输出**（JSON）：
```json
{
"code": "00700",
"name": "腾讯控股",
"news": [
{
"title": "腾讯游戏业务Q2增长超预期",
"source": "新浪财经",
"sentiment": "positive",
"confidence": 0.85,
"keywords": ["游戏", "超预期", "增长"]
}
],
"overall_sentiment": "positive"
}
```
**实现方式**：
- 知微在评估 cron 中，web_search 拉取新闻后，将新闻文本发给小果分类
- 小果返回情感标签 + 置信度
- 知微汇总到 D5 消息面分析
### 5.3 量价异常标注
**输入**：当日行情数据（收评）——价格/成交量/换手率/量比
**输出**（JSON）：
```json
{
"code": "300750",
"name": "宁德时代",
"anomalies": [
{
"type": "volume_surge",
"detail": "今日成交量3.2倍于20日均量",
"assessment": "放量下跌，警惕"
}
]
}
```
**异常类型**：
- `volume_surge`: 量比>2 的异常放量
- `volume_shrink`: 量比<0.5 的异常缩量
- `price_volume_divergence`: 价量背离（价涨量缩或价跌量放）
- `turnover_spike`: 换手率异常高（>20只日均换手3倍）
- `amplitude_surge`: 振幅异常大
**实现方式**：
- 数据收集脚本（collect_evaluation_data.py）收评后，将当日数据发给小果
- 小果标注异常点
- 标注结果写入 evaluation_input.json 的 anomaly 字段
### 5.4 持续情报监控（新增）
让**小果持续跑**，不只在收评时分析：
```
小果持续运行（每15-30分钟）
↓
扫描行业热点数据（market.json）
↓
发现异常 → 写入 小果情报日志
↓
知微评估 cron 读取情报日志，判断是否有价值 → 整合到分析报告
```
**持续监控内容**：
- 行业排行榜变化：前3名/末3名的行业
- 涨跌比变化：上涨/下跌比例突变
- 资金流向变化：突然转向的行业
- 新闻突发：web_search 发现的重大新闻
---
## 六、废弃清单
### 立即废弃
| 组件 | 原因 | 替代 |
|------|------|------|
| `strategy_evaluator.py` 中的评估逻辑（R/R、评分、阶段一/二） | LLM cron 做六维评估，脚本不做判断 | 保留脚本做数据采集/统计部分 |
| 旧 cron `b818e2bfd8d1`（市场数据采集 LLM 版） | 不可靠、数据虚假 | 新建 no_agent market_watch cron |
| `market.json` 旧数据 | 虚假数据 | 新 market_watch 覆盖 |
### 逐步废弃
| 组件 | 原因 | 替代 |
|------|------|------|
| 旧 `EXPERT_SYSTEM_DESIGN.md`（项目目录和 Dashboard 目录各一份） | 过时，与新系统不一致 | 新需求文档统一管理 |
| `stock_profiles.json` 中空字段 | 无数据占位 | 自动补全脚本 |
---
## 七、实施优先级
### P0（当前可做）
1. 修复 market_watch 脚本：输出目录改为 Dashboard data/
2. 创建 market_watch cron（no_agent，每30分钟）
3. 小果 API 调用验证（发一条简单测试）
4. 废弃旧 market.json + 旧 cron
### P1（本周）
5. stock_profiles.json 行业自动补全脚本
6. 知微洞察 MVP（每日1条有价值洞察）
7. 小果新闻情感分析接入
### P2（下周）
8. 潜力股挖掘 MVP
9. 小果持续情报监控
10. 行业数据刷新 Dashboard 展示
### P3（远期）
11. 行业资金流向可视化
12. 行业轮动预警系统
13. 小果自主情报Bot（主动推送）
---
## 八、关联文件规范
所有本需求涉及的组件，必须在以下文件中标注链接：
- `strategy-evaluation` skill 中标注 D2/D5 数据源为 market.json + 小果
- `mofin-system-arch` skill（如有）中标注新模块
- `collect_evaluation_data.py` 中标注加入行业数据合并
- 本需求文档链接进所有相关 skill 的 references 部分
---
*本需求文档为权威需求，高于任何 skill/记忆/脚本中的描述。如有不一致，以本文档为准。*
docs/market-screening-pipeline.md
+225
View File
@@ -0,0 +1,225 @@
# 全市场潜力股筛选 - LLM调用流程与提示词文档
## 概述
本流程在收盘后（16:00）通过一个 LLM cron（市场精选推荐-每日）一次性完成。全程只有一个 LLM 入口：**我（知微，deepseek-v4-flash）** 根据 cron prompt 的指令逐步执行。
数据采集层（market_watch.py）为 no_agent 脚本，不调 LLM，只拉 API 写文件。
---
## 一、数据源准备（15:30，no_agent，不调LLM）
### market_watch.py
对 A 股 90 个行业板块逐个拉取同花顺（akshare）数据，写入 `market.json`：
```json
{
"timestamp": "2026-06-19 15:30",
"source": "ths", // 数据来源：ths/eastmoney
"total_sectors": 90,
"up_ratio": 27.8, // 上涨板块占比(%)
"mood": "bearish", // bullish/neutral/bearish
"top_gainers": [...], // 涨幅前5
"top_losers": [...], // 跌幅前3
"sectors": [
{
"name": "半导体", // 板块名称
"change": 2.29, // 涨跌幅(%)
"up_count": 131, // 上涨家数
"down_count": 46, // 下跌家数
"net_inflow": 120.97, // 资金净流入(亿)
"lead_stock": "晶升股份", // 领涨股名
"lead_stock_change": 20.01 // 领涨股涨跌幅(%)
},
...
],
"insights": [...] // 旧管道残留，可忽略
}
```
注意：`source` 为 `eastmoney` 时，`change` 单位是万分比（如 596 = 5.96%），需除以 100；`source` 为 `ths` 时已是百分比。
---
## 二、LLM 入口
### 2.1 定时触发
```
cron 任务: 市场精选推荐-每日
job_id: 759064f56c03
时间: 0 16 * * 1-5（交易日16:00）
模型: deepseek-v4-flash（通过 Hermes gateway，hermes-agent model name）
Tools: terminal, file, web, search
```
### 2.2 完整 Prompt
以下为 cron prompt 的完整内容。LLM（即我）按照这个提示一步步执行，每一步的思考过程不对外输出，最终产出是写入数据文件 + 返回报告文本。
```
## 任务：每日全市场潜力股精选 + 星级推荐
收盘后执行。分三步，每一步都要出具体结果，不能输出模板示例。
### 第1步：读数据
读 /home/hmo/web-dashboard/data/market.json：
- sectors[] — 全行业板块数据（名称、涨跌幅、涨跌家数、资金流入、领涨股）
- source — 数据来源（ths 或 eastmoney，影响涨跌幅单位：ths已是百分比，EM需除以100）
读 /home/hmo/web-dashboard/data/candidate_pool.json — 历史候选池
### 第2步：全市场筛选
用 market.json 的板块数据做分析：
**2a 市场判断**
分析涨跌比、领涨板块特征，输出一句话判断：强势/中性/弱势 + 理由。
写入 market.json 的 market_verdict 和 verdict_reason 字段。
**2b 选热门行业**
从涨幅前10板块中选出2-3个你最看好的行业。
标准：不只看出涨幅，还要看涨跌家数比（上涨家数远大于下跌家数）、资金流入为正、不是一日游。
每个行业给一句话理由。
写入 market.json 的 hot_sectors 字段。
**2c 选危险行业**
从跌幅前5板块中选出1-2个需回避的行业。
写入 market.json 的 danger_sectors 字段。
**2d 查个股**
对每个热门行业，用腾讯API查该行业知名龙头股的当前价格：
`curl -s --noproxy '*' "http://qt.gtimg.cn/q=sh{代码}"` 或 `sz{代码}`
解析格式：vt_sh代码="1~名称~...~第4字段=当前价~...~第32字段=涨跌幅"
用真实价格辅助判断。
选2-3只候选股，每只给出：
- 评分 1-10（9-10强趋势+最佳时机；7-8板块向好+安全边际；5-6有逻辑但需等入场）
- 推荐理由一句话
- 入场区间（具体数字）
- 止损价（具体数字）
- 目标价（具体数字）
### 第3步：更新候选池 + 出推荐
将上述结果与 candidate_pool.json 合并：
- 新的候选股 → 新增（xiaoguo_score填评分，num_observations=1）
- 已有候选 → 更新评分，追加评分历史，num_observations+1
- 连续3次评分下降 → trend_warning=true
- 平均分<5或7天未更新 → dropped=true
从候选池中选出最佳推荐（满足：未淘汰、未推荐过、评分>=7）：
- 用你的知识做最终验证
- 给星级：5.0/4.5/4.0/3.5/3.0
- 写入 zhiwei_star、zhiwei_reviewed=true
- promoted=true
### 输出格式
最终回复必须包含以下内容，直接发给老爸：
【📊 今日市场】
判断：强势/中性/弱 — 一句话理由
热门行业：xxx（理由）、xxx（理由）
风险行业：xxx（理由）
【⚡ 潜力股推荐】
按星级排序，每只格式：
股票名(代码) ★星级 | 所属板块
入场区间 X~X | 止损 X | 目标 X
理由：一句话
【📋 候选池状态】
活跃X只，今日新增X只，已推荐X只，淘汰X只
没有符合条件的就说"今日无符合条件的新标的"。
禁止使用：可关注、可考虑、建议观察、试试、谨慎关注、择机
```
---
## 三、执行细节
### 3.1 LLM 工具调用序列
在实际执行中，LLM 会依次调用以下工具：
| 顺序 | 工具 | 用途 |
|------|------|------|
| 1 | read_file market.json | 读板块数据 |
| 2 | read_file candidate_pool.json | 读历史候选池 |
| 3 | read_file xiaoguo_insights.json | 读当日情感（可选） |
| 4 | terminal curl 腾讯API | 验证候选股实时价格（每只一次） |
| 5 | write_file candidate_pool.json | 写回更新后的候选池 |
| 6 | write_file market.json | 写回 market_verdict/hot_sectors 等 |
| 7 | 最终回复 | 输出报告文本 |
### 3.2 腾讯API调用示例
```bash
# 沪市股票
curl -s --noproxy '*' "http://qt.gtimg.cn/q=sh688981"
# 返回: v_sh688981="1~中芯国际~688981~140.50~..."
# 字段[3]=当前价, 字段[32]=涨跌幅
# 深市股票
curl -s --noproxy '*' "http://qt.gtimg.cn/q=sz002371"
```
### 3.3 候选池治理规则（硬编码在 LLM 指令中）
由 LLM 在执行第3步时自行判断：
- 候选评分连续 3 次下降 → trend_warning=true
- 近 3 次平均分 < 5 → dropped=true
- 距上次更新超过 7 天 → dropped=true
- dropped 的候选保留在池中供追溯，不再参与推荐
---
## 四、完整数据流
```
┌────────────────────────────────────────────────────────┐
│ 15:30 数据采集层（no_agent） │
│ │
│ market_watch.py │
│ → akshare 拉取同花顺90个行业板块 │
│ → 写入 /data/market.json │
└──────────────────────┬─────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────┐
│ 16:00 LLM层（deepseek-v4-flash，单次cron调用） │
│ │
│ 读 market.json │
│ → 分析涨跌比 → market_verdict │
│ → 选热门行业 → hot_sectors │
│ → 选危险行业 → danger_sectors │
│ → 写回 market.json │
│ │
│ 读 candidate_pool.json │
│ → 腾讯API查实时价 → 验证候选 │
│ → 合并新候选、更新评分、淘汰劣质 │
│ → 写回 candidate_pool.json │
│ → 给最终星级 → 输出报告 │
└──────────────────────┬─────────────────────────────────┘
│
▼
老爸收到三段式报告
```
---
## 五、与其他管道的关系
| 管道 | 时间 | 关系 |
|------|------|------|
| 市场数据采集 (market_watch) | 每30分 | 本管道的唯一数据源 |
| 市场精选推荐 (本管道) | 16:00 | 依赖 market_watch 的最新一次写入 |
| 小果情感分析 | 16:00 | 独立管道，结果写入 xiaoguo_insights.json，本管道可选读取 |
| 策略评估-每日 | 21:00 | 与本管道无关，独立评估持仓策略 |
| 知识萃取 | 16:30 | 本管道的输出可作为知识萃取的输入 |
docs/market-screening-system-design.md
+187
View File
@@ -0,0 +1,187 @@
# 全市场潜力股挖掘系统设计
## 目标
打破持仓和自选的局限，从全 A 股市场挖掘新投资标的，附带入场策略和动态星级评分。
## 整体架构（两层式）
```
市场数据(market.json)
│ 每30分更新
▼
┌──────────────────────────────────────┐
│ 第一层：小果本地LLM · 高频低耗 │
│ │
│ 每轮1-2个板块，积少成多覆盖全市场 │
│ → 分析板块趋势 │
│ → 筛选成分股 │
│ → 给出初步评分+策略 │
│ → 写入候选池(candidate_pool.json) │
└──────────────────┬───────────────────┘
│
▼
┌──────────────────────────────────────┐
│ 第二层：知微（主模型）· 低频高质 │
│ │
│ 每日收盘后 │
│ → 读候选池 │
│ → 用技术分析+策略引擎验证 │
│ → 确认星级(5/4.5/4/3.5/3) │
│ → 输出最终推荐+推送 │
│ → 已推荐的标记 promoted │
└──────────────────────────────────────┘
```
## 候选池设计
### candidate_pool.json 结构
```json
{
"last_updated": "2026-06-19 15:30",
"total_candidates": 12,
"sectors_analyzed_today": ["半导体", "消费电子", "汽车零部件"],
"candidates": [
{
"code": "600000",
"name": "XX股份",
"sector": "半导体",
"added_at": "2026-06-19 10:30",
"last_updated": "2026-06-19 15:30",
"num_observations": 3,
"xiaoguo_score": 8.2,
"xiaoguo_reason": "放量突破前高，板块龙头",
"xiaoguo_strategy": {
"entry_range": "18.5~19.2",
"stop_loss": "17.5",
"target": "22.0"
},
"score_history": [
{"date": "2026-06-19 10:30", "score": 7.5},
{"date": "2026-06-19 11:00", "score": 8.0},
{"date": "2026-06-19 15:30", "score": 8.2}
],
"zhiwei_star": null,
"zhiwei_reviewed": false,
"zhiwei_reviewed_at": null,
"promoted": false,
"promoted_at": null,
"dropped": false,
"drop_reason": null
}
]
}
```
### 候选池治理规则
- 评分历程 >= 3 次且均分 < 5 → 自动淘汰
- 连续 3 次评分下降 → 标记预警，下轮淘汰
- 超过 7 天未评分 → 标记过期待重评
- 已 promoted（确认推荐）→ 保留供回顾，不重复推
## 第一层：小果筛选（no_agent 脚本）
### 文件：market_screener.py
**触发频率：** 每 60 分钟（跟随 market_watch 节奏，间隔一次执行）
**每轮流程：**
1. 读 market.json → 取行业板块涨幅排名
2. 选择本轮分析的板块：
- 优先级：涨幅前 10 中「累计分析次数最少」的板块
- 确保一周内覆盖所有活跃板块
- 每轮分析 2 个板块
3. 对每个板块：
a. `ak.stock_board_industry_cons_ths()` → 取成分股
b. 基础过滤：涨幅 > 0、价格 3~100 元、有成交量
c. 取前 5~8 只候选
d. 调小果 LLM API 分析 → 返回评分+策略
4. 更新 candidate_pool.json（新增候选 + 刷新已有候选的评分）
**小果 LLM Prompt：**
```
你是一位A股市场分析助手。分析以下板块和个股，筛选潜力候选股。
板块：{sector_name}
板块涨幅：{change}%
上涨/总家数：{up_count}/{total_count}
资金净流入：{net_inflow}亿
领涨股：{lead_stock} +{lead_stock_change}%
成分股（涨幅前8）：
代码 | 名称 | 现价 | 涨跌幅 | 换手率
{a} | {b} | {c} | {d} | {e}
判断标准：
1. 板块是真强势还是短期反弹？看量价配合和领涨股持续性
2. 个股：量价配合好、趋势健康、不是单纯跟涨
3. 给出 1-10 分（7分以上才值得关注）
输出JSON：
{
"sector_judgment": "强势|中性|弱势",
"sector_reason": "一句话理由",
"candidates": [
{
"code": "600xxx",
"name": "名称",
"score": 8.5,
"reason": "选股理由含技术面特征",
"entry_range": "18.5~19.2",
"stop_loss": "17.5",
"target": "22.0"
}
]
}
```
**代码注意事项：**
- 小果 API 调用超时设 120s（27B 模型较慢）
- 调用失败时跳过该板块，下次重试
- 输出只写文件，不输出到 stdout（no_agent 静默模式）
## 第二层：知微精选（LLM cron）
**触发时间：** 每日 16:00（收盘后）
**流程：**
1. 读 candidate_pool.json → 取未 reviewed 且评分 >= 7 的候选
2. 对每个候选用我的技术分析工具验证
3. 综合打分 → 星级（5/4.5/4/3.5/3）
4. 输出最终 2-3 只推荐（含完整策略）
5. 写入 market.json 的 potential_stocks 字段
6. 标记 promoted
**星级标准：**
- 5.0：强趋势+板块强势+技术面完美+入场时机佳
- 4.5：趋势健康+板块向好+技术面良好+有安全边际
- 4.0：板块和个股都OK，但缺明确催化剂
- 3.5：有逻辑但需要等待更好入场点
- 3.0以下：不推荐
## 时序与 cron 设计
| 时间 | 组件 | 类型 | 频率 | 说明 |
|------|------|------|------|------|
| 9:00~15:30 | market_watch | no_agent | 每30分 | 已有，采集板块数据 |
| 9:30~15:30 | market_screener | no_agent | 每60分 | 新脚本，小果筛股 |
| 16:00 | 市场精选推荐 | LLM | 每日 | 新cron，我出最终推荐 |
## 文件清单
| 文件 | 类型 | 说明 |
|------|------|------|
| /home/hmo/web-dashboard/market_screener.py | 新脚本 | 小果筛选引擎 |
| /home/hmo/web-dashboard/data/candidate_pool.json | 新数据 | 候选池 |
| /home/hmo/web-dashboard/market_insight.py | 废弃 | 被替换 |
| /home/hmo/web-dashboard/inject_xiaoguo_insight.py | 保留 | 仍需要注入情感到market.json |
## 关联修改
1. market_insight.py 停用（cron 改为新脚本）
2. 新 cron job：市场精选推荐（LLM，16:00）
3. 小果筛选 cron：market_screener.py（no_agent，每60分）
docs/mofin-database-architecture.md
+395
View File
@@ -0,0 +1,395 @@
# MoFin 统一数据库架构设计
## 目标
将 MoFin 系统目前散落在各 JSON 文件中的数据统一纳入 SQLite 数据库，实现：
- 数据关系化（板块 ↔ 个股 ↔ 持仓 ↔ 策略，SQL join 直连）
- 历史可追溯（板块快照、价格序列、评分变更全部时序化）
- 操作 no_agent 化（纯 SQL 即可完成大部分查询和分析）
- 增量迁移（现有 JSON 不动，新数据双写，逐步切换）
---
## 一、数据库概览
```
数据库文件: /home/hmo/web-dashboard/data/mofin.db
引擎: SQLite 3
```
### 逻辑分组
| 组 | 表 | 说明 |
|----|-----|------|
| 市场 | market_snapshots, sector_snapshots | 全市场板块快照（每30分） |
| 个股 | stocks, stock_daily, stock_weekly, stock_monthly, stock_fundamentals | 个股K线+基本面 |
| 板块成分 | stock_sectors | 个股所属板块映射 |
| 持仓 | holdings, holding_strategies | 持仓股+策略参数 |
| 自选 | watchlist_stocks | 自选股+买入区 |
| 候选池 | candidates, candidate_score_history | 小果+知微潜力股推荐 |
| 事件 | price_events, zone_breaches | 价格预警、区间触发 |
| 策略评估 | strategy_evaluations | 策略重评记录 |
---
## 二、表结构详述
### 2.1 市场/板块快照
核心时间序列表。每次 market_watch 执行（每30分）写一条 snapshot，再把每个板块的数据写入 sector_snapshots。
```sql
-- 每次采集的元信息
CREATE TABLE market_snapshots (
id INTEGER PRIMARY KEY AUTOINCREMENT,
timestamp TEXT NOT NULL, -- '2026-06-19 15:30'
source TEXT NOT NULL DEFAULT 'ths', -- ths / eastmoney
up_ratio REAL, -- 上涨板块占比(%)
mood TEXT, -- bullish / neutral / bearish
created_at TEXT DEFAULT (datetime('now','localtime'))
);
CREATE INDEX idx_snapshots_time ON market_snapshots(timestamp);
-- 每个板块在每次采集中的快照数据
CREATE TABLE sector_snapshots (
id INTEGER PRIMARY KEY AUTOINCREMENT,
snapshot_id INTEGER NOT NULL REFERENCES market_snapshots(id),
name TEXT NOT NULL, -- 板块名称（同花顺行业名）
change_pct REAL, -- 涨跌幅(%)
up_count INTEGER, -- 上涨家数
down_count INTEGER, -- 下跌家数
net_inflow REAL, -- 资金净流入(亿)
lead_stock TEXT, -- 领涨股名
lead_stock_change REAL, -- 领涨股涨跌幅(%)
volume REAL, -- 成交量(万手)
turnover REAL -- 成交额(亿)
);
CREATE INDEX idx_sector_name ON sector_snapshots(name);
CREATE INDEX idx_sector_snapshot ON sector_snapshots(snapshot_id);
CREATE INDEX idx_sector_name_time ON sector_snapshots(name, snapshot_id);
```
**典型查询：**
```sql
-- 半导体板块最近5天的涨跌幅趋势
SELECT s.timestamp, ss.change_pct, ss.net_inflow
FROM sector_snapshots ss
JOIN market_snapshots s ON ss.snapshot_id = s.id
WHERE ss.name = '半导体'
ORDER BY s.timestamp DESC LIMIT 10;
-- 资金连续3天净流入的板块（最近3次采集）
SELECT name, COUNT(*) as times, AVG(net_inflow) as avg_inflow
FROM sector_snapshots ss
JOIN market_snapshots s ON ss.snapshot_id = s.id
WHERE s.timestamp >= date('now', '-3 days')
AND net_inflow > 0
GROUP BY name
HAVING COUNT(*) >= 3
ORDER BY avg_inflow DESC;
```
---
### 2.2 个股K线 + 基本面
替代现有的 multi_tf_cache.json 和 data/stocks/*.json。
```sql
CREATE TABLE stocks (
code TEXT PRIMARY KEY, -- '688981'
name TEXT NOT NULL, -- '中芯国际'
exchange TEXT DEFAULT 'SH', -- SH / SZ / HK
type TEXT DEFAULT 'A', -- A / H
updated_at TEXT
);
-- 日线数据（时间序列）
CREATE TABLE stock_daily (
code TEXT NOT NULL REFERENCES stocks(code),
date TEXT NOT NULL, -- '2026-06-19'
open REAL,
close REAL,
high REAL,
low REAL,
volume REAL, -- 成交量
amount REAL, -- 成交额
PRIMARY KEY (code, date)
);
-- 周线数据
CREATE TABLE stock_weekly (
code TEXT NOT NULL REFERENCES stocks(code),
date TEXT NOT NULL, -- 周结束日期
open REAL, close REAL, high REAL, low REAL,
volume REAL,
PRIMARY KEY (code, date)
);
-- 月线数据
CREATE TABLE stock_monthly (
code TEXT NOT NULL REFERENCES stocks(code),
date TEXT NOT NULL, -- 月结束日期
open REAL, close REAL, high REAL, low REAL,
volume REAL,
PRIMARY KEY (code, date)
);
-- 基本面（最新，非时序）
CREATE TABLE stock_fundamentals (
code TEXT PRIMARY KEY REFERENCES stocks(code),
pe REAL, -- 市盈率
pb REAL, -- 市净率
eps REAL, -- 每股收益
mcap_total REAL, -- 总市值
mcap_flow REAL, -- 流通市值
updated_at TEXT
);
```
---
### 2.3 板块成分股映射
个股和板块的关系表。目前股票不知道自己在哪个板块，板块不知道有哪些成分股。这使 join 分析无法进行。
```sql
CREATE TABLE stock_sectors (
code TEXT NOT NULL REFERENCES stocks(code),
sector_name TEXT NOT NULL, -- 板块名称（与 sector_snapshots.name 一致）
source TEXT DEFAULT 'ths', -- 数据来源
updated_at TEXT DEFAULT (datetime('now','localtime')),
PRIMARY KEY (code, sector_name)
);
CREATE INDEX idx_stock_sector ON stock_sectors(sector_name);
```
**典型查询：**
```sql
-- 我的持仓股所在的板块今天表现如何
SELECT h.code, h.name, ss.change_pct, ss.net_inflow
FROM holdings h
JOIN stock_sectors ss_map ON h.code = ss_map.code
JOIN sector_snapshots ss ON ss_map.sector_name = ss.name
JOIN market_snapshots ms ON ss.snapshot_id = ms.id
WHERE ms.timestamp = (SELECT MAX(timestamp) FROM market_snapshots)
ORDER BY ss.change_pct DESC;
```
---
### 2.4 持仓
```sql
CREATE TABLE holdings (
code TEXT PRIMARY KEY REFERENCES stocks(code),
name TEXT NOT NULL,
shares INTEGER NOT NULL, -- 持股数
cost REAL, -- 成本价
position_pct REAL, -- 仓位占比(%)
added_at TEXT, -- 买入时间
is_active INTEGER DEFAULT 1, -- 1=持仓中, 0=已卖出
closed_at TEXT, -- 卖出时间
close_pnl REAL -- 最终盈亏(%)
);
-- 持仓策略参数（可重评，保留历史）
CREATE TABLE holding_strategies (
id INTEGER PRIMARY KEY AUTOINCREMENT,
code TEXT NOT NULL REFERENCES holdings(code),
version INTEGER DEFAULT 1, -- 策略版本号
stop_loss REAL, -- 止损价
take_profit REAL, -- 止盈价
entry_low REAL, -- 买入区下沿
entry_high REAL, -- 买入区上沿
strategy_type TEXT DEFAULT 'holding', -- holding / watch
source TEXT, -- reassess / manual / initial
reason TEXT, -- 策略理由
created_at TEXT DEFAULT (datetime('now','localtime')),
superseded_at TEXT -- 被新版本替代的时间
);
CREATE INDEX idx_strategy_code ON holding_strategies(code);
```
---
### 2.5 自选股
```sql
CREATE TABLE watchlist_stocks (
code TEXT PRIMARY KEY REFERENCES stocks(code),
name TEXT NOT NULL,
added_at TEXT DEFAULT (datetime('now','localtime')),
is_active INTEGER DEFAULT 1
);
-- 自选股买入区策略（关联到 holding_strategies，共用策略表）
```
说明：自选股的买入区策略直接使用 `holding_strategies` 表（`strategy_type='watch'`），不需要单独建表。
---
### 2.6 候选池
```sql
CREATE TABLE candidates (
code TEXT PRIMARY KEY REFERENCES stocks(code),
name TEXT NOT NULL,
sector TEXT, -- 所属板块
reason TEXT, -- 推荐理由
entry_range TEXT, -- '49.00-52.00'
stop_loss REAL,
target REAL,
zhiwei_star REAL, -- 知微星级 5.0/4.5/4.0/3.5/3.0
zhiwei_reviewed INTEGER DEFAULT 0,
zhiwei_reviewed_at TEXT,
promoted INTEGER DEFAULT 0, -- 是否已向老爸推荐过
promoted_at TEXT,
dropped INTEGER DEFAULT 0,
drop_reason TEXT,
created_at TEXT DEFAULT (datetime('now','localtime'))
);
-- 评分历史（每次小果/知微评分的记录）
CREATE TABLE candidate_score_history (
id INTEGER PRIMARY KEY AUTOINCREMENT,
code TEXT NOT NULL REFERENCES candidates(code),
score REAL NOT NULL, -- 评分 1-10
source TEXT NOT NULL, -- xiaoguo / zhiwei
reason TEXT,
created_at TEXT DEFAULT (datetime('now','localtime'))
);
CREATE INDEX idx_candidate_history ON candidate_score_history(code, created_at);
```
**典型查询：**
```sql
-- 候选池状态（活跃候选及其最新评分）
SELECT c.code, c.name, c.sector, c.zhiwei_star, c.promoted,
(SELECT score FROM candidate_score_history
WHERE code = c.code ORDER BY created_at DESC LIMIT 1) as latest_score
FROM candidates c
WHERE c.dropped = 0
ORDER BY c.zhiwei_star DESC NULLS LAST;
-- 某候选的评分趋势
SELECT created_at, score, source
FROM candidate_score_history
WHERE code = '688981'
ORDER BY created_at;
```
---
### 2.7 价格事件
```sql
CREATE TABLE price_events (
id INTEGER PRIMARY KEY AUTOINCREMENT,
code TEXT NOT NULL REFERENCES stocks(code),
name TEXT,
event_type TEXT NOT NULL, -- entry_zone / stop_breach / take_profit / zone_warning
price REAL, -- 触发时价格
trigger_value TEXT, -- '15.36-16.49' 区间描述
event_label TEXT, -- '买入区' / '止损预警'
created_at TEXT DEFAULT (datetime('now','localtime')),
date TEXT -- 触发日期
);
CREATE INDEX idx_events_code ON price_events(code);
CREATE INDEX idx_events_date ON price_events(date);
```
---
### 2.8 策略评估记录
```sql
CREATE TABLE strategy_evaluations (
id INTEGER PRIMARY KEY AUTOINCREMENT,
code TEXT NOT NULL REFERENCES stocks(code),
eval_type TEXT NOT NULL, -- daily / weekly / adhoc
status TEXT DEFAULT 'pending', -- pending / completed / error
old_stop_loss REAL,
new_stop_loss REAL,
old_tp REAL,
new_tp REAL,
reason TEXT,
created_at TEXT DEFAULT (datetime('now','localtime'))
);
```
---
## 三、与现有系统的关系
### 3.1 分步迁移计划
```
阶段1：新库就位
→ 创建 mofin.db + 所有表
→ market_watch.py 改：写 market.json（保留兼容）+ 同时写 market_snapshots / sector_snapshots
→ 验证：数据正常双写，旧管道不受影响
阶段2：个股数据迁移
→ refresh_mtf_cache.py 改：写 multi_tf_cache.json + 同时写 stock_daily/weekly/monthly
→ 新增 stock_sectors 填充（从 market.json 的板块数据提取成分股）
→ 验证：K线数据在SQLite可查
阶段3：业务表迁移
→ portfolio / watchlist / candidate_pool 逐步迁移
→ 每个模块：先写JSON+SQLite双写，确认无问题后切到SQLite
→ 淘汰对应JSON文件
阶段4：no_agent 化
→ 通用查询脚本：mofin_query.py "SELECT ..." → 输出JSON/TEXT
→ 定时报表：纯SQL生成，无需LLM
→ 预警规则：SQL条件 → 推送通知
```
### 3.2 JSON 文件保留策略
| 文件 | 阶段1 | 阶段2 | 阶段3 | 阶段4 |
|------|-------|-------|-------|-------|
| market.json | ✅ 双写 | ✅ 双写 | ❌ 淘汰 | — |
| multi_tf_cache.json | — | ✅ 双写 | ❌ 淘汰 | — |
| portfolio.json | — | — | ✅ 双写 | ❌ 淘汰 |
| watchlist.json | — | — | ✅ 双写 | ❌ 淘汰 |
| candidate_pool.json | — | — | ✅ 双写 | ❌ 淘汰 |
| price_events.json | — | — | ✅ 双写 | ❌ 淘汰 |
| decisions.json | — | — | ⚠️ 按需迁移 | — |
---
## 四、关键关联路径
以下是最有价值的跨表查询链：
```
持仓股 → stock_sectors（查所属板块）→ sector_snapshots（板块最近表现）
↓
sector_snapshots 历史（板块趋势）
↓
stock_daily（个股K线与板块对比）
↓
candidate_score_history（候选评分变化）
事件触发 → stock_daily（看当日量价）→ holding_strategies（检查策略偏离）
↓
strategy_evaluations（策略重评记录）
```
---
## 五、迁移风险控制
- 每条写操作先写 JSON（现有流程不受影响），再写 SQLite
- SQLite 写失败时降级报警，不阻塞 JSON 写
- 全部验证通过后才切掉 JSON
- 所有变更通过 market_watch.py / refresh_mtf_cache.py 的 patch 实现，不重写
docs/strategy-evaluation-requirements.md
+110
View File
@@ -0,0 +1,110 @@
# 策略评估系统 — 需求文档
> 版本: v1.0 | 最后更新: 2026-06-18 | 状态: 生效
> 来源: 老爸直接口述批注，最高优先级需求文档
---
## 一、评估的范围（管谁）
所有持仓股（position > 0 的）和所有自选股。每次评估全覆盖，不遗漏。
A股和港股分开处理。
---
## 二、评估的频率和触发方式
三种触发方式：
1. **每日收盘后推送一次全面评估** — 21:00 定时，走 XMPP 推送
2. **盘中异动触发** — 涨跌 >±5%、成交突然放大、有突发新闻
3. **老爸主动问的时候** — 拉实时数据出六维评估
---
## 三、每个股票要评估的六个维度
### 维度1 — 宏观环境
大盘当天涨跌：
- A股：上证指数 + 深证成指 + 富时A50
- 港股：恒生指数 + 恒生科技指数
输出：当前是普涨还是普跌，系统性风险信号（有/无/一般）。
### 维度2 — 行业表现
- 该股所属行业当天涨跌幅
- 相对大盘的强弱（跑赢/跑输/同步）
- 行业内的横向对比（同行业其他自选股表现如何）
### 维度3 — 技术面（当前，不是历史快照）
- 当前支撑位和压力位（基于近期K线和今日数据）
- K线形态
- 量价关系
- 趋势判断（向上/向下/震荡）
### 维度4 — 基本面
- PE、PB（如果能拿到）
- 估值高低判断
- 股价相比历史区间的位置
### 维度5 — 消息面
- 公司公告、业绩预警、行业政策变化、市场传闻
- 上网搜索最近3天有无相关新闻
### 维度6 — 资金面
- 成交额和换手率
- 当日资金流向（主动买入 vs 主动卖出）
---
## 四、策略评估逻辑（三个阶段的递进判断）
### 阶段一：原有策略是否正确
当初给的买入区、止损价、止盈价，股价是否到过这些价位？到了之后往哪个方向走了？
如果策略是错的，错在哪里？
### 阶段二：当前是否还安全
止损价有没有被跌破的可能性？止盈价是否还合理？需要调整吗？
### 阶段三：现在该怎么做
**基于阶段一和阶段二的结论，确认当前的止损和止盈价格，并描述理由。**
基于现价、R/R、持仓成本，给出确定的操作建议（加仓/减仓/持有/止损/调价）。
不做选择题，只给唯一确定建议。
---
## 五、输出的呈现规则
- 优先排序：有紧急信号的放最前面，不用动的放最后
- 每只股票最多6行六维概要，不限篇幅但信息要精炼
- 必带具体价格（买入/卖出/止损/止盈都带数字）
- 不允许"可关注""可考虑""择机"这类模糊词
- 整个报告800字左右，快速评估版不超过500字
- **所有股票都要给理由，不只是深套股**
---
## 六、与其他系统的关系
- 推送走 XMPP
- 数据来源：腾讯行情API / 网络搜索（消息面）
- 不依赖钉钉
- daily cron 21:00 跑完整评估
- 评估结果写入 decisions.json（评估记录持久化）
---
## 七、变更记录
| 日期 | 版本 | 变更内容 | 批准人 |
|------|------|----------|--------|
| 2026-06-18 | v1.0 | 初版，老爸口述批注整理 | 老爸 |