Back to Details

brainstorming

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Brainstorming: Divergent Ideation Skill

头脑风暴：发散式构思技能

You help people escape convergent thinking and generate genuinely different ideas across any domain—software, business, creative projects, or personal decisions.
你可以帮助人们跳出收敛思维，在任意领域——软件、商业、创意项目或个人决策中——产生真正与众不同的想法。

Core Principle

核心原则

The first ideas that surface are most available, not most appropriate. Availability correlates with frequency of exposure—first-pass ideas are almost always defaults that anyone would generate.
The problem isn't lack of creativity. It's that humans and AI both draw from the same well of common patterns, producing bell-curve outputs clustered around obvious approaches.
最先浮现的想法往往是最“易获取”的，而非最“合适”的。易获取性与曝光频率相关——初次构思的想法几乎都是所有人都会想到的默认方案。
问题不在于缺乏创造力，而在于人类和AI都会从相同的常见模式库中汲取灵感，产出集中在明显思路周围的钟形曲线结果。

The Convergence Problem

收敛问题

Ideas cluster because they match expected patterns on multiple dimensions. When your solution uses the obvious WHO doing the obvious WHAT at the obvious SCALE via the obvious METHOD—that's why it feels predictable.
The key test: Could three different people brainstorming independently produce the same list? If yes, you haven't diverged yet.
想法之所以会扎堆，是因为它们在多个维度上都符合预期模式。当你的解决方案是由“显而易见的角色”做“显而易见的事”，在“显而易见的规模”下采用“显而易见的方法”时，就会显得毫无新意。
关键测试：三个独立进行头脑风暴的人会得出相同的想法列表吗？如果答案是肯定的，说明你还没有实现发散。

The States

不同状态

State B1: Convergence Blindness

状态B1：收敛盲区

Symptoms:
  • First ideas feel "right" immediately
  • All ideas cluster around same approach
  • Session produces variations on one theme
  • "We already know what to do, we just need to pick"
Key Questions:
  • What's the most obvious solution? Have you named it explicitly?
  • Would three different people produce the same list?
  • Are you exploring the space or confirming an intuition?
  • How many fundamentally different APPROACHES (not variations) are on the table?
Interventions: Run Default Enumeration (Phase 1). Name the cluster before trying to escape it. You cannot escape defaults you haven't made visible.
症状：
  • 最初的想法立刻让人觉得“正确”
  • 所有想法都围绕同一思路
  • 会议产出的都是同一主题的变体
  • “我们已经知道该怎么做了，只需选一个就行”
关键问题：
  • 最显而易见的解决方案是什么？你是否明确将其列了出来？
  • 三个独立的人会得出相同的想法列表吗？
  • 你是在探索可能性空间，还是在验证直觉？
  • 目前桌上有多少种本质不同的思路（而非变体）？
干预措施：执行默认方案枚举（阶段1）。在尝试跳出之前，先明确命名当前的想法集群。你无法逃离未被明确识别的默认框架。

State B2: Function Lock

状态B2：功能锁定

Symptoms:
  • Ideas all take the same form
  • Discussion assumes the solution type ("We need an app that...")
  • Can't see alternatives because solution-form is assumed
  • "We need X" rather than "We need to accomplish Y"
Key Questions:
  • What must this accomplish? (Not: what should it be?)
  • Could something completely different achieve the same outcome?
  • What problem are you actually solving vs. what solution are you attached to?
  • What constraints are real vs. assumed?
Interventions: Run Function Extraction (Phase 2). Separate WHAT from HOW. Generate 5 alternatives per function, not per solution.
症状：
  • 所有想法都采用相同形式
  • 讨论默认了解决方案的类型（“我们需要一个能……的应用”）
  • 因为预设了解决方案形式，所以看不到其他选择
  • 开口就是“我们需要X”，而非“我们需要达成Y目标”
关键问题：
  • 这件事必须达成什么目标？（而非：它应该是什么样子？）
  • 有没有完全不同的方式能达成相同结果？
  • 你真正要解决的是什么问题，而非你执着于哪种解决方案？
  • 哪些约束是真实存在的，哪些是主观预设的？
干预措施：执行功能提取（阶段2）。将“要做什么”与“怎么做”分离。针对每个功能生成5种替代方案，而非针对解决方案本身。

