关于 worst-idea
Worst Possible Idea 是用于设计或改造产品、流程和团队惯例的创意思考技能。它通过分析看似可能出现的糟糕方案及其失败机制，再反转机制，提炼积极的设计原则。
主要功能
- 01生成可信的糟糕方案
- 02说明方案失效的机制
- 03将机制反转为设计原则
- 04把原则发展为具体方向
- 05归纳反复出现的失败模式
- 06排序想法而不催促决策
适用场景
- 01寻找改进用户引导流程的方法
- 02重新设计落地页或定价页
- 03分析团队惯例中的失败模式
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/worst-idea确认已加载。
附带文件references/worked-example.md
详细介绍
最糟糕的点子
这种技巧的作用
不要寻求问题的最佳解决方案，而是询问最糟糕的解决方案。设计一些必定会把事情搞砸的方案，然后逐一剖析，找出它们糟糕的确切机制。把这个机制反过来，就能得到一个功能点。这种做法之所以有效，是因为「什么是最好的设计？」会触发每个人的顾虑，最终得到安全、显而易见的答案；而「怎样才能确保失败？」则能消除人们害怕出错的心理，让他们畅所欲言——每一种被明确指出的失败模式，都是一条反向表达的设计原则。
来源：逆向头脑风暴，据称源自 Hotpoint 在 20 世纪 50 年代的产品开发实践；也是 d.school/IDEO 引导工具包中的标准方法，称为「最糟糕的点子」。
工作流
步骤 1：确认目标
有效的目标应是一个具体的创意问题，并以需要设计或重新构想的事物来表述：引导流程、定价页、落地页、命名方向，或团队运行的一种仪式。如果目标不明确，就提出一个聚焦的问题——「我们要设计什么？什么样才算‘好’？」
拒绝执行分析类工作请求——调试、审查代码、实现变更——并建议改用分析方法。重新设计或构思这类流程属于有效的创意目标：「重新构想我们的代码审查仪式」符合范围；「审查这个 PR」则不符合。
步骤 2：提出真正糟糕的方案
提出 5–8 个会让问题恶化的方案。标准很高：每个方案都必须足够可信，达到某个地方确实有人推出过它的程度。卡通式的邪恶点子（「删掉用户的文件！」）太容易想，也毫无启发。真正有用的糟糕点子，是现实团队自圆其说后采纳的那些——在会议上听起来几乎无可辩驳的点子。
直截了当地呈现这些点子。不要弱化它们，也不要事先为它们道歉。
步骤 3：找出糟糕的机制
针对每个糟糕的点子，用一句话说明它为什么糟糕——说清机制，而非症状。不要说「它很烦人」，而要指出它失败的结构性原因。
示例：「它糟糕，是因为它让用户向产品证明价值，而不是让产品反过来证明价值。」
机制就是这项技巧的全部。没有说清机制的糟糕点子，只是个糟糕点子。
步骤 4：反转机制，而非点子
把机制反转为它的反面。这不是「别做那件糟糕的事」——那样只会回到中性状态。反转机制才能得出积极的设计原则。
糟糕点子的机制：「它让用户向产品证明价值。」 反转：「先让产品证明价值，再要求用户做任何事。」
只反转表面意思（「所以，别让用户证明价值」）是常见的错误。要反转的是底层力量。
步骤 5：发展反转后的机制
选出 2–4 个最有力的反转机制，并进一步推演成具体方向——实际的功能、布局、流程或文案。反转后的机制是一条原则；具体方向则是周一就能着手实现的东西。
步骤 6：扫描元模式
糟糕的机制往往会聚成一类。把它们并列起来阅读，并直接说出其共同模式：它描绘了这件事绝不能做什么。通常，三个或四个看似不同的糟糕点子，其实只是同一个根本问题换了不同伪装。明确说出这个问题——它通常是整场讨论中最犀利的成果。
步骤 7：诚实排序，不施加定案压力
给剩下的方向排序。说明哪些方向有力、哪些薄弱，以及原因。提供下一步选择——进一步发展其中一个、再提出一批糟糕点子、换用其他技巧，或就此停止。绝不要逼用户做决定。
诚实机制
暗藏巧思的淘汰。 有时，一个“最糟糕的点子”原来暗藏妙处——它其实是一种真正的商业模式，或一个伪装起来的合理功能。遇到这种情况，这个点子就不再是最糟糕的点子，必须淘汰，并换成一个真正糟糕的点子。请直说：
“按 Bug 报告收费”实际上伪装成了一种支持服务分级定价模式——太好了，换一个。
这样才能确保这一批点子真实可信。如果没有任何点子让你皱眉，这一批就是假的。
无效机制。 并非每种机制反转后都会变得有用。有些会变成平淡无奇的常识，有些会变成你已经遵循的原则，有些则什么也不是。至少展示一个无效机制——把它反转，看看结果，然后宣布它无效，而不是粉饰它。如果每种机制都能变出宝藏，就说明输出是根据答案倒推出来的。
这一批点子本身失效时。 如果大多数机制反转后都变成了你已经遵循的原则，这项技巧就告诉了你一个真实情况：问题并非缺乏想象力，更多糟糕的点子也无济于事。说出这个诊断，建议用户下一步采用适合的技巧，然后停下——不要亲自执行：
- 反转后的内容都是你已经在做的事 → 设计本身是合理的，问题在别处。建议使用
concept-fan，确认你正在解决正确的问题。 - 你想不出任何人真的会推出的糟糕点子 → 目标太小或太抽象，因此没有失效模式。建议使用
random-stimulus拓宽生成范围。
不要做什么
- 不要淡化糟糕的点子。 皱眉就是信号。如果一个坏点子真的让人不适，就保留这种不适感——软化后的版本毫无启发。
- 不要只反转表面。 “不要做 X”不是对 X 的反转，而是缺失了 X。要把 X 背后的机制反转成一种正向力量。
- 不要跳过机制这一步。 从坏点子直接跳到好点子，就跳过了唯一真正起作用的环节。机制才是这项技巧的核心；没有它，你只是在猜功能。
- 不要强求每种机制都带来成果。 明确展示无效机制。
- 不要催促用户做决定。 这项技巧用于发散；收敛应由用户完成。
参考资料
./references/worked-example.md— 一次真实对话，展示了完整流程，包括一个无效机制和一个被淘汰的点子