agent-skills 创意提炼方法论：idea-refine 技能中的 7 种发散思维框架（Ideation Frameworks）实战指南

本文围绕 frameworks.md 这一参考文档展开，系统讲解 agent-skills 技能包中 idea-refine（创意提炼）技能内置的 7 种创意框架——SCAMPER、How Might We（HMW）、第一性原理、Jobs to Be Done（JTBD）、约束驱动、事前验尸（Pre-mortem）与类比启发（Analogous Inspiration）。读完本文，你能掌握每种框架的适用场景与操作要点，理解它们如何嵌入 idea-refine 的三阶段（发散—收敛—输出）工作流，并知道在面对一个模糊想法时如何选择正确的"思维透镜"，而不是机械地跑一遍所有框架。

框架的定位：被选择性调用的工具箱，而非检查清单

frameworks.md 开宗明义地确立了使用原则：

Use these frameworks selectively. Pick the lens that fits the idea — don't mechanically run every framework. The goal is to unlock thinking, not to follow a checklist.

即：按需选取与想法匹配的透镜，目标是为思考"松绑"，而不是走流程。这一原则与主文件 SKILL.md 中的指示完全一致——该文件在 Phase 1（理解与发散）阶段明确要求："Read frameworks.md in this skill directory for additional ideation frameworks you can draw from. Use them selectively — pick the lens that fits the idea, don't run every framework mechanically."（见 SKILL.md#L84）。

从源码结构看，idea-refine 技能的文件组织体现了"主流程 + 外挂参考"的分层设计：

• SKILL.md：三阶段主流程、内置的 7 个发散透镜、反模式与验证清单；
• frameworks.md：本文主角，补充的 7 个经典创意框架；
• refinement-criteria.md：Phase 2 使用的完整评估量表（用户价值、可行性、差异化、假设审计、决策矩阵）；
• examples.md：三个完整的示范会话（餐厅直接复购、文档协作功能、团队回顾流程改造）；
• idea-refine.sh：可选的初始化脚本。

值得注意的是，SKILL.md 的 Phase 1 自带一套 7 透镜生成法（Inversion 反转、Constraint removal 移除约束、Audience shift 受众迁移、Combination 组合、Simplification 简化、10x 放大、Expert lens 专家视角），而 frameworks.md 提供的 7 个框架是额外的、可按需调用的工具箱。两套机制的关系可以推断为：内置透镜用于每次会话的常规发散，frameworks.md 用于想法卡在某个特定困境时"对症下药"。

框架一：SCAMPER——对既有想法做七种变换

SCAMPER 是一种对既有想法进行结构化改造的方法，通过 7 种不同操作生成变体：

操作	核心提问
S — Substitute（替代）	哪个组件、材料或流程可以被替换？如果核心技術换掉呢？目标用户换掉呢？商业模式换掉呢？
C — Combine（组合）	如果把它与另一个产品、服务或想法合并？哪两件通常不搭配的东西能组合出新东西？
A — Adapt（借鉴）	还有什么东西与它类似？其他行业、领域甚至其他时代有什么可借用的想法？自然界有什么对应的平行结构？
M — Modify（放大/缩小）	如果把它放大 10 倍？缩小 10 倍？如果夸张化某一个特性？如果剥离到绝对最小？
P — Put to other uses（另作他用）	还有谁能用它？它能解决什么别的问题？放到一个完全不同的场景里会发生什么？
E — Eliminate（删除）	如果彻底删掉某个功能会怎样？零配置的版本是什么样？步骤减半是什么样？
R — Reverse/Rearrange（反转/重排）	如果步骤倒序执行？如果由用户做系统该做的事（或反过来）？如果价值链反转？

适用场景（Best for）：改进或重新构想既有产品/功能。对从零开始（greenfield）的想法帮助较小。

在 examples.md 的餐厅案例中可以看到 SCAMPER 思想的实战形态："Inversion — Charge the Customer, Not the Restaurant"（把配送费模型反转，向用户收小额溢价、餐厅零佣金）正是 Reverse 操作的直接应用；"What If Delivery Weren't Required?"（Pickup-first 模型）则对应 Eliminate——把"配送"这个最昂贵的组件整个删掉，只保留点单与自取。

框架二：How Might We（HMW）——把问题重述为机会

HMW 用"How Might We..."句式把问题重构为机会：

1. 从一个观察或痛点出发；
2. 重述为 "How might we [期望结果] for [具体用户] without [关键约束]?"；
3. 对同一个问题生成多个 HMW 表述——不同的重构方式会解锁不同的解法空间。

