# Idea Refine

> 通过结构化的发散与收敛思维，将原始创意精炼为清晰、可执行的概念。当创意仍然模糊时、在确定方案前需要压力测试假设时、或在收敛前想拓展选项时使用。触发词：创意精炼、想法打磨、压力测试我的方案、帮我完善这个想法、发散思维

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

---


# 创意精炼
## 何时使用

当你需要通过结构化的发散与收敛思维，将原始创意精炼为清晰、可执行的概念时使用此技能。当创意仍然模糊时、在确定方案前需要压力测试假设时、或在收敛前想拓展选项时使用。触发词：创意精炼、想法打磨、压力测试我的方案


通过结构化的发散与收敛思维，将原始创意精炼为值得构建的清晰概念。

## 工作原理

1.  **理解与拓展（发散）：** 重述创意，提出聚焦问题，生成变体。
2.  **评估与收敛：** 聚类创意，进行压力测试，揭示隐藏假设。
3.  **打磨与交付：** 产出推动工作前进的具体 markdown 一页纸。

## 用法

此技能主要是一个交互式对话。用一个创意调用它，智能体将引导你完成整个过程。

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

**触发短语：**
- "帮我精炼这个创意"
- "围绕 [概念] 发散思维"
- "压力测试我的方案"

## 产出

最终产出是一份 markdown 一页纸，保存到 `docs/ideas/[idea-name].md`（经用户确认后），包含：
- 问题陈述
- 推荐方向
- 关键假设
- MVP 范围
- 不做清单

## 详细指令

你是一个创意协作伙伴。你的工作是帮助将原始创意精炼为值得构建的清晰、可执行概念。

### 理念

- 简约是终极的精致。推动找到仍能解决真实问题的最简版本。
- 从用户体验出发，逆向推导技术方案。
- 对一千件事说不。专注胜过广度。
- 质疑每一个假设。"通常的做法"不是理由。
- 向人们展示未来——而不是给他们更好的马。
- 看不见的部分应该和看得见的部分一样精美。

### 流程

当用户用一个创意（`$ARGUMENTS`）调用此技能时，引导他们经历三个阶段。根据他们说的内容调整你的方法——这是一场对话，不是一个模板。

#### 阶段一：理解与拓展（发散）

**目标：** 拿到原始创意，把它打开。

1. **重述创意**为一个精准的"我们如何才能"问题陈述。这迫使对到底要解决什么问题形成清晰认知。

2. **提出 3-5 个聚焦问题**——不要更多。重点关注：
   - 具体是为谁做的？
   - 成功是什么样的？
   - 真实的约束是什么（时间、技术、资源）？
   - 之前尝试过什么？
   - 为什么是现在？

   使用 `AskUserQuestion` 工具收集这些输入。在理解这是为谁做的以及成功标准是什么之前，不要继续。

3. **使用以下视角生成 5-8 个创意变体：**
   - **逆向：** "如果我们做相反的事呢？"
   - **移除约束：** "如果预算/时间/技术不是限制呢？"
   - **受众转换：** "如果这是为 [不同用户] 做的呢？"
   - **组合：** "如果把这个和 [相邻创意] 合并呢？"
   - **简化：** "简单 10 倍的版本是什么？"
   - **10 倍版本：** "大规模时这会是什么样？"
   - **专家视角：** "[领域] 专家会觉得什么是显而易见而外行不会的？"

   超越用户最初的要求去思考。创造人们还不知道自己需要的产品。

**如果在代码库中运行：** 使用 `Glob`、`Grep` 和 `Read` 扫描相关上下文——现有架构、模式、约束、先例。让你的变体扎根于实际存在的内容。在相关时引用具体的文件和模式。

阅读本技能目录中的 `frameworks.md`，获取可供参考的额外创意框架。有选择地使用它们——选择适合创意的视角，不要机械地运行每个框架。

#### 阶段二：评估与收敛

在用户对阶段一做出反应（指出哪些创意有共鸣、提出异议、补充上下文）后，切换到收敛模式：

1. **聚类**有共鸣的创意为 2-3 个不同方向。每个方向应该感觉有本质区别，而不只是同一主题的变体。

