需求歧义分析 Skill：识别模糊表述并推动需求澄清

6 分钟阅读 PolyForm Noncommercial 1.0.0

AI 测试QA Skills需求歧义分析

“仪表盘应该让普通用户快速加载，并在必要时展示相关数据”听起来没问题，但一到设计和测试阶段，就必须回答快速、普通和加载分别指什么。

为什么需要这个 Skill

需求歧义分析 Skill 在保留原文和来源的前提下诊断需求缺少什么，列出不同合理理解并指出缺失区分条件，不悄悄替业务选解释。

Skill 用来做什么

本文关注的是如何让歧义变得可处理，但不假装知道产品负责人真正想表达什么。

当需求中的角色、对象、范围、数量、时间、状态或验收标准不清楚时，在设计或测试规划前使用这个 Skill。它负责诊断和生成问题，不负责编写业务规则。

好的发现应使用 RA 编号，引用模糊原文，写出缺失区分条件、可能理解、影响，并把可关闭问题交给负责人。

当故事里出现“快速”“及时”“正常”“适当”“必要时”等词，或者两个团队可能按同一句话实现出不同结果时，使用这个 Skill。

它不做什么

需求歧义分析 Skill 可以组织模糊陈述的材料、证据和下一步动作，但它不能替代：

  • 业务或领域负责人对规则、范围和风险的确认。
  • 真实环境、账号、数据、日志或运行结果；静态分析不会自动升级为运行证据。
  • 发布、合规、生产操作和残余风险接受等授权决定。
  • 在输入相互冲突时替团队选择一个未经确认的事实。

它主要检查哪些内容

这个 Skill 的价值不在于把关键词再列一遍，而在于把每个关注点接到可观察的输入、判断和收口动作。先用源 Skill 已定义的输出字段整理一张小矩阵：

检查关注点开始前要问结果应留下什么
模糊陈述原始措辞和来源位置引用证据
缺失区分条件缺失的角色、阈值、状态、时间、范围或规则明确缺口
可能理解不止一种合理实现含义不要选其中一个
可关闭问题负责人可以回答的问题及验证方式负责人、优先级和方法

如果某一行只有经验判断、没有来源或验证方法，就把它留在待确认项里，不要提前写成通过。

开始之前先审计输入

围绕“模糊陈述”开始分析时，先把输入分成六种状态。缺口不会自动变成失败，但也不能被隐藏在结论里。

状态含义本 Skill 的处理方式
known材料直接证明的事实标出来源、版本和时间，允许进入判断
missing本轮需要但尚未提供的材料列出最小补证动作，结论保持受限
conflicting来源之间互相矛盾并列来源和冲突点，交给负责人裁决
stale材料存在但版本或时间已经过期标出新鲜度，不把旧结论当当前事实
out_of_scope有关但不在本轮范围内明确排除，避免分析悄悄扩大
assumptions为继续分析而暂时采用的假设写出验证方式和失效条件

至少把输入版本、范围、环境、证据位置和负责人放在一起。没有运行记录时，只能交付分析、设计或验证计划，不能写执行通过。

从问题到结构化 Finding

先把来源、范围、证据状态、分析判断、责任角色、动作、关闭条件和验证方式连起来，再写结论。下面的案例保留这个 Skill 的专属编号和领域语境。

分层写法

围绕模糊陈述，不要把四种语气揉成一句“建议通过”：

层次写法本文应用
Fact材料直接显示了什么引用来源中的重点、版本、输入或运行记录
Evidence-backed Inference多个事实共同支持的判断说明推断链，并保留不确定性
Recommendation下一步最小动作是什么指定补证、复核、执行或回归路径
Human Decision谁需要决定什么由负责人确认范围、风险接受、资源和发布含义

一个完整案例

本节按输入（Input）、分析（Analysis）、Finding、决策（Decision）和验证（Validation）展开；材料不足时保留 missing、conflicting 或 assumptions，不把它们改写成通过。

输入（Input）

材料这次提供什么缺失时的处理
需求来源原始故事、验收条件、版本和位置有原文时不要只分析转述
范围与角色产品、角色、状态、平台、租户、区域和时间窗口适用范围缺失时标出
现有证据样例、原型、契约、历史决策和关联材料把证据与惯例分开
决策边界有权澄清规则的角色，哪些内容不能推断把问题路由给负责人

可以这样调用：

请使用 requirement-ambiguity-analysis Skill。