好 HMW 的三个特征：

• 足够窄，可以行动（例："…帮新用户在头 5 分钟内找到相关内容"）；
• 足够宽，允许创造性解法（不能窄成"…加一个推荐侧边栏"）；
• 包含一个迫使创造力的张力或约束。

坏 HMW 的三个特征：

• 太宽："How might we make users happy?"
• 太窄："How might we add a button to the settings page?"
• 内嵌了方案："How might we build a chatbot for support?"（这是方案不是问题）

适用场景：打破锚定思维。当有人已经锁定某个解法时，用 HMW 把他拉回问题本身。

HMW 在 idea-refine 工作流中不是一次性工具，而是贯穿全程的语法：Phase 1 第一步就是"Restate the idea as a crisp 'How Might We' problem statement"（SKILL.md#L60）；Phase 3 产出物 one-pager 的第一节 Problem Statement 也是一句话 HMW 表述（SKILL.md#L112-L116）。三个范例会话都以 HMW 重述开场，例如"让餐厅与大平台竞争"被重述为"How might we 让独立餐厅获得顾客期望的触达与便利，而不把它们推入侵蚀毛利与品牌的模式？"（见 examples.md）。

框架三：First Principles（第一性原理）——拆到基本事实再重建

第一性原理思考把想法拆解到基本事实，再从那里重建：

1. 我们确定知道什么是真的？（不是假设、不是惯例——是真正为真的东西）
2. 我们假设了什么？ 列出所有假设，包括那些感觉"理所当然"的。
3. 哪些假设可以被挑战？ 对每一个问："这真的是物理定律，还是仅仅'一直这么做'？"
4. 从真相重建。 如果只有这些基本事实，你会构建什么？

适用场景：突破渐进式思维（incremental thinking）。当每个想法都感觉只是对现状的小修小补时，这个框架最有用。

框架四：Jobs to Be Done（JTBD）——用户"雇佣"产品完成的任务

JTBD 聚焦用户真正想完成的事，而不是他们嘴上说要的东西。把任务分成三个层面：

• 功能任务（Functional job）：用户在完成什么具体任务？
• 情感任务（Emotional job）：用户想获得什么感受？
• 社会任务（Social job）：用户希望被他人如何看待？

标准格式："When I [情境], I want to [动机], so I can [期望结果]."

核心洞察：用户不是购买产品，而是"雇佣"它们来完成一项任务。竞争产品不一定在同一品类——原文给出的例子是：Netflix 的对手不只是其他流媒体，还包括"睡觉"。

适用场景：理解真问题。当你不确定自己解决的是不是正确的问题时。

框架五：Constraint-Based Ideation——用约束逼出创意解

主动施加约束来强制产生创造性方案，文档给出六类约束句式：

• 时间约束："如果只有 1 天来构建这个东西？"
• 功能约束："如果它只能有一个功能？"
• 技术约束："如果不能用最显而易见的那个技术？"
• 成本约束："如果它必须永远免费？"
• 受众约束："如果你的用户从没用过电脑？"
• 规模约束："如果需要支撑 10 亿用户呢？如果只支撑 10 个呢？"

适用场景：切开复杂度。当想法变得太大或太含糊时。

这个框架与 SKILL.md 内置透镜中的 "Constraint removal"（"如果预算/时间/技术不是因素？"）形成互补：一个做减法（移除约束看上限），一个做加法（压上约束看下限）。examples.md 中流程改造案例的收尾建议——"第一个修复应该是 0 分钟准备、0 成本"——正是约束思维在收敛阶段的体现。

框架六：Pre-mortem（事前验尸）——在失败发生前复盘

Pre-mortem 让想法"已经失败"，然后倒推：

1. 现在是 12 个月后。项目上线了，并且失败了。哪里出了错？
2. 列出所有合理的失败原因——技术、市场、团队、时机。
3. 对每个失败模式问：这是可预防的？还是"这个想法需要改变"的信号？
4. 哪些失败模式你愿意接受？哪些会直接杀死项目？

适用场景：文档明确将其定位为 Phase 2 评估阶段的工具——专门用于压力测试那些"感觉良好但没被压测过"的想法。这与 idea-refine 三阶段流程中的 Phase 2（Evaluate & Converge）呼应：该阶段要求对每个方向做压力测试（用户价值、可行性、差异化）并显式暴露隐藏假设（SKILL.md#L86-L106）。Pre-mortem 正是"暴露隐藏假设"的叙事化操作：先想象失败，再倒推假设。

