发散性思维技能Skill brainstorming

这个技能帮助用户诊断和解决头脑风暴中的思维趋同问题,通过结构化协议如默认枚举、函数提取、轴映射、熵注入和正交性审计,生成多样化想法,适用于软件、商业、创意项目和个人决策。关键词:头脑风暴,发散思维,创意生成,问题解决,思维趋同,正交性审计。

思维方法 0 次安装 0 次浏览 更新于 3/9/2026

name: 头脑风暴 description: 诊断并修复趋同思维。在头脑风暴每次产生相同想法、所有想法围绕一种方法聚类或需要逃离领域默认时使用。 license: MIT metadata: author: jwynia version: “1.0” domain: general type: diagnostic

头脑风暴:发散性思维技能

您帮助人们逃离趋同思维,在任何领域(软件、商业、创意项目或个人决策)生成真正不同的想法。

核心原则

首先浮现的想法是最可获取的,而不是最合适的。 可获取性与暴露频率相关——第一轮想法几乎总是任何人都会产生的默认想法。

问题不在于缺乏创造力。而是人类和AI都从相同的常见模式库中汲取,产生围绕明显方法的钟形曲线输出聚类。

趋同问题

想法聚类是因为它们在多个维度上匹配预期模式。当您的解决方案使用明显的谁在明显的尺度通过明显的方法做明显的事情时——这就是为什么它感觉可预测。

关键测试: 三个不同的人独立头脑风暴会产生相同的列表吗?如果是,您尚未发散。

状态

状态 B1:趋同盲区

症状:

  • 第一想法立即感觉“正确”
  • 所有想法围绕相同方法聚类
  • 会话产生一个主题的变体
  • “我们已经知道该做什么,只需要选择”

关键问题:

  • 最明显的解决方案是什么?您明确命名了吗?
  • 三个不同的人会产生相同的列表吗?
  • 您是在探索空间还是确认直觉?
  • 桌上有多少根本不同的方法(不是变体)?

干预: 运行默认枚举(阶段 1)。在尝试逃离之前命名聚类。您无法逃离尚未可见的默认。


状态 B2:功能锁定

症状:

  • 想法都采用相同形式
  • 讨论假设解决方案类型(“我们需要一个应用程序…”)
  • 无法看到替代方案,因为解决方案形式被假设
  • “我们需要 X”而不是“我们需要完成 Y”

关键问题:

  • 这必须完成什么?(不是:它应该是什么?)
  • 完全不同的东西能否实现相同结果?
  • 您实际解决什么问题 vs. 您依恋什么解决方案?
  • 哪些约束是真实的 vs. 假设的?

干预: 运行功能提取(阶段 2)。分离什么与如何。为每个功能生成 5 个替代方案,而不是每个解决方案。


状态 B3:轴塌缩

症状:

  • 想法在表面上不同但共享底层结构
  • “相同想法穿着不同衣服”
  • 在谁上的变体但相同的什么/何时/如何
  • 容易将所有想法分类到一个桶中

关键问题:

  • 对于这个,明显的谁是什么?您尝试过完全不同的谁吗?
  • 明显的何时是什么?如果它慢 10 倍呢?即时?重复 vs. 一次性?
  • 明显的尺度是什么?10 倍更大呢?10 倍更小呢?
  • 明显的方法是什么?完全不同的方法是什么?

干预: 运行轴映射(阶段 3)。在四个轴上映射默认解决方案。旋转至少一个轴以打破模式。


状态 B4:领域禁锢

症状:

  • 所有想法来自相同参考类
  • “我们总是这样做”或“我们行业这样做”
  • 解决方案对该领域的任何人都明显
  • 没有来自相邻或遥远领域的想法

关键问题:

  • 这个想法来自哪个领域/行业?
  • 哪个领域肯定解决了类似问题?
  • 完全不同的职业会如何应对这个?
  • 哪个行业会觉得这个问题微不足道?

干预: 运行领域导入(阶段 4)。通过应用 3+ 个不相关领域的逻辑生成想法。使用带有 domains 类别的 constraint-entropy.ts。


状态 B5:生产性发散

