swing-options

创意采样器

按概率加权的选项生成器，旨在对抗典型性偏差，发掘非传统的替代方案。其核心价值在于揭示“显而易见”的选择背后的隐藏假设。

应对锚定偏差这一认知缺陷——AI 会默认选择第一个或最显而易见的方案，而不去探索完整的决策空间，导致用户错过从未考虑过的更优替代方案。

规则（绝对要求）

1. 默认恰好生成 5 个选项。 如果决策空间中真正不同的方法少于 4 种，则生成所有不同的方法，并至少提供 1 种对问题本身进行非传统重新构想的方案。绝不要用只有细微差异的同类想法凑数。如果用户指定了其他数量，则遵照执行。
2. 至少有 1 个选项必须是非传统的（非传统区或黑马区）。这正是整个流程的意义所在——发掘通常会被压下的想法。
3. 分配相对概率区间，表示典型程度，而非质量。尽可能根据可观察信号进行估算：社区采用情况、教程普及程度、StackOverflow 上的出现频率、会议演讲频率。无法给出有依据的精确概率时，请改用区间标签：
   • 常规（p > 40%）——大多数人会选择的“显而易见”的方案
   • 主流（p 20-40%）——通常会考虑的替代方案
   • 少见（p 10-20%）——可行但经常被忽略的方案
   • 非传统（p 5-10%）——挑战既有假设
   • 黑马（p < 5%）——彻底重新思考 至少有一个选项必须来自最低的两个区间。
4. 概率越低 = 创意越强，而非质量越差。应明确说明低概率选项值得探索。
5. 不提供默认推荐。 将所有选项都呈现为可行方案，让用户在了解各种权衡后自行决定。
6. 必须分析权衡。 每个选项都必须有具体的优缺点，而非含糊的描述。
7. 输入含糊时必须先澄清。 如果决策问题过于模糊，无法确定什么算“非传统”，则在生成选项前提出一个关于约束条件的澄清问题。约束条件决定了常规与非传统之间的界限。

流程

步骤 1：检查输入是否清晰

生成选项前，请确认：

• 是否清楚地陈述了要做的决定？
• 是否已知足够的约束条件，以区分常规方案和非传统方案？

如果没有，请提出一个有针对性的问题。例如：“你最大的约束是什么——时间、预算还是团队专业技能？这决定了哪些选项对你而言属于非传统方案。”

步骤 2：界定决策空间

明确：

• 要做什么决定？（技术、架构、方法、设计、策略）
• 有哪些约束条件？（时间、预算、团队技能、现有技术栈）
• “显而易见”的答案会是什么？（这是我们要挑战的答案）

步骤 3：生成选项（优先覆盖分布）

从完整的概率分布中抽取选项，而不只是选择最可能的那个答案。

Probability zones (use zone labels when precise % cannot be grounded):
  Conventional  (p > 40%)  — the "obvious" choice most would pick
  Mainstream    (p 20-40%) — commonly considered alternative
  Uncommon      (p 10-20%) — valid but often overlooked
  Unconventional (p 5-10%) — challenges assumptions
  Wild card     (p < 5%)   — radical rethink, paradigm shift

强制至少有一个选项来自最低的两个区间。

步骤 4：分析每个选项

对每个选项，提供：

1. 方案是什么（1 句话）
2. 为什么它可能是最佳选择（最有力的支持理由）
3. 为什么它可能失败（最有力的反对理由）
4. 最适合……时使用（该选项胜出的具体场景）
5. 相对于其他选项的预估工作量（低 / 中 / 高）

步骤 5：揭示隐藏假设

呈现所有选项后，明确说明：

• “常规选择假设了 [X]。如果这一假设不成立，请考虑选项 [Y, Z]。”
• 指出哪些约束条件如果解除，会改变选项的排序。

输出格式

## Decision: [The question being decided]

### Constraints
- [constraint 1]
- [constraint 2]

### Options

#### 1. [Option Name] — Conventional (p ~ XX%)
> [One-line description]

| Dimension | Assessment |
|-----------|------------|
| Best argument FOR | [concrete reason] |
| Best argument AGAINST | [concrete reason] |
| Best suited when | [specific scenario] |
| Effort | Low / Medium / High |
| Risk level | Low / Medium / High |

#### 2. [Option Name] — Mainstream (p ~ XX%)
> ...

#### 3. [Option Name] — Uncommon (p ~ XX%)
> ...

#### 4. [Option Name] — Unconventional (p ~ XX%)
> ...

#### 5. [Option Name] — Wild card (p ~ XX%)
> ...

### Hidden Assumptions
- The conventional choice (Option 1) assumes: [assumption]
- If [condition changes], reconsider: Option [N]
- Constraint "[X]" was taken as fixed — but is it really?

### Decision Matrix

| Criteria | Opt 1 | Opt 2 | Opt 3 | Opt 4 | Opt 5 |
|----------|-------|-------|-------|-------|-------|
| [user constraint 1] | Strong / Moderate / Weak | ... | ... | ... | ... |
| [user constraint 2] | Strong / Moderate / Weak | ... | ... | ... | ... |
| [user constraint 3] | Strong / Moderate / Weak | ... | ... | ... | ... |
| **Hidden criterion:** [X] | Strong / Moderate / Weak | ... | ... | ... | ... |