State B3: Axis Collapse

状态B3：维度坍缩

Symptoms:
  • Ideas differ cosmetically but share underlying structure
  • "Same idea wearing different clothes"
  • Variations on WHO but same WHAT/WHEN/HOW
  • Easy to categorize all ideas into one bucket
Key Questions:
  • What's the obvious WHO for this? Have you tried a completely different who?
  • What's the obvious WHEN? What if it was 10x slower? Instant? Recurring vs. one-time?
  • What's the obvious SCALE? What about 10x bigger? 10x smaller?
  • What's the obvious METHOD? What's a completely different approach?
Interventions: Run Axis Mapping (Phase 3). Map the default solution on four axes. Rotate at least one axis to break the pattern.
症状：
  • 想法在表面上不同，但底层结构一致
  • “换汤不换药”
  • 仅在“角色”上有变化，但“做什么/何时做/怎么做”完全相同
  • 所有想法很容易被归为一类
关键问题：
  • 这件事最显而易见的“角色”是谁？你有没有试过完全不同的角色？
  • 最显而易见的“时间”是什么？如果速度慢10倍会怎样？即时完成呢？周期性 vs 一次性？
  • 最显而易见的“规模”是什么？扩大10倍？缩小10倍？
  • 最显而易见的“方法”是什么？有没有完全不同的思路？
干预措施：执行维度映射（阶段3）。在四个维度上映射默认解决方案。至少调整一个维度来打破固有模式。

State B4: Domain Imprisonment

状态B4：领域禁锢

Symptoms:
  • All ideas come from same reference class
  • "How we always do it" or "how our industry does it"
  • Solutions are obvious to anyone in the field
  • No ideas from adjacent or distant domains
Key Questions:
  • What field/industry does this idea come from?
  • What domain has definitely solved something similar?
  • How would a completely different profession approach this?
  • What industry would find this problem trivial?
Interventions: Run Domain Import (Phase 4). Generate ideas by applying logic from 3+ unrelated fields. Use constraint-entropy.ts with 
domains
category.
症状：
  • 所有想法都来自同一参考类别
  • “我们一直都是这么做的”或“我们行业都是这么做的”
  • 解决方案对业内任何人来说都显而易见
  • 没有来自相邻或遥远领域的想法
关键问题：
  • 这个想法来自哪个领域/行业？
  • 哪个领域肯定解决过类似问题？
  • 完全不同的职业会如何处理这个问题？
  • 哪个行业会觉得这个问题微不足道？
干预措施：执行领域迁移（阶段4）。通过应用3个以上无关领域的逻辑来生成想法。使用
constraint-entropy.ts
的
domains
分类。

State B5: Productive Divergence

状态B5：有效发散

Symptoms:
  • Ideas span different forms, scales, actors, and timeframes
  • Evaluation problem (too many options) rather than generation problem
  • Some ideas feel uncomfortable or surprising
  • Hard to group all ideas into one cluster
Key Questions:
  • Which criteria should filter these?
  • What's the minimum viable experiment for top candidates?
  • Which ideas can be combined?
  • Which ideas serve different user segments?
Interventions: Move to evaluation framework. Cluster by approach, pick representative from each cluster to prototype/test.
症状：
  • 想法涵盖不同形式、规模、角色和时间范围
  • 面临的是评估问题（选项太多）而非生成问题
  • 有些想法让人感到不适或意外
  • 很难将所有想法归为一类
关键问题：
  • 应该用哪些标准来筛选这些想法？
  • 针对优先级最高的候选方案，最小可行实验是什么？
  • 哪些想法可以组合？
  • 哪些想法服务于不同的用户群体？
干预措施：切换到评估框架。按思路聚类，从每个聚类中选取代表性想法进行原型制作/测试。

The Escape Velocity Protocol

逃逸速度协议

A structured process for breaking out of convergent brainstorming. Use all five phases for stuck sessions; skip to relevant phase when the problem is clear.
这是一个打破收敛式头脑风暴的结构化流程。对于陷入僵局的会议，使用全部五个阶段；当问题明确时，可直接跳至相关阶段。

Phase 1: Default Enumeration (Mandatory)

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

Before generating "real" ideas, explicitly list the defaults:
  • What would "anyone" suggest?
  • What's the genre/industry default for this problem?
  • What did you/your team suggest last time?
  • What would the first search result say?
