brainstorming

头脑风暴：构思技能

你可以帮助人们拓展想法，跳出收敛式思维，适用于任何领域——软件、商业、创意项目或个人决策。

核心原则

想法需要成长的空间，也需要碰撞。 有时你会陷入困境，需要摆脱惯性思维；有时你手上已有一个萌芽，需要拓展它。这两者都是构思问题，只是切入点不同。

两种模式，一个目标：探索可能性空间，而不是满足于第一个可行选项。

起点诊断

深入讨论前，先确定你从哪里开始：

起点	信号	模式
陷入困境	总是冒出相同的想法。所有选项都像是同一想法的变体。“我们什么都试过了。”还没探索就开始评估。	→ 突围协议
萌芽想法	已经有了某件事的开端。想看看它能发展成什么。寻找相邻的可能性或缺失的部分。	→ 种子拓展协议
不确定	不确定是陷入困境，还是只是刚起步。手上有些想法，但不确定是否可行。	→ 从种子拓展开始；如果陷入收敛，就切换到突围协议

关键问题： 你是想从某种状态中脱身（陷入困境），还是想让某个想法成长（萌芽想法）？

---

收敛问题（陷入困境模式）

想法会聚集在一起，因为它们在多个维度上都符合预期模式。当你的解决方案采用显而易见的方式，由显而易见的人来做显而易见的事，达到显而易见的规模——这就是它显得可预测的原因。

关键测试： 三个不同的人独立头脑风暴，会不会得出同一份清单？如果会，你还没有发散开来。

状态

状态 B1：对收敛视而不见

症状：

• 最初的想法立刻让人觉得“对”
• 所有想法都围绕同一种方法聚集
• 讨论会产出同一主题的不同变体
• “我们已经知道该做什么，只需要选一个”

关键问题：

• 最显而易见的解决方案是什么？你是否明确说出了它？
• 三个不同的人会不会得出同一份清单？
• 你是在探索各种可能，还是在确认直觉？
• 桌面上有多少种本质不同的做法（而不是变体）？

干预措施： 运行默认选项枚举（阶段 1）。尝试跳出之前，先说出这个聚集的主题。没有让默认选项显现出来，就无法摆脱它们。

---

状态 B2：功能锁定

症状：

• 所有想法都采用相同的形式
• 讨论默认了某种解决方案形式（“我们需要一个应用……”）
• 因为解决方案形式已被默认，所以看不到替代方案
• 说的是“我们需要 X”，而不是“我们需要实现 Y”

关键问题：

• 必须实现什么？（不是：应该做成什么？）
• 完全不同的东西能否达到相同的结果？
• 你实际解决的是什么问题？你执着于什么解决方案？
• 哪些限制是真实的，哪些只是默认的？

干预措施： 运行功能提取（阶段 2）。将做什么与怎么做分开。针对每项功能生成 5 个替代方案，而不是针对每个解决方案生成。

---

状态 B3：维度坍缩

症状：

• 想法在表面上不同，但底层结构相同
• “同一个想法，换了身衣服”
• 变化的是“谁”，但“做什么／何时／如何”相同
• 很容易把所有想法归为一类

关键问题：

• 最显而易见的“谁”是什么？你是否尝试过完全不同的人？
• 最显而易见的“何时”是什么？如果慢 10 倍呢？如果即时完成呢？定期发生还是只发生一次？
• 最显而易见的“规模”是什么？如果大 10 倍呢？小 10 倍呢？
• 最显而易见的“方法”是什么？完全不同的方法是什么？

干预措施： 运行维度映射（阶段 3）。从四个维度映射默认解决方案。至少转动一个维度，以打破模式。

---

状态 B4：领域束缚

症状：

• 所有想法都来自同一参考类别
• “我们一贯的做法”或“我们行业的做法”
• 业内任何人都能想到这些解决方案
• 没有来自相邻或遥远领域的想法

关键问题：

• 这个想法来自哪个领域／行业？
• 哪个领域肯定已经解决过类似问题？
• 完全不同的职业会如何处理这个问题？
• 哪个行业会觉得这个问题微不足道？

干预措施： 运行领域引入（阶段 4）。运用 3 个或更多互不相关领域的逻辑来生成想法。使用 constraint-entropy.ts 中的 domains 类别。

---

状态 B5：有效发散

症状：

• 想法涵盖不同形式、规模、参与者和时间范围
• 面临的是评估问题（选项太多），而不是生成问题
• 有些想法让人感到不安或出乎意料
• 很难把所有想法归为同一类

关键问题：

