| name | xx-clarify |
| description | 需求澄清技能。当用户有模糊的产品想法但说不清到底要解决什么问题、给谁用、做成什么样时使用。默认快速模式一次走完 5 步（锁定问题陈述 / JTBD 重定义 / 用户故事映射找盲点 / Kano 分类与优先级 / 输出澄清卡）直接输出一张简化澄清卡；用户说"再深一点"才进入该步的深入模式，展开 5W1H 全表、Forces of Progress 四股力、walking skeleton 断点表、Kano 五类、OST 结构图等方法论细节。每步附判断标准与 AI 执行约束。 |
需求澄清
模糊想法不是需求。在判断"该不该做"之前，先把"到底要做什么"问清楚。
这个技能做什么
帮你在快速模式约 15 分钟 / 深入模式 30-60 分钟内，把"我想做个 XX 工具"这种模糊想法，澄清成结构化的问题定义 + 机会清单，输出一张澄清卡。
模糊想法最常见的死法不是做不出来，而是一开始就没问清楚：到底给谁、在什么场景下、解决什么可感知的问题。结果做到一半发现"这根本不是用户要的"。
本技能是 01-think 层的第一个 skill：xx-ai-feature 判断"产品要不要 AI 能力"，xx-goal 定"目标"，xx-research 验"需求真不真"——而本技能在它们之前，先把"模糊想法"变成"可被判断的需求"。
双模式说明：
- 快速模式（默认）： AI 一次走完 5 步，直接输出简化澄清卡（每步只取核心结论，不展开方法论细节），不每步停下来等确认。
- 深入模式（按需）： 用户说"再深一点"/"第 N 步我不确定"/"展开说说"时，才进入该步的深入模式（展开 5W1H 全表、Forces of Progress 四股力、walking skeleton 断点表、Kano 五类、OST 结构图）。深入模式按原有"每步确认"节奏走。
交互节奏：
| 步 | 做什么 | 产出 | 快速模式取什么 | 进入下一步的条件 |
|---|
| 1 | 锁定问题陈述 | 一句话 problem statement | 一句话 problem statement（谁+场景+可感知后果） | 快速模式：直接往下走 / 深入模式：用户说"对/可以" |
| 2 | JTBD 重定义 | outcome statement + 四股力 | outcome statement + 推力/拉力两句 | 同上 |
| 3 | 用户故事映射找盲点 | walking skeleton + 断点清单 | 一条 walking skeleton + 2-3 个最致命断点 | 同上 |
| 4 | Kano 分类 + 优先级 | 带 Kano/优先级的机会清单 | 机会清单 + MVP 取法（哪些进 MVP） | 同上 |
| 5 | 输出澄清卡 | 澄清卡（含假设 + 下一步） | 简化澄清卡（含 2-3 条假设 + 下一步） | 卡片交付，技能结束 |
AI 执行约束（快速模式）： 禁止在每步停下来等确认，一次性走完 5 步出简化澄清卡。每步只取核心结论，不展开方法论全表。出卡后主动问"要不要对某一步再深一点？"
AI 执行约束（深入模式）： 进入某步深入模式后，每步结束必须输出一个明确的确认问题（如"这版问题陈述对吗？哪里要改？"），得到用户"对/可以/进入下一步"才继续。用户说"不对"就原地修改，不跳步、不抢跑。
如何判断用户要不要深入： 用户说"再深一点"/"第 N 步我不确定"/"展开说说"/"第 N 步怎么得出的"→ 进入该步深入模式，展开对应方法论细节。
第 1 步：锁定问题陈述
快速模式只取：一句话 problem statement（谁 + 场景 + 可感知后果）。
要回答：到底是谁、在什么场景下、因为什么、受了什么损失？
用 5W1H 把模糊想法逼成一句话（深入模式展开 5W1H 全表）：
Who 谁（具体到职业 + 场景，不是"用户"）
What 遇到什么问题（可观察的行为，不是"需要个工具"）
When 什么时候发生（触发场景）
Where 在哪里发生（物理/数字位置）
Why 为什么是问题（现有方案哪里不行）
How 现在怎么凑合的（替代行为）
一句话 problem statement：
[谁] 在 [什么场景] 下，因为 [什么问题]，
导致 [什么可感知的后果]，希望 [什么改变]。
判断标准（给人）： problem statement 必须有具体的"谁"和"场景"，能想象出一张脸；必须有"可感知的后果"（浪费时间/被打回/丢客户），不能只说"不方便/体验差"。出现"用户/大家/一般人"等泛词，视为不达标。
AI 执行约束： 快速模式下，若用户输入信息不足以填满 problem statement 模板，AI 用合理推断补全并标注"推断"。深入模式下，若用户只说"做个 XX 工具"，必须用 5W1H 逐项追问。problem statement 里出现"用户""大家""一般人"等泛词，标红追问"具体是哪类人、在什么场景下"。后果若不可感知，追问"这件事没解决会损失什么"。
第 2 步：JTBD 重定义
快速模式只取：outcome statement + 推力/拉力两句。
要回答：用户"雇佣"这个产品来完成什么任务？
把第 1 步的问题转成 outcome statement（任务视角，不是功能视角）：
当 [情境]，
我想 [完成什么任务]，
以便 [得到什么可感知的结果]。
再用 Forces of Progress（四股力，深入模式展开）检查这个需求有没有动力：
| 力 | 含义 | 小象取色例 |
|---|
| 推力 | 现状哪里让用户不满 | 客户看不懂 Hex，方案被打回 |
| 拉力 | 新方案哪里吸引人 | 一秒出中式色名，专业又好懂 |
| 焦虑 | 换方案顾虑什么 | AI 命名准不准？会不会闹笑话 |
| 习惯 | 现状惯性在哪 | 现在搜官网查，虽然慢但"靠谱" |
判断标准（给人）： outcome statement 的"[结果]"必须是用户能感知的"成果"（方案一次过 / 客户看懂），不是"功能"（用 AI 命名）。四股力里至少能说清"推力"和"拉力"——说不清推力，说明痛点是脑补的。
AI 执行约束： 若"[我想做什么]"写成"使用 XX 功能"而非"完成 XX 任务"，必须改写为任务视角。四股力缺推力或拉力，标"动力不足，需求可疑"，建议回第 1 步重挖痛点，不硬往下走。
第 3 步：用户故事映射找盲点
快速模式只取：一条 walking skeleton + 2-3 个最致命断点。
要回答：用户从触发到完成，端到端走一遍会卡在哪？
先画 walking skeleton（最小端到端主干，一条线，不是功能清单）：
[触发] → [步骤1] → [步骤2] → ... → [完成/交付]
再沿这条线找断点：用户会卡住、放弃、或需要补救的地方（深入模式展开断点表）。
| 断点 | 卡在哪 | 卡住后果 |
|---|
| 断点 1 | … | …（可感知的损失） |
| 断点 2 | … | … |
判断标准（给人）： walking skeleton 必须是端到端一条线（有触发、有终点），不是功能罗列。每个断点必须标"卡住后果"，没后果的断点不算真断点。
AI 执行约束： 若 walking skeleton 只是功能罗列（如"取色、命名、海报"），必须重排成时序流程。每个断点必须附"卡住后果"，缺后果就追问"卡在这用户会怎样"。断点超过 5 个时，提示用户先聚焦最致命的 2-3 个。
第 4 步：Kano 分类 + 优先级筛选
快速模式只取：机会清单 + MVP 取法（哪些进 MVP）。
要回答：哪些该进 MVP，哪些该砍？
把第 3 步发现的机会点做 Kano 分类（深入模式展开 Kano 五类全表）：
| Kano 类 | 定义 | 判断口径 |
|---|
| 基本 | 没有就骂街 | 缺了它产品不能用 |
| 期望 | 越多越好 | 用户会主动比较、挑多的 |
| 兴奋 | 没有也行，有了惊艳 | 用户没想过，用了惊喜 |
| 无差异 | 有没有都一样 | 用户不在意 |
| 反向 | 做了更糟 | 做了用户反而反感 |
再用 MoSCoW + RICE 排优先级：
MoSCoW：Must / Should / Could / Won't（本版）
RICE 简评：(Reach × Impact × Confidence) / Effort，给高/中/低即可
MVP 取法： 基本（全要）+ 期望（核心 1-2 个）+ 兴奋（只取 1 个做差异化）。
判断标准（给人）： 每个机会点必须归到 Kano 某一类，不能全标"期望"。MVP 里的兴奋型不超过 1 个——多了就没了惊艳点。
AI 执行约束： 若所有功能都标"期望"或都标"Must"，必须追问"如果只能留一个，留哪个、为什么"，逼出区分。兴奋型进 MVP 超过 1 个，标红提示"差异化点过多，建议砍到 1 个"。无差异和反向类必须标 Won't，不能含糊带过。
第 5 步：输出澄清卡
快速模式只取：简化澄清卡（含 2-3 条假设 + 下一步）。
要回答：澄清完的东西，怎么交给下一步？
用 OST（Opportunity Solution Tree，深入模式展开结构图）把前 4 步收口：
outcome（来自第 2 步 outcome statement）
└─ opportunity（来自第 3 步断点 = 机会点）
└─ solution（来自第 4 步 MVP 取法）
└─ experiment（要验证的假设 + 方法）
整理成澄清卡：
## 澄清卡
### 问题陈述
[第 1 步的一句话 problem statement]
### JTBD
[第 2 步 outcome statement]
推力：… 拉力：… 焦虑：… 习惯：…
### 机会清单（带 Kano + 优先级）
| 机会点 | Kano | MoSCoW | RICE |
| … | … | … | … |
MVP = 基本(…) + 期望(…) + 兴奋(…)
### 假设清单
1. [假设]（最危险？）→ 验证方法：…
2. [假设] → 验证方法：…
### 建议下一步
- 假设 X → 用 xx-research 找 5-10 人验证
- 商业逻辑 → 用 xx-business 画布
- 需求清楚后 → 用 xx-prd 定义 MVP
判断标准（给人）： 每个假设必须可证伪（能说出什么数据算通过）。建议下一步必须指向具体 skill 和具体动作，不能是"继续想"。
AI 执行约束： 澄清卡任一字段为空，标"证据不足，需回第 N 步补"，不留空格。假设必须可证伪，不可证伪的（如"用户会喜欢"）必须改写成可观测行为。建议下一步不能是"继续想/再讨论"，必须是"走 X 技能做 Y"。
验收清单
快速模式最低要求（简化卡必须有的）
深入模式完整要求（深入模式时逐项检查）
AI 执行约束： 任意一项不满足，必须明确标注"该项证据不足/不达标"，不能补全脑补。快速模式出卡后主动提示"要不要对某一步深入"。
示例：小象取色 从"我想做个取色工具"到结构化问题定义
以下是深入模式的完整演示（5 步全展开）。快速模式输出会更简——直接给一张简化澄清卡，不展开 5W1H 全表、四股力、断点表、Kano 表。
模糊想法： "我想做个取色工具"
第 1 步 · 锁定问题陈述
5W1H 追问后：
- Who：每周做配色 ≥3 次的平面/UI 设计师，常接国风/品牌项目
- What：取到屏幕颜色后只有 Hex，无法快速转成可交付的中式色名
- When：客户现场沟通配色、交付方案时
- Where：设计师工位 / 客户现场（手机上）
- Why：Hex 客户看不懂；中式色名要翻官网，一个色找半天
- How：现在搜官网查 / 自己编名字 / 直接发 Hex 凑合
一句话 problem statement：
设计师在客户现场沟通配色时，因为只能给出 Hex 色号、客户看不懂，导致方案被打回反复修改，希望快速把屏幕颜色转成客户能理解的中式色名。
第 2 步 · JTBD 重定义
outcome statement：
当我在客户现场需要确认一个颜色时，我想一秒把这个颜色转成可交付的中式色名，以便客户立刻看懂、方案一次过。
四股力：
- 推力：客户看不懂 Hex，方案被打回
- 拉力：一秒出中式色名，专业又好懂
- 焦虑：AI 命名准不准？会不会出错闹笑话
- 习惯：现在搜官网查，虽然慢但"靠谱"
第 3 步 · 用户故事映射找盲点
walking skeleton：
打开小程序 → 摄像头对准颜色 → 点击取色 → 显示中式色名 →（可选）生成配色方案 →（可选）生成海报 → 保存历史
断点清单：
| 断点 | 卡住后果 |
|---|
| 取色不准（光线/反光） | 色名错，交付出错 |
| AI 命名不专业/有错 | 客户质疑专业度 |
| 只有单色没有配色 | 还是要回去凑方案 |
| 现场没网 | AI 用不了，整条流程断 |
第 4 步 · Kano 分类 + 优先级
| 机会点 | Kano | MoSCoW | RICE |
|---|
| 摄像头实时取色 | 基本 | Must | 高/中 |
| AI 中式色名 | 期望 | Must | 高/中 |
| 配色方案生成 | 兴奋 | Should | 中/中 |
| 海报模板 | 兴奋 | Could | 中/低（付费点） |
| 历史记录 | 期望 | Should | 中/低 |
| 离线取色 | 无差异 | Won't（本版） | 低/高 |
MVP = 基本（取色）+ 期望（中式色名）+ 兴奋（配色方案，1 个差异化点）
第 5 步 · 澄清卡
问题陈述： 设计师在客户现场沟通配色时，因为只能给 Hex、客户看不懂，导致方案被打回，希望快速把屏幕颜色转成可交付的中式色名。
JTBD： 一秒把颜色转成可交付中式色名，让客户看懂、方案一次过。
机会清单： 见第 4 步表。MVP = 取色 + 中式色名 + 配色方案。
假设清单：
- 设计师愿意把 AI 命名结果直接交付给客户（最危险）→ 验证：手工 MVP，帮 10 个设计师命名，看几人直接用于交付
- 客户能看懂"故宫红/天青色"这类中式色名 → 验证：拿命名结果给 5 个非设计行业客户看
- 设计师愿意为高级配色/海报模板付费 → 验证：落地页留资看付费意愿
建议下一步：
- 假设 1 → 用 xx-research 找 5-10 个设计师验证
- 假设 3 → 用 xx-business 画布看付费逻辑
- 需求清楚后 → 用 xx-prd 定义 MVP 功能
使用方式
把你的模糊想法告诉我，我默认快速模式一次走完 5 步，直接给你一张简化澄清卡。你看完觉得哪一步想再深一点（比如"第 3 步断点我不确定"/"展开说说 Kano"），就说"再深一点"或"第 N 步深入"，我进入那一步的深入模式，按"每步确认"的节奏跟你走。你只需用自然语言说想法和判断"对/不对/改哪里"。
对话示例：
- "我想做个取色工具" → 我快速走完 5 步，直接给简化澄清卡，再问"要不要对某一步深入"
- "第 2 步的 outcome 我觉得不对" → 进入第 2 步深入模式，原地改，不跳步
- "断点我觉得还少一个" → 进入第 3 步深入模式补断点
- "再深一点" → 我问你指哪一步，进入该步深入模式
- "5 步都走完了，可以了" → 我把澄清卡给你，建议你走 xx-research 验证最危险假设
与其他技能的关系
- 后续： 澄清卡 →
xx-research 验证假设清单（尤其最危险假设）/ xx-business 画布看商业模式 / xx-prd 定义 MVP 功能
- 后续：
xx-ai-feature 可在本技能后判断"产品要不要 AI 能力"（澄清了任务才好判断产品该不该加 AI）
- 前置定位： 本技能是 01-think 的入口，模糊想法先过本技能，再进
xx-goal 定目标、xx-research 验需求
- 回溯：
xx-track 上线后用真实数据回校澄清卡里的假设清单是否成立
方法论来源
- JTBD（Jobs-to-be-Done） — outcome statement + Forces of Progress，Bob Moesta / jobstobedone.org
- 用户故事映射（User Story Mapping） — walking skeleton 找断点，Jeff Patton《User Story Mapping》
- Kano 模型 — 需求分类（基本/期望/兴奋/无差异/反向），狩野纪昭
- OST（Opportunity Solution Tree） — outcome→opportunity→solution→experiment 结构化输出，Teresa Torres《Continuous Discovery Habits》
