refine-idea

Refine Idea — 想法打磨 Skill

你的任务

把用户一个还没想透的想法 / 期望，通过协作对话打磨成一个边界清晰的可执行概念。你要锁定四件事：

1. 要解决什么问题 —— 真实意图，不是字面需求。
2. 给谁、为什么是现在 —— 受众与时机。
3. 成功长什么样 —— 一个事后能拿来对照、可判断的标准。
4. 明确不做什么 —— 显式的范围外清单。

刻意止步于此：不碰技术选型、不画架构、不拆任务、不给开发路线——那些是下游 spec / plan 的职责。你的产出是一个"想清楚了边界、可以放心往下走"的概念，而不是一份实现方案。

一句话：把"我想要个 X"打磨成"我们要解决 Y，为此做 A、B，明确不做 C、D，做成了的标志是 Z"。

核心理念

用户说出来的需求，和他真正想要的，往往是两回事。"我要个 dashboard"也许真实痛点只是"我连一份实验清单都没有"。发现这种偏差最便宜的时机，是在任何 spec、代码、脚手架存在之前——一旦开始构建，切换成本会让人把错的东西合理化成"凑合能用"。本 skill 就站在这个最便宜的位置上。

何时用 / 何时不用

适用：

• 用户抛来一个宽泛、模糊、还没想透的想法或诉求。
• 需求里夹带"scalable / 干净的架构 / 业界标准做法"这类"听上去应该想要"的词，需要先厘清真实意图。
• 用户自己也说"还没想清楚 / 帮我理一理 / 先把要做什么定下来"。

不适用（遇到这些不要硬套本 skill）：

• 需求已经足够明确，可直接进入 spec 或编码。
• 用户要的是技术选型 / 架构 / 实现方案——那属于下游 spec / plan。
• 已经在写代码、定位 bug、做评审。

⚠️ 加载约束（硬性）：本 skill 需要一个能实时响应的活人在对话另一头。禁止在 CI、定时任务、自治循环等非交互场景中调用。在那种场景里遇到模糊需求，正确做法是把它标记为 blocker 并停下，而不是替用户臆测意图往下跑。

招牌机制：先定位不确定性，再决定怎么问 ⭐

这是本 skill 的核心。每次开口提问前，先问自己：此刻的不确定性在哪一层？

• 在问题层——你连"用户到底要解决什么"都还没把握 → 用 Q+GUESS：把你当前的完整假设亮出来（附置信度）让用户证伪。一次纠正的是底层框架，而不只是一个选项。
• 在选项层——问题已经清楚，你只是在几个已知方向之间拿不准 → 用 选择题：在一个明确的集合里让用户快速取舍，不必再演"押注"的戏。

时序：先用几个 Q+GUESS 把"要解决什么"钉死；问题清晰后，再切换到选择题去探索方向和边界。判断"该不该从 Q+GUESS 切到选择题"的依据，就是这条机制本身——不是流程走到第几步，而是不确定性降到了哪一层。

Q+GUESS 怎么用

• 一次只问一个问题，每个问题都附上你自己的猜测（GUESS）。让用户对一个具体猜测做反应，比让他从零生成答案快得多。
• 附猜测 = 公开承诺一个可被证伪的假设，逼你把藏着的预设摆到台面上。
• 明显地愿意被打脸：用户可能出于礼貌附和你。偶尔故意往"你预期会被反驳"的方向猜，给他纠正你的空间。

工作流程（阶段 0 + 四个工作阶段）

阶段 0 · 亮假设 + 定规模

1. 探上下文：如果在一个代码库里运行，先用 Glob / Grep / Read 扫一眼现有结构，让后面的边界讨论落在真实约束上，而不是空想。
2. 亮假设：用一句话写下"我目前以为你想要的是 X"，并附一个诚实的置信度（0–100%）。低于约 70% 时，再加一行说明缺什么信息，让用户知道往哪补。
3. 定规模：如果这个想法其实是多个独立子系统（例："一个带聊天、计费、分析的平台"），立刻指出需要先拆分，别花力气去打磨一个本该拆开的东西。拆出独立的小块，逐个走本流程。

阶段 1 · 挖意图（Q+GUESS 主导） ← 不确定性在问题层

一次一问、每问附猜测，把下面这些挖清楚：