• 应该用哪些标准筛选这些想法？
• 对于首选方案，最小可行实验是什么？
• 哪些想法可以组合？
• 哪些想法服务于不同的用户群体？

干预措施： 转入评估框架。按方法聚类，并从每个类别中选出一个代表方案进行原型设计／测试。

---

突围协议

一种打破收敛式头脑风暴的结构化流程。对于陷入僵局的讨论，使用全部五个阶段；问题明确时，直接跳到相关阶段。

阶段 1：默认方案枚举（必需）

在生成“真正的”想法之前，明确列出默认方案：

• “任何人”都会提出什么建议？
• 针对这个问题，惯常的类型／行业默认做法是什么？
• 你／你的团队上次提出了什么建议？
• 搜索结果中的第一个结果会说什么？

输出： 列出 5 至 10 个显而易见的想法，并明确标注为默认方案。

目的： 让吸引子显现出来。没有明确指出的事物，就无从摆脱。

---

阶段 2：提取功能

对于每项要求，将“做什么”与“怎么做”分开：

• 必须完成什么？（功能）
• 我们对实现方式有什么假设？（形式）
• 哪些限制是真实存在的，哪些只是想当然？

重新表述： “我们需要 [形式]”变为“我们需要实现 [功能]，[形式] 只是其中一种方式”

输出： 列出解决方案必须实现的 3 至 5 项核心功能，不受形式限制。

示例：

• “我们需要一个移动应用” → “我们需要用户在外出时完成 X，而移动应用只是其中一种形式”
• “我们需要每周开会” → “我们需要信息在团队之间流通，而会议只是其中一种机制”

---

阶段 3：轴向映射

从四个维度映射默认解决方案：

维度	问题	默认方案	替代方案
谁	谁来执行／使用／拥有它？	[显而易见的参与者]	3 个不太可能的参与者
何时	时间范围／频率是什么？	[显而易见的时机]	不同的节奏／时机
规模	大小／范围是什么？	[显而易见的规模]	大 10 倍？小 10 倍？
方法	采用什么方法／机制？	[显而易见的方法]	完全不同的方法

关键洞见： 当想法在这四个维度上都符合“可能的”选项时，就会显得可以预测。改变任何一个维度，想法就会变得不那么显而易见。

输出： 完成轴向映射图，每个维度至少有 2 个替代方案。

---

阶段 4：注入熵

引入随机限制，推动探索：

熵的类型：

• 随机参与者（来自不同领域）
• 随机限制（时间、资源、能力限制）
• 随机组合（解决这个问题，同时解决一个无关问题）
• 逆向思考（什么会阻止这件事？现在围绕这个因素设计）
• 领域引入（[随机领域] 会如何解决这个问题？）

工具： 使用 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：正交性审查

对于有前景的想法，检查：

• 这个想法是否“知道”自己是显而易见的解决方案？（如果它能明确表达“我是预期的做法”，那它就是收敛的）
• 对于期待该类型默认做法的人来说，这会不会令人意外？
• 我们实际转动了哪个轴？
• 这是否在实现功能的同时打破了预期形式？

测试： 当一个想法有自己的逻辑，与问题发生碰撞，而不是以预期方式服务于问题时，它就是正交的。

输出： 标记出真正具有发散性的想法，以及仅在表面上有所不同的想法。

---

种子扩展流程

一种从初始种子发展想法的结构化流程。基于 Steven Johnson 对好想法来源的研究。当你有需要扩展的内容，而不是需要逃离的内容时使用。

Johnson 原则

这些不是励志箴言，而是诊断工具。每条原则都描述了想法实际发展的机制：

原则	机制	诊断问题
邻近可能性	大多数“新”想法都是从现有事物迈出的下一步。是阶梯，不是瞬移。	从这个种子迈出一步会是什么？一旦它存在，什么会成为可能？
液态网络	当不完整的想法发生碰撞时，想法便会形成——人与人、人与实物、与过往工作、与无关领域之间的碰撞。	这个种子应该与什么碰撞？环境中有什么可以建立联系？
缓慢萌发的灵感	许多好想法一开始都不成熟。它们需要时间，才能遇到缺失的部分。	这个种子有什么不完整之处？什么能让它完整？
意外发现	运气加上识别能力。当意外之物出现时，你能注意到它的用处。	最近遇到了什么意料之外的事，可能与此有关？
错误	失败就是信息。反馈能让漫无目的的探索逐渐收敛。	这个想法最笨拙的版本是什么？它会在哪里出问题？
功能转用	将为一种用途而构建的事物改作他用。复用即创造。	这个种子能否解决完全不同的问题？有什么原本为其他用途而构建的东西可以用在这里？
平台	稳定的基本构件能让人们更快、更安全地构建。	可以基于什么稳定的事物来构建？什么能让它成为其他想法的平台？

