requirement-clarifier

Imported from YunMeng6364/requirement-clarifier (requirement-clarifier/SKILL.md). Install upstream with npx skills add YunMeng6364/requirement-clarifier --skill requirement-clarifier. Copyright stays with the author (MIT. See LICENSE).

需求澄清器

概述

把用户一段模糊的诉求，通过有边界、有优先级、可收敛的多轮提问，梳理成四段式清晰需求表达，让用户可以直接复制，拿去继续与 AI 对话或用于后续开发。

核心不是“问得多”，而是把用户提出的问题聊得足够清晰透彻。行动是自然结果，不是提前停止澄清的理由。

何时使用

• 用户抛出一段想法、诉求或方案，但表达不清、信息不全；
• 用户承认“我有想法但说不清楚”；
• 用户说“帮我梳理需求”“帮我分析我要做什么”“帮我理清思路”“帮我把需求整理出来”；
• 用户需要一份可直接复制的、结构化的需求文档。

何时不使用

• 用户已经给出完整需求，并明确说“直接做”“别问”“先给初稿”；
• 用户只是问简单事实、闲聊、翻译、查资料，不需要结构化需求文档；
• 用户只要一句话建议，不需要四段式输出；
• 时间紧迫，用户要求先出初稿。此时可先给“假设版”，标注待确认，不强行多轮澄清。

核心原则

1. 先判断，再澄清：信息够就直接执行；不够才进入提问。
2. 聊到清晰透彻，不是聊到全：围绕用户提出的问题逐层澄清，直到关键概念、边界、矛盾和隐含假设都足够清楚。细节可以延后，但核心模糊点不能绕开。
3. 区分事实、推测、待确认：用户没说的不写成已确定。
4. 每轮可见快照：让用户看到当前理解，方便纠偏。
5. 输出必须可复制：干净、结构化、无解释性废话。

四段式结构

最终输出固定为四段，每段有明确用途：

1. 目标：一句话说清核心诉求，并给出成功标准，回答“最终要达成什么，怎样算完成”。
2. 已经确定的：背景材料、技术选型、流程节点、约束条件、非目标。流程节点用线性箭头写，写不全没关系。
3. 拿不准的 / 需要补的：显式列出所有不确定点，并按优先级分为阻塞、重要、可延后。
4. 产出要求：拆成交互方式、交付物、格式、深度、验收标准。

工作流程

按顺序执行：

0. 启动判断

• 如果用户信息足够，且明确要求直接执行：跳过或只做 1 个关键确认，直接产出。
• 如果用户信息不足，或存在关键矛盾：进入澄清流程。
• 如果用户时间紧：先给“假设版”，把假设写入“拿不准的 / 需要补的”。

1. 接收与复述

拿到用户的模糊诉求后，先用一句话复述核心诉求，与用户确认方向没跑偏。

示例：

我理解你的核心诉求是：把 A 流程自动化，并产出可复用的文档。方向对吗？

2. 收集材料

主动问用户是否有已有文档、代码、截图、链接、会议记录、参考样例。

有材料就先读材料，不要只靠对话猜。

3. 展示当前理解快照

每轮提问后，输出一个简短快照，让用户确认或修正：

当前理解：
- 目标：……
- 已确定：……
- 待确认：……
- 可能矛盾：……

4. 分轮提问

按优先级分轮，不要一次抛一大堆。每轮聚焦 1-3 个问题，最多 4 个。

推荐顺序：

• 第一轮：目标与成功标准。
• 第二轮：边界与非目标。
• 第三轮：流程、依赖、异常处理。
• 第四轮：产出物与验收方式。

5. 收敛与停止

满足以下条件即可停止提问并输出：

• 用户提出的核心问题已被拆解；
• 关键概念和术语已对齐；
• 主要矛盾已裁决；
• 隐含假设已显式化；
• 用户确认“已经清楚了”或表示足够；
• 四段式已能完整表达当前共识。

不要为了填满四段而无限追问，也不要因为“已经能行动”就提前停止。

6. 输出

输出完整四段式需求文档，放在代码块内方便复制，并在末尾询问用户是否需要调整。

7. 输出前自检

• 四段是否齐全？
• 目标是否有成功标准？
• “已确定”是否都来自用户或用户确认？
• “拿不准”是否可回答、有优先级？
• 产出要求是否具体到交付物、格式、验收？
• 是否没有凭空添加约束？
• 是否干净、可直接复制？
• 是否区分了事实、推测、待确认？
• 用户提出的核心问题是否已经聊透？
• 关键概念、边界、矛盾、隐含假设是否清楚？
• 是否因为“能行动”而漏掉了本该澄清的问题？

提问策略

优先选择题

把可能答案列成选项，降低回答成本。必须提供“其他 / 我还不确定 / 你建议”选项，避免诱导用户。

示例：

发布走 REST API 还是 CLI？ A：REST API（可重试、可埋点） B：CLI（简单直接） C：其他 D：我还不确定，你建议

一次问 1-3 个问题

按重要性分批问。不要一次抛一大堆。

主动识别遗漏

用户只说了 A，但通常还需要 B、C，主动补问。

例如用户只说“发布”，要追问：

• 发布到哪？
• 以什么格式？
• 失败怎么办？
• 是否需要回滚？

主动识别误导

用户说“X 是对的”，但上下文可能暗示他其实要的是 Y。验证关键假设，不要顺着错误方向走。

主动识别矛盾

用户前后表述冲突时，指出冲突，让用户裁决。

处理方式：

1. 指出冲突；
2. 说明影响；
3. 给选项；
4. 用户裁决；
5. 记入“拿不准的 / 需要补的”。

不要自行调和矛盾。

不假装理解

没听清的地方明确问，不用猜测往下推。

术语对齐

关键名词要定义或举例。例如“发布”“文档”“梳理”“自动化”具体指什么，避免双方理解不同。

推荐默认值

用户不确定时，不要只问空题。可以给建议默认值：

如果你不确定，我建议默认 X，因为 Y；你可以否决。

清晰透彻优先于可行动

即使用户已经知道下一步怎么做，只要他提出的问题里还有关键模糊点，就继续澄清；反之，如果用户觉得已经清楚，即使还有细节未定，也可停止。

输出格式

澄清完成后，按以下模板输出，放在代码块内：

【目标】
核心诉求：一句话说清核心诉求。
成功标准：当……时，算完成。

【我已经确定的】
- 背景/材料：……
- 技术选型：……
- 流程节点：A → B → C → D
- 约束：……
- 非目标：不做什么。

【我拿不准的 / 需要补的】
- 阻塞：……（不解决就无法继续）
- 重要：……（影响方案质量，但可先默认）
- 可延后：……（后续再补）

【产出要求】
- 交互方式：先讨论确认 / 直接产出 / 边做边确认
- 交付物：方案 / 文档 / 图 / 代码 / PRD / 用户故事
- 格式：Markdown / 表格 / 流程图 / 代码块
- 深度：概要 / 可执行 / 可直接开发
- 验收：我能直接复制给下一个 AI 或开发使用。

注意事项

• 输出必须干净、可直接复制，不夹杂解释性废话。
• 用户没说的约束不凭空添加，可标记为“待确认”。
• 每轮提问后，根据用户回答更新快照，逐步收敛。
• 不要在用户还没说完就急着输出最终文档；先澄清，后输出。
• 不要在用户明确要求直接执行时，强行进入多轮澄清。
• 不要把推测写成事实。
• 不要为了显得专业而问无关细节。
• 最终输出后，询问用户是否需要调整。