通用的系统性优化项目UI的任务描述

请对当前项目进行一次系统性的整体 UI 质量优化。

这不是单个页面的局部美化，也不是重新制作一个演示页面，而是基于现有业务和设计体系，对整个项目的 UI 进行审计、统一、重构和验证。

一、项目背景

项目类型：[填写项目类型，例如桌面管理工具、后台管理系统、数据分析工具]

目标用户：[填写目标用户]

核心使用场景：[填写用户最常执行的操作]

目标平台：[填写操作系统、浏览器或窗口类型]

当前 UI 风格：[填写已有视觉风格；没有时可写“以当前项目主题为准”]

二、优化目标

整体 UI 应达到以下目标：

1. 保持现有产品定位和业务结构不变。
2. 建立统一、完整、稳定的视觉体系。
3. 保证所有页面使用同一套组件语言和主题规则。
4. 提高页面的信息层级、扫描效率和操作效率。
5. 消除浏览器原生控件、临时样式和页面级视觉分裂。
6. 让项目达到正式产品的 UI 交付质量，而不是演示页面质量。
7. 在常用窗口尺寸和最小支持尺寸下保持布局稳定。
8. 不改变现有业务逻辑、数据结构、API、权限和核心用户流程。

三、优化范围

检查并根据需要优化整个项目，包括但不限于：

• 应用整体布局；
• 侧边栏和顶部导航；
• 页面标题和操作栏；
• 页面间距和内容宽度；
• 表单和字段布局；
• 文件上传和选择控件；
• 搜索、筛选和分页；
• 表格和数据展示；
• 按钮和操作区；
• 弹窗、菜单和下拉控件；
• 加载状态；
• 空数据状态；
• 错误状态；
• 成功状态；
• 禁用状态；
• 权限不足状态；
• 提示信息；
• 用户信息区域；
• 所有业务页面；
• 所有公共 UI 组件。

不能只修改一个页面。发现某个问题在多个页面重复出现时，应优先通过公共组件或主题规则统一解决。

四、组件和主题约束

1. 项目现有的 shadcn/ui 和公共组件是唯一的基础 UI 组件体系。
2. 所有用户可见的交互控件必须使用现有组件或公共组件。
3. 不得直接展示浏览器默认样式的原生控件，包括原生按钮、输入框、下拉框、复选框、单选框、文件选择器和弹窗。
4. 原生 HTML 控件可以作为隐藏的底层能力，但默认界面不得直接暴露给用户。
5. 文件选择、日期选择、下拉选择、弹窗、表格和提示信息必须使用统一组件实现。
6. 默认不修改已安装的 shadcn/ui 基础组件源码。
7. 页面应优先使用组件已有的属性、variant、size 和组合能力。
8. 确实需要扩展时，应实现为可复用的公共组件或正式 variant，不得创建只服务单个页面的临时组件。
9. 页面级样式主要用于布局、间距、尺寸、定位、滚动和响应式适配。
10. 不得通过页面级样式修改基础组件的颜色、圆角、阴影、字号、控件高度和状态样式。
11. 所有颜色、圆角、阴影、字号和状态颜色必须来自项目主题令牌。
12. 不得在业务页面随意使用十六进制颜色、RGB、HSL 或其他任意视觉值。
13. 同一种组件在不同页面中必须保持相同的尺寸、颜色、状态和交互方式。
14. 不得在单个页面中引入与现有主题不同的视觉语言。

五、设计原则

1. UI 必须服务于用户任务，优先保证清晰度、操作效率和一致性。
2. 默认采用简洁、克制、专业、稳定且符合目标平台使用习惯的设计。
3. 不盲目使用大面积渐变、超大标题、复杂阴影、装饰性背景、夸张动画和大量卡片。
4. 不把所有页面区域都设计成独立卡片。
5. 不嵌套无意义的卡片。
6. 不为了填充页面而制造大面积空白。
7. 页面应具有明确的信息层级：
   • 页面标题表达当前任务；
   • 主要操作容易发现；
   • 次要操作降低视觉权重；
   • 相关内容合理分组；
   • 高频信息便于扫描和比较。