---

种子状态诊断

扩展之前，先了解你拥有什么类型的种子：

状态 S1：适合延伸

信号：

• 种子具体而明确
• 清楚它能做什么，但不清楚接下来是什么
• 感觉像某件更大事情的“第一步”

关键问题：

• 一旦它存在，哪些现在无法实现的事情会成为可能？
• 人们自然会想要迈出的下一步是什么？
• 你会在它之上构建什么？

扩展： 梳理邻近可能性。列出从这个种子出发可以实现的 3-5 件事。选出最有趣的一项并重复此过程。

---

状态 S2：渴望碰撞

信号：

• 种子单独看来并不完整
• 感觉它需要“别的东西”
• 在某些情境下有效，在另一些情境下却无效

关键问题：

• 哪个领域从未接触过这个想法？
• 它让你想起了哪些以往的工作？
• 谁会觉得它理所当然？谁会觉得它陌生？

扩展： 强制制造碰撞。将不同领域、约束和实物投向这个种子。必要时，使用 Escape Velocity Protocol 中的熵注入。

---

状态 S3：尚未成熟的灵感

信号：

• 还无法完整阐述这个想法
• 感觉很重要，但又模糊不清
• “这里有点东西，但我说不出来”

关键问题：

• 你能清楚阐述的部分是什么？
• 如果这个想法已经完善，它会回答什么问题？
• 缺少的是什么——机制、示例，还是用例？

扩展： 不要强求完善。先阐述你已有的内容，明确缺口。把灵感记下来，让它继续留存；然后寻找可能随着时间填补缺口的碰撞。

---

状态 S4：富含错误信息

信号：

• 已尝试种子，但失败了
• 知道哪些方法行不通
• 失败带来的启发，而非终结感

关键问题：

• 具体哪里出错了？（机制、情境、执行？）
• 这次失败揭示了问题结构的哪些信息？
• 要让它奏效，需要做出哪些改变？

拓展： 深挖失败。错误包含了解决方案形态的信息。列出你学到的内容，然后寻找能避开这些失败模式的相邻种子。

---

状态 S5：异用候选

信号：

• 种子很好地实现了其原本用途
• 觉得它还能做完全不同的事
• “这让我想起了 X”，而 X 毫不相关

关键问题：

• 这个种子原本是为完成什么任务而设计的？
• 还有哪些任务具有相似的结构？
• 把这个种子移植到哪里会既出人意料又合情合理？

拓展： 有意移植。列出 5 个完全不同的情境。在每个情境中尝试使用这个种子。记录哪些发生了变化，哪些保留了下来。

---

种子拓展阶段

与 Escape Velocity（按顺序进行）不同，请根据种子状态按需使用这些阶段：

阶段 S1：阐明种子

拓展之前，先记录你手头的内容：

• 这个种子的核心是什么？（一句话）
• 它擅长什么？不擅长什么？
• 它从何而来？（碰撞、相邻步骤、直觉、失败、异用？）
• 你目前对它有哪些不确定之处？

输出： 清楚说明这个种子是什么，以及它属于哪一类种子。

---

阶段 S2：相邻映射

绘制从这个种子出发可以到达的方向：

• 一步之遥的是什么？
• 哪些原本不可能的事情现在变得可能？
• 如果这件事成功了，自然会接着发生什么？
• 有人会基于此构建什么？

输出： 3-5 种相邻可能性，并标记一个“最有趣”的选项。

---

阶段 S3：生成碰撞

让这个种子与其他材料发生碰撞：

• 领域碰撞：[不相关领域] 会如何看待这个种子？
• 产物碰撞： 以往有哪些工作（你自己的或他人的）与之相关？
• 约束碰撞： 在不寻常的约束下会发生什么？
• 反转碰撞： 反面是什么？如果反转，会有什么崩坏？

工具： 使用 constraint-entropy.ts domains --count 5 生成随机领域来进行碰撞。

输出： 3-5 个碰撞结果，并注明哪些产生了有趣的发现。

---

阶段 S4：识别缺口

对于不完整的种子，指出缺少的内容：

• 如果完整了，这个种子能回答什么问题？
• 你无法阐明的机制是什么？
• 什么示例可以证明它有效？
• 要让别人相信它，需要让他们看到什么？

输出： 清楚说明存在的缺口。这就是你在未来的碰撞中要寻找的内容。

---

阶段 S5：移植测试

对于可能适用于其他场景的种子：

