--- name: brainstorming description: 当用户明确要求"使用 brainstorming"或"使用 awesome-code"时使用。⚠️ 不适用：用户只是想优化/改进某个功能（应直接修改）、只是询问技能问题（应直接回答）、没有明确使用 brainstorming/awesome-code 的一般性开发。 metadata: short-description: 交互式设计优化 keywords: - brainstorming - awesome-code - 交互式设计 category: 设计 author: Bensz Conan platform: Claude Code | OpenAI Codex | ChatGPT iron-law: | NO IMPLEMENTATION WITHOUT DESIGN DISCUSSION FIRST --- # 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 log --oneline -10 git diff HEAD~1 ``` **目标**：建立上下文，避免重复提问 --- ### 步骤 2：逐一提问 **提问原则**： 1. **一次只问一个问题** - ❌ 坏："你需要什么功能？用什么技术栈？什么时候完成？" - ✅ 好："你想要实现什么功能？" 2. **优先选择题** - ❌ 坏："你需要什么类型的用户认证？" - ✅ 好："用户认证你希望用哪一种？" - A. JWT Token（推荐：无状态、跨平台） - B. Session Cookie（简单：传统 Web 应用） - C. OAuth 第三方登录（社交登录场景） - D. 其他（请说明） 3. **探索替代方案** - ❌ 坏："好的，我们用 JWT 实现。" - ✅ 好："对于用户认证，我建议考虑以下方案：" - **方案 A：JWT Token**（推荐） - 优势：无状态、跨平台、移动端友好 - 劣势：需要管理过期和刷新 - **方案 B：Session Cookie** - 优势：简单、服务器控制 - 劣势：有状态、不适合微服务 - **方案 C：无认证**（如果适用） - 优势：最简单 - 劣势：无安全控制 - **推荐方案 A**，因为你的项目需要支持移动端。 --- ### 步骤 3：分段呈现设计 **每次 200-300 词，每段后确认**： ```markdown ## 设计文档 - [功能名称] ### 概述 [200-300 词的功能概述] **这段描述是否正确？** ### 数据模型 [200-300 词的数据模型设计] **这个数据模型是否满足你的需求？** ### API 设计 [200-300 词的 API 设计] **这些接口是否足够？还需要其他接口吗？** ### 技术选型 [200-300 词的技术选型说明] **你同意这个技术栈吗？有其他偏好吗？** ``` **关键点**： - ✅ 每段后等待用户确认 - ✅ 用粗体标记问题 - ✅ 提供具体示例 - ❌ 不一次性呈现完整设计 --- ### 步骤 4：YAGNI 无情移除 **在最终确认前**，主动提问： ```markdown ## YAGNI 检查 我注意到设计中包含了以下功能： - [ ] 功能 A - [ ] 功能 B - [ ] 功能 C **问题**： 1. 功能 A 是否是 MVP 必需？能否延后到 v2.0？ 2. 功能 B 是否有真实使用场景？还是"可能有需要"？ 3. 功能 C 是否简化了？能否用更简单的方案替代？ **YAGNI 原则**：只实现当前明确需要的功能。 ``` **实践要点**： - ✅ 主动质疑每个功能 - ✅ 提供"延后实现"选项 - ✅ 推荐最简单可行方案 - ❌ 不保留"可能有需要"的功能 --- ### 步骤 5：保存设计文档 **设计确认后**，保存到 `docs/plans/`： ```bash # 创建目录 mkdir -p docs/plans # 保存设计文档 docs/plans/YYYY-MM-DD--[feature-name]-design.md ``` **文档模板**： ```markdown # [功能名称] 设计文档 **创建日期**：YYYY-MM-DD **状态**：已确认 / 待确认 ## 概述 [功能概述] ## 需求 [用户需求] ## 方案对比 ### 方案 A - 优势： - 劣势： ### 方案 B - 优势： - 劣势： **选择方案 A，因为...** ## 数据模型 [数据模型设计] ## API 设计 [API 接口设计] ## 技术选型 [技术栈选择] ## 实现计划 [简要实现步骤] ## YAGNI 移除项 以下功能考虑过但移除： - 功能 X：原因... - 功能 Y：原因... --- **设计者**：AI Agent **确认者**：用户 ``` --- ## 何时使用本技能 在以下场景时激活： - 🎨 **创建新功能**：任何新功能开发前 - 🔧 **修改现有行为**：改变功能行为前 - 🏗️ **构建新组件**：UI/架构组件设计前 - 📋 **添加功能**：任何代码编写前 - 🤔 **需求不明确**：用户需求模糊时 **何时不需要使用**： - ❌ 修复 Bug（使用 systematic-debugging） - ❌ 重构代码（已有设计，只需优化） - ❌ 简单重命名（ trivial 变更） - ❌ 文档更新（非功能性变更） --- ## 提问模板库 ### 功能需求提问 ``` 你想要实现什么功能？ A. 用户可以 [具体行为]（推荐） B. 系统自动 [具体行为] C. 其他（请说明） 这个功能的主要用户是谁？ A. 终端用户（推荐：关注易用性） B. 管理员（推荐：关注效率） C. 开发者（推荐：关注可扩展性） ``` ### 技术选型提问 ``` 对于 [功能]，我建议考虑以下方案： **方案 A：[技术1]**（推荐） - 优势：[具体优势] - 劣势：[具体劣势] **方案 B：[技术2]** - 优势：[具体优势] - 劣势：[具体劣势] 你倾向于哪个方案？或者有其他想法？ ``` ### YAGNI 检查提问 ``` 我注意到设计中包含了 [功能 X]。 **问题**：这个功能是否是 MVP 必需？ A. 是的，必须有（请说明原因） B. 可以延后到 v2.0（推荐：简化 MVP） C. 完全不需要（YAGNI：移除） ``` --- ## 常见问题 ### Q1: 用户说"没时间讨论"怎么办？ **A**: 宁可等待也不浪费开发时间。 **回应策略**： ```markdown 我理解时间紧迫。但错误实现浪费的时间远超设计讨论时间。 我建议： 1. 用 5 分钟快速确认核心需求（只问关键问题） 2. 我提供 2-3 个方案供你选择（选择题，快速决策） 3. 确认后立即开始实现 这样可以避免"开发两周后发现方向错误"的情况。 ``` ### Q2: 用户说"你看着办"怎么办？ **A**: "看着办"≠"任意办"。仍需确认核心决策。 **回应策略**： ```markdown 我理解你希望我自主决策。但在开始前，我需要确认几个关键点： 1. **核心目标**：这个功能主要解决什么问题？ 2. **约束条件**：有时间/技术/资源限制吗？ 3. **优先级**：速度优先还是质量优先？ 确认这些后，我会提供完整的设计方案供你确认。 ``` ### Q3: 设计讨论需要多长时间？ **A**: - **简单功能**：5-10 分钟（3-5 个问题） - **中等功能**：15-20 分钟（5-10 个问题） - **复杂功能**：30+ 分钟（多轮讨论） **节省时间技巧**： - 使用选择题（快速响应） - 分段确认（避免返工） - YAGNI 移除（减少实现时间） --- ## 验证清单 设计确认后，检查： - [ ] 用户需求已明确 - [ ] 已探索 2-3 个替代方案 - [ ] 用户已确认选择方案 - [ ] 数据模型已设计 - [ ] API 接口已定义 - [ ] 技术选型已确认 - [ ] YAGNI 检查已完成（移除非必要功能） - [ ] 设计文档已保存到 `docs/plans/` - [ ] 用户已最终确认设计 --- ## 相关参考 - [writing-plans](../writing-plans/SKILL.md) - 设计确认后，编写详细实现计划 - [tdd-workflow](../tdd-workflow/SKILL.md) - 使用 TDD 实现设计 - [systematic-debugging](../systematic-debugging/SKILL.md) - 调试实现中的问题 **注意**：`writing-plans` 技能需要配合 `executing-plans` 或 `subagent-driven-development` 使用。 ## 约束 ### 公共硬约束 本块由 `docs/templates/skill-common-constraints.md` 统一维护；每个 `SKILL.md` 的 `## 约束` 必须逐字同步本块，不得在副本中改写公共规则。 - 任务需要落盘时，使用唯一的 `./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/` 根目录；共享材料放入 `shared/`，Skill 专属材料放入该 Skill 的 `input/`、`output/`、`log/`。 - 正式交付物、源代码和正式计划按项目约定保存，不写入任务工作区；未经授权不覆盖、删除、迁移或远程写入。 - 项目维护变更检查 BAC 可用性并记录需求、AI 产出、工具结果、文件改动和验证摘要；BAC 只做过程审计，不替代署名、责任或合规判断。 - 不记录 API Key、访问令牌、密码、Cookie、环境/凭据文件、私有 Prompt、身份信息、本地用户名、主机名或不必要的大体积原始数据。 - 文件路径必须规范化并限制在授权项目范围内；外部 URL、子进程和网络访问遵循最小权限，防止路径遍历、SSRF 和命令注入。 - Skill 版本唯一记录在自身 `config.yaml:skill_info.version`；公开 API、协议、目录或配置变更同步文档与 `CHANGELOG.md`。 - `bensz-collect-bugs` 是一个 Agent Skill；仅将 Bensz Agent Skill 或 Bensz 基础设施本身的设计缺陷交给它。先脱敏写入 `~/.bensz-skills/bugs/`，当前任务不中断，只有用户明确要求才公开上报，禁止直接修改用户已安装的 Skill 源码。