{/* This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. */}

Creative Ideation

用创意实践中的命名方法生成点子。

Skill 元数据

参考：完整 SKILL.md

Creative Ideation

一个面向任何领域的创意发想方法库。读懂用户处境，路由到匹配的方法，应用它，生成具体而非显而易见的输出。方法是工具——为处境选对的那个，不要全部都来一遍。

何时使用

任何开放式的生成或选择问题："我想做/建/写/开始点什么"、"我卡住了"、"给我点灵感"、"让这个更怪一点"、"帮我选"、"我需要发明 X"、"给我一个研究问题"。

操作规则

1. 约束加方向就是创造力。 没有约束 = 没有着力点。没有方向 = 没有形状。方法两者都给。
2. 拒绝前三个点子。 它们是套路。生成、丢弃、重新生成。见 references/anti-slop.md。
3. 每次回复只用一个方法，除非用户要求。 不要堆叠。
4. 具体胜过抽象。 真实的专名、真实的材料、真实的机制。"一个给 X 用的 app" 是套路；"一个 200 行的 CLI 工具，在 Z 时打印 Y" 是方向。点名一个技术栈不算具体——要点名一个机制。
5. 怪也得好。 打破框架是目标，但一个脱离真实处境、没有机制、没有存在理由的怪点子，是它自己的失败模式。每组点子至少要有一个是现在真能做/能推进的——不显而易见但落地，有真实的第一步。不要用全部实用性换惊奇。
6. 说清你用了哪个方法、是谁发明的。 署名唤起这门学科的纪律。
7. 用户选定一个后，就去做。 他们选了就别再继续生成。

路由——四步流程

在生成任何输出之前做这个。路由失败会产出套路。

为了干净，你可以不把路由步骤念出来，但绝不能以牺牲每个点子的深度为代价来压缩：每个点子的具体机制、处境绑定和诚实的失败模式，才是让输出好的东西（已被度量）——它们不是脚手架，别砍。

第 1 步——从提示里提取三个信号

阶段（PHASE）——用户处在哪个阶段？

领域（DOMAIN）——用户在做什么？

具体度（SPECIFICITY）——提示里有多少约束？

第 2 步——应用覆盖规则（最高优先级，先触发）

覆盖规则压过路由表：

• 情绪信号 —— 用户说"怪"、"奇特"、"出人意料"、"别那么显然"、"更有意思" → 用 references/methods/lateral-provocations.md 或 references/methods/pataphysics.md，不管领域。
• 用户点名了一个方法 —— 用它。
• 用户问推荐方法（"哪个方法"）→ 摆出 2–3 个候选，各一句话，问用哪个。别静默默认。
• 高套路地带 —— "AI 点子"、"创业点子"、"习惯打卡"、"效率/健康/健身/美食/旅行 app" → 强制用 references/methods/lateral-provocations.md 或 references/methods/pataphysics.md，压过显而易见的方法。拒绝前 5 个点子，不是 3 个。

第 3 步——先按阶段路由，再按领域

按阶段（不分领域都适用）：

按领域（当 GENERATING 且领域已知时）：

第 4 步——处理歧义和矛盾

• 多条路都说得通 → 选最贴近用户原话的那个。别为了显得高深而选最有意思的方法。
• 真的含糊 → 问一个澄清问题，别静默猜。例如："你是在生成点子，还是在已有点子里挑？" / "这是给小说、散文还是别的？"
• 信号互相矛盾（例如"怪的创业点子"→ 产品领域 + 怪的情绪）→ 显式堆叠两个方法。说清你在做什么："用 jobs-to-be-done 做产品框架 + lateral-provocations 打破显而易见的形状。"
• 没有匹配 → 约束派发（references/full-prompt-library.md）是安全回退。
• 同一个问题又问一遍 → 换方法。方法变了 = 点子分布变了。

反默认检查（生成前跑一遍）

• 正要写"这是 5 个点子："或一个光秃秃的编号列表？→ 停。先选个方法。
• 正要默认进入通用 LLM 式头脑风暴？→ 停。从上面选条路。
• 输出看起来像没路由过的 LLM 会产出的东西？→ 路由失败，重来。

默认的 LLM 模式，正是本 skill 要取代的东西。你若不路由就生成，就打败了这个 skill。

更深的边缘情况（情绪信号、堆叠、反模式）见 references/heuristics.md。

输出格式

约束派发默认路径：

## Constraint: [Name] — from [Source]
> [The constraint, one sentence]

### Ideas

1. **[One-line pitch]**
   [2-3 sentences — what specifically is made, why it's interesting]
   ⏱ [weekend/week/month]  •  🔧 [stack/medium/materials]

2. ...
3. ...

其他方法用该方法规定的格式（TRIZ 产出矛盾分析；OuLiPo 产出约束文本；Oblique Strategies 产出一张应用的卡片 → 下一步行动）。别把每个方法都硬塞进约束模板。

每组点子，无论方法：

• 说出用了哪个方法。在套路地带，说出你拒绝了哪些显而易见的点子。
• 给每个点子它的具体机制和诚实的失败模式/权衡/适合谁。这种深度才让点子落地——是被度量的，不是装饰。
• 至少把一个点子标为落地的那个——现在能做/能推进，不显而易见但有真实第一步。其他可以往更怪的方向跑；这一个必须真能做。别让整组都怪却不切实际。

文件地图

• references/full-prompt-library.md —— 约束库，按领域分段（General、Software、Physical、Social、Lists）。SPECIFICITY=NONE 的默认路径。
• references/method-catalog.md —— 每个方法一行摘要 + 何时用
• references/heuristics.md —— 边缘情况的扩展决策树
• references/anti-slop.md —— 反套路规则；应用到每个输出
• references/exercises.md —— 限时练习（5 分钟 / 30 分钟 / 1 小时 / 一天 / 一周）
• references/methods/ —— 22 个命名方法，每个一个文件，只加载你正在用的那个

署名

约束派发核心改编自 wttdotm.com/prompts.html。方法取自每个方法文件中引用的一手来源。