# Refine Idea

> 当用户提出一个想法或诉求时，通过对话挖掘真实意图、明确边界，提炼成清晰、可执行的概念。

- Skill: `rollrollroll/refine-idea` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add rollrollroll/refine-idea`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rollrollroll/refine-idea/raw
- Safety review: PASS (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: RollRollRoll (https://skillmd.com/u/rollrollroll)
- Updated: 2026-08-19
- Page: https://skillmd.com/skills/rollrollroll/refine-idea

---


# Refine Idea

## 你的任务

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

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

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

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

## 核心理念

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

## 何时用 / 何时不用

**适用**：

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

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

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

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

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

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

- **在问题层**——你连"用户到底要解决什么"都还没把握 → 用 **Q+GUESS**：把你当前的完整假设亮出来（附置信度）让用户证伪。一次纠正的是底层框架，而不只是一个选项。
- **在选项层**——问题已经清楚，针对解决这个问题的边界需要明确 → 交给 **[grilling](../grilling/)**：通过决策树的形式，按轮次把当前问得动的问题一次问完，直到双方形成共同理解。

**时序**：先用几个 Q+GUESS 把"要解决什么"钉死；问题清晰后，交给 grilling 来形成共同理解明确边界。

### Q+GUESS 怎么用

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

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

### 阶段 0 · 亮假设 + 定规模

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

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

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

- **真实意图**：他要解决的到底是什么问题？
- **给谁用、为什么是现在**：受众和时机往往藏着真实约束。
- **之前试过什么、为什么不满意**。

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

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

### 阶段 2 · 明确边界（调用 grilling） ← 不确定性降到选项层

**调用 grilling**，传入：
   - **范围**：**只展开概念层**——做什么 / 不做什么、受众、成功标准、硬约束、隐藏假设。技术选型、架构、数据模型、实现路线**不再讨论范围内**，留给下游 make-design。
   - **已定事实与约束**：阶段 0 探索到的现有结构、阶段 1 定下的结论。
   - **交回形态**："做什么 / 不做什么"两份清单 + 挂起项 + 被剪掉的分支。

**出口判据**：概念层的 frontier 空了——每个边界分支要么归了"做"、要么归了"不做"、要么被显式挂起或剪出去。

> **机制随不确定性走，不机械推进**：如果 grilling 的某一轮暴露出**问题层**的不确定性（例如某个选项让你发现"原来他要解决的根本不是之前以为的那个问题"），立刻中止轮次、**退回 Q+GUESS**把这层重新钉死再重新grilling。

### 阶段 3 · 复述 + 严格确认

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

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

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

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

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

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

- **默认**：在对话里给出确认过的概念，**不写文件**。
- **用户要才落盘**：按 [references/concept-note.md](references/concept-note.md) 写一份轻量「概念单」，默认到当前项目的 `docs/proposal/<名字>.md`（用户可指定别的位置）。概念单**绝不含**技术选型、架构、任务拆解。
- **落盘前先确认目录**：若目标目录（默认 `docs/proposal/`）尚不存在，**必须先问用户是否新建该目录，得到明确同意后，才能创建目录并写入**——不要默默 `mkdir`。
- **终态**：把确认过的概念交还用户。可以一句话提示"需要的话，可据此进入 spec / plan 阶段"，但**不自动调用任何实现 skill、不开始写代码**。本 skill 到"概念清晰"为止。

## 核心原则（不要违反）

1. **挖意图，别接字面需求** —— 用户说的 ≠ 想要的。先确认你在解决对的问题。
2. **先定位不确定性，再决定怎么问** —— 问题层自己用 Q+GUESS，选项层交给 grilling 跑轮次（见上文招牌机制）。**调用即交出判据定义权**：不重述 grilling 的规则。
3. **显式化隐藏假设** —— 在赌什么、什么会让它失效、忽略了什么，都要写出来。
4. **"不做什么"是一等公民** —— 一半的错位来自对"不做什么"的沉默分歧。必须显式。
5. **诚实而非迎合** —— 想法弱就善意但具体地指出来，不当 yes-machine。
6. **止步于概念，不越界到方案** —— 概念确认前不写 spec、不碰技术、不拆任务；确认后交还用户，不自动往下冲。

## 终止条件（可检验）

- **阶段 1 达标即停**：用 95% 测试——"我能预测用户对接下来三个问题的反应吗？"能，就切进阶段 2，别为了流程完整而多挖。
- **阶段 2 穷尽即停**：概念层 frontier 空即止。这一层**不适用**达标即停——"一半的错位来自对『不做什么』的沉默分歧"，给边界留余量正是沉默分歧的来源。范围外的分支靠**剪枝**出局，不靠不问。
- **兜底**：如果问了好几轮，置信度还是不涨，说明问题本身有根本性缺失（信息不存在、用户自己也没想清）。**停下来把这个判断告诉用户**，别在原地死磕。

## 反例（不要这样做）

❌ 用户说"做个 dashboard"，直接接住开始定 dashboard 的功能 —— 没挖他真正的痛点。
❌ 问题层还没搞清（连他要解决什么都没把握），就开始甩选择题让他在方案间选 —— 用错了机制。
❌ 阶段 2 调 grilling 却不声明范围，任由它把技术选型、架构也问了 —— 越界到下游。
❌ 在本 skill 里重述一遍 grilling 的轮次与 frontier 规则 —— 判据该住在被调 skill 里，抄一份必然改一处忘一处。
❌ grilling 剪掉的分支不带进阶段 3 说明，让用户以为整棵树都问过了。
❌ 把"用 SQLite 存储 / React 前端"写进概念 —— 越界到技术实现层。
❌ 用户回一句"你看着办"，就当作确认通过。
❌ 复述时把"不做什么"留空，或干脆不复述就开干。
❌ 概念还没确认，就开始拆任务 / 写 spec / 敲代码。
❌ 在 CI、定时任务、自治循环里调用本 skill，遇到模糊需求自己脑补意图往下跑。

## 相关参考

- [grilling](../grilling/) —— 阶段 2 调用的 composable 能力单元。
- [references/concept-note.md](references/concept-note.md) —— 阶段 4 落盘时用的轻量「概念单」模板（只到概念边界，不含技术方案与任务）。