327 lines
9.9 KiB
Markdown
327 lines
9.9 KiB
Markdown
# 结果总览查看详情窗口整体展示优化设计
|
||
|
||
**日期**: 2026-03-25
|
||
**模块**: 初核项目详情 - 结果总览 - 项目分析弹窗
|
||
**作者**: Codex
|
||
**状态**: 已确认
|
||
|
||
## 1. 概述
|
||
|
||
当前 `结果总览` 页中的“查看详情”弹窗已经具备统一入口、基础左右分栏和真实详情加载能力，但整体视觉仍存在以下问题：
|
||
|
||
- 弹窗内部存在明显“页面套页面”感，整体偏重
|
||
- 左右分栏比例与留白不够舒展，主内容区压缩感较强
|
||
- 头部、侧栏、页签、表格、标签之间未形成统一的工作台视觉语言
|
||
|
||
本次设计只聚焦“整体展示效果优化”，允许对弹窗头部、侧栏组织和主区阅读节奏做明显重排，但不改变现有业务入口、路由和接口边界。
|
||
|
||
## 2. 设计范围
|
||
|
||
### 2.1 包含内容
|
||
|
||
- 重构 `ProjectAnalysisDialog.vue` 的整体视觉骨架
|
||
- 重排弹窗头带、左侧档案面板、右侧主工作区的层级关系
|
||
- 统一异常明细、占位页签、标签、摘要块、表格的视觉语言
|
||
- 保留现有“查看详情”入口与默认页签行为
|
||
- 保留现有真实详情接口调用链路
|
||
|
||
### 2.2 不包含内容
|
||
|
||
- 不新增后端接口
|
||
- 不调整结果总览列表层字段、按钮位置和交互入口
|
||
- 不新增页面、路由或抽屉式替代方案
|
||
- 不扩展导出、审批、关注等本轮需求之外的功能
|
||
- 不增加兼容性、补丁式或降级分支方案
|
||
|
||
## 3. 当前上下文
|
||
|
||
当前相关文件主要包括：
|
||
|
||
- `ruoyi-ui/src/views/ccdiProject/components/detail/ProjectAnalysisDialog.vue`
|
||
- `ruoyi-ui/src/views/ccdiProject/components/detail/ProjectAnalysisSidebar.vue`
|
||
- `ruoyi-ui/src/views/ccdiProject/components/detail/ProjectAnalysisAbnormalTab.vue`
|
||
- `ruoyi-ui/src/views/ccdiProject/components/detail/ProjectAnalysisPlaceholderTab.vue`
|
||
|
||
当前实现特点：
|
||
|
||
1. 弹窗外层采用 `el-dialog`，内部再包一层 `project-analysis-shell`
|
||
2. 左侧和右侧虽已收进同一外壳，但仍有较强“卡片拼装”感
|
||
3. “当前命中模型”作为独立提示块出现在主区顶部，容易打断阅读
|
||
4. 侧栏以字段表单式平铺为主，人物档案感不足
|
||
5. 异常明细区块、占位页签和侧栏之间的边框、背景、圆角节奏不统一
|
||
|
||
## 4. 设计目标
|
||
|
||
### 4.1 视觉目标
|
||
|
||
- 去除“弹窗里再套一页”的套娃感
|
||
- 让窗口更像一个完整的分析工作台，而不是多张卡片临时拼接
|
||
- 在保持当前产品色系下，形成更稳定、更克制的调查分析气质
|
||
|
||
### 4.2 交互目标
|
||
|
||
- 用户打开弹窗后，首屏先看清“是谁、风险怎样、为什么点进来”
|
||
- 默认仍进入 `异常明细`，不改变用户现有操作路径
|
||
- 来源于模型命中列表时，上下文提示应更自然地并入头部信息
|
||
|
||
### 4.3 实现目标
|
||
|
||
- 维持现有数据链路与组件职责，不扩散到后端与页面壳层
|
||
- 将改动边界收敛在弹窗及其直属子组件内
|
||
|
||
## 5. 视觉方向
|
||
|
||
### 5.1 Visual Thesis
|
||
|
||
以“沉浸式分析工作台”为核心方向，整体界面强调一层主壳、两块功能面和连续阅读流，避免多层容器叠加造成的后台表单感。
|
||
|
||
### 5.2 Content Plan
|
||
|
||
1. 首屏识别人和风险上下文
|
||
2. 主体展示项目内异常分析内容
|
||
3. 辅助承载其余四个分析页签
|
||
4. 在一次打开中完成快速判断与继续追查的阅读起点
|
||
|
||
### 5.3 Interaction Thesis
|
||
|
||
- 通过头部信息头带建立进入时的第一落点
|
||
- 通过左侧档案面板维持人物语义，不让侧栏沦为字段表单
|
||
- 通过主区摘要条和页签导航建立清晰、稳定的操作路径
|
||
|
||
## 6. 方案比较
|
||
|
||
### 6.1 方案 A：去壳化微调版
|
||
|
||
做法：
|
||
|
||
- 保留当前左右分栏与页签布局
|
||
- 仅去掉部分边框、圆角和外层容器感
|
||
|
||
优点：
|
||
|
||
- 改动边界最小
|
||
|
||
缺点：
|
||
|
||
- 只能缓解表层问题
|
||
- 套娃感和层级割裂无法根治
|
||
|
||
### 6.2 方案 B：沉浸式分析工作台
|
||
|
||
做法：
|
||
|
||
- 保留左右工作台语义
|
||
- 弹窗本身作为唯一主壳
|
||
- 头部、侧栏、主区阅读节奏全部重排
|
||
|
||
优点：
|
||
|
||
- 能同时解决套娃感、比例失衡和风格碎片化问题
|
||
- 与当前业务场景最匹配
|
||
- 后续继续补真实页签内容时不需要再次推翻结构
|
||
|
||
缺点：
|
||
|
||
- 结构调整比简单样式修饰更明显
|
||
|
||
### 6.3 方案 C：单栏纵向叙事版
|
||
|
||
做法：
|
||
|
||
- 弱化或取消侧栏
|
||
- 全部内容按纵向单列展开
|
||
|
||
优点：
|
||
|
||
- 阅读路径最直接
|
||
|
||
缺点：
|
||
|
||
- 不符合当前“分析工作台”场景
|
||
- 会削弱多页签和多模块并存时的效率感
|
||
|
||
### 6.4 结论
|
||
|
||
采用 **方案 B：沉浸式分析工作台**。
|
||
|
||
原因：
|
||
|
||
1. 能一次性解决当前最核心的 `A/C/D` 三类问题
|
||
2. 保留左右工作台语义，不偏离当前业务场景
|
||
3. 不需要引入新接口或新页面，仍然是最短路径实现
|
||
|
||
## 7. 总体设计
|
||
|
||
### 7.1 外层骨架
|
||
|
||
弹窗整体改为“三段式节奏”：
|
||
|
||
1. 顶部信息头带
|
||
2. 主体工作区
|
||
3. 底部留白收束
|
||
|
||
其中，`el-dialog` 内容区直接承担唯一外壳职责，不再在内部额外包一层大白卡式 `shell` 容器。
|
||
|
||
### 7.2 主体布局
|
||
|
||
主体仍保留左右分栏，但重设比例与层次：
|
||
|
||
- 左侧：固定窄栏，宽度约 `300px ~ 320px`
|
||
- 右侧：自适应主工作区
|
||
- 左右两区不再依赖粗边框硬切，而是通过背景层次、留白和局部分隔建立边界
|
||
|
||
### 7.3 头部信息头带
|
||
|
||
头部替代原有简单弹窗标题，组织方式如下：
|
||
|
||
- 左侧主信息：
|
||
- 姓名
|
||
- 风险等级状态
|
||
- 工号 / 部门 / 所属项目
|
||
- 右侧操作：
|
||
- 关闭按钮
|
||
- 右侧补充上下文：
|
||
- 若入口来自模型命中列表，则展示“当前命中模型”
|
||
|
||
“当前命中模型”不再占用主区独立一行，而是并入头带完成来源说明。
|
||
|
||
### 7.4 左侧人物档案面板
|
||
|
||
左栏改为“人物档案面板”，按以下顺序组织：
|
||
|
||
1. 人物身份区
|
||
2. 命中模型摘要区
|
||
3. 排查状态或辅助提示区
|
||
|
||
具体原则：
|
||
|
||
- 不再使用强表单感的左右对齐字段列表作为主要视觉形式
|
||
- 通过人物姓名、风险等级徽标和简洁元信息建立识别性
|
||
- 核心异常标签按统一标签语言展示
|
||
- 如果某组信息不足，则保持简洁，不硬凑空块
|
||
|
||
### 7.5 右侧主工作区
|
||
|
||
主区改为连续阅读流：
|
||
|
||
1. 风险摘要条
|
||
2. 页签导航
|
||
3. 当前页签主体内容
|
||
|
||
其中风险摘要条优先展示当前人员在本项目内最值得关注的 2 至 3 项信息，例如：
|
||
|
||
- 命中模型数
|
||
- 异常标签数
|
||
- 异常分组数或重点异常数
|
||
|
||
### 7.6 异常明细页签
|
||
|
||
`异常明细` 仍为默认页签和主视图，组织节奏调整为：
|
||
|
||
1. 分组标题与一句摘要
|
||
2. 异常明细表格
|
||
3. 对象异常或补充摘要区
|
||
|
||
目标是让主表格继续作为信息中心，同时不再被多余边框和零散块状结构打断。
|
||
|
||
### 7.7 其他页签
|
||
|
||
`资产分析`、`征信摘要`、`关系图谱`、`资金流向` 四个页签本轮仍可保持静态承载，但视觉上统一为同一套工作台区块，不再采用简单占位板式呈现。
|
||
|
||
## 8. 视觉规范
|
||
|
||
### 8.1 背景与层次
|
||
|
||
- 最外层弹窗：唯一主壳
|
||
- 左栏背景：较主区略深的浅灰蓝面
|
||
- 主区背景：白色或极浅白底
|
||
- 关键内容块：局部轻边框或轻底色区分
|
||
|
||
避免同屏重复出现多层边框、圆角和阴影。
|
||
|
||
### 8.2 圆角与边框
|
||
|
||
- 圆角只保留在外层弹窗和主区关键块
|
||
- 大面积容器减少边框存在感
|
||
- 优先通过留白、标题层级、背景差和局部轻分隔线建立秩序
|
||
|
||
### 8.3 间距体系
|
||
|
||
统一使用三档垂直节奏：
|
||
|
||
- 紧凑信息：`8px`
|
||
- 区块内常规间距：`16px`
|
||
- 大区块间距：`24px`
|
||
|
||
主区和侧栏的左右内边距保持同一基线，避免视觉错位。
|
||
|
||
### 8.4 标签与状态
|
||
|
||
- 风险等级、异常标签、命中模型提示统一为浅底色、细边框、小圆角体系
|
||
- 不混用重阴影和高饱和整块底色
|
||
- 不同标签的差异主要通过语义色和轻度背景体现
|
||
|
||
### 8.5 表格
|
||
|
||
- 表格仍是主工作区核心阅读面
|
||
- 弱化网格感，减少厚边框
|
||
- 通过表头层级、行高、次级文字颜色和金额色建立信息密度
|
||
|
||
## 9. 交互与状态
|
||
|
||
### 9.1 保持不变
|
||
|
||
- `风险人员总览` 与 `命中模型涉及人员列表` 的“查看详情”入口不变
|
||
- 默认页签仍为 `异常明细`
|
||
- 仍使用现有详情接口按需拉取真实数据
|
||
|
||
### 9.2 调整点
|
||
|
||
- 加载态与报错态并入主区头部附近，减少打断感
|
||
- 来源为模型命中列表时，模型上下文移入头带
|
||
- 打开弹窗后的首屏信息顺序改为：
|
||
- 人员识别
|
||
- 风险背景
|
||
- 当前来源上下文
|
||
- 详细分析内容
|
||
|
||
## 10. 影响范围
|
||
|
||
本轮前端改动预计收敛在以下文件：
|
||
|
||
- `ruoyi-ui/src/views/ccdiProject/components/detail/ProjectAnalysisDialog.vue`
|
||
- `ruoyi-ui/src/views/ccdiProject/components/detail/ProjectAnalysisSidebar.vue`
|
||
- `ruoyi-ui/src/views/ccdiProject/components/detail/ProjectAnalysisAbnormalTab.vue`
|
||
- `ruoyi-ui/src/views/ccdiProject/components/detail/ProjectAnalysisPlaceholderTab.vue`
|
||
|
||
必要时补充弹窗结构与视觉契约相关单测，但不涉及：
|
||
|
||
- 后端接口
|
||
- 项目详情页路由
|
||
- 结果总览列表层逻辑
|
||
- 其他业务模块详情弹窗
|
||
|
||
## 11. 验收标准
|
||
|
||
1. 打开弹窗后，用户能在首屏快速识别“是谁、风险怎样、为什么点进来”
|
||
2. 窗口整体不再呈现“弹窗里再套一页”的视觉感受
|
||
3. 左右分栏比例更稳定，右侧主区成为明确视觉中心
|
||
4. 头带、侧栏、页签、表格、标签形成统一工作台语言
|
||
5. 不改变当前业务入口、接口和默认页签行为
|
||
|
||
## 12. 结论
|
||
|
||
本次设计采用“沉浸式分析工作台”作为结果总览查看详情窗口的整体优化方向：
|
||
|
||
1. 去掉多余外壳，收口为一层主壳
|
||
2. 重排头带、侧栏和主区节奏
|
||
3. 统一标签、摘要、页签和表格视觉语言
|
||
|
||
该方案满足用户确认的三项核心诉求：
|
||
|
||
- 去除套娃感
|
||
- 调顺分栏比例和留白
|
||
- 统一整体展示效果
|
||
|
||
同时保持当前接口与业务路径不变，属于符合现有边界的最短路径优化方案。
|