Pm requirement reverse audit

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

1. 目标

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

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

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

核心原则：

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

2. 使用前输入

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

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

3. 触发分级

A. 必触发

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

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

B. 选触发

命中时按需轻扫：

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

4. 终止条件

如果抽象后发现：

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

则只做轻量扫描：

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

不要展开完整反证矩阵。

5. 三步工作法

Step 1: 抽象业务模型

先抽：

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

Step 2: 定位破坏点

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

优先级从高到低：

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

Step 3: 生成反例

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

可用句式：

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

示例：

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

6. 维度选择规则

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

命中交易/购买/退款/售后/履约/权益 -> 必跑：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 个。

优先级：

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. 输出模板

## 需求反证审计

### 1. 需求一句话
-

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

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

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

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

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

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

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

### 7. Scope 收敛建议
-

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

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

9. 使用原则

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