| name | architecture-designer |
| description | 架构设计与技术规约生成器 - 基于PRD文档进行系统架构设计和技术规约生成。确保100%覆盖PRD需求，包含接口规约、数据结构规约、状态机规约、边界条件规约。 |
Architecture Designer Skill
基于 PRD 文档进行系统架构设计和技术规约生成，确保 100% 覆盖 PRD 需求，提供完整的架构文档和技术规约。
核心原则
1. 严格对应原则
- 每个架构章节必须对应 PRD 中的具体功能需求
- 每个模块设计必须追溯到 PRD 中的用户故事
- 每个接口设计必须对应 PRD 中的功能点
- 所有设计决策必须在 PRD 中有依据
2. 100% 覆盖原则
- PRD 中的每个功能需求都必须有对应的架构设计
- PRD 中的每个用户故事都必须有对应的接口规约
- PRD 中的每个数据实体都必须有对应的数据结构规约
- PRD 中的每个验收标准都必须有对应的边界条件规约
3. 文档自包含原则
- 每个文档必须是自包含的，能够自我解释
- 不依赖其他文档即可理解当前子系统的全貌
- 包含完整的上下文信息支持独立开发
4. 行为规约精度原则
- "自动"行为必须拆解：凡出现"自动 XX"的描述，必须明确三要素：
- 触发信号：哪个事件 / 通知 / 回调（如
NSWindow.didEnterFullScreenNotification）
- 响应动作：修改哪个变量 / 调用哪个方法（如
isSidebarVisible = false）
- 跨模块副作用：哪些其他模块的状态会随之改变，或显式声明"无跨模块副作用"
- PRD 交互分支必须逐一对应接口：PRD 中每个独立的交互分支（不同对象、不同入口）必须在接口清单中各自有独立条目；不允许将多个分支的行为合并描述在同一个接口下
- View 层交互必须细化到手势：每个用户交互（点击、双击、拖拽、长按等）必须定义独立的 View 层接口，不能只停留在 ViewModel 层的大接口（如
goToPage）
- 级联影响必须全量分析：接口的后置影响必须包含级联分析——列出所有订阅该状态变更的模块及其响应行为（格式：
模块名.监听变量 → 触发的动作）
- 多步骤流程必须设计时序：涉及多步骤的业务流程（如打开文件→恢复位置→渲染）必须设计时序图或状态转换图，明确各步骤的触发条件和执行顺序
- UI 组件必须定义布局约束：每个 UI 组件必须定义尺寸约束（高度/宽度范围）、边距、响应式适配规则
输入要求
必须提供 PRD 文档路径：
docs/v{N}/01-prd.md - PRD 文档- 或用户指定的 PRD 文件路径
工作流程
阶段 1: 有效信息提取
目标: 从 PRD 中提取所有有效信息，建立完整的需求清单。
1.1 提取功能需求清单
## 功能需求提取
| 编号 | 功能名称 | 优先级 | 用户故事数 | 验收标准数 | 状态 |
|-----|---------|-------|-----------|-----------|------|
| FR-001 | [功能1] | P0 | 2 | 5 | 待设计 |
| FR-002 | [功能2] | P0 | 3 | 8 | 待设计 |
...
1.2 提取用户故事清单
## 用户故事提取
| 编号 | 用户故事 | 对应功能 | 涉及实体 | 涉及接口数 | 状态 |
|-----|---------|---------|---------|-----------|------|
| US-001 | 作为用户，我想... | FR-001 | Entity-001 | 2 | 待设计 |
| US-002 | 作为用户，我想... | FR-001 | Entity-002 | 3 | 待设计 |
...
1.3 提取数据实体清单
## 数据实体提取
| 编号 | 实体名称 | 属性数 | 关联实体 | 对应功能 | 状态 |
|-----|---------|-------|---------|---------|------|
| Entity-001 | 用户 | 8 | Entity-002 | FR-001 | 待设计 |
| Entity-002 | 订单 | 12 | Entity-003 | FR-002 | 待设计 |
...
1.4 提取业务流程清单
## 业务流程提取
| 编号 | 流程名称 | 状态数 | 转换数 | 对应功能 | 状态 |
|-----|---------|-------|-------|---------|------|
| Flow-001 | 订单流程 | 5 | 8 | FR-002 | 待设计 |
| Flow-002 | 支付流程 | 4 | 6 | FR-003 | 待设计 |
...
1.5 提取验收标准清单
## 验收标准提取
| 编号 | 验收标准 | 对应用户故事 | 边界类型 | 状态 |
|-----|---------|------------|---------|------|
| AC-001-01 | 输入验证... | US-001 | 输入边界 | 待设计 |
| AC-001-02 | 权限检查... | US-001 | 业务边界 | 待设计 |
...
阶段 2: 覆盖映射表生成
目标: 建立 PRD 需求到架构设计的完整映射关系，确保 100% 覆盖。
2.1 PRD-架构覆盖映射表
## PRD-架构覆盖映射表
### 功能需求覆盖
| PRD编号 | 功能名称 | 架构模块 | 接口规约 | 数据规约 | 状态 |
|---------|---------|---------|---------|---------|------|
| FR-001 | [功能] | MOD-01 | API-001~003 | DATA-001 | ✅ 已覆盖 |
| FR-002 | [功能] | MOD-02 | API-004~006 | DATA-002 | ✅ 已覆盖 |
| FR-003 | [功能] | MOD-03 | - | - | ❌ 未覆盖 |
### 用户故事覆盖
| PRD编号 | 用户故事 | 接口规约 | 状态机 | 边界条件 | 状态 |
|---------|---------|---------|-------|---------|------|
| US-001 | [故事] | API-001,002 | STATE-001 | BOUND-001~003 | ✅ 已覆盖 |
| US-002 | [故事] | API-003,004 | - | BOUND-004~006 | ✅ 已覆盖 |
### 数据实体覆盖
| PRD编号 | 实体名称 | 数据结构规约 | 索引设计 | 状态 |
|---------|---------|------------|---------|------|
| Entity-001 | [实体] | DATA-001 | IDX-001,002 | ✅ 已覆盖 |
| Entity-002 | [实体] | DATA-002 | IDX-003 | ✅ 已覆盖 |
### 验收标准覆盖
| PRD编号 | 验收标准 | 边界条件规约 | 测试场景 | 状态 |
|---------|---------|------------|---------|------|
| AC-001-01 | [标准] | BOUND-001 | TEST-001 | ✅ 已覆盖 |
| AC-001-02 | [标准] | BOUND-002 | TEST-002 | ✅ 已覆盖 |
2.2 未覆盖项清单
## 未覆盖项清单（必须为空才能进入下一阶段）
| PRD编号 | 类型 | 描述 | 原因 | 处理方案 |
|---------|-----|------|------|---------|
| - | - | - | - | - |
**检查点**: 如果此清单不为空，必须先补充设计，确保 100% 覆盖。
阶段 3: 架构设计生成
3.1 整体架构设计
对应 PRD: 1. 项目概述 + 2. 功能需求
输出: docs/v{N}/02-architecture/01-overview.md
# 整体架构设计
## 文档信息
- **项目名称**: [项目名称]
- **版本**: v1.0
- **对应PRD**: docs/v{N}/01-prd.md
- **更新日期**: [日期]
## 1. 系统定位
### 1.1 系统概述
[基于PRD项目概述的系统定位]
### 1.2 核心功能架构
[功能模块划分，与PRD功能清单对应]
### 1.3 系统架构图
[包含所有功能模块的架构图]
## 2. 技术选型
| 层次 | 技术栈 | 选型理由 |
|-----|-------|---------|
| 前端 | [技术] | [理由] |
| 后端 | [技术] | [理由] |
| 数据库 | [技术] | [理由] |
## 3. 覆盖映射
本文档对应的功能需求：
| PRD编号 | 功能 | 覆盖状态 |
|---------|-----|---------|
| FR-001 | [功能] | ✅ |
| FR-002 | [功能] | ✅ |
3.2 分层架构设计
对应 PRD: 2. 功能需求（按功能类型分层）
输出: docs/v{N}/02-architecture/02-layers.md
# 分层架构设计
## 1. 层次划分
| 层次 | 名称 | 职责 | 对应PRD功能 |
|-----|------|------|------------|
| L1 | 基础设施层 | 基础服务 | FR-XXX |
| L2 | 数据访问层 | 数据存储 | FR-XXX |
| L3 | 业务逻辑层 | 核心业务 | FR-XXX |
| L4 | 接口层 | 对外接口 | FR-XXX |
| L5 | 展示层 | 用户界面 | FR-XXX |
## 2. 层间依赖
[层间依赖关系图]
## 3. 功能-层次映射
| PRD功能 | 所属层次 | 模块编号 |
|---------|---------|---------|
| FR-001 | L3-业务逻辑层 | MOD-01 |
| FR-002 | L4-接口层 | MOD-02 |
3.3 模块详细设计
对应 PRD: 2. 功能需求（逐条对应）
每个模块一个文件: docs/v{N}/02-architecture/03-{模块编号}-{模块名称}.md
模块文档模板:
# [模块编号]-[模块名称]
## 文档信息
- **项目名称**: [项目名称]
- **文档编号**: [模块编号]
- **版本**: [版本号]
- **更新日期**: [日期]
- **对应PRD**: [PRD需求编号]
---
## 目录
1. [系统定位](#系统定位)
2. [对应PRD](#对应prd)
3. [全局架构位置](#全局架构位置)
4. [依赖关系](#依赖关系)
5. [数据流](#数据流)
6. [核心设计](#核心设计)
7. [接口定义](#接口定义)
8. [数据结构](#数据结构)
9. [状态机设计](#状态机设计)
10. [边界条件](#边界条件)
11. [非功能需求](#非功能需求)
12. [实现文件](#实现文件)
13. [验收标准](#验收标准)
14. [覆盖映射](#覆盖映射)
---
## 系统定位
### 在整体架构中的位置
**所属层次**: [层次名称]
**架构定位图**:
┌─────────────────────────────────────────────────────┐
│ [上层模块名称] │
└───────────────────────┬─────────────────────────────┘
│ ▼ 调用
┌─────────────────────────────────────────────────────┐
│ ★ [本模块名称] ★ │
└───────────────────────┬─────────────────────────────┘
│ ▼ 依赖
┌─────────────────────────────────────────────────────┐
│ [下层模块名称] │
└─────────────────────────────────────────────────────┘
### 核心职责
- **职责1**: [具体职责描述]
- **职责2**: [具体职责描述]
### 边界说明
- **负责**: [本模块负责的范围]
- **不负责**: [明确不属于本模块的范围]
---
## 对应PRD
| PRD章节 | 编号 | 内容 |
|---------|-----|------|
| 功能需求 | FR-XXX | [功能描述] |
| 用户故事 | US-XXX | [用户故事] |
| 验收标准 | AC-XXX-XX | [验收标准] |
---
## 全局架构位置
[系统全景图，标注本模块位置]
---
## 依赖关系
### 上游依赖（本模块调用的模块）
| 模块名称 | 模块编号 | 依赖原因 | 调用方式 |
|---------|---------|---------|---------|
### 下游依赖（调用本模块的模块）
| 模块名称 | 模块编号 | 被调用场景 | 调用方式 |
|---------|---------|-----------|---------|
### 外部依赖
| 依赖项 | 类型 | 用途 | 版本要求 |
|-------|------|------|---------|
---
## 数据流
### 输入数据流
| 数据项 | 来源 | 格式 | 说明 |
|-------|------|------|------|
### 输出数据流
| 数据项 | 目标 | 格式 | 说明 |
|-------|------|------|------|
---
## 核心设计
### 设计目标
| 目标 | 描述 | 度量标准 |
|-----|------|---------|
### 核心组件
[组件设计详情]
---
## 接口定义
### 对外接口清单
| 接口编号 | 接口名称 | 方法 | 路径 | 对应PRD |
|---------|---------|------|------|---------|
| API-XXX | [接口名] | POST | /api/xxx | US-XXX |
### 接口详细定义
#### API-XXX: [接口名称]
**对应PRD**:
- 用户故事: US-XXX
- 验收标准: AC-XXX-XX
**接口定义**:
- 路径: `POST /api/[resource]`
- 描述: [接口描述]
**请求参数**:
| 参数名 | 类型 | 必填 | 来源 | 说明 |
|-------|------|------|------|------|
**响应格式**:
```typescript
interface Response {
success: boolean;
data?: ResultType;
error?: string;
}
边界条件:
| 编号 | 条件 | 处理方式 |
|---|
| BOUND-XXX | [条件] | [处理] |
数据结构
核心实体
DATA-XXX: [实体名称]
对应PRD: Entity-XXX
interface [EntityName] {
id: string;
field1: string;
field2: number;
createdAt: Date;
updatedAt: Date;
}
字段规约:
索引设计:
状态机设计
STATE-XXX: [状态机名称]
对应PRD: Flow-XXX
状态定义:
状态转换:
状态转换图:
[状态1] --事件1--> [状态2] --事件2--> [状态3]
边界条件
BOUND-XXX: [边界条件名称]
对应PRD: AC-XXX-XX
输入边界:
业务边界:
验证规则:
错误处理:
非功能需求
性能要求
安全要求
实现文件
验收标准
覆盖映射
PRD需求覆盖情况
| PRD类型 | PRD编号 | 架构元素 | 覆盖状态 |
|---|
| 功能需求 | FR-XXX | MOD-XXX | ✅ |
| 用户故事 | US-XXX | API-XXX | ✅ |
| 数据实体 | Entity-XXX | DATA-XXX | ✅ |
| 业务流程 | Flow-XXX | STATE-XXX | ✅ |
| 验收标准 | AC-XXX-XX | BOUND-XXX | ✅ |
---
### 阶段 4: 技术规约生成
#### 4.1 接口规约文档
**输出**: `docs/v{N}/02-architecture/04-api-spec.md`
```markdown
# 接口规约文档
## 文档信息
- **项目名称**: [项目名称]
- **版本**: v1.0
- **对应PRD**: docs/v{N}/01-prd.md
- **更新日期**: [日期]
## 接口清单
| 编号 | 接口名称 | 方法 | 路径 | 对应用户故事 | 所属模块 |
|-----|---------|------|------|------------|---------|
| API-001 | [接口] | POST | /api/xxx | US-001 | MOD-01 |
| API-002 | [接口] | GET | /api/xxx | US-001 | MOD-01 |
...
## 接口详细定义
### API-001: [接口名称]
**对应PRD**:
- 用户故事: US-001
- 功能点: FR-001
- 验收标准: AC-001-01, AC-001-02
**所属模块**: MOD-01
**接口定义**:
- 路径: `POST /api/[resource]`
- 描述: [接口功能描述]
**前置条件**:
- [前置条件1]
- [前置条件2]
**请求参数**:
| 参数名 | 类型 | 必填 | 来源 | 说明 |
|-------|------|------|------|------|
| param1 | string | 是 | PRD字段[field1] | [描述] |
**请求示例**:
```json
{
"param1": "value1"
}
响应格式:
interface Response {
code: number;
message: string;
data: ResultType;
}
响应示例:
{
"code": 0,
"message": "success",
"data": {...}
}
错误码:
| 错误码 | 场景 | 对应PRD |
|---|
| 400 | 参数错误 | AC-001-01 |
| 401 | 未授权 | AC-001-02 |
| 404 | 资源不存在 | AC-001-03 |
依赖接口:
后置影响（必填，不得留空）:
- 直接变更：
模块名.状态变量: 旧值 → 新值（如 ReaderViewModel.currentPage: 1 → 5）
- 级联影响分析（列出所有订阅该状态变更的模块）：
ThumbnailGridView.currentPageHighlight: 更新蓝色边框到第5页BookmarkListView.currentPageIndicator: 更新当前页书签图标状态DocumentRepository.lastViewedPage: 异步保存到数据库SearchViewModel.highlightedResults: 清除搜索高亮（页面变更时）
- 若确实无跨模块影响，必须显式写：
// 无跨模块状态变化
...
#### 4.2 数据结构规约文档
**输出**: `docs/v{N}/02-architecture/05-data-spec.md`
```markdown
# 数据结构规约文档
## 文档信息
- **项目名称**: [项目名称]
- **版本**: v1.0
- **对应PRD**: docs/v{N}/01-prd.md
## 数据实体清单
| 编号 | 实体名称 | 表名 | 对应PRD实体 | 所属模块 |
|-----|---------|------|------------|---------|
| DATA-001 | [实体] | t_xxx | Entity-001 | MOD-01 |
...
## 实体详细定义
### DATA-001: [实体名称]
**对应PRD**:
- 实体定义: Entity-001
- 功能点: FR-001
- 用户故事: US-001, US-002
**所属模块**: MOD-01
**数据模型**:
```typescript
interface [EntityName] {
// PRD属性: [属性名]
id: string; // 唯一标识
field1: string; // [PRD描述]
field2: number; // [PRD描述]
createdAt: Date; // 创建时间
updatedAt: Date; // 更新时间
}
字段规约:
| 字段名 | PRD属性 | 类型 | 约束 | 默认值 | 说明 |
|---|
| id | - | string | PK, UUID | - | 唯一标识 |
| field1 | [PRD属性名] | string | NOT NULL, 长度1-100 | - | [PRD描述] |
关联关系:
| 关联实体 | 关系类型 | 外键 | 对应PRD |
|---|
| DATA-002 | 一对多 | entity2_id | [PRD关系描述] |
索引设计:
| 索引名 | 字段 | 类型 | 用途 | 对应PRD查询 |
|---|
| idx_field1 | field1 | UNIQUE | 唯一约束 | PRD查询场景1 |
数据流:
- 创建来源: API-001
- 读取场景: API-002, API-003
- 更新场景: API-004
- 删除场景: API-005
生命周期:
- 创建时机: [描述]
- 更新时机: [描述]
- 归档/删除时机: [描述]
...
#### 4.3 状态机规约文档
**输出**: `docs/v{N}/02-architecture/06-state-spec.md`
```markdown
# 状态机规约文档
## 文档信息
- **项目名称**: [项目名称]
- **版本**: v1.0
- **对应PRD**: docs/v{N}/01-prd.md
## 状态机清单
| 编号 | 状态机名称 | 实体 | 对应PRD流程 | 状态数 | 转换数 |
|-----|-----------|------|------------|-------|-------|
| STATE-001 | [状态机] | DATA-001 | Flow-001 | 5 | 8 |
...
## 状态机详细定义
### STATE-001: [状态机名称]
**对应PRD**:
- 业务流程: Flow-001
- 功能点: FR-002
- 用户故事: US-003
**所属实体**: DATA-001
**状态定义**:
| 状态 | 编码 | PRD描述 | 说明 | 允许操作 |
|-----|------|---------|------|---------|
| 待处理 | PENDING | PRD描述 | 初始状态 | 取消、处理 |
| 处理中 | PROCESSING | PRD描述 | 处理中状态 | 完成、失败 |
**状态转换**:
| 编号 | 当前状态 | 触发事件 | 下一状态 | 条件 | 对应PRD | 触发接口 |
|-----|---------|---------|---------|------|---------|---------|
| T001 | 待处理 | 开始处理 | 处理中 | 条件满足 | PRD描述 | API-001 |
| T002 | 处理中 | 处理完成 | 已完成 | 条件满足 | PRD描述 | API-002 |
**状态转换图**:
┌─────────┐ 开始处理 ┌─────────┐ 处理完成 ┌─────────┐
│ 待处理 │ ────────────▶ │ 处理中 │ ────────────▶ │ 已完成 │
└─────────┘ └─────────┘ └─────────┘
│ │
│ 取消 │ 处理失败
▼ ▼
┌─────────┐ ┌─────────┐
│ 已取消 │ │ 已失败 │
└─────────┘ └─────────┘
**转换规则详情**:
- T001-规则: [详细规则描述] (来源: PRD章节X.X)
- T002-规则: [详细规则描述] (来源: PRD章节X.X)
**状态约束**:
- [约束1]: [约束描述] (对应PRD: AC-XXX-XX)
---
...
4.4 边界条件规约文档
输出: docs/v{N}/02-architecture/07-boundary-spec.md
# 边界条件规约文档
## 文档信息
- **项目名称**: [项目名称]
- **版本**: v1.0
- **对应PRD**: docs/v{N}/01-prd.md
## 边界条件清单
| 编号 | 边界条件名称 | 类型 | 对应PRD | 对应接口 |
|-----|------------|------|---------|---------|
| BOUND-001 | [边界] | 输入验证 | AC-001-01 | API-001 |
| BOUND-002 | [边界] | 业务规则 | AC-001-02 | API-001 |
...
## 边界条件详细定义
### BOUND-001: [边界条件名称]
**对应PRD**:
- 验收标准: AC-001-01
- 功能点: FR-001
- 用户故事: US-001
**所属接口**: API-001
**边界类型**: 输入验证/业务规则/权限控制/数据约束
**输入边界**:
| 参数 | 类型 | 约束 | 来源 | 错误码 |
|-----|------|------|------|-------|
| param1 | string | 长度1-100, 非空 | PRD字段[field1] | 400 |
**业务边界**:
- [边界1]: [边界描述] (对应AC: AC-001-01)
- 触发条件: [条件]
- 处理方式: [处理]
- 错误码: 400
**验证规则**:
```typescript
// 验证函数示例
function validateParam1(value: string): boolean {
// 规则来源: AC-001-01
if (!value || value.length === 0) {
throw new Error('参数不能为空');
}
if (value.length > 100) {
throw new Error('参数长度不能超过100');
}
return true;
}
错误处理:
| 错误码 | 错误消息 | 场景 | 恢复方案 |
|---|
| 400 | 参数错误 | 输入验证失败 | 提示用户修正 |
| 403 | 权限不足 | 权限检查失败 | 引导用户获取权限 |
...
---
### 阶段 5: 覆盖验证
#### 5.1 生成覆盖报告
**输出**: `docs/v{N}/02-architecture/00-coverage-report.md`
```markdown
# PRD-架构覆盖报告
## 覆盖统计
| 类型 | PRD总数 | 已覆盖 | 未覆盖 | 覆盖率 |
|-----|--------|-------|-------|-------|
| 功能需求 | 12 | 12 | 0 | 100% |
| 用户故事 | 25 | 25 | 0 | 100% |
| 数据实体 | 8 | 8 | 0 | 100% |
| 业务流程 | 5 | 5 | 0 | 100% |
| 验收标准 | 48 | 48 | 0 | 100% |
## 详细覆盖清单
### 功能需求覆盖
| PRD编号 | 功能名称 | 架构模块 | 接口规约 | 数据规约 | 状态 |
|---------|---------|---------|---------|---------|------|
| FR-001 | [功能] | MOD-01 | API-001~003 | DATA-001 | ✅ |
...
### 用户故事覆盖
| PRD编号 | 用户故事 | 接口规约 | 状态机 | 边界条件 |
|---------|---------|---------|-------|---------|
| US-001 | [故事] | API-001,002 | STATE-001 | BOUND-001~003 | ✅ |
...
## 未覆盖项
**[无未覆盖项]**
✅ 所有PRD需求已100%覆盖
---
## 变更历史
| 版本 | 日期 | 变更内容 |
|-----|------|---------|
| 1.0 | [日期] | 初始版本 |
输出目录结构
docs/v{N}/
├── 01-prd.md # PRD 文档（输入）
└── 02-architecture/
├── 00-coverage-report.md # 覆盖报告
├── 01-overview.md # 整体架构设计
├── 02-layers.md # 分层架构设计
├── 03-{模块编号}-{模块名称}.md # 模块详细设计（多个）
├── 04-api-spec.md # 接口规约
├── 05-data-spec.md # 数据结构规约
├── 06-state-spec.md # 状态机规约
└── 07-boundary-spec.md # 边界条件规约
设计检查清单
阶段1检查：有效信息提取
阶段2检查：覆盖映射
阶段3检查：架构设计
阶段3补充检查：行为规约精度
阶段4检查：技术规约
阶段5检查：覆盖验证
使用示例
用户: "基于PRD文档设计系统架构"
AI: [读取 PRD 文档]
【阶段1】有效信息提取
- 功能需求: 12个 (FR-001 ~ FR-012)
- 用户故事: 25个 (US-001 ~ US-025)
- 数据实体: 8个 (Entity-001 ~ Entity-008)
- 业务流程: 5个 (Flow-001 ~ Flow-005)
- 验收标准: 48个
【阶段2】覆盖映射表生成
✅ 生成PRD-架构覆盖映射表
✅ 未覆盖项清单: 空
【阶段3】架构设计生成
✅ 01-overview.md
✅ 02-layers.md
✅ 03-mod-01-用户模块.md
✅ 03-mod-02-订单模块.md
...
【阶段4】技术规约生成
✅ 04-api-spec.md (32个接口)
✅ 05-data-spec.md (8个实体)
✅ 06-state-spec.md (5个状态机)
✅ 07-boundary-spec.md (48个边界条件)
【阶段5】覆盖验证
✅ 00-coverage-report.md
✅ 覆盖率: 100%
架构设计完成！
注意事项
- 100%覆盖: 必须确保PRD中的每个需求都有对应的架构设计
- 严格追溯: 每个设计元素都要标注对应的PRD编号
- 自包含: 每个模块文档都要能独立理解
- 一致性: 保持与PRD的命名和定义一致
- 优先级: 优先设计P0功能，再处理P1、P2
严格对应 · 100%覆盖 · 完整自包含 🏗️
