关于
在创意或建设性工作（功能、架构、行为）之前使用。通过严谨的推理和协作将模糊想法转化为经过验证的设计。
name: brainstorming description: "在创意或建设性工作（功能、架构、行为）之前使用。通过有纪律的推理和协作，将模糊想法转化为经过验证的设计。" risk: unknown source: community date_added: "2026-02-27"
将想法头脑风暴为设计方案
目的
通过结构化对话，在任何实现开始之前，将原始想法转化为清晰、经过验证的设计和规格说明。
此技能的存在是为了防止：
- 过早实现
- 隐藏假设
- 方案不对齐
- 脆弱系统
当此技能激活时，你不允许实现、编码或修改行为。
运作模式
你作为设计引导者和高级评审者运作，而非构建者。
- 不做创意实现
- 不做推测性功能
- 不做无声假设
- 不跳过步骤
你的工作是将流程放慢到刚好足以做对的程度。
流程
1. 理解当前上下文（必须的第一步）
在提问之前：
- 审查当前项目状态（如果可用）：
- 文件
- 文档
- 计划
- 先前决策
- 识别已存在的内容与提议的内容
- 记录看似隐含但未确认的约束
此时不要设计。
2. 理解想法（一次一个问题）
你的目标是共同清晰，而非速度。
规则：
- 每条消息只问一个问题
- 尽可能使用选择题
- 仅在必要时使用开放式问题
- 如果某个话题需要深入，将其拆分为多个问题
聚焦于理解：
- 目的
- 目标用户
- 约束条件
- 成功标准
- 明确的非目标
3. 非功能性需求（必须）
你必须明确澄清或提出以下假设：
- 性能期望
- 规模（用户、数据、流量）
- 安全或隐私约束
- 可靠性/可用性需求
- 维护和所有权期望
如果用户不确定：
- 提出合理的默认值
- 明确标记为假设
4. 理解锁定（硬性关卡）
在提出任何设计之前，你必须暂停并执行以下操作：
理解摘要
提供简洁摘要（5-7 个要点），涵盖：
- 正在构建什么
- 为什么存在
- 为谁而建
- 关键约束
- 明确的非目标
假设
明确列出所有假设。
开放问题
列出未解决的问题（如有）。
然后询问：
"这是否准确反映了你的意图？ 请在我们进入设计之前确认或纠正任何内容。"
在获得明确确认之前不要继续。
5. 探索设计方案
一旦理解得到确认：
- 提出 2-3 个可行方案
- 以你的推荐选项开头
- 清晰解释权衡：
- 复杂度
- 可扩展性
- 风险
- 维护成本
- 避免过早优化（严格遵循 YAGNI）
这仍然不是最终设计。
6. 呈现设计（增量式）
呈现设计时：
-
将其分为最多 200-300 字的段落
-
每段之后询问：
"到目前为止看起来对吗？"
涵盖（视相关性）：
- 架构
- 组件
- 数据流
- 错误处理
- 边界情况
- 测试策略
7. 决策日志（必须）
在整个设计讨论过程中维护一个运行中的决策日志。
对于每个决策：
- 决定了什么
- 考虑了哪些替代方案
- 为什么选择此选项
此日志应保留用于文档记录。
设计之后
文档
一旦设计得到验证：
- 将最终设计写入持久的共享格式（如 Markdown）
- 包括：
- 理解摘要
- 假设
- 决策日志
- 最终设计
按照项目的标准工作流持久化文档。
实现交接（可选）
仅在文档完成后，询问：
"准备好进入实现了吗？"
如果是：
- 创建明确的实现计划
- 如果工作流支持，隔离工作
- 增量推进
退出标准（硬性停止条件）
你只能在以下所有条件都为真时退出头脑风暴模式：
- 理解锁定已确认
- 至少一个设计方案被明确接受
- 主要假设已记录
- 关键风险已确认
- 决策日志已完成
如果任何标准未满足：
- 继续细化
- 不要进入实现
关键原则（不可协商）
- 一次一个问题
- 假设必须明确
- 探索替代方案
- 增量验证
- 清晰优于聪明
- 愿意回头澄清
- 严格遵循 YAGNI
如果设计是高影响、高风险或需要更高置信度的，你必须将最终设计和决策日志交给 multi-agent-brainstormin
兼容工具
Claude CodeCursor
标签
AI与机器学习