Output: A list of 5-10 obvious ideas, explicitly labeled as defaults.
Purpose: Make attractors visible. You cannot escape what you haven't named.
在生成“真正的”想法之前，明确列出所有默认方案：
  • “任何人”都会提出什么建议？
  • 针对这个问题，该领域/行业的默认方案是什么？
  • 你/你的团队上次提出了什么方案？
  • 第一个搜索结果会给出什么建议？
输出：一份包含5-10个明显想法的列表，并明确标记为默认方案。
目的：让“吸引力陷阱”可视化。你无法逃离未被命名的事物。

Phase 2: Function Extraction

阶段2：功能提取

For each requirement, separate WHAT from HOW:
  • What must be accomplished? (function)
  • What are we assuming about how? (form)
  • What constraints are real vs. assumed?
Reframe: "We need [FORM]" becomes "We need to [FUNCTION] and [FORM] is one way"
Output: A list of 3-5 core functions the solution must accomplish, independent of form.
Example:
  • "We need a mobile app" → "We need users to accomplish X on the go, and a mobile app is one form"
  • "We need weekly meetings" → "We need information to flow between teams, and meetings are one mechanism"
针对每个需求，分离“要做什么”与“怎么做”：
  • 必须达成什么目标？（功能）
  • 我们对“怎么做”有哪些预设？（形式）
  • 哪些约束是真实存在的，哪些是主观预设的？
重构表述：“我们需要[形式]”变为“我们需要达成[功能]，而[形式]是其中一种方式”
输出：一份包含3-5个核心功能的列表，这些功能是解决方案必须达成的，与形式无关。
示例：
  • “我们需要一个移动应用” → “我们需要用户能在外出时完成X操作，而移动应用是其中一种形式”
  • “我们需要每周开会” → “我们需要信息在团队间流转，而会议是其中一种机制”

Phase 3: Axis Mapping

阶段3：维度映射

Map the default solution on four axes:
AxisQuestionDefaultAlternatives
WhoWho does/uses/owns this?[obvious actor]3 unlikely actors
WhenWhat timeframe/frequency?[obvious timing]Different cadence/timing
ScaleWhat size/scope?[obvious scale]10x bigger? 10x smaller?
MethodWhat approach/mechanism?[obvious approach]Completely different approach
The key insight: Ideas feel predictable when they match "likely" on all four axes. Change ANY axis and the idea becomes less obvious.
Output: Completed axis map with at least 2 alternatives per axis.
在四个维度上映射默认解决方案：
维度问题默认方案替代选项
角色谁来做/使用/拥有这件事？[显而易见的角色]3个非预期角色
时间时间范围/频率？[显而易见的时间]不同节奏/时间点
规模大小/范围？[显而易见的规模]扩大10倍？缩小10倍？
方法思路/机制？[显而易见的方法]完全不同的思路
核心洞察：当想法在四个维度上都符合“预期”时，就会显得毫无新意。改变任意一个维度，想法就会变得不再显而易见。
输出：完成的维度映射表，每个维度至少包含2个替代选项。

Phase 4: Entropy Injection

阶段4：熵注入

Introduce random constraints to force exploration:
Types of entropy:
  • Random actor (from different domain)
  • Random constraint (time, resource, capability limit)
  • Random combination (solve this AND something unrelated)
  • Inversion (what would PREVENT this? Now design around that)
  • Domain import (how would [random field] solve this?)
Tool: Use 
constraint-entropy.ts
to generate random constraints:
bash
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
Output: 3-5 ideas generated under unusual constraints.
Purpose: Force exploration of non-adjacent possibility space. Accept the constraints even if uncomfortable.
引入随机约束以推动探索：
熵的类型：
  • 随机角色（来自不同领域）
  • 随机约束（时间、资源、能力限制）
  • 随机组合（同时解决这个问题和另一个无关问题）
  • 反转（什么会阻止这件事发生？现在围绕这个设计方案）
  • 领域迁移（[随机领域]会如何解决这个问题？）
工具：使用
constraint-entropy.ts
生成随机约束：
bash
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个在非常规约束下生成的想法。
目的：推动对非相邻可能性空间的探索。即使感到不适，也要接受这些约束。

Phase 5: Orthogonality Audit

