175 lines
7.0 KiB
Markdown
175 lines
7.0 KiB
Markdown
## 系统上下文
|
||
|
||
这是一个 Flutter 框架的桌面程序，它的主要功能为如下：
|
||
|
||
- *
|
||
|
||
## 技术栈和限制
|
||
|
||
- 运行时：跨平台
|
||
- 语言：Dart
|
||
- 框架: Flutter
|
||
|
||
## 硬性规定
|
||
|
||
- 数值比较应该使用小于，即使常量在前变量在后
|
||
- 仅使用上述工具。除非堆栈无法合理地解决外部依赖关系，否则不要引入外部依赖关系
|
||
- 在编写自定义实现之前，首选所选工具中的官方 API
|
||
- 该项目目前没有测试, 除非明确要求，否则不要添加测试
|
||
- 所有文字、评论和文档均为中文
|
||
|
||
## 项目结构
|
||
|
||
```markdown
|
||
android/ # 安卓平台源码
|
||
ios/ # iOS 平台源码
|
||
macos/ # MacOS 平台源码
|
||
web/ # Web 平台源码
|
||
windows/ # Windows 平台源码
|
||
lib/ # Dart/Flutter 源码
|
||
├── api/ # 网络请求
|
||
├── models/ # 模块
|
||
├── pages/ # 页面 UI
|
||
├── widgets/ # 可复用组件
|
||
├── utils/ # 通用工具
|
||
└── main.dart # 应用启动入口
|
||
test/ # 单元测试和组件测试
|
||
pubspec.yaml # 依赖管理和资源配置
|
||
assets/ # 静态资源 (图片、字体等)
|
||
```
|
||
|
||
# 用户体验
|
||
|
||
## 核心设计原则
|
||
|
||
这是一个跨平台全平台的 Flutter 应用程序，必须完全兼容所有目标平台（iOS、Android、Windows、macOS、Linux、Web）的功能特性和视觉样式。遵循以下核心设计原则：
|
||
|
||
### 平台特性适配
|
||
1. **圆角系统配置**
|
||
- 提供统一的可配置圆角系统，允许硬编码不同平台的圆角值
|
||
- Windows 10 平台使用直角设计（borderRadius: 0）
|
||
- iOS 和 Android 平台使用大圆角设计（borderRadius: 12-16）
|
||
- 其他平台（Windows 11、macOS、Linux、Web）使用适中圆角（borderRadius: 6-8）
|
||
- 圆角值必须通过平台检测动态应用
|
||
|
||
### 用户体验要求
|
||
2. **状态反馈完整性**
|
||
- 所有数据加载场景必须始终显示明确的加载状态指示器
|
||
- 空数据状态必须提供有意义的空状态 UI 和操作引导
|
||
- 错误状态必须显示清晰的错误信息和恢复操作选项
|
||
|
||
3. **性能优化约束**
|
||
- 避免在主线程执行繁重计算，必须卸载到 Isolate 或延迟执行
|
||
- 所有网络请求必须包含缓存策略，避免不必要的重复 API 调用
|
||
- 使用存储层协调重复请求，实现请求去重和结果复用
|
||
|
||
### 代码质量规范
|
||
4. **组件设计原则**
|
||
- 保持组件小而集中，单一职责原则
|
||
- 将可复用的逻辑提取为独立的可组合项
|
||
- 避免过度抽象，在重复出现 3 次及以上的模式才考虑抽象
|
||
|
||
5. **依赖管理策略**
|
||
- 在没有充分必要性的情况下避免添加外部依赖库
|
||
- 优先使用 Flutter 原生功能和官方推荐库
|
||
- 如必须使用第三方库，需考虑其维护状态、包大小和平台兼容性
|
||
|
||
### 主题与颜色模式
|
||
6. **多主题支持**
|
||
- 必须同时支持浅色和深色两种颜色模式
|
||
- 实现系统主题跟随和手动切换两种主题切换方式
|
||
- 所有颜色值必须通过设计 Token 系统管理，禁止硬编码颜色值
|
||
- 深色模式不是简单的颜色反转，需要专门设计的颜色映射
|
||
- 主题切换过程必须平滑，避免视觉跳跃
|
||
|
||
7. **设计Token系统**
|
||
- 建立完整的设计 Token 体系（颜色、间距、字体、圆角等）
|
||
- Token 命名必须语义化，反映用途而非具体值
|
||
- 通过 ThemeExtension 实现自定义设计 Token
|
||
|
||
### 响应式布局设计
|
||
8. **跨平台布局系统**
|
||
- 实现真正的响应式布局，而非简单的平台检测
|
||
- 定义移动端（手机）、平板、桌面三套布局断点
|
||
- 布局必须流畅适应从最小 320px 到最大4K屏幕的所有分辨率
|
||
- 关键导航模式必须根据不同屏幕尺寸自适应调整
|
||
|
||
9. **组件响应式行为**
|
||
- 移动端优先设计，逐步增强桌面体验
|
||
- 表单元素在不同设备上有优化的布局方式
|
||
- 数据表格在移动端转为卡片列表，桌面端保持表格形式
|
||
- 弹窗和抽屉在不同设备上有适当的呈现方式
|
||
|
||
### 手势操作支持
|
||
10. **移动端手势系统**
|
||
- 必须支持 iOS 和 Android 平台的标准手势操作
|
||
- 列表项支持左滑/右滑操作菜单（可配置）
|
||
- 图片查看器支持双指缩放、双击放大/缩小、单指拖动
|
||
- 长按操作提供触觉反馈（Haptic Feedback）
|
||
- 下拉刷新使用平台自适应组件，符合平台习惯
|
||
|
||
11. **手势冲突处理**
|
||
- 明确手势优先级，避免手势冲突
|
||
- 在可滚动区域内正确处理缩放和滚动手势的协调
|
||
- 边缘手势（如返回手势）必须与系统手势协调
|
||
|
||
### 桌面端快捷键
|
||
12. **键盘快捷键系统**
|
||
- 为所有主要操作提供键盘快捷键支持
|
||
- 遵循平台快捷键惯例（Ctrl 组合键对应 Windows/Linux，Cmd 组合键对应 macOS）
|
||
- 全局快捷键（如保存、搜索、新建）在任何页面都可用
|
||
- 上下文快捷键只在特定组件或场景激活
|
||
|
||
13. **快捷键发现与帮助**
|
||
- 提供快捷键帮助页面（可通过 F1 或 Ctrl + / 访问）
|
||
- 在菜单项和按钮工具提示中显示对应的快捷键
|
||
- 支持用户自定义快捷键（高级功能）
|
||
|
||
### 跨平台一致性
|
||
14. **交互反馈统一**
|
||
- 所有平台上的相同操作应该有类似的感觉
|
||
- 动画时长和缓动曲线保持跨平台一致
|
||
- 加载状态和过渡动画在所有设备上都应提供
|
||
|
||
15. **平台特定优化**
|
||
- 在尊重平台惯例的基础上保持品牌一致性
|
||
- 适当使用平台特定的 UI 模式（如 iOS 的底部操作栏）
|
||
- 确保触摸目标和点击区域符合各平台人机界面指南
|
||
|
||
## 开发流程约束
|
||
|
||
### 实现优先级
|
||
1. **功能完整性和正确性** - 确保核心功能在所有平台正常工作
|
||
2. **性能表现** - 确保 60fps 流畅体验，减少内存占用
|
||
3. **响应式布局** - 确保从手机到桌面的完整布局适配
|
||
4. **平台特性** - 合理利用平台特有功能增强体验
|
||
5. **视觉优化** - 精细调整视觉效果和动画
|
||
|
||
### 代码审查要点
|
||
审查代码时特别注意：
|
||
- 是否遵循了平台特定的圆角规则
|
||
- 是否完整处理了加载/空/错误状态
|
||
- 是否实现了响应式布局断点
|
||
- 是否支持主题切换且切换过程平滑
|
||
- 是否添加了必要的手势支持
|
||
- 是否为桌面操作添加了键盘快捷键
|
||
- 是否避免了不必要的依赖添加
|
||
|
||
## 输出格式要求
|
||
生成代码时，请按以下结构组织：
|
||
1. 平台检测和配置逻辑
|
||
2. 主题和设计 Token 定义
|
||
3. 响应式布局辅助类
|
||
4. 核心组件实现（包含手势和快捷键支持）
|
||
5. 状态管理和数据层
|
||
6. 视图层集成
|
||
|
||
所有生成的代码必须包含清晰的注释，说明：
|
||
- 平台特定的处理逻辑
|
||
- 响应式布局的实现方式
|
||
- 手势操作的支持情况
|
||
- 键盘快捷键的配置
|
||
- 主题切换的影响范围
|
||
|
||
请基于以上完整约束，生成符合所有要求的Flutter应用程序代码。优先保证核心功能的正确实现，然后逐步增强各平台的优化特性。
|