# Clarify Idea

> 将模糊想法、需求、产品请求、工具改造想法、内容计划、工作流改进，或“我不知道怎么讲清楚”的表达，整理成清晰、可执行、可验收的需求说明。 适用于用户要求“把想法讲清楚”、澄清需求、写轻量 PRD/spec、把模糊想法变成行动方案、减少返工、把需求讲给 AI/开发者/设计师/剪辑师/协作者听，或用户明确表示自己不会写代码、需要把想法变成别人能理解且自己能验收的内容。 典型触发：“把这个想法讲清楚”、“先别做，先澄清需求”、“帮我整理成 PRD”、“写成 AI 能执行的 spec”、“我不会写代码，帮我讲明白”、“把这段需求整理给开发/设计师看”。 不要用于：用户已经给出明确实现任务且要求直接执行、代码审查、纯文案润色、翻译、事实查询、无需澄清的单步命令，或用户明确要求不要提问/不要整理需求。

- Skill: `zhouzilai626/clarify-idea` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add zhouzilai626/clarify-idea`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zhouzilai626/clarify-idea/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: zhouzilai626 (https://skillmd.com/u/zhouzilai626)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zhouzilai626/clarify-idea

---


# 把想法讲清楚

## 核心假设

默认用户可能不会写代码，也不熟悉软件工程、产品经理、设计或开发术语。不要要求用户先给出技术方案。你的任务是把用户的自然语言表达转成：

1. 用户能确认的白话复述
2. 缺失信息和少量关键澄清问题
3. AI、开发者、设计师、剪辑师或协作者能执行的需求
4. 能减少返工的边界、风险和不做范围
5. 用户自己能亲自验证的验收清单

优先追求清楚、具体、可执行。不要为了显得正式而输出很重的 PRD，除非用户明确要求，或者任务复杂到确实需要。

## 使用边界

### 适合使用

- 用户只有一句含糊想法，希望先变清楚。
- 用户要把需求交给 AI、开发者、设计师、剪辑师或协作者。
- 用户想写轻量 PRD、可执行 Spec、验收清单或项目 brief。
- 用户担心“边做边改”造成返工，希望先明确边界和完成标准。
- 用户说自己不会写代码、不懂产品/设计/工程术语，但想把需求讲明白。

### 不适合使用

- 用户已经给出明确任务并要求立刻执行。
- 用户要的是代码审查、bug 修复、资料查询、翻译或普通润色。
- 用户明确说“不要提问”“不要整理需求”“直接给最终答案”。
- 输入已经是完整 PRD/spec，只需要格式排版或语言优化。

## 安全边界

- 不要把模糊想法直接当成执行授权；先整理、标注假设，再让用户确认。
- 不要替用户编造预算、平台、受众、时间线、技术方案或验收标准。
- 不要默认输出厚重 PRD；除非用户明确要求，先给短而可确认的澄清稿。
- 当需求涉及删除数据、自动发消息、付款、公开发布、隐私信息或账号权限时，必须单独列为风险和待确认项。
- 如果用户给出私人信息、账号、客户资料或商业敏感内容，只保留完成需求所需的抽象描述。

## 工作流程

### 1. 先复述想法

先用白话简短复述你理解到的用户想法，让用户能判断你有没有理解偏。

必要时使用这个句式：

```text
你现在想要的不是「某个功能」，而是在【场景】下完成【任务】，减少【痛点】，最后得到【理想结果】。
```

### 2. 提取六个字段

把用户的话整理成这六个字段：

```md
## 背景
为什么要做这件事？

## 场景
用户会在什么情况下使用它？

## 当前问题
哪里不顺、哪里重复、哪里不符合预期？

## 理想状态
做好以后应该是什么样？

## 约束条件
不会写代码、时间、预算、平台、工具、不能接受的结果等。

