docs: 文档治理2026-08-11——归档7份过时文档+57份研究过程文档,重写README,新增doc-audit核实报告
This commit is contained in:
+22
-15
@@ -1,6 +1,7 @@
|
||||
# MoFin 文档中心
|
||||
|
||||
> 文档驱动开发。每次代码变更必须同步更新对应文档。
|
||||
> 最后更新:2026-08-11(文档治理:归档 7 份过时文档 + 57 份研究过程文档,见 doc-audit-20260811.md)
|
||||
|
||||
---
|
||||
|
||||
@@ -10,10 +11,11 @@
|
||||
|
||||
| # | 文档 | 内容 | 时间 |
|
||||
|---|------|------|------|
|
||||
| 1 | **[SYSTEM_ARCHITECTURE.md](SYSTEM_ARCHITECTURE.md)** | 系统总览:架构图、数据流、模块职责 | 10 min |
|
||||
| 2 | **[portfolio-data-model.md](portfolio-data-model.md)** | 核心数据模型:表结构、币种规则、常见错误 | 10 min |
|
||||
| 3 | **[DEVELOPMENT_STANDARDS.md](DEVELOPMENT_STANDARDS.md)** | 开发规范:代码结构、DB 规范、Prompt 规范、开发流程 | 15 min |
|
||||
| 4 | **[CHANGELOG.md](../CHANGELOG.md)** | 变更日志:所有改动的完整记录 | 5 min |
|
||||
| 1 | [portfolio-data-model.md](portfolio-data-model.md) | 核心数据模型:表结构、币种规则、常见错误 | 10 min |
|
||||
| 2 | [DEVELOPMENT_STANDARDS.md](DEVELOPMENT_STANDARDS.md) | 开发规范:代码结构、DB 规范、Prompt 规范、开发流程 | 15 min |
|
||||
| 3 | [CHANGELOG.md](../CHANGELOG.md) | 变更日志:所有改动的完整记录 | 5 min |
|
||||
|
||||
> 系统架构总览已归档(archive/SYSTEM_ARCHITECTURE-root.md)——当前架构以数据模型 + 方法论文档为准。
|
||||
|
||||
### 🔧 日常开发
|
||||
|
||||
@@ -27,29 +29,33 @@
|
||||
|
||||
| 文档 | 内容 |
|
||||
|------|------|
|
||||
| [cron-catalog.md](cron-catalog.md) | Cron 任务清单(知微维护) |
|
||||
| [decisions-db-migration.md](decisions-db-migration.md) | JSON→DB 迁移记录(✅ 已完成) |
|
||||
| [cron-review-poversold-20260811.md](cron-review-poversold-20260811.md) | **Cron 梳理报告**(对照 p_oversold 部署,停8/保持30/调整8/新增2)|
|
||||
| [cron-catalog.md](cron-catalog.md) | Cron 任务清单(⚠️ 6/27 版,过时待重建)|
|
||||
| [QUICKSTART.md](QUICKSTART.md) | 快速操作手册 |
|
||||
| [DASHBOARD.md](DASHBOARD.md) | Dashboard API 参考 |
|
||||
| [HEALTH-PIPELINE.md](HEALTH-PIPELINE.md) | 健康监控管线 |
|
||||
| [doc-audit-20260811.md](doc-audit-20260811.md) | **文档治理核实报告**(15 份文档对照系统实际)|
|
||||
|
||||
### 📈 策略研究(2026-08 起,小小莫维护)
|
||||
|
||||
| 文档 | 内容 |
|
||||
|------|------|
|
||||
| [strategy_research_methodology.md](strategy_research_methodology.md) | **研究方法论**:由果及因/12维预测/铁律/支撑压力规范 |
|
||||
| [predictive_oversold_strategy.md](predictive_oversold_strategy.md) | **预测超跌反弹策略**(年化14.75%达标)|
|
||||
| [research/README.md](research/README.md) | 研究总索引(过程文档+脚本+数据)|
|
||||
| [predictive_oversold_strategy.md](predictive_oversold_strategy.md) | **预测超跌反弹策略**(年化 18.57% 达标 v5)|
|
||||
| [deployment-plan-predictive-oversold.md](deployment-plan-predictive-oversold.md) | **部署计划**(策略整合 MoFin 全流程)|
|
||||
| [research/methodology.md](research/methodology.md) | 方法论总纲(含铁律0-5)|
|
||||
| [research/research-log.md](research/research-log.md) | 研究日志(08-08 ~ 08-10 完整历程)|
|
||||
| [research/research-scripts.md](research/research-scripts.md) | 研究脚本清单 |
|
||||
| [research/research-status.md](research/research-status.md) | 策略现状与待办 |
|
||||
| [research/2026-08-06-low-drawdown-study.md](research/2026-08-06-low-drawdown-study.md) | 低回撤组合策略研究 |
|
||||
| [research/2026-08-08-experience-lessons.md](research/2026-08-08-experience-lessons.md) | 研究经验教训 |
|
||||
| [research/2026-08-0*.md](research/) | 研究过程文档(57份,08-06~08-09 各策略实验)|
|
||||
|
||||
> 研究脚本见 `scripts/research/`(含 README.md 索引)
|
||||
> 研究过程文档(57 份单次实验记录)已归档至 `research/archive/`,结论已汇总进 methodology.md。
|
||||
> 研究脚本见 `scripts/research/`(含 README.md 索引)。
|
||||
|
||||
### 📦 历史文档(archive/)
|
||||
|
||||
旧的设计文档、需求文档、分析报告。仅供参考,不代表当前系统状态。
|
||||
旧的设计文档、需求文档、分析报告、已废弃组件文档。仅供参考,不代表当前系统状态。
|
||||
|
||||
---
|
||||
|
||||
@@ -60,10 +66,11 @@
|
||||
- 不直接删除旧文档,移到 `archive/` 保留
|
||||
- 交叉引用使用相对路径 `[xxx](xxx.md)`
|
||||
|
||||
## 当前系统状态
|
||||
## 当前系统状态(2026-08-11 核实)
|
||||
|
||||
- **数据**:纯 SQLite(`/home/hmo/web-dashboard/data/mofin.db`)
|
||||
- **数据**:纯 SQLite(`/home/hmo/MoFin/data/mofin.db`,47 表)。`web-dashboard` 是 MoFin 软链别名
|
||||
- **币种**:港股存 HKD,A 股存 CNY,汇总时转换
|
||||
- **JSON**:已全部移除,无残留
|
||||
- **JSON**:decisions.json / watchlist.json 已移除;**portfolio.json 仍在用**(update_data.py 写、stock_profile.py 读)
|
||||
- **服务**:`mofin-dashboard.service`(:8899,API+Dashboard 一体);无独立 mofin-api 服务
|
||||
- **测试**:`scripts/run_all_tests.py` — 33/33 通过
|
||||
- **最新**:`CHANGELOG.md` 查看完整变更
|
||||
- **最新**:`CHANGELOG.md` 查看完整变更
|
||||
@@ -0,0 +1,109 @@
|
||||
# MoFin 系统架构
|
||||
|
||||
> 最后更新:2026-07-03
|
||||
> 维护人:Sisyphus (小小莫) + Zhiwei (知微)
|
||||
|
||||
---
|
||||
|
||||
## 一、数据层
|
||||
|
||||
### 数据库
|
||||
|
||||
所有数据存储在 SQLite:`/home/hmo/web-dashboard/data/mofin.db`
|
||||
|
||||
| 表 | 用途 | 写入方 |
|
||||
|----|------|--------|
|
||||
| `holdings` | 持仓列表 | price_monitor, import_holding_xls |
|
||||
| `portfolio_summary` | 总资产/市值/仓位 | price_monitor, regenerate_all |
|
||||
| `holding_strategies` | 策略/决策 | regenerate_all, server.py API |
|
||||
| `watchlist_stocks` | 自选股 | price_monitor, regenerate_all |
|
||||
| `cash_log` | 现金变更审计 | write_cash_log |
|
||||
| `market_snapshots` | 大盘数据 | market_watch |
|
||||
| `sector_snapshots` | 板块数据 | market_watch |
|
||||
| `live_prices` | 实时价格快照 | price_monitor |
|
||||
| `mtf_cache` | 多周期K线缓存 | multi_timeframe |
|
||||
| `capital_flow_cache` | 资金流缓存 | capital_flow_collector |
|
||||
| `price_events` | 价格触发事件 | price_monitor |
|
||||
|
||||
### 数据访问
|
||||
|
||||
- **读取**:`mo_data.py` — `read_portfolio()` / `read_decisions()` / `read_watchlist()`
|
||||
- **写入**:`mofin_db.py` — `write_holdings_batch()` / `write_holding_strategy()` / `write_portfolio_summary()` 等
|
||||
|
||||
JSON 文件已全部移除(portfolio.json, decisions.json, watchlist.json 等)。
|
||||
|
||||
### 币种
|
||||
|
||||
| 品种 | 个股存储 | 汇总 |
|
||||
|------|---------|------|
|
||||
| 港股 | HKD (currency='HKD') | CNY (×汇率) |
|
||||
| A股 | CNY (currency='CNY') | CNY |
|
||||
|
||||
`calc_total_assets()` 汇总时自动将港股 HKD 转 CNY。汇率由 `hk_rate.py` 实时获取。
|
||||
|
||||
---
|
||||
|
||||
## 二、核心模块
|
||||
|
||||
```
|
||||
MoFin/
|
||||
├── mo_models.py # 统一数据模型:calc_total_assets, is_hk_stock, to_cny
|
||||
├── mo_data.py # 统一读取层:read_portfolio, read_decisions, read_watchlist
|
||||
├── mofin_db.py # DB 层:建表 + 写函数 + 查询函数
|
||||
├── mo_config.py # 配置单例
|
||||
├── price_monitor.py # 价格更新(cron: */2 9-16 1-5)
|
||||
├── strategy_lifecycle.py # 策略生命周期(regenerate_all + quality gates)
|
||||
├── server.py # Flask Web API(端口 8899)
|
||||
├── market_watch.py # 大盘采集(cron: */30 9-15)
|
||||
├── market_screener.py # 全市场筛选(cron: */30 9-15)
|
||||
├── strategy_tree.py # 策略树/分支管理
|
||||
├── strategy_evaluator.py # 策略评估
|
||||
├── hk_rate.py # 港币汇率(API + 缓存)
|
||||
├── multi_timeframe.py # 多周期K线分析
|
||||
├── stock_profile.py # 个股画像
|
||||
├── data_freshness.py # 数据新鲜度校验
|
||||
├── system_audit.py # 系统审计
|
||||
├── system_health_check.py# 系统健康检查
|
||||
├── prompt_manager/ # LLM Prompt 管理
|
||||
├── scripts/ # 工具/一次性脚本
|
||||
└── docs/ # 文档
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 三、数据流
|
||||
|
||||
```
|
||||
开盘 (9:00-16:00)
|
||||
│
|
||||
├── price_monitor (每2分钟)
|
||||
│ ├── 东财/腾讯 API → 拉价格
|
||||
│ ├── write_holdings_batch → holdings 表
|
||||
│ └── write_portfolio_summary → portfolio_summary 表
|
||||
│
|
||||
├── market_watch (每30分钟)
|
||||
│ └── write_market_snapshot → market_snapshots + sector_snapshots
|
||||
│
|
||||
├── market_screener (每30分钟)
|
||||
│ └── 读 market_snapshots → 小果 LLM 筛选 → candidate_pool
|
||||
│
|
||||
└── stale_push_wlin (每30分钟)
|
||||
└── 读持仓+决策 → 区间检测 → XMPP 推送
|
||||
|
||||
盘后
|
||||
│
|
||||
├── system_audit (17:30) → 全局审计报告
|
||||
├── strategy_review (20:00) → 策略复盘
|
||||
└── regenerate_all (手动/定时) → 全量策略重评
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 四、版本
|
||||
|
||||
| 版本 | 日期 | 关键变更 |
|
||||
|------|------|---------|
|
||||
| 5.0 | 2026-07-03 | JSON 彻底移除,纯 DB。币种修正(港股 HKD,汇总 CNY)。消除重复文件。 |
|
||||
| 4.0 | 2026-07-01 | mo_data 统一读取层,cash_log 表 |
|
||||
| 3.0 | 2026-06-30 | mo_models 统一数据模型,DSA 集成 |
|
||||
| 2.0 | 2026-06-29 | 初始架构重构 |
|
||||
@@ -0,0 +1,104 @@
|
||||
|
||||
## 2026-07-01 盘中自检:科创50跌3%HIGH信号分析
|
||||
|
||||
**事件:** 自愈执行器上报盘中宏观风险HIGH信号(科创50指数跌幅扩大至3%)
|
||||
|
||||
**原因分析:**
|
||||
- 韩国政府计划设立智库利用芯片巨头超额利润的传闻引发半导体板块恐慌
|
||||
- 三星电子一度跌超6%,SK海力士一度跌超5%,韩国KOSPI从+1.7%急跌至-4%
|
||||
- 韩国产业通商资源部已紧急辟谣,KOSPI收窄至-0.87%
|
||||
- 另一重因素:阳光电源崩跌近20%(光伏逆变器美国政策不确定性)
|
||||
|
||||
**市场状态(14:13):**
|
||||
- 上证指数 +0.39%(大盘整体稳定)
|
||||
- 科创50 -2.37%(已从-3%回升)
|
||||
- 创业板指 -1.63%
|
||||
|
||||
**持仓影响:**
|
||||
- 海博思创 -9.95%(距止损5.8%)
|
||||
- 长芯博创 -8.53%(距止损仅2.9%⚠️)
|
||||
- 中芯国际科创 -2.76%(距止损仅2.5%⚠️)
|
||||
- 中际旭创 -3.73%(距止损3.9%)
|
||||
- 均为高景气被动杀跌,按规则不动止损
|
||||
|
||||
**操作:** 已更新 macro_risk_state.json level从high降为medium,追加修正覆盖说明。无持仓操作建议。
|
||||
|
||||
**知识萃取:**
|
||||
1. 韩国芯片巨头利税分配传闻是典型的「情绪性杀跌」——传闻已被辟谣,辟谣后指数快速回升。对A股科创板的影响主要通过半导体板块联动传导。
|
||||
2. 科创50跌3%触发的HIGH信号本身是正确的——但需要结合消息面做上下文修正。这正是实时信号采集器(红绿灯)产生信号后需要LLM深度分析验证的原因。本次红绿灯正确捕捉到信号,LLM分析修正了级别。
|
||||
3. 重仓科技股在情绪杀跌日不做止损调整——这是系统性应对规则的正确应用。长芯博创距止损仅2.9%也不应在恐慌日调宽,等1-2个交易日确认趋势。
|
||||
|
||||
## 2026-07-02 全球半导体冲击:韩国熔断+美股半导体暴跌4.4%
|
||||
|
||||
**事件:** 自愈执行器上报盘中宏观风险HIGH信号(韩国KOSPI-6%触发熔断+费城半导体-4.4%+日经-2%)
|
||||
|
||||
**原因分析:**
|
||||
- Meta拟出租过剩算力(布局AI云业务)→ 市场解读为AI资本开支见顶 → 全球半导体板块抛售
|
||||
- 费城半导体指数跌4.4%(NVDA-3.2%/AMD-4.3%/ASML-4.1%/MRVL-7.7%)
|
||||
- 韩国KOSPI跌6%触发熔断(三星-7%/SK海力士-8%)+ 日经225跌2%
|
||||
- 微软6月跌20%/8个月市值蒸发1.3万亿
|
||||
- **注意:这不是传闻,Meta已确认动向** — 与7月1日韩国芯片传闻有本质区别
|
||||
|
||||
**市场状态(09:30开盘):**
|
||||
- 上证指数 -1.42%(有韧性,非全面崩溃)
|
||||
- 科创50 -4.33%(半导体重仓指数暴跌)
|
||||
- 创业板指 -2.94%
|
||||
- 深证成指 -2.41%
|
||||
|
||||
**持仓影响(A股开盘):**
|
||||
- 中际旭创(15.27%) 1160 -5.16% 距止损8%
|
||||
- 中芯国际A(5.44%) 146.5 -5.17% 距止损7%
|
||||
- 博创科技(3.2%) 241.3 -4.99% 距止损9%
|
||||
- 法拉电子(2.3%) 172.6 -5.48% 距止损4%
|
||||
- 海博思创(6.31%) 255 -3.0% 距止损8%
|
||||
- 华恒生物(5.25%) 16.0 -2.26%
|
||||
- 防御股验证:紫金矿业+2% 黄金ETF+1.86% 模塑科技+2.87%
|
||||
|
||||
**定性:** 全球半导体/AI叙事冲击(板块冲击B类,但严重程度接近系统性)
|
||||
- 区别昨天:昨天是韩国传闻辟谣后快速修复,今天是真实事件(Meta确认)+ 韩国熔断
|
||||
- A股上证仅-1.42%说明不是全面系统性下跌,资金在板块间轮动(半导体→黄金/资源)
|
||||
|
||||
**操作:**
|
||||
- 已推送给Dad XMPP报告
|
||||
- 高景气被动杀跌持仓不动止损
|
||||
- 防御股保留
|
||||
- 等待HK开市检查港股持仓
|
||||
|
||||
**知识萃取:**
|
||||
1. **传闻 vs 真实事件的应对区别:** 7月1日是传闻(韩国芯片利润传闻,辟谣后快速修复),7月2日是真实事件(Meta确认出租算力+韩国熔断)。传闻日可预期修复,真实事件需3-5日观察趋势确认。两者触发相同的「不动止损」规则,但后续跟踪周期不同。
|
||||
2. **韩国熔断的历史信号意义:** 韩国KOSPI触发熔断是极罕见事件(上一次在2020年3月新冠初期),熔断本身不代表长期趋势转折——2020年熔断后KOSPI在半年内涨超80%。熔断是流动性冲击的信号,不是基本面崩塌。
|
||||
3. **科创板-4.33%开盘但上证仅-1.42%的结构性分化验证了三维分析框架的价值:** 不看单一指数结论。科创50暴跌但上证不崩、黄金上涨、宁德时代翻红——说明是科技板块轮动式下跌而非全面系统性风险。仅看科创50会误判为系统性。
|
||||
|
||||
## 2026-07-07 标准化操作建议流程(Dad强制要求)
|
||||
|
||||
**触发:** 腾讯盘中触止盈位,我直接给出「出半仓」建议。Dad 追问后才意识到港股每手100股不能拆半手,且系统策略信号是"持有"而不是卖出。
|
||||
|
||||
**根因:** 出操作建议前跳过了两个关键步骤:
|
||||
1. 没有调 reassess_strategy() 获取系统策略判断(系统策略是持有,不是卖出)
|
||||
2. 没有检查最小交易单位(港股每手=100股,100股=1手不能拆半)
|
||||
|
||||
**修改内容:**
|
||||
1. 新建 `/home/hmo/.hermes/profiles/position-analyst/scripts/prepare_recommendation.py`
|
||||
— 标准化前置流程脚本,调 reassess_strategy() + 检查交易约束 + 输出结构化 JSON
|
||||
- 调用方式:`python3 prepare_recommendation.py {code} {price}`
|
||||
- 输出:strategy(信号/止损/止盈) + trade_constraints(市场/最小手/可拆半手) + pnl(成本/盈亏%)
|
||||
2. 更新盘前中监控 cron (62a2ba59f7ff) prompt — 加入三步标准化流程
|
||||
3. 更新午后监控 cron (23adf24922b3) prompt — 加入三步标准化流程
|
||||
|
||||
**强制规则(以后所有推荐都走):**
|
||||
三步流程:触发系统策略重评 → 检查交易约束 → 基于策略结果出推荐
|
||||
禁止凭行情直接下结论。
|
||||
|
||||
## 2026-07-08 补建prepare_recommendation.py(实际文件缺失修复)
|
||||
|
||||
**发现问题:** 午后监控(13:35)运行时发现prepare_recommendation.py实际不存在——2026-07-07知识日志记录已"新建"但system_inventory.json引用的文件路径缺失。根因: 2026-07-07 session中仅记录了计划/写入意图但文件未实际落盘。
|
||||
|
||||
**修改内容:**
|
||||
1. 实际创建 `/home/hmo/.hermes/profiles/position-analyst/scripts/prepare_recommendation.py`
|
||||
- 调用per_stock_reassess.py获取策略信号(timing_signal/action_note/止损/止盈/RR)
|
||||
- 自动识别市场(A股/港股/科创板)及最小交易单位(100/200)
|
||||
- 对持仓股计算pnl(成本/盈亏金额/盈亏比例)
|
||||
- 输出标准化JSON(strategy + trade_constraints + pnl)
|
||||
- 已验证: 688981(科创板200股)→策略信号:买入但RR1.31<1.5降级+浮盈+22.57%
|
||||
- 已验证: 01478(港股100股)→策略信号:弱势持有+浮亏-48.85%
|
||||
2. 同时生成本日午后监控报告
|
||||
@@ -0,0 +1,184 @@
|
||||
# MoFin Cron 梳理报告 —— 对照预测超跌反弹策略(p_oversold)部署
|
||||
|
||||
> 状态:📋 初稿(待老莫逐部分确认)
|
||||
> 创建:2026-08-11 | 对照策略:预测超跌反弹 v5(docs/predictive_oversold_strategy.md)
|
||||
> 依据:docs/deployment-plan-predictive-oversold.md(部署计划)+ 58 个启用 cron 实际功能核查
|
||||
> 范围:/home/hmo/.hermes/profiles/position-analyst/cron/jobs.json 启用任务 58 个 + mohe 2 个(mohe 不涉及)
|
||||
|
||||
## 〇〇、方法论对齐(2026-08-11 补充:3+6+12 视角)
|
||||
|
||||
> 依据:docs/research/2026-08-06-low-drawdown-study.md §7(老莫纠正原话)+
|
||||
> docs/research/methodology.md(总纲)+ docs/strategy_research_methodology.md(由果及因)
|
||||
|
||||
### 3+6+12 定义(权威)
|
||||
**3/6/12 = 3次重评 + 6步推导 + 12维全评**
|
||||
|
||||
| 组成 | 内容 | 落地文档 |
|
||||
|------|------|---------|
|
||||
| **3次重评** | 选股初评 → 入场重评 → 出场重评 | low-drawdown-study §7 / v_mr_strategy §19 |
|
||||
| **6步推导** | 研究流程:果→因→全市场筛→负面剔除→正负合并→稳健验证 | methodology §3.2 / learned.md L14 |
|
||||
| **12维全评** | 大盘/行业/个股 × 消息/基本/技术/资金 | methodology §3 / strategy_research_methodology §2 |
|
||||
|
||||
### cron 评估的 3+6+12 视角(核心)
|
||||
从策略组合角度,每个 cron 应支撑以下环节之一:
|
||||
|
||||
**3次重评(运行态决策)**:
|
||||
- 选股初评 → 主力建仓扫描 / p_oversold 扫描器 / 候选过滤 / 候选提拔
|
||||
- 入场重评 → 盘前全量重评(regenerate_all)/ 12维补全 / 自选自动清理
|
||||
- 出场重评 → ⚠️ **缺口**(low-drawdown-study L134:出场由 watchlist 12维 LLM 接管,非确定性规则,不可回测)→ 需补机械兜底+12维倾斜双层规则
|
||||
|
||||
**6步推导(研究态)**:
|
||||
- 数据采集(stock_daily/stock_weekly/fundamentals/capital_flow)→ 研究数据基础
|
||||
- 策略评估 / 策略复盘 / 建议对账 → 验证闭环
|
||||
|
||||
**12维全评(数据基础)**:
|
||||
- 大盘维:市场数据采集(mkt_rsi/mkt_dd60)、宏观上下文、宏观新闻
|
||||
- 行业维:行业富集-cninfo、市场数据采集(板块)
|
||||
- 个股维:基本面刷新、资金流采集、多周期缓存、价格监控
|
||||
- 消息维:宏观新闻采集、知微洞察
|
||||
|
||||
### 由此得出的 cron 评估原则
|
||||
1. **支撑 3+6+12 任一环节的 cron = 保留**(数据管道是策略的生命线)
|
||||
2. **与 3+6+12 无关的 cron = 候选停**(如纯运维/重复/停摆)
|
||||
3. **3次重评有缺口的环节 = 需新增/调整**(尤其出场重评)
|
||||
4. **6步推导第6步"稳健验证"依赖数据完整性** → 数据采集类 cron 绝不能停
|
||||
|
||||
|
||||
## 〇、分析框架
|
||||
|
||||
新策略 p_oversold 的核心需求:
|
||||
1. 扫描器写入 candidates(sector=p_oversold)→ 需调度
|
||||
2. 候选评估:p_oversold 有自己的选股条件,**不适配 accumulation 的 6阶段评分 + RR>=2 门槛**
|
||||
3. 盘前重评(regenerate_all)需覆盖新策略候选
|
||||
4. 健康监控/简报需体现新策略
|
||||
|
||||
基于此,58 个 cron 分四类:停 / 保持 / 调整 / 新增。
|
||||
|
||||
---
|
||||
|
||||
## 一、可以直接停止的(8 个)
|
||||
|
||||
依据:与新策略无关 + 功能冗余/过时 + 持续失败无价值
|
||||
|
||||
| # | cron | 调度 | 脚本 | 为什么停 |
|
||||
|---|------|------|------|---------|
|
||||
| 1 | 策略评估-每日 | 0 21 * * 1-5 | stale_detector.py | ❌ error 8/6 起(Connection error)。与策略评估-每周重复,每日版是早期半成品 |
|
||||
| 2 | 市场精选推荐-每日 | 0 16 * * 1-5 | prompt型(无script) | ❌ 7/31 起停摆(部署计划 §11.2 明确)。与新策略无关——新策略有专属扫描器,不需要通用精选 |
|
||||
| 3 | 跨市场背离检测-周末 | 30 8-16/2 * * 0,6 | divergence_detector.py | 与跨市场背离检测(*/30 8-15 工作日)完全同脚本,周末单独重复 |
|
||||
| 4 | 宏观风险扫描-午间 | 30 11 * * 1-5 | prompt型 | 与宏观风险扫描(8:30)重复度 80%,午间版冗余 |
|
||||
| 5 | 宏观风险扫描-周末 | 0 10 * * 0,6 | prompt型 | 与宏观风险扫描(8:30)同脚本,周末重复 |
|
||||
| 6 | 行业富集-cninfo-午间 | 45 12 * * 1-5 | sector_enrich_cninfo.py | 与行业富集-早间(7:50)同脚本。早间已覆盖全部 active 策略,cninfo 一天一次就够 |
|
||||
| 7 | 基本面刷新-午间 | 47 12 * * 1-5 | fundamentals_refresh.py | 同脚本早晚各一次。基本面(PE/PB)一天变一次,午间版冗余 |
|
||||
| 8 | 自选12维分析补全-每日午间 | 30 12 * * 1-5 | watchlist_12d_backfill.py | ⚠️ 待定:调度注释说"约80分钟",与午间其他任务重叠;若 p_oversold 有自己的评估,此任务价值下降 |
|
||||
|
||||
> ⚠️ 注:#8 自选12维补全是否停,需确认它与 p_oversold 专属评估是否冲突——若 p_oversold 走独立评估,此通用 12 维补全可降频或停。
|
||||
|
||||
---
|
||||
|
||||
## 二、必须保持不动(30 个)
|
||||
|
||||
依据:系统核心运转依赖,与新策略无冲突。
|
||||
|
||||
### 2.1 候选管道核心(5 个)——p_oversold 依赖它们
|
||||
|
||||
| cron | 调度 | 保持理由 |
|
||||
|------|------|---------|
|
||||
| 主力建仓扫描-每15分 | */10 9-15 | accumulation 扫描器——保留,新策略加独立扫描器不冲突 |
|
||||
| 候选股过滤管道-每30分 | */30 9-15 | 保留(但见第三类"调整":RR/评分适配问题)|
|
||||
| 候选股自动提拔-每30分 | */30 9-15 | 保留(但见第三类"调整")|
|
||||
| 盘前全量重评-自选退出 | 10 8 * * 1-5 | 保留(2026-08-11 已修缓存预热 7:50)——p_oversold 候选进 holding_strategies 后自动被重评 |
|
||||
| 自选自动清理-开盘前 | 5 9 * * 1-5 | 保留——管道收尾 |
|
||||
|
||||
### 2.2 数据基础(5 个)
|
||||
|
||||
| cron | 调度 | 保持理由 |
|
||||
|------|------|---------|
|
||||
| 价格监控-高频 | */2 9-16 | 实时价格唯一入口,p_oversold 也需要 |
|
||||
| 市场数据采集 | */10 9-11,13-15 | 大盘/板块数据,p_oversold 门控依赖(mkt_rsi/mkt_dd60)|
|
||||
| 资金流采集-盘中 | 1,31 9-15 | 2026-08-11 已修(DELETE全表→单行upsert),p_oversold 可用资金流验证 |
|
||||
| 多周期缓存刷新-盘中 | 50 7,11,14 | 2026-08-11 已修(补flush + 提前7:50)——**p_oversold 重评依赖它的缓存** |
|
||||
| 数据采集-策略评估前 | 30 20 * * 1-5 | 策略评估数据源 |
|
||||
|
||||
### 2.3 LLM 分析/报告(5 个)
|
||||
|
||||
| cron | 调度 | 保持理由 |
|
||||
|------|------|---------|
|
||||
| 策略复盘-每日 | 0 20 * * 1-5 | 每日策略复盘,含新策略后自动覆盖 |
|
||||
| 分析师-持仓复查 | 0 20 * * 4 | 周四持仓复查 |
|
||||
| 开盘简报 | 35 9 * * 1-5 | 每日简报(部署计划 §五要求简报提及新策略)|
|
||||
| 收盘简报 | 10 16 * * 1-5 | 每日简报 |
|
||||
| 知微洞察生成 | 35 15 * * 1-5 | 知微日报(部署计划 §五要求交接)|
|
||||
|
||||
### 2.4 宏观/风险(4 个)
|
||||
|
||||
| cron | 调度 | 保持理由 |
|
||||
|------|------|---------|
|
||||
| 宏观新闻采集 | */30 8-16 | 数据源 |
|
||||
| 宏观风险信号消费 | 5,20,35,50 9-15 | 消费信号 |
|
||||
| 宏观上下文刷新-每30分 | */30 9-15 | p_oversold 门控用 macro_bias |
|
||||
| 跨市场背离检测(工作日)| */30 8-15 | 保留(停周末版)|
|
||||
|
||||
### 2.5 系统维护/自愈(11 个)——绝不能停
|
||||
|
||||
| cron | 调度 | 保持理由 |
|
||||
|------|------|---------|
|
||||
| Gateway看门狗-知微 | every 10m | 系统自愈 |
|
||||
| 部署一致性守卫 | */15 | 防代码漂移 |
|
||||
| 元监控-自检系统的自检-L4 | 5 * * * * | 防螺旋 |
|
||||
| agent螺旋监控 | */10 | 防螺旋(2026-07-21 事件后补)|
|
||||
| 自愈执行器-TODO自动处理-v2 | */10 8-22 | 自动修复 |
|
||||
| LLM修复循环-L3 | */30 9-16,20-22 | 自动修复 |
|
||||
| 功能健康检查-L1 | */15 9-16,20-22 | 监控 |
|
||||
| 健康监控数据采集-每15分 | */15 9-16,20-22 | 监控(但见第三类调整:注册 p_oversold 项)|
|
||||
| 系统卫生审计-每日 | 20 8 * * * | 维护 |
|
||||
| 系统全局审计 | 30 17 * * 1-5 | 维护 |
|
||||
| DB每日备份-0750 | 50 7 * * * | 数据安全 |
|
||||
| state.db真空整理-每周 | 0 3 * * 6 | 维护 |
|
||||
| cron报告推XMPP-每5分 | */5 9-16 | 报告分发 |
|
||||
| 记忆守卫-每日 | 0 7 * * * | 记忆管理 |
|
||||
|
||||
> 注:2.5 实际 14 个(标题写 11,含全),保持不动。
|
||||
|
||||
---
|
||||
|
||||
## 三、需要调整的(8 个)
|
||||
|
||||
| # | cron | 当前问题 | 调整方案 |
|
||||
|---|------|---------|---------|
|
||||
| 1 | 候选股过滤管道 | 6阶段评分为 accumulation 设计(量价放大/中低位),p_oversold 候选(深跌+低估值)评分不适配 | **方案A(推荐)**:p_oversold 候选写 candidates 时直接标记高分+pass_final=1,绕过 candidate_filter;或让 candidate_filter 按 sector 分流 |
|
||||
| 2 | 候选股自动提拔 | **RR>=2.0 硬门槛**(promote_candidates.py:130)——超跌候选 RR 天然 <2(部署计划 §8.2 实测 40+/57 被拒)| 加 sector 判断:p_oversold 候选跳过 RR>=2 门槛(用专属评估替代)|
|
||||
| 3 | 主力建仓扫描 | 只扫 accumulation | 保持——新增 p_oversold 独立扫描器 |
|
||||
| 4 | 健康监控数据采集 | 无 p_oversold 项 | 注册 p_oversold 健康检查项(部署计划 §五)|
|
||||
| 5 | 开盘简报 | 模板无新策略 | 模板提及新策略 |
|
||||
| 6 | 知微洞察生成 | 未交接新策略 | 简报模板 + 策略文档 |
|
||||
| 7 | 开盘前钉对钉 | ✅ 2026-08-11 已修(registry 路径,18/18 通过)| 保持,未来加 p_oversold 检查项 |
|
||||
| 8 | MoFin 系统常规体检-开盘前 | 清单自动扩展 | 加 p_oversold 健康项 |
|
||||
|
||||
---
|
||||
|
||||
## 四、需要新增的(2 个)
|
||||
|
||||
| 新 cron | 说明 |
|
||||
|---------|------|
|
||||
| predictive_oversold_scanner | p_oversold 扫描器(腾讯行情源 + 大盘门控 + 写 candidates sector=p_oversold + 当日幂等 + 单例守卫 + 600s 护栏)。**调度方式待老莫定**:独立 cron vs market_watch 链式 |
|
||||
| p_oversold 专属评估 | 按选股逻辑评估(不复用 accumulation 的 RR>=2)——可并入 scanner 或独立 |
|
||||
|
||||
---
|
||||
|
||||
## 五、汇总
|
||||
|
||||
| 类别 | 数量 | 说明 |
|
||||
|------|------|------|
|
||||
| 🛑 停 | 8 | 策略评估-每日、市场精选、跨市场背离-周末、宏观风险×2(午间/周末)、行业富集-午间、基本面-午间、自选12维补全(待定) |
|
||||
| ✅ 保持 | 30 | 系统核心 + 数据基础 + 监控自愈 |
|
||||
| 🔧 调整 | 8 | 候选管道×3(RR/评分适配)、健康监控/简报/体检×5(注册新策略)|
|
||||
| ➕ 新增 | 2 | p_oversold 扫描器 + 专属评估 |
|
||||
| ⚠️ 观察 | 3 | 策略评估-每日(停)、LLM修复循环、候选股过滤(已修,观察恢复)|
|
||||
|
||||
---
|
||||
|
||||
## 六、待老莫拍板
|
||||
|
||||
1. **停 8 个确认吗?**(尤其"市场精选推荐"——7/31 停摆,是否彻底废弃?)
|
||||
2. **候选管道适配**:方案A(p_oversold 绕过 filter 直接标记高分)还是方案B(改管道门槛)?
|
||||
3. **p_oversold 扫描器调度**:独立 cron 还是 market_watch 链式?
|
||||
@@ -0,0 +1,53 @@
|
||||
# MoFin 文档治理核实报告(对照系统实际)
|
||||
|
||||
> 状态:✅ 已核实(2026-08-11,实测 246 服务器)
|
||||
> 范围:15 份"系统实现相关"文档 vs MoFin 实际状态(DB 47表 / crontab / systemd / 进程 / API)
|
||||
> 方法:数据库 sqlite_master 实查、crontab 实查、systemd 实查、端口/进程实查、API 实测、脚本文件存在性核查
|
||||
|
||||
## 一、核实总表
|
||||
|
||||
| # | 文档 | 结论 | 一句话 |
|
||||
|---|------|------|--------|
|
||||
| 1 | 根目录 SYSTEM_ARCHITECTURE.md | 过时 | 表/模块/DB路径仍准,但 4 个 cron 已停、regenerate_all 已改名、"JSON 全移除"错误 |
|
||||
| 2 | docs/SYSTEM_ARCHITECTURE.md | 过时+放错目录 | 讲的是 Hermes/XMPP 系统,非 MoFin;端口/PID/bot路径全对不上 |
|
||||
| 3 | docs/portfolio-data-model.md | 基本一致 | 9 张表全存在、公式/币种正确;唯一错:portfolio.json 仍在用 |
|
||||
| 4 | docs/decisions-db-migration.md | 过时(历史文档) | 完成声明属实,但正文 strategies 表从未建成(实际 holding_strategies)|
|
||||
| 5 | docs/QUICKSTART.md | 大体有效(2处硬错) | mofin-api 服务不存在、dashboard.log 路径不存在 |
|
||||
| 6 | docs/DASHBOARD.md | 基本一致 | 全部端点 200、monitor 状态逐字吻合;示例服务数 5 vs 实际 4 |
|
||||
| 7 | docs/HEALTH-PIPELINE.md | 基本一致 | Tier1 精确到源码;仅 Tier2 "规划中"过时(已部署)|
|
||||
| 8 | docs/xiaoguo-signal-pipeline.md | 已废弃 | 小果 7/9 停跑、7/20 归档,无 cron |
|
||||
| 9 | docs/xiaoguo-scanner-design.md | 已废弃 | 同上 |
|
||||
| 10 | docs/market-screening-pipeline.md | 过时 | 描述的 17 信号管道已停摆,被 accumulation→candidate 取代 |
|
||||
| 11 | docs/lifecycle-management.md | 部分过时 | 框架有效、已落地;JSON 中心说法过时、xiaoguo 缺口失效 |
|
||||
| 12 | docs/morning-health-check.md | 机制有效、细节过期 | 8:00 运行 ✓;但 48 项→40 项、存储改 DB 表 |
|
||||
| 13 | docs/strategy-review-loop.md | 基本一致(已实施) | 闭环全落地,accuracy_stats 已闭环 |
|
||||
| 14 | docs/SELF_GROWTH_SYSTEM.md | 部分过时 | 三件套都在跑;cron 表/xiaoguo 章节过期 |
|
||||
| 15 | docs/TDX_RELAY_COLLAB.md | 已废弃 | TDX relay 7/20 归档,集成逻辑已移除 |
|
||||
|
||||
## 二、处置建议
|
||||
|
||||
| 处置 | 文档 |
|
||||
|------|------|
|
||||
| 归档(7份) | 根 SYSTEM_ARCHITECTURE、docs/SYSTEM_ARCHITECTURE、decisions-db-migration、xiaoguo×2、TDX_RELAY_COLLAB、market-screening-pipeline |
|
||||
| 保留+更新(6份) | portfolio-data-model、QUICKSTART、DASHBOARD、HEALTH-PIPELINE、morning-health-check、lifecycle-management、SELF_GROWTH_SYSTEM |
|
||||
| 保留(1份) | strategy-review-loop(标注已实施)|
|
||||
|
||||
## 三、关键横切发现
|
||||
|
||||
1. **数据库唯一**:data/mofin.db(6.4GB,47表);根目录 market.db/market_data.db/stock_analysis.db/state.db 全是 0 字节占位
|
||||
2. **web-dashboard 是软链** → MoFin(6-20 创建),非两套部署
|
||||
3. **JSON 真实现状**:decisions.json/watchlist.json 已删;**portfolio.json 仍活着**(update_data.py 写、stock_profile.py 读)
|
||||
4. **调度真实现状**:crontab 39 条;market_screener/system_audit/stale_push_wlin/strategy_review 均未在系统 cron(在 hermes jobs.json)
|
||||
5. **服务真实现状**:只有 mofin-dashboard.service(= server.py :8899,API+Dashboard 一体);无 mofin-api.service
|
||||
6. **已暂停 5 个 job(2026-08-10 22:43-44)**:全部合理,无需恢复
|
||||
- 系统健康检查:被 morning_health_check(8:00 更全面)替代
|
||||
- 小果市场筛选:小果已废弃
|
||||
- 300308 盯盘×2:临时任务结束
|
||||
- 自选买入区提醒(per_stock_reassess):由 watchlist_12d_backfill 承接
|
||||
|
||||
## 四、待清理项(独立治理 TODO)
|
||||
|
||||
- [ ] 小果残留文件:MoFin 顶层 3 个(xiaoguo_scanner.py / xiaoguo_news_processor.py / inject_xiaoguo_insight.py)+ 运行时目录 4 个
|
||||
- [ ] server.py /api/update/realtime 死端点(TDX 归档后残留)
|
||||
- [ ] mofin_db.py / mofin_health.py / system_audit.py 中 xiaoguo 字符串(无害遗留,system_audit 统计恒为 0)
|
||||
- [ ] candidate_filter / refresh_mtf_cache 近期 database is locked(2026-08-11 已修资金流长锁,观察)
|
||||
Reference in New Issue
Block a user