8. 表单标签、控件、帮助文本、错误提示和操作按钮必须保持统一对齐。
9. 同一表单中的控件高度、标签间距和字段间距必须一致。
10. 主要操作应突出，但单个操作区域通常只保留一个主要按钮。
11. 熟悉的工具操作优先使用统一图标，并为含义不明确的图标提供提示。
12. 动画只用于表达状态变化和操作反馈，不得妨碍操作。
13. 文本、按钮、表格、表单和工具栏不得发生溢出、遮挡或错位。
14. 如果项目已有设计稿、截图或参考产品，应保持其整体布局、密度和视觉方向。
15. 如果没有明确设计参考，应以当前项目主题和已有公共组件作为唯一视觉基准，不要重新创造一套风格。

六、系统性优化流程

请按照以下顺序执行：

第一步：项目 UI 审计

检查并记录：

• 所有页面和路由；
• 所有公共组件；
• shadcn/ui 组件使用情况；
• 原生 HTML 控件；
• 页面级颜色和样式；
• 重复的 UI 实现；
• 不一致的按钮、表单、表格和状态；
• 空状态、错误状态和加载状态；
• 不同窗口尺寸下的布局问题。

第二步：确定主题基线

确认并统一：

• 颜色和语义化颜色令牌；
• 字体和字号层级；
• 间距体系；
• 控件尺寸；
• 圆角；
• 阴影；
• 边框；
• 焦点状态；
• 成功、警告、错误和禁用状态。

不得只在单个页面中修补这些规则，应优先在主题或公共组件层解决。

第三步：整理公共组件

优先统一和复用：

• 页面标题区；
• 操作栏；
• 表单字段；
• 文件上传；
• 表格；
• 状态标签；
• 空状态；
• 加载状态；
• 错误状态；
• 弹窗；
• 提示信息；
• 分页；
• 筛选区域。

第四步：优化业务页面

在公共组件稳定后，再优化具体页面：

• 调整页面结构；
• 优化信息层级；
• 统一对齐和间距；
• 减少重复卡片；
• 修复过度留白；
• 调整主要和次要操作；
• 补充必要状态；
• 确保页面之间保持统一。

第五步：视觉和交互验证

实际运行项目并检查：

• 常用窗口尺寸；
• 最小支持窗口尺寸；
• 内容较多的页面；
• 空数据页面；
• 表单页面；
• 表格页面；
• 弹窗和菜单；
• 加载、错误和禁用状态；
• 主要用户流程。

七、禁止事项

以下情况不得出现在最终结果中：

1. 可见的浏览器原生控件。
2. 同一页面混用两套组件风格。
3. 页面级临时 CSS 覆盖公共组件。
4. 主题令牌之外的任意颜色、圆角、阴影或字体规则。
5. 相同功能使用多个外观不一致的组件。
6. 只优化当前页面而忽略其他页面的相同问题。
7. 只实现正常状态而缺少必要的加载、空数据或错误状态。
8. 为了视觉效果改变业务逻辑或用户操作含义。
9. 使用伪造数据、占位内容或开发阶段文案。
10. 使用大面积空白、无意义卡片或装饰性内容填充页面。
11. 遗留无效按钮、无效菜单、不可操作控件或静默失败。
12. 仅确认页面“能显示”，但没有进行实际视觉和交互检查。

八、验收标准

当且仅当以下条件满足时，才认为整体 UI 优化完成：

1. 所有用户可见控件都属于统一组件体系。
2. 没有暴露浏览器原生默认控件。
3. 所有页面使用一致的颜色、字体、间距、圆角、阴影和控件尺寸。
4. 公共问题已经通过公共组件或主题规则解决，而不是逐页打补丁。
5. 页面信息层级清晰，主要操作容易发现。
6. 表单、表格、弹窗和状态反馈具有统一的视觉和交互规范。
7. 常用窗口尺寸和最小支持尺寸下没有溢出、遮挡和错位。
8. 主要页面已经检查正常、加载、空数据、错误、成功和禁用状态。
9. 没有改变现有业务逻辑、API、权限和核心用户流程。
10. 项目已经完成必要的构建、类型检查、测试和实际运行验证。
11. 重要页面已经通过截图进行视觉验收。
12. 仍存在的问题和未验证内容已经明确记录。

九、交付说明

完成后简洁汇报：

1. UI 审计发现的主要问题；
2. 统一的主题和设计规则；
3. 调整或新增的公共组件；
4. 优化的页面和范围；
5. 执行的验证命令；
6. 实际运行和截图验证结果；
7. 尚未解决的问题和已知限制。

不要只输出设计建议或静态示例，应直接在当前项目中完成系统性 UI 优化。