Brainstorming

Brainstorming - 交互式设计优化

铁律

NO IMPLEMENTATION WITHOUT DESIGN DISCUSSION FIRST

违反规则的信件就是违反规则的精神。

无例外：

• 不跳过设计阶段直接编码
• 不基于模糊需求直接实现
• 不在用户确认前开始编码
• YAGNI（You Aren't Gonna Need It）无情移除非必要功能

常见合理化

红色标志 - 停止并重新开始

• "需求很明确，直接开始"
• "先写个原型再说"
• "用户没时间讨论"
• "这很简单不需要设计"
• "我理解用户意图"
• 跳过设计讨论直接编码

所有这些意味着：停止编码。回到设计讨论阶段。

核心原则

Brainstorming 是一种通过苏格拉底式提问来探索用户意图、明确需求、对比方案的设计方法。

┌─────────────────────────────────────────────────────────┐
│  理解项目状态 → 逐一提问 → 探索方案 → 分段呈现 → 保存设计  │
└─────────────────────────────────────────────────────────┘

核心原则：

• 一次一个问题：不要用多个问题压倒用户
• 多选题优先：选择题比开放式问题更容易回答
• 探索替代方案：在确定前总是提出 2-3 个方案
• 增量验证：分段展示设计，逐段确认
• YAGNI 无情：从所有设计中移除非必要功能

自主模式

当用户明确要求“不要反复确认”“自己选最优方案”“直接推进”时，不要把提问流程机械执行成阻塞。

此时改为 静默设计简报：

• 先在内部补齐 purpose / audience / constraints / options / chosen direction / assumptions
• 用 2-3 个候选方向做快速比较，但只把最终选定方向和关键取舍写给用户
• 设计阶段仍然必须先于实现，只是“讨论”改为内部完成、对外输出结论
• 如果已有项目或设计系统足够清晰，直接基于现有上下文收敛方案，不为了提问而提问

工作流程

步骤 1：理解项目状态

在提问或静默设计前，先检查：

1. 项目结构

   ls -la
   find . -name "*.md" -o -name "*.txt" | head -20
   

2. 现有文档

   • README.md 是否存在？
   • 是否有 docs/ 目录？
   • 是否有设计文档？

3. 最近提交

   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 词，每段后确认：

## 设计文档 - [功能名称]

### 概述

[200-300 词的功能概述]

**这段描述是否正确？**

### 数据模型

[200-300 词的数据模型设计]

**这个数据模型是否满足你的需求？**

### API 设计

[200-300 词的 API 设计]

**这些接口是否足够？还需要其他接口吗？**

### 技术选型

[200-300 词的技术选型说明]

**你同意这个技术栈吗？有其他偏好吗？**

关键点：

• ✅ 每段后等待用户确认
• ✅ 用粗体标记问题
• ✅ 提供具体示例
• ❌ 不一次性呈现完整设计

步骤 4：YAGNI 无情移除

在最终确认前，主动提问：

## YAGNI 检查

我注意到设计中包含了以下功能：
- [ ] 功能 A
- [ ] 功能 B
- [ ] 功能 C

**问题**：
1. 功能 A 是否是 MVP 必需？能否延后到 v2.0？
2. 功能 B 是否有真实使用场景？还是"可能有需要"？
3. 功能 C 是否简化了？能否用更简单的方案替代？

**YAGNI 原则**：只实现当前明确需要的功能。

实践要点：

• ✅ 主动质疑每个功能
• ✅ 提供"延后实现"选项
• ✅ 推荐最简单可行方案
• ❌ 不保留"可能有需要"的功能

步骤 5：保存设计文档

设计确认后，保存到 docs/plans/：

# 创建目录
mkdir -p docs/plans

# 保存设计文档
docs/plans/YYYY-MM-DD--[feature-name]-design.md

文档模板：

# [功能名称] 设计文档

**创建日期**：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: 宁可等待也不浪费开发时间。

回应策略：

我理解时间紧迫。但错误实现浪费的时间远超设计讨论时间。

我建议：
1. 用 5 分钟快速确认核心需求（只问关键问题）
2. 我提供 2-3 个方案供你选择（选择题，快速决策）
3. 确认后立即开始实现

这样可以避免"开发两周后发现方向错误"的情况。

Q2: 用户说"你看着办"怎么办？

A: "看着办"≠"任意办"。仍需确认核心决策。

回应策略：

我理解你希望我自主决策。但在开始前，我需要确认几个关键点：

1. **核心目标**：这个功能主要解决什么问题？
2. **约束条件**：有时间/技术/资源限制吗？
3. **优先级**：速度优先还是质量优先？

确认这些后，我会提供完整的设计方案供你确认。

Q3: 设计讨论需要多长时间？

A:

• 简单功能：5-10 分钟（3-5 个问题）
• 中等功能：15-20 分钟（5-10 个问题）
• 复杂功能：30+ 分钟（多轮讨论）

节省时间技巧：

• 使用选择题（快速响应）
• 分段确认（避免返工）
• YAGNI 移除（减少实现时间）

验证清单

设计确认后，检查：

• 用户需求已明确
• 已探索 2-3 个替代方案
• 用户已确认选择方案
• 数据模型已设计
• API 接口已定义
• 技术选型已确认
• YAGNI 检查已完成（移除非必要功能）
• 设计文档已保存到 docs/plans/
• 用户已最终确认设计

相关参考

• writing-plans - 设计确认后，编写详细实现计划
• tdd-workflow - 使用 TDD 实现设计
• systematic-debugging - 调试实现中的问题

注意：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 源码。