[research@ai4se] : ~ $ ▌
cd ../
[process] | | 11 min

# 与 AI 头脑风暴：为什么 Clarify 比 Prompt 更重要

AI 头脑风暴的价值不在让 AI 替你想，而在借 AI 帮你想清楚——掌握发散–收敛节奏、分离问题与方案空间、留下决策日志，比选哪套 brainstorming 工具更重要。

[brainstorming][workflow-design][agentic-engineering][hitl]

同一个 Superpowers brainstorming skill，有人跑完产出一份 design doc，有人聊三轮就直接让 Agent 选了技术栈。工具相同，结果差了一个数量级——差距通常不在模型，而在有没有把头脑风暴当成可学习的流程技能。

主流 AI 开发工作流——Superpowers、GStack、gstack、OpenSpec、Spec Kit——几乎都内置某种形式的 brainstorming / clarify / explore。但业界观察一致：同样一套工具，不同人效果差很大。本文不谈「哪个工具最好」，而谈一套跨工具通用的原则：为什么在 AI 时代头脑风暴更重要、怎样与 coding agent 有效协作、以及哪些 anti-pattern 会让 AI 替你做决定。

一、为什么在 AI 时代，头脑风暴比 Prompt 更重要

人与 AI 协作的核心，是把意图表达清楚。但现实是：人往往只知道自己大概的方向或目标，却说不清——即使脑子里有画面，也很难结构化地写出来。

这并不丢人。没有人一上来就能完整、清晰地陈述自己的意图；**渐进式理解「我到底想做什么」**是合理且常见的过程。传统上，头脑风暴是一种软技能：善于提问、善于收敛、善于在分歧里做决策。不是每个人都擅长，也不是每个团队都有时间练。

有了 AI 和 coding agent 之后，情况变了。你可以通过 skill、workflow 把头脑风暴流程嵌入 Agent 会话——Superpowers 的 brainstorming、GStack 的 Office Hour、OpenSpec 的 explore、Spec Kit 的 clarify，都是把「先澄清再动手」做成可重复步骤。AI 不会替你想出全部答案，但它可以：

  • 追问你没意识到的模糊点
  • 并列多种 framing，逼你看清自己的偏好
  • 记录讨论过程中的选项与取舍

换句话说：AI 头脑风暴的首要价值，不是「让 AI 帮你想」，而是借 AI 帮你想清楚。这和 AI Development Workflows 全景 里 Research→Plan 骨架的定位一致——在 Execute 之前，先把 intent 和 problem 拉直。

二、理论骨架：Double Diamond 与问题 / 方案空间

Double Diamond：两次发散–收敛

UK Design Council 的 Double Diamond 把设计创新过程拆成四个阶段，并明确对应两种思维模式：

阶段思维模式在做什么
Discover发散理解问题，而非假设问题
Define收敛从洞察中提炼、定义挑战
Develop发散针对已定义问题探索多种方案
Deliver收敛小范围测试、筛选、交付

两个 diamond 就是两轮发散–收敛循环。Design Council 强调：这不是线性流程——发现新信息后可能回到起点；早期原型本身也可以是 discovery 的一部分。这与 AI 工作流里「聊完一轮觉得问题定义不对，再开一轮 clarify」完全同构。

问题空间 vs 方案空间

Dan Olsen 在 The Lean Product Playbook 中区分了两个空间：

  • Problem space（问题空间）：用户需要、痛点、待完成任务——不存在具体产品或实现形态
  • Solution space（方案空间）：mockup、原型、功能、技术选型——已是某种具体选择

Indi Young 进一步指出：深度理解 problem space 需要时间，不宜与 solution space 的交付节奏混为一谈（When & Why to Explore the Problem Space）。

映射到 AI 头脑风暴：

  • 第一个 diamond（Discover / Define） 主要在 problem space 里工作：我们要解决什么？为谁？成功标准是什么？
  • 第二个 diamond（Develop / Deliver） 进入 solution space：用什么架构？分几个 phase？验收怎么写？

常见翻车：还没定义问题，就和 Agent 讨论「用 React 还是 Vue」。那是 solution space 的讨论，却缺少 problem space 的收敛产物——Agent 只能猜你的意图，或者替你做决定。

Digital.gov 的 HCD 指南 把两种思维说得很直白：Divergent thinking 探索可能性，暂时放下约束；Convergent thinking 是决策——筛选、聚焦、选定方向。设计阶段的成功，取决于有意识地在这两种模式间切换，而不是只发散或只收敛。

三、AI 工作流里的头脑风暴落点

在 AI Development Workflows 全景 的五步骨架里，brainstorming 落在 Research 与 Plan 的交界：

Research（理解系统与意图）→ Plan（怎么做、怎样证明做完）→ Execute → Review → Ship

头脑风暴主要服务前两步的前半段：在写计划、写 spec、写代码之前，先把「做什么、为什么做」收敛成可记录的决策。

与常见工具的关系可以这样理解——工具是 lens，流程是纪律：

工具 / 能力典型入口在流程中的角色
Superpowers brainstormingskill 触发通用澄清，中立追问，产出 design 确认
GStack Office Hourgear / 模式产品价值视角，偏「这事值不值得做」
OpenSpec explore / propose/opsx:propose规格变更探索，problem 与 delta 对齐
Spec Kit clarifyCLI / 模板需求结构化，补全 spec 字段

