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 原型服务。 - 反向代理：优先复用现有 Caddy 或 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 部署时应用容器使用 `docker-compose.yml` 管理并开启自动重启，反向代理可复用服务器现有 Caddy/Nginx。 - 非 Docker 部署时可继续使用 systemd 托管应用进程，开启自动重启。 - 日志写文件并保留最近 7-14 天。 ## 11. 推荐实施顺序 ### 第一步 - 在现有项目内加入 Web 服务骨架 - 能通过域名或 Docker 反向代理打开首页和规则页 ### 第二步 - 接入 SQLite - 落地筛股/买入/卖出结果表 ### 第三步 - 接入规则引擎 - 支持手动运行一次任务 ### 第四步 - 增加每日定时任务 - 首页显示最新结果 ## 12. 我对 V1 的建议结论 - V1 不要追求实时和复杂回测。 - V1 先做成“收盘后自动刷新 + 网页查看 + 人工复核”的规则辅助系统。 - 只要这个流程跑顺，后面再做盘中提醒、更多数据源、回测和策略迭代，都会容易很多。 ## 13. 郑国成版小核心状态机草案 这一节不是新增一套复杂打分系统，而是给当前原型补一层“投资理念 -> 可量化判断 -> 股池迁移”的桥。 核心原则只有两条： - 主状态机只保留少数硬骨架，不让所有解释变量都变成硬闸门。 - 熟悉度、认知深度、主线偏好、人工理解等变量优先进入诊断层和复核层，而不是全部进入买卖状态本身。 ### 13.1 从理念到状态机的四层结构 第一层：理念层 - 主线优先，不做杂乱题材收集。 - 位置重要，强调低位、回补、二波、前高附近等可出手区间。 - 熟悉标的优先，研究不充分不贸然下结论。 - 有催化和阶段共振时加分，没有共振时宁可等待。 - 退潮、过热、兑现、题材结束时要明确降级或退出。 第二层：核心判断轴 - 主线与方向：是不是长期需求主题、阶段主线或季节轮动方向。 - 位置与结构：是不是处在低位、回补位、起涨点、二波确认位、前高附近。 - 催化与阶段：政策、事件、节日、热点、窗口期是否在强化逻辑。 - 赔率与弹性：空间是否足够，是否还有“股价未充分反应”的条件。 - 风险与退潮：是否出现短线转弱、题材生命周期结束、阶段窗口结束、过热兑现。 第三层：主状态机 - 前台观察：已经接近可行动，但仍需盯触发条件，不等于直接重仓。 - 正式候场：逻辑成立、赔率仍在，但还没有进入前台观察。 - 跟踪候场：方向可留意，但尚未达到正式候场质量。 - 研究补缺：逻辑可能成立，但材料、熟悉度或证据链不足。 - 回避：出现明确硬伤，不进入候选。 - 卖出/减仓：已经进入兑现、退潮、转弱或风险释放阶段。 第四层：迁移层 - 正式候场 -> 前台观察：主线、位置、结构、催化同时对齐，且没有硬阻断。 - 跟踪候场 -> 正式候场：方向成立且赔率改善，但还未进入前台。 - 任意状态 -> 研究补缺：证据不足、理解不足、需要补材料。 - 任意状态 -> 回避：出现过热、退潮、题材结束、硬风险等一票否决条件。 - 前台观察 -> 卖出/减仓：从“等待确认”切换到“兑现/离场/降权”。 ### 13.2 哪些进入硬闸门，哪些只留在诊断层 建议进入硬闸门的只有 4 类： - 主线是否成立 - 位置与结构是否合适 - 赔率是否还在 - 风险/退潮/过热是否已触发否决 建议只留在诊断层和复核层的变量： - 熟悉标的程度 - 对公司或题材的认知深度 - 是否属于个人偏好主线 - 研究材料是否完整 - 人工备注、例外条件、特殊经验判断 也就是说，诊断层是用来解释“为什么保留/为什么等待/为什么不前移”，不是用来无限增加硬门槛。 ### 13.2.1 当前 V1 规则的边界划分 建议按下面的口径先落地： - 硬闸门：趋势对齐过滤、季节轮动方向过滤、趋势确认后买入关注、起涨点/二波结构买点、短线转弱离场提示、阶段收益兑现提示、题材生命周期结束提示。 - 诊断层：长期需求主题优先、阶段性重点人工覆核、熟悉标的回补提示、阶段主线共振加分、阶段窗口结束降权。 这里的意思不是说诊断层不重要，而是： - 硬闸门负责决定“能不能迁移、该不该降级、是否必须退出”。 - 诊断层负责解释“为什么保留、为什么继续看、为什么优先级上调或下调”。 第一版执行上，宁可少一些硬闸门，也不要把熟悉度、偏好、研究深度、阶段共振这类变量一次性都塞进状态迁移条件里。 ### 13.3 对当前三张页面的映射建议 - 筛股页：主要承接“正式候场 + 跟踪候场 + 研究补缺”。 - 买入页：主要承接“前台观察”，重点展示升级条件和触发原因。 - 卖出页：主要承接“卖出/减仓 + 回避”，重点展示退潮、兑现、转弱理由。 当前系统仍保留“候选记录池”逻辑，因此 V1 不强制先聚合成唯一股票池；但每条记录都应该补齐所属层级与迁移原因。 ### 13.4 建议新增的最小字段 - `pool_layer`：前台观察 / 正式候场 / 跟踪候场 / 研究补缺 / 回避 / 卖出减仓 - `state_reason`：当前状态的主因说明 - `promotion_trigger`：如果要上移一层，还差什么条件 - `hard_blocker`：阻断前移的一票否决原因 - `diagnostic_tags`：熟悉标的、主线方向、阶段窗口、人工经验标签 - `review_priority`：人工复核优先级 ### 13.5 第一版落地建议 - 先不改成复杂分数系统，先把状态机和字段补齐。 - 先让规则引擎输出状态层级、迁移条件和阻断原因。 - 先让首页和三张信号页显示“为什么在这里、下一步往哪里迁移”。 - 当前统一规则表已外置为独立配置文件，后续优先改规则配置，不优先继续堆叠引擎分支判断。 - 等状态机稳定后，再考虑是否需要把部分判断进一步量化成分数。 ### 13.6 这份草案的实际意义 它的目的不是把郑国成体系硬拧成一套重因子量化策略，而是： - 保留郑国成方法里“主线、结构、催化、熟悉标的、退潮退出”这些核心思想。 - 把这些思想压缩成一个可执行、可解释、可迁移的轻量状态机。 - 为后续的股池架构、前台观察、人工复核和迁移监控提供统一骨架。