设计思维（Design Thinking）
v2026.5.17当用户要求设计思维（包括明确提及或带有明显拼写错误的指令）或希望进行以人为本的探索——同情需求，定义问题，头脑风暴，原型设计意图，并确定下一步要学习的内容时，使用此技能。适用于HCD、服务或UX概念冲刺、构建前如何可能风格的发现，或根据用户证据重构，即使在混乱的背景下。跳过此技能，当规格已经完全确定且不需要发现时，或当任务仅为代码维护且无需用户问题定义时。
by 运行时依赖
安装命令
点击复制技能文档
设计思维（Design Thinking） 爱上问题，而不是第一个解决方案。以学习为结尾，而不仅仅是想法。如何运用这个技能：每个阶段都有一个明确的标题，按以下顺序：同理心（Empathize）→ 定义（Define）→ 思想生成（Ideate）→ 原型设计（Prototype）→ 测试计划（Test plan）。
设置（开始前运行） 在一个简短的块中：设计挑战——谁受到影响以及在什么情况下？默认通过：同理心（Empathize）→ 定义（Define）→ 思想生成（Ideate）→ 原型设计（Prototype）→ 测试计划（Test plan）（声明这一行）。如果用户、约束或成功信号缺失，问最多3个问题，然后继续。以简单语言记录任何剩余的差距或工作假设（不使用括号标签）。
阶段 同理心（Empathize） 谁——主要用户或利益相关者（事实与[推断]）。 工作/痛点/收益——他们试图做什么以及什么会伤害他们。 背景——需要何时/何地出现。不要伪造引语；只对用户提供的内容进行概括。
定义（Define） 洞察声明——连接痛点和背景的非显而易见的紧张关系。 观点（POV）——“[用户]需要[动词]因为[洞察]。” 如何可能（How Might We，HMW）——2-3个由POV打开的范围明确的问题。
思想生成（Ideate） 数量+多样性。使用HMW作为提示。将想法标记为理想/可行/可行的假设（未经验证）。产生一个有实质性的列表（除非用户指定一个固定数量）。
原型设计（Prototype） 描述低保真度的工件：纸质流程、角色扮演脚本、着陆烟雾测试、可点击的草图。对于每一个：目的——这个工件回答什么问题？保真度说明：一行将工件放在草图和交互式光谱之间（不使用低/中标签）。
测试计划（Test plan） 学习目标——什么会让你相信这个想法是错误的？参与者/样本（或[TBD]）。信号——要观察的行为或指标。下一次迭代——如果结果混合，会发生什么变化。
执行规则 定义必须反映同理心实际包含的内容；不要编造实地研究。不要在原型设计之前将思想生成压缩成单一解决方案。测试计划必须包括可证伪的信号。
检查清单（在响应前验证） 设置：设计挑战+默认通过 同理心区分事实与[推断] POV + HMW在思想生成之前 思想生成是有实质性的；使用理想/可行/可行标签 原型设计说明目的和一行保真度说明（不使用低/中标签） 测试计划具有学习目标和信号