# Pm Requirement Reverse Audit

> 触发：交易/履约/状态/角色等高风险需求需反证；不触发：普通澄清→用pm-requirement-intake；泛风险挑战→用pm-devil-advocate；输出：反例+补规则建议

- Skill: `suibianqugenichenghaole/pm-requirement-reverse-audit` (Agent Skill)
- Install (CLI): `npx skillmds@latest add suibianqugenichenghaole/pm-requirement-reverse-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/suibianqugenichenghaole/pm-requirement-reverse-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: suibianqugenichenghaole (https://skillmd.com/u/suibianqugenichenghaole)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/suibianqugenichenghaole/pm-requirement-reverse-audit

---


# 需求策划阶段反证审计框架 v0.4

## 1. 目标

用于在需求策划阶段识别正向流程看不出的业务盲点。

它不是异常场景清单，而是反证：

- 业务对象是否闭环
- 状态、展示、事实源是否混乱
- 售卖、履约、解释是否一致
- 配置、历史数据、角色视角是否会导致需求失真
- 指标和 scope 是否只是看起来成立

核心原则：

> 先抽象业务模型，再找最可能让模型崩掉的反例。
> 不全量扫清单，只打当前需求最高风险的点。
> 审计必须导向一个明确动作：补规则、缩 scope、拆 release、合并模型，或回到需求澄清。

## 2. 使用前输入

```md
## 输入信息
- 产品背景:
- 当前需求描述:
- 已知业务规则:
- 已知约束:
- 当前阶段: 想法 / 需求讨论 / PRD初稿 / 评审前
```

如果上下文不足，先补问 1-2 个高价值问题，不要编造业务背景。

## 3. 触发分级

### A. 必触发

命中任一项，必须做反证审计：

- 涉及交易、购买、退款、售后、履约、权益
- 存在状态机：审核、退款、发货、履约、生效、失效
- 涉及多角色：用户、运营、客服、财务、管理员、系统任务
- 后台配置会影响前台展示、交易、权限、权益
- 出现多套状态、多个事实源、多个展示口径
- 需求里已经开始加字段、加状态、加配置，但问题本身没讲清楚

### B. 选触发

命中时按需轻扫：

- 涉及历史数据、存量用户、旧订单、旧配置
- 涉及指标、转化、留存、效率、满意度
- 涉及内容、标签、分类、推荐、入口
- 涉及多个 release 或多个业务模块
- 涉及运营手动干预、自动任务、审核发布

## 4. 终止条件

如果抽象后发现：

- 核心业务对象少于 3 个
- 无交易、权益、履约链路
- 无状态机
- 无多角色口径
- 无历史兼容
- 只是文案、样式、简单排序、单点展示调整

则只做轻量扫描：

```md
- 是否有隐藏业务规则:
- 是否影响已有状态/配置:
- 是否需要补一句边界说明:
```

不要展开完整反证矩阵。

## 5. 三步工作法

### Step 1: 抽象业务模型

先抽：

- 正向业务链路
- 核心对象
- 关键关系
- 生命周期/状态
- 售卖/展示/履约/统计对象
- 角色视角
- 配置和规则
- 历史数据影响

### Step 2: 定位破坏点

Step 2 用于定位破坏方向，第 6 节用于选择具体检查工具。两者串行：先用 Step 2 确定破坏点方向，再用第 6 节选择对应维度展开。

优先级从高到低：

1. **关系断链**：对象能否双向反查，售卖/履约/展示是否闭环
2. **状态源冲突**：真实状态、流程节点、展示投影是否混成多套事实
3. **规则冲突**：多个规则、人工/自动、新旧规则同时命中谁优先
4. **历史与时间**：存量数据、并发、不可逆动作是否能解释
5. **角色口径**：用户、客服、运营、财务是否共享同一事实
6. **指标与 scope**：是否解决真实问题，是否过度塞范围

### Step 3: 生成反例

根据当前业务模型选择最能破坏它的 1-3 个句式，不要机械套用全部句式。必须用具体业务对象替换 A/B。

可用句式：

```text
如果 A 存在但 B 不存在，会怎样？
如果 A 变化但 B 没变化，会怎样？
如果从下游反查上游，会不会断？
如果多个规则同时命中，谁优先？
如果历史数据没有新字段，怎么解释？
如果展示需要的状态和业务真实状态不一致，以谁为准？
```

示例：

```text
如果对象 A 存在但关键关系 B 不存在，会怎样？
如果业务真实状态和展示状态不一致，以谁为准？
```

## 6. 维度选择规则

不要全量跑 10 个维度。根据触发信号选择 3-5 个重点维度。

```text
命中交易/购买/退款/售后/履约/权益 -> 必跑：1 对象与关系闭环、2 售卖-履约-使用一致性、6 历史时间不可逆、7 规则冲突
命中状态机/多套状态/展示节点 -> 必跑：3 状态事实源与展示投影、7 规则冲突、8 多角色口径与解释能力
命中后台配置影响前台 -> 必跑：1 对象与关系闭环、5 配置生命周期、6 历史时间不可逆、8 多角色口径与解释能力
命中历史数据/存量用户/旧订单/旧配置 -> 必跑：6 历史时间不可逆、7 规则冲突、8 多角色口径与解释能力
命中多角色/客服/财务/运营/系统任务 -> 必跑：8 多角色口径与解释能力、7 规则冲突、3 状态事实源与展示投影
命中指标/转化/效率/满意度 -> 必跑：9 指标反作用、10 Scope 与 Solution Smuggling
命中 scope 过大/多个 release/多个模块 -> 必跑：10 Scope 与 Solution Smuggling、1 对象与关系闭环
命中内容/标签/分类/推荐/入口 -> 必跑：1 对象与关系闭环、4 粒度错配、2 售卖-履约-使用一致性
```

如果命中多个触发信号，先取维度并集；如果并集超过 5 个，按优先级列表截取前 5 个。

优先级：

```text
1、3、7、6、8、2、5、10、4、9
```

## 7. 反证矩阵

### 1. 对象与关系闭环

检查对象是否有业务意义，关系是否能双向解释。

重点问：

- 对象能否独立存在？独立存在是否有效？
- 上游能否找到下游？下游能否反查上游？
- 是否存在孤岛、空壳、断链、脏配置？
- 关系断开时，是禁止、隐藏、降级、提示，还是允许异常存在？

### 2. 售卖-履约-使用一致性

检查用户买到、获得、使用、失效是否闭环。

重点问：

- 售卖对象、支付对象、履约对象、展示对象是否一致？
- 如果不一致，映射规则是什么？
- 卖出去的东西是否一定能履约？
- 权益变化后，历史订单按旧规则还是新规则？

### 3. 状态事实源与展示投影

合并检查真实状态、流程节点、展示节点。

重点问：

- 哪个状态是唯一业务事实？
- 哪个只是流程节点、操作日志、展示投影？
- App 展示能否由真实状态 + 记录 + 角色规则推导？
- 如果能推导，为什么要新增独立状态？
- 多套状态不同步时，以谁为准？

原则：

> 展示状态默认应是投影，不应轻易变成新的事实源。

### 4. 粒度错配

检查不同模块是否按不同粒度理解同一业务。

重点问：

- 后台按订单，用户是否按商品理解？
- 运营按标签，系统是否按 SKU 履约？
- 用户按内容理解，后台是否按卡/权益配置？
- 粒度转换规则是什么？

### 5. 配置生命周期

检查配置是否被当作业务规则设计。

重点问：

- 配置有草稿、生效、失效、下架、回滚吗？
- 配置修改影响存量还是新增？
- 配置为空、重复、冲突、过期时怎么办？
- 谁能改？谁审核？谁回滚？

### 6. 历史、时间与不可逆

检查旧世界、新规则、事件顺序是否能共存。

重点问：

- 旧数据有没有新字段？
- 历史订单/会员/配置是否迁移？
- 按提交时间、支付时间、生效时间还是处理时间判断？
- 发布、售卖、领取、使用、结算后，哪些动作不可逆？

### 7. 规则冲突与优先级

检查多个规则同时命中时的决策顺序。

重点问：

- 默认规则和特殊规则谁优先？
- 人工操作和自动规则谁优先？
- 新旧规则谁优先？
- 用户、订单、权益、内容状态冲突时，以谁为准？

### 8. 多角色口径与解释能力

检查用户、客服、运营、财务是否共享同一事实。

重点问：

- 用户看到什么？
- 客服如何解释？
- 运营如何配置/修正？
- 财务/报表按什么统计？
- 系统是否记录可解释原因？
- 能否区分业务拒绝和系统异常？

### 9. 指标反作用

检查指标是否只是表面成功。

重点问：

- 有没有 baseline、target、guardrail？
- 转化提升是否可能带来误购、退款、投诉？
- 完成率提升是否牺牲质量？
- 客服咨询下降是否只是用户找不到入口？

### 10. Scope 与 Solution Smuggling

检查是否把方案包装成问题，或把多个 release 塞进一个需求。

重点问：

- 真实问题是什么？
- 为什么必须用当前方案？
- 是否一上来就在加字段、状态、页面、配置？
- 第一版最薄闭环是什么？
- 哪些必须现在解决，哪些可以后置？

## 8. 输出模板

```md
## 需求反证审计