阶段5：正交性审核

For promising ideas, check:
  • Does this idea "know" it's the obvious solution? (If it could articulate "I'm the expected approach," it's convergent)
  • Would this surprise someone expecting the genre default?
  • Which axis did we actually rotate on?
  • Does this serve the function while breaking the expected form?
The test: An idea is orthogonal when it has its own logic that collides with the problem rather than serving it in the expected way.
Output: Ideas flagged as genuinely divergent vs. cosmetically different.
针对有潜力的想法，检查以下几点：
  • 这个想法“知道”自己是显而易见的解决方案吗？（如果它能表述“我是预期中的方案”，那它就是收敛的）
  • 它会让预期领域默认方案的人感到意外吗？
  • 我们实际调整了哪个维度？
  • 它在打破预期形式的同时，是否仍能满足功能需求？
测试标准：一个想法具有正交性，是指它拥有独立的逻辑，与问题产生“碰撞”，而非以预期方式“服务”于问题。
输出：标记为真正发散的想法，以及仅在表面上不同的想法。

Anti-Patterns

反模式

The Quantity Delusion

数量幻觉

Problem: Generating 50 ideas that are all variations of the same 3 approaches.
Symptom: High count, low spread. Ideas cluster visually when mapped. Easy to group into few buckets.
Fix: Stop counting. Start mapping on axes. Require at least one idea per quadrant before adding more. Measure spread, not volume.
问题：生成50个想法，但都是同一3种思路的变体。
症状：数量多，但覆盖范围窄。将想法可视化后会发现它们扎堆。很容易被归为少数几类。
解决方法：停止计数，开始按维度映射。在添加更多想法之前，要求每个象限至少有一个想法。衡量覆盖范围，而非数量。

The Inversion Trap

反转陷阱

Problem: "What if we did the opposite?" is lazy divergence. Opposites share the same axis—they're still convergent.
Symptom: "Instead of fast, make it slow." "Instead of automated, make it manual." "Instead of expensive, make it free."
Fix: Inversion changes magnitude, not dimension. Find a truly orthogonal axis, not the negative of the same axis. "What if speed wasn't the relevant dimension at all?"
问题：“如果我们反过来做会怎样？”是一种偷懒的发散方式。对立面共享同一维度——本质上仍是收敛的。
症状：“与其快，不如慢”“与其自动化，不如手动”“与其昂贵，不如免费”
解决方法：反转只是改变了量级，而非维度。找到真正正交的维度，而非同一维度的对立面。比如问：“如果速度根本不是相关维度呢？”

The Premature Evaluation Loop

过早评估循环

Problem: Evaluating ideas while generating them. "That won't work because..." kills divergence.
Symptom: Ideas die mid-sentence. Group corrects toward "realistic" ideas. Discomfort with impractical suggestions.
Fix: Strict phase separation. Generation is not evaluation. All ideas written down before ANY filtering. Impractical ideas may contain seeds of practical ones.
问题：在生成想法的同时进行评估。“那行不通，因为……”会扼杀发散思维。
症状：想法刚提出就被否定。团队会向“现实”的想法靠拢。对不切实际的建议感到不适。
解决方法：严格分离阶段。生成阶段不进行评估。在进行任何筛选之前，先把所有想法写下来。不切实际的想法中可能蕴含着实用的种子。

The Expert Anchor

专家锚定

Problem: Domain expert's first idea dominates because of authority, not quality.
Symptom: First speaker's idea becomes the reference point. All subsequent ideas are variants or reactions. Deference to experience.
Fix: Anonymous idea generation first. Or: expert speaks last. Or: explicitly enumerate expert's default in Phase 1, then exclude it from further consideration.
问题：领域专家的第一个想法因权威地位而非质量占据主导。
症状：第一个发言者的想法成为参考点。后续所有想法都是其变体或反应。对经验的过度顺从。
解决方法：先进行匿名想法生成。或者：专家最后发言。或者：在阶段1中明确枚举专家提出的默认方案，然后在后续构思中将其排除。

The Novelty Chase

新奇追逐

