Brainstorm

头脑风暴引擎 (Brainstorm v2.0)

版本: 2.0.0 | 角色: AI-DDD 协作思考的核心载体 更新: 重构为简洁对话式设计，参考 Superpowers 最佳实践

快速开始

使用场景

• 需求还不清晰，需要多轮讨论澄清
• 需要在多个方案之间做选择
• 需要探索问题的本质而非急于实现

不使用场景

• 需求明确，直接进入实现 → 使用 phase-b-developer
• 简单 bug 修复 → 使用 quick-fix

核心原则

执行流程

阶段 1: 理解想法 (Understanding)

步骤:
  1. 检查项目状态:
     - 读取文件、文档、最近提交

  2. 一次问一个问题:
     - 优先使用多选题
     - 开放式问题也可接受
     - 每条消息只问一个问题

  3. 了解重点:
     - 目的 (Purpose)
     - 约束 (Constraints)
     - 成功标准 (Success Criteria)

示例对话:
  AI: 这个功能的主要目的是什么？
      a) 提高用户参与度
      b) 减少操作步骤
      c) 其他 (请说明)

  用户: b

  AI: 想要减少哪些操作的具体步骤？

阶段 2: 探索方案 (Exploring)

步骤:
  1. 提出 2-3 个方案:
     - 每个方案的描述
     - 优缺点对比
     - 约束匹配度

  2. 对话式展示:
     - 说明推荐选项
     - 解释推荐理由

  3. 等待用户选择或反馈

示例对话:
  AI: 我考虑了三种方案：

      方案 A: 简化流程
      优点: 快速实现，用户学习成本低
      缺点: 功能受限

      方案 B: 智能默认值
      优点: 平衡功能和复杂度
      缺点: 需要数据积累

      方案 C: 渐进式引导
      优点: 灵活性高
      缺点: 实现复杂

      我推荐方案 B，因为...

阶段 3: 展示设计 (Presenting)

步骤:
  1. 确认理解后开始展示设计

  2. 分段展示 (每段 200-300 词):
     - 架构概述
     - 核心组件
     - 数据流
     - 错误处理
     - 测试策略

  3. 每段后验证:
     - "这样对吗？"
     - "需要调整吗？"
     - 等待反馈再继续

  4. 随时准备回退澄清

示例对话:
  AI: [展示架构概述 200-300 词]

      这样的架构安排看起来对吗？

  用户: 某个组件不清楚

  AI: [回退澄清该组件]

阶段 3 完成后: post_brainstorm 审计检查点

触发条件: audit.enabled == true AND audit.checkpoints.post_brainstorm != "off"

执行:
  调用 audit-engine:
    checkpoint: "post_brainstorm"
    mode: 来自 config (audit.mode) 或 adaptive
    context: 本次头脑风暴生成的决策记录文件路径  # 如 .aria/brainstorm-{id}.md 或 docs/decisions/DEC-*.md

  if verdict == FAIL:
    → 阻塞输出文件写入，呈现审计报告，等待用户决策
  else (PASS / PASS_WITH_WARNINGS):
    → 继续写入输出文件

context 类型契约 (#17 Drift Guard): post_brainstorm audit 的 context 必须传决策记录文件路径 (非 Forgejo issue URL) — audit-engine Step 0 anchor 提取器据此识别"已确认决策"段 → in_scope、"DEFERRED" 条目 → out_of_scope_hints、核心议题 → primary_goal (与 audit-engine SKILL.md Step 0 post_brainstorm 调用契约对齐); context 为 issue URL 时降级 issue_title anchor。

不可协商规则

对话控制:
  - 每次只能问 1 个问题
  - 必须等待用户回答再继续
  - 禁止一次性生成所有 User Stories
  - 禁止跳过验证步骤

设计验证:
  - 设计必须分段展示 (200-300 词/段)
  - 每段后必须询问反馈
  - 用户不满意必须调整或回退

输出控制:
  - 理解阶段不输出任何文件
  - 设计阶段分段输出并验证
  - 最终确认后才写入文件

输出规范

Requirements 模式输出

主要输出:
  - docs/decisions/requirements-{id}.md

可选输出:
  - docs/requirements/user-stories/US-*.md (逐个确认后创建)

User Story 模板:
  ## US-{序号}: {标题}
  > **优先级**: P{0-3} | **状态**: Ready

  **描述**: 作为 {角色}，我想要 {功能}，以便 {价值}

  **验收标准**:
  - [ ] {标准1}
  - [ ] {标准2}

Decision 模板

# 决策: DEC-{YYYYMMDD}-{序号} - {标题}

> **日期**: {date} | **模式**: {mode}

## 背景
{背景描述}

## 约束条件
| 类型 | 约束 | 影响 |
|------|------|------|

## 考虑的方案
| 方案 | 描述 | 评分 | 状态 |
|------|------|------|------|

## 最终选择
**方案**: {selected}

## 理由
1. {理由1}
2. {理由2}

## 风险与缓解
| 风险 | 缓解措施 |
|------|----------|

模式说明

problem 模式

• 触发: 用户输入模糊，新功能想法
• 目标: 澄清问题本质
• 输出: problem-definition.md

requirements 模式

• 触发: PRD 创建，功能分解
• 目标: 分解为 User Stories
• 输出: requirements-{id}.md + user-stories/

technical 模式

• 触发: OpenSpec 创建前，架构选型
• 目标: 技术方案设计
• 输出: technical-{id}.md + proposal.md 草案

错误处理

相关文档

详细参考文档见 references/ 目录:

• principles.md - 核心原则详解
• question-patterns.md - 提问模式库
• decision-workflow.md - 决策记录流程

集成

state-scanner 集成

触发: 检测到模糊需求，复杂度 >= Level 2
推荐: "发现新功能想法，建议先进行头脑风暴"

spec-drafter 集成

输入: 决策记录 + 约束条件 + 方案选择
行为: 自动填充 proposal.md，引用决策 ID

最后更新: 2026-06-11 (#17 audit-drift-guard — Drift Guard 原始目的锚定) Skill版本: 2.0.0 (基于 Superpowers 最佳实践重构)