• 列出 5 个完全不同的情境
• 对每个情境：哪些发生了变化？哪些保留了下来？有什么收获？
• 是否有任何移植揭示了你此前未曾察觉的种子特性？

输出： 移植结果，以及每个结果所揭示内容的记录。

---

阶段 S6：压力测试

找出种子失效的情形：

• 最坏的应用场景是什么？
• 哪项假设如果不成立，就会让它失败？
• 最愚蠢的实现方式是什么？
• 谁会讨厌它？为什么？

输出： 失败模式，以及这些模式揭示了种子的哪些实际结构特征。

---

在模式间切换

你可能会从一种模式开始，之后需要切换：

种子 → 卡住： 如果种子拓展产生聚类（所有拓展都只是同一事物的变体），请切换到 Escape Velocity。你已陷入收敛。

卡住 → 种子： 如果 Escape Velocity 产生了有前景的发散想法，请切换到种子拓展来加以发展。你已找到一个值得培育的种子。

交接： Escape Velocity 生成候选项。种子拓展则发展优胜者。它们是同一构思过程中的不同阶段。

---

反模式

数量谬误

问题： 生成 50 个想法，结果全是同 3 种方法的变体。

症状： 数量多，覆盖面窄。映射后会发现想法聚集在一起，很容易归入少数几个类别。

解决方法： 别再计数，开始沿坐标轴绘制。每个象限至少要有一个想法，再继续增加。衡量覆盖面，而不是数量。

---

反转陷阱

问题：“如果我们反着来呢？”是一种偷懒式发散。对立选项共享同一坐标轴——仍属于收敛思维。

症状：“不如别求快，改成慢。”“不如别自动化，改成手动。”“不如别定价高，改成免费。”

**解决方法：**反转改变的是程度，而非维度。寻找真正正交的坐标轴，而不是同一坐标轴上的反面。“如果速度根本不是相关维度呢？”

---

过早评估循环

问题： 一边生成想法，一边评估。“那行不通，因为……”会扼杀发散。

症状： 想法说到一半就夭折。团队会朝“现实”的想法修正。大家对不切实际的建议感到不自在。

解决方法： 严格分阶段。生成不是评估。筛选之前，先写下所有想法。看似不切实际的想法中，可能包含实用想法的种子。

---

专家锚定

问题： 领域专家的第一个想法因其权威性而占据主导，而非因为质量更高。

症状： 第一个发言者的想法成了参照点。之后的想法全是变体或回应。大家对经验心存敬畏。

解决方法： 先匿名生成想法。或者让专家最后发言。也可以在阶段 1 明确列出专家的默认方案，然后不再考虑。

---

追逐新奇

问题： 为了发散而发散，追求无法实现实际功能的古怪想法。

症状： 想法令人惊讶，却毫无用处。巧妙，却不能发挥作用。“这个想法很有创意，但解决不了问题。”

解决方法： 回到阶段 2（功能提取）。这个古怪的想法真的实现了所需功能吗？如果没有，它就不是发散，而是无关。正交性必须服务于功能。

---

回避研究

问题： 明明已有先例，却从头开始头脑风暴，重复发明已有的解决方案。

症状：“不知道有没有人试过……”（有人试过了）。这些想法对团队来说很新颖，但在别处早已存在。

解决方法： 构思前先研究。找到至少 5 种现有方法，在阶段 1 将它们列为默认方案，然后再发散。站在前人的肩膀上，而不是重复造轮子。

---

按状态分类的关键问题

收敛诊断（任何状态）

• 你生成了多少种本质不同的方法（不是变体）？
• 如果把想法分成几组，会有多少组？
• 有没有哪个想法让你感到不自在？（不自在往往意味着真正的发散）
• 来自不同领域的人会列出同样的清单吗？

功能锁定（B2）

• 如果“显而易见的解决方案”不存在，会发生什么？
• 如果资源增加 10 倍呢？减少到 1/10 呢？
• 如果不能使用[假定的方法]，还有什么办法能实现该功能？
• 除了实现途径之外，你真正需要的结果是什么？

领域扩展（B4）

• 哪个行业肯定解决过类似问题？
• 哪个行业会觉得这个问题微不足道？
• 来自[随机领域]的人会注意到哪些你忽略的东西？
• 大自然如何解决这个问题？军方呢？幼儿园老师呢？

坐标轴审查（B3）

• 谁是“显而易见”的用户／行动者？还可能是谁？
• 什么是“显而易见”的时间范围？慢 10 倍呢？即时呢？
• 什么是“显而易见”的规模？面向 1 个人呢？100 万人呢？
• 什么是“显而易见”的方法？还有什么截然不同的方法？

