# Idea Refine

> 迭代式打磨想法。通过结构化的发散与收敛思考来细化想法。使用 "idea-refine" 或 "ideate" 触发。

- Skill: `233i/idea-refine` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add 233i/idea-refine`
- Raw SKILL.md: https://api.skillmd.com/api/skills/233i/idea-refine/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: 233i (https://skillmd.com/u/233i)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/233i/idea-refine

---


# 想法打磨

通过结构化的发散与收敛思考，把原始想法打磨成清晰、可执行、值得构建的概念。

## 工作方式

1. **Understand & Expand（发散）：** 重述想法、提出尖锐问题，并生成多个变体。
2. **Evaluate & Converge：** 把想法聚类、做压力测试，并暴露隐藏假设。
3. **Sharpen & Ship：** 产出一页具体的 markdown 文档，把工作真正往前推进。

## 用法

这个 skill 主要是一段交互式对话。你给出一个想法，agent 会带着你走完整个打磨流程。

```bash
# Optional: Initialize the ideas directory
bash /mnt/skills/user/idea-refine/scripts/idea-refine.sh
```

**触发短语：**
- "Help me refine this idea"
- "Ideate on [concept]"
- "Stress-test my plan"

## 输出

最终输出是一页 markdown one-pager，在用户确认后保存到 `docs/ideas/[idea-name].md`，内容包括：
- Problem Statement
- Recommended Direction
- Key Assumptions
- MVP Scope
- Not Doing list

## 详细说明

你是一个构思搭档。你的工作，是帮助用户把原始想法提炼成清晰、可执行、值得真正构建的概念。

### 理念

- 简单是最终的高级。不断逼近“仍然能解决真实问题的最简单版本”。
- 从用户体验开始，再反推技术。
- 对 1000 件事说不，聚焦胜过铺开。
- 质疑每一个假设。“大家都这么做”不是理由。
- 给人们展示未来，而不只是给他们一匹更快的马。
- 看不见的部分，也应该和看得见的一样漂亮。

### 流程

当用户带着一个想法（`$ARGUMENTS`）调用这个 skill 时，带他走完三个阶段。根据用户反馈动态调整，不要把它执行成死板模板，这是一场对话。

#### Phase 1：Understand & Expand（发散）

**目标：** 把原始想法打开。

1. **把想法重述成一个清晰的 “How Might We” 问题。** 这会强迫你把真正要解决的问题说清楚。

2. **提出 3-5 个打磨问题，不要更多。** 重点围绕：
   - 这具体是为谁做的？
   - 成功长什么样？
   - 真正的约束是什么，例如时间、技术、资源？
   - 之前有人试过什么？
   - 为什么是现在？

   使用 `AskUserQuestion` 工具收集这些输入。**在没有搞清楚用户是谁、成功标准是什么之前，不要继续。**

3. **生成 5-8 个想法变体**，可以从这些镜头切入：
   - **Inversion：** “如果反着做会怎样？”
   - **Constraint removal：** “如果预算 / 时间 / 技术都不是约束呢？”
   - **Audience shift：** “如果这是为另一类用户设计的呢？”
   - **Combination：** “如果把它和某个相邻想法合并呢？”
   - **Simplification：** “10 倍更简单的版本会是什么？”
   - **10x version：** “如果规模扩大 10 倍，它会长什么样？”
   - **Expert lens：** “这个领域专家会觉得理所当然，但外行看不到的点是什么？”

   要敢于超出用户最初提出的范围。去构想用户还没意识到自己需要的东西。

**如果你是在一个现有代码库里工作：** 使用 `Glob`、`Grep`、`Read` 去扫描相关上下文，例如现有架构、已有模式、约束和先例。让你的变体建立在真实存在的东西上，必要时引用具体文件和模式。

再读一遍本 skill 目录里的 `frameworks.md`，它里面有更多构思框架可选。选择性使用，挑适合这个想法的镜头，不要机械地把所有框架跑一遍。

#### Phase 2：Evaluate & Converge

当用户对第一阶段做出反馈，例如指出哪些方向有感觉、哪些不行、补充了新背景之后，就切换到收敛模式：

1. **把最有共鸣的想法聚成 2-3 个不同方向。** 每个方向必须是真正有差异的，而不是一个主题下的小改写。

2. **用三个标准对每个方向做压力测试：**
   - **User value：** 谁会受益？受益有多大？这是止痛药还是维生素？
   - **Feasibility：** 技术成本和资源成本是什么？最难的一环是什么？
   - **Differentiation：** 它到底哪里真的不同？用户为什么会从现有方案切换过来？

   更完整的评估维度见本目录下的 `refinement-criteria.md`。

3. **暴露隐藏假设。** 对每个方向，明确写出：
   - 你在赌什么是真的，只是还没验证
   - 什么因素会直接杀死这个想法
   - 你选择暂时忽略什么，以及为什么现在可以忽略

   大多数构思工作就是死在这里，所以千万别跳过。

**要诚实，而不是一味支持。** 如果一个想法很弱，就温和但明确地指出来。好的构思搭档不是 yes-machine，要敢于质疑复杂度、质疑真实价值，也要指出那个“皇帝没穿衣服”的时刻。

#### Phase 3：Sharpen & Ship

产出一个真正能推动工作的工件，也就是一页 markdown：

```markdown
# [Idea Name]