### Decision Matrix Rules
- Derive 3-5 criteria **directly from the user's stated constraints** (budget, timeline, team size, etc.)
- Add exactly 1 criteria the user did NOT mention but should consider (label it "Hidden criterion")
- Rate each option per criterion: **Strong** / **Moderate** / **Weak** (relative to the other options)
- Do NOT use numerical scores — they imply false precision for qualitative assessment
- If one option dominates across all criteria, explicitly note this in Hidden Assumptions — the criteria selection may be biased toward the conventional choice

质量校准

糟糕的输出（应避免）

## Decision: Which database for our new service?

#### 1. PostgreSQL — p ≈ 35%
#### 2. MySQL — p ≈ 25%
#### 3. MariaDB — p ≈ 20%
#### 4. CockroachDB — p ≈ 12%
#### 5. Amazon Aurora — p ≈ 8% ⚡ Unconventional

### Hidden Assumptions
- PostgreSQL is probably the best choice for most use cases.

问题：

• 选项 1–3 几乎没有区别（都是传统 SQL，只是范式相同）
• 概率缺乏依据——为什么是 35%，而不是 25%？
• “非传统”选项（Aurora）只是同类方案的托管版本
• “隐藏假设”部分毫无增益，只是在重复显而易见的内容
• 方法缺乏真正的多样性

优秀的输出（应追求）

## Decision: Which database for our new service?

### Constraints
- Team of 3, familiar with SQL
- Read-heavy analytics + some transactional writes
- Budget: < $500/mo infra

#### 1. PostgreSQL — Conventional (p ~ 50%)
> Battle-tested relational DB with strong analytics extensions (pg_analytics, TimescaleDB).

#### 2. ClickHouse + SQLite — Uncommon (p ~ 15%)
> Split reads (ClickHouse for analytics) from writes (SQLite for transactions). Optimizes for actual access pattern.

#### 3. DuckDB embedded — Unconventional (p ~ 8%)
> In-process analytical DB. Zero infrastructure. Handles the read-heavy workload at zero cost; pair with any simple write store.

#### 4. Managed Supabase — Mainstream (p ~ 22%)
> PostgreSQL with auth/APIs built-in. Trades control for development speed.

#### 5. Event sourcing + materialized views — Wild card (p ~ 5%)
> Don't pick a database — design the data flow. Events are the source of truth; views are disposable projections. Database becomes an implementation detail you can swap later.

### Hidden Assumptions
- The conventional choice assumes your read and write patterns are similar enough for one DB. If analytics queries are 10x more frequent than writes, a split architecture (Opt 2, 3) may cost less and perform better.
- "Team knows SQL" is treated as a constraint, but DuckDB (Opt 3) is also SQL — the real constraint is operational complexity, not query language.
- If the service grows past the team of 3, Option 5's event sourcing makes future database migrations trivial — worth considering if you expect growth.

为何更好：

• 每个选项都代表一种截然不同的方法（单一数据库、拆分架构、嵌入式、托管式、范式转变）
• 区域标签以可观察到的采用模式为依据
• “隐藏假设”部分会质疑问题的框架，并关联到具体选项
• 另辟蹊径的选项会重新定义问题本身，而不只是挑选一种冷门技术

适用场景

• 架构决策：“单体还是微服务，还是……”
• 技术选型：“选哪个数据库／框架／语言”
• 设计方案：“这个功能应该如何组织”
• 策略：“应该如何发布／营销／扩展”
• 问题解决：“如何修复／改进／优化”
• 任何发现自己正要默认选择某个显而易见答案的时刻

不适用场景

• 有唯一正确答案的事实类问题（使用 swing-research）
• 需求明确且没有决策点的任务
• 方法显而易见且没有争议的简单实现
• 用户已经做出决定、只需要执行时

集成说明

• 与 swing-clarify 配合： 对含糊请求，先运行 swing-clarify，再调用此技能。明确范围后，效果会更好。
• 与 swing-review 配合： 将选定的选项交给对抗性评审进行压力测试
• 单独使用： 通过 /swing-options [question] 直接调用，快速获得决策支持

注意事项

• 虚假的多样性： 不要生成只是细微变化的选项。每个选项都应代表一种截然不同的方法或范式。
• 概率作秀： 不要给出无法依据证据支撑的具体百分比。缺乏可观察数据时，使用区域标签。“常规”是诚实的；“p = 37.2%”则不是。
• 埋没重点： 如果在给定约束下某个选项明显更好，就在“隐藏假设”中说明——但仍要公平呈现所有选项。
• 忽视约束： 另辟蹊径的选项仍应能在既定约束内实现，只是采用出乎意料的路径。
• 缺乏力度的“隐藏假设”： “选项 1 可能最好”不算假设分析。指出具体假设，说明什么情况会使其不成立，并说明哪些选项会从中受益。
• 标准洗白： 不要挑选天然有利于常规选择的决策矩阵标准。如果选项 1 每一项都胜出，说明标准存在偏见——要明确指出。