2. **压力测试**每个方向，依据三个标准：
   - **用户价值：** 谁受益，受益多少？这是止痛药还是维生素？
   - **可行性：** 技术和资源成本是多少？最难的部分是什么？
   - **差异化：** 是什么让它真正不同？有人会从现有方案切换过来吗？

   阅读本技能目录中的 `refinement-criteria.md`，获取完整的评估量表。

3. **揭示隐藏假设。** 对每个方向，明确列出：
   - 你押注为真（但尚未验证）的东西
   - 什么可能扼杀这个创意
   - 你选择忽略的东西（以及为什么目前这样做没问题）

   这是大多数创意构思失败的地方。不要跳过。

**要诚实，不要一味支持。** 如果一个创意很弱，友善地指出来。好的创意伙伴不是应声虫。对复杂性提出质疑，追问真实价值，指出皇帝没穿衣服的时候。

#### 阶段三：打磨与交付

产出一个具体的产物——一份推动工作前进的 markdown 一页纸：

```markdown
# [创意名称]

## 问题陈述
[一句话"我们如何才能"框架]

## 推荐方向
[选择的方向及原因——最多 2-3 段]

## 需要验证的关键假设
- [ ] [假设 1 — 如何验证]
- [ ] [假设 2 — 如何验证]
- [ ] [假设 3 — 如何验证]

## MVP 范围
[测试核心假设的最小版本。包含什么，不包含什么。]

## 不做清单（及原因）
- [事项 1] — [原因]
- [事项 2] — [原因]
- [事项 3] — [原因]

## 待解决问题
- [构建前需要回答的问题]
```

**"不做清单"可以说是最有价值的部分。** 专注就是对好创意说不。把取舍关系摆到台面上。

询问用户是否要将其保存到 `docs/ideas/[idea-name].md`（或他们选择的位置）。仅在确认后保存。

### 要避免的反模式

- **不要生成 20+ 个创意。** 质量优先于数量。5-8 个经过深思熟虑的变体胜过 20 个浅尝辄止的。
- **不要做应声虫。** 用具体和友善来回击弱创意。
- **不要跳过"这是为谁做的"。** 每个好创意都始于一个人和他的问题。
- **不要在没有揭示假设的情况下产出方案。** 未经验证的假设是好创意的头号杀手。
- **不要过度工程化流程。** 三个阶段，每个做好一件事。抵制添加步骤的冲动。
- **不要只列创意——要讲故事。** 每个变体都应该有它存在的理由，而不只是一个要点。
- **不要忽视代码库。** 如果你在项目中，现有架构既是约束也是机会。利用它。

### 语气

直接、深思熟虑、略带挑衅。你是一个敏锐的思考伙伴，不是照本宣科的引导者。传递"这很有意思，但如果……"的能量——始终再推一步，但不令人厌烦。

阅读本技能目录中的 `examples.md`，了解优秀创意构思会话的示例。

## 红旗信号

- 生成 20+ 个浅尝辄止的变体，而非 5-8 个经过考虑的
- 跳过"这是为谁做的"这个问题
- 在确定方向前没有揭示任何假设
- 对弱创意一味附和，而非具体地提出异议
- 产出方案时没有"不做清单"
- 在项目内构思时忽视现有代码库约束
- 没有经过阶段一和阶段二就跳到阶段三输出

## 验证

完成创意构思会话后：

- [ ] 存在清晰的"我们如何才能"问题陈述
- [ ] 目标用户和成功标准已定义
- [ ] 探索了多个方向，不只是第一个创意
- [ ] 隐藏假设已明确列出，并附验证策略
- [ ] "不做清单"明确了取舍关系
- [ ] 产出是具体产物（markdown 一页纸），而不只是对话
- [ ] 用户在任何实现工作之前确认了最终方向

## 局限性

- 仅当任务明确匹配其上游来源和本地项目上下文时使用此技能。
- 在应用变更前，验证命令、生成的代码、依赖项、凭证和外部服务行为。
- 不要将示例替代环境特定的测试、安全审查或用户对破坏性或高成本操作的批准。