实现支持 OpenAI 和 Anthropic 双协议的统一大模型 API 网关 MVP 版本,包含: - OpenAI 和 Anthropic 协议代理 - 供应商和模型管理 - 用量统计 - 前端配置界面
209 lines
6.1 KiB
Markdown
209 lines
6.1 KiB
Markdown
# 前端配置界面
|
||
|
||
## Purpose
|
||
|
||
TBD - 提供供应商、模型配置和用量统计的前端管理界面
|
||
|
||
## Requirements
|
||
|
||
### Requirement: 提供供应商管理页面
|
||
|
||
前端 SHALL 提供用于管理供应商配置的网页。
|
||
|
||
#### Scenario: 显示供应商列表
|
||
|
||
- **WHEN** 加载供应商管理页面
|
||
- **THEN** 前端 SHALL 显示所有已配置供应商的列表
|
||
- **THEN** 每个供应商 SHALL 显示 id, name, base_url 和 enabled 状态
|
||
- **THEN** API Key SHALL 被掩码
|
||
|
||
#### Scenario: 添加新供应商
|
||
|
||
- **WHEN** 用户点击"添加供应商"按钮
|
||
- **THEN** 前端 SHALL 显示输入供应商详情的表单
|
||
- **THEN** 表单 SHALL 包含 id, name, api_key, base_url 字段
|
||
- **WHEN** 用户提交包含有效数据的表单
|
||
- **THEN** 前端 SHALL 向 `/api/providers` 发送 POST 请求
|
||
- **THEN** 前端 SHALL 刷新供应商列表
|
||
|
||
#### Scenario: 编辑现有供应商
|
||
|
||
- **WHEN** 用户点击供应商的"编辑"按钮
|
||
- **THEN** 前端 SHALL 显示预填充供应商当前数据的表单
|
||
- **WHEN** 用户提交包含更新数据的表单
|
||
- **THEN** 前端 SHALL 向 `/api/providers/:id` 发送 PUT 请求
|
||
- **THEN** 前端 SHALL 刷新供应商列表
|
||
|
||
#### Scenario: 删除供应商
|
||
|
||
- **WHEN** 用户点击供应商的"删除"按钮
|
||
- **THEN** 前端 SHALL 提示确认
|
||
- **WHEN** 用户确认删除
|
||
- **THEN** 前端 SHALL 向 `/api/providers/:id` 发送 DELETE 请求
|
||
- **THEN** 前端 SHALL 刷新供应商列表
|
||
|
||
### Requirement: 提供模型管理界面
|
||
|
||
前端 SHALL 在供应商页面中提供管理模型配置的界面。
|
||
|
||
#### Scenario: 显示供应商的模型
|
||
|
||
- **WHEN** 选择或展开供应商
|
||
- **THEN** 前端 SHALL 显示该供应商的模型列表
|
||
- **THEN** 每个模型 SHALL 显示 model_name 和 enabled 状态
|
||
|
||
#### Scenario: 为供应商添加模型
|
||
|
||
- **WHEN** 用户点击供应商的"添加模型"
|
||
- **THEN** 前端 SHALL 显示输入 model_name 的表单
|
||
- **WHEN** 用户提交表单
|
||
- **THEN** 前端 SHALL 向 `/api/models` 发送 POST 请求,携带 provider_id
|
||
- **THEN** 前端 SHALL 刷新模型列表
|
||
|
||
#### Scenario: 编辑模型
|
||
|
||
- **WHEN** 用户点击模型的"编辑"
|
||
- **THEN** 前端 SHALL 显示编辑 model_name 的表单
|
||
- **WHEN** 用户提交表单
|
||
- **THEN** 前端 SHALL 向 `/api/models/:id` 发送 PUT 请求
|
||
- **THEN** 前端 SHALL 刷新模型列表
|
||
|
||
#### Scenario: 删除模型
|
||
|
||
- **WHEN** 用户点击模型的"删除"
|
||
- **THEN** 前端 SHALL 提示确认
|
||
- **WHEN** 用户确认删除
|
||
- **THEN** 前端 SHALL 向 `/api/models/:id` 发送 DELETE 请求
|
||
- **THEN** 前端 SHALL 刷新模型列表
|
||
|
||
### Requirement: 提供统计查看页面
|
||
|
||
前端 SHALL 提供查看用量统计的页面。
|
||
|
||
#### Scenario: 显示统计概览
|
||
|
||
- **WHEN** 加载统计页面
|
||
- **THEN** 前端 SHALL 显示所有供应商和模型的统计
|
||
- **THEN** 前端 SHALL 按供应商和模型分组显示请求计数
|
||
|
||
#### Scenario: 按供应商过滤统计
|
||
|
||
- **WHEN** 用户从下拉菜单选择供应商
|
||
- **THEN** 前端 SHALL 过滤统计,仅显示该供应商的数据
|
||
|
||
#### Scenario: 按模型过滤统计
|
||
|
||
- **WHEN** 用户从下拉菜单选择模型
|
||
- **THEN** 前端 SHALL 过滤统计,仅显示该模型的数据
|
||
|
||
#### Scenario: 按日期范围过滤统计
|
||
|
||
- **WHEN** 用户选择开始和结束日期
|
||
- **THEN** 前端 SHALL 过滤统计,仅显示该范围内的数据
|
||
|
||
### Requirement: 优雅处理 API 错误
|
||
|
||
前端 SHALL 处理 API 错误并显示用户友好的消息。
|
||
|
||
#### Scenario: API 请求失败
|
||
|
||
- **WHEN** API 请求失败(网络错误、4xx、5xx)
|
||
- **THEN** 前端 SHALL 向用户显示错误消息
|
||
- **THEN** 错误消息 SHALL 具有描述性和可操作性
|
||
|
||
#### Scenario: 验证错误
|
||
|
||
- **WHEN** 用户提交包含无效数据的表单
|
||
- **THEN** 前端 SHALL 在相关字段旁显示验证错误
|
||
- **THEN** 前端 SHALL 阻止表单提交
|
||
|
||
### Requirement: 提供响应式布局
|
||
|
||
前端 SHALL 提供适应不同屏幕尺寸的响应式布局。
|
||
|
||
#### Scenario: 桌面布局
|
||
|
||
- **WHEN** 在桌面屏幕上查看前端
|
||
- **THEN** 布局 SHALL 使用多列设计以高效利用空间
|
||
|
||
#### Scenario: 移动布局
|
||
|
||
- **WHEN** 在移动屏幕上查看前端
|
||
- **THEN** 布局 SHALL 适应为单列设计
|
||
- **THEN** 所有功能 SHALL 保持可访问
|
||
|
||
### Requirement: 使用无组件库的最小 UI
|
||
|
||
前端 SHALL 使用自定义组件,不使用外部 UI 库。
|
||
|
||
#### Scenario: 自定义组件
|
||
|
||
- **WHEN** 实现前端
|
||
- **THEN** 它 SHALL 使用自定义 HTML/CSS 组件
|
||
- **THEN** 它 SHALL NOT 使用外部 UI 库,如 Ant Design、Material-UI 或 shadcn/ui
|
||
|
||
#### Scenario: SCSS 样式
|
||
|
||
- **WHEN** 编写样式
|
||
- **THEN** 前端 SHALL 使用 SCSS 进行样式设计
|
||
- **THEN** 样式 SHALL 有组织且可维护
|
||
|
||
### Requirement: 提供导航
|
||
|
||
前端 SHALL 在不同页面间提供导航。
|
||
|
||
#### Scenario: 导航到供应商页面
|
||
|
||
- **WHEN** 用户点击导航中的"供应商"
|
||
- **THEN** 前端 SHALL 导航到供应商管理页面
|
||
|
||
#### Scenario: 导航到统计页面
|
||
|
||
- **WHEN** 用户点击导航中的"统计"
|
||
- **THEN** 前端 SHALL 导航到统计查看页面
|
||
|
||
### Requirement: 使用 React 和 TypeScript
|
||
|
||
前端 SHALL 使用 React 和 TypeScript 实现。
|
||
|
||
#### Scenario: TypeScript 使用
|
||
|
||
- **WHEN** 编写前端代码
|
||
- **THEN** 它 SHALL 使用 TypeScript 提供类型安全
|
||
- **THEN** 所有组件和函数 SHALL 具有适当的类型定义
|
||
|
||
#### Scenario: React 组件
|
||
|
||
- **WHEN** 实现 UI
|
||
- **THEN** 它 SHALL 使用 React 函数组件
|
||
- **THEN** 它 SHALL 使用 React hooks 进行状态管理
|
||
|
||
### Requirement: 使用 Vite 构建
|
||
|
||
前端 SHALL 使用 Vite 作为构建工具。
|
||
|
||
#### Scenario: 开发服务器
|
||
|
||
- **WHEN** 在开发模式下启动前端
|
||
- **THEN** Vite SHALL 使用热模块替换服务应用
|
||
|
||
#### Scenario: 生产构建
|
||
|
||
- **WHEN** 为生产构建前端
|
||
- **THEN** Vite SHALL 生成优化的静态文件
|
||
|
||
### Requirement: 与后端 API 通信
|
||
|
||
前端 SHALL 使用 fetch 或类似方法与后端 API 通信。
|
||
|
||
#### Scenario: API 基础 URL 配置
|
||
|
||
- **WHEN** 前端发起 API 请求
|
||
- **THEN** 它 SHALL 使用配置的后端 API 基础 URL(默认:http://localhost:9826)
|
||
|
||
#### Scenario: API 客户端封装
|
||
|
||
- **WHEN** 进行 API 调用
|
||
- **THEN** 它们 SHALL 封装在专用的 API 客户端模块中
|
||
- **THEN** 错误处理 SHALL 集中化
|