requirement-clarification（需求澄清技能）Skill 是什么？规划前怎么用？

需求澄清技能：让 AI 在动手前先把模糊需求问清楚

• 一句话定位：在「研究已完成、规划尚未开始」的间隙里，把模糊的用户请求转成清晰、可实施、可验证的需求文档。
• 核心机制：内置范围澄清、技术决策、约束三类问题模板，加上五条问题质量检查清单与三级优先级，把提问这件事标准化。
• 关键设计：阻碍性问题最多 10 个，且每个问题都必须附带默认值——用户不回答也能继续推进，不制造“问卷地狱”。
• 可验证：提供 scripts/validate-requirements.py 校验脚本，检查阻碍性问题是否已回答、需求是否自相矛盾、技术可行性是否确认。
• 产物可沉淀：问题与需求分别落到 docs/specs/ 下的 Markdown 文件，成为团队可追溯的资产，而不是聊天记录里的一段对话。

1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？

这个技能的中文名是需求澄清技能Skill，英文名是 requirement-clarification，技能 ID 为 11833。

它解决的问题非常具体：当你对 AI 说“帮我加个导出功能”“做一个数据看板”这类请求时，AI 往往会立刻开始写代码或给方案，结果做出来的东西和真实期望差一大截。这个技能把“先问清楚再动手”变成了一个标准化环节——它的官方描述就写明：必须（MUST）在规划阶段前使用，在技术工作开始前验证需求是否完整且明确。

「一键安装」的思路与步骤：

1. 确认安装前提：你的 AI 开发环境需要支持 Skill（技能）机制，并具备可读写项目目录的能力；由于该技能的验证环节依赖 Python 脚本，环境中还需要可用的 Python 运行时。具体支持的环境清单以官方说明为准。
2. 获取并安装：在技能市场或技能库中按英文名 requirement-clarification 或技能 ID 11833 检索，通过官方提供的安装入口一键添加；具体命令与入口地址以官方说明为准。
3. 确认目录结构完整：安装后应能看到技能主体说明文件、question-templates/ 下的三类问题模板（scope-questions、technical-questions、constraint-questions）、scripts/validate-requirements.py 校验脚本。
4. 验证是否生效：向 AI 抛出一个刻意模糊的需求（例如“给系统加个导出功能”），如果它没有直接动手，而是先输出一批结构化澄清问题，并把问题写入 docs/specs/questions-{session}.md，就说明技能已正确加载。

相比“每次手动提醒 AI 先问我几个问题”，一键安装的价值在于把这条规则固化进了工作流——不依赖你的记性，也不依赖当次对话的运气。

2. 该技能的主要功能和特点

• 从研究结果生成问题：它不是凭空发问，而是基于研究阶段在 docs/research/ 中产出的发现来生成澄清问题，保证提问有上下文、有依据。
• 三类问题模板覆盖三大盲区：范围澄清（“某功能是否也应处理某个边缘情况？”“当某条件成立时应该发生什么？”）、技术决策（“对于某目的，你更倾向 A 还是 B？”“这需要与现有系统集成吗？”“需要什么级别的性能/安全性？”）、约束确认（“有截止日期吗？”“有技术或方法上的限制吗？”“谁将使用这个功能？”）。
• 五条问题质量检查清单：每个问题必须具体、可回答（用户手里确实有答案）、有影响（答案会改变实施方式）、非技术性（用易懂语言表述）、可默认（有回退假设）。这一条直击“AI 提问让人不想回答”的痛点。
• 三级优先级与硬性上限：必须回答（阻碍）的问题最多 10 个，且始终提供默认值；应该回答（重要）的问题不答也能用默认值继续；可以回答（锦上添花）的问题仅用于优化。
• 可执行的需求校验：运行 python scripts/validate-requirements.py <session-id> 即可检查阻碍性问题是否全部回答、需求之间是否矛盾、技术可行性是否确认，并确认已分配置信度级别。
• 产物双份落地：问题输出到 docs/specs/questions-{session}.md，需求输出到 docs/specs/requirements-{session}.md，形成可评审、可归档的文档。

和普通工具相比强在哪？普通 AI 对话也能“追问”，但问题质量参差、数量失控、没有默认值兜底、也不会留下结构化产物；需求管理工具能存文档，但不会帮你“生成该问什么”。这个技能恰好卡在两者之间，补的是“从模糊到清晰”的那一段。

3. 如何使用该技能？

第一步：先完成研究阶段。 确保 docs/research/ 下已有对当前任务的调研发现，这是技能生成问题的原料。

第二步：触发技能。 在需求尚不明确时明确要求使用需求澄清技能，例如：“请用需求澄清技能处理这个请求：给后台加一个数据导出功能。”触发方式可以是显式点名技能，也可以由环境在检测到非技术性、模糊请求时自动启用，具体以官方说明为准。

第三步：阅读生成的问题清单。 技能会按优先级分组输出问题，且每个阻碍性问题都带默认值。示意：

必须回答（阻碍）

1. 导出功能是否需要支持超过 10 万行的数据量？默认假设：单次导出上限 5 万行。
2. 导出的文件格式是 CSV 还是 Excel？默认假设：CSV。 应该回答（重要）
3. 导出操作是否需要记录操作日志？默认假设：记录。

