brainstorming

# Brainstorming - 交互式设计优化 ## BenszAPI 任务工作区 本 Skill 的新任务中间文件统一写入 `./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/{skill名}/input|output|log/`。同一任务复用一个任务根目录；多 Skill 协作才创建 `shared/`。正式交付物不写入该目录，历史隐藏目录只允许显式兼容读取、迁移或清理。 ## 与 bensz-collect-bugs 的协作约定 - 因本 skill 设计缺陷导致的 bug，先用 `bensz-collect-bugs` 规范记录到 `~/.bensz-skills/bugs/`，不要直接修改用户本地已安装的 skill 源码；若有 workaround，先记 bug，再继续完成任务。 - 只有用户明确要求“report bensz skills bugs”等公开上报时，才用本地 `gh` 上传新增 bug 到 `huangwb8/bensz-bugs`；不要 pull / clone 整个仓库。 ## 铁律 ``` NO IMPLEMENTATION WITHOUT DESIGN DISCUSSION FIRST ``` **违反规则的信件就是违反规则的精神。** **无例外**： - 不跳过设计阶段直接编码 - 不基于模糊需求直接实现 - 不在用户确认前开始编码 - YAGNI（You Aren't Gonna Need It）无情移除非必要功能 --- ## 常见合理化 | 借口 | 现实 | |------|------| | "需求很明确，直接开始" | 需求"明确"≠需求"正确"。误解成本高于设计讨论成本 | | "先写个原型再说" | 无设计的原型=技术债。重构比从头设计更难 | | "用户没时间讨论" | 宁可等待也不浪费开发时间。错误实现浪费双方时间 | | "这很简单不需要设计" | 简单功能也可能有复杂交互。设计5分钟节省调试5小时 | | "我理解用户意图" | 你理解的≠用户想要的。确认总比假设好 | --- ## 红色标志 - 停止并重新开始 - "需求很明确，直接开始" - "先写个原型再说" - "用户没时间讨论" - "这很简单不需要设计" - "我理解用户意图" - 跳过设计讨论直接编码 **所有这些意味着：停止编码。回到设计讨论阶段。** --- ## 核心原则 **Brainstorming** 是一种通过**苏格拉底式提问**来探索用户意图、明确需求、对比方案的设计方法。 ``` ┌─────────────────────────────────────────────────────────┐ │ 理解项目状态 → 逐一提问 → 探索方案 → 分段呈现 → 保存设计 │ └─────────────────────────────────────────────────────────┘ ``` **核心原则**： - **一次一个问题**：不要用多个问题压倒用户 - **多选题优先**：选择题比开放式问题更容易回答 - **探索替代方案**：在确定前总是提出 2-3 个方案 - **增量验证**：分段展示设计，逐段确认 - **YAGNI 无情**：从所有设计中移除非必要功能 --- ## 自主模式 当用户明确要求“不要反复确认”“自己选最优方案”“直接推进”时，不要把提问流程机械执行成阻塞。 此时改为 *...