它们不是互斥的流水线环节，而是不同 framing lens。Superpowers 更通用；GStack Office Hour 更像投资人视角的价值拷问；OpenSpec 偏 brownfield 变更记忆；Spec Kit 偏 greenfield spec 填空。选哪个 lens，取决于你当前在第一个 diamond 还是第二个、在 problem space 还是 solution space——而不是「哪个工具排名更高」。

若你已经在用 OpenSpec + Superpowers + gstack 三层栈，brainstorming 通常出现在 OpenSpec propose 之前或与之并行：先 Clarify，再落 spec，再进 Superpowers 的 writing-plans 与 TDD 执行链。

四、操作原则：发散–收敛循环与 Decision Log

无论用哪套工具，有效的 AI 头脑风暴都遵循同一套操作纪律。

1. 每一轮发散都要有 exit criteria

发散不是「聊到 Agent 说可以了」。一轮发散结束前，至少应产出：

  • 若干候选 framing（问题可以怎么定义）
  • 若干显式假设（我们认为 X 成立，但未验证）
  • Open questions（还不清楚、下一轮要追的点）

没有 exit criteria 的发散，容易变成闲聊——token 花了，决策没留下。

2. 收敛必须是人参与的决策

ACM CHI 2025 的研究 指出：在 idea selection（收敛）阶段，用户普遍偏好高 human agency——AI 应响应显式反馈与行为，而不是替人拍板。这与 Springer BISE 2025 关于人机头脑风暴的研究 里提到的 social loafing / smart loafing 风险一致：人把思考外包给 AI，整体看似有产出，人的主动决策却在消失。

收敛时你要能回答：

  • 选了什么（一句话决策陈述）
  • 排除了什么（至少列 1–2 个被否选项）
  • 为什么（依据、约束、权衡）
  • 什么还没定（留到下一 diamond 或 Execute 再验证）

3. Decision Log 是最小真相源

聊天记录会消失；context window 会轮转；Agent 换 session 就「失忆」。Decision Log 是头脑风暴的可持久产物——也是后续 Plan、Spec、Execute 的输入。

最小字段建议：

字段含义
Decision本轮回合的最终结论（一句话）
Alternatives considered讨论过但未采纳的选项
Rationale选择理由与关键约束
Open questions尚未关闭的假设或待验证项
Scope本决策覆盖 problem space 还是 solution space

可以写在 OpenSpec 的 design.md、Superpowers 的 design spec、或项目 docs/decisions/ 下——形态不重要，可检索、可引用、可审计才重要。这与 AI4SE 工作坊设计策略 里「决策回写文档、避免收敛时把理由弄丢」是同一原则，只是从「多人漏斗」下沉到「人与 Agent 一对一场景」。

4. 允许 Lazy Loading 式意图

不必一次 load 全部 intent。可以像 项目知识层 里的 Lazy Loading 一样：先收敛 problem space 的核心决策，再按需展开 solution space 的细节。第一轮头脑风暴只回答「我们要解决什么问题、为谁、成功标准是什么」；第二轮再讨论架构与实现路径——只要每轮都有 decision log，渐进式澄清就是 Feature，不是 Bug。

五、Anti-patterns：让 AI 替你想的四种方式

1. 只发散，不收敛

和 Agent 聊得很开心，选项列了十几条，却没有一轮明确的「我们选 A，因为……」。结果是 Execute 阶段 Agent 自行理解，改代码时漂移。

IEICE Trans. 2025 的研究 发现：简单把 GenAI 加进群体头脑风暴，并不能自动提升创造力；有时人类产出的 idea 数量反而显著减少。工具在场不等于流程有效——交互式轮流改进、显式收敛才是干预方向。

2. 假收敛：AI 替你做决定

Agent 总结「综上所述，建议采用方案 B」，你点了头，但 B 里的关键权衡你并未真正参与。这是 smart loafing：看起来完成了 clarify，决策权却在 AI 侧。

检验方法：关掉 Agent，你能否向同事用三句话讲清楚「我们决定了什么、为什么、没选什么」？不能，就是假收敛。

3. 问题空间与方案空间混谈

还没定义「用户要完成什么任务」，就开始讨论「用微服务还是 monolith」。Agent 会顺着你的 solution 关键词往下编，problem 定义被悄悄替换。

做法：第一个 diamond 结束前，禁止 deep dive 技术选型；只允许 problem statement、用户、约束、成功标准。进入第二个 diamond 再打开 solution space。

4. 无 Decision Log：聊天即焚

头脑风暴结论只留在 session 里。换 Agent、换同事、隔一周再开，同样的歧义重问一遍。Workflow 最小单位应从 prompt 升级为有入口、有产物、有检查点的流程资产——decision log 就是那个产物。

六、最小行动清单

下次开新 feature 或新变更前，不必换工具，可以先试这三步：

  1. Problem-space 一轮：与 Agent 只讨论「要解决什么、为谁、怎样算成功」，收敛成 3 条以内的 decision log，不写代码、不选框架。
  2. 显式切换模式：对 Agent 说「现在进入收敛，请列出选项 A/B/C，我来选」——把 convergent thinking 变成可执行的指令。
  3. 落盘再 Plan：把 decision log 写入 spec / design / docs/decisions/，再进入 writing-plans 或 /opsx:propose。

头脑风暴不是 AI 开发工作流的装饰步骤。在 Agent 能写代码、能改仓库的时代，Clarify 的质量决定了 Execute 的上限。工具会迭代，Superpowers 和 GStack 的 lens 也会变——但发散–收敛的节奏、问题与方案的分离、以及 decision log 的纪律，是跨工具可迁移的能力。

References