需求冲突检测 Skill:从表面差异中识别真实需求矛盾

两份文档看起来矛盾,并不代表它们真的冲突;其中一份可能只适用于另一个租户、版本、区域或用户状态。检测冲突前必须先核对边界。

为什么需要这个 Skill

Requirement Conflict Detection Skill 在不替业务决定优先级的前提下比较互斥规则,保留双方陈述、条件、证据和决策负责人,避免把适用范围缺失误判成产品冲突。

Skill 用来做什么

本文先确认两条规则是否作用于同一个对象和范围,再处理文档之间的冲突。

当需求、政策、合同或验收材料在同一范围内同时允许和禁止某个行为时,使用这个 Skill。它负责诊断冲突,不负责接受风险、发明折中方案或决定谁优先。

好的发现应使用 RF 编号,保留双方陈述和来源,核对对象与范围是否相同,指出最小证据,并向负责人提出可关闭的优先级问题。

当一个材料说允许某行为、另一个说禁止,或者一次变更暴露出同一角色、状态、字段或动作存在不同规则时,使用这个 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-conflict-detection Skill。

任务:判断隐私政策的 30 天删除规则,是否与分析合同对欧盟客户事件保留 90 天的规则冲突。
输入材料:[政策版本、合同、租户和区域范围、数据分类、生效日期]
范围:[欧盟生产数据和客户事件]
限制:[不做最终法律解释、不修改数据]

保留双方陈述,先检查适用范围,区分 conflict、missing、stale 和未评估,并为每条 RF-## 发现给出决策问题、负责人、关闭条件和验证方法。

分析(Analysis)

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

Finding

聚焦例子:检查保留规则,但不要替法律负责人选赢家

政策说欧盟客户事件 30 天后必须删除,分析合同却说事件保留 90 天。这个 Skill 应确认合同是否覆盖同一事件类型和区域,保留双方来源,并把优先级问题交给隐私和产品负责人。如果合同是全球范围且明确排除欧盟数据,表面冲突就会变成适用范围差异。

分析可以说明给定规则在给定范围下是什么关系,不能提供法律意见、批准保留策略或修改数据。

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

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

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

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

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

决策(Decision)

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

验证(Validation)

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

Finding 怎么进入下一阶段

交接产物

产物要回答的问题示例状态
来源对双方原始陈述和版本可追溯证据
适用性检查角色、对象、区域、状态和时间是否一致共同范围或缺失边界
冲突状态冲突、歧义、缺失、过期或未评估不要默默降级
决策请求问题、负责人、关闭条件和验证方式人工优先级边界

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

下一步路由

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

怎样准备更好的输入

提供原文、版本、生效日期、数据对象定义、角色、租户、区域、平台和状态。任何边界缺失时先标为 missing 或 stale,不要急着叫冲突。

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

和其他 Skill 怎么配合

容易踩的坑

  1. 不检查范围和权威性,就选择看起来更严格或更新的规则。
  2. 把两条规则合并成未经批准的折中句子。
  3. 把缺失版本或区域边界叫作冲突,让团队修错问题。

安装与调用

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

FAQ

这个 Skill 应该决定哪条需求优先吗?

不应该。它保留证据,并把优先级、风险接受或规格修改交给有责任的人工负责人。

如果来源版本不同怎么办?

先检查生效日期和适用范围。比较窗口不清楚时标为 stale 或未评估,不要自动把版本漂移当成当前冲突。

参考

源 Skill 与执行契约

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

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

参考链接

分享