任务：分析“仪表盘应该让普通用户快速加载，并在必要时展示相关数据”。
输入材料：[故事版本、产品范围、用户角色、原型、性能上下文和已有决策]
范围：[Web 仪表盘、已登录用户、首次加载与刷新]
限制：[不要替业务选择阈值]

保留模糊短语、来源、缺失区分条件、可能理解、影响、负责人问题、关闭条件和验证方式。使用 RA-## 编号，区分歧义与冲突。

分析（Analysis）

先根据输入、检查矩阵和证据状态整理判断，再进入 Finding；缺失材料保留为缺口。

Finding

聚焦例子：让“快速”可测试，但不要替负责人定义它

对于“快速加载”，这个 Skill 可以追问指标是首屏内容、可交互时间还是完整数据加载，适用什么网络和设备，以及覆盖哪个用户群体。它不应该因为常见做法就直接选两秒。产物应该是决策问题和验证方法，而不是自创验收条件。

结果能证明给定材料中的措辞存在多种合理理解，不能替产品决定业务规则、法律含义或最终验收阈值。

示例发现：把一次问题写成可交接动作

下面的字段示例只展示记录方式，不代表真实环境已经执行。

假设当前材料无法证明“模糊陈述”已经满足要求，发现可以这样写。它既不替团队补写规则，也不把缺失证据伪装成失败。

字段示例写法
来源与范围记录本轮使用的需求、版本、环境和模糊陈述的具体对象
发现模糊陈述的判断条件或结果仍缺少可追溯依据
证据状态missing / assumptions；如果来源相互矛盾则改为 conflicting
影响与优先级说明会影响哪个用户、链路或交付决定，不凭感觉扩大等级
Owner 与 Human 决策由业务、开发、安全或测试负责人确认规则和风险取舍
动作与关闭条件补齐最小证据；关闭条件是来源、判断和责任人都能复核
验证指定一次可重复的检查、查询或运行，并保存原始产物

这类记录的重点是让下一位同事能从发现回到来源，再执行一项能改变结论的动作。

决策（Decision）

责任角色和待决策问题应由对应负责人确认；Skill 不替他们做风险取舍。

验证（Validation）

关闭前按 Finding 中的验证方式执行，并保留原始产物；没有执行记录时，状态仍然保持未验证。

Finding 怎么进入下一阶段

交接产物

产物要回答的问题示例状态
模糊陈述原始措辞和来源位置引用证据
缺失区分条件缺失的角色、阈值、状态、时间、范围或规则明确缺口
可能理解不止一种合理实现含义不要选其中一个
可关闭问题负责人可以回答的问题及验证方式负责人、优先级和方法

每条结论都应该能回到来源、证据状态和下一步动作。材料不足时使用 pending、blocked、未评估或 NOT_SCORED，不要用自信填空。

下一步路由

至少交付来源、证据状态、负责人、关闭条件和验证动作；下一阶段的结论仍受证据状态约束。

怎样准备更好的输入

提供原始需求和来源、范围、角色、已知样例、关联设计或契约，以及有权澄清的人。输入不完整也可以开始，但必须提出三到五个高价值问题。

交接时至少保留输入版本、范围、时间窗口、证据索引、假设、人工决策边界和最小验证动作。

和其他 Skill 怎么配合

容易踩的坑

  1. 把模糊词替换成熟悉阈值，再把改写后的句子当成最终需求。
  2. 只有一份材料时就说存在冲突，而不是指出缺少区分条件。
  3. 列出歧义，却没有保留原文、负责人、关闭条件和验证方法。

安装与调用

npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/requirement-ambiguity-analysis -g
请使用 requirement-ambiguity-analysis Skill。
提供目标、范围、版本、证据路径、限制和决策边界。
先审计输入，保留证据状态，最后给出负责人、关闭条件和验证方式。

FAQ

这个 Skill 可以直接重写需求吗？

可以提出澄清问题或候选表述，但必须保留原始陈述，不能把未经批准的解释写成最终需求。

只有一份需求文档也能分析吗？

可以发现单份材料内部的歧义。冲突需要互斥证据，不能自行编出另一方。

参考

源 Skill 与执行契约

完整执行规则在 需求歧义分析 提示词。源目录 中还可能包含评测用例和补充材料。

静态计划、文件存在和 dry-run 保留原有证据状态，不能变成运行时证明、全部通过结论或发布批准。

参考链接

安全测试白盒测试背靠背测试本地化测试边界测试
分享