---
name: deep-design-iteration
description: "Iterative deep design methodology: multi-angle expert review, user persona simulation, and progressive refinement. Use when designing a new system, major feature, or architecture. Forces multi-perspective evaluation before implementation."
---

# 迭代式深度设计方法论

> 核心信念：设计清楚、设计清晰、设计合理才是真正有价值的地方。打字是最简单的很快，别急着实现。

## 触发条件

当用户要求设计一个**新系统、重大功能、或架构变更**时，使用此方法论。不适用于改 bug、小功能、< 30 行改动。

## 设计流程总览

```
1. 探索现状 → 理解代码和上下文
2. 初始设计 → 写出第一版设计文档
3. 第一轮评估：技术专家角度（架构师、安全、运维）
4. 第二轮评估：协议/接口/边界完整性
5. 第三轮评估：用户画像模拟（7+ 角色）
6. 第四轮评估：美术/UX/可访问性（如有视觉元素）
7. 持续迭代：每轮发现问题 → 解决 → 重新评估
8. 输出：设计文档 + 评审记录 + 实施规划
```

**每轮评估必须发现问题并解决问题，不能走过场。**

---

## Phase 1：探索现状

**在做任何设计之前**，先充分理解现有系统：

1. 读现有代码结构，理解模块边界和依赖关系
2. 读现有设计文档（如果有）
3. 理解用户的业务场景和约束条件
4. 列出现有系统的公共 API 和扩展点
5. 明确"不能动什么"和"可以动什么"

**输出**：一段现状总结，包含关键文件路径和扩展点。

---

## Phase 2：初始设计

写出第一版设计文档，包含：

1. **核心定位**：用一句话说清楚这个东西是什么
2. **架构图**：ASCII 图，展示模块边界和数据流
3. **关键机制**：每个核心机制的设计（消息协议、状态机、数据模型等）
4. **代码结构**：文件放在哪，和现有系统的关系
5. **分期计划**：MVP 和后续迭代

**设计文档路径**：`docs/superpowers/specs/YYYY-MM-DD-{topic}-design.md`

**写完即提交 git。**

---

## Phase 3：多角度专家评估（每轮 10+ 个问题）

### 核心原则

> 不要自己评估自己的设计。派出独立的 Agent，每个赋予专业角色，从不同角度找问题。

### 评估轮次模板

#### 第一轮：技术深度评估

派出 3-4 个 Agent，角色：

| 角色 | 关注点 |
|------|--------|
| **系统架构师** | 模块边界、依赖方向、数据流、扩展性 |
| **安全工程师** | 认证、授权、数据隐私、攻击面 |
| **运维工程师** | 故障恢复、监控、部署、规模 |
| **成本分析师** | 资源消耗、token 成本、性能瓶颈 |

每个角色必须输出：
1. 发现的问题（带编号）
2. 问题的严重程度（高/中/低）
3. 具体解决方案
4. 对其他模块的影响

#### 第二轮：协议与接口完整性

检查所有接口的完整性：

- 消息协议：是否有遗漏的消息类型？错误处理？超时？
- 状态机：是否有未定义的转换？边界条件？
- 并发：竞态条件、死锁、数据一致性
- 生命周期：注册、运行、故障、恢复、清理

#### 第三轮：用户画像模拟

**这是最重要的一轮。** 模拟 7+ 个真实用户角色：

| 维度 | 覆盖范围 |
|------|---------|
| **年龄** | 23-45 岁 |
| **层级** | 新人 → 基层 → 资深 → 主管 |
| **岗位** | 开发、测试、产品、运维、设计 |
| **技术能力** | 不写代码 → 熟练 → 专家 |
| **性格** | 内向社恐 → 外向善沟通 |

对每个角色输出：
1. **TA 的一天**：这个系统在 TA 的日常中如何出现
2. **TA 最想看到什么**：进入系统后最关心什么信息
3. **TA 会怎么用**：高频使用场景
4. **TA 可能抵触什么**：为什么 TA 可能不想用
5. **设计盲点**：从 TA 的角度，设计缺了什么

**关键**：每个角色的问题必须是具体的、有洞察的，不能泛泛而谈。

#### 第四轮（如有视觉元素）：美术/UX/可访问性

| 角色 | 关注点 |
|------|--------|
| **像素美术师** | 色板、尺寸、视角、描边、光影 |
| **UI/UX 设计师** | 信息密度、缩放、无障碍、视觉一致性 |
| **前端工程师** | 渲染性能、HiDPI、动画、素材格式 |
| **目标用户 ×4** | 不同审美的真实反馈 |

---

## Phase 4：问题解决与迭代

### 每轮发现的处理流程

```
发现问题 → 写入设计文档（问题 N：标题）
          → 给出解决方案
          → 更新设计文档中受影响的章节
          → 提交 git
          → 进入下一轮评估
```

### 问题编号规则

- 问题按发现顺序编号：问题 1、问题 2...问题 N
- 每个问题标注**发现者角色**
- 格式：

```markdown
### 问题 N：简明标题

**发现者**：角色名

**问题**：具体描述

**解法**：具体方案（代码/协议/配置示例）
```

### 迭代停止条件

满足以下条件之一时停止迭代：
1. 连续一轮没有发现严重程度为"高"的新问题
2. 用户明确说"够了，可以了"
3. 设计文档已覆盖所有已知场景

---

## Phase 5：设计文档组织

### 文档结构

```markdown
# 标题 — 一句话定位
> 日期

## 核心定位
## 架构
## [各子系统设计]
## 模块边界与接口契约
## 深度设计：关键问题与解决方案
### 问题 1：...
### 问题 N：...
## 用户画像驱动的设计补全
## MVP 范围定义
```

### 每次修改都提交 git

```bash
git add docs/superpowers/specs/YYYY-MM-DD-*.md
git commit -m "docs(topic): 第N轮设计修复 — 简述修复了什么"
```

---

## 关键原则

### 1. 不要急着实现
用户说"先设计清楚"的时候，真的只做设计。不要写代码，不要搭脚手架。

### 2. 多角度强制评估
每轮评估必须派出独立 Agent，赋予专业角色。自己评估自己的设计 = 没有评估。

### 3. 用户画像不是装饰
第三轮的用户画像模拟是最重要的一轮。7+ 个角色覆盖年龄、层级、岗位、技术能力、性格。每个角色的反馈必须是具体的。

### 4. 美术是皮肤，不是骨架
如果设计涉及视觉元素，美术风格必须是独立的皮肤层，和功能逻辑完全解耦。换皮肤不应该改任何功能代码。

### 5. 不影响现有功能
新功能通过 Bridge 层或类似隔离机制接入，不修改任何现有代码。验证标准：删除新功能目录后，现有系统编译运行零报错。

### 6. 问题比答案重要
每个发现的问题都记录在设计文档中。即使后来方案改了，问题本身也有价值——它记录了"为什么这样设计"的决策过程。

---

## 评估质量自检

| 检查项 | 通过标准 |
|--------|---------|
| 技术评估 | 每轮发现 ≥8 个问题 |
| 用户画像 | 覆盖 ≥7 个角色，每个发现 ≥2 个盲点 |
| 美术评估 | ≥3 个专业角色 + ≥4 个目标用户 |
| 协议完整性 | 所有消息类型有定义、有错误处理、有超时 |
| 隔离性 | 新功能删除后现有系统零影响 |
| 隐私 | 有隐私分级机制，管理者只看聚合数据 |
| 成本 | 有 token 预算和成本控制方案 |
| 运维 | 有故障恢复、监控指标、优雅停机方案 |
