Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.

2026-04-140

bugfix

goodjin/agent-team

当用户报告错误、操作失败、系统报错时自动触发，执行问题诊断和修复流程。包括收集错误信息、分析错误、定位问题代码、设计修复方案、执行修复和文档记录。

2026-04-140

canvas-design

goodjin/agent-team

Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.

2026-04-140

content-collector

goodjin/agent-team

网址池资料采集工具。支持定时采集和主动触发，可采集新闻、文章、指南、参考资料等。触发场景：(1) 用户说"收集文章"、"采集资料"、"收集新闻"、"抓取内容"、"今日新闻" (2) 用户指定主题要求收集相关资料 (3) 用户提供网站要求采集内容 (4) 用户说"搜索并收集XX资料" (5) 用户管理网址池："添加网址"、"删除网址"、"列出网址" (6) 用户配置定时任务："设置定时采集"

2026-04-140

dev-plan-builder

goodjin/agent-team

开发计划生成器 - 基于架构文档生成详细的开发计划，包括前端、后端、集成测试等子文档。每个模块对应一个开发计划，每个计划拆分为原子化开发任务。

2026-04-140

来源

goodjin

goodjin/agent-team

打开 GitHub 仓库查看创作者相关仓库

安装命令

下载

在 Manus 中运行

适用职业SOC

软件开发工程师计算机与数学类职业15-1252L4

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;              // 实体ID
  field1: string;          // 字段说明 (对应PRD: [字段名])
  field2: number;          // 字段说明
  createdAt: Date;         // 创建时间
  updatedAt: Date;         // 更新时间
}

字段规约:

字段名	PRD属性	类型	约束	说明

索引设计:

索引名	字段	类型	用途

状态机设计

STATE-XXX: [状态机名称]

对应PRD: Flow-XXX

状态定义:

状态	PRD描述	说明

状态转换:

当前状态	事件	下一状态	条件	对应PRD

状态转换图:

[状态1] --事件1--> [状态2] --事件2--> [状态3]

边界条件

BOUND-XXX: [边界条件名称]

对应PRD: AC-XXX-XX

输入边界:

参数	类型	约束	来源	说明

业务边界:

验证规则:

错误处理:

错误码	场景	处理方式

非功能需求

性能要求

指标	要求	对应PRD

安全要求

需求	描述	实现方案

实现文件

文件路径	职责

验收标准

标准	要求	验证方法	对应PRD

覆盖映射

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检查：覆盖映射

已生成PRD-架构覆盖映射表
未覆盖项清单为空
覆盖率达到100%

阶段3检查：架构设计

每个模块都有对应的PRD功能点
每个模块文档都是自包含的
模块间依赖关系清晰

阶段3补充检查：行为规约精度

文档中不存在"自动 XX"描述——每处均已拆解为触发信号 + 响应动作 + 跨模块副作用
PRD 中每个独立的交互分支（不同对象类型 / 不同 UI 入口）在接口清单中各有独立条目
接口模板中"后置影响"字段已填写，不能留空或仅写"[影响描述]"占位符
每个用户交互（点击/双击/拖拽等）都有独立的 View 层接口定义，细化到具体手势
接口的后置影响包含级联分析，列出所有订阅该状态变更的模块
多步骤业务流程（如打开→恢复→渲染）已设计时序图或状态转换图
每个 UI 组件已定义尺寸约束（高度/宽度范围）、边距、响应式适配规则

阶段4检查：技术规约

所有用户故事都有接口规约
所有数据实体都有数据结构规约
所有业务流程都有状态机规约（如有状态）
所有验收标准都有边界条件规约

阶段5检查：覆盖验证

覆盖报告已生成
所有PRD需求都已覆盖
无遗漏项

使用示例

用户: "基于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%覆盖 · 完整自包含 🏗️