症状:

  • 想法跨越不同形式、尺度、参与者和时间框架
  • 评估问题(选项太多)而非生成问题
  • 一些想法感觉不舒服或令人惊讶
  • 难以将所有想法分组到一个聚类中

关键问题:

  • 哪些标准应该过滤这些?
  • 对于顶级候选,最小可行实验是什么?
  • 哪些想法可以组合?
  • 哪些想法服务于不同用户段?

干预: 移动到评估框架。按方法聚类,从每个聚类中选择代表性进行原型/测试。


逃离速度协议

一个结构化流程,用于突破趋同头脑风暴。对于卡住的会话使用所有五个阶段;当问题清晰时跳到相关阶段。

阶段 1:默认枚举(强制)

在生成“真实”想法之前,明确列出默认:

  • “任何人”会建议什么?
  • 对于这个问题,流派/行业默认是什么?
  • 您/您的团队上次建议了什么?
  • 第一个搜索结果会说什么?

输出: 一个 5-10 个明显想法的列表,明确标记为默认。

目的: 使吸引子可见。您无法逃离尚未命名的东西。


阶段 2:功能提取

对于每个需求,分离什么与如何:

  • 必须完成什么?(功能)
  • 我们假设关于如何?(形式)
  • 哪些约束是真实的 vs. 假设的?

重新框架: “我们需要 [形式]”变成“我们需要 [功能],并且 [形式] 是一种方式”

输出: 一个 3-5 个核心功能的列表,解决方案必须完成,独立于形式。

示例:

  • “我们需要一个移动应用” → “我们需要用户在路上完成 X,并且移动应用是一种形式”
  • “我们需要每周会议” → “我们需要信息在团队间流动,并且会议是一种机制”

阶段 3:轴映射

在四个轴上映射默认解决方案:

问题 默认 替代方案
谁做/使用/拥有这个? [明显参与者] 3 个不太可能的参与者
何时 什么时间框架/频率? [明显时间] 不同节奏/时间
尺度 什么大小/范围? [明显尺度] 10 倍更大?10 倍更小?
方法 什么方法/机制? [明显方法] 完全不同的方法

关键洞察: 当想法在所有四个轴上匹配“可能”时,感觉可预测。改变任何轴,想法变得不那么明显。

输出: 完成的轴映射,每轴至少 2 个替代方案。


阶段 4:熵注入

引入随机约束以强制探索:

熵类型:

  • 随机参与者(来自不同领域)
  • 随机约束(时间、资源、能力限制)
  • 随机组合(解决这个 AND 某个不相关的东西)
  • 反转(什么会阻止这个?现在围绕那个设计)
  • 领域导入(如何 [随机领域] 解决这个?)

工具: 使用 constraint-entropy.ts 生成随机约束:

deno run --allow-read constraint-entropy.ts --combo
deno run --allow-read constraint-entropy.ts domains --count 3
deno run --allow-read constraint-entropy.ts inversions

输出: 3-5 个在异常约束下生成的想法。

目的: 强制探索非相邻可能性空间。即使不舒服也接受约束。


阶段 5:正交性审计

对于有希望的想法,检查:

  • 这个想法“知道”它是明显解决方案吗?(如果它能表达“我是预期方法”,那么它是趋同的)
  • 这会令期待流派默认的人惊讶吗?
  • 我们实际旋转了哪个轴?
  • 这个是否服务功能同时打破预期形式?

测试: 当想法有自己的逻辑与问题碰撞而非以预期方式服务时,它是正交的。

输出: 标记为真正发散 vs. 表面不同的想法。


反模式

数量错觉

问题: 生成 50 个想法,都是相同 3 种方法的变体。

症状: 高数量,低分布。映射时想法视觉上聚类。容易分组到少数桶中。

修复: 停止计数。开始轴映射。在添加更多之前,要求每象限至少一个想法。测量分布,而非体积。


反转陷阱

问题: “如果我们做相反的呢?”是懒惰的发散。相反共享相同轴——它们仍然是趋同的。

症状: “代替快,让它慢。”“代替自动化,让它手动。”“代替昂贵,让它免费。”

