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 是否被显式记录？（放弃了什么、为什么接受这个代价）
• 设计是否考虑了团队能力约束？（团队能维护这个复杂度的系统吗？）

常见反模式

已固化模式

关键追问

挑刺式（找改进空间）

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

正向式（找值得复用的）

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

反证条件指引

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