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：通过决策树的形式，按轮次把当前问得动的问题一次问完，直到双方形成共同理解。

时序：先用几个 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 写一份轻量「概念单」，默认到当前项目的 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 —— 阶段 2 调用的 composable 能力单元。
• references/concept-note.md —— 阶段 4 落盘时用的轻量「概念单」模板（只到概念边界，不含技术方案与任务）。