Problem: Divergence for its own sake. Pursuing weird ideas that don't serve the actual function.
Symptom: Ideas are surprising but useless. Clever without being functional. "That's creative but doesn't solve the problem."
Fix: Return to Phase 2 (Function Extraction). Does the weird idea actually accomplish the required function? If not, it's not divergent—it's irrelevant. Orthogonality must serve function.
问题：为了发散而发散。追求怪异但无法满足实际功能的想法。
症状：想法令人惊讶但毫无用处。只追求巧妙，不解决问题。“这很有创意，但解决不了我们的问题。”
解决方法：回到阶段2（功能提取）。这个怪异的想法真的能满足所需功能吗？如果不能，那它不是发散，而是无关。正交性必须服务于功能需求。

The Research Avoidance

研究回避

Problem: Brainstorming from scratch when prior art exists. Reinventing existing solutions.
Symptom: "I wonder if anyone has tried..." (they have). Ideas are novel to the group but exist elsewhere.
Fix: Research before ideation. Find 5+ existing approaches, enumerate them as defaults in Phase 1, THEN diverge. Standing on shoulders, not reinventing wheels.
问题：在已有先例的情况下从零开始头脑风暴，重复发明已有的解决方案。
症状：“我想知道有没有人试过……”（其实已经有人试过了）。这些想法对团队来说是新的，但在其他地方已经存在。
解决方法：在构思前先做研究。找到5种以上现有方案，在阶段1中将其枚举为默认方案，然后再进行发散构思。站在巨人的肩膀上，而非重复造轮子。

Key Questions by State

按状态分类的关键问题

For Convergence Diagnosis (Any State)

收敛诊断（任意状态）

  • How many fundamentally different APPROACHES (not variations) did you generate?
  • If you grouped ideas into clusters, how many clusters would there be?
  • Did any idea make you uncomfortable? (Discomfort often signals actual divergence)
  • Would someone from a different field produce the same list?
  • 你生成了多少种本质不同的思路（而非变体）？
  • 如果把想法聚类，会分成多少个集群？
  • 有没有哪个想法让你感到不适？（不适往往意味着真正的发散）
  • 来自不同领域的人会得出相同的想法列表吗？

For Function Lock (B2)

功能锁定（B2）

  • What happens if the "obvious solution" doesn't exist?
  • What would you do with 10x resources? 1/10th resources?
  • If you couldn't use [assumed approach], what else achieves the function?
  • What's the actual outcome you need, separate from how you get there?
  • 如果“显而易见的解决方案”不存在，会发生什么？
  • 如果资源增加10倍会怎么做？减少到1/10呢？
  • 如果你不能使用[预设方法]，还有什么其他方式能达成功能？
  • 你真正需要的结果是什么，与达成方式无关？

For Domain Expansion (B4)

领域拓展（B4）

  • What industry has definitely solved something similar?
  • What industry would find this problem trivial?
  • What would someone from [random field] notice that you're missing?
  • How does nature solve this problem? How does the military? How does a kindergarten teacher?
  • 哪个领域肯定解决过类似问题？
  • 哪个行业会觉得这个问题微不足道？
  • 来自[随机领域]的人会注意到哪些你忽略的点？
  • 自然界会如何解决这个问题？军队呢？幼儿园老师呢？

For Axis Audit (B3)

维度审核（B3）

  • Who is the "obvious" user/actor? Who else could it be?
  • What's the "obvious" timeframe? What if 10x slower? Instant?
  • What's the "obvious" scale? What if for 1 person? 1 million people?
  • What's the "obvious" method? What's a completely different method?
  • “显而易见的”用户/角色是谁？还能是谁？
  • “显而易见的”时间范围是什么？如果慢10倍会怎样？即时完成呢？
  • “显而易见的”规模是什么？如果只为1个人服务呢？为100万人呢？
  • “显而易见的”方法是什么？有没有完全不同的方法？

Available Tools

可用工具

constraint-entropy.ts

constraint-entropy.ts

Generates random constraints to force divergent exploration.
bash
undefined
生成随机约束以推动发散探索。
bash
undefined

Generate random constraints

生成随机约束

deno run --allow-read constraint-entropy.ts --count 3
deno run --allow-read constraint-entropy.ts --count 3

Get domain-import prompts

获取领域迁移提示

deno run --allow-read constraint-entropy.ts domains --count 5
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
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
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

JSON格式输出

deno run --allow-read constraint-entropy.ts --combo --json

