复杂策略需求文档

复杂策略需求文档

复杂策略 PRD 把目标空间、原则、特殊场景、Case 和验证标准交给研发，由算法探索具体实现。相对简单策略需求文档，特征是因素多、状态多、场景多，需要概述、原则、特殊场景和大量 Case。分类仍看逻辑复杂度，开发成本只是辅助。

功能是收敛的解决方案：页面告诉开发每一步展示什么。策略是发散的：条件不同，处理不同。自动亮度要回答何时触发、光线和时间如何影响结果、如何避免抖动、上下限是什么、用户手动调过后要不要学习、具体场景下希望亮到什么程度。这些问题不能只靠一张原型图。

文档目的仍是让参与方理解来龙去脉。通用五块不变：背景、目标、概述、详述、统计监控。差异集中在概述和详述。

flowchart LR
    A[为什么做] --> B[要解决什么问题]
    B --> C[输入和约束]
    C --> D[必须满足的规则]
    D --> E[输出应达到的效果]

表达对象：原则与结果

回到策略四要素：待解决问题、输入、影响因素、计算 / 决策规则，再加上输出，形成闭环。复杂策略常涉及更复杂的算法，具体模型由算法工程师设计。PM 要详细表达的是：问题及证据、可用输入、业务原则和边界、特殊场景下的期望输出、代表性 Case。算法内部可以是黑盒；双方用 Case 对齐结果的「度」。

需求详述建议拆成三层，缺一不可。

只有原则，实现会在边界翻车；只有 Case，没有方向；只有「优化算法」四个字，研发无法判断往哪走。

从四要素写到可开发 PRD

1. 背景和目标。产品现在遇到什么用户问题、为什么当前阶段要解决、理想态 / 核心指标是什么、策略改善哪个环节。亮度课例：屏幕亮度随外部条件变化，以获得更好的阅读体验。拼车课例：针对已发现的不合理 Case，降低拼车取消率。
2. 需求概述，先搭主干。触发时机、主要输入、重要影响因素、规则方向、输出对象和期望效果。让不熟悉细节的人先理解这套策略总体做什么。
3. 输入与影响因素分开写。输入是系统能获取的数据（频率、范围、口径）；影响因素是哪些变化会改变输出（正向还是负向）。另写约束、用户干预、时序。
4. 特殊场景和边界。极端输入、输入缺失、快速来回操作导致抖动、输出上下限、多因素冲突时谁优先、手动设置与自动规则冲突、是否降级到默认。
5. 用 Case 描述期望输出。列出代表性输入、当前问题、理想输出，让研发看见「度」。
6. 统计和监控。输入是否正常到达、触发和输出分布、目标指标、负向体验、代表性 Case 如何回归、何时复盘调参。见效果监控与策略监控。
7. 写清 PM 与算法的边界。PM 负责用户问题、理想态、输入、原则、边界和效果标准；算法负责模型、参数和实现。过早指定算法会限制解空间。

1
2

Case A：输入条件 → 当前输出 → 理想输出 → 需要改善什么
Case B：输入条件 → 当前输出 → 理想输出 → 需要改善什么

短例一：屏幕亮度自动调节

目标：亮度随外部条件变化，改善可读性和舒适度。要把「什么时候调」和「调到什么值」分开：前者是触发，后者是输出计算。

课例三类触发：用户点亮屏幕、外部环境变化、长时间无动作后进入节能 / 息屏相关变暗。主要影响因素包括外部亮度、系统时间、连续的环境光读数。总原则：外部越亮，屏幕也应越亮；具体映射由后续算法实现。

课例四项特殊场景：

1. 自然光下相对更亮，减轻反光；灯光下可相对暗一些。
2. 走路或设备晃动时传感器会连续跳动，必须有滞后 / 敏感度控制，不能忽亮忽暗。
3. 设最低值和最高值：不能刺眼，也不能低到看不清；外部读数为零也不能把屏幕降到不可读。
4. 记录用户手动调整，作为个性化特征补进规则。

