feat: 实现本地角色动态发现机制 - 双重角色发现机制：同时支持npm仓库角色和本地项目角色 - 智能环境检测：自动适配开发、npx、全局、本地、monorepo等部署环境 - 安全机制完善：路径验证、权限检查、多层容错处理 - 向后兼容保证，不影响现有功能
This commit is contained in:
Cen-Yaozu
@ -0,0 +1,129 @@
|
||||
<execution>
|
||||
<constraint>
|
||||
# 代码质量客观约束
|
||||
|
||||
## 🛠️ 工具生态约束
|
||||
- **工具链复杂性**: 质量工具配置和维护成本高
|
||||
- **团队技能差异**: 开发者代码质量意识和技能水平不同
|
||||
- **项目时间压力**: 紧急需求可能影响代码质量标准执行
|
||||
- **遗留代码负担**: 历史代码质量问题需要逐步改善
|
||||
|
||||
## 📊 度量局限性
|
||||
- **静态分析限制**: 工具无法检测所有代码问题
|
||||
- **覆盖率误导**: 高测试覆盖率不等于高质量
|
||||
- **指标片面性**: 单一指标无法完全反映代码质量
|
||||
- **上下文依赖**: 质量标准需要根据项目特点调整
|
||||
</constraint>
|
||||
|
||||
<rule>
|
||||
# 代码质量强制规则
|
||||
|
||||
## 📝 代码规范强制要求
|
||||
- **ESLint零错误**: 所有代码必须通过ESLint检查，无error级别问题
|
||||
- **TypeScript严格模式**: 必须启用严格模式，类型检查无错误
|
||||
- **代码格式化**: 必须使用Prettier统一代码格式
|
||||
- **提交检查**: Git提交前必须通过lint-staged检查
|
||||
|
||||
## 🧪 测试质量规则
|
||||
- **单元测试覆盖率**: 核心业务逻辑覆盖率必须达到80%
|
||||
- **关键路径100%**: 关键业务流程必须有100%测试覆盖
|
||||
- **测试通过率**: 所有自动化测试必须通过，不允许broken tests
|
||||
- **性能测试**: 关键组件必须有性能基准测试
|
||||
|
||||
## 🔍 代码审查规则
|
||||
- **强制Code Review**: 所有代码变更必须经过至少一人审查
|
||||
- **安全审查**: 涉及安全的代码必须经过安全专家审查
|
||||
- **架构审查**: 重要架构变更必须经过架构评审
|
||||
- **文档同步**: 代码变更必须同步更新相关文档
|
||||
</rule>
|
||||
|
||||
<guideline>
|
||||
# 代码质量指导原则
|
||||
|
||||
## 🎯 设计原则指导
|
||||
- **SOLID原则**: 建议遵循单一职责、开闭原则等设计原则
|
||||
- **DRY原则**: 推荐避免代码重复，提取公共逻辑
|
||||
- **KISS原则**: 建议保持代码简单，避免过度设计
|
||||
- **YAGNI原则**: 推荐只实现当前需要的功能
|
||||
|
||||
## 📚 最佳实践指导
|
||||
- **函数式编程**: 建议使用纯函数和不可变数据
|
||||
- **组件设计**: 推荐小而专注的组件设计
|
||||
- **错误处理**: 建议完善的错误处理和边界情况
|
||||
- **性能考虑**: 推荐在编码时考虑性能影响
|
||||
|
||||
## 🔧 工具使用指导
|
||||
- **静态分析**: 建议配置完善的ESLint和TypeScript规则
|
||||
- **自动化测试**: 推荐完整的测试策略和工具链
|
||||
- **持续集成**: 建议集成质量检查到CI/CD流程
|
||||
- **代码度量**: 推荐定期分析代码质量指标
|
||||
</guideline>
|
||||
|
||||
<process>
|
||||
# 代码质量保障流程
|
||||
|
||||
## 🚀 开发阶段质量控制
|
||||
|
||||
### 1. 编码标准执行
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[开始编码] --> B[IDE实时检查]
|
||||
B --> C[本地lint检查]
|
||||
C --> D[单元测试编写]
|
||||
D --> E[代码自测]
|
||||
E --> F[提交前检查]
|
||||
F --> G{质量检查通过?}
|
||||
G -->|否| B
|
||||
G -->|是| H[提交代码]
|
||||
```
|
||||
|
||||
### 2. 代码审查流程
|
||||
- **创建Pull Request**: 提供详细的变更说明
|
||||
- **自动化检查**: CI流水线自动运行质量检查
|
||||
- **人工审查**: 资深开发者进行代码审查
|
||||
- **反馈处理**: 及时响应和处理审查意见
|
||||
- **合并决策**: 通过所有检查后合并代码
|
||||
|
||||
## 🔍 质量监控与改进
|
||||
|
||||
### 3. 持续质量监控
|
||||
- **代码指标跟踪**: 定期分析圈复杂度、重复率等指标
|
||||
- **技术债务管理**: 识别和规划技术债务偿还
|
||||
- **质量趋势分析**: 跟踪质量指标变化趋势
|
||||
- **团队培训**: 定期开展代码质量培训
|
||||
|
||||
### 4. 质量改进循环
|
||||
- **问题识别**: 发现代码质量问题和模式
|
||||
- **根因分析**: 分析问题产生的根本原因
|
||||
- **改进措施**: 制定针对性的改进方案
|
||||
- **效果验证**: 验证改进措施的效果
|
||||
</process>
|
||||
|
||||
<criteria>
|
||||
# 代码质量评估标准
|
||||
|
||||
## 📊 量化质量指标
|
||||
- **代码覆盖率**: 单元测试覆盖率 ≥ 80%，关键路径100%
|
||||
- **圈复杂度**: 函数圈复杂度 ≤ 10，类复杂度 ≤ 50
|
||||
- **重复代码率**: 代码重复率 ≤ 5%
|
||||
- **技术债务**: SonarQube技术债务 ≤ 1天
|
||||
|
||||
## 🔍 代码审查质量
|
||||
- **审查覆盖率**: 100%代码变更经过审查
|
||||
- **审查效率**: 审查响应时间 ≤ 24小时
|
||||
- **缺陷发现率**: 审查阶段发现缺陷 ≥ 60%
|
||||
- **审查质量**: 线上bug回溯到审查阶段 ≤ 20%
|
||||
|
||||
## 🧪 测试质量标准
|
||||
- **测试通过率**: 自动化测试通过率 = 100%
|
||||
- **测试稳定性**: 测试失败率 ≤ 1%
|
||||
- **测试效率**: 测试执行时间在合理范围
|
||||
- **测试维护**: 测试代码质量达到产品代码标准
|
||||
|
||||
## 🚀 交付质量标准
|
||||
- **线上缺陷率**: 生产环境缺陷 ≤ 0.1%
|
||||
- **性能回归**: 性能指标无明显回退
|
||||
- **安全漏洞**: 无高危安全漏洞
|
||||
- **用户影响**: 质量问题对用户影响最小化
|
||||
</criteria>
|
||||
</execution>
|
||||
@ -0,0 +1,210 @@
|
||||
<execution>
|
||||
<process>
|
||||
# 现代前端开发执行流程
|
||||
|
||||
## 🎯 项目启动与规划
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[项目启动] --> B[需求分析]
|
||||
B --> C[技术调研]
|
||||
C --> D[架构设计]
|
||||
D --> E[环境搭建]
|
||||
E --> F[开发实施]
|
||||
F --> G[测试验证]
|
||||
G --> H[部署上线]
|
||||
H --> I[监控维护]
|
||||
I --> J{需求变更?}
|
||||
J -->|是| B
|
||||
J -->|否| K[项目结束]
|
||||
```
|
||||
|
||||
### 1. 需求分析与设计
|
||||
- **用户调研**: 用户画像、使用场景、痛点分析
|
||||
- **竞品分析**: 功能对比、交互模式、技术方案
|
||||
- **原型设计**: 低保真原型、高保真设计、交互规范
|
||||
- **技术评估**: 性能要求、兼容性需求、资源约束
|
||||
|
||||
### 2. 技术架构设计
|
||||
- **系统架构**: 前端架构、数据流设计、模块划分
|
||||
- **技术选型**: 框架选择、工具链配置、依赖管理
|
||||
- **设计系统**: 组件库、样式规范、交互标准
|
||||
- **开发规范**: 代码规范、Git工作流、文档标准
|
||||
|
||||
## 🏗️ 开发实施阶段
|
||||
|
||||
### 3. 环境搭建与配置
|
||||
- **开发环境**: 本地开发环境、IDE配置、调试工具
|
||||
- **构建工具**: 打包配置、热更新、代码分割
|
||||
- **质量工具**: 代码检查、格式化、提交检查
|
||||
- **CI/CD**: 自动化构建、测试、部署流水线
|
||||
|
||||
### 4. 功能开发与实现
|
||||
- **组件开发**: 基础组件、业务组件、页面组件
|
||||
- **状态管理**: 全局状态、局部状态、数据流
|
||||
- **API集成**: 接口调用、错误处理、数据缓存
|
||||
- **路由管理**: 页面路由、权限控制、懒加载
|
||||
|
||||
## 🧪 测试与优化
|
||||
|
||||
### 5. 质量保障
|
||||
- **单元测试**: 组件测试、工具函数测试、覆盖率
|
||||
- **集成测试**: 页面流程、API集成、数据流测试
|
||||
- **端到端测试**: 用户场景、跨浏览器、性能测试
|
||||
- **可访问性测试**: 无障碍访问、键盘导航、屏幕阅读器
|
||||
|
||||
### 6. 性能优化
|
||||
- **加载优化**: 代码分割、资源预加载、缓存策略
|
||||
- **运行优化**: 虚拟化、防抖节流、内存管理
|
||||
- **网络优化**: HTTP/2、CDN、资源压缩
|
||||
- **体验优化**: 骨架屏、加载动画、错误边界
|
||||
|
||||
## 🚀 部署与维护
|
||||
|
||||
### 7. 生产部署
|
||||
- **构建优化**: 生产构建、资源优化、环境配置
|
||||
- **部署策略**: 蓝绿部署、灰度发布、回滚机制
|
||||
- **监控系统**: 性能监控、错误追踪、用户行为
|
||||
- **安全防护**: HTTPS、CSP、依赖安全检查
|
||||
|
||||
### 8. 持续维护
|
||||
- **性能监控**: Core Web Vitals、用户体验指标
|
||||
- **错误处理**: 错误收集、分析处理、修复发布
|
||||
- **功能迭代**: 需求分析、功能开发、A/B测试
|
||||
- **技术升级**: 依赖更新、框架升级、重构优化
|
||||
</process>
|
||||
|
||||
<guideline>
|
||||
# 现代前端开发指导原则
|
||||
|
||||
## 🎨 用户体验优先
|
||||
- **性能至上**: 首屏加载时间 < 2秒，交互响应 < 100ms
|
||||
- **渐进增强**: 核心功能优先，增强功能渐进加载
|
||||
- **响应式设计**: 移动优先，多端适配，无缝体验
|
||||
- **可访问性**: 遵循WCAG 2.1标准，包容性设计
|
||||
|
||||
## 🏗️ 代码质量原则
|
||||
- **组件化思维**: 单一职责、高内聚低耦合、可复用性
|
||||
- **函数式编程**: 纯函数、不可变数据、函数组合
|
||||
- **类型安全**: TypeScript优先，严格类型检查
|
||||
- **测试驱动**: 先写测试，后写实现，测试覆盖率 > 80%
|
||||
|
||||
## ⚡ 现代化工程
|
||||
- **工具链自动化**: 构建、测试、部署全流程自动化
|
||||
- **模块化架构**: ES模块、动态导入、Tree Shaking
|
||||
- **版本管理**: 语义化版本、变更日志、发布管理
|
||||
- **文档先行**: API文档、组件文档、最佳实践
|
||||
|
||||
## 🔒 安全与性能
|
||||
- **安全编码**: 输入验证、XSS防护、CSRF保护
|
||||
- **性能预算**: Bundle大小限制、性能指标监控
|
||||
- **缓存策略**: 浏览器缓存、CDN缓存、应用缓存
|
||||
- **监控体系**: 实时监控、异常告警、用户反馈
|
||||
</guideline>
|
||||
|
||||
<rule>
|
||||
# 前端开发强制规则
|
||||
|
||||
## 📋 代码规范强制要求
|
||||
- **必须使用**: TypeScript + ESLint + Prettier 组合
|
||||
- **必须遵循**: 统一的命名规范和文件组织结构
|
||||
- **必须通过**: 所有代码审查和自动化检查
|
||||
- **必须达到**: 单元测试覆盖率 ≥ 80%，关键路径 100%
|
||||
|
||||
## 🔍 质量门禁要求
|
||||
- **必须满足**: Core Web Vitals 所有指标达到Good
|
||||
- **必须支持**: 主流浏览器最新3个版本
|
||||
- **必须通过**: 无障碍性检查（WCAG 2.1 AA级别）
|
||||
- **必须验证**: 移动端和桌面端完整功能
|
||||
|
||||
## 🛡️ 安全规则
|
||||
- **严禁暴露**: API密钥、敏感配置、用户隐私数据
|
||||
- **必须防护**: XSS、CSRF、点击劫持等Web安全漏洞
|
||||
- **必须启用**: Content Security Policy (CSP)
|
||||
- **必须验证**: 所有用户输入和第三方数据
|
||||
|
||||
## 📱 兼容性规则
|
||||
- **必须适配**: iOS Safari、Android Chrome、PC Chrome/Firefox
|
||||
- **必须处理**: 网络异常、加载失败、API错误
|
||||
- **必须提供**: 优雅降级和错误边界
|
||||
- **必须支持**: 离线访问核心功能（PWA）
|
||||
</rule>
|
||||
|
||||
<constraint>
|
||||
# 前端开发约束条件
|
||||
|
||||
## 🌐 技术环境约束
|
||||
- **浏览器兼容**: 现代浏览器 ES2020+ 特性支持
|
||||
- **设备适配**: 320px - 2560px 宽度范围全覆盖
|
||||
- **网络环境**: 3G网络下可用，2G网络核心功能可用
|
||||
- **性能预算**:
|
||||
- 首屏JS bundle < 200KB gzipped
|
||||
- 总资源大小 < 1MB
|
||||
- 首屏图片 < 500KB
|
||||
|
||||
## 🔧 开发工具约束
|
||||
- **Node.js版本**: >= 18.0.0 LTS版本
|
||||
- **包管理器**: 团队统一使用 pnpm 或 yarn
|
||||
- **构建工具**: Vite（开发）+ Rollup（生产）
|
||||
- **代码编辑器**: VS Code + 必要扩展插件
|
||||
|
||||
## 📊 性能约束指标
|
||||
- **Core Web Vitals**:
|
||||
- LCP (Largest Contentful Paint) ≤ 2.5s
|
||||
- FID (First Input Delay) ≤ 100ms
|
||||
- CLS (Cumulative Layout Shift) ≤ 0.1
|
||||
- **其他指标**:
|
||||
- FCP (First Contentful Paint) ≤ 1.8s
|
||||
- TTI (Time to Interactive) ≤ 3.8s
|
||||
|
||||
## 🔐 安全约束
|
||||
- **数据传输**: 生产环境强制HTTPS
|
||||
- **存储安全**: 敏感数据禁止localStorage存储
|
||||
- **依赖管理**: 禁用有安全漏洞的依赖包
|
||||
- **CSP策略**: 严格的内容安全策略配置
|
||||
</constraint>
|
||||
|
||||
<criteria>
|
||||
# 前端开发评估标准
|
||||
|
||||
## ✅ 功能完整性标准
|
||||
- **需求覆盖率**: 100% 实现PRD中所有功能点
|
||||
- **交互一致性**: UI交互与设计稿一致性 ≥ 98%
|
||||
- **数据完整性**: 正确处理所有数据状态（加载/成功/失败/空）
|
||||
- **路由功能**: 页面导航、浏览器历史、深度链接完全正常
|
||||
|
||||
## 🎨 用户体验标准
|
||||
- **视觉还原度**: 与设计稿像素级一致，误差 ≤ 2px
|
||||
- **响应式适配**: 所有目标设备完美显示，无布局破损
|
||||
- **动画流畅度**: 60fps流畅动画，无卡顿感知
|
||||
- **操作反馈**: 所有用户操作都有即时、清晰的视觉反馈
|
||||
|
||||
## ⚡ 性能质量标准
|
||||
- **Lighthouse评分**: Performance ≥ 95, Accessibility ≥ 95
|
||||
- **真实用户监控**: Core Web Vitals在75分位数达到Good
|
||||
- **资源加载**: 关键资源预加载，非关键资源懒加载
|
||||
- **缓存效率**: 静态资源缓存命中率 ≥ 90%
|
||||
|
||||
## 🧪 代码质量标准
|
||||
- **测试覆盖**:
|
||||
- 单元测试覆盖率 ≥ 80%
|
||||
- 关键业务逻辑覆盖率 = 100%
|
||||
- E2E测试覆盖主要用户流程
|
||||
- **代码质量**:
|
||||
- ESLint检查 0 error
|
||||
- TypeScript严格模式 0 error
|
||||
- 圈复杂度 ≤ 10
|
||||
- **文档完整**: 所有公共API和组件都有完整文档
|
||||
|
||||
## 🔒 安全质量标准
|
||||
- **安全扫描**: 通过OWASP安全检查，无高危漏洞
|
||||
- **依赖安全**: 所有依赖包无已知安全漏洞
|
||||
- **隐私保护**: 符合GDPR等隐私保护法规
|
||||
- **数据安全**: 敏感数据传输加密，存储脱敏
|
||||
|
||||
## 🌍 兼容性与可维护性标准
|
||||
- **浏览器兼容**: 目标浏览器100%功能正常
|
||||
- **设备兼容**: 各种屏幕尺寸和分辨率完美适配
|
||||
- **网络适应**: 各种网络条件下基本可用
|
||||
- **代码可维护**: 新功能开发效率，bug修复速度符合预期
|
||||
</criteria>
|
||||
</execution>
|
||||
@ -0,0 +1,146 @@
|
||||
<execution>
|
||||
<constraint>
|
||||
# 技术架构客观约束
|
||||
|
||||
## 🌐 浏览器环境约束
|
||||
- **执行环境**: 单线程JavaScript引擎，异步非阻塞模式
|
||||
- **内存限制**: 浏览器内存上限，避免内存泄漏和过度消耗
|
||||
- **安全沙箱**: 同源策略、CSP限制、CORS跨域约束
|
||||
- **API兼容性**: 浏览器API支持差异，需要优雅降级
|
||||
|
||||
## 📱 设备性能约束
|
||||
- **计算能力**: 移动设备CPU/GPU性能限制
|
||||
- **网络环境**: 移动网络带宽不稳定，延迟较高
|
||||
- **存储空间**: 本地存储容量限制（localStorage, indexedDB）
|
||||
- **电池续航**: 高计算消耗影响设备续航
|
||||
|
||||
## 🔧 技术生态约束
|
||||
- **框架生命周期**: 技术栈更新频率和兼容性变化
|
||||
- **构建工具限制**: 打包工具的配置复杂度和性能瓶颈
|
||||
- **依赖管理**: 第三方库的安全性、维护状态、版本冲突
|
||||
- **部署环境**: CDN、服务器、容器化平台的技术限制
|
||||
</constraint>
|
||||
|
||||
<rule>
|
||||
# 技术架构强制规则
|
||||
|
||||
## 🏗️ 架构设计规则
|
||||
- **模块化强制要求**: 必须采用模块化设计，避免代码耦合
|
||||
- **组件化原则**: 必须基于组件化思维构建UI，单一职责
|
||||
- **状态管理规范**: 必须明确状态管理边界，避免状态混乱
|
||||
- **API接口规范**: 必须统一API调用方式和错误处理机制
|
||||
|
||||
## 🔒 安全架构规则
|
||||
- **输入验证**: 必须对所有用户输入进行严格验证和转义
|
||||
- **权限控制**: 必须实现前端路由和组件级别的权限控制
|
||||
- **敏感数据**: 禁止在前端存储敏感信息（密码、token等）
|
||||
- **依赖安全**: 必须定期检查和更新有安全漏洞的依赖包
|
||||
|
||||
## ⚡ 性能架构规则
|
||||
- **代码分割**: 必须实现路由和组件级别的代码分割
|
||||
- **资源优化**: 必须压缩和优化静态资源（JS、CSS、图片）
|
||||
- **缓存策略**: 必须实现合理的浏览器和CDN缓存策略
|
||||
- **打包大小**: 单个chunk不得超过200KB，总体积控制在合理范围
|
||||
</rule>
|
||||
|
||||
<guideline>
|
||||
# 技术架构指导原则
|
||||
|
||||
## 🎯 设计原则指导
|
||||
- **渐进增强**: 建议基础功能优先，高级功能渐进增强
|
||||
- **响应式优先**: 推荐移动优先的响应式设计策略
|
||||
- **可访问性**: 建议从设计阶段就考虑无障碍访问需求
|
||||
- **国际化准备**: 推荐预留国际化扩展的架构空间
|
||||
|
||||
## 🔧 技术选型指导
|
||||
- **主流框架**: 建议选择成熟稳定的主流框架（React/Vue/Angular）
|
||||
- **构建工具**: 推荐现代化构建工具（Vite优于Webpack）
|
||||
- **状态管理**: 建议根据项目复杂度选择合适的状态管理方案
|
||||
- **UI组件库**: 推荐使用成熟的组件库作为基础，定制化开发
|
||||
|
||||
## 📈 可扩展性指导
|
||||
- **微前端**: 大型项目建议考虑微前端架构
|
||||
- **插件系统**: 推荐设计插件化架构支持功能扩展
|
||||
- **API抽象**: 建议抽象API层便于后端服务替换
|
||||
- **配置化**: 推荐重要功能支持配置化，减少代码修改
|
||||
</guideline>
|
||||
|
||||
<process>
|
||||
# 技术架构设计流程
|
||||
|
||||
## 🎯 架构规划阶段
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[需求分析] --> B[技术调研]
|
||||
B --> C[架构设计]
|
||||
C --> D[技术选型]
|
||||
D --> E[原型验证]
|
||||
E --> F[架构评审]
|
||||
F --> G{是否通过?}
|
||||
G -->|是| H[实施开发]
|
||||
G -->|否| C
|
||||
```
|
||||
|
||||
### 1. 需求分析与技术调研
|
||||
- **功能需求梳理**: 明确核心功能、扩展功能、性能要求
|
||||
- **非功能需求**: 性能指标、安全要求、兼容性标准
|
||||
- **技术环境**: 目标浏览器、设备类型、部署环境
|
||||
- **团队技能**: 评估团队技术能力和学习成本
|
||||
|
||||
### 2. 架构设计与技术选型
|
||||
- **整体架构**: 确定应用架构模式（SPA/MPA/SSR等）
|
||||
- **技术栈选择**: 框架、构建工具、状态管理、UI库
|
||||
- **目录结构**: 设计清晰的文件组织结构
|
||||
- **开发规范**: 制定代码规范、Git工作流、部署流程
|
||||
|
||||
## 🏗️ 架构实施阶段
|
||||
|
||||
### 3. 基础环境搭建
|
||||
- **项目初始化**: 创建项目骨架，配置开发环境
|
||||
- **构建配置**: 配置打包工具、代码检查、自动化流程
|
||||
- **基础组件**: 开发通用组件、工具函数、样式系统
|
||||
- **API层封装**: 封装HTTP客户端、错误处理、数据转换
|
||||
|
||||
### 4. 核心功能开发
|
||||
- **路由系统**: 实现页面路由、权限控制、懒加载
|
||||
- **状态管理**: 建立全局状态、数据流管理
|
||||
- **业务组件**: 开发核心业务功能组件
|
||||
- **集成测试**: 确保各模块协同工作正常
|
||||
|
||||
## 🔍 架构优化阶段
|
||||
|
||||
### 5. 性能优化与监控
|
||||
- **性能分析**: 使用工具分析性能瓶颈
|
||||
- **代码优化**: 优化关键路径代码和资源加载
|
||||
- **监控体系**: 建立性能监控和错误追踪
|
||||
- **持续改进**: 基于监控数据持续优化架构
|
||||
</process>
|
||||
|
||||
<criteria>
|
||||
# 技术架构评估标准
|
||||
|
||||
## ✅ 架构质量标准
|
||||
- **可维护性**: 代码结构清晰，易于理解和修改
|
||||
- **可扩展性**: 支持功能扩展，架构弹性良好
|
||||
- **可测试性**: 组件解耦，便于单元测试和集成测试
|
||||
- **可复用性**: 组件和工具函数具有良好的复用性
|
||||
|
||||
## ⚡ 性能质量标准
|
||||
- **加载性能**: 首屏加载时间 ≤ 2秒，页面切换 ≤ 500ms
|
||||
- **运行性能**: 60fps流畅交互，内存使用稳定
|
||||
- **网络优化**: 资源压缩率 ≥ 70%，HTTP请求数量合理
|
||||
- **缓存效率**: 静态资源缓存命中率 ≥ 90%
|
||||
|
||||
## 🔒 安全质量标准
|
||||
- **输入安全**: 所有用户输入都经过验证和转义
|
||||
- **权限安全**: 前端路由和API调用都有权限控制
|
||||
- **数据安全**: 敏感数据不在前端存储，传输加密
|
||||
- **依赖安全**: 无已知安全漏洞的第三方依赖
|
||||
|
||||
## 🌍 兼容性标准
|
||||
- **浏览器兼容**: 目标浏览器100%功能正常
|
||||
- **设备适配**: 各种屏幕尺寸和分辨率完美显示
|
||||
- **网络适应**: 弱网环境下基本功能可用
|
||||
- **降级支持**: 不支持的功能有优雅降级方案
|
||||
</criteria>
|
||||
</execution>
|
||||
@ -0,0 +1,147 @@
|
||||
<execution>
|
||||
<constraint>
|
||||
# 用户体验客观约束
|
||||
|
||||
## 👥 用户群体约束
|
||||
- **能力差异**: 用户技术水平、学习能力、操作熟练度差异巨大
|
||||
- **设备多样性**: 不同屏幕尺寸、分辨率、输入方式的设备差异
|
||||
- **环境限制**: 网络环境、使用场景、干扰因素的不可控性
|
||||
- **无障碍需求**: 视觉、听觉、运动能力障碍用户的特殊需求
|
||||
|
||||
## 🌍 技术环境约束
|
||||
- **浏览器差异**: 不同浏览器的渲染引擎和API支持差异
|
||||
- **性能限制**: 低端设备的计算能力和内存限制
|
||||
- **网络条件**: 带宽限制、延迟波动、不稳定连接
|
||||
- **系统集成**: 与操作系统、其他应用的集成限制
|
||||
</constraint>
|
||||
|
||||
<rule>
|
||||
# 用户体验强制规则
|
||||
|
||||
## 🎯 可访问性强制要求
|
||||
- **WCAG 2.1 AA级别**: 必须符合Web内容可访问性指南AA级别
|
||||
- **键盘导航**: 所有功能必须支持键盘操作，无鼠标依赖
|
||||
- **屏幕阅读器**: 必须为视障用户提供完整的屏幕阅读器支持
|
||||
- **对比度要求**: 文本对比度必须达到4.5:1，大文本3:1
|
||||
|
||||
## ⚡ 性能用户感知规则
|
||||
- **首屏时间**: 首屏内容必须在2秒内显示
|
||||
- **交互响应**: 用户操作反馈必须在100ms内响应
|
||||
- **页面切换**: 页面或路由切换必须在500ms内完成
|
||||
- **滚动流畅**: 滚动必须保持60fps，无卡顿感知
|
||||
|
||||
## 📱 响应式设计规则
|
||||
- **移动优先**: 必须采用移动优先的设计和开发策略
|
||||
- **断点适配**: 必须在320px-2560px范围内完美适配
|
||||
- **触摸友好**: 触摸目标最小44px×44px，间距足够
|
||||
- **内容优先**: 核心内容在任何设备上都必须可访问
|
||||
</rule>
|
||||
|
||||
<guideline>
|
||||
# 用户体验指导原则
|
||||
|
||||
## 🎨 设计系统指导
|
||||
- **一致性原则**: 建议建立统一的设计语言和交互模式
|
||||
- **简洁性原则**: 推荐简化界面，减少认知负担
|
||||
- **反馈性原则**: 建议为每个用户操作提供明确反馈
|
||||
- **容错性原则**: 推荐设计容错机制，减少用户错误成本
|
||||
|
||||
## 🔄 交互设计指导
|
||||
- **渐进披露**: 建议根据用户需求层次渐进展示信息
|
||||
- **操作效率**: 推荐为熟练用户提供快捷操作方式
|
||||
- **上下文感知**: 建议根据用户当前状态提供相关功能
|
||||
- **个性化**: 推荐支持用户自定义偏好设置
|
||||
|
||||
## 🚀 性能体验指导
|
||||
- **感知性能**: 建议优化用户感知的加载速度
|
||||
- **渐进加载**: 推荐采用骨架屏、懒加载等技术
|
||||
- **缓存策略**: 建议合理使用缓存提升重复访问体验
|
||||
- **离线支持**: 推荐为核心功能提供离线访问能力
|
||||
</guideline>
|
||||
|
||||
<process>
|
||||
# 用户体验设计与实现流程
|
||||
|
||||
## 🔍 用户研究阶段
|
||||
|
||||
### 1. 用户调研与分析
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[用户访谈] --> B[行为观察]
|
||||
B --> C[数据分析]
|
||||
C --> D[画像构建]
|
||||
D --> E[需求洞察]
|
||||
```
|
||||
|
||||
- **目标用户识别**: 明确核心用户群体和使用场景
|
||||
- **用户行为分析**: 观察真实使用行为和痛点
|
||||
- **需求优先级**: 区分核心需求和边缘需求
|
||||
- **竞品分析**: 分析同类产品的UX优劣势
|
||||
|
||||
## 🎨 设计实现阶段
|
||||
|
||||
### 2. 交互设计与原型
|
||||
- **信息架构**: 设计清晰的信息组织结构
|
||||
- **交互流程**: 设计用户操作的完整流程
|
||||
- **界面布局**: 设计响应式界面布局方案
|
||||
- **原型测试**: 验证设计方案的可用性
|
||||
|
||||
### 3. 视觉设计与规范
|
||||
- **设计系统**: 建立完整的设计系统和组件库
|
||||
- **视觉风格**: 确定符合品牌的视觉风格
|
||||
- **适配方案**: 设计多端适配的视觉方案
|
||||
- **无障碍设计**: 确保设计符合可访问性要求
|
||||
|
||||
## 💻 开发实现阶段
|
||||
|
||||
### 4. 前端实现与优化
|
||||
- **组件开发**: 基于设计系统开发可复用组件
|
||||
- **交互实现**: 实现流畅的交互动画和反馈
|
||||
- **性能优化**: 优化加载速度和运行性能
|
||||
- **兼容性处理**: 处理浏览器和设备兼容性问题
|
||||
|
||||
## 🧪 测试验证阶段
|
||||
|
||||
### 5. 用户体验测试
|
||||
- **可用性测试**: 验证设计的易用性和效率
|
||||
- **A/B测试**: 对比不同方案的用户反馈
|
||||
- **无障碍测试**: 验证可访问性实现效果
|
||||
- **性能测试**: 验证真实环境下的性能表现
|
||||
</process>
|
||||
|
||||
<criteria>
|
||||
# 用户体验评估标准
|
||||
|
||||
## 👨💼 用户满意度标准
|
||||
- **易用性得分**: 用户任务完成率 ≥ 95%，错误率 ≤ 5%
|
||||
- **效率指标**: 核心任务完成时间符合预期目标
|
||||
- **满意度评分**: 用户满意度评分 ≥ 4.0/5.0
|
||||
- **推荐意愿**: 净推荐值(NPS) ≥ 50
|
||||
|
||||
## ⚡ 性能体验标准
|
||||
- **Core Web Vitals**:
|
||||
- LCP (最大内容绘制) ≤ 2.5秒
|
||||
- FID (首次输入延迟) ≤ 100毫秒
|
||||
- CLS (累积布局偏移) ≤ 0.1
|
||||
- **交互响应**: 界面操作响应时间 ≤ 100ms
|
||||
- **页面切换**: 路由切换时间 ≤ 500ms
|
||||
|
||||
## ♿ 可访问性标准
|
||||
- **WCAG合规**: 100%符合WCAG 2.1 AA级别要求
|
||||
- **键盘操作**: 所有功能都支持键盘导航
|
||||
- **屏幕阅读器**: 完整支持主流屏幕阅读器
|
||||
- **颜色对比**: 文本对比度符合最低要求
|
||||
|
||||
## 📱 响应式适配标准
|
||||
- **设备兼容**: 在目标设备上100%功能正常
|
||||
- **布局适配**: 在所有断点下布局美观实用
|
||||
- **触摸操作**: 移动端操作便捷，无误触
|
||||
- **性能一致**: 各设备上性能表现稳定
|
||||
|
||||
## 🎯 业务价值标准
|
||||
- **转化率**: 关键业务流程转化率达到预期
|
||||
- **留存率**: 用户留存率和活跃度指标良好
|
||||
- **支持成本**: 用户支持请求数量减少
|
||||
- **品牌价值**: 提升品牌形象和用户忠诚度
|
||||
</criteria>
|
||||
</execution>
|
||||
Reference in New Issue
Block a user