简介：策略产品经理基础知识系列中关于策略需求文档编写的DOCX文档，面向策略产品经理、产品新人及希望系统掌握需求文档写作方法的从业者。文档完整拆解了策略需求文档的核心结构——项目背景、项目目标、需求概述、需求详述、统计与监控需求五大模块，并针对每个部分给出了具体的编写要点与思考方式。尤为实用的是，文档结合新闻平台个性消息推送等实际案例，演示了触发条件、考虑因素、计算逻辑与呈现结果如何串联成完整的策略逻辑链，并强调了避免照抄模板、确保内容精简有用的编写原则。资源包包含1份docx文档，压缩包大小仅18KB，适合快速下载查阅。目前已有173人浏览学习，借由文档中的逻辑拆解与案例示范，可快速搭建策略需求文档的撰写框架，掌握将业务需求转化为可落地产品方案的表达方法，对日常文档输出与逻辑梳理均有直接帮助。
1. 为什么策略需求文档比功能PRD更容易翻车：先想清楚它要回答什么
策略产品经理手里的策略需求文档，和功能PRD是两个物种。功能PRD回答“页面长什么样、点了哪里发生什么”，而策略需求文档回答“什么条件下做什么决策、依据是什么、怎么验证做对了”。这一份名为“2.3策略需求文档”的入门资料，讲的就是后者——把一条策略的输入变量、判断逻辑、兜底路径、指标口径写得让算法、后端、测试都能照着落地。它适合刚开始做推荐、搜索、定价、风控等策略方向的产品经理，也适合功能PM转策略岗时补课。很多人第一次写策略PRD会照着功能PRD的模板硬套，结果评审时被问得哑口无言，因为策略文档的核心不是“界面交互”，而是“决策逻辑的可验证性”。
2. 策略需求文档的骨架：从问题定义到上线回滚，六段式结构怎么排
策略需求文档没有统一的国标模板，但业内反复验证下来，最不容易漏事的结构是六段式：问题定义、策略目标、策略方案、数据与特征、实验与评估、上线与回滚。每一段对应评审时对方一定会问的一个问题，少一段，评审就多一个窟窿。
| 段落 | 回答的核心问题 | 评审时谁最关心 |
|---|---|---|
| 问题定义 | 为什么要做这条策略 | 所有角色 |
| 策略目标 | 做到什么程度算成 | 产品负责人、算法 |
| 策略方案 | 具体怎么决策 | 算法、后端 |
| 数据与特征 | 用什么数据判断 | 算法、数据开发 |
| 实验与评估 | 怎么证明有效 | 数据分析师、测试 |
| 上线与回滚 | 出问题怎么办 | 后端、运维、客服 |
下面把这六段里最容易写偏的三个部分展开，这三段写扎实了，整份文档的地基就稳了。
2.1 问题定义段：把“现状-矛盾-损失”三层写透
问题定义段最常见的错误是写成背景介绍：“随着业务发展，现有策略已无法满足需求，因此需要优化。”这句话说了等于没说。我一般要求自己在这段里回答三个递进的问题：现状是什么、矛盾在哪、损失有多大。
现状要写清楚当前线上跑的是什么。比如“当前列表页按商品销量倒序排序，所有用户看到的结果一致”。矛盾要写清楚为什么这个现状撑不住了。比如“近一个月新客次日留存下降、点击集中在头部三个商品，长尾商品曝光不足”。损失要量化，哪怕是一个区间估算：“按当前DAU测算，每月因曝光不足流失的长尾GMV约XX万”。
我见过很多策略文档的问题段把“现状”和“矛盾”混在一起，结果评审时后端问了一句“现在线上到底是什么逻辑”，产品经理想了三秒没答上来，整场评审的信任感就从这里开始塌。写问题定义时，建议把线上逻辑和问题表现分成两段写，中间用数据截图隔开，让别人一眼看出“现状没问题、是环境变了”。
2.2 策略目标段：主指标、护栏指标和反向指标的取舍
策略目标段不是随便写一个“提升点击率”就完事。单一指标做目标的最大风险是“指标透支”——点击率涨了，转化率跌了；转化率涨了，退货率爆了。策略产品经理在目标段要做的事，是把指标分成三层：主指标、护栏指标、反向指标。
主指标是这次策略要直接优化的东西，只写一个。护栏指标是不允许恶化太多甚至必须保持的指标。反向指标是要盯着别爆掉的指标。比如一个“猜你喜欢”重排策略，主指标可以是“人均点击商品数”，护栏指标是“人均交易额不低于基线95%”，反向指标是“人均曝光负反馈率”。
提示：写指标时必须带口径定义，包括计算窗口（周/日）、分子分母、是否去重、基线数值。口径不写清楚，数据分析师看完会拿着另外一套口径给你算，上线后你俩对着一个数字吵一上午，最后发现一个按UV算、一个按PV算。
目标段还要写清楚预期收益的“合理区间”而不是一个点。策略模型的收益往往不是线性的，写“预期人均点击提升3%~5%”比写“提升5%”更诚实，也更能扛住评审追问“凭什么”。
2.3 策略方案段：规则、模型和兜底三种表达方式
策略方案段是整份文档的技术核心，这里写得好不好，直接决定算法和后端在排期时给不给你好脸色。策略方案一般分三类，表达方式各不相同。
第一类是规则类，典型像是“首单用户下单满20元减5元”。规则类必须写明触发条件、参数值、优先级和生效范围。不要只写“满减”，要写“满XX减XX，与店铺券互斥，用户同时命中多档时取门槛高一档”。规则中的数字用参数表列出来，方便后端对着配。
第二类是模型类，近两年这类策略越来越多，比如“用一个点击率预估模型对商品排序”。模型类策略最难写，因为策略产品经理容易把它写成黑匣子——“这里用模型排序，效果见实验”。我一般要求至少写明：模型输入特征（至少列出特征大类）、训练样本与更新频率、打分结果的用途（决定排序权重还是直接截断）、模型输出的阈值或分桶方式。不要写模型内部的数学细节，那是算法的事，但你要写清楚模型产出的结果怎么被业务使用。
第三类是兜底策略，这是最容易被忽视的一块。线上数据不会永远规规矩矩，用户可能没有历史行为、特征缺失、模型打分超时。兜底策略写的是“当正常路径走不通时，系统退到哪一步”。比如“用户无历史行为时，按类目热榜填充；模型服务超时500ms时，降级为原排序”。兜底不写，后端同学默认给你写一个空列表返回，线上效果直接跳水。
三类表达方式不必分开写成三段，很多时候一条完整策略同时包含模型主体规则选择和规则兜底，按决策顺序写成一个流程更清晰。但无论怎么写，一定要有一个“当前线上策略 vs 新策略”的对比表，让别人一眼看出你改的是什么。
3. 把docx当交付物而不是记事本：写策略PRD时用Word的三个实操技巧
策略需求文档的最终交付格式通常是docx，全公司都要能打开、能批注、能归档。但很多人只是把Word当成打字工具，样式不用、目录不建、模板不配，等到文档写到第20版，文件名变成“策略需求文档_最终版_真最终版_v7.docx”，就彻底乱套了。这里分享三个我几乎每份策略PRD都会用到的docx实操。
3.1 用样式层级管版本：标题、正文、修订三件套怎么设
策略需求文档最怕的不是写不完，是改来改去把自己改晕了。我用Word的第一习惯是全部用“样式”来排版，不手动调字号和加粗。标题1放章节名、标题2放小节名、正文样式统一为宋体五号或等线11磅。这样做的好处是：导航窗格能自动生成目录，评审时别人说“看2.3”，你三秒钟跳过去；更关键的是，另存为PDF时目录和页码不会乱。
修订和批注也要留痕。线上策略出问题了，回溯时最怕看到一份干干净净的docx，所有改动都被覆盖掉了。我在每次评审后都会用“审阅-修订”模式改文档，哪怕只是改一个参数。这样最终归档时，谁在什么时候改了什么参数，全部可查。这个习惯救过我一次：某条定价策略上线后毛利异常，回溯发现是评审时把门槛从“满199减30”改成了“满99减30”，有人口头提了没人记下来，幸好修订记录里有那一笔，不然要查三天。
3.2 在Windows里搜docx正文：两种可靠方法，别再翻文件夹
策略需求文档写多了，总要在历史文件里找某一句话或某个参数。“我记得上次那条风控策略里写过‘频次超过5次’”，但文件名叫“风控策略_v3”，根本想不起来是哪份。Windows里搜docx正文是能做到的，不用装任何第三方工具。
方法一是依靠Windows自带的搜索索引，前提是你的文件放在“文档”或“桌面”这类默认索引位置。打开“控制面板-索引选项”，确认“.docx”在这里被勾选。然后在文件资源管理器搜索框里输入：
content:“频次超过”注意content冒号后面的关键词要加英文双引号。如果搜不出来，去索引选项里点“高级-重建”，等索引建完再搜。Windows对docx正文的索引依赖Word的文本提取，如果这份docx是从WPS或在线文档导出的，偶尔会有索引不到的情况。
方法二更适合非索引目录，比如网络盘或移动硬盘。用Everything搜索文件名很快，但它默认不搜docx正文，需要“工具-选项-内容索引”，新建一个“docx”规则，再对目标目录做一次索引。我一般把策略文档的归档目录单独建索引，只索引docx提取正文文本，目录不用太大，全盘索引反而慢。
提示：如果你搜正文是为了做“策略参数变更审计”，更可靠的做法是不要把正文当数据库用。策略参数变化频繁的话，把关键参数抽出来单独维护一个JSON或CSV，docx只写分析过程，检索交给结构化文件。
3.3 从docx到JSON：把写死的规则变成可校验的结构
策略评审会上最常出现的场景是：产品经理口头说“门槛是199”，后端打开文档找半天，发现表格里写的是“满199减30”，但文档里的数字是图片格式，复制不出来，只能手敲进配置中心，敲错一个数字就是一次线上事故。所以近两年我养成了一个习惯：规则类的策略参数，除了写在docx里，我还会用脚本把它转成JSON，直接交付给后端做校验。
docx转JSON不需要多复杂的工具，python-docx这个库就能干。我一般写一个小脚本，把文档里的表格和标题结构抽出来：
from docx import Document import json doc = Document("策略需求文档_2.3.docx") data = {"sections": []} current_section = None for para in doc.paragraphs: if para.style.name.startswith("Heading 1"): current_section = {"title": para.text, "tables": []} data["sections"].append(current_section) elif para.style.name.startswith("Heading 2"): # 用表格标题做key，后续表格归属到最近的小节 current_section = {"title": para.text, "tables": []} data["sections"].append(current_section) for table in doc.tables: rows = [] for row in table.rows: cells = [cell.text.strip() for cell in row.cells] rows.append(cells) # 简化处理：把表格追加到最后一个section下 if data["sections"]: data["sections"][-1]["tables"].append(rows) print(json.dumps(data, ensure_ascii=False, indent=2))这段脚本的逻辑是：先遍历docx的段落，按标题样式切分章节；再遍历所有表格，把每一行单元格转成列表；最后把章节结构和表格合并成JSON输出。python-docx的单元格文本会包含换行符，实际使用时要替换成空格。转出来的JSON不需要完美还原排版，核心目的是让后端拿到可复制的参数值，并且方便做diff——上一版“门槛199”和这一版“门槛99”，两个JSON文件一比对就出来了。
如果你的团队后端用的是Java，他们多半会问你要docx模板生成的接口，而不是要你手动交付JSON。这种情况常见做法是后端用docxtpl这类模板引擎，你在docx里预留变量占位符，后端把配置中心的值灌进去生成文档。无论哪条路，原则是同一个：参数逻辑只有一份真源，docx和JSON只是它的两种投影，不要让两边手维护、出现不一致。
4. 策略需求文档避坑：评审不通过和线上事故都藏在细节里
策略需求文档踩过的坑，比功能PRD多得多。下面是五条高发踩坑记录，每一条我都见过对应的事故现场，写出来供你对照自查。
4.1 现象：指标写“转化率提升5%”，评审时被问“相对谁提升”
原因：这是几乎所有策略PM新手都会犯的错。转化率有老客转化、新客转化、整体转化，是相对上周提升还是相对对照组提升？分母是UV还是PV？不写清楚，数据分析师只能默认按自己的口径算，而算法同学也会在实验配置时无所适从。
解决：指标一律写成“相对基线（XX口径下近14天均值）的相对提升/绝对提升X个百分点”，并注明计算口径。我会在目标段直接给出一个示例：主指标为“新客首购转化率，口径为当日新注册用户在当天23:59前完成首购的UV占比，基线为12.3%，预期相对提升3%~5%”。一行写完整，不接受模糊表述。
4.2 现象：只写主策略没写兜底策略，线上出现空白推荐
原因：产品经理默认用户都有历史行为、默认模型服务永远正常、默认数据表不会缺字段。实际上新用户无行为、接口超时、埋点延迟天天发生。线上主策略一旦失效，没写兜底的后端只能返回空列表，整页空白，几小时内业务方电话就被打爆。
解决：策略方案段强制写“异常场景兜底”。我习惯的做法是列一个三行表格：异常场景、兜底逻辑、兜底数据来源。比如“模型打分全为0时，按类目销量榜Top50截断补位”。这条不通过评审，文档不发版。
4.3 现象：决策树画了流程图，但没标注特征顺序，算法实现结果和预期不一致
原因：策略PM经常在文档里画一张决策树，树画得很漂亮，却漏了关键信息——先判断哪一维特征、特征缺失时走哪条分支、数值型特征的阈值是否含边界。同样一张树，算法可以按“先看客单价再看品类”，也可以按“先看品类再看客单价”，结果差出去一大截。
解决：凡涉及规则类分支，一律用表格列出决策顺序和优先级，不要只画图。表格列至少包含：决策顺序、特征名、判定条件、阈值边界（含或不含）、分支结果、缺失值行为。这一张表写完，算法不用猜，后端也不用反复来问。
4.4 现象：同一次实验里改了三个参数，数据上涨却说不清是哪一个起了作用
原因：策略PM为了抢时间，把排序权重、截断阈值、展示数量三个参数同时改掉，一起发版。实验数据确实涨了，但评审复盘时产品经理解释不清——是排序更准了，还是曝光量变大了？下次迭代不知道保留哪个参数。
解决：每次实验只动一个核心参数，其他参数保持基线；如果确实需要联动修改，把实验设计成两阶段，先单独验证权重，再单独验证阈值。写进文档的实验方案里要有“变量控制表”，明确哪个是实验变量、哪些是固定变量。这条也是给测试同学看的，方便他们设计用例。
4.5 现象：模型类策略只写“引入新模型”，模型版本、训练周期、回滚条件全没写
原因：模型型策略对PM来说最容易写成黑匣子。评审会上算法说“效果还不错”，产品听不懂也不敢追问，文档里就写“新版模型排序”。结果模型上线两周后效果衰减，整个团队找不到历史版本，回滚都不知道滚到哪个版本。
解决：模型类策略段落里，最低限度写清楚三件事：模型版本号或训练日期、线上和实验模型的差异点、回滚触发条件。回滚不是“效果差就回滚”，而是一行数据阈值：比如“监控指标连续3天低于基线90%，自动切换回上一版模型”。这条写清楚，运维才有执行依据，而不是靠人肉盯屏。
5. 发布前的最后一道闸：评审自检清单和两个百试百灵的检查动作
每次准备发起评审前，我会把文档从头到尾过一遍自检清单，全部打勾才敢发出去。这里给你一套可以直接用的版本。
第一，问题定义段能不能在30秒内讲完“现状-矛盾-损失”，讲不完说明还没想透。第二，策略目标段的主指标、护栏指标、反向指标各有一个，且全部带口径和基线。第三，策略方案段是否包含“当前线上策略 vs 新策略”的对比表，以及异常场景兜底表。第四，参数是否同时存在于docx和结构化文件（JSON或CSV）里。第五，实验方案是否明确实验变量、固定变量和实验周期。第六，是否有回滚触发条件和负责人。
提示：不要小看“负责人”这一栏。策略文档写了回滚条件，但没写谁按下回滚按钮，事故发生时大家互相等对方先动手，多等一分钟就多一批用户受影响。
自检之外，我还有一个从血泪里养成的验证动作：把docx另存为PDF后再检查一遍。docx在别人电脑上打开可能会因为字体缺失而排版错乱、表格列宽变形，PDF是你交付出去给人看的最终形态，格式问题在评审现场被发现会非常尴尬。另存为PDF后主要看三样：表格有没有被截断、决策树图片有没有糊、页码和目录有没有错位。
另一个动作是逆着读一遍自己的指标口径——把自己当数据分析师，只看目标段文字和指标表，不看策略方案，能不能算出你要的那个数。算不出来，说明口径缺信息，回去补。这篇基础的第2.3节内容写到这里，从六段式骨架到docx实操，再到五条踩坑和自检清单，基本覆盖了策略需求文档从零到评审的全部路径。策略文档写得越细，你在评审会上越轻松，希望这份实战拆解帮到你。
本文还有配套的精品资源，点击获取