---

可用工具

constraint-entropy.ts

生成随机约束，迫使探索走向不同方向。

# Generate random constraints
deno run --allow-read constraint-entropy.ts --count 3

# Get domain-import prompts
deno run --allow-read constraint-entropy.ts domains --count 5

# Generate constraint combo (one from each category)
deno run --allow-read constraint-entropy.ts --combo

# Specific categories
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 output
deno run --allow-read constraint-entropy.ts --combo --json

类别：

• actors - 对象约束（“必须让一位 10 岁的孩子使用”，“有人对此怀有敌意”）
• resources - 资源约束（“预算缩减至 1/10”，“不能使用显而易见的技术”）
• combinations - 强制组合（“还必须解决 X”，“绝不能做预期中的事”）
• inversions - 视角反转（“如果目标是失败呢？”，“如果约束本身就是功能呢？”）
• domains - 领域借鉴提示词（“军事后勤会如何解决这个问题？”）

为什么使用脚本： 真正的随机性会迫使人类和大模型探索原本会回避的方向。精心设计的约束能带来真正有用的发散。

---

交互示例

用户：“我们需要一些改进团队沟通的点子。我们总是想出相同的点子——Slack 频道、增加会议、编写文档。”

诊断方法：

1. 识别状态： B1（收敛盲区）+ B4（领域禁锢）。想法都集中在沟通工具和会议形式上——这是这个问题领域显而易见的默认选项。

2. 阶段 1 - 列举默认选项： 我们明确列出这些默认选项：

   • 更好地使用 Slack/Teams 或换用新工具
   • 增加会议 / 减少会议
   • 文档维基
   • 每日站会
   • 团队建设活动
   • 调整办公室布局

   这些都是惯常选项。虽然合理，但可以预见。

3. 阶段 2 - 提取功能： 团队沟通必须实现什么？

   • F1： 信息传达给需要的人
   • F2： 问题能得到解答，且不会造成阻塞
   • F3： 上下文能随时间保留
   • F4： 信任让艰难的对话成为可能
   • F5： 信噪比保持在可管理范围内

4. 阶段 3 - 映射维度（以“每日站会”为例）：

   维度	默认选项	替代方案
   参与者	整个团队	轮流配对？跨团队？邀请客户？
   时间	每天早上	每周？按需触发？遇到阻塞后？
   时长	15 分钟	严格限制 2 分钟？每月进行一次 2 小时的深入讨论？
   方式	口头同步	异步文本？视频录制？边走边谈？

5. 阶段 4 - 注入熵： 运行 constraint-entropy.ts --combo：

   • 对象：“必须让一个对此怀有敌意的人也能受益”
   • 反转：“如果过度沟通才是导致失败的原因呢？”

   这会迫使我们思考：如何让讨厌开会的人也能获得信息？如果我们设计的沟通更少、效果却更好，会怎样？

6. 生成发散想法：

   • 配对轮换： 不开团队会议。每天由轮换搭档同步。信息通过网络传播，而不是广播。内向者会更喜欢。
   • 决策记录： 每项决策都记录并附上上下文。沟通方式变为“阅读记录”，而不是“再次询问”。优先采用异步方式。
   • 打扰额度： 每个人每周只有有限数量的“打扰”令牌。这会迫使大家优先考虑哪些内容值得说。
   • 祖母测试： 任何公告都必须让不懂技术的家人也能看懂。这样能发现术语并促使表达清晰。
   • 上下文优先： 每条更新都必须以“今天加入的人会对什么感到困惑？”开头。

   这些想法彼此正交——它们沿着不同维度展开，而不是“会议工具”的不同变体。

---

你要做什么

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 阶段）
• 入选或有希望的想法及其理由

对话与文件

保存到文件	留在对话中
列出的默认项	讨论哪些默认项难以改变
轴向映射及其变换	对约束选择的迭代
生成的差异化想法	对想法的实时反馈
正交性评估	澄清问题
有希望的组合	放弃的选项

文件命名

格式：{topic}-{date}.md 示例：product-naming-2025-01-15.md

不要做的事

• 替用户生成想法（提供流程，而非内容）
• 在生成过程中评估想法（将不同阶段分开）
• 跳过默认项枚举（看不见的默认项无法摆脱）
• 为了新奇而追求新奇（古怪 ≠ 有用）
• 取代领域专业知识（与知识协作，而非取而代之）
• 保证想法出色（保证探索可能性空间）
• 接受“我们已经尝试了一切”（尝试的很可能只是同一种方法的变体）