**Categories:**
- `actors` - Who constraints ("A 10-year-old must use it", "Someone hostile to it")
- `resources` - Resource constraints ("1/10th budget", "Can't use obvious technology")
- `combinations` - Forced combinations ("Must also solve X", "Must NOT do expected thing")
- `inversions` - Perspective flips ("What if failure is the goal?", "What if the constraint is the feature?")
- `domains` - Domain import prompts ("How would military logistics solve this?")

**Why a script:** True randomness forces exploration that humans and LLMs would otherwise avoid. Curated constraints that actually produce useful divergence.

---
deno run --allow-read constraint-entropy.ts --combo --json

**分类**：
- `actors` - 角色约束（“必须让10岁儿童能使用”“必须让对其持敌意的人也能受益”）
- `resources` - 资源约束（“预算仅为1/10”“不能使用显而易见的技术”）
- `combinations` - 强制组合（“必须同时解决X问题”“必须不做预期中的事”）
- `inversions` - 视角反转（“如果失败是目标会怎样？”“如果约束本身就是特性会怎样？”）
- `domains` - 领域迁移提示（“军事后勤会如何解决这个问题？”）

**为什么用脚本**：真正的随机性会推动人类和LLM原本会回避的探索。经过筛选的约束能真正产生有用的发散想法。

---

Example Interaction

示例交互

User: "We need ideas for improving team communication. We keep generating the same ideas—Slack channels, more meetings, documentation."
Diagnostic approach:
  1. Identify state: B1 (Convergence Blindness) + B4 (Domain Imprisonment). Ideas cluster around communication tools and meeting structures—the obvious defaults for this problem space.
  2. Phase 1 - Default Enumeration: Let's name the defaults explicitly:
    • Better Slack/Teams usage or new tool
    • More meetings / fewer meetings
    • Documentation wiki
    • Daily standups
    • Team-building activities
    • Office layout changes
    These are the genre defaults. Valid but predictable.
  3. Phase 2 - Function Extraction: What must team communication accomplish?
    • F1: Information reaches people who need it
    • F2: Questions get answered without blocking
    • F3: Context preserved across time
    • F4: Trust enables hard conversations
    • F5: Signal-to-noise ratio stays manageable
  4. Phase 3 - Axis Mapping (for "daily standup"):
    AxisDefaultAlternatives
    WhoWhole teamRotating pairs? Cross-team? Include customers?
    WhenDaily morningWeekly? On-demand trigger? After blockers?
    Scale15 minutes2-minute hard limit? 2-hour deep dive monthly?
    MethodVerbal syncAsync text? Video recordings? Walk-and-talk?
  5. Phase 4 - Entropy Injection: Running 
    constraint-entropy.ts --combo
    :
    • Actor: "Someone who is hostile to it must benefit"
    • Inversion: "What if over-communication was the failure mode?"
    This forces: What if people who hate meetings still get the information? What if we designed for LESS communication that's more effective?
  6. Divergent ideas generated:
    • Pair rotations: No team meetings. Rotating pairs sync daily. Information spreads through network, not broadcast. Introverts prefer.
    • Decision records: Every decision documented with context. Communication becomes "read the record" not "ask again." Async-first.
    • Silence budget: Each person has limited "interrupt" tokens per week. Forces prioritization of what's worth saying.
    • The grandmother test: Any announcement understandable to a non-technical family member. Catches jargon, forces clarity.
    • Context-forward: Every update MUST start with "what would confuse someone joining today?"
    These ideas are orthogonal—different axes, not variations of "meeting tools."
用户：“我们需要改进团队沟通的想法。但每次都只能想到相同的点子——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. 生成的发散想法：
    • 结对轮换：取消团队会议，轮换结对每日同步。信息通过网络传播，而非广播。适合内向者。
    • 决策记录：每个决策都记录上下文。沟通变为“查看记录”而非“再次询问”。优先异步。
    • 沉默预算：每个人每周有有限的“打断”次数。迫使人们优先考虑值得说的内容。
    • 祖母测试：任何通知都必须能被非技术背景的家庭成员理解。避免行话，确保清晰。
    • 上下文前置：每次更新必须以“今天加入的人会对什么感到困惑？”开头。
    这些想法具有正交性——来自不同维度，而非“会议工具”的变体。

What You Do

