简介这是一份百词斩产品需求文档适合产品助理、转岗产品经理或对教育类App功能设计感兴趣的读者阅读。文档以百词斩背词类产品为对象梳理了需求来源、运营目标、特性列表、版本修订记录、数据统计需求与运营支持需求并重点描述了写作背词模式、听力背词模式、调整背词逻辑、增加英音美音发音、单词电台断点续播、复习闯关游戏、单词PK奖励机制等功能点及对应功能拆解可用于学习PRD结构、理解功能优先级划分和产品迭代思路。资源为单个docx文档压缩包共1个文件、大小约3.47MB便于直接阅读和二次编辑。该文档已有251人学习下载适合以真实案例作为需求文档撰写参考尤其适合零基础或初级产品学习者对照模仿从中获取竞品分析、功能列表梳理和产品版本管理方面的可操作经验。1. 一份“百词斩PRD文档”值得写但别只把它当作业交拿到“9、百词斩PRD文档.docx”这个文件名时很多人第一反应是把它当成一份课程作业或求职作品集里的示例照网上找的PRD模板把百词斩的功能列一遍就算完。但真正的问题是你交出去的是一份“需求列表”还是一份能让研发直接动手、测试能照出用例、设计能拿到信息架构的PRD百词斩最值得拆的不是界面而是从选词书、定计划、图背单词到复习打卡这一整条闭环里的规则细节。这篇笔记就沿着这条闭环讲一遍PRD怎么写哪些参数必须在文档里写死哪些边界最容易在评审会上被问住。适合产品新人、转岗做产品经理以及想用逆向方式练需求拆解的在职产品。2. 写PRD之前先把百词斩拆成“定位 流程 文档骨架”2.1 产品定位和用户画像先有一把能反驳开发的“尺子”很多新手写PRD上来就贴原型图、写页面跳转关系开发问一句“这个功能到底给谁用、解决什么问题”就答不上来。这是因为PRD不是原型说明书功能描述只是表象底下得有一把尺子叫产品定位。百词斩的产品定位可以这么写一款用图片联想记忆法帮助备考人群在碎片时间里记住单词的工具型App。这个定位有三个关键词“图片联想记忆法”是核心机制“备考人群”是目标用户“碎片时间”是核心使用场景。写完这行字后面每一个功能决策都能往回对照如果某个功能既不服务备考人群也不提升记忆效率也不适配碎片时间那它就不该进V1.0。用户画像建议写两个就够不要堆一堆伪画像。一个是高中生每天能拿出20到30分钟词汇量目标跟着考纲走最怕背了忘需要复习提醒另一个是备考大学生或职场人可能在地铁、午休时间背单词在意连续打卡因为他们把打卡当成坚持的外部见证。画像的用处不是朗读而是在功能取舍时帮你说清楚理由。比如开发问“为什么要做排行榜”你就可以回答第二类用户有坚持诉求打卡加排行榜是给他们提供外部监督不是凭空抄竞品。写定位和画像时避免一句话原则是“不能被反驳”。像“帮助用户快乐学英语”这种话开发没法拿它判断功能该不该做设计也没法拿它理解信息层级。PRD里写定位是为了让团队在分歧时回到起点不是为了在评审会开场时念PPT。2.2 核心业务链路从选词书到打卡先把主流程写对写PRD前不要急着拆功能先梳理一遍主流程。百词斩的主流程是一条很标准的闭环首次启动后选择词书设置每日学习计划然后进入每日学习单元新增单词和复习单词按规则混排完成当日全部任务后解锁打卡打卡成功后进入次日或中断后的恢复流程。这一步可以用一个“用户步骤 系统响应”的表格把闭环固定下来后续功能分析都要挂在上面不容易遗漏。这个表格里的很多字段之后会直接复制到对应功能页里使用。环节用户动作系统动作关键规则首次启动选择词书展示词书分类与列表按考试阶段分类热门词书可置顶首次启动设置每日新词数计算学习计划默认30词/天范围10到100每日学习开始学习生成当日学习队列新词与复习词按一定比例混排学习单元对单词反馈认识、模糊、忘记更新单词状态状态机待学习、学习中、待复习、已掌握完成目标查看今日完成情况开放打卡入口未完成全部任务不可打卡次日继续新一天学习重置当日进度中断超过7天则降低新词比例为什么要把主流程放在PRD正文靠前的位置因为业务流程图是评审会上第一道防线。研发问“这个功能从哪进来、又走到哪去”你直接指表格就能答。很多PRD翻车的起点就是流程缺失某个页面做得非常细但用户根本不经过那个入口最后开发完了才发现是孤岛。2.3 文档骨架一份能指导开发的PRD至少要有七个部分主流程之后就要确定PRD本身的文档结构。我见过太多PRD把“功能需求”写成了“页面清单”每个页面一段描述没有任何判断依据。好的PRD应当包含七个部分文档信息与修订记录、产品概述、用户画像与场景、信息架构、功能需求、非功能需求与埋点、数据指标与验收标准。章节内容留给谁看文档信息与修订记录作者、版本、变更记录全员产品概述背景、定位、目标评审会全员用户画像与场景目标用户与典型场景设计、研发信息架构页面层级、入口关系设计、研发功能需求每个功能的规则、参数、边界研发、测试非功能需求与埋点性能、兼容性、数据统计研发、测试数据指标与验收标准每项需求怎么算通过测试、管理层其中文档信息这块容易被忽略但评审会上它的作用很大。比如你在V1.2里把“打卡判定”从“完成新词”改成“完成新词且复习词正确率大于60%”如果没有修订记录开发看的是最新版测试看的是上一版当场就会吵起来。每次改动哪怕只改一个参数都要在这个表格里加一行日期、版本、变更点、变更人、原因。文档骨架定了之后后面的功能需求就有了归属写起来不会到处乱跑。3. 功能需求怎么描述百词斩四个核心模块的PRD写法3.1 选词书与学习计划日期怎么算规则怎么写词书选择是用户进产品后的第一个关键动作PRD里要写清楚词书列表展示什么信息以及用户选完之后学习计划怎么生成。词书列表的字段如下词书名称、封面图、词汇总量、适用考试类型、学习人数、难度标签。这里有两个容易漏的地方。一个是排序规则不能只写“按热门排序”要写清楚热门怎么定义可以按“最近7天学习人数”降序也可以按“新增用户选择量”降序我一般建议按“近7天活跃学习人数”定义因为它比累计量更能反映当前热度。另一个是空态如果某个考试分类下没有词书页面不能空着要给出推荐词书或引导搜索。学习计划是更重要的规则模块。用户用滑动条或步进器设置每日新词数范围10到100默认30。计划生成规则要写全参数默认值边界规则说明每日新词数3010到100整数用户可修改修改后重新计算计划总计划天数无不小于1天总词数除以每日新词数后向上取整复习词每日上限50可配置复习队列长度超过阈值时优先处理到期词中断恢复7天超过7天重新触发复习调整降低新词比例增加复习比重需求描述要用“当…则…”的句式保证开发可以照着实现。例如当用户在计划设置页把每日新词数从30改成50系统应重新计算计划总天数并同步修改学习进度条修改后当日尚未完成的计划不受影响从次日起应用新计划。这种写法在评审会上没有歧义。还有一个常见遗漏计划完成日期要不要含当天按产品习惯我可以这样定——“从首次学习的次日开始计算第1天当日学习安排不受影响”这个细节如果不写开发会用自然日计算测试会用24小时整点判断两边就吵起来了。3.2 学习单元单词卡的状态流转不能靠口头描述百词斩学习单元的核心是图背单词但在PRD里不能只描述“展示一张图片和单词”要把单词状态机和反馈动作写清楚。这一块是测试写用例的主要依据也是开发建立数据表结构的依据。单词状态至少需要四个待学习、学习中、待复习、已掌握。状态含义进入条件待学习从未学过的单词词书加载完成后初始状态学习中首次展示给用户进入学习队列时待复习需要按遗忘曲线再次学习答错或到期已掌握连续答对达到阈值连续3次正确且不在复习队列学习单元里的交互动作一般有三个认识、模糊、忘记。每个动作对应的系统行为要写在PRD里不能只写“点击按钮切换下一个词”。用户反馈系统行为单词状态变化认识播放正确音效进入下一词连续正确计数加1计数达到3次状态变为已掌握模糊展示释义与例句稍后在同一轮末端重现状态不变但记入该轮次复习忘记展示答案并将单词加入当日复习队列稍后重现状态变为待复习这里有一个很容易被忽视的规则模糊和忘记之后单词都在同一次学习单元里重现但重现顺序不能放在最前面否则用户马上靠短期记忆答对没有真实检测效果。我一般会建议把重试单词放在当前队列的最后并且间隔至少10个新词。卡面本身的规格也要写图片比例统一为3比4单词英文放在图片下方加粗显示点击喇叭播放读音。如果PRD里不定义比例设计排版会各自发挥最后开发还原界面时只能靠反复比对视觉稿。3.3 复习与遗忘曲线把“智能复习”翻译成开发能实现的参数产品经理特别喜欢在PRD里写“根据遗忘曲线智能安排复习”这句话是评审会上最容易引发争辩的表述因为开发拿到这句话等于什么参数都没有。在实际文档里要把遗忘曲线变成一张可实现的周期表。常见做法是采用近似艾宾浩斯节奏的间隔周期首次学习后的第1天、第3天、第7天、第14天、第30天各复习一次。该周期不是固定模板不同团队根据自己的数据可以调整但PRD里必须明确写出一个版本否则无法开发。复习轮次距上次学习间隔触发条件答错处理第1轮第1天首次学习完成24小时后重新进入第1轮第2轮第3天第1轮完成72小时后重新进入第1轮第3轮第7天第2轮完成7天后重新进入第1轮第4轮第14天第3轮完成14天后重新进入第1轮第5轮第30天第4轮完成30天后重新进入第1轮每次复习的单词数量也要有上限。比如每日复习队列最多50个词超过的话优先处理最接近“临界日”的词也就是第1天和第3天到期的词。这个优先规则要写明确否则开发会按字典顺序排序前端展示效果就差很远。另外一个很容易被忽略的问题是“复习时答对算不算计入连续正确次数”。如果不写开发会把复习的正确次数也累进状态机导致一个单词被复习队列入列后很快就变成已掌握。正确做法是已掌握状态只由首次学习单元的连续答对次数触发复习环节的正确率只影响是否进入下一轮复习不改变状态机。这就是为什么PRD里的每个状态和参数都必须写到测试可以照着用例短句判断的程度。等进入开发再补规则所有的状态清理、数据库字段改造都会翻车。3.4 打卡与连续天数认定规则比打卡按钮更重要打卡模块看起来功能最简单一个按钮加一个分享图但它下面埋着很多边界规则。先写触发条件只有当日全部学习内容完成即新词全部学完且复习队列清空才会开放打卡入口。未完成时入口置灰点击提示“今日学习还差X词完成”。然后写连续天数的计算规则。这是整个打卡模块最容易被开发按照主观理解瞎写的地方。连续天数必须按用户所在时区的自然日计算。零点重置当日进度次日凌晨系统查询用户最近一次打卡时间如果是前一天连续天数加1否则重新从第1天开始。打卡记录用服务器时间不用设备本地时间否则用户改手机时间就能作弊。打卡成功后系统生成一张分享卡片卡片上包含连续天数、累计学习天数、今日学习词数、排名信息。这里的时间字段要用目标时区显示不能直接传服务器时间给前端做本地格式化否则跨国用户会看到日期错位。分享卡片上还要加一个防刷机制同一用户每天只能生成一次有效分享图重复点击只展示同一张图。这个问题看起来小但如果不写开发为了省事会每次点击都调一次生成接口服务器压力变大分享统计也会失真。4. 需求优先级与边界别把V1.0做成全家桶4.1 用MoSCoW法给百词斩功能排序能砍的才能叫规划评审会上最常出现的冲突是“这个功能这么好为什么不放进第一版”。PRD里如果没有优先级需求就是一堆功能清单谁声音大谁就插队。MoSCoW方法很直接把所有功能分成Must、Should、Could、Wont四个级别。Must是闭环刚需没有就不能上线Should是重要但可以后置Could是有比没有好Wont是明确不做并且要写下来。优先级功能理由Must选词书、学习计划、图背单词、复习队列、打卡核心闭环缺一不可Must每日复习提醒没有提醒遗忘曲线形同虚设Should错词本、排行榜、学习统计提升留存与外部监督Could单词电台、桌面小组件、家长端差异化场景详见V1.5规划Wont社区Feed、好友私信分散注意力不做这里有一个判断方法Must功能的特征是去掉之后用户的核心任务无法完成。百词斩用户的核心任务是“记住单词并坚持”所以选词书和学习计划是Must错词本去掉之后用户还能背只是效率变低所以是Should。这个逻辑写进PRD后别人再问“排行榜能不能进V1.0”你可以直接回应它是Should进V1.0的前提是Must不延期。Wont列表的意义经常被低估。把明确不做的功能写下来客户和运营就不会在评审会后反复提“加个打卡分享到朋友圈吧”之类的话题。PRD里有一页“本版本明确不做”反而能挡掉大量无效讨论。4.2 非功能需求埋点、性能与兼容性越具体越少扯皮PRD不只有功能需求非功能需求决定了功能上线后是否还能正常运转。百词斩这类工具型产品至少要写三块埋点、性能、兼容性。埋点要对应主流程的关键动作。我一般会要求埋点表写清楚事件名、触发时机、上报字段。比如事件名触发时机关键字段app_startApp冷启动渠道、版本word_learn每个单词学习完成单词ID、词书ID、反馈结果review_done复习队列全部完成复习词数、正确率checkin_success打卡成功连续天数、本次词数研发拿到埋点表后能直接建事件测试也能核对上报链路而不是等产品上线后想看数据才发现没埋。性能指标要写可验证的数值。例如词书列表页在4G网络下首屏加载不超过2秒单词卡图片在弱网环境下支持渐进式加载不阻塞主流程冷启动时间不超过3秒。这些指标第一次评审时就会收到研发的反驳因为他们最怕“越快越好”这种无法验收的说法。写明确值双方才好对齐。兼容性至少包括iOS最低支持版本、Android最低支持版本、平板适配范围。百词斩的用户里有不少学生用旧安卓机如果PRD里不写最低版本开发和测试会用最新机型跑一遍就报完成线上旧机一出问题就是线上事故。4.3 异常状态测试用例的漏洞往往出在边界场景功能需求写完了还要写异常状态。这是PRD最薄弱的环节也是评审会上最容易被测试同学抓漏的地方。异常状态不要只写“空态”要写当某个条件不满足或出错时系统怎么表现。异常场景系统预期行为用户反馈首次启动无网络加载本地缓存词书列表顶部提示网络不可用可以选词书不能同步进度学习过程中断网已加载的单词卡可继续学完打卡接口上报失败时本地重试不打断当前卡片词书加载为空获取词书失败时展示重试按钮不能进入空白页面打卡按钮重复点击接口做幂等处理后端重复请求只记录一次页面不跳两次设备时区切换打卡判定以目标时区自然日为准连续天数不因时区变化清零写异常状态的好处是能让测试直接产出用例。比如打卡按钮重复点击这个点很多PRD里根本不提测试也不会主动测上线后用户双击导致连续天数重复累计运营那边投诉一堆。把异常场景写成表格等于把测试用例的骨架也一并交付了。5. 百词斩PRD的五个常见坑评审会上最容易被问住的细节5.1 词书内容从哪来数据来源和格式没定义现象需求文档里写了词书列表、单词卡、例句、音频但开发要建数据表时问“词书内容从哪里拿一份词书包含哪些字段更新频率多少”文档里没有答案研发只能先建一张临时表后续返工。原因PRD只描述了功能交互没有描述内容规范。百词斩核心资产是词书内容不定义它的来源和结构功能描述就是空中楼阁。解决在PRD里单独加一节“词书内容规范”写明词书原始数据由内容运营提供格式为CSV或JSON每个单词必须包含单词、音标、常用释义、例句、例句译文、音频文件链接、配图文件链接。同时注明拼写一律以牛津/朗文双解词表为准音标用美式IPA。更新频率目前按词书包发版更新不做后端热更新。这样开发一次建模到位编辑运营也有明确交付清单。5.2 图片联想的版权与素材规格设计到开发才发现缺图现象图背单词最核心的是配图但PRD里没写图片的尺寸、比例、风格、版权要求。设计同学临时去图库找图出来的图大小不一致排在列表里参差不齐严重的还有版权风险。原因写PRD时把精力全放在流程上忘了素材也是一种定义需求。配图如果不规定比例和来源最终效果就靠视觉同学的临场发挥。解决在词书内容规范里写明配图统一为3比4竖构图最小宽度不低于640像素风格要求实拍或插画统一不得使用带水印图片图片来源全部使用已购买版权的图库或自绘插画任何网络下载图一律禁止。这条规则写进去之后设计在出图前就能按规范执行研发也不用反复适配不同比例的图导致布局抖动。5.3 只写“智能复习”不给参数开发没法排期现象PRD里写“根据遗忘曲线智能安排复习时间”看起来很高端。评审会上开发问曲线是哪个版本间隔是几小时还是几天答错之后是重置还是继续累计需求方答不上来开发只能按自己的理解写一个方案上线后复习节奏完全不是产品想要的。原因把没有落到参数的概念性表述当成需求。遗忘曲线是普遍认知的理论但落到产品里需要具体数字。解决把复习周期写成参数表直接放进PRD并且说明这个参数初期可以按经验值配置后续由数据分析来调整不要等算法团队给出完美模型再开发。先有一个能上线的参数化版本配合埋点再迭代。版本每调整一次在修订记录里同步更新参数表保证研发和测试看到的永远是同一个版本。5.4 打卡连续天数计算规则模糊用户改个时区就出问题现象有旅行或出差用户反馈连续打卡天数突然清零还有用户反馈自己在凌晨12点前后打卡天数计算和他自己数的不一样。运营查了半天发现开发是用设备本地时间判断“今天是否打过卡”不同时区之间日期不一致。原因打卡逻辑没有定义时区基准。PRD里只写了“每日完成学习即可打卡”没有说明用什么时间判定“每日”。解决补上打卡规则三要素一、判定时间以用户所在时区的自然日为准二、打卡记录存储使用服务器UTC时间戳展示时按用户目标时区转换三、连续天数判断依据最近一次打卡的UTC时间戳是否落在当前时区的昨天。这三条直接写进功能需求测试用例按不同时区造数据验证问题就能在开发阶段拦住。5.5 错词本同步机制缺失手机换了一堆词没了现象用户在单词学习过程中手动把单词加入错词本或者答错的词自动进入错词本结果换手机登录后错词本变成空的又或者已经完整复习过的词还在错词本里反复出现。原因PRD里定义了错词本功能但没有定义它和单词状态机的关系也没有定义多端同步机制和删除条件。错词本不是一个独立列表它实际上是“待复习”状态的一个视图不写状态关联就会出现数据对不上。解决在PRD中明确错词本不单独存储而是从“待复习”状态中提取生成。已掌握或进入已掌握状态的词自动从错词本移除。同步采用服务端优先策略用户登录时拉取最新状态本地修改在下次联网时上报合并。删除规则是用户手动删除错词不改变单词状态只是从视图中隐藏若单词进入待复习删除后仍然会重新出现。6. 把PRD带到评审会验证需求完整性的三个技巧写完PRD不等于需求完整评审会才是验收现场。我常用的第一个技巧是“模拟开发提问式走查”拿一份打印稿从头到尾问“什么时候触发”“按什么时间计算”“数据从哪来”“异常了怎么办”任何一个问题在文档里答不上来就当场补补完再继续。这个方法很耗时但比评审会当场翻车高效得多。第二个技巧是“用户故事翻译法”。闭眼选一个画像比如那个高中生用第一人称把主流程走一遍“我下载App选考纲词书设置每天30个新词学完单词卡复习了20个到期词完成打卡分享给同学看连续天数。”然后把这段话里每一个动作对应的文档位置标出来如果有动作找不到对应需求就是缺口。反过来文档里写了但用户故事用不到的功能就要考虑是不是塞了多余需求。第三个技巧是“竞品实跑对照法”。把百词斩App装上自己完整跑一遍从选词书到打卡的过程每看到一个状态、一句提示、一个异常就回去对照你的PRD看这个表现能不能由文档推导出来。很多文档里的逻辑冲突比如连续天数算法只有实际看到App表现才会发现。最后分享一个我自己的教训有一次在产品需求里只写了“完成当日目标后可以打卡”没有定义“完成”究竟是新词完成还是新词加复习都完成。开发按自己的理解实现了上线后用户只学完新词、没复习也能打卡复习率一下子掉了很多。从那以后所有涉及“完成”的判定我都强迫自己写出具体条件。希望这套写法能帮你在评审会上少踩几个坑也让那份名为“百词斩PRD文档.docx”的作品真正成为拿得出手的实战样本。本文还有配套的精品资源点击获取