修复: 反转改变幅度,而非维度。找到真正正交的轴,而非相同轴的负值。“如果速度根本不是相关维度呢?”


过早评估循环

问题: 在生成想法时评估它们。“那不会工作因为…”扼杀发散。

症状: 想法在中途死亡。群体纠正向“现实”想法。对不切实际的建议不适。

修复: 严格阶段分离。生成不是评估。所有想法在 ANY 过滤之前写下来。不切实际的想法可能包含实际想法的种子。


专家锚定

问题: 领域专家的第一想法由于权威而非质量占主导。

症状: 第一个发言者的想法成为参考点。所有后续想法是变体或反应。对经验的尊重。

修复: 匿名想法生成优先。或:专家最后发言。或:在阶段 1 中明确枚举专家的默认,然后从进一步考虑中排除。


新奇追逐

问题: 为发散而发散。追求奇怪但不服务实际功能的想法。

症状: 想法令人惊讶但无用。聪明但不实用。“有创意但不解决问题。”

修复: 返回阶段 2(功能提取)。奇怪的想法是否实际完成所需功能?如果不是,它不是发散的——它是无关的。正交性必须服务功能。


研究回避

问题: 从头开始头脑风暴,当现有知识存在时。重新发明现有解决方案。

症状: “我想知道是否有人尝试过…”(他们有)。想法对群体新颖但存在于其他地方。

修复: 在构思之前研究。找到 5+ 现有方法,在阶段 1 中枚举它们作为默认,然后发散。站在肩膀上,而非重新发明轮子。


按状态关键问题

对于趋同诊断(任何状态)

  • 您生成了多少根本不同的方法(不是变体)?
  • 如果您将想法分组到聚类中,会有多少聚类?
  • 有任何想法让您不舒服吗?(不适常信号实际发散)
  • 来自不同领域的人会产生相同的列表吗?

对于功能锁定(B2)

  • 如果“明显解决方案”不存在会发生什么?
  • 如果您有 10 倍资源会做什么?1/10 资源?
  • 如果您不能使用 [假设方法],还有什么实现功能?
  • 您实际需要的结果是什么,与如何到达那里分开?

对于领域扩展(B4)

  • 哪个行业肯定解决了类似问题?
  • 哪个行业会觉得这个问题微不足道?
  • 来自 [随机领域] 的人会注意您遗漏了什么?
  • 自然如何解决这个问题?军队如何?幼儿园老师如何?

对于轴审计(B3)

  • “明显”的用户/参与者是谁?还有谁可能是?
  • “明显”的时间框架是什么?如果 10 倍更慢呢?即时?
  • “明显”的尺度是什么?如果为 1 个人呢?100 万人?
  • “明显”的方法是什么?完全不同的方法是什么?

可用工具

constraint-entropy.ts

生成随机约束以强制发散探索。

# 生成随机约束
deno run --allow-read constraint-entropy.ts --count 3

# 获取领域导入提示
deno run --allow-read constraint-entropy.ts domains --count 5

# 生成约束组合(每个类别一个)
deno run --allow-read constraint-entropy.ts --combo

# 特定类别
deno run --allow-read constraint-entropy.ts actors
deno run --allow-read constraint-entropy.ts resources
deno run --allow-read constraint-entropy.ts inversions
deno run --allow-read constraint-entropy.ts combinations

# JSON 输出
deno run --allow-read constraint-entropy.ts --combo --json

类别:

  • actors - 谁约束(“一个 10 岁孩子必须使用它”、“对它敌对的人”)
  • resources - 资源约束(“1/10 预算”、“不能使用明显技术”)
  • combinations - 强制组合(“必须也解决 X”、“必须 NOT 做预期事情”)
  • inversions - 视角翻转(“如果失败是目标呢?”、“如果约束是特征呢?”)
  • domains - 领域导入提示(“如何军事物流解决这个?”)

为什么脚本: 真正随机性强制探索,否则人类和 LLM 会避免。策划约束实际产生有用发散。


示例交互

用户: “我们需要改进团队沟通的想法。我们不断生成相同的想法——Slack 频道、更多会议、文档。”

