title: “Creative Ideation — Generate ideas via named methods from creative practice” sidebar_label: “Creative Ideation” description: “Generate ideas via named methods from creative practice”

{/* 本页面由 website/scripts/generate-skill-docs.py 根据技能的 SKILL.md 文件自动生成。请直接编辑源文件 SKILL.md，而非此页面。 */}

创意构思

通过创意实践中的特定方法来生成创意点子。

技能元数据

参考：完整的 SKILL.md 文件

:::info 以下是当触发该技能时 Hermes 会加载的完整技能定义。当技能处于激活状态时，智能体看到的指令即为此内容。

::

创意构思

一个涵盖各领域的创意方法库。首先分析用户的需求状况，匹配对应的方法，再加以应用，最终生成具体且富有新意的成果。这些方法均为工具——需根据具体情况选择最合适的工具，而非全部使用。

适用场景

任何开放式的问题或需要选择的情况：“我想创造/构建/撰写/开始某件事”、“我陷入了僵局”、“给我一些灵感”、“让这个更奇特一点”、“帮我做选择”、“我需要发明X”、“给我一个研究课题”。

运行规则

1. 约束条件与明确方向是创造力的核心。 没有约束则缺乏方向，没有方向则无法形成具体形态。这些方法能同时提供两者。
2. 拒绝前三个生成的点子。 它们质量较差。需反复生成、舍弃后再重新生成。详情请参阅 references/anti-slop.md。
3. 除非用户另有要求，否则每次回复仅使用一种方法。 不要叠加多种方法。
4. 具体性优于抽象性。 应使用真实的专有名词、真实的材料与真实的运作机制。“一个用于X的应用程序”属于模糊表述；而“一个200行长的CLI工具，当Z发生时能输出Y”则更具方向性。仅提及技术栈并非具体表现——需明确具体的运作机制。
5. 奇特的同时也要具备可行性。 破除常规是目标，但若某个点子虽然奇特，却缺乏实际背景、运作机制或存在依据，那它本身就属于失败案例。每组生成的点子中至少应包含一个真正现在即可构建/实施的方案——即虽不寻常但有现实基础，并且具备明确的第一个行动步骤。不要为了追求新奇而牺牲实用性。
6. 需注明所使用的方法及其发明者。 明确归属能增强方法的严谨性。
7. 一旦用户选定某个方法，即应着手实现它。 用户做出选择后不要再继续生成其他点子。

路由机制 —— 四步流程

在生成任何输出之前，必须先完成此步骤。若路由失败，生成的点子质量将很差。

如果表述更简洁，可省略对路由步骤的说明，但绝不能以牺牲每个点子的深度为代价：每个点子的具体运作机制、与用户情境的关联以及真实的失败可能性，才是决定输出质量的关键因素——它们并非临时框架，不可删减。

第一步 —— 从提示语中提取三个信号

阶段 —— 用户当前处于哪个阶段？

领域 —— 用户正在创造/处理的内容属于哪个领域？

具体性程度 —— 提示语中包含多少约束条件？

第二步 —— 应用优先级更高的规则

这些优先级规则会覆盖常规的路由机制：

• 情绪信号 —— 用户提到“奇特”、“奇怪”、“令人惊讶”、“不要那么常规”、“更有趣” → 无论属于哪个领域，均使用 references/methods/lateral-provocations.md 或 references/methods/pataphysics.md 中的方法。
• 用户指定了某种方法 —— 直接使用该方法。
• 用户请求推荐方法（“用哪种方法？”） → 提供2–3种候选方法，每一种用一句话简要说明，再询问用户选择哪一种。不要擅自默认。
• 属于低质量生成的高风险领域 —— 如“AI相关点子”、“初创公司点子”、“习惯追踪工具”、“提升效率/健康/健身/饮食/旅行类应用” → 强制使用 references/methods/lateral-provocations.md 或 references/methods/pataphysics.md，而非常规方法。需拒绝前5个生成的点子，而非3个。

第三步 —— 先按阶段路由，再按领域分类

按阶段路由（适用于所有领域）：

按领域路由（当处于构思阶段且已明确领域时）：

第四步 —— 处理歧义与矛盾情况

• 存在多条合理路径 → 选择最符合用户原始表述的路径。不要为了显得高明而选择最有趣的方法。
• 确实存在歧义 → 只询问一个澄清问题，不要擅自猜测。例如：“您是想要生成新的点子，还是从已有的点子中选择？” / “这是用于小说、散文，还是其他类型的内容？”
• 不同信号相互矛盾（例如“奇特的初创公司点子”——产品领域 + 奇特的情绪） → 明确叠加两种方法。需说明所采用的方法组合：“对于产品框架部分使用 jobs-to-be-done 方法，同时运用 lateral-provocations 方法来打破常规思维模式。”
• 没有匹配的路径 → 采用约束条件处理机制（references/full-prompt-library.md）作为安全备选。
• 再次提出相同问题 → 更换使用方法。不同的方法会带来不同的点子生成结果。

防止默认行为的检查（在生成前执行）

• 正准备输出“以下是5个点子：”或单纯的数字列表？→ 停下。先选择一个方法。
• 正准备直接采用通用的LLM式头脑风暴模式？→ 停下。先按照上述步骤选择路径。
• 生成的输出看起来像未经路由处理的LLM会产生的内容？→ 路由失败，需重新处理。

默认的LLM模式正是该技能旨在替代的。如果在不经过路由处理的情况下直接生成内容，就等于违背了该技能的设计初衷。关于更多边缘情况（如情绪信号、方法叠加、不良模式等），请参阅 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 — 约束库，按领域分类（通用、软件、物理、社会、列表）。当设置 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。各方法则源自相应方法文件中引用的原始资料。