## 完成标准
用户如何判断它真的完成？
```

信息不足时标成 `待确认`，不要编造。如果某个字段会影响后续执行，但用户没说清楚，先写出“我的假设是”，再把它放进待确认问题。

### 3. 少问但问关键问题

最多问 3-5 个高价值问题，不要一次丢出很长问卷。

优先问会影响执行的问题：

- 谁会使用？
- 在什么具体场景下使用？
- 事情发生前、发生中、发生后分别应该怎样？
- 哪些设置、结果或状态需要被记住？
- 什么结果是用户不能接受的？
- 用户最后会怎么亲自验收？

如果上下文已经足够，就先基于合理假设继续整理，并明确标注“我的假设是”。

问问题时优先使用白话，不要用内部术语考用户。每个问题后面最好说明“为什么问这个”，但保持简短。

### 4. 选择输出深度

使用刚好够用的格式：

- **想法澄清稿**：适合早期想法、个人思路整理
- **轻量 PRD**：适合多个功能、多人协作、分阶段推进
- **可执行 Spec**：适合下一步要交给 AI、开发者或设计师执行

不确定时，默认先输出想法澄清稿，再说明可以继续升级成 PRD 或 Spec。

### 5. 留一个确认点

当用户的想法会进入实现、发布、群发、付费、删除、迁移、公开展示或影响真实用户时，在输出末尾加一个明确确认点：

```text
请先确认这版需求方向是否准确；确认后再进入执行/设计/开发。
```

如果只是个人想法整理或内容规划，不需要强制停手，但仍要给出下一步选择。

## 输出模板

### 想法澄清稿

默认使用这个：

```md
## 需求重述

## 背景与使用场景

## 当前问题

## 理想状态

## 可执行需求

## 不做什么

## 风险点

## 验收清单

## 下一步
```

### 轻量 PRD

当用户要求 PRD，或任务涉及多个功能、多个阶段、多人协作时使用：

```md
# 轻量 PRD

## 1. 背景

## 2. 目标用户

## 3. 使用场景

## 4. 问题与痛点

## 5. 目标体验

## 6. 功能需求

## 7. 非功能需求

## 8. 不做范围

## 9. 风险与依赖

## 10. 验收标准
```

### 可执行 Spec

当下一步要进入实现时使用：

```md
# 可执行 Spec

## 1. 目标

## 2. 状态与流程

## 3. 功能规则

## 4. 数据/设置保存

## 5. 边界情况

## 6. 错误与异常

## 7. 验收用例

## 8. 实施顺序
```

功能规则尽量写成：

```text
当【前提/状态】时，如果用户【动作】，系统应该【结果】。
```

验收用例可以使用 Given/When/Then：

```text
Given 已选择摄像头
When 用户关闭并重新打开工具
Then 摄像头设备、位置和大小应恢复为上一次设置
```

## 质量标准

输出前检查：

- 不懂代码的用户能不能看懂并确认？
- 另一个 AI 或协作者能不能不用猜就执行？
- 相关的“之前/过程中/之后/重启后/导出后”等状态是否覆盖？
- 验收清单是不是具体动作，而不是“功能正常”这种空话？
- 假设和未知信息有没有标清楚？
- 内容是不是足够短，用户真的愿意看？

## 常见失败模式

- **过早执行**：用户只是想澄清需求，却直接开始写代码、设计方案或发布内容。
- **问题太多**：一次抛出十几个问题，用户反而更不知道怎么回答。
- **替用户脑补**：把没有说过的平台、预算、目标用户、技术方案写成事实。
- **验收太虚**：写“功能正常”“体验良好”，却没有用户能亲自执行的检查动作。
- **格式过重**：早期想法也套完整 PRD，增加理解负担。
- **边界缺失**：没有写不做范围、不能接受的结果、风险和暂停点。

## 给不会写代码用户的特别规则

始终区分三类内容：

- **用户需要确认的事**：想要的行为、优先级、验收标准
- **用户不需要懂的事**：代码实现、库、内部架构、技术细节
- **用户需要亲自验收的事**：在自己的机器、内容或工作流里真实测试

对于软件或工具类需求，给出用户能执行的验收清单，例如：

```md
1. 打开工具
2. 完成关键配置
3. 执行核心操作
4. 生成结果
5. 关闭重开
6. 检查设置和结果是否符合预期
```

## 示例

### 工具改造

原始想法：

```text
这个录屏工具摄像头不好用，每次都要调。
```

澄清后：

```text
用户希望在 Windows 上录制带摄像头画面的教程视频。选择摄像头后，画面应立即显示，支持移动和缩放；开始录制后继续显示；导出成片中应包含且只包含一个摄像头画面；关闭重开后摄像头设备、位置、大小和麦克风选择保持上一次设置。
```

### 内容想法

原始想法：

```text
我想做一个 AI 工具账号。
```

澄清后：

```text
用户想做一个面向职场人的短视频账号，主题是 AI 工具提升日常工作效率。第一阶段目标不是做完整品牌，而是两周发布 6 条 60 秒以内视频，验证哪些选题带来更高收藏和评论。
```