框架七：Analogous Inspiration（类比启发）——跨领域找结构相似

看其他领域如何解决了类似的问题：

• 哪个行业已经解决了这个问题的某个版本？
• 如果是 [某具体公司/产品] 来做，它会做成什么样？
• 哪个自然系统是这样运作的？
• 历史上有什么先例？

文档特别强调了关键区分：要找结构层面的相似，而非表面层面的相似。"Uber for X"是表面类比；"一个解决陌生人之间信任问题的双边市场"才是结构性类比。

适用场景：文档将其定位为 Phase 1 扩展阶段的工具——生成与常规思路真正不同、而非仅表面变形的选项。

框架 × 阶段：选择透镜的实操映射

综合 frameworks.md 各框架的 "Best for" 说明与 SKILL.md 的三阶段流程，可以整理出如下的选择映射（供检索速查）：

你卡住的困境	优先使用的框架	对应阶段
想法是既有功能的改进，不知如何变换	SCAMPER	Phase 1 发散
思路锚定在某个方案上出不来	How Might We	Phase 1 重述
想法都只是在现状上小修小补	First Principles	Phase 1 发散
不确定自己解决的是不是正确的问题	JTBD	Phase 1 澄清
想法太大、太含糊	Constraint-Based Ideation	Phase 1 发散
想法感觉良好但从没被压测过	Pre-mortem	Phase 2 收敛
需要一个"真正不同"的选项	Analogous Inspiration	Phase 1 扩展

从框架到产物：idea-refine 的完整落地链路

7 个框架产出的是"发散素材"，最终要收敛为可执行的产物。idea-refine 技能把这条链路标准化为三步（SKILL.md#L10-L14）：

1. Understand & Expand（发散）：用 HMW 重述想法、问 3–5 个锐化问题（具体为谁、成功是什么样子、真实约束、试过什么、为什么是现在），生成 5–8 个有命名透镜的变体；
2. Evaluate & Converge（收敛）：把用户认可的变体聚成 2–3 个真正不同的方向，按用户价值/可行性/差异化三准则压测（完整量表见 refinement-criteria.md，其中包含 Painkiller vs Vitamin 判别、差异化六级排序，以及"Must Be True / Should Be True / Might Be True"三级假设审计），并显式暴露隐藏假设；
3. Sharpen & Ship（输出）：生成 markdown one-pager，包含 Problem Statement、Recommended Direction、Key Assumptions to Validate、MVP Scope、Not Doing（and Why） 与 Open Questions 六节（模板见 SKILL.md#L112-L136），经用户确认后保存到 docs/ideas/[idea-name].md。

可选地，运行初始化脚本预先创建产物目录：

bash skills/idea-refine/scripts/idea-refine.sh

从 idea-refine.sh 的源码可以看到，它做的事情非常克制：检查 docs/ideas 目录是否存在，不存在则 mkdir -p 创建，最后向 stdout 输出一行 JSON 状态（{"status": "ready", "directory": "docs/ideas"}）供调用方解析。

两个细节值得注意，它们是这套方法论"防走样"的设计：

• 质量上限：SKILL.md 的反模式清单明确禁止"生成 20+ 个想法"——5–8 个深思过的变体胜过 20 个浅层变体。这与 frameworks.md "不机械跑所有框架"的总原则一脉相承。
• 诚实而非附和：技能要求"Be honest, not supportive"——好的创意伙伴不是 yes-machine，要具体而友善地反驳弱想法。这一行为约束被评测用例固化了下来：evals/cases/idea-refine.json 中的对话评测期望明确包含 "The agent pushes back on weak aspects instead of only agreeing"，以及"输出包含显式 Not Doing 列表""收敛前先问锐化问题""显式暴露隐藏假设"等验收项。

小结

frameworks.md 的价值不在于提供 7 个新名词，而在于给 idea-refine 技能的发散阶段配备了一套可按症状选用的透镜：SCAMPER 改造既有想法、HMW 解除方案锚定、第一性原理突破渐进思维、JTBD 校准真问题、约束驱动切开复杂度、Pre-mortem 在 Phase 2 压测方向、类比启发在 Phase 1 生成结构性不同的选项。配合 SKILL.md 的三阶段流程、refinement-criteria.md 的评估量表与 examples.md 的三个示范会话，这套组合把"从一个模糊想法到一份带 Not Doing 列表的 one-pager"的完整路径变成了可复用、可验证的工程化实践。