---
title: 原后端业务地图
doc_type: business-map
domain: business
keywords:
  - 原后端业务
  - 业务地图
  - 研究链路
  - 公告研究
summary: 用当前仓库的页面、表和模块重建原后端继承下来的业务地图。
when_to_read:
  - 想确认项目继承了哪些稳定业务语义
  - 需要把页面和表结构放回业务图里
read_next:
  - ./context.md
  - ./notice-llm-analysis-design.md
---
# 原后端业务地图

这篇文档只回答一件事：当前 Tauri 仓库继承下来的“原后端业务”，本质上到底在服务什么。

这里不按代码目录讲，也不按技术组件讲，而是把对照仓库里已经稳定的业务语义，结合当前仓库已经落地的页面、表结构和 Rust 模块，重新整理成一张在本项目里可以直接使用的业务图。

## 一句话先记住

这个产品本质上不是单纯的行情查看器，而是一个围绕“证券公告研究”和“个股研判”运转的本地研究工作台。它负责拉数据、留原文、做分析、生成报告、安排任务，并把这些结果沉淀成可回看、可追踪的研究资产。

## 这次分析依据什么

| 依据 | 用来判断什么 |
| --- | --- |
| 对照仓库里已经整理好的原后端业务文档 | 用来还原长期稳定的业务语义和业务闭环 |
| 当前仓库 `src-tauri/sql/desktop_schema.sql` 中的 `notice_record`、`llm_request_log`、`sys_scheduled_task`、`tsk_run` 等表 | 用来确认哪些业务对象已经在 Tauri 仓库真实落地 |
| 当前仓库 `notice_pipeline.rs`、`notice_ai.rs`、`scheduler.rs`、`notice_original_read_model.rs` | 用来确认同步、过滤、分析、报告和原文回溯到底怎么执行 |
| 当前仓库 `src/renderer/src/router/index.ts` 中的业务入口 | 用来确认这些业务最后服务给用户的研究动作是什么 |

## 一张业务架构图

```mermaid
flowchart LR
    Source["外部来源<br/>CNInfo / Tushare / AkShare / iFind / 初始化包"] --> Sync["同步与导入"]
    Sync --> Snapshot["本地快照和标准化数据"]
    Snapshot --> Market["证券主数据 / 行情 / 指标 / 交易日历"]
    Snapshot --> Notice["公告记录 / 原文元数据 / 分析状态"]
    Market --> Watch["当日看盘"]
    Market --> Stock["个股详情 / 行情页"]
    Notice --> Watch
    Notice --> Analysis["公告分析"]
    Notice --> Original["公告原文"]
    Analysis --> Report["深度报告"]
    Analysis --> Task["补分析 / 调度任务 / 失败重试"]
    Report --> Output["本地研究产物 / 日志 / 回看结果"]
    Task --> Output
    Original --> Output
```

这张图说明两件事：

- 这个产品的中心不是“接口调用”，而是“研究对象、研究过程和研究产物”
- 公告、个股、原文、报告、任务和日志不是孤立页面，而是一条研究链路上的不同环节

## 当前仓库里的主要业务模块

| 业务模块 | 白话解释 | 当前仓库落点 |
| --- | --- | --- |
| 证券主数据与行情 | 管理股票基本信息、交易日历、provider 自持日线、快照和技术指标 | `stock_basic_info`、`stock_trade_calendar`、`api_tushare_*`、`api_akshare_price_daily`、`stock_indicator_*`、`market_sync_service.rs` |
| 公告采集与原文留存 | 从 CNInfo 拉公告，把主记录、原始快照和来源链接落到本地 | `notice_sync.rs`、`notice_record`、`api_cninfo_notice_raw`、`art_artifact` |
| 公告筛选与状态流转 | 把不同公告压成可处理工作队列，并标记过滤、处理和失败状态 | `stock_filter.rs`、`notice_status.rs`、`notice_record.filter_status`、`notice_record.status` |
| 公告 AI 分析 | 为公告补评分、结论、方向和失败原因 | `notice_ai.rs`、`notice_record.ai_analysis`、`score_*`、`beneficial_direction` |
| 深度报告 | 围绕重点公告生成更完整的研究输出 | `generate_deep_report`、`notice_record.deep_report`、`notice_record.deep_report_status` |
| 任务调度与运行时 | 让同步、补分析和重试按规则执行，并记录运行轨迹 | `scheduler.rs`、`task_runtime.rs`、`sys_scheduled_task`、`sys_scheduled_task_log`、`tsk_run`、`tsk_run_event` |
| 运维审计与恢复 | 记录 LLM 调用、操作日志、失败操作和系统配置，方便追踪和恢复 | `llm_request_log`、`sys_operation_log`、`sys_failed_operation`、`sys_config` |

