# Retro Design

> Retro Design

- Skill: `kaixin1seu/retro-design` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kaixin1seu/retro-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kaixin1seu/retro-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kaixin1seu (https://skillmd.com/u/kaixin1seu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kaixin1seu/retro-design

---


# retro-design — 设计/架构复盘透镜

## 适用范围与边界

本 skill 偏向**系统架构和流程设计**——系统分层、模块划分、技术选型、审查流程、设计方法论等。

**与其它 skill 的区分**：
- 写代码时做的具体实现决策（函数签名、错误处理逻辑） → `retro-coding`
- 实验设计和假设验证 → `retro-experiment`
- 数据处理架构选择（流式 vs 批处理）→ 本 skill 覆盖，但数据层面的具体问题归 `retro-data`

如果一个发现涉及多个领域，归入最相关领域深度复盘，其他领域在综合时简述。

**不适用场景**：简单的代码重构决策（用 retro-coding）、算法选择（用 retro-experiment）、API 参数设计、UI 布局设计。

## 评估维度

### 1. 决策质量
- 关键决策是否被记录？（不只记了"选了什么"，还记了"为什么选"和"放弃了什么"？）
- 决策前是否考虑了至少 2 个备选方案？（包括"不做"这个选项）
- 决策是可逆的还是不可逆的？不可逆决策是否给了足够的审查时间？
- 是否存在"先给方案再找问题"的倾向？（用解决方案倒推问题定义）

### 2. 架构完整性
- 设计是否覆盖了**正常路径和失败路径**？（不只是 happy path）
- 非功能需求是否被明确考虑？（性能、安全、可维护性、可扩展性）
- 外部依赖的失败模式是否被纳入设计？（依赖挂了怎么办？）

### 3. 流程与方法
- 设计过程是否遵循了"先理解问题，再设计方案"的顺序？
- 关键假设是否被验证过？（还是只靠推理？）
- 是否有外部视角的审查？（自己审查自己容易有盲区）
- 设计迭代的节奏是否合理？（审查→修改→再审查，有没有过度或不足？）

### 4. 风险与迁移
- 设计是否考虑了从当前状态到目标状态的迁移路径？（不只是最终状态，还有中间步骤）
- 有没有"单点不可逆"的决策？（如果这个决策错了，能不能回头？）
- 技术债务是否被显式标记和规划偿还时间？
- 设计是否过度工程化？（为了可能的需求增加了不必要的复杂度）

### 5. 文档与传播
- 设计文档是否足够清晰，让后来者能理解"为什么这样设计"？
- 关键 tradeoff 是否被显式记录？（放弃了什么、为什么接受这个代价）
- 设计是否考虑了团队能力约束？（团队能维护这个复杂度的系统吗？）

## 常见反模式

| 反模式 | 检测信号 |
|--------|----------|
| 方案先行 | 对话中先出现技术方案，后补问题定义。问"要解决什么问题"时回答模糊 |
| 审查迷失 | 设计迭代中新增架构层/子系统/规则系统，但原始问题定义和约束无变化——新加的复杂度不是服务于核心目标 |
| 隐式 tradeoff | 设计只说了选了什么，没说什么被放弃了。所有方案都有代价——说不出来代价说明没想清楚 |
| 过度工程化 | 为"未来可能"的需求设计了复杂抽象，但当前场景只需要简单方案 |
| 过度设计 | 为简单问题设计了不必要的复杂架构。问"这能更简单吗？"回答不出 |
| Happy-path 设计 | 只画了正常流程，没有考虑依赖故障、输入异常、资源耗尽等失败场景 |
| 缺乏迁移路径 | 描述了完美的最终状态，但没有说明从当前状态怎么一步步走过去 |
| 决策理由丢失 | 设计做完了但**为什么**这样做没有被记录。后来者只能猜测当初的考量，重复讨论已解决的问题 |
| 审查权威模糊 | 审查发现的问题没有区分"必须改"和"建议改"，每个意见都像否决票 |
| 单点决策 | 关键决策由一个人/一次推理确定，没有交叉验证或外部视角 |

## 已固化模式

| 模式 | 适用信号 | 验证 | 来源 |
|------|----------|:--:|------|
| 研究→第一性原理→审查→对齐 | 系统设计类任务，不确定最佳方案时。信号：任务涉及多个可行方案、有行内最佳实践可参考、用户强调质量 | 1 | 🤖 2026-07-06 |
| 系统性修复 | 发现组件缺陷后，先检查同类组件是否有一致问题再批量修复。信号：存在结构同构的多个组件 | 1 | 🤖 2026-07-06 |

## 关键追问

### 挑刺式（找改进空间）
- 这个设计要解决的核心问题是什么？问题定义有没有被反复确认？
- 放弃了什么？（每个设计都有代价，如果说不出来代价，说明没想清楚）
- 如果最关键的假设是错的，设计还能成立吗？
- 从当前状态到目标状态，第一步是什么？中间有没有不可逆的步骤？
- 这个设计产生的复杂度，团队有能力长期维护吗？
- 审查过程中，有没有"为了修复审查发现而增加复杂度"的情况？（审查迷失）
- 设计的成功标准是什么？怎么知道它起作用了？
- 设计过程中用了什么工具/方法来辅助决策？（ADR、决策矩阵、原型验证、tradeoff 分析等）有没有该用但没用的？

### 正向式（找值得复用的）
- 这次设计中最值得复用的做法或模式是什么？为什么它有效？
  （信号：某个设计模式在后续迭代中被反复引用无修改、某个决策标准被其它设计任务复用）
- 有哪些"这次做对了"的决策值得被记住？（下次类似场景可以直接复用）
  （信号：某个决策带来了意料之外的正向副作用、后续设计自然延续了这个决策没有回头）
- 设计过程中有没有特别顺畅的环节？什么因素促成的？
  （信号：某个审查流程特别高效、某次讨论产出远超预期、某个方法论被团队自然接受）

### 反证条件指引
对于核心设计决策，追问：**什么具体信号会提示这个决策需要重新考虑？**
（引导写出可操作的反证条件，而非空洞的"如果前提假设错了"——什么具体信号说明前提假设错了？）