prototype-design.md
/app/prototype-design.md
# 郑国成规则辅助型系统 V1 原型设计 ## 1. 目标定位 - 目标形态：部署到腾讯云服务器，通过域名直接访问。 - 核心能力：只做筛股、买入提示、卖出提示，不做自动下单，不做持仓打分。 - 策略定位：基于现有规则表，构建“硬规则量化 + 软规则标签 + 例外条件人工复核”的半量化系统。 ## 2. V1 范围 ### 2.1 做什么 - 每日收盘后生成候选股列表。 - 根据买入提示规则生成可关注买点列表。 - 根据卖出提示规则生成风险提示列表。 - 在网页上展示规则、信号、日志和人工复核结果。 - 支持通过域名访问，支持基础账号登录。 ### 2.2 不做什么 - 不做自动交易。 - 不做券商接口接入。 - 不做盘中高频信号。 - 不做多用户协作。 - 不做复杂回测系统。 ## 3. 推荐技术路线 ### 3.1 部署架构 - 服务器：腾讯云 CVM，Linux。 - 访问方式：域名 -> Nginx -> Python Web 服务。 - 部署形态：支持宿主机直接部署，也支持 Docker / Docker Compose 部署。 - Web 服务：FastAPI。 - 容器编排：V1 推荐 Docker Compose，单机部署更直接。 - 进程管理：如果不用 Docker，则使用 systemd。 - HTTPS：Nginx + Let's Encrypt。 ### 3.3 Docker 部署建议 - 应用容器：运行 FastAPI 原型服务。 - Nginx 容器：负责域名访问和反向代理。 - 数据卷：挂载 SQLite 文件与后续导出的日志目录。 - 腾讯云上线时，可先放通 80/443，对外只暴露 Nginx 容器。 ### 3.2 应用结构 - Web 层：展示页面、规则表、信号结果、人工复核入口。 - 规则引擎层：按筛股/买入/卖出三张规则表计算信号。 - 数据适配层：负责行情、行业标签、概念标签、基础财务字段读取。 - 任务调度层：每日定时跑筛股与信号计算。 - 存储层：V1 建议 SQLite，后续再迁移 MySQL/PostgreSQL。 ## 4. V1 页面设计 ### 4.1 首页仪表盘 - 今日候选股数量 - 今日买入提示数量 - 今日卖出提示数量 - 最近一次任务执行时间 - 最近一次任务状态 ### 4.2 筛股页面 - 展示进入候选池的股票 - 显示命中的筛股规则 - 显示软规则标签 - 显示是否需要人工复核 ### 4.3 买入提示页面 - 展示股票、命中规则、触发时间、触发条件 - 显示是否为硬规则、软规则加分或例外条件 - 支持人工标记“已复核/忽略/关注” ### 4.4 卖出提示页面 - 展示股票、风险类型、触发条件、建议动作 - 支持人工标记“已复核/忽略” ### 4.5 规则配置页面 - 展示三张规则表 - 展示每条规则的优先级、执行级别、冲突处理、最小字段 - V1 先只读展示，不开放网页修改 ### 4.6 任务与日志页面 - 展示每日任务执行记录 - 展示失败日志 - 支持手动触发一次全量刷新 ## 5. V1 数据流设计 ### 5.1 每日批处理流程 1. 拉取 A 股股票池与基础行情数据 2. 生成筛股候选池 3. 在候选池上运行买入提示规则 4. 对观察池运行卖出提示规则 5. 写入数据库 6. 更新网页展示 ### 5.2 运行频率建议 - V1 先做日频，不做盘中实时推送。 - 每个交易日收盘后跑一次。 - 如需盘中能力，放到 V2。 ## 6. 规则引擎设计 ### 6.1 筛股层 - 输入：A 股全市场股票池 - 输出：候选股列表 - 主要规则： - 长期需求主题优先 - 趋势对齐过滤 - 季节轮动方向过滤 - 阶段性重点人工复核 ### 6.2 买入提示层 - 输入：候选股列表 - 输出：买入关注提示 - 主要规则： - 趋势确认后买入关注 - 起涨点/二波结构买点 - 熟悉标的回补提示 - 阶段主线共振加分 ### 6.3 卖出提示层 - 输入：观察池或人工关注池 - 输出：卖出风险提示 - 主要规则： - 短线转弱离场提示 - 阶段收益兑现提示 - 题材生命周期结束提示 - 阶段窗口结束降权 ## 7. 数据字段最小集合 ### 7.1 行情数据 - 股票代码 - 股票名称 - 交易日期 - 开高低收 - 成交量 - 成交额 - 换手率 ### 7.2 技术指标 - MA5 / MA10 / MA20 / MA60 - MACD DIF / DEA / Histogram - 阶段高点 / 阶段低点 - 启动位 / 前高位 ### 7.3 主题与标签 - 行业标签 - 概念标签 - 是否属于季节轮动方向 - 是否属于长期需求主题 ### 7.4 事件与人工标签 - 当前阶段重点方向 - 是否进入人工复核池 - 是否属于熟悉标的 ## 8. V1 API 设计 ### 8.1 页面接口 - `GET /` - `GET /screening` - `GET /signals/buy` - `GET /signals/sell` - `GET /rules` - `GET /jobs` ### 8.2 数据接口 - `GET /api/screening/latest` - `GET /api/signals/buy/latest` - `GET /api/signals/sell/latest` - `POST /api/jobs/run` - `POST /api/review/mark` ## 9. 数据库存储建议 ### 9.1 主要表 - `stocks` - `daily_bars` - `screening_results` - `buy_signals` - `sell_signals` - `manual_reviews` - `job_runs` ### 9.2 V1 存储建议 - 本地 SQLite 文件即可。 - 等到需要多用户或更高并发，再迁移到 MySQL/PostgreSQL。 ## 10. 安全与运维建议 - V1 增加基础登录，不裸露所有接口。 - 后台管理接口只允许登录后访问。 - 域名只暴露 Nginx 80/443，应用服务走 Docker 内部网络或本地回环。 - Docker 部署时应用容器和 Nginx 容器使用 `docker-compose.yml` 管理并开启自动重启。 - 非 Docker 部署时可继续使用 systemd 托管应用进程，开启自动重启。 - 日志写文件并保留最近 7-14 天。 ## 11. 推荐实施顺序 ### 第一步 - 在现有项目内加入 Web 服务骨架 - 能通过域名或 Docker 反向代理打开首页和规则页 ### 第二步 - 接入 SQLite - 落地筛股/买入/卖出结果表 ### 第三步 - 接入规则引擎 - 支持手动运行一次任务 ### 第四步 - 增加每日定时任务 - 首页显示最新结果 ## 12. 我对 V1 的建议结论 - V1 不要追求实时和复杂回测。 - V1 先做成“收盘后自动刷新 + 网页查看 + 人工复核”的规则辅助系统。 - 只要这个流程跑顺，后面再做盘中提醒、更多数据源、回测和策略迭代，都会容易很多。