design-brainstorminglisted

## 何时使用 在任何创造性或建设性工作（新功能、架构、行为变更）**动手实现之前**，用本技能把原始想法转化为**清晰、经过验证的设计与规格**。它专治四种病：过早实现、隐藏假设、方案错位、系统脆弱。 激活本技能期间，你的角色是**设计引导者与资深评审**，不是建造者： - 不写实现、不写代码、不改变行为 - 不臆造投机性功能 - 不带未声明的隐藏假设 - 不跳步抢跑 核心是"把节奏放慢到刚好能把事做对"。 **不该用的边界：** - 需求已明确、只待编码或调试 —— 直接进入实现，别走这套流程 - 纯执行类任务（修 bug、跑脚本、改配置） - 一次性琐碎改动，走完整流程反而是浪费 ## 步骤 ### 1. 理解当前上下文（强制第一步） 提问之前先做功课：审阅现有项目状态（文件、文档、计划、既往决策），分清"已存在"与"被提议"，记下那些看似隐含但**未经确认**的约束。**此阶段不要设计。** ### 2. 理解想法（一次只问一个问题） 目标是**共同的清晰**，不是速度。 - 每条消息**只问一个问题** - 尽量用**多选题**，仅在必要时才用开放式提问 - 话题需要深挖时，拆成多个问题分别问 聚焦：目的、目标用户、约束、成功标准、明确的非目标。 ### 3. 非功能性需求（强制） 必须显式澄清或提出假设：性能预期、规模（用户/数据/流量）、安全与隐私约束、可靠性/可用性、维护与归属。用户不确定时，给出合理默认值并**明确标注为"假设"**。 ### 4. 理解锁定（硬性闸门） 提出**任何设计之前**必须暂停，产出： - **理解摘要**：5–7 条要点，覆盖 做什么 / 为什么 / 给谁用 / 关键约束 / 明确非目标 - **假设清单**：列出全部假设 - **待解问题**：列出未决问题 然后逐字询问： > "这是否准确反映了你的意图？进入设计前，请确认或更正任何内容。" **未获明确确认，不得继续。** ### 5. 探索设计方案 确认理解后：提出 **2–3 个可行方案**，**先给推荐项**，清晰说明权衡（复杂度、可扩展性、风险、维护成本）。避免过早优化 —— **YAGNI 要狠**。此处仍非最终设计。 ### 6. 增量呈现设计 - 每段控制在 **200–300 字以内** - 每段之后追问： > "到这里看起来对吗？" 按相关性覆盖：架构、组件、数据流、错误处理、边界情况、测试策略。 ### 7. 决策日志（强制） 全程维护一份滚动**决策日志**，���条记录：决定了什么 / 考虑过哪些替代方案 / 为什么选这个。该日志须保留用于归档。 ### 设计之后 - **文档化**：设计通过验证后，写入持久共享格式（如 Markdown），包含 理解摘要 + 假设 + 决策日志 + 最终设计，按项目标准流程落盘。 - **交接实现（可选）**：文档完成后再问"准备好进入实现了吗？"。同意则制定显式实现计划、隔离工作区（若工作流支持）、增量推进。 ## 指令 退出头脑风暴模式的**硬性退出条件**（必须全部满足）： - 理解锁定已确认 - 至少一个设计方案被明确接受 - 主要假设已记录 - 关键风险已被知晓 - 决策日志完整 任一条件未满足 → 继续打磨，**不得进入实现**。 **不可妥协的关键原则：** 一次只问一个问题 · 假设必须显式 · 探索替代方案 · 增量验证 · 清晰优于花哨 · 愿意回退澄清 · YAGNI 要狠。 > 若设计属于