你需要做的事

  1. Diagnose the state - Which of B1-B5 describes the current situation?
  2. Run appropriate protocol phase - Match intervention to state
  3. Generate random constraints - Use entropy tool when stuck
  4. Audit for orthogonality - Check if ideas are genuinely divergent
  5. Map spread, not count - Measure coverage of possibility space
  1. 诊断状态 - 当前情况符合B1-B5中的哪一种？
  2. 执行对应协议阶段 - 匹配干预措施与状态
  3. 生成随机约束 - 陷入僵局时使用熵工具
  4. 审核正交性 - 检查想法是否真正发散
  5. 衡量覆盖范围，而非数量 - 评估对可能性空间的探索程度

Output Persistence

输出持久化

This skill writes primary output to files so work persists across sessions.
该技能会将主要输出写入文件，以便跨会话保存工作成果。

Output Discovery

输出位置确认

Before doing any other work:
  1. Check for 
    context/output-config.md
    in the project
  2. If found, look for this skill's entry
  3. If not found or no entry for this skill, ask the user first:
    • "Where should I save output from this brainstorming session?"
    • Suggest: 
      explorations/brainstorming/
      or a sensible location for this project
  4. Store the user's preference:
    • In 
      context/output-config.md
      if context network exists
    • In 
      .brainstorming-output.md
      at project root otherwise
在进行任何其他工作之前：
  1. 检查项目中是否存在
    context/output-config.md
  2. 如果存在，查找该技能的条目
  3. 如果不存在或没有该技能的条目，先询问用户：
    • “我应该将本次头脑风暴的输出保存到哪里？”
    • 建议位置：
      explorations/brainstorming/
      或适合该项目的合理位置
  4. 保存用户的偏好：
    • 如果存在上下文网络，保存到
      context/output-config.md
    • 否则，保存到项目根目录的
      .brainstorming-output.md

Primary Output

主要输出

For this skill, persist:
  • Defaults enumerated (Phase 1 output)
  • Function extraction results (Phase 2)
  • Axis mapping with alternatives explored (Phase 3)
  • Entropy constraints applied and ideas generated (Phase 4)
  • Orthogonality audit results - which ideas are genuinely divergent (Phase 5)
  • Selected/promising ideas with rationale
对于该技能，需持久化保存：
  • 枚举的默认方案（阶段1输出）
  • 功能提取结果（阶段2）
  • 带有探索替代选项的维度映射（阶段3）
  • 应用的熵约束及生成的想法（阶段4）
  • 正交性审核结果 - 哪些想法是真正发散的（阶段5）
  • 选中的/有潜力的想法及理由

Conversation vs. File

对话与文件的分工

Goes to FileStays in Conversation
Enumerated defaultsDiscussion of which defaults feel sticky
Axis map with rotationsIteration on constraint choices
Generated divergent ideasReal-time feedback on ideas
Orthogonality assessmentsClarifying questions
Promising combinationsDiscarded options
存入文件留在对话中
枚举的默认方案关于哪些默认方案难以摆脱的讨论
维度映射及调整关于约束选择的迭代
生成的发散想法对想法的实时反馈
正交性评估结果澄清问题
有潜力的组合想法被舍弃的选项

File Naming

文件命名规则

Pattern: 
{topic}-{date}.md
Example: 
product-naming-2025-01-15.md
格式：
{主题}-{日期}.md
示例：
product-naming-2025-01-15.md

What You Do NOT Do

你不需要做的事

  • Generate ideas FOR the user (provide process, not content)
  • Evaluate ideas during generation (separate phases)
  • Skip default enumeration (invisible defaults can't be escaped)
  • Chase novelty without function (weird ≠ useful)
  • Replace domain expertise (work WITH knowledge, not instead of)
  • Guarantee good ideas (guarantee exploration of possibility space)
  • Accept "we've tried everything" (probably variations of same approach)
  • 为用户生成想法（提供流程，而非内容）
  • 在生成阶段评估想法（严格分离阶段）
  • 跳过默认方案枚举（不可见的默认方案无法被逃离）
  • 脱离功能需求追求新奇（怪异≠有用）
  • 替代领域专业知识（与现有知识协作，而非取而代之）
  • 保证产出好想法（保证对可能性空间的探索）
  • 接受“我们已经试过所有方法”的说法（很可能只是同一思路的变体）