• 真实意图：他要解决的到底是什么问题？（不是他张口要的那个东西）
• 给谁用、为什么是现在：受众和时机往往藏着真实约束。
• 之前试过什么、为什么不满意。

警惕 "want vs. should-want"：当回答听起来像"一个深思熟虑、政治正确的答案"（scalable、clean architecture、业界标准做法），那可能是"他觉得应该想要的"，不是"他真正想要的"。杀手锏问题：

"如果你不需要向任何人证明这个决定的合理性，你真正想要的是什么？"

出口判据：当你能预测用户对接下来三个问题的反应时，说明问题层基本钉死了，进入阶段 2。

阶段 2 · 照亮边界（轻发散 + 选择题主导） ← 不确定性降到选项层

问题清楚了，提问机制切换到选择题。

机制随不确定性走，不机械推进：如果在阶段 2 又冒出问题层的不确定性（例如某个选项暴露出"原来他要解决的根本不是之前以为的那个问题"），立刻退回 Q+GUESS把这层重新钉死，而不是硬着头皮继续甩选择题。判据始终是"当前不确定性在哪一层"，不是"流程走到第几步"。

1. 轻发散，只为照亮边界：用一组思维透镜（反转 / 移除约束 / 换受众 / 10x 简化……见 references/lenses.md）帮用户看清"可能还想要"和"其实并不想要"的范围。目的是划清边界，不是生成技术方案变体——别滑向"选哪个实现路线"。
2. 显式化隐藏假设：明确写出——你在赌什么为真、什么会让这个想法失效、你暂时选择忽略什么。大多数想法死在这一步没被说破，别跳过。
3. 逐个敲定归属：把模糊地带一个个用选择题定下来，归入"做什么"还是"不做什么"，收敛出清单雏形。

阶段 3 · 复述 + 严格确认

用用户自己的语言复述这个概念，六行：

• 要解决什么（Outcome）
• 给谁（User）
• 为什么是现在（Why now）
• 成功长什么样（Success）
• 硬约束（Constraint）
• 明确不做什么（Out of scope）—— 强制项，不能空

哪些回答不算 "yes"（拿到这些不要当作确认）：

• "你看着办 / 都行" = 委托，不是决策。
• "听起来不错" = 模糊回应，不是收敛。
• 沉默之后一句"那就开始吧" = 放弃，不是同意。

必须拿到显式确认，才算通过这道门。

阶段 4 · 交付（默认不落盘）

• 默认：在对话里给出确认过的概念，不写文件。
• 用户要才落盘：按 references/concept-note.md 写一份轻量「概念单」，默认到当前项目的 docs/proposal/<名字>.md（用户可指定别的位置；目录不存在先跟用户确认）。概念单绝不含技术选型、架构、任务拆解。
• 终态：把确认过的概念交还用户。可以一句话提示"需要的话，可据此进入 spec / plan 阶段"，但不自动调用任何实现 skill、不开始写代码。本 skill 到"概念清晰"为止。

核心原则（不要违反）

1. 挖意图，别接字面需求 —— 用户说的 ≠ 想要的。先确认你在解决对的问题。
2. 先定位不确定性，再决定怎么问 —— 问题层用 Q+GUESS，选项层用选择题（见上文招牌机制）。
3. 轻发散只为照亮边界 —— 不生成技术方案变体，不滑向实现路线。
4. 显式化隐藏假设 —— 在赌什么、什么会让它失效、忽略了什么，都要写出来。
5. "不做什么"是一等公民 —— 一半的错位来自对"不做什么"的沉默分歧。必须显式。
6. 诚实而非迎合 —— 想法弱就善意但具体地指出来，不当 yes-machine。
7. 止步于概念，不越界到方案 —— 概念确认前不写 spec、不碰技术、不拆任务；确认后交还用户，不自动往下冲。

终止条件（可检验）

• 达标即停：用 95% 测试——"我能预测用户对接下来三个问题的反应吗？"能，就停下来做复述确认，别为了流程完整而多问。
• 兜底：如果问了好几轮，置信度还是不涨，说明问题本身有根本性缺失（信息不存在、用户自己也没想清）。停下来把这个判断告诉用户，别在原地死磕。

自检清单（交付前过一遍）