### 1. 需求一句话
-

### 2. 审计模式
- 完整审计 / 重点审计 / 轻量扫描
- 触发原因:
- 本次选择维度:

### 3. 业务模型
- 正向链路:
- 核心对象:
- 关键关系:
- 状态/生命周期:
- 角色视角:
- 配置/规则:
- 历史数据影响:

### 4. 最高风险反例 Top 3
1. 反例:
- 破坏点:
- 影响:
- 置信度: 高 / 中 / 低
- 置信度原因:

2. 反例:
- 破坏点:
- 影响:
- 置信度: 高 / 中 / 低
- 置信度原因:

3. 反例:
- 破坏点:
- 影响:
- 置信度: 高 / 中 / 低
- 置信度原因:

### 5. 冗余清单
- 是否发现冗余: 是 / 否
- 如是，可合并的状态:
- 如是，可合并的对象:
- 如是，可合并的配置:
- 合并理由:

### 6. 需要补齐的规则
- 规则描述:
- 影响范围:
- 优先级: 上线前必须 / 可迭代补充

### 7. Scope 收敛建议
-

### 8. 可以后置的问题
-

### 9. 审计后最优先的一件事
- 选择: 补规则 / 缩 scope / 拆 release / 合并状态对象配置 / 回到需求澄清 / 无需改动
- 原因:
- 其他建议动作（可选）:
```

## 9. 使用原则

- 不全量跑 10 个维度，只选择最相关的 3-5 个重点打。
- 优先检查关系断链和状态源冲突。
- 只输出会影响业务模型、评审结论、开发实现或上线风险的问题。
- 普通 UI 异常不放大成需求缺陷。
- 不确定就标注反例级置信度，不捏造业务规则。
- 如果只能输出一堆“不适用”，说明应该走轻量扫描或停止审计。
- 审计结论必须推动：补规则、缩 scope、拆 release、合并状态/对象/配置，或者回到需求澄清。