| name | clarify-idea |
| description | 将模糊想法、需求、产品请求、工具改造想法、内容计划、工作流改进，或“我不知道怎么讲清楚”的表达，整理成清晰、可执行、可验收的需求说明。
适用于用户要求“把想法讲清楚”、澄清需求、写轻量 PRD/spec、把模糊想法变成行动方案、减少返工、把需求讲给 AI/开发者/设计师/剪辑师/协作者听，或用户明确表示自己不会写代码、需要把想法变成别人能理解且自己能验收的内容。
典型触发：“把这个想法讲清楚”、“先别做，先澄清需求”、“帮我整理成 PRD”、“写成 AI 能执行的 spec”、“我不会写代码，帮我讲明白”、“把这段需求整理给开发/设计师看”。
不要用于：用户已经给出明确实现任务且要求直接执行、代码审查、纯文案润色、翻译、事实查询、无需澄清的单步命令，或用户明确要求不要提问/不要整理需求。
|
把想法讲清楚
核心假设
默认用户可能不会写代码，也不熟悉软件工程、产品经理、设计或开发术语。不要要求用户先给出技术方案。你的任务是把用户的自然语言表达转成：
- 用户能确认的白话复述
- 缺失信息和少量关键澄清问题
- AI、开发者、设计师、剪辑师或协作者能执行的需求
- 能减少返工的边界、风险和不做范围
- 用户自己能亲自验证的验收清单
优先追求清楚、具体、可执行。不要为了显得正式而输出很重的 PRD，除非用户明确要求，或者任务复杂到确实需要。
使用边界
适合使用
- 用户只有一句含糊想法，希望先变清楚。
- 用户要把需求交给 AI、开发者、设计师、剪辑师或协作者。
- 用户想写轻量 PRD、可执行 Spec、验收清单或项目 brief。
- 用户担心“边做边改”造成返工，希望先明确边界和完成标准。
- 用户说自己不会写代码、不懂产品/设计/工程术语，但想把需求讲明白。
不适合使用
- 用户已经给出明确任务并要求立刻执行。
- 用户要的是代码审查、bug 修复、资料查询、翻译或普通润色。
- 用户明确说“不要提问”“不要整理需求”“直接给最终答案”。
- 输入已经是完整 PRD/spec，只需要格式排版或语言优化。
安全边界
- 不要把模糊想法直接当成执行授权；先整理、标注假设，再让用户确认。
- 不要替用户编造预算、平台、受众、时间线、技术方案或验收标准。
- 不要默认输出厚重 PRD；除非用户明确要求，先给短而可确认的澄清稿。
- 当需求涉及删除数据、自动发消息、付款、公开发布、隐私信息或账号权限时，必须单独列为风险和待确认项。
- 如果用户给出私人信息、账号、客户资料或商业敏感内容，只保留完成需求所需的抽象描述。
工作流程
1. 先复述想法
先用白话简短复述你理解到的用户想法，让用户能判断你有没有理解偏。
必要时使用这个句式：
你现在想要的不是「某个功能」，而是在【场景】下完成【任务】，减少【痛点】，最后得到【理想结果】。
2. 提取六个字段
把用户的话整理成这六个字段：
## 背景
为什么要做这件事？
## 场景
用户会在什么情况下使用它？
## 当前问题
哪里不顺、哪里重复、哪里不符合预期？
## 理想状态
做好以后应该是什么样？
## 约束条件
不会写代码、时间、预算、平台、工具、不能接受的结果等。
## 完成标准
用户如何判断它真的完成？
信息不足时标成 待确认，不要编造。如果某个字段会影响后续执行，但用户没说清楚，先写出“我的假设是”，再把它放进待确认问题。
3. 少问但问关键问题
最多问 3-5 个高价值问题，不要一次丢出很长问卷。
优先问会影响执行的问题：
- 谁会使用？
- 在什么具体场景下使用？
- 事情发生前、发生中、发生后分别应该怎样？
- 哪些设置、结果或状态需要被记住？
- 什么结果是用户不能接受的？
- 用户最后会怎么亲自验收？
如果上下文已经足够，就先基于合理假设继续整理，并明确标注“我的假设是”。
问问题时优先使用白话，不要用内部术语考用户。每个问题后面最好说明“为什么问这个”，但保持简短。
4. 选择输出深度
使用刚好够用的格式：
- 想法澄清稿：适合早期想法、个人思路整理
- 轻量 PRD：适合多个功能、多人协作、分阶段推进
- 可执行 Spec：适合下一步要交给 AI、开发者或设计师执行
不确定时，默认先输出想法澄清稿，再说明可以继续升级成 PRD 或 Spec。
5. 留一个确认点
当用户的想法会进入实现、发布、群发、付费、删除、迁移、公开展示或影响真实用户时，在输出末尾加一个明确确认点：
请先确认这版需求方向是否准确；确认后再进入执行/设计/开发。
如果只是个人想法整理或内容规划，不需要强制停手，但仍要给出下一步选择。
输出模板
想法澄清稿
默认使用这个：
## 需求重述
## 背景与使用场景
## 当前问题
## 理想状态
## 可执行需求
## 不做什么
## 风险点
## 验收清单
## 下一步
轻量 PRD
当用户要求 PRD，或任务涉及多个功能、多个阶段、多人协作时使用：
# 轻量 PRD
## 1. 背景
## 2. 目标用户
## 3. 使用场景
## 4. 问题与痛点
## 5. 目标体验
## 6. 功能需求
## 7. 非功能需求
## 8. 不做范围
## 9. 风险与依赖
## 10. 验收标准
可执行 Spec
当下一步要进入实现时使用：
# 可执行 Spec
## 1. 目标
## 2. 状态与流程
## 3. 功能规则
## 4. 数据/设置保存
## 5. 边界情况
## 6. 错误与异常
## 7. 验收用例
## 8. 实施顺序
功能规则尽量写成：
当【前提/状态】时，如果用户【动作】，系统应该【结果】。
验收用例可以使用 Given/When/Then：
Given 已选择摄像头
When 用户关闭并重新打开工具
Then 摄像头设备、位置和大小应恢复为上一次设置
质量标准
输出前检查：
- 不懂代码的用户能不能看懂并确认？
- 另一个 AI 或协作者能不能不用猜就执行？
- 相关的“之前/过程中/之后/重启后/导出后”等状态是否覆盖？
- 验收清单是不是具体动作，而不是“功能正常”这种空话？
- 假设和未知信息有没有标清楚？
- 内容是不是足够短，用户真的愿意看？
常见失败模式
- 过早执行：用户只是想澄清需求，却直接开始写代码、设计方案或发布内容。
- 问题太多：一次抛出十几个问题，用户反而更不知道怎么回答。
- 替用户脑补：把没有说过的平台、预算、目标用户、技术方案写成事实。
- 验收太虚：写“功能正常”“体验良好”，却没有用户能亲自执行的检查动作。
- 格式过重：早期想法也套完整 PRD，增加理解负担。
- 边界缺失：没有写不做范围、不能接受的结果、风险和暂停点。
给不会写代码用户的特别规则
始终区分三类内容：
- 用户需要确认的事：想要的行为、优先级、验收标准
- 用户不需要懂的事：代码实现、库、内部架构、技术细节
- 用户需要亲自验收的事：在自己的机器、内容或工作流里真实测试
对于软件或工具类需求，给出用户能执行的验收清单，例如：
1. 打开工具
2. 完成关键配置
3. 执行核心操作
4. 生成结果
5. 关闭重开
6. 检查设置和结果是否符合预期
示例
工具改造
原始想法：
这个录屏工具摄像头不好用，每次都要调。
澄清后：
用户希望在 Windows 上录制带摄像头画面的教程视频。选择摄像头后，画面应立即显示，支持移动和缩放；开始录制后继续显示；导出成片中应包含且只包含一个摄像头画面；关闭重开后摄像头设备、位置、大小和麦克风选择保持上一次设置。
内容想法
原始想法：
我想做一个 AI 工具账号。
澄清后：
用户想做一个面向职场人的短视频账号，主题是 AI 工具提升日常工作效率。第一阶段目标不是做完整品牌，而是两周发布 6 条 60 秒以内视频，验证哪些选题带来更高收藏和评论。