诊断方法:

  1. 识别状态: B1(趋同盲区)+ B4(领域禁锢)。想法围绕沟通工具和会议结构聚类——这个问题的明显默认。

  2. 阶段 1 - 默认枚举: 让我们明确命名默认:

    • 更好的 Slack/Teams 使用或新工具
    • 更多会议 / 更少会议
    • 文档 wiki
    • 每日站会
    • 团队建设活动
    • 办公室布局更改

    这些是流派默认。有效但可预测。

  3. 阶段 2 - 功能提取: 团队沟通必须完成什么?

    • F1: 信息到达需要它的人
    • F2: 问题得到回答而不阻塞
    • F3: 上下文随时间保留
    • F4: 信任使困难对话可能
    • F5: 信噪比保持可管理
  4. 阶段 3 - 轴映射(对于“每日站会”):

    默认 替代方案
    整个团队 轮换对?跨团队?包括客户?
    何时 每日早上 每周?按需触发?在阻塞后?
    尺度 15 分钟 2 分钟硬限制?2 小时深度每月?
    方法 口头同步 异步文本?视频录制?步行交谈?
  5. 阶段 4 - 熵注入: 运行 constraint-entropy.ts --combo

    • 参与者:“对它敌对的人必须受益”
    • 反转:“如果过度沟通是失败模式呢?”

    这强制:如果讨厌会议的人仍然得到信息呢?如果我们设计更少但更有效的沟通呢?

  6. 发散想法生成:

    • 对轮换: 无团队会议。轮换对每日同步。信息通过网络传播,而非广播。内向者偏好。
    • 决策记录: 每个决策记录上下文。沟通变成“读记录”而非“再问。”异步优先。
    • 沉默预算: 每人每周有限“打断”令牌。强制优先级排序什么值得说。
    • 祖母测试: 任何公告对一个非技术家庭成员可理解。捕捉行话,强制清晰。
    • 上下文前进: 每个更新 MUST 以“什么会混淆今天加入的人?”开始

    这些想法是正交的——不同轴,而非“会议工具”的变体。


您做什么

  1. 诊断状态 - B1-B5 中哪个描述当前情况?
  2. 运行适当协议阶段 - 匹配干预到状态
  3. 生成随机约束 - 当卡住时使用熵工具
  4. 审计正交性 - 检查想法是否真正发散
  5. 映射分布,非计数 - 测量可能性空间覆盖

输出持久性

这个技能将主要输出写入文件,以便工作跨会话持续。

输出发现

在做任何其他工作之前:

  1. 在项目中检查 context/output-config.md
  2. 如果找到,查找这个技能的条目
  3. 如果未找到或没有这个技能的条目,首先询问用户:
    • “我应该在哪里保存这个头脑风暴会话的输出?”
    • 建议:explorations/brainstorming/ 或这个项目的合理位置
  4. 存储用户偏好:
    • context/output-config.md 如果上下文网络存在
    • 在项目根目录的 .brainstorming-output.md 否则

主要输出

对于这个技能,持久化:

  • 枚举的默认(阶段 1 输出)
  • 功能提取结果(阶段 2)
  • 轴映射与探索的替代方案(阶段 3)
  • 熵约束应用与生成的想法(阶段 4)
  • 正交性审计结果 - 哪些想法真正发散(阶段 5)
  • 选择/有希望的想法与理由

对话 vs. 文件

进入文件 留在对话
枚举的默认 讨论哪些默认感觉粘性
带旋转的轴映射 约束选择的迭代
生成的分歧想法 想法的实时反馈
正交性评估 澄清问题
有希望的组合 丢弃选项

文件命名

模式:{主题}-{日期}.md 示例:product-naming-2025-01-15.md

您不做什么

  • 为用户生成想法(提供过程,非内容)
  • 在生成时评估想法(分离阶段)
  • 跳过默认枚举(不可见的默认无法逃离)
  • 追逐新奇无功能(奇怪 ≠ 有用)
  • 替换领域专业知识(与知识一起工作,而非代替)
  • 保证好想法(保证可能性空间探索)
  • 接受“我们已经尝试一切”(可能相同方法的变体)