## 关键业务对象

为了让当前仓库可以直接复用，下表统一使用这个仓库已经存在的对象名，而不是沿用旧系统里分散的历史命名。

| 当前对象 | 更容易懂的解释 | 在业务里扮演什么角色 |
| --- | --- | --- |
| `stock_basic_info` | 股票主档 | 是当日看盘、个股详情和公告关联的主对象 |
| `stock_trade_calendar` | 交易日历 | 用来解释交易日、空态和补数窗口 |
| `api_tushare_*` / `api_akshare_price_daily` / `stock_market_snapshot` / `today_watch_quote_snapshot` | 行情数据集 | provider 自持日线事实通过统一查询层提供价格、量能和行情上下文；其中 `today_watch_quote_snapshot` 只服务当日看盘今日查询 |
| `notice_record` | 公告分析结果集 | 是公告分析、当日看盘、解析详情和深度报告的核心数据源 |
| `api_cninfo_notice_raw` | 公告原始来源元数据 | 负责把 `notice_id` 连接到 API 原始链接值、分类和原始快照 |
| `art_artifact` | 本地产物登记 | 记录原文快照、报告和其它制品的位置与状态 |
| `llm_request_log` | AI 调用日志 | 记录一次模型调用做了什么、结果怎样 |
| `sys_scheduled_task` | 定时任务配置 | 决定同步、补分析和后台维护任务何时自动执行 |
| `tsk_run` / `tsk_run_event` | 任务运行轨迹 | 记录一次任务从派发到完成经历了什么 |
| `sys_failed_operation` | 失败操作队列 | 记录需要后续重试或人工处理的失败动作 |

## 原后端真正服务的业务动作

### 1. 先把“可研究的数据”准备出来

- 拉取公告、交易日历、股票主数据和行情快照
- 把第三方返回内容保存在本地，而不是只保留页面需要的那几个字段
- 把原始数据整理成统一可筛选的数据集，供后续复用

### 2. 再把“要处理的公告”压缩成工作队列

- 不是所有公告都同等重要
- 系统会给公告补过滤状态、处理状态、评分、方向和失败原因
- 用户真正关心的是哪些公告值得补跑、复核和继续深挖

### 3. 再把重点对象升级成研究产物

- 普通公告先进入摘要、评分和状态层
- 更重要的对象进入解析详情、个股详情和原文回溯
- 高优先级对象再进入深度报告或后续导出链路

### 4. 用任务和日志把这条研究链路跑稳

- 同步、补分析和后台维护都不是一次性动作
- 系统需要知道哪次任务跑了什么、失败在哪、能不能重试
- LLM 日志、操作日志和失败操作记录都属于研究控制面的一部分

## 这套业务更像什么，不像什么

| 它更像 | 为什么 |
| --- | --- |
| 本地研究工作台 | 核心是围绕公告和个股整理研究对象、持续形成研究结论 |
| 研究任务编排系统 | 同步、补分析、失败重试和报告生成都需要排队、追踪和恢复 |
| 研究资产仓 | 原文、分析结果、报告、日志和本地产物都需要长期留存 |

| 它不太像 | 为什么 |
| --- | --- |
| 纯行情终端 | 核心不只是看价格，而是围绕公告和价格信号做判断 |
| 纯 CMS | 内容不是人工静态录入，而是围绕同步、分析和任务持续生成 |
| 一次性 AI 工具 | 结果需要留档、回看、补跑和复核，不是“一问一答”就结束 |

## 对当前 Tauri 项目最有价值的继承结论

1. 当前仓库要继承的是“研究闭环”，不是简单照搬旧后端表结构。
2. `notice_record` 不是普通公告表，而是研究工作台里的公告处理队列。
3. 当日看盘、公告分析、个股详情、公告原文和深度报告本质上属于同一条研究链路。
4. `sys_scheduled_task`、`tsk_run`、`llm_request_log` 和 `sys_failed_operation` 是控制面，目的是保证研究流程跑稳，而不是把产品做成任务中心本身。
