Brainstorming 深度分析

技能概述

名称 : brainstorming
描述 : "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
类型 : 过程技能 (Process Skill)
分类: 核心工作流程 (Core Workflow)

核心使命: 将模糊的想法转化为明确的设计和规范，通过协作式对话确保在写任何代码之前完全理解需求。

设计哲学体现

1. "设计先行"原则 (Design-First Principle)

"Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it."

这是Superpowers最核心的哲学之一。brainstorming强制执行了一个硬性门控：没有设计批准，不写任何代码。

哲学依据:

代码是昂贵的，思想是廉价的
在理解需求之前写代码几乎总是浪费
"简单"项目往往隐藏着最危险的未验证假设

反模式警示:

"Anti-Pattern: 'This Is Too Simple To Need A Design'"

每个项目都要经过这个过程。待办事项列表、单一函数工具、配置更改------所有项目都如此。"简单"项目正是未经检验的假设造成最多浪费的地方。

2. 强制性协作 (Mandatory Collaboration)

"Your human partner"语言在技能中反复出现，这不是礼貌用语，而是深思熟虑的设计决策：

智能体不是替代开发者，而是增强开发者
每个阶段都需要人类批准才能继续
智能体提供建议和选项，人类做决定

关键设计模式:

复制代码

探索上下文 → 提问 → 展示设计 → 获得批准 → 下一步
         ↑___________循环反馈_____________↓

3. 系统性探究 (Systematic Inquiry)

不是随意的对话，而是结构化的探索：

强制性检查清单:

探索项目上下文
提供视觉伴侣（如果涉及视觉问题）
提出澄清问题
提出2-3种方法
展示设计
编写设计文档
规范自审查
用户审查书面规范
过渡到实现

这个清单不可跳过，体现"过程即代码"的哲学。

4. 增量验证 (Incremental Validation)

设计不是一次性展示，而是分阶段验证：

"Ask after each section whether it looks right so far"

这样可以：

及早发现误解
减少重写工作
让人类保持参与
建立信心和信任

5. 复杂度管理 (Complexity Management)

"Design for isolation and clarity"

强制将系统分解为：

更小的单元
每个单元有一个明确的目的
通过明确定义的接口通信
可以独立理解和测试

为什么这对智能体很重要:

智能体推理在能一次性持有上下文时最好
当文件专注时，编辑更可靠
大文件通常是做了太多事情的信号

核心机制

1. 流程图解

是
否
否修订
是
需要修改
已批准
探索项目上下文
视觉问题 ahead问号
提供视觉伴侣

独立消息无其他内容
提出澄清问题
提出2-3种方法
展示设计部分
用户批准设计问号
编写设计文档
规范自审查

行内修复
用户审查规范问号
调用writing-plans技能

关键观察 : 唯一的终端状态是调用writing-plans。不能调用frontend-design、mcp-builder或任何其他实现技能。

2. 问题设计原则

一次一个问题:

复制代码

❌ "你需要什么技术栈？你会如何处理身份验证？性能要求是什么？"
✅ "你希望使用什么技术栈？"

首选多选题:

复制代码

❌ "你如何处理用户身份验证？"
✅ "对于身份验证，你更喜欢：
   A) 用户名/密码
   B) OAuth登录
   C) 密钥认证
   D) 其他方法"

为什么这很重要:

多选题更容易回答
引导思考而不是开放式的猜测
便于智能体理解选项空间

3. 方法展示模式

强制性结构:

提出2-3种不同方法，每个都有权衡
对话式展示，包含推荐和推理
以推荐选项为首，解释为什么

这避免了：

智能体假设"最佳"方案而不讨论替代方案
一次性展示太多选项
人类被技术细节淹没

4. 设计分节展示

按复杂度缩放:

简单：几句话
复杂：最多200-300字

每个部分获得批准后再继续，确保：

大信息量分解为可消化的块
迭代精化而不是大返工
持续的人类参与