PM 用真实场景加光感采集 Case，不写最终曲线：进入普通和极端光照，用户调到自认舒服的值，记录当时外部亮度等，得到环境条件与舒适亮度的样本，交给算法当输入和目标。

短例二：拼车取消率优化

这是根据前期调研、针对已发现问题做优化。目标是降低取消率。文档可以较短，仍要把不合理 Case、原因和期望结果写清。

课例问题一：一类取消的影响面约 37%，主要集中在早晚高峰、两位乘客拼车或绕路比例较高。日常时段方案可能不明显有问题；高峰堵车会放大绕路和额外等待。可能方向是提高高峰相关拼车的判断 / 筛选标准，覆盖面可能下降，但本次目标是降取消。

课例问题二：折扣比例可能达到 90%，但订单金额很小，用户实际只便宜一两毛。看到高折扣不等于获得足够绝对收益，仍可能觉得不值得而取消。优化方向是不只看折扣比例，还要综合绝对优惠金额。

「优化折扣」无法指导研发：没说哪些订单是问题 Case、当前损失是什么、高峰 / 人数 / 绕路如何影响、比例与绝对优惠的矛盾、希望减少哪类取消、如何验证。复杂策略要把抽象的「优化」变成可实现、可回归的目标。

复杂策略 PRD 大纲

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# 需求名称

## 1. 项目背景
- 当前产品 / 策略、发现了什么问题、证据来源、为什么当前阶段要做

## 2. 项目目标
- 用户理想态、核心指标、目标方向、不可接受的副作用

## 3. 需求概述
- 策略解决什么问题、触发、主要输入、关键影响因素、规则方向、输出

## 4. 需求详述
### 4.1 输入和数据口径
### 4.2 影响因素及方向
### 4.3 基本原则 / 主规则
### 4.4 特殊场景和异常处理
### 4.5 输出边界、兜底和降级
### 4.6 代表性 Case

## 5. 算法 / 工程协作边界
## 6. 统计与监控

1
2
3

目标指标 = 目标事件数 ÷ 目标总体数
问题影响面 = 问题 Case 数 ÷ 有效调研总体
可解决影响面 = 问题影响面 × 预期解决比例

亮度可观察变化次数、手动纠正率、过亮 / 过暗 Case；拼车可观察取消率及高峰、低金额订单等分群。名称和口径以项目定义为准。课例未给统一公式。

文档自检：结构是否层次清楚；背景是否一眼可见；目标 / 理想态是否写清；原则是否明确；特殊场景是否不只写正常路径；Case 是否让研发理解结果的「度」；统计监控是否提前约定。

常见误区

1. 写成一句「优化算法」，没有问题、输入、因素和输出。
2. 把 PRD 写成算法代码。应定义目标、原则和效果。
3. 只有总体原则，没有特殊场景。
4. 只有规则，没有效果 Case。「更舒适」「更合理」需要具体参照。
5. 只看折扣比例，不看绝对优惠。
6. 只看平均场景，不看时段差异。
7. 把输入与影响因素混在一起。
8. 忽略上下限和兜底。
9. 把开发成本当复杂度唯一标准。
10. 忘记统计和监控。
11. 把主观判断写成事实。区分调研证据和待验证假设。
12. 不标注算法黑盒边界。对深度学习等实现，只描述输入、目标、约束和 Case。

适合因素多、需要算法探索实现的策略。规则非常直接时，用简单策略文档。PRD 不能替代算法方案评审、数据质量评审和安全评审。拿不到可靠 Case 时，应先补抽样分析。亮度与拼车的触发、上下限、高峰 / 金额都是课例，不能直接当业务阈值。

开发阶段用开发评估、Diff 评估对照这些 Case 验收；上线后用效果回归看目标空间是否真的被填上。

延伸阅读

• 简单策略需求文档
• 抽样分析
• 理想态
• 开发评估
• Diff 评估
• 策略通用方法论

来源说明

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用