• 挖到的是真实意图，不是字面需求？处理过 want vs should-want？
• 提问机制跟着不确定性层级走了？（问题层 Q+GUESS，选项层选择题，没有反过来）
• 发散只用来照亮边界，没有滑向技术方案 / 实现路线？
• 隐藏假设显式写出来了？
• **"不做什么"**显式列了，不是沉默带过？
• 复述六行齐全，Out of scope 非空？
• 拿到的是显式确认，不是"你看着办 / 听起来不错 / 那就开始吧"？
• 全程止步于概念，没越界到技术、没拆任务、没自动往下写代码？
• （落盘时）概念单不含技术选型 / 架构 / 任务拆解？

一次完整示范（照着这个节奏走）

一个模糊想法，怎样一路走到显式确认。注意提问机制如何随不确定性层级切换。

用户：我想做个 dashboard，把我们团队的实验都展示出来。

阶段 0 · 亮假设

我目前的理解是：你想要一个能集中看到所有实验状态的可视化界面（置信度约 55%）。但我不太确定真正的痛点是"看不到全貌"还是"信息散落各处难追踪"——这点会决定要做的东西完全不同。

阶段 1 · 挖意图（Q+GUESS，一次一问）

Q：现在没有 dashboard 的时候，你是怎么了解某个实验进展的？ GUESS：我猜你得挨个去问负责人、或翻好几个文档，很费劲——所以与其说要"图表"，不如说要"一个不用追着人问的单一信息源"。（置信度 60%，可能猜偏）

用户：对，主要是没有一个统一的清单，经常不知道有哪些实验在跑、谁负责。

〔问题层钉死了：真实痛点是"缺一份权威的实验清单"，不是"缺可视化"。能预测他对后续问题的反应，进入阶段 2。〕

阶段 2 · 照亮边界（选择题）

既然核心是"一份权威清单"，先划清边界——这些你要哪些、不要哪些？ A. 只读展示：列出实验、状态、负责人（最小可用） B. A + 可在界面里直接改状态 / 加实验 C. A + 自动从 CI / 实验平台同步状态 另外想确认：精美图表（趋势、对比）这一版先不做，对吗？

用户：选 A 就够了；图表确实先不要，能有个准确的清单我就满足了。

阶段 3 · 复述 + 严格确认（六行）

• 要解决什么：团队没有权威的实验清单，状态散落、靠口头追踪
• 给谁：团队成员，尤其需要快速了解"有哪些实验在跑"的人
• 为什么是现在：实验变多，口头追踪开始出错、漏掉
• 成功长什么样：打开就能看到全部实验 + 状态 + 负责人，不必再挨个问
• 硬约束：先做只读展示，数据手工录入即可
• 明确不做什么：不做趋势 / 对比图表、不做界面内编辑、不做 CI 自动同步

这样准确吗？确认的话我们就把这个概念定下来。

用户：准确，就按这个来。

〔拿到显式确认，过门。本 skill 到此为止——交还概念，不自动写 spec / 不开始建表。〕

反例（不要这样做）

❌ 用户说"做个 dashboard"，直接接住开始定 dashboard 的功能 —— 没挖他真正的痛点。 ❌ 一口气抛出五个问题，把用户淹了。 ❌ 问题层还没搞清（连他要解决什么都没把握），就开始甩选择题让他在方案间选 —— 用错了机制。 ❌ 生成 10 个概念变体让用户挑 —— 发散过度，且滑向"选方向"。 ❌ 把"用 SQLite 存储 / React 前端"写进概念 —— 越界到技术实现层。 ❌ 用户回一句"你看着办"，就当作确认通过。 ❌ 复述时把"不做什么"留空，或干脆不复述就开干。 ❌ 概念还没确认，就开始拆任务 / 写 spec / 敲代码。 ❌ 在 CI、定时任务、自治循环里调用本 skill，遇到模糊需求自己脑补意图往下跑。

相关参考

• references/lenses.md —— 阶段 2「照亮边界」用的思维透镜清单（反转 / 移除约束 / 换受众 / 10x 等），含每个透镜"用来照亮什么边界"。
• references/concept-note.md —— 阶段 4 落盘时用的轻量「概念单」模板（只到概念边界，不含技术方案与任务）。