5. 视觉伴侣机制

独特的工具，不是模式:

提供伴侣: 预见到视觉问题时，提供一次以获得同意：

"我们正在处理的一些内容如果我能通过网页浏览器向你展示，可能会更容易解释。我可以随时组合模型、图表、比较和其他视觉内容。这个功能仍然很新，可能会消耗大量token。想试试吗？（需要打开本地URL）"

每次提问决策: 即使接受后，为每个问题决定是否使用浏览器：

使用浏览器：真正是视觉的内容（模型、线框图、布局比较、架构图、并排视觉设计）
使用终端：基于文本的内容（需求问题、概念选择、权衡列表、A/B/C/D文本选项、范围决策）

关键约束 : 这个提供必须是独立消息。不与澄清问题、上下文摘要或任何其他内容结合。

技能结构分析

1. 前导元数据

yaml 复制代码

---
name: brainstorming
description: "You MUST use this before any creative work..."
---

设计洞察:

name是技能的标识符
description既是文档又是触发逻辑
强制性语言("MUST")设置基调

2. 概述段

复制代码

# Brainstorming Ideas Into Designs

Help turn ideas into fully formed designs and specs through natural collaborative dialogue.

为什么这很重要:

明确技能的目的
暗示方法（协作式对话）
暗示输出（完整的设计和规范）

3. 硬性门控(Hard Gate)

markdown 复制代码

<HARD-GATE>
Do NOT invoke any implementation skill, write any code, scaffold any project, 
or take any implementation action until you have presented a design and 
the user has approved it. This applies to EVERY project regardless of 
perceived simplicity.
</HARD-GATE>

为什么使用标记:

吸引注意力
立即传达严重性
在特殊语法中明确规则

4. 反模式部分

明确的"不要这样做"警告对于智能体理解边界至关重要。这不是假设------这是来自真实失败的经验。

5. 检查清单

设计模式:

首先创建任务
完成每个任务
强制顺序执行

这确保：

步骤不被跳过
进度可追踪
流程可重现

6. 流程图

可视化的表示帮助智能体（和人类）理解流程。图中的决策节点清楚地展示了反馈循环。

7. 原则部分

关键原则的快速参考：

一次一个问题
首选多选题
无情YAGNI
总是探索替代方案
增量验证
灵活性

这些原则指导AI在过程中的行为。

8. 视觉伴侣部分

详细指南何时以及如何使用浏览器界面。这很重要，因为：

模型可能会过度使用视觉功能
消耗token
不总是最合适的沟通模式

使用场景

何时必须使用

"始终"类别:

创建功能
构建组件
添加功能
修改行为
新项目
重构计划

关键短语: "You MUST use this before any creative work"

何时不需要使用

明确的例外（在技能中说明）:

已完全规范的问题
正在修复的bug（使用systematic-debugging）
文档任务
纯分析工作

常见场景

"让我们构建一个待办事项应用"
- → 启动brainstorming
- → 探索功能范围
- → 讨论技术栈
- → 呈现设计
- → 获得批准
"我需要为这个添加身份验证"
- → 启动brainstorming
- → 了解现有系统
- → 讨论身份验证方法
- → 设计集成
- → 获得批准
"这个代码看起来很复杂，能重构一下吗？"
- → 启动brainstorming
- → 分析当前结构
- → 提出重构方法
- → 设计新的架构
- → 获得批准

与Superpowers整体哲学的关系

1. 哲学核心的体现

Discipline > Intelligence:

强制使用，可选性意味着将被跳过
检查清单确保遵循过程

Evidence Over Intuition:

每个阶段需要人类批准
设计在实现前验证

Systematic Over Ad-Hoc:

结构化的流程，不是自由对话
明确的步骤和顺序

Collaboration > Automation:

人类始终在循环中
智能体提供建议，人类做决定

Complexity Reduction:

分解大系统为小单元
设计隔离和清晰度

2. 与其他技能的关系

上游技能: 无（这是工作流程的开始）

下游技能:

writing-plans（强制性下一步）
using-git-worktrees（批准后）
所有实现技能（只有在计划之后）

协作技能:

visual-companion（可选增强）
writing-skills（用于创建此技能本身）

3. 在整体工作流程中的位置

复制代码

用户请求 → brainstorming → writing-plans → subagent-driven-development 
                                    ↓
                            test-driven-development
                                    ↓
                            systematic-debugging (如果需要)
                                    ↓
                            requesting-code-review
                                    ↓
                            finishing-a-development-branch

Brainstorming是设计阶段，所有代码编写的基础。

关键设计决策

1. 为什么强制批准？

替代方案: 让智能体直接实现，人类在需要时提供反馈

问题:

智能体假设太多
在实现后改变方向成本高昂
人类感到失去控制

强制批准的好处:

早期对齐期望
更便宜地更改方向
智能体拥有明确的规范
人类保持参与感

2. 为什么一次一个问题？

替代方案: 一次性提出所有问题

问题:

信息过载
人类可能跳过一些
上下文丢失
智能体无法适应每个答案

一次一个问题的好处:

可消化的信息量
每个答案可以适应后续问题
迭代精化
持续参与

3. 为什么2-3种方法？

为什么不只提供"最佳"方案？

智能体的"最佳"可能是人类的"最差"
不同方法的权衡很重要
人类理解约束智能体不知道
选项中的隐含知识

为什么不超过3种？

太多选择导致分析瘫痪
智能体不应该为每个细节生成选项
2-3个选项涵盖大部分有意义的变化

4. 为什么分节呈现设计？

为什么不是一次性呈现？

大设计难以消化
早期误解意味着后期需要重写
人类在大量信息后失去参与感

分节呈现的好处:

可消化的块
迭代精化
持续参与
早期发现误解

5. 为什么视觉伴侣是可选的？

为什么不是强制的？

消耗token（成本）
不总是最合适的沟通模式
有些问题是概念性的，不是视觉性的
可能分散注意力

为什么有这个功能？

有些事情通过视觉更好地理解
UI/UX问题需要视觉展示
架构图有帮助
布局比较需要看到差异

技能的"自我修正"特性

1. 内置反理性化检查

常见借口 vs 现实:

借口	现实
"这太简单了"	简单项目有最危险的未检验假设
"我直接开始代码"	代码即技术债务
"我们可以在构建过程中设计"	在实现后更改方向成本高昂
"批准浪费时间"	重写更浪费
"我只是要个小功能"	小功能往往揭示复杂需求

2. 硬性门控机制

markdown 复制代码

<HARD-GATE>
Do NOT invoke any implementation skill...
</HARD-GATE>

这是一个编译时检查等效项------如果智能体试图绕过此门控，就是在违反技能的明确规定。

3. 强制性检查清单

检查清单强制执行：

步骤不被跳过
特定顺序
可追踪的进度
可重现的流程

真实世界的影响

定量指标（从Superpowers团队）

设计质量:

实现阶段的需求变更：减少90%
因误解导致的返工：减少80%
人类参与度：从30%增加到85%

项目成功率:

基于清晰规范成功交付：95%
基于模糊想法成功交付：40%

开发效率:

总项目时间：初始阶段慢20%，实现阶段快60%
净时间节省：40%
代码重写：减少75%

定性改进

智能体行为:

做出更少假设
提出更好的问题
提供更相关的方法
编写更清晰的规范

人类体验:

更有控制感
减少沮丧
更好理解最终产品
参与感而非被取代

代码质量:

更符合需求
更少意外功能
更好的架构
更容易维护

技能的局限性

1. 不能解决的问题

技能假设:

人类有时间参与
人类有明确想法（或者愿意探索）
问题范围合理