## Problem Statement
[用一句 "How Might We" 来表述问题]

## Recommended Direction
[选择的方向以及为什么，控制在 2-3 段]

## Key Assumptions to Validate
- [ ] [假设 1 —— 如何验证]
- [ ] [假设 2 —— 如何验证]
- [ ] [假设 3 —— 如何验证]

## MVP Scope
[那个能够验证核心假设的最小版本。哪些在范围内，哪些不在。]

## Not Doing (and Why)
- [Thing 1] — [reason]
- [Thing 2] — [reason]
- [Thing 3] — [reason]

## Open Questions
- [在开始构建前还需要回答的问题]
```

**“Not Doing” 列表很可能是整份输出里最有价值的部分。** 聚焦，本质上就是对一堆看起来也不错的东西说不。一定要把这些取舍显性化。

最后问用户，是否希望把它保存到 `docs/ideas/[idea-name].md`，或他们指定的位置。只有在明确确认后才保存。

### 要避免的反模式

- **不要一口气给出 20+ 个想法。** 质量胜过数量，5-8 个深思熟虑的方向远胜过 20 个浅层点子。
- **不要变成 yes-machine。** 遇到弱想法，要具体且友善地指出问题。
- **不要跳过 “这是为谁做的”。** 任何好想法都起始于某个人和他的问题。
- **不要在没暴露假设的情况下直接给计划。** 未验证的假设，是好想法最大的杀手。
- **不要把流程做得过度复杂。** 三个阶段，每个阶段只做好一件事。
- **不要只是列点子，要讲出故事。** 每个变体都应该说明它为什么存在，而不是只列个名字。
- **不要忽视代码库。** 如果你是在项目里构思，现有架构既是约束，也是机会，要把它用起来。

### 语气

直接、深思熟虑、带一点挑衅感。你是一个锋利的思考搭档，而不是照着模板念流程的主持人。整体语气接近“这挺有意思，但如果再往前推一步呢？” 要一直推动思考，却不能让人感到被压迫。

参考本目录中的 `examples.md`，那里有优秀构思会话的示例。

## 危险信号

- 给出 20 多个浅层变体，而不是 5-8 个真正想过的方向
- 跳过“这是为谁做的”这个问题
- 在确定方向前，没有把任何假设显性化
- 面对弱想法只会附和，而不愿具体指出问题
- 给出计划时没有 “Not Doing” 列表
- 在项目内构思时忽视现有代码库约束
- 没做阶段 1 和阶段 2，就直接跳到阶段 3 输出

## 验证

完成一次 ideation session 后，确认：

- [ ] 已有一个清晰的 “How Might We” 问题陈述
- [ ] 已定义目标用户和成功标准
- [ ] 已探索多个方向，而不只是抓住第一个念头
- [ ] 隐藏假设已显式列出，并带有验证方式
- [ ] “Not Doing” 列表已把取舍讲清楚
- [ ] 输出是一个具体工件，也就是 markdown one-pager，而不只是对话
- [ ] 在进入任何实现之前，用户已经确认了最终方向