brainstorming

# Brainstorming - 交互式设计优化 ## 铁律 ``` NO IMPLEMENTATION WITHOUT DESIGN DISCUSSION FIRST ``` **违反规则的信件就是违反规则的精神。** **无例外**： - 不跳过设计阶段直接编码 - 不基于模糊需求直接实现 - 不在用户确认前开始编码 - YAGNI（You Aren't Gonna Need It）无情移除非必要功能 --- ## 常见合理化 | 借口 | 现实 | |------|------| | "需求很明确，直接开始" | 需求"明确"≠需求"正确"。误解成本高于设计讨论成本 | | "先写个原型再说" | 无设计的原型=技术债。重构比从头设计更难 | | "用户没时间讨论" | 宁可等待也不浪费开发时间。错误实现浪费双方时间 | | "这很简单不需要设计" | 简单功能也可能有复杂交互。设计5分钟节省调试5小时 | | "我理解用户意图" | 你理解的≠用户想要的。确认总比假设好 | --- ## 红色标志 - 停止并重新开始 - "需求很明确，直接开始" - "先写个原型再说" - "用户没时间讨论" - "这很简单不需要设计" - "我理解用户意图" - 跳过设计讨论直接编码 **所有这些意味着：停止编码。回到设计讨论阶段。** --- ## 核心原则 **Brainstorming** 是一种通过**苏格拉底式提问**来探索用户意图、明确需求、对比方案的设计方法。 ``` ┌─────────────────────────────────────────────────────────┐ │ 理解项目状态 → 逐一提问 → 探索方案 → 分段呈现 → 保存设计 │ └─────────────────────────────────────────────────────────┘ ``` **核心原则**： - **一次一个问题**：不要用多个问题压倒用户 - **多选题优先**：选择题比开放式问题更容易回答 - **探索替代方案**：在确定前总是提出 2-3 个方案 - **增量验证**：分段展示设计，逐段确认 - **YAGNI 无情**：从所有设计中移除非必要功能 --- ## 自主模式 当用户明确要求“不要反复确认”“自己选最优方案”“直接推进”时，不要把提问流程机械执行成阻塞。 此时改为 **静默设计简报**： - 先在内部补齐 `purpose / audience / constraints / options / chosen direction / assumptions` - 用 2-3 个候选方向做快速比较，但只把最终选定方向和关键取舍写给用户 - 设计阶段仍然必须先于实现，只是“讨论”改为内部完成、对外输出结论 - 如果已有项目或设计系统足够清晰，直接基于现有上下文收敛方案，不为了提问而提问 --- ## 工作流程 ### 步骤 1：理解项目状态 **在提问或静默设计前**，先检查： 1. **项目结构** ```bash ls -la find . -name "*.md" -o -name "*.txt" | head -20 ``` 2. **现有文档** - README.md 是否存在？ - 是否有 docs/ 目录？ - 是否有设计文档？ 3. **最近提交** ```bash git l...