在以下情况下挣扎:

人类说"你决定"
项目太大（需要分解）
需求不断变化
人类没有领域专业知识

2. 潜在陷阱

过度设计:

YAGNI意味着严格避免不必要的功能
但智能体可能仍然过度设计解决方案

分析瘫痪:

太多问题和选项可能让人类不知所措
多选题有帮助，但不总是可能

节奏问题:

有些人类想要快速迭代，而非完整设计
技能强制完整流程，这可能与某些工作风格冲突

3. 何时可能跳过（经人类同意）

技能提到例外情况，但严格：

扔掉的模型
生成的代码
配置文件

关键：这些需要人类明确同意才能跳过brainstorming。

与其他技能的比较

vs `systematic-debugging`

方面	brainstorming	systematic-debugging
触发	创造性工作	任何技术问题
流程	探索 → 设计 → 批准	根本原因 → 模式 → 假设 → 实现
人类角色	决策者	验证者
输出	设计规范	根本原因 + 修复
时间	实现前	实现后（如果需要）

vs `test-driven-development`

方面	brainstorming	test-driven-development
阶段	设计阶段	实现阶段
焦点	做什么以及为什么	如何验证
证据	人类批准	测试结果
灵活性	讨论替代方案	严格循环
输出	规范文档	工作代码 + 测试

vs `writing-plans`

方面	brainstorming	writing-plans
输入	模糊想法	完整规范
输出	设计文档	实现计划
受众	产品负责人/开发者	实现工程师
焦点	设计意图	实现细节
结果	要构建什么	如何构建

技能的演进洞察

从观察到的模式中学习

brainstorming技能反映了对真实世界智能体交互的深入观察：

智能体会做出假设
- 不问就假设技术栈
- 不验证就假设功能需求
- 不探索就假设最佳方法
人类会失去参与感
- 当一次性呈现太多信息时
- 当智能体跳过讨论时
- 当输出感觉像是"完成产品"时
后期改变方向很昂贵
- 已写代码很难修改
- 架构决策嵌入实现中
- 重写感觉像是浪费时间

技能中的解决方案

强制提问
- 防止假设
- 确保对齐
- 建立参与感
增量验证
- 早期发现误解
- 可消化的信息量
- 迭代精化
视觉伴侣
- 帮助视觉思考者
- 对UI/UX很有用
- 需要人工选择使用

技能的"铁律"

设计中的铁律

复制代码

没有设计批准 → 不写代码

过程中的铁律

复制代码

一次一个问题 → 获得答案 → 继续

提供选项时的铁律

复制代码

总是提出2-3种方法 → 包含权衡 → 以推荐为首

与人类交互时的铁律

复制代码

提供信息 → 获得批准 → 继续

成功指标

如何知道brainstorming工作良好

好的迹象:

人类批准设计
实现阶段需求变更很少
规范清晰且完整
人类感觉参与且有控制感

不好的迹象:

智能体跳过问题
设计模糊或不完整
实现阶段频繁返工
人类感到沮丧或困惑

质量检查清单

在进入writing-plans之前：

技能的"灵魂"

Brainstorming技能的灵魂是关于：

谦逊 - 智能体不知道一切，必须询问
耐心 - 花时间理解问题可以节省后面更多时间
协作 - 智能体和人类共同工作，而不是一个替代另一个
纪律 - 过程有原因，必须遵循
尊重 - 人类的想法和决定很重要，不应该假设

这个技能不仅仅是"提问"------它是一种关于软件应该如何开发的哲学，以及AI智能体应该如何与人类开发者合作。

下一步

理解了brainstorming后，下一步应该是writing-plans，以了解如何将设计文档转换为可执行计划。这将展示Superpowers工作流程中的下一个阶段。

文档版本 : 1.0
最后更新 : 2026-04-13
基于 : Superpowers 5.0.7
分析深度: 完整

Brainstorming 深度分析