第四步：逐条回答，或直接采纳默认值。 对不关心的条目回复“用默认值”即可，避免流程卡死。

第五步：运行校验脚本。 执行 python scripts/validate-requirements.py <session-id>，确认没有未回答的阻碍性问题、没有互相矛盾的需求、技术可行性已确认。

第六步：确认输出并进入规划。 检查 docs/specs/requirements-{session}.md 是否符合预期，之后才允许规划阶段开始。整个过程与官方描述的五步工作流一致：研究产出发现 → 技能生成问题 → 用户回答 → 生成已验证的需求文档 → 规划阶段开始。

4. 同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
需求澄清技能（requirement-clarification）	工作流中的需求澄清环节	三类问题模板、五条质量清单、三级优先级、校验脚本、双份文档输出	需支持 Skill 的环境与 Python 运行时，一键安装	AI 辅助开发、非技术用户提需求、规划前把关	优势：提问标准化、有默认值兜底、产物可追溯；不足：依赖前置研究产出，纯手工项目需自行补齐目录结构
直接与通用 AI 对话追问	通用对话助手	可自由追问、灵活	零门槛	灵感发散、快速确认单点问题	优势：无学习成本；不足：问题质量不稳定、数量易失控、无默认值、不留结构化文档
传统 PRD / 需求模板	文档规范	提供固定章节模板（背景、目标、验收标准等）	需人工填写，依赖经验	正式立项、跨部门评审	优势：格式统一、便于评审；不足：不会主动发现盲区，靠人想
用户故事 + 验收标准（Given-When-Then）	敏捷需求表达	用“作为…我想要…以便…”描述需求并附验收条件	需团队共识与培训	迭代开发、任务拆分	优势：贴近开发落地；不足：仍以人工撰写为主，澄清过程本身未被工具化

可以看出，这个技能的差异化不在“能不能提问”，而在“提问是否可控、可校验、可留痕”。

5. 该技能的典型应用场景与实际体验情况

场景一：非技术背景的产品/运营同学提需求。 痛点是“我想要个数据看板”这类表达无法直接开发。技能会把“非技术性”写进问题质量清单，用业务语言反问“看板给谁看”“多久刷新一次”“数据不对时以哪个系统为准”，用户答得出来，开发也看得懂。

场景二：开发接手一张模糊工单。 后端同学拿到“优化一下导出性能”的任务，技能会从约束维度发问“有截止日期吗”“有技术方案限制吗”“谁将使用这个功能”，避免做完才发现用错了方向。

场景三：AI 辅助编码（Vibe Coding）流程。 使用 AI 生成代码时，最大的浪费是“做错方向”。把该技能固定插在研究与规划之间，等同于给 AI 加了一道需求闸门。

实际体验情况： 上手难度低，只要记住“规划前先触发”即可；问题质量明显高于随手追问，因为五条检查清单会过滤掉含糊、无影响、技术味太重的问题；三级优先级设计让流程不至于无限拉长。注意事项：一是阻碍性问题虽有上限，但仍可能出现 6~10 个，需要预留回答时间；二是默认值必须显式确认，否则可能把假设当结论；三是如果研究阶段产出为空，问题会偏向泛泛而谈，建议先补研究。

6. 该技能能为用户带来的价值

提升效率：把需求澄清从“开会吵两小时”或“来回十几轮消息”压缩成一次结构化问答，阻碍性问题控制在 10 个以内，并且每个都有默认值，不回答也能推进。

降低门槛：五条质量清单中的“非技术性”要求，让不懂代码的业务方也能顺畅参与需求确认，减少“翻译损耗”。

减少返工：校验脚本会检查需求是否互相矛盾、技术可行性是否确认，把冲突提前暴露在规划之前，而不是在开发中后期才发现。

长期价值：问题与需求分别沉淀为 docs/specs/ 下的 Markdown 文件，按 session 归档，团队交接、需求复盘、责任追溯都有据可依；同时它把“先问清楚再动手”固化为流程纪律，这种一致性收益会随着项目数量累积而放大。

7. 常见问题 FAQ

Q1：这个技能怎么安装？ 在技能库中按英文名 requirement-clarification 或技能 ID 11833 检索，通过官方安装入口一键添加即可；前提是所处环境支持 Skill 机制并能读写项目目录，验证脚本还需要 Python 运行时。具体命令与入口以官方说明为准。

Q2：使用它需要付费吗？ 该技能本身在官方说明中未标注定价信息，是否收费取决于你获取技能的平台与所处套餐，请以官方说明为准。

Q3：什么时候必须用它？ 官方定位是“研究阶段完成后、规划阶段开始前”，且标注为必须使用。此外，当用户需求不明确，或提出请求的是非技术用户时，也建议启用。

Q4：用户不愿意一条条回答问题怎么办？ 这正是三级优先级设计的用意：只有“必须回答”的问题会阻碍流程，且每个问题都带默认值；你可以直接回复“全部用默认值”，技能会按回退假设继续生成需求文档，之后随时可修正。

Q5：它和直接让 AI 多问我几个问题有什么区别？ 区别在于标准化与可校验：它有固定模板、五条质量清单、阻碍性问题不超过 10 个的硬约束、校验脚本，以及落到 docs/specs/ 的结构化产物；随手追问则完全依赖当次对话的运气。