AI需求澄清Skill
把”我平时怎么做需求澄清”写成给 AI 用的规则：先判断需求到了什么程度，再复述理解并把「已知信息 / 假设 / 缺失信息」分开，然后分档分轮提问（默认 5—10 个问题，必须确认 / 建议确认 / 可以后续确认），最后整理纪要——没确认的内容继续标着，不能悄悄变成”事实”。
简介
AI 需求澄清 Skill 是产品经理简谙为自己搭建的三个 Skill（需求澄清、需求设计、前端设计）中的第一个，目标是阻止 AI 拿到一句话想法就自作主张写出一大篇 PRD。在 2026-09-21-woshipm-pm-ai-tools-skills 中，作者把它当作”善用 Skills，把自己的工作方法留下来”这一节的完整示例。
它回答的问题不是”Skill 是什么”（那是 2026-05-11-skill-sop-for-ai 和 2026-05-26-woshipm-pm-skills-claude 的题目），而是”我自己那条 Skill 该长什么样”——即一份从个人习惯翻译成 AI 可执行规则的规格说明。
它解决的具体风险是：AI 写需求写得越快越完整，自行补出来的内容就越多。作者的原话是”否则文档越完整，里面自行补出来的内容可能越多”，所以这个 Skill 的全部设计都指向同一件事——把”不确定”显式留在台面上，而不是让它在生成过程中变成事实。
关键信息
- 类型：方法论 / Skill 设计规格
- 作者：简谙（同名 Skill 家族：需求澄清、需求设计、前端设计）
- 核心产出：一份带”待确认标记”的需求纪要，交给下游的需求设计环节
- 默认提问量：每轮 5—10 个有价值的问题
- 三个提问分档：必须确认 / 建议确认 / 可以后续确认
- 来源：2026-09-21-woshipm-pm-ai-tools-skills
核心特性
1. 先判断成熟度，不预设用户想清楚了
Skill 的第一步不是提问，而是判断给进来的需求处于什么程度——是一句话想法，还是已有方案需要调整。这个分流决定了后面所有动作的力度：一句话想法需要从头收敛目标与场景，已有方案则需要先找出它偏离的部分。这与 需求真伪识别 的思路互补：后者判断需求本身是真是假，这里判断的是”需求成熟到可以进入设计了吗”。
2. 复述理解，并把三类信息显式分层
第二步是用几句话复述自己的理解，并把「已知信息」「自己的假设」「缺失的信息」分开列出。作者对这一步的评价是：“这个步骤很有必要，有时候它从第一句就理解偏了，后面写得再认真也没用。”
这一步的价值在于它把”AI 的假设”从隐性变成显性——假设一旦被列在纸面上，就获得了被否定的机会。这是整个 Skill 里成本最低、收益最高的一步。
3. 分档 + 分轮的提问设计
提问被设计成三个约束同时生效：
- 数量约束：每轮默认问 5—10 个有价值的问题，而不是想到什么就一股脑全问出来。
- 分档约束：必须确认 / 建议确认 / 可以后续确认三类。
- 理由约束：每个问题要说明”为什么问、不确认会影响什么”。
排序原则是：影响权限和业务流程的先问，按钮文案、默认排序之类的往后放。这条排序原则本身就是一份隐含的业务判断——它把”改动会牵动权限与流程的问题”排在”改了也不影响别人”的问题之前。
4. 提问路径从业务问题一路下钻到异常情况
问题的下钻顺序是：业务问题、用户场景和目标 → 这期做什么、不做什么 → 流程状态 → 字段来源 → 权限 → 异常情况。
其中作者特别点出”涉及金额精度、敏感字段、重复操作、接口失败这些容易遗漏的地方，也要继续追问”——这是一份可直接迁移的易漏清单，对 B 端和交易类产品尤其适用。
以”批量导出”为例，这个 Skill 应该先弄清业务为什么需要，再问导出范围、角色权限（例如：哪些人能导出、能导出哪些字段、导出勾选记录还是全部筛选结果、这些规则谁定的）。
5. 收口时”没有确认的内容继续标着”
答完之后，Skill 把已经确认的内容整理成纪要；信息基本够了，再把目标、范围、角色权限、业务规则、异常情况、验收方向整理好，交给需求设计环节。而整个流程最关键的约束是最后一句：没有确认的内容继续标着，不能悄悄变成”事实”。
这一条与 需求冷冻机制 是同一种思路在不同环节的体现：不确定的东西不是被消灭，而是被显式地隔离和跟踪。
6. 提问答不上来时的正确动作是”带去找业务”，不是”让 AI 编一个”
作者给出的行为准则是：“它问的事情如果我答不上来，就带着去找业务确认，而不是让它随便编一个。“这把 Skill 的定位说清楚了——它不是替代业务沟通，而是生成一份高质量的沟通清单。
不同素材中的观点
- 2026-09-21-woshipm-pm-ai-tools-skills（简谙，2026-09-21）：给出这份 Skill 的完整六步流程（判别成熟度 → 复述分层 → 分档分轮提问 → 易漏清单追问 → 纪要收口 → 标记未确认项），并提出可复用的扩展方向：“大家也可以把自己常用的 PRD 格式、页面规范、评审检查项整理进去。不用一开始就追求做得多复杂，先把一个经常做的任务固定下来，哪里不好用再改。”
- 2026-05-11-skill-sop-for-ai：从理论上解释为什么这条路成立——Skill 的本质是”隐性经验 → 程序性知识包”，把老师傅的隐性经验编译成新手（AI）可执行的程序性知识。本篇提供的是这个过程的一个完整实例：作者把自己”怎么问问题”的隐性习惯，翻译成了六步可执行规则。
- 2026-07-23-woshipm-grill-me-skill / 2026-05-26-woshipm-pm-skills-claude：同属”把提问本身 Skill 化”的家族——用 Skill 让 AI 反过来审问人，以减少需求盲区。本 Skill 的差异是用”分档 + 分轮 + 说明理由”控制提问密度，避免一次性抛出几十个问题把人问烦。
实用信息
- 适用场景：产品经理接到一句话需求时；需要把需求从”想法”推进到”可设计”时；需要在评审前暴露出未确认假设时；团队希望统一需求澄清口径时
- 基本用法（可直接写进自己的 Skill）：
- 判别需求成熟度（一句话想法 / 已有方案需调整）
- 复述理解，分列「已知信息 / 假设 / 缺失信息」
- 每轮问 5—10 个问题，分「必须确认 / 建议确认 / 可以后续确认」三档，每个问题说明为什么问
- 按”业务问题 → 场景目标 → 本期范围 → 流程状态 → 字段来源 → 权限 → 异常”下钻；金额精度、敏感字段、重复操作、接口失败必问
- 整理纪要并交棒给需求设计；未确认项显式标记
- 注意事项：不要让 Skill 直接产出 PRD——它的产出物是”带待确认标记的纪要”，不是成品文档；答不上来的问题要带去找业务，不要让 AI 补全；作者强调不必一开始就做复杂，“先把一个经常做的任务固定下来，哪里不好用再改”