462 lines
22 KiB
Markdown
462 lines
22 KiB
Markdown
---
|
||
title: "feat: Admin UI + Creator Review Status + Order Payment"
|
||
status: active
|
||
created: 2026-06-21
|
||
origin: docs/plans/2026-06-21-001-feat-admin-review-hermes-sync-plan.md (U7 前端缺失)
|
||
plan_depth: standard
|
||
---
|
||
|
||
# Plan: 管理员后台 UI + 创作者审核状态展示 + 订单付款流程
|
||
|
||
## Summary
|
||
|
||
补齐 EternalAI 平台的三个核心功能缺口:(1) 管理员后台 UI,让管理员可通过浏览器完成角色审核和 Hermes 同步发起;(2) 创作者角色卡片审核状态展示,让创作者看到自己角色的审核进度和二维码;(3) Order 订单后端 API + 前端付款流程对接,替换当前的纯前端 Mock。微信 OAuth 和收入/提现后端不在本次范围内。
|
||
|
||
---
|
||
|
||
## Problem Frame
|
||
|
||
当前平台存在三个阻断性缺口:
|
||
|
||
1. **管理员无法通过浏览器操作**:后端审核 API(`/api/admin/reviews/*`)、同步 API(`/api/admin/sync/*`)、配置 API(`/api/admin/config/*`)均已就绪,但 `index.html` 中无任何 admin 视图,`app.js` 中无 admin 相关代码。管理员只能通过 curl/Postman 操作,无法实际使用。
|
||
|
||
2. **创作者看不到审核状态**:后端 `GET /api/roles/my/roles` 已返回 `reviewStatus`、`qrCodeUrl`、`syncedAt`、`reviewNote`,但前端 `renderCreatorRoles()` 只显示 `status`(running/stopped),创作者无法知道自己角色处于待审核/已通过/已同步/被驳回哪个状态,也看不到驳回原因和同步后的二维码。
|
||
|
||
3. **付款流程是前端 Mock**:`prisma/schema.prisma` 定义了 Order 模型但无任何路由,`app.js` 的 `payRole()` 仅切换 DOM 显示,无 API 调用、无订单创建。用户"付款"后看不到真实二维码,平台无法记录订阅关系。
|
||
|
||
---
|
||
|
||
## Requirements
|
||
|
||
### 功能需求
|
||
|
||
- **R1**: 管理员可通过浏览器登录后台(独立登录入口,与用户登录隔离)
|
||
- **R2**: 管理员可查看待审核角色列表,支持按状态筛选
|
||
- **R3**: 管理员可查看角色详情,通过或驳回(驳回需填写原因)
|
||
- **R4**: 管理员可对已通过角色发起 Hermes 同步,填写 profile 名、model key、服务商等参数
|
||
- **R5**: 同步成功后管理员可看到二维码和 profileId
|
||
- **R6**: 管理员可查看同步状态列表(approved/syncing/synced/failed)
|
||
- **R7**: 管理员可配置系统参数(HERMES_WEBHOOK_URL 等)
|
||
- **R8**: 创作者角色卡片显示审核状态标签(待审核/已通过/同步中/已同步/同步失败/已驳回)
|
||
- **R9**: 被驳回角色卡片显示驳回原因
|
||
- **R10**: 已同步角色卡片显示二维码图片和「转发二维码」按钮
|
||
- **R11**: 后端提供 Order CRUD API(创建/查询)
|
||
- **R12**: 前端付款流程调用后端 API 创建订单,付款成功后展示真实二维码
|
||
|
||
### 非功能需求
|
||
|
||
- 管理员 token 与用户 token 隔离存储,不互相干扰
|
||
- 管理员 UI 遵循现有视图路由模式(showView + views 注册)
|
||
- Order API 需用户认证(authMiddleware)
|
||
- 付款流程暂不对接真实支付网关,创建订单即视为已付款(status=paid),返回角色二维码
|
||
|
||
### 范围边界
|
||
|
||
**在范围内**:
|
||
- 管理员后台 UI(登录、审核列表、审核详情、同步表单、同步状态、系统配置)
|
||
- 创作者角色卡片审核状态展示
|
||
- Order 后端 API + 前端付款流程对接
|
||
|
||
**不在范围内**(Deferred):
|
||
- 微信 OAuth 真实接入(hermes-server/src/routes/bind.js 仍为占位符)
|
||
- 收入/提现后端 API(仍为前端 Mock)
|
||
- 真实支付网关对接(本次创建订单即视为已付款)
|
||
- 角色删除/上下架切换
|
||
- 定时任务调度逻辑(Hermes Agent 侧实现)
|
||
|
||
---
|
||
|
||
## Key Technical Decisions
|
||
|
||
### KTD1: 管理员 token 独立存储
|
||
|
||
管理员 token 存储在 `localStorage` 的 `eternal_ai_admin_token`,与用户 token(`eternal_ai_token`)隔离。管理员 state 存储在 `eternal_ai_admin_state`,与用户 state(`eternal_ai_state`)隔离。
|
||
|
||
**理由**: 管理员和用户可能是同一人,token 隔离避免互相覆盖。管理员 API 使用独立的 `ADMIN_JWT_SECRET`,token 不可混用。
|
||
|
||
### KTD2: 管理员入口通过 URL hash 访问
|
||
|
||
管理员后台不显示在底部 TabBar 中(普通用户不可见)。入口通过 URL hash `#admin` 直达,或在首页添加隐藏入口(如长按 logo)。
|
||
|
||
**理由**: 管理员后台是内部工具,不应暴露给普通用户。URL hash 方式简单直接,管理员可收藏书签。
|
||
|
||
### KTD3: Order 状态简化为 pending → paid
|
||
|
||
本次 Order 状态仅 `pending`(待付款)和 `paid`(已付款)。不对接真实支付网关,创建订单时前端直接标记为 `paid`。后续对接真实支付时扩展 `failed`/`refunded` 状态。
|
||
|
||
**理由**: 本次目标是让付款流程有后端记录,而非实现完整支付系统。简化状态机避免过度设计。
|
||
|
||
### KTD4: 付款后返回角色 qrCodeUrl
|
||
|
||
Order 创建(付款)成功后,后端返回角色的 `qrCodeUrl`(来自 Role 表的 `qrCodeUrl` 字段,由 Hermes 同步时写入)。前端展示该二维码供用户扫码绑定微信。
|
||
|
||
**理由**: 用户付款的目的是获取角色二维码以扫码绑定。`qrCodeUrl` 已在同步流程中存储到 Role 表,直接返回即可。若角色未同步(无 qrCodeUrl),则返回错误提示。
|
||
|
||
### KTD5: 创作者角色卡片状态基于 reviewStatus 优先
|
||
|
||
角色卡片状态标签优先显示 `reviewStatus`(pending_review/approved/rejected/syncing/synced/failed),仅当 `reviewStatus` 为 `synced` 时才显示 `status`(running/stopped)作为运行状态。
|
||
|
||
**理由**: `reviewStatus` 是角色的生命周期主状态,`status` 仅在同步完成后才有意义。避免两个状态标签混淆。
|
||
|
||
---
|
||
|
||
## High-Level Technical Design
|
||
|
||
### 管理员后台视图架构
|
||
|
||
```
|
||
用户访问 #admin
|
||
↓
|
||
检查 adminToken 是否有效(GET /api/admin-auth/me)
|
||
↓
|
||
有效 → 显示审核列表页 无效 → 显示管理员登录页
|
||
↓ ↓
|
||
点击角色 → 审核详情页 登录成功 → 存储 adminToken → 显示审核列表页
|
||
↓
|
||
通过 → 返回列表页(状态更新)
|
||
驳回 → 弹窗填写原因 → 返回列表页
|
||
同步 → 同步表单页 → 提交 → 显示二维码 → 返回列表页
|
||
```
|
||
|
||
### Order 付款流程
|
||
|
||
```
|
||
用户在角色详情页点击「立即订阅」
|
||
↓
|
||
POST /api/orders { roleId, amount }
|
||
↓
|
||
后端校验角色已同步(reviewStatus=synced, qrCodeUrl 非空)
|
||
↓
|
||
创建 Order 记录(status=paid)
|
||
↓
|
||
返回 { order, role: { qrCodeUrl } }
|
||
↓
|
||
前端展示二维码
|
||
```
|
||
|
||
---
|
||
|
||
## Implementation Units
|
||
|
||
### U1. 管理员登录页 + 认证状态管理
|
||
|
||
**Goal**: 实现管理员登录页面和独立的 token/state 管理机制。
|
||
|
||
**Requirements**: R1
|
||
|
||
**Dependencies**: 无(后端 API 已就绪)
|
||
|
||
**Files**:
|
||
- `index.html` — 新增 `#admin-login` 视图和 `#admin-reviews` 视图骨架
|
||
- `app.js` — 新增管理员 state 管理、adminApi 封装、登录逻辑、hash 路由
|
||
|
||
**Approach**:
|
||
1. 在 `index.html` 中新增两个视图:
|
||
- `#admin-login`:管理员登录表单(账号、密码、登录按钮)
|
||
- `#admin-reviews`:管理员后台主视图(包含审核列表、详情、同步等子面板,通过内部 Tab 切换)
|
||
2. 在 `app.js` 中新增:
|
||
- `adminState` 对象和 `loadAdminState()`/`saveAdminState()` 函数(key: `eternal_ai_admin_state`)
|
||
- `getAdminToken()`/`setAdminToken()` 函数(key: `eternal_ai_admin_token`)
|
||
- `adminApi(path, options)` 封装(自动添加管理员 Authorization 头)
|
||
- `handleHashRoute()` 函数:监听 `hashchange`,当 hash 为 `#admin` 时检查管理员登录状态并显示对应视图
|
||
- `handleAdminLogin(formData)` 函数:调用 `POST /api/admin-auth/login`,成功后存储 token 并跳转审核列表
|
||
3. 在 `views` 对象中注册 `'admin-login'` 和 `'admin-reviews'`
|
||
4. 在 `viewLabels` 中添加对应标签
|
||
|
||
**Patterns to follow**:
|
||
- 用户登录表单模式(`app.js:1189-1232` 行的 auth 表单提交)
|
||
- `api()` 封装模式(`app.js:4-42` 行),adminApi 镜照此模式但读取 adminToken
|
||
- 视图注册模式(`app.js:112-122` 行 views 对象)
|
||
|
||
**Test scenarios**:
|
||
- **Happy path**: 管理员访问 `#admin`,输入正确账号密码,登录成功跳转审核列表页
|
||
- **Error path**: 管理员输入错误密码,显示错误提示
|
||
- **Edge case**: 管理员已登录时访问 `#admin`,直接跳转审核列表页(不显示登录表单)
|
||
- **Edge case**: 非管理员用户访问 `#admin`,显示登录页(用户 token 不能用于管理员 API)
|
||
- **Integration**: 登录后调用 `GET /api/admin-auth/me` 验证 token 有效
|
||
|
||
**Verification**: 管理员可通过 `#admin` URL 访问登录页,登录成功后进入审核列表页,刷新页面后仍保持登录状态。
|
||
|
||
---
|
||
|
||
### U2. 管理员审核列表页 + 角色详情审核页
|
||
|
||
**Goal**: 实现审核列表(支持状态筛选)和角色详情审核页(通过/驳回)。
|
||
|
||
**Requirements**: R2, R3, R6
|
||
|
||
**Dependencies**: U1
|
||
|
||
**Files**:
|
||
- `index.html` — 在 `#admin-reviews` 视图中添加审核列表和详情面板的 HTML 结构
|
||
- `app.js` — 新增 `renderAdminReviews()`、`renderAdminReviewDetail()`、`handleApprove()`、`handleReject()` 函数
|
||
- `e2e/admin-sync-flow.spec.js` — 扩展 E2E 测试覆盖管理员审核 UI 流程(可选,已有 API 级测试)
|
||
|
||
**Approach**:
|
||
1. 审核列表页结构:
|
||
- 顶部状态筛选 Tab(全部/待审核/已通过/已同步/同步失败/已驳回)
|
||
- 角色卡片列表(头像、名称、创作者、审核状态标签、创建时间)
|
||
- 点击卡片进入详情页
|
||
2. 详情审核页结构:
|
||
- 角色完整信息(头像、名称、描述、人设字段)
|
||
- 当前审核状态
|
||
- 操作按钮区:
|
||
- `pending_review` 状态:显示「通过」和「驳回」按钮
|
||
- `approved` 状态:显示「发起同步」按钮(跳转 U3)
|
||
- `synced` 状态:显示二维码图片和 profileId
|
||
- `rejected` 状态:显示驳回原因
|
||
- `failed` 状态:显示「重新同步」按钮
|
||
3. 驳回流程:点击「驳回」→ 弹窗输入原因 → 调用 `POST /api/admin/reviews/:roleId/reject`
|
||
4. 列表数据通过 `GET /api/admin/reviews?status=xxx` 获取,支持分页
|
||
|
||
**Patterns to follow**:
|
||
- 角色库列表渲染模式(`app.js:302-339` 行 `renderRoleLibrary()`)
|
||
- 创作者角色卡片渲染模式(`app.js:415-450` 行 `renderCreatorRoles()`)
|
||
- Tab 切换模式(`app.js:409-431` 行 creator-center 的 center-tabs)
|
||
|
||
**Test scenarios**:
|
||
- **Happy path**: 管理员登录后看到待审核角色列表,点击角色进入详情,点击「通过」后角色状态变为 approved
|
||
- **Happy path**: 管理员点击「驳回」,输入原因,角色状态变为 rejected,列表中显示驳回原因
|
||
- **Edge case**: 切换状态筛选 Tab,列表正确过滤
|
||
- **Error path**: 对已审核角色再次操作,后端返回 400,前端显示错误提示
|
||
- **Integration**: 审核通过后,角色出现在「已通过」筛选列表中
|
||
|
||
**Verification**: 管理员可查看各状态角色列表,可审核通过或驳回角色,操作后列表实时更新。
|
||
|
||
---
|
||
|
||
### U3. 管理员同步表单 + 二维码展示 + 系统配置
|
||
|
||
**Goal**: 实现同步发起表单、同步成功后二维码展示、系统配置页面。
|
||
|
||
**Requirements**: R4, R5, R7
|
||
|
||
**Dependencies**: U2
|
||
|
||
**Files**:
|
||
- `index.html` — 在 `#admin-reviews` 视图中添加同步表单面板和配置面板的 HTML
|
||
- `app.js` — 新增 `renderSyncForm(roleId)`、`handleSyncSubmit()`、`renderSyncResult()`、`renderAdminConfig()`、`handleConfigUpdate()` 函数
|
||
|
||
**Approach**:
|
||
1. 同步表单(在详情页中 `approved` 状态时显示):
|
||
- 字段:profile 名(必填)、主 model key(必填)、主服务商(必填,下拉选择 openrouter/siliconflow 等)、多媒体 model key、多媒体服务商、定时任务开关、webhook URL 覆盖(可选)
|
||
- 提交按钮:调用 `POST /api/admin/sync/:roleId`
|
||
- 提交后显示 loading 状态
|
||
2. 同步结果展示:
|
||
- 成功:显示二维码图片(`qrCodeUrl`)、profileId、「复制二维码链接」按钮
|
||
- 失败:显示错误信息、「重新同步」按钮
|
||
3. 系统配置页(管理员后台第三个 Tab):
|
||
- 列出所有系统配置(`GET /api/admin/config`)
|
||
- 每项配置可编辑(`PUT /api/admin/config/:key`)
|
||
- 敏感配置(SYNC_SECRET)显示 `***` 且不可编辑
|
||
- 重点配置:HERMES_WEBHOOK_URL、HERMES_ADMIN_TOKEN 等
|
||
|
||
**Patterns to follow**:
|
||
- 角色创建表单的 stepper 模式(`app.js:633-936` 行)
|
||
- 设置表单提交模式(`app.js:1233-1255` 行 settings 表单)
|
||
- Hermes 部署指南弹窗模式(`app.js:546-617` 行 `showHermesDeployGuide()`)
|
||
|
||
**Test scenarios**:
|
||
- **Happy path**: 管理员在 approved 角色详情页填写同步参数,提交后显示二维码和 profileId
|
||
- **Error path**: 同步失败(Hermes 不可达),显示错误信息
|
||
- **Edge case**: webhook URL 留空时使用全局配置
|
||
- **Edge case**: 同步中状态(syncing)时按钮禁用
|
||
- **Happy path**: 管理员在配置页修改 HERMES_WEBHOOK_URL,保存成功
|
||
- **Error path**: 尝试修改 SYNC_SECRET,返回 403 禁止操作
|
||
|
||
**Verification**: 管理员可发起同步并看到二维码,可修改系统配置。
|
||
|
||
---
|
||
|
||
### U4. 创作者角色卡片审核状态展示
|
||
|
||
**Goal**: 修改创作者角色卡片,展示审核状态、驳回原因、二维码。
|
||
|
||
**Requirements**: R8, R9, R10
|
||
|
||
**Dependencies**: 无(后端已返回所需字段)
|
||
|
||
**Files**:
|
||
- `app.js` — 修改 `renderCreatorRoles()` 函数(约 415-450 行)
|
||
- `styles.css` — 新增审核状态标签样式
|
||
- `e2e/creator.spec.js` — 扩展测试覆盖审核状态展示
|
||
|
||
**Approach**:
|
||
1. 修改 `renderCreatorRoles()` 中的卡片渲染逻辑:
|
||
- 根据 `reviewStatus` 渲染状态标签(优先于 `status`):
|
||
- `pending_review` → 灰色标签「待审核」
|
||
- `approved` → 蓝色标签「已通过」
|
||
- `rejected` → 红色标签「已驳回」+ 显示 `reviewNote`
|
||
- `syncing` → 黄色标签「同步中」
|
||
- `synced` → 绿色标签「已同步」+ 显示 `status`(运行中/已停止)
|
||
- `failed` → 橙色标签「同步失败」
|
||
- `synced` 状态角色卡片额外显示:
|
||
- 二维码缩略图(`qrCodeUrl`)
|
||
- 「查看二维码」按钮(点击放大显示)
|
||
- 「转发二维码」按钮(复制链接到剪贴板)
|
||
- `rejected` 状态角色卡片额外显示:
|
||
- 驳回原因文本(`reviewNote`)
|
||
- 「编辑」按钮高亮提示修改
|
||
2. 新增 `showQrCodeModal(qrCodeUrl)` 函数:弹窗显示二维码大图
|
||
3. 新增 `copyQrCodeLink(qrCodeUrl)` 函数:复制二维码链接到剪贴板
|
||
|
||
**Patterns to follow**:
|
||
- 现有角色卡片状态标签模式(`role-card__status--${statusClass}`)
|
||
- Hermes 部署指南弹窗模式(`app.js:546-617` 行)
|
||
- `escapeHtml()` 用于所有用户可控内容
|
||
|
||
**Test scenarios**:
|
||
- **Happy path**: 创作者创建角色后,卡片显示「待审核」标签
|
||
- **Happy path**: 管理员审核通过后,创作者卡片显示「已通过」标签
|
||
- **Happy path**: 同步完成后,创作者卡片显示「已同步」+ 二维码缩略图
|
||
- **Happy path**: 被驳回后,创作者卡片显示「已驳回」+ 驳回原因
|
||
- **Edge case**: 点击「查看二维码」弹窗显示大图
|
||
- **Edge case**: 点击「转发二维码」复制链接到剪贴板
|
||
|
||
**Verification**: 创作者可在角色列表看到每个角色的审核状态、驳回原因和二维码。
|
||
|
||
---
|
||
|
||
### U5. Order 订单后端 API
|
||
|
||
**Goal**: 实现 Order 模型的 CRUD 后端端点。
|
||
|
||
**Requirements**: R11
|
||
|
||
**Dependencies**: 无(Order 模型已在 schema 中定义)
|
||
|
||
**Files**:
|
||
- `src/routes/orders.js` — 新建订单路由文件
|
||
- `server.js` — 挂载 `/api/orders` 路由
|
||
- `e2e/orders.spec.js` — 新建订单 E2E 测试
|
||
|
||
**Approach**:
|
||
1. 新建 `src/routes/orders.js`,实现以下端点:
|
||
- `POST /api/orders` — 创建订单(付款)
|
||
- 认证:`authMiddleware`
|
||
- 请求体:`{ roleId, amount }`
|
||
- 逻辑:
|
||
- 校验 roleId 存在且角色 `reviewStatus='synced'` 且 `qrCodeUrl` 非空
|
||
- 校验 amount > 0
|
||
- 创建 Order 记录(status='paid',userId=当前用户)
|
||
- 返回 `{ order: { id, roleId, amount, status, createdAt }, role: { qrCodeUrl, displayName } }`
|
||
- `GET /api/orders` — 查询当前用户订单列表
|
||
- 认证:`authMiddleware`
|
||
- 返回:`{ orders: [{ id, roleId, role: { displayName, avatar }, amount, status, createdAt }] }`
|
||
- `GET /api/orders/:id` — 查询订单详情
|
||
- 认证:`authMiddleware`
|
||
- 校验:订单属于当前用户
|
||
- 返回:`{ order: { ...完整字段, role: { ...角色信息 } } }`
|
||
2. 在 `server.js` 中挂载路由:`app.use('/api/orders', require('./src/routes/orders'));`
|
||
3. 错误处理:
|
||
- 角色未同步:返回 400 `{ error: '该角色尚未同步,无法订阅' }`
|
||
- 角色不存在:返回 404
|
||
- 订单不属于当前用户:返回 403
|
||
|
||
**Patterns to follow**:
|
||
- 现有路由模式(`src/routes/roles.js` 的 `authMiddleware` 使用)
|
||
- 现有错误处理模式(`res.status(400).json({ error: '...' })`)
|
||
- Prisma 查询模式(`prisma.order.findMany({ where: { userId }, include: { role: true } })`)
|
||
|
||
**Test scenarios**:
|
||
- **Happy path**: 用户对已同步角色发起付款,创建订单成功,返回 qrCodeUrl
|
||
- **Error path**: 用户对未同步角色发起付款,返回 400
|
||
- **Error path**: 未认证用户发起付款,返回 401
|
||
- **Edge case**: 用户查询自己的订单列表,只返回自己的订单
|
||
- **Edge case**: 用户查询他人订单,返回 403
|
||
- **Integration**: 创建订单后,订单列表中包含该订单
|
||
|
||
**Verification**: Order API 可创建、查询订单,角色未同步时拒绝创建。
|
||
|
||
---
|
||
|
||
### U6. 前端付款流程对接
|
||
|
||
**Goal**: 修改前端 `payRole()` 函数,调用后端 API 创建订单并展示真实二维码。
|
||
|
||
**Requirements**: R12
|
||
|
||
**Dependencies**: U5
|
||
|
||
**Files**:
|
||
- `app.js` — 修改 `payRole()` 函数(约 361-367 行),新增 `renderPaidState()` 函数
|
||
- `index.html` — 修改 `#role-detail` 视图中的付款后区域结构
|
||
- `e2e/roles.spec.js` — 扩展测试覆盖付款流程
|
||
|
||
**Approach**:
|
||
1. 修改 `payRole()` 函数:
|
||
- 调用 `POST /api/orders` 传入 `{ roleId: currentRole.id, amount: currentRole.price }`
|
||
- 成功后调用 `renderPaidState(data.role.qrCodeUrl)` 展示二维码
|
||
- 失败时 `alert` 错误信息
|
||
- 添加 loading 状态(按钮禁用 + 文字变为「处理中…」)
|
||
2. 新增 `renderPaidState(qrCodeUrl)` 函数:
|
||
- 隐藏「立即订阅」按钮
|
||
- 显示「已订阅」区域
|
||
- 渲染二维码图片(`<img src="${qrCodeUrl}" alt="角色二维码" />`)
|
||
- 添加「保存二维码」按钮(长按或下载)
|
||
3. 修改 `#role-detail` 视图 HTML:
|
||
- `#detail-qr` 区域改为可容纳 `<img>` 的容器
|
||
- 移除 `qr-placeholder` 占位符
|
||
|
||
**Patterns to follow**:
|
||
- 现有 `api()` 调用模式(`app.js:4-42` 行)
|
||
- 现有按钮 loading 模式(禁用 + 文字变化)
|
||
- `escapeHtml()` 用于所有动态内容
|
||
|
||
**Test scenarios**:
|
||
- **Happy path**: 用户点击「立即订阅」,调用 API 成功,显示真实二维码
|
||
- **Error path**: 角色未同步,API 返回 400,显示错误提示
|
||
- **Error path**: 网络错误,显示「无法连接服务器」
|
||
- **Edge case**: 重复点击「立即订阅」按钮,第二次点击被禁用(loading 状态)
|
||
- **Integration**: 付款后刷新页面,角色详情页仍显示已订阅状态(基于订单记录)
|
||
|
||
**Verification**: 用户付款后看到真实二维码,非占位符。
|
||
|
||
---
|
||
|
||
## Risks & Dependencies
|
||
|
||
### 风险
|
||
|
||
1. **管理员 UI 复杂度**: 管理员后台涉及多个面板(审核列表、详情、同步表单、配置),HTML 和 JS 代码量较大。**缓解**: 分三个实现单元(U1/U2/U3)逐步实现,每个单元可独立验证。
|
||
|
||
2. **Order 付款流程简化**: 本次创建订单即视为已付款,不对接真实支付。后续对接支付网关时需重构。**缓解**: Order 模型已预留 `status` 字段,后续扩展状态机即可。
|
||
|
||
3. **创作者卡片状态展示复杂性**: `reviewStatus` 和 `status` 两个状态字段的展示逻辑需仔细设计,避免混淆。**缓解**: KTD5 明确了优先级规则——`reviewStatus` 优先,仅 `synced` 时显示 `status`。
|
||
|
||
### 依赖
|
||
|
||
- 后端管理员 API 已全部就绪(U1-U3 依赖)
|
||
- 后端 `GET /api/roles/my/roles` 已返回所需字段(U4 依赖)
|
||
- Order 模型已在 Prisma schema 中定义(U5 依赖)
|
||
- 前端 `payRole()` 函数已存在(U6 修改对象)
|
||
|
||
---
|
||
|
||
## Deferred to Follow-Up Work
|
||
|
||
- 微信 OAuth 真实接入(hermes-server/src/routes/bind.js 的 `wechat_oauth_placeholder`)
|
||
- 收入/提现后端 API(当前仍为前端 Mock 数据)
|
||
- 真实支付网关对接(当前创建订单即视为已付款)
|
||
- 角色删除/上下架切换
|
||
- 定时任务调度逻辑(enableSchedule 标志已传递,但 Hermes Server 无实际调度)
|
||
- 管理员后台移动端适配优化(本次优先功能完整性)
|
||
|
||
---
|
||
|
||
## System-Wide Impact
|
||
|
||
- **用户**: 普通用户在角色详情页付款后能看到真实二维码(U6)
|
||
- **创作者**: 创作者可在角色列表看到审核状态和二维码(U4)
|
||
- **管理员**: 管理员可通过浏览器完成审核和同步操作(U1-U3)
|
||
- **数据库**: Order 表开始有数据写入(U5)
|
||
- **API**: 新增 `/api/orders` 路由(U5)
|
||
|
||
---
|
||
|
||
## Acceptance Examples
|
||
|
||
- **AE1**: 管理员访问 `#admin`,登录后看到待审核角色列表,点击「通过」→ 角色状态变为 approved → 点击「发起同步」→ 填写参数 → 显示二维码
|
||
- **AE2**: 创作者创建角色后,在角色列表看到「待审核」标签 → 管理员驳回后,看到「已驳回」+ 驳回原因 → 修改后重新提交,看到「待审核」
|
||
- **AE3**: 用户在角色详情页点击「立即订阅」→ 调用 API 创建订单 → 显示真实二维码 → 用户扫码绑定
|