112 lines
5.9 KiB
Markdown
112 lines
5.9 KiB
Markdown
# 需求文档 - MVP版本
|
||
|
||
## 介绍
|
||
|
||
基本面选股系统MVP是一个综合的中文网站，允许用户输入证券代码和交易市场，生成包含多维度分析的详细股票基本面报告。系统通过多个专业分析模块，结合财务数据、AI分析和市场信息，为用户提供全面的投资决策支持。
|
||
|
||
## 术语表
|
||
|
||
- **选股系统 (Stock_Selection_System)**: 提供基本面分析和报告生成的主要系统
|
||
- **用户 (User)**: 使用系统进行股票分析的终端用户
|
||
- **证券代码 (Security_Code)**: 股票在特定交易市场的唯一标识符
|
||
- **交易市场 (Trading_Market)**: 股票交易的地理区域，包括中国、香港、美国、日本
|
||
- **基本面报告 (Fundamental_Report)**: 包含九个分析模块的综合股票分析报告
|
||
- **TradingView图表 (TradingView_Chart)**: 使用TradingView高级图表组件显示的股价图表
|
||
- **Tushare_API**: 用于获取中国股票财务数据的数据源接口
|
||
- **Gemini_Model**: Google的大语言模型，用于生成业务分析内容
|
||
- **景林模型 (Jinglin_Model)**: 基本面分析师使用的问题集分析框架
|
||
- **PostgreSQL数据库 (PostgreSQL_Database)**: 用于存储报告数据的关系型数据库
|
||
- **分析模块 (Analysis_Module)**: 报告中的独立分析部分，每个模块对应一个显示页面
|
||
|
||
## 需求
|
||
|
||
### 需求 1
|
||
|
||
**用户故事:** 作为投资者，我希望能够输入股票代码和选择交易市场，以便获取该股票的综合基本面分析报告
|
||
|
||
#### 验收标准
|
||
|
||
1. 当用户访问首页时，选股系统应当显示证券代码输入框和交易市场选择器
|
||
2. 当用户选择交易市场时，选股系统应当提供中国、香港、美国、日本四个选项
|
||
3. 当用户提交证券代码和交易市场时，选股系统应当处理用户请求并跳转到报告页面
|
||
|
||
### 需求 2
|
||
|
||
**用户故事:** 作为投资者，我希望系统能够检查历史报告，以便决定是查看现有报告还是生成新报告
|
||
|
||
#### 验收标准
|
||
|
||
1. 当用户提交证券代码和交易市场后，选股系统应当在PostgreSQL数据库中查询对应的历史报告
|
||
2. 如果存在历史报告，选股系统应当显示历史报告内容和"生成最新报告"按钮
|
||
3. 如果不存在历史报告，选股系统应当自动启动九步报告生成流程
|
||
|
||
### 需求 3
|
||
|
||
**用户故事:** 作为投资者，我希望系统能够获取准确的财务数据，以便进行可靠的基本面分析
|
||
|
||
#### 验收标准
|
||
|
||
1. 当生成中国股票报告时，选股系统应当使用Tushare_API获取财务信息
|
||
2. 当处理其他市场股票时，选股系统应当根据交易市场选择相应的数据源
|
||
3. 当财务数据获取完成时，选股系统应当将数据作为后续分析的基础
|
||
|
||
### 需求 4
|
||
|
||
**用户故事:** 作为投资者，我希望系统能够通过AI分析获取公司业务信息，以便了解公司的全面情况
|
||
|
||
#### 验收标准
|
||
|
||
1. 当需要业务信息时，选股系统应当使用Gemini生成公司概览、主营业务、发展历程、核心团队、供应链、主要客户及销售模式、未来展望
|
||
2. 当调用Gemini_Model时，选股系统应当使用配置的API密钥进行身份验证
|
||
3. 当业务信息生成完成时，选股系统应当将内容整合到报告的第二部分
|
||
|
||
### 需求 5
|
||
|
||
**用户故事:** 作为投资者，我希望系统能够提供多维度的专业分析，以便获得全面的投资决策支持
|
||
|
||
#### 验收标准
|
||
|
||
1. 当生成报告时，选股系统应当按顺序执行10个分析模块：财务信息、业务信息、基本面分析、看涨分析、看跌分析、市场分析、新闻分析、交易分析、内部人与机构动向分析、最终结论
|
||
2. 当执行基本面分析时，选股系统应当使用问题集进行分析
|
||
3. 当执行看涨分析时，选股系统应当研究潜在隐藏资产和护城河竞争优势
|
||
4. 当执行看跌分析时，选股系统应当分析公司价值底线和最坏情况
|
||
5. 当执行市场分析时，选股系统应当研究市场情绪分歧点与变化驱动
|
||
6. 当执行新闻分析时，选股系统应当研究股价催化剂与拐点预判
|
||
7. 当执行交易分析时，选股系统应当研究市场体量与增长路径
|
||
8. 当执行内部人分析时，选股系统应当研究内部人与机构动向
|
||
9. 当生成最终结论时，选股系统应当指出关键矛盾与预期差以及拐点的临近
|
||
|
||
### 需求 6
|
||
|
||
**用户故事:** 作为投资者，我希望每个分析模块都能独立查看，以便专注于特定的分析维度
|
||
|
||
#### 验收标准
|
||
|
||
1. 当显示报告时，选股系统应当为每个分析模块提供独立的显示页面
|
||
2. 当用户在模块间切换时，选股系统应当保持导航的流畅性
|
||
3. 当所有模块完成时，选股系统应当将完整报告保存到PostgreSQL数据库
|
||
|
||
### 需求 7
|
||
|
||
**用户故事:** 作为投资者，我希望在报告生成过程中能够看到实时进度，以便了解当前状态和预估完成时间
|
||
|
||
#### 验收标准
|
||
|
||
1. 当开始生成报告时，选股系统应当显示进度指示器展示所有分析步骤
|
||
2. 当执行每个分析步骤时，选股系统应当高亮显示当前正在进行的步骤
|
||
3. 当每个步骤完成时，选股系统应当更新步骤状态为已完成
|
||
4. 当执行分析步骤时，选股系统应当记录每个步骤的开始时间和完成时间
|
||
5. 当显示进度时，选股系统应当展示每个步骤的耗时统计
|
||
6. 当步骤执行失败时，选股系统应当显示错误状态和错误信息
|
||
|
||
### 需求 8
|
||
|
||
**用户故事:** 作为系统管理员，我希望能够配置系统参数，以便系统能够正常连接外部服务
|
||
|
||
#### 验收标准
|
||
|
||
1. 选股系统应当提供配置页面用于设置数据库连接参数
|
||
2. 选股系统应当提供配置页面用于设置Gemini_API密钥
|
||
3. 选股系统应当提供配置页面用于设置各市场的数据源配置
|
||
4. 当配置更新时，选股系统应当验证配置的有效性
|
||
5. 当配置保存时，选股系统应当将配置持久化存储 |