@zeyue0329/xiaoma-cli 1.0.49 → 6.0.0-alpha.14

package/xiaoma-core/templates/architecture-tmpl.yaml

@@ -1,650 +0,0 @@
-template:
-  id: architecture-template-v2
-  name: 架构文档
-  version: 2.0
-  output:
-    format: markdown
-    filename: docs/architecture.md
-    title: "{{project_name}} Architecture Document"
-
-workflow:
-  mode: interactive
-  elicitation: advanced-elicitation
-
-sections:
-  - id: introduction
-    title: 引言
-    instruction: |
-      如果可以，请在开始前审查所有提供的相关文档以收集全部背景信息。如果至少无法找到 docs/prd.md，请询问用户哪些文档将为架构设计提供基础。
-    sections:
-      - id: intro-content
-        content: |
-          本文档概述了 {{project_name}} 的整体项目架构，包括后端系统、共享服务以及非 UI 特定的问题。其主要目标是作为 AI 驱动开发的指导性架构蓝图，确保遵循所选模式和技术的一致性。
-
-          **与前端架构的关系：**
-          如果项目包含重要的用户界面，将有一份独立的前端架构文档详细说明前端特定的设计，并且该文档必须与本文档结合使用。本文档中记录的核心技术栈选择（见“技术栈”）对整个项目（包括任何前端组件）具有决定性作用。
-      - id: starter-template
-        title: 启动模板或现有项目
-        instruction: |
-          在进一步进行架构设计之前，请检查项目是否基于启动模板或现有代码库：
-
-          1. 审查 PRD 和头脑风暴简报中是否提及：
-          - 启动模板（例如，Create React App, Next.js, Vue CLI, Angular CLI 等）
-          - 作为基础的现有项目或代码库
-          - 脚手架项目或工具
-          - 需要克隆或改造的先前项目
-
-          2. 如果提及了启动模板或现有项目：
-          - 要求用户通过以下方式之一提供访问权限：
-            - 启动模板文档的链接
-            - 上传/附加项目文件（适用于小型项目）
-            - 分享项目仓库的链接（GitHub, GitLab 等）
-          - 分析启动模板/现有项目以了解：
-            - 预配置的技术栈和版本
-            - 项目结构和组织模式
-            - 内置脚本和工具
-            - 现有的架构模式和约定
-            - 启动模板带来的任何限制或约束
-          - 利用此分析来指导和调整您的架构决策
-
-          3. 如果没有提及启动模板但这是一个全新的项目：
-          - 根据技术栈偏好建议合适的启动模板
-          - 解释其好处（更快的设置、最佳实践、社区支持）
-          - 让用户决定是否使用
-
-          4. 如果用户确认不使用启动模板：
-          - 从头开始进行架构设计
-          - 注意所有工具和配置都需要手动设置
-
-          在继续进行架构设计之前，在此处记录决策。如果没有，则填写“不适用”。
-        elicit: true
-      - id: changelog
-        title: 变更日志
-        type: table
-        columns: [日期, 版本, 描述, 作者]
-        instruction: 跟踪文档版本和变更
-
-  - id: high-level-architecture
-    title: 高层架构
-    instruction: |
-      本节包含多个为架构奠定基础的子章节。请一次性呈现所有子章节。
-    elicit: true
-    sections:
-      - id: technical-summary
-        title: 技术摘要
-        instruction: |
-          提供一段简短的概述（3-5句话），内容包括：
-          - 系统的整体架构风格
-          - 关键组件及其关系
-          - 主要的技术选择
-          - 使用的核心架构模式
-          - 回顾 PRD 目标以及此架构如何支持这些目标
-      - id: high-level-overview
-        title: 高层概览
-        instruction: |
-          根据 PRD 的技术假设部分，描述：
-
-          1. 主要的架构风格（例如，单体、微服务、无服务器、事件驱动）
-          2. PRD 中决定的仓库结构（Monorepo/Polyrepo）
-          3. PRD 中决定的服务架构
-          4. 概念层面上的主要用户交互流程或数据流
-          5. 关键的架构决策及其理由
-      - id: project-diagram
-        title: 高层项目图
-        type: mermaid
-        mermaid_type: graph
-        instruction: |
-          创建一个 Mermaid 图，以可视化高层架构。考虑：
-          - 系统边界
-          - 主要组件/服务
-          - 数据流方向
-          - 外部集成
-          - 用户入口点
-
-      - id: architectural-patterns
-        title: 架构与设计模式
-        instruction: |
-          列出将指导架构的关键高层模式。对于每个模式：
-
-          1. 如果存在多个选项，请提出 2-3 个可行的方案
-          2. 提出您的建议并附上明确的理由
-          3. 在最终确定前获得用户确认
-          4. 这些模式应与 PRD 的技术假设和项目目标保持一致
-
-          需要考虑的常见模式：
-          - 架构风格模式（无服务器、事件驱动、微服务、CQRS、六边形架构）
-          - 代码组织模式（依赖注入、仓库、模块、工厂）
-          - 数据模式（事件溯源、Saga、每个服务一个数据库）
-          - 通信模式（REST, GraphQL, 消息队列, 发布/订阅）
-        template: "- **{{pattern_name}}:** {{pattern_description}} - _理由：_ {{rationale}}"
-        examples:
-          - "**无服务器架构：** 使用 AWS Lambda 进行计算 - _理由：_ 符合 PRD 中关于成本优化和自动扩展的要求"
-          - "**仓库模式：** 抽象数据访问逻辑 - _理由：_ 便于测试和未来的数据库迁移"
-          - "**事件驱动通信：** 使用 SNS/SQS 进行服务解耦 - _理由：_ 支持异步处理和系统弹性"
-
-  - id: tech-stack
-    title: 技术栈
-    instruction: |
-      这是决定性的技术选型部分。与用户合作做出具体选择：
-
-      1. 审查 PRD 技术假设以及来自 {root}/data/technical-preferences.yaml 或附加的 technical-preferences 文件中的任何偏好
-      2. 为每个类别提供 2-3 个带有优缺点的可行选项
-      3. 根据项目需求提出明确的建议
-      4. 为每个选型获得用户明确的批准
-      5. 记录确切的版本（避免使用 "latest" - 请锁定具体版本）
-      6. 此表格是唯一的信息源 - 所有其他文档必须引用这些选择
-
-      需要最终确定的关键决策 - 在显示表格之前，确保您了解或询问用户以下信息 - 如果用户不确定，告知他们您也可以提供带有理由的建议：
-
-      - 启动模板（如果有）
-      - 语言和运行时的确切版本
-      - 框架、库和包
-      - 云服务提供商和关键服务选择
-      - 数据库和存储解决方案 - 如果不清楚，根据项目和云服务提供商建议 sql、nosql 或其他类型
-      - 开发工具
-
-      渲染表格时，确保用户意识到本节选择的重要性，并应检查是否存在差距或分歧，如果不清楚列表中某项的原因，请要求澄清，并立即征求反馈 - 该声明和选项应在允许用户输入之前全部渲染和提示。
-    elicit: true
-    sections:
-      - id: cloud-infrastructure
-        title: 云基础设施
-        template: |
-          - **提供商：** {{cloud_provider}}
-          - **关键服务：** {{core_services_list}}
-          - **部署区域：** {{regions}}
-      - id: technology-stack-table
-        title: 技术栈表
-        type: table
-        columns: [类别, 技术, 版本, 用途, 理由]
-        instruction: 使用所有相关技术填充技术栈表
-        examples:
-          - "| **语言** | TypeScript | 5.3.3 | 主要开发语言 | 强类型，优秀的工具链，团队专业知识 |"
-          - "| **运行时** | Node.js | 20.11.0 | JavaScript 运行时 | LTS 版本，性能稳定，生态系统广泛 |"
-          - "| **框架** | NestJS | 10.3.2 | 后端框架 | 企业级，良好的依赖注入，符合团队模式 |"
-
-  - id: data-models
-    title: 数据模型
-    instruction: |
-      定义核心数据模型/实体：
-
-      1. 审查 PRD 需求并识别关键业务实体
-      2. 对每个模型，解释其用途和关系
-      3. 包括关键属性和数据类型
-      4. 显示模型之间的关系
-      5. 与用户讨论设计决策
-
-      在转向数据库模式之前，创建一个清晰的概念模型。
-    elicit: true
-    repeatable: true
-    sections:
-      - id: model
-        title: "{{model_name}}"
-        template: |
-          **用途：** {{model_purpose}}
-
-          **关键属性：**
-          - {{attribute_1}}: {{type_1}} - {{description_1}}
-          - {{attribute_2}}: {{type_2}} - {{description_2}}
-
-          **关系：**
-          - {{relationship_1}}
-          - {{relationship_2}}
-
-  - id: components
-    title: 组件
-    instruction: |
-      基于上述的架构模式、技术栈和数据模型：
-
-      1. 识别主要的逻辑组件/服务及其职责
-      2. 考虑 PRD 中定义的仓库结构 (monorepo/polyrepo)
-      3. 定义组件之间清晰的边界和接口
-      4. 对每个组件，明确：
-      - 主要职责
-      - 暴露的关键接口/API
-      - 对其他组件的依赖
-      - 基于技术栈选择的技术细节
-
-      5. 在需要时创建组件图
-    elicit: true
-    sections:
-      - id: component-list
-        repeatable: true
-        title: "{{component_name}}"
-        template: |
-          **职责：** {{component_description}}
-
-          **关键接口：**
-          - {{interface_1}}
-          - {{interface_2}}
-
-          **依赖：** {{dependencies}}
-
-          **技术栈：** {{component_tech_details}}
-      - id: component-diagrams
-        title: 组件图
-        type: mermaid
-        instruction: |
-          创建 Mermaid 图来可视化组件关系。选项：
-          - C4 容器图用于高层视图
-          - 组件图用于详细的内部结构
-          - 序列图用于复杂的交互
-          选择最合适的图以保证清晰度
-
-  - id: external-apis
-    title: 外部 API
-    condition: 项目需要外部 API 集成
-    instruction: |
-      对于每个外部服务集成：
-
-      1. 根据 PRD 需求和组件设计识别所需的 API
-      2. 如果文档 URL 未知，向用户询问具体信息
-      3. 记录认证方法和安全考量
-      4. 列出将要使用的具体端点
-      5. 注意任何速率限制或使用约束
-
-      如果不需要外部 API，请明确说明并跳到下一节。
-    elicit: true
-    repeatable: true
-    sections:
-      - id: api
-        title: "{{api_name}} API"
-        template: |
-          - **用途：** {{api_purpose}}
-          - **文档：** {{api_docs_url}}
-          - **基础 URL：** {{api_base_url}}
-          - **认证：** {{auth_method}}
-          - **速率限制：** {{rate_limits}}
-
-          **使用的关键端点：**
-          - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
-
-          **集成说明：** {{integration_considerations}}
-
-  - id: core-workflows
-    title: 核心工作流
-    type: mermaid
-    mermaid_type: sequence
-    instruction: |
-      使用序列图说明关键系统工作流：
-
-      1. 从 PRD 中识别关键用户旅程
-      2. 显示组件交互，包括外部 API
-      3. 包括错误处理路径
-      4. 记录异步操作
-      5. 根据需要创建高层和详细的图表
-
-      重点关注那些能阐明架构决策或复杂交互的工作流。
-    elicit: true
-
-  - id: rest-api-spec
-    title: REST API 规范
-    condition: 项目包含 REST API
-    type: code
-    language: yaml
-    instruction: |
-      如果项目包含 REST API：
-
-      1. 创建一个 OpenAPI 3.0 规范
-      2. 包括来自 epics/stories 的所有端点
-      3. 基于数据模型定义请求/响应模式
-      4. 记录认证要求
-      5. 包括请求/响应示例
-
-      使用 YAML 格式以获得更好的可读性。如果没有 REST API，请跳过此节。
-    elicit: true
-    template: |
-      openapi: 3.0.0
-      info:
-        title: {{api_title}}
-        version: {{api_version}}
-        description: {{api_description}}
-      servers:
-        - url: {{server_url}}
-          description: {{server_description}}
-
-  - id: database-schema
-    title: 数据库模式
-    instruction: |
-      将概念数据模型转换为具体的数据库模式：
-
-      1. 使用在技术栈中选择的数据库类型
-      2. 使用适当的表示法创建模式定义
-      3. 包括索引、约束和关系
-      4. 考虑性能和可伸缩性
-      5. 对于 NoSQL，显示文档结构
-
-      以适合数据库类型的格式呈现模式（SQL DDL, JSON schema 等）。
-    elicit: true
-
-  - id: source-tree
-    title: 源码树
-    type: code
-    language: plaintext
-    instruction: |
-      创建一个能反映以下内容的项目文件夹结构：
-
-      1. 选择的仓库结构 (monorepo/polyrepo)
-      2. 服务架构 (monolith/microservices/serverless)
-      3. 选择的技术栈和语言
-      4. 上述的组件组织方式
-      5. 所选框架的最佳实践
-      6. 清晰的关注点分离
-
-      根据项目需求调整结构。对于 monorepo，显示服务分离。对于 serverless，显示函数组织。包括特定于语言的约定。
-    elicit: true
-    examples:
-      - |
-        project-root/
-        ├── packages/
-        │   ├── api/                    # 后端 API 服务
-        │   ├── web/                    # 前端应用
-        │   ├── shared/                 # 共享工具/类型
-        │   └── infrastructure/         # IaC 定义
-        ├── scripts/                    # Monorepo 管理脚本
-        └── package.json                # 带有 workspaces 的根 package.json
-
-  - id: infrastructure-deployment
-    title: 基础设施与部署
-    instruction: |
-      定义部署架构和实践：
-
-      1. 使用在技术栈中选择的 IaC 工具
-      2. 选择适合架构的部署策略
-      3. 定义环境和晋升流程
-      4. 建立回滚程序
-      5. 考虑安全性、监控和成本优化
-
-      获取用户关于部署偏好和 CI/CD 工具选择的输入。
-    elicit: true
-    sections:
-      - id: infrastructure-as-code
-        title: 基础设施即代码 (Infrastructure as Code)
-        template: |
-          - **工具：** {{iac_tool}} {{version}}
-          - **位置：** `{{iac_directory}}`
-          - **方法：** {{iac_approach}}
-      - id: deployment-strategy
-        title: 部署策略
-        template: |
-          - **策略：** {{deployment_strategy}}
-          - **CI/CD 平台：** {{cicd_platform}}
-          - **流水线配置：** `{{pipeline_config_location}}`
-      - id: environments
-        title: 环境
-        repeatable: true
-        template: "- **{{env_name}}:** {{env_purpose}} - {{env_details}}"
-      - id: promotion-flow
-        title: 环境晋升流程
-        type: code
-        language: text
-        template: "{{promotion_flow_diagram}}"
-      - id: rollback-strategy
-        title: 回滚策略
-        template: |
-          - **主要方法：** {{rollback_method}}
-          - **触发条件：** {{rollback_triggers}}
-          - **恢复时间目标 (RTO)：** {{rto}}
-
-  - id: error-handling-strategy
-    title: 错误处理策略
-    instruction: |
-      定义全面的错误处理方法：
-
-      1. 为技术栈中的语言/框架选择合适的模式
-      2. 定义日志记录标准和工具
-      3. 建立错误类别和处理规则
-      4. 考虑可观察性和调试需求
-      5. 确保安全性（日志中不含敏感数据）
-
-      本节将指导 AI 和人类开发者实现一致的错误处理。
-    elicit: true
-    sections:
-      - id: general-approach
-        title: 通用方法
-        template: |
-          - **错误模型：** {{error_model}}
-          - **异常层次结构：** {{exception_structure}}
-          - **错误传播：** {{propagation_rules}}
-      - id: logging-standards
-        title: 日志记录标准
-        template: |
-          - **库：** {{logging_library}} {{version}}
-          - **格式：** {{log_format}}
-          - **级别：** {{log_levels_definition}}
-          - **必需的上下文：**
-            - 关联 ID: {{correlation_id_format}}
-            - 服务上下文: {{service_context}}
-            - 用户上下文: {{user_context_rules}}
-      - id: error-patterns
-        title: 错误处理模式
-        sections:
-          - id: external-api-errors
-            title: 外部 API 错误
-            template: |
-              - **重试策略：** {{retry_strategy}}
-              - **断路器：** {{circuit_breaker_config}}
-              - **超时配置：** {{timeout_settings}}
-              - **错误转换：** {{error_mapping_rules}}
-          - id: business-logic-errors
-            title: 业务逻辑错误
-            template: |
-              - **自定义异常：** {{business_exception_types}}
-              - **面向用户的错误：** {{user_error_format}}
-              - **错误码：** {{error_code_system}}
-          - id: data-consistency
-            title: 数据一致性
-            template: |
-              - **事务策略：** {{transaction_approach}}
-              - **补偿逻辑：** {{compensation_patterns}}
-              - **幂等性：** {{idempotency_approach}}
-
-  - id: coding-standards
-    title: 编码标准
-    instruction: |
-      这些标准对 AI 代理是强制性的。与用户合作，仅定义防止劣质代码所需的关键规则。解释说：
-
-      1. 本节直接控制 AI 开发者的行为
-      2. 保持最简化 - 假设 AI 了解通用的最佳实践
-      3. 专注于项目特定的约定和陷阱
-      4. 过度详细的标准会膨胀上下文并减慢开发速度
-      5. 标准将被提取到单独的文件中供开发代理使用
-
-      对于每个标准，都要获得用户明确确认其必要性。
-    elicit: true
-    sections:
-      - id: core-standards
-        title: 核心标准
-        template: |
-          - **语言与运行时：** {{languages_and_versions}}
-          - **风格与检查 (Linting)：** {{linter_config}}
-          - **测试组织：** {{test_file_convention}}
-      - id: naming-conventions
-        title: 命名约定
-        type: table
-        columns: [元素, 约定, 示例]
-        instruction: 仅在偏离语言默认约定时包含此部分
-      - id: critical-rules
-        title: 关键规则
-        instruction: |
-          仅列出 AI 可能违反的规则或项目特定的要求。例如：
-          - "切勿在生产代码中使用 console.log - 请使用 logger"
-          - "所有 API 响应必须使用 ApiResponse 包装类型"
-          - "数据库查询必须使用仓库模式，切勿直接使用 ORM"
-
-          避免使用显而易见的规则，如“使用 SOLID 原则”或“编写清晰的代码”。
-        repeatable: true
-        template: "- **{{rule_name}}:** {{rule_description}}"
-      - id: language-specifics
-        title: 特定语言指南
-        condition: 需要关键的特定语言规则
-        instruction: 仅在对于防止 AI 错误至关重要时添加。大多数团队不需要此部分。
-        sections:
-          - id: language-rules
-            title: "{{language_name}} 特定规则"
-            repeatable: true
-            template: "- **{{rule_topic}}:** {{rule_detail}}"
-
-  - id: test-strategy
-    title: 测试策略与标准
-    instruction: |
-      与用户合作定义全面的测试策略：
-
-      1. 使用技术栈中的测试框架
-      2. 决定采用 TDD 还是后测试方法
-      3. 定义测试的组织和命名
-      4. 建立覆盖率目标
-      5. 确定集成测试基础设施
-      6. 规划测试数据和外部依赖
-
-      注意：基本信息会放在编码标准中供开发代理使用。这个详细的部分供 QA 代理和团队参考。
-    elicit: true
-    sections:
-      - id: testing-philosophy
-        title: 测试理念
-        template: |
-          - **方法：** {{test_approach}}
-          - **覆盖率目标：** {{coverage_targets}}
-          - **测试金字塔：** {{test_distribution}}
-      - id: test-types
-        title: 测试类型与组织
-        sections:
-          - id: unit-tests
-            title: 单元测试
-            template: |
-              - **框架：** {{unit_test_framework}} {{version}}
-              - **文件约定：** {{unit_test_naming}}
-              - **位置：** {{unit_test_location}}
-              - **模拟库 (Mocking Library)：** {{mocking_library}}
-              - **覆盖率要求：** {{unit_coverage}}
-
-              **AI 代理要求：**
-              - 为所有公共方法生成测试
-              - 覆盖边缘情况和错误条件
-              - 遵循 AAA 模式（Arrange, Act, Assert）
-              - 模拟所有外部依赖
-          - id: integration-tests
-            title: 集成测试
-            template: |
-              - **范围：** {{integration_scope}}
-              - **位置：** {{integration_test_location}}
-              - **测试基础设施：**
-                - **{{dependency_name}}:** {{test_approach}} ({{test_tool}})
-            examples:
-              - "**数据库：** 单元测试使用内存 H2，集成测试使用 Testcontainers PostgreSQL"
-              - "**消息队列：** 测试使用内嵌 Kafka"
-              - "**外部 API：** 使用 WireMock 进行打桩"
-          - id: e2e-tests
-            title: 端到端测试
-            template: |
-              - **框架：** {{e2e_framework}} {{version}}
-              - **范围：** {{e2e_scope}}
-              - **环境：** {{e2e_environment}}
-              - **测试数据：** {{e2e_data_strategy}}
-      - id: test-data-management
-        title: 测试数据管理
-        template: |
-          - **策略：** {{test_data_approach}}
-          - **固定数据 (Fixtures)：** {{fixture_location}}
-          - **工厂 (Factories)：** {{factory_pattern}}
-          - **清理：** {{cleanup_strategy}}
-      - id: continuous-testing
-        title: 持续测试
-        template: |
-          - **CI 集成：** {{ci_test_stages}}
-          - **性能测试：** {{perf_test_approach}}
-          - **安全测试：** {{security_test_approach}}
-
-  - id: security
-    title: 安全
-    instruction: |
-      为 AI 和人类开发者定义强制性的安全要求：
-
-      1. 专注于与实现相关的规则
-      2. 引用技术栈中的安全工具
-      3. 为常见场景定义清晰的模式
-      4. 这些规则直接影响代码生成
-      5. 与用户合作，确保完整性而不冗余
-    elicit: true
-    sections:
-      - id: input-validation
-        title: 输入验证
-        template: |
-          - **验证库：** {{validation_library}}
-          - **验证位置：** {{where_to_validate}}
-          - **必需规则：**
-            - 所有外部输入必须经过验证
-            - 在处理前于 API 边界进行验证
-            - 优先使用白名单方法而非黑名单
-      - id: auth-authorization
-        title: 认证与授权
-        template: |
-          - **认证方法：** {{auth_implementation}}
-          - **会话管理：** {{session_approach}}
-          - **必需模式：**
-            - {{auth_pattern_1}}
-            - {{auth_pattern_2}}
-      - id: secrets-management
-        title: 密钥管理
-        template: |
-          - **开发环境：** {{dev_secrets_approach}}
-          - **生产环境：** {{prod_secrets_service}}
-          - **代码要求：**
-            - 绝不硬编码密钥
-            - 仅通过配置服务访问
-            - 日志或错误消息中不包含密钥
-      - id: api-security
-        title: API 安全
-        template: |
-          - **速率限制：** {{rate_limit_implementation}}
-          - **CORS 策略：** {{cors_configuration}}
-          - **安全头 (Headers)：** {{required_headers}}
-          - **HTTPS 强制：** {{https_approach}}
-      - id: data-protection
-        title: 数据保护
-        template: |
-          - **静态加密 (Encryption at Rest)：** {{encryption_at_rest}}
-          - **传输中加密 (Encryption in Transit)：** {{encryption_in_transit}}
-          - **个人身份信息 (PII) 处理：** {{pii_rules}}
-          - **日志记录限制：** {{what_not_to_log}}
-      - id: dependency-security
-        title: 依赖安全
-        template: |
-          - **扫描工具：** {{dependency_scanner}}
-          - **更新策略：** {{update_frequency}}
-          - **审批流程：** {{new_dep_process}}
-      - id: security-testing
-        title: 安全测试
-        template: |
-          - **SAST 工具：** {{static_analysis}}
-          - **DAST 工具：** {{dynamic_analysis}}
-          - **渗透测试：** {{pentest_schedule}}
-
-  - id: checklist-results
-    title: 清单检查结果报告
-    instruction: 在运行清单检查前，主动提出输出完整的架构文档。一旦用户确认，执行 architect-checklist 并在此处填充结果。
-
-  - id: next-steps
-    title: 后续步骤
-    instruction: |
-      完成架构设计后：
-
-      1. 如果项目有 UI 组件：
-      - 使用“前端架构模式”
-      - 将此文档作为输入提供
-
-      2. 对于所有项目：
-      - 与产品负责人一起审查
-      - 使用开发代理开始用户故事的实现
-      - 使用 DevOps 代理设置基础设施
-
-      3. 如果需要，为下一个代理包含具体的提示
-    sections:
-      - id: architect-prompt
-        title: 架构师提示
-        condition: 项目有 UI 组件
-        instruction: |
-          创建一个简短的提示，用于交接给架构师以创建前端架构。包括：
-          - 对此架构文档的引用
-          - PRD 中的关键 UI 需求
-          - 在此做出的任何与前端相关的决策
-          - 请求详细的前端架构