需求澄清技能：把一句“加个登录功能”自动变成可直接开发的 PRD
核心结论速览
- 它解决什么：开发中最贵的返工往往不是写代码，而是“没想清楚就开写”。需求澄清技能（requirements-clarity）在动手前先做这件事——把模糊的一句话需求，通过聚焦对话逐轮问清，最终产出结构化 PRD。
- 它怎么做到：用 0-100 分清晰度评分系统量化“到底想清楚了没有”，并结合两个核心提问原则——YAGNI（为什么做？不做行不行）和 KISS（有没有更简单的做法）。
- 它输出什么：当清晰度 ≥ 90 分时，自动生成完整 PRD 文档，落地到
./docs/prds/{功能名称}-v{版本}-prd.md，含验收标准与分阶段执行计划。 - 它什么时候不该用：需求已经明确到文件路径、代码片段、清晰复现步骤的 bug 修复，它不会启动，避免“为澄清而澄清”。
- 谁最该用：产品经理、技术负责人、独立开发者，以及被“跨团队协作 + 复杂功能（>2 天工作量）”反复折磨的团队。
1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？
技能基本信息
| 项目 | 内容 |
|---|---|
| 中文名 | 需求澄清技能Skill |
| 英文名 | requirements-clarity |
| 技能 ID | 12017 |
| 技能形态 | AI 技能（Skill），通过对话式交互驱动 |
| 核心用途 | 在实施前澄清模糊需求，自动产出可执行 PRD |
它到底解决什么问题？
几乎所有技术团队都经历过这个场景：有人说“加个登录功能”，然后开发问“用什么方式登录”，回答“你看着办”；开发又问“要支持第三方登录吗”，回答“先简单做”；等做完交付，对方说“我要的是手机号验证码登录，不是账号密码”。需求澄清技能针对的正是这一类信息缺失型需求——它会在编码开始前，系统化地把“没说清楚的部分”一层层问出来，并用分数告诉你距离“可以开工”还有多远。
它重点识别四类模糊信号：
- 模糊功能请求：如“添加登录功能”“实现支付”“创建仪表板”，缺少技术方案与约束信息；
- 缺失技术上下文：未提及技术栈、未识别集成点、未说明性能或安全要求；
- 不完整规范：没有验收标准、没有成功指标、未考虑边缘情况与错误处理；
- 模糊范围：功能边界不清（“用户管理”具体包含哪些？）、未区分 MVP 与后续增强、没说明“不包括什么”。
为什么叫“一键安装式提效”？
传统提高需求质量的路径是开会、写模板、反复评审，成本高、依赖人。AI 技能的思路完全不同：把一套成熟的需求澄清方法论（评分模型、提问策略、PRD 结构）固化成一个可复用的技能包，装进你的 AI 编程助手或智能体平台，之后每次需求进来都可以“一键唤起”，让 AI 按固定流程陪你问完、写完。
安装与启用的一般步骤（具体命令、目录与入口以官方说明为准）：
- 确认前提：你使用的 AI 开发助手/智能体平台支持技能（Skill）机制；当前项目目录具备写权限，因为技能最终会在项目中生成
./docs/prds/目录及 PRD 文件。 - 获取技能：从官方提供的技能市场、技能库或技能包分发入口获取 requirements-clarity 技能（安装源与获取方式以官方说明为准）。
- 安装并启用：按平台惯例将技能安装到工作区的技能目录中，并在会话/项目设置里启用该技能（具体路径与开启方式以官方说明为准）。
- 验证是否生效：新建一次对话，输入一句故意模糊的需求，例如“帮我加个支付功能”。如果技能已正确加载，它会返回“我理解您的需求。让我帮您细化这个规范”，并给出一个 0-100 的当前清晰度分数、已清晰的点与待澄清的差距清单，随后提出 2-3 个聚焦问题——出现这个“评分 + 提问”的模式，说明技能已生效。
- 反向验证：再输入一条带具体文件路径或代码片段的诉求（如“修复 auth.go 里的空指针”），技能应当不进入澄清模式，这同样说明它的触发边界判断正常。
2. 该技能的主要功能和特点
- 模糊需求自动识别：能判断当前输入属于“模糊功能请求 / 缺技术上下文 / 规范不完整 / 范围模糊”中的哪一类，并据此决定是否启动澄清流程。
- 0-100 分清晰度量化评分：把“需求清不清楚”这种主观判断变成可追踪的数字。评分体系四维度明确：
- 功能清晰度 30 分（输入输出 10 / 用户交互 10 / 成功标准 10）
- 技术具体性 25 分（技术栈 8 / 集成点 8 / 约束 9）
- 实施完整性 25 分（边缘情况 8 / 错误处理 9 / 数据验证 8）
- 业务上下文 20 分（问题陈述 7 / 目标用户 7 / 成功指标 6）
- 节制的提问节奏：每轮只问 2-3 个问题、只聚焦一个类别，基于上一轮答案继续追问，不会一次性抛出一屏问题把人劝退。
- 两个核心拷问：为什么？（YAGNI 检查——这个功能真的需要做吗？不做会怎样？）与更简单？（KISS 检查——有没有成本更低的实现路径？），在最容易浪费资源的地方先拦住。
- 分数驱动迭代：每轮回答后更新分数（如 62/100 → 78/100 → 92/100），并列出“新澄清内容”与“剩余澄清点”，直到 ≥ 90 分才允许进入文档生成阶段。
- 拒绝提前收工：在未达 90 分前不会生成 PRD，避免产出一份“看起来很正式但关键信息全是空白”的文档。
- 结构化 PRD 自动生成：输出包含需求描述、设计决策、验收标准、四阶段执行计划（准备 / 核心开发 / 集成与测试 / 部署）的完整文档，验收标准采用
- [ ]可勾选格式，可直接进入开发交接。 - 过程可追溯：PRD 中会记录文档版本号（默认 1.0）、创建时间、澄清轮次与最终质量分数，方便事后复盘“这个需求当时是怎么定下来的”。
- 明确的非激活边界：提到具体文件路径、包含代码片段、引用现有函数/类、或具备清晰复现步骤的 bug 修复，这些场景下技能不启动，避免过度流程化。
和普通工具比强在哪？ 普通需求文档模板只提供“填空格”，填不填、填得对不对没人管；通用 AI 对话能一次生成一份 PRD，但很容易在你没提供信息的地方自行编造。需求澄清技能的差异在于：它把“不许假设、不许提前产出、必须问到达标”写进了流程本身。
3. 如何使用该技能？
步骤 1：抛出你的原始需求（可以很粗糙）
直接说人话即可，例如：
帮我加个支付功能。
步骤 2：接收初始评估
技能会先解析需求、生成 kebab-case 格式的功能名称、确定文档版本（默认 1.0）、确保 ./docs/prds/ 目录存在，然后给出初始清晰度评估。示意输出如下：
我理解您的需求。让我帮您细化这个规范。
**当前清晰度分数**：34/100
**清晰方面**：
- 明确了要做“支付”这一功能方向
**需要澄清**：
- 支付渠道、金额范围、是否需要退款
- 技术栈与集成点未提及
- 无验收标准与失败场景处理
让我系统化澄清这些点...
步骤 3：按轮次回答问题
技能会围绕四个维度（功能范围、用户交互、技术约束、业务价值）逐轮提问，每轮 2-3 个：
1. **[业务价值]**：这个支付功能要解决的具体业务问题是什么？如果本期不做，会损失什么？
- 例如：是为了支持线上课程售卖，还是为了替代现有的人工转账流程？
2. **[功能范围]**：本期需要支持哪些支付渠道？哪些明确不在本期范围内？
3. **[技术约束]**：现有系统使用什么技术栈？支付回调需要对接哪些已有服务？
步骤 4：观察分数更新
每一轮回答后，你会看到类似反馈：
感谢额外信息！
**清晰度分数更新**：34/100 → 61/100
**新澄清内容**：
- 支付渠道：微信支付 + 支付宝，暂不做海外
- 技术栈：现有后端为 Go 服务，已有订单模块
**剩余澄清点**：
- 退款与对账是否在本期范围内
- 支付失败的降级与重试策略
步骤 5：达标后自动生成 PRD
当分数达到 90 分及以上，技能会提示“完美！我现在将生成完整的 PRD 文档…”，并把文件写入：
./docs/prds/{功能名称}-v{版本}-prd.md
例如 ./docs/prds/payment-integration-v1.0-prd.md。
步骤 6：评审与交接
打开生成的 PRD，重点看三块：功能边界（包括什么、不包括什么）、验收标准清单、四阶段执行计划中的任务与交付物。确认无误后即可进入开发排期；若有偏差，继续对话补充，技能会更新分数与文档内容。
小提示：如果你只想先摸底，可以说“先帮我列出这个需求还缺哪些信息，不用生成文档”，这样可以在不动文件的情况下拿到差距清单。
4. 同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 需求澄清技能（requirements-clarity） | 面向 AI 助手的“需求澄清 + PRD 生成”技能 | 模糊需求识别、0-100 分评分、分轮提问、PRD 自动落盘、四阶段执行计划 | 需在支持技能机制的 AI 平台安装，项目目录需可写；具体安装方式以官方说明为准 | 复杂功能（>2 天）、跨团队协作、需求方表达模糊 | 优势：流程固化、有量化标尺、拒绝提前产出；不足：依赖人工逐轮回答，简单需求会显得“啰嗦” |
| 传统需求评审会 + PRD 模板 | 人工流程 + 文档模板 | 模板填空、会议对齐、人工评审 | 门槛低，但需要组织会议与资深评审人 | 中大型项目、需要多方签字确认的需求 | 优势：组织权威性强、可追责；不足：耗人力、质量强依赖评审人经验、无量化标准 |
| 通用大模型直接生成 PRD | 一次性文档生成 | 根据一段描述直接输出 PRD 文本 | 极低，打开对话框即可 | 快速起草初稿、脑子里已有完整方案 | 优势：快；不足：缺信息时容易自行编造假设，产出“看着完整实则空洞”，缺乏澄清与校验闭环 |
| 需求管理工具（如 Jira、禅道类）内置 AI 能力 | 需求登记与流转平台 | 工单管理、字段校验、进度追踪 | 需团队整体迁移到该工具 | 已有成熟研发流程的团队做需求登记 | 优势：与研发流程深度绑定、可统计；不足：偏“记录与流转”，不擅长主动追问与澄清，澄清动作仍靠人 |
从对比可以看出，需求澄清技能的差异化位置很明确：它不是替代需求管理工具，而是在需求进入工单系统之前，先把“话说明白”这一步做扎实。
5. 该技能的典型应用场景与实际体验情况
场景一：产品经理只有一句需求标题
- 角色与痛点：产品经理收到老板一句“做一个数据看板”，自己也没想清楚要展示哪些指标、给谁看、多久刷新一次。
- 使用方式：把这句话丢给技能，按它的四维度提问依次回答——业务问题是什么、目标用户是谁、成功指标怎么定、性能和权限有什么约束。
- 实际体验：上手几乎零成本，因为问题本身足够具体（“这个看板如果只有 3 个指标，你会选哪 3 个？”），回答起来比面对空白文档轻松得多。注意事项：回答尽量给具体数字或范围，回答“你看着办”会让分数停滞。
场景二：技术负责人做跨团队需求拆解
- 角色与痛点：一个涉及支付、订单、风控三个团队的功能，边界不清导致每个团队都以为别人在做。
- 使用方式：用技能强制产出“功能边界：包括什么 / 不包括什么”，以及分阶段执行计划与交付物清单。
- 实际体验：价值最大的部分不是 PRD 正文，而是那句“什么不在本期范围内”——它把跨团队扯皮最常见的模糊地带提前钉死。注意事项：跨团队场景下仍需人工确认各方对边界的认可，技能负责提出、不负责拍板。
场景三：独立开发者给自己做减法
- 角色与痛点：一个人做产品，最容易功能越加越多，两个月做不完一个 MVP。
- 使用方式：借助技能内置的 YAGNI（为什么做？不做行不行）与 KISS（有没有更简单的做法）两问，主动砍掉边缘功能。
- 实际体验：这两个问题看起来像“废话”，但真正被追问“如果去掉这个功能，会损失哪一类用户”时，很多想当然的需求会立刻站不住。这是该技能对个人开发者最“反直觉但实用”的地方。
场景四：需求已明确的 bug 修复
- 角色与痛点：开发只想赶紧修 bug，不想再走一轮澄清流程。
- 使用方式：直接给出文件路径、报错片段与复现步骤。
- 实际体验：技能按设计不会激活，不会打断修 bug 节奏。这提醒使用者：把“问题定位型任务”和“需求定义型任务”分开表达，效果最好。
6. 该技能能为用户带来的价值
- 把返工成本前置消化：需求阶段的模糊，最终都会以“做完再改”的形式变成开发工时。技能用评分机制把“还差多少信息”显性化，让问题在写第一行代码之前暴露。
- 降低需求表达门槛：需求方不需要懂 PRD 怎么写，只需要回答“给谁看”“成功怎么衡量”“不做会损失什么”这类日常问题，文档结构由技能负责补齐。
- 让“想清楚”变成可验收的动作：90 分阈值是一个客观的开工闸门，团队可以用“清晰度是否达标”替代“感觉差不多了”这种主观判断。
- 沉淀可复用的团队资产：每份 PRD 都记录版本、澄清轮次与质量分数，长期积累下来就是一套带决策上下文的项目档案，新人接手时不必再从群聊记录里考古。
- 减少无效功能开发：YAGNI 与 KISS 两问的持续施加，能系统性地过滤掉“做了也没人用”的功能，直接节省开发与后续维护成本。
- 长期价值在于习惯：用上几次之后，很多人在提需求前就会自己先想清楚边界与指标——这是这类工具最理想的溢出效应。
7. 常见问题 FAQ
Q1：这个技能怎么安装？装完怎么确认生效？
需要在支持技能（Skill）机制的 AI 开发助手或智能体平台中安装并启用该技能，具体安装源、目录路径与启用入口以官方说明为准。验证方法很简单：输入一句模糊需求（如“加个登录功能”），如果它返回“当前清晰度分数 X/100”并列出待澄清差距、连续追问 2-3 个问题，说明已生效。反之，输入带文件路径的具体修复诉求时它不启动，也属正常设计。
Q2：这个技能收费吗？
技能本身的定价、是否需要订阅或额度，取决于你获取它的平台与分发渠道，本处无法确认，请以官方说明为准。可以明确的是：它的运行依赖你所使用的 AI 助手/模型的调用额度，这部分成本由对应平台规则决定。
Q3：它和直接让 AI 写一份 PRD 有什么区别？
最大的区别是“不假设”和“不提前交付”。通用对话往往在你信息不全时自行脑补，产出一份看起来完整、实则关键项空白的文档；需求澄清技能在清晰度未达 90 分前明确不生成 PRD，而是持续追问，并把评分构成（功能清晰度 30 / 技术具体性 25 / 实施完整性 25 / 业务上下文 20）透明展示出来，让你知道到底缺哪一块。
Q4：什么样的需求适合用它？会不会太啰嗦？
适合：需求描述模糊、功能复杂度超过 2 天工作量、涉及跨团队协调的场景。不适合：已经给出具体文件路径、包含代码片段、引用现有函数/类的任务，以及有清晰复现步骤的 bug 修复——这些情况下技能本身就不会激活。简单需求若觉得轮次太多，可以在回答中一次性补齐技术栈、边界与验收标准，分数会跳得更快。
Q5：90 分是硬性门槛吗？达不到怎么办？
按技能设定，清晰度分数需达到 90 分及以上才会进入 PRD 生成阶段。如果始终达不到，通常意味着某一维度信息确实缺失（最常见的是“成功指标”和“边缘情况处理”）。这时有两种做法：补齐信息继续澄清，或者明确告知技能“先按当前信息出一版草案，把未决项标注为待定”，让缺口显性留在文档里而不是被悄悄补全。