简介一份围绕抖音短视频App撰写的完整产品需求文档以PDF单文件打包大小3.16MB面向产品经理、助理及运营人员用于学习成熟移动应用的PRD结构与需求拆解方法。压缩包内仅含1个PDF文件但内容组织完整覆盖产品简介、用户数据、需求总结、产品功能/信息架构、全局说明、流程图与页面逻辑图。文档对登录页的三种登录方式、网络环境、键盘输入、评论框、分享框等全局规则以及首页推荐/附近的视频播放、分类切换、互动功能区均有详细交互说明可帮助读者对比实际抖音产品理解各模块需求点。已有190人学习下载适合作为短视频类产品需求文档的写作模板和功能梳理参考。1. 一份“产品需求文档抖音短视频.pdf”能不能让三方直接开工短视频产品从零到一大多数评审会的火药味都集中在一份名为“产品需求文档抖音短视频.pdf”的文档上。它是产品、研发、测试三方对范围的唯一契约产品看到的是形态研发看到的是排期测试看到的是验收口径。如果这份PDF只写了一堆功能描述却把数据表、接口、审核链路、埋点指标全部留白评审会基本会演变成吵架现场。这篇内容专门用来拆解这份文档该怎么分层、每层写多深、哪些参数必须提前定死适合准备认真做一个短视频产品的产品经理以及不想在需求评审时被问倒的工程师读完可以拿章节结构直接当目录去逐节补内容。2. 用户画像与核心场景先定稿没有这一章后面全是空谈短视频产品的边界不是靠竞品截图圈出来的而是靠用户画像和场景圈出来的。我见过不少PRD开篇就写“我们要做一个年轻人都爱看的短视频App”这句话在评审会上没有任何约束力因为研发无法从中推导出任何一条功能。真正能推导功能的是画像里的典型行为以及每个行为背后的时长、频次和容忍度。2.1 三个用户画像决定了功能边界建议在PRD前两页用一张画像表把三类角色分开写不用把画像写成人物小传只需要填四个维度使用时间、核心行为、离开原因、可接受的失败方式。画像年龄段使用场景核心行为离开/流失点浏览型用户18-30岁通勤、午休、睡前刷推荐流、点赞、评论、关注连续刷到重复或低质内容创作型用户16-28岁有素材后用手机直接拍拍摄、上传、剪封面、看反馈发布失败或长时间无曝光运营型用户25-35岁后台工作台审核、话题运营、创作者维护后台无法定位违规内容每个画像至少要回答“他在什么情况下会离开”。浏览型用户不是离开App而是离开推荐流创作型用户不是不用产品而是发了一条没人看就放弃。PRD里写清楚离开点后续的性能指标和推荐策略才有指向性。我在需求评审时经常问团队一句话这个画像离开时系统里哪个模块的哪个指标会变差答不上来的画像就是无效画像。2.2 四个核心场景写成动作链筛掉伪需求场景不要写散文写动作链。动作链的意思是用户在哪个页面做了什么操作系统必须返回什么结果异常时怎么办。初版PRD我建议只保留四个场景多了研发排期会散少了业务闭环会缺。第一浏览者在空闲时间进入推荐流顺序执行刷新、观看、下滑、点赞、看评论。系统这里必须做的事是快速拉取一页视频、对已看过的视频去重、在点赞后更新底部按钮状态。第二浏览者刷到陌生创作者的主页想看他的历史作品并决定是否关注。系统必须做的是主页作品按时间倒序展示关注按钮落库后立刻返回状态且不影响推荐流里的当前位置。第三创作者完成拍摄后上传一段带话题的视频系统必须完成分片上传、转码、封面生成、审核状态返回。第四用户收到评论或回复通知回到内容详情查看系统必须保证详情页能按评论ID定位到原内容而不是只给一个跳不过去的通知。这四个场景分别对应推荐流、关注关系、发布链路、互动通知写完后你再看功能清单多余的东西会自己浮出来。比如“同城定位”在这个版本里没有出现在任何动作链上那就不要往P0里塞“私信”只在第四个场景的延伸里出现那它最多到P1。2.3 版本功能范围P0/P1/P2怎么切功能优先级是PRD里最容易被投票投出来的部分谁声音大谁进P0。我的做法是给每个优先级绑定一个原则P0必须保证“刷得起来、发得出去、留得住关系”P1是“找得到内容、找得到人”P2是“赚得到钱、留得更久”。优先级模块包含内容P0基础闭环推荐信息流、关注流、视频上传发布、点赞评论、个人主页、登录注册P1发现与连接搜索、话题页、消息通知、私信P2增长与商业化直播、道具特效、购物车、创作者激励当时我犯过的错是把直播也放进了第一批需求结果一个直播房间的IM、房间状态、礼物系统把推荐流的排期挤掉半个月。短视频的第一版核心不是功能多是让用户在两分钟内完成“看到内容、产生互动、理解创作者是谁”这个闭环。P0里的关注流必须和推荐流并排出现在首页Tab里因为它承担着把临时用户沉淀成稳定关系的作用没有关注流推荐流再准也留不住人。3. 把“刷短视频”翻译成研发能排期的结构信息架构与核心表用户画像和场景解决的是“为什么做”从这一章开始解决“怎么做”。信息架构解决页面怎么摆五张核心表解决数据怎么落接口清单解决前端怎么排期。很多PRD在这里突然变成纯文字描述渲染、算法、推荐全用“智能”两个字带过去这是研发最怕的写法。3.1 页面结构与跳转关系PRD里写页面结构时不需要画复杂状态图用一张表格把Tab层级、页面路径、依赖条件列清楚就行。短视频产品的主结构一般是五个底部Tab首页、关注、发现、消息、我。首页承载推荐流是默认落地页关注页按时间倒序展示已关注用户的近期作品发现页放搜索入口、话题榜和运营位消息页放互动通知我的页面放个人资料、作品列表和创作入口。页面跳转关系里最容易翻车的是返回逻辑。从推荐流点进个人主页再点进作品详情然后返回是回到个人主页还是回到推荐流的原位置答案一定是回到原位置并且保持之前刷到的视频序号不变。这一条不写进PRD前端大概率会做成重新拉一页数据用户被迫重刷反馈就是“刷着刷着被踢出去了”。还有一条是从评论区点进另一个用户的头像再继续往返多级跳转的堆栈只允许用户退回到最早的那个入口而不是一层层退到App首页。需要单独说明的还有上传入口。拍摄入口和“”按钮放在首页顶部和“我的”页面右上角两处这两处必须指向同一个新建视频页面否则产品会在后台上看到两个上传事件来源埋点分析直接分开。3.2 五张核心表把业务上限写清楚短视频产品的业务模型其实不复杂但表结构不提前定研发会按自己对业务的理解做出完全不同的设计。PRD里至少要把五张核心表的字段和主键约束写出来不用写SQL但要写清楚每个字段的业务含义。表名核心字段说明useruid、nickname、avatar_url、signature、birthday、gender、user_type、status、reg_timeuser_type区分普通用户/创作者/官方账号官方账号需要有认证标记videovid、uid、cover_url、video_url、duration、width、height、topic_id、status、play_count、like_count、comment_count、share_count、create_timestatus贯穿上传中、审核中、已发布、已下架四个状态followid、uid、follow_uid、create_time联合唯一索引一定要建在uidfollow_uid上否则重复关注会变成脏数据interactionid、uid、target_type、target_id、action_type、create_timetarget_type区分视频或评论action_type区分点赞、收藏、不喜欢topictopic_id、topic_name、cover_url、video_count、hot_score、status话题榜展示依赖hot_score运营可后台调整这里有个必须提前想清楚的取舍play_count这类数据到底实时读还是异步刷新。如果要求绝对准确每次打开视频详情就去count一次互动表数据库扛不住如果允许分钟级延迟就可以用异步任务更新计数列。PRD里要明确写“展示数字允许最多10分钟延迟”否则测试会拿详情页的数字和数据库值对比对不上就提单研发还得加班解释。3.3 接口清单先行前端才敢排期页面结构定了之后接口清单必须在PRD正文里出现哪怕只写接口名字、方向和关键参数前端也能据此评估工作量。推荐流的核心接口是获取信息流的列表接口发布链路的核心接口是视频上传接口互动链路的核心是点赞评论的关注接口具体可以按下面这个粒度写。接口请求方向关键参数返回结果GET /api/v1/feed首页刷新加载feed_type(home/follow)、page、last_vid视频列表、悬浮广告位、分页游标POST /api/v1/video/upload发布链路video_file、cover_file、title、topic_id、locationvid、upload_status、审核状态POST /api/v1/interaction点赞评论关注target_type、target_id、action_type当前计数、操作结果GET /api/v1/user/{uid}/profile个人主页uid用户信息、作品列表、统计数据GET /api/v1/topic/hot发现页榜单period话题榜列表关键点是feed接口不能用传统分页的page/page_size直接切短视频要的是游标分页用last_vid定位上次刷到的位置否则用户在信息流里往下刷了三页再拉新数据时很容易因为中间插入了新内容而重复刷到旧视频。上传接口要强调分片上传和断点续传移动网络不稳定是常态PRD里要写明单个文件超过50MB时自动走分片上传流程并且允许用户切换到Wi-Fi后继续。4. 推荐、审核和性能指标PRD里最容易写空的非功能部分推荐、审核、性能这三块是短视频产品PRD里公认最容易“写了个寂寞”的部分。不懂的人不敢写懂一点的又只愿意写结果不愿意写约束。但正因为这三块决定产品能不能活PRD更不能含糊。我写这部分的原则是不逼着算法团队公开模型但要把输入、输出、边界三条线拉清楚。4.1 冷启动推荐既别写成黑匣子也别指挥算法实现细节很多团队在PRD里只留下一句“推荐策略由算法团队实现”这就是把推荐当黑匣子评审时谁也说不清用户第一屏看到什么。要我说初版PRD把推荐拆成“候选池、排序规则、曝光保护”三个可检验对象就足够了。候选池指的是用户打开App后系统从哪里挑视频给他。新用户没有行为历史最稳的候选池是“注册城市热门话题视频同年龄段热门视频少量随机新视频”三层混合。这里要写清楚数据来源从已审核通过且status发布的视频池里按topic的hot_score倒序取1000条再混入当天新发布的1000条不要让某个池直接膨胀到几万条再实时智能筛选性能会翻车。排序规则的初版设置是帮助模型冷启动的临时压价。完全按热度排序会让老视频霸榜新人永无出头之日。建议PRD里写一条兜底规则新发布视频在产生完播率之前至少获得每小时一次的随机曝光机会且曝光位置不得低于信息流第二屏这就是新内容保护期它比模型本身更能决定冷启动期的内容生态质量。推荐部分的PRD还需要写清楚实验开关需求。推荐参数必须支持后台远程配置至少要覆盖“候选池大小、新视频保护期时长、推荐列表混入比例”三个控制项算法团队迭代时不用发版就能调整否则任何一次参数调优都意味着整条发布链路要跟着重新测试。4.2 去重与负反馈一个细节毁掉整个信息流体验短视频去重是实际体验最容易崩的地方。用户刷到第7条时发现刚才看过的视频又出现了第一反应不是“没事再看一遍”而是“这App怎么这么差”。PRD里必须给出明确的去重规则而不是一句“注意不要重复推荐”。我的建议分两层写会话内去重和24小时去重。同一会话内任何视频只允许出现一次跨会话的24小时内一个视频最多可以再现两次且不能连续出现。实现上靠曝光记录来完成客户端要上报视频曝光事件推荐服务端要保存最近N条视频的曝光记录并做过滤。如果客户端不按时上报这个功能就直接失效所以要写清上报时机是“视频滑入屏幕面积超过50%”不是“点击播放”。负反馈是另一处高频踩坑点。用户点了“不感兴趣”之后当前这条视频要立刻从会话内移除同时该视频所属话题的权重降到原来的30%左右持续15分钟。不建议做永久屏蔽用户今天不喜欢美妆下周可能因为朋友转发又开始看美妆永久屏蔽反而把内容池越切越窄。测试验收时要专门验证两点第一点击后当前会话内不再出现该视频第二相关话题视频在接下来15分钟内占比明显降低。这两点没有明确验收通路前端报了事件就算完成后端不回写权重负反馈就是摆设。4.3 内容审核链路拦截、复审、申诉要形成闭环任何UGC产品都要面对内容审核PRD不能只写“接入内容安全服务”要写清楚审核在视频发布流程中的位置和异常处理路径。完整的链路是用户上传视频并提交发布系统先做技术校验格式、大小、时长、封面比例然后进入机器审核。机器给出置信度分数0.9分以上直接拦截0.8到0.9转人工复核0.8以下放行并标记为抽样复审对象抽样比例不少于5%24小时内完成。这里要想好和用户侧的状态交互。视频上传后前端要居然显示出“审核中”的状态卡片而不是默默不发也不给提示。创作者最反感的是发布后什么都没发生辛苦拍的内容石沉大海。状态至少要区分上传中转码中、审核中、已发布、审核未通过。审核未通过时要把拦截原因用可理解的话返回给用户比如“内容涉及违规元素请修改后重新发布”而不是只给一个“失败”字段。审核的兜底是申诉。误判一定存在所以PRD里要包含“对审核结果有异议”的申诉入口用户在个人主页的作品列表里可以发起申诉需要提交申诉理由和承诺。申诉进入后台队列最迟两个小时内回到机器加人工的复合复审首次申诉的优先级要高于普通复审队列因为用户在这个阶段最容易流失。5. 避坑五条容易让PRD翻车的写法对应的后果各不一样这一章是我做短视频产品时交过的学费不是理论推演。每一条都按现象、原因、解决的顺序写清楚你在写PRD时可以直接对照检查。5.1 功能描述写成了作文验收标准却是空白现象PRD里写“用户可以查看视频详情页的评论并对感兴趣的评论进行回复”这一句话占了半页但研发问“回复成功后评论数据什么时候可见”时产品经理答不上来。原因是把PRD当成功能说明书只写了交互路径没有写数据一致性。解决每条功能需求必须带三件套前置条件、操作路径、验收判定。上面这条好评如潮的验收判定就应该是评论A被用户B回复后在3秒内刷新详情页可以看到新回复且回复数1且原评论的下拉列表定位到当前用户发出回复的位置。写不出来三件套的功能就直接列到P2去别占用评审时间。5.2 “不感兴趣”形同虚设用户投诉怎么还一直推同类内容现象产品在推荐流加了一个“不感兴趣”的入口用户点击后当前视频消失但往后刷仍然反复出现同话题内容半个月后负面反馈集中爆发。原因是从UI交互到推荐服务端没有一条完整的数据链路。揭开前端的“掉当前视频”操作只是在前端字段里屏蔽了这条视频既没有把负反馈事件上报给推荐服务也没有把推荐权重调整对象确认到话题维度。举报按钮不能只当UI画要当成一个事件全链路。解决PRD里要明确负反馈的分类是“我不喜欢这条视频”还是“我不喜欢这类话题”两种诉求的处理完全不同。按麻烦程度更建议初版统一处理为后者点击调推荐服务端的“内容降权”接口服务端返回“已收到屏蔽请求并生效”前端拿到回执后关闭按钮同时在推荐日志中记录本次负反馈操作便于技术排查询问“为什么没有生效”。5.3 新创作者冷启动等于零发布后像个数字孤儿现象创作者在一场头部活动里发布作品24小时后播放量是个位数大量的新人作品沉底且没有获得任何反馈创作者开始流失。原因是团队只把推荐池做成了“热门榜”序列系统按热度去拉数据新发布的作品热度低永远进不了首屏系统越来越集中地推荐同样的头部内容。解决PRD改为设定新内容保护池定义“新内容”的时间范围是发布后24小时内。新内容在进入推荐池时按话题分类打散每条作品在进入保护池后被随机分发给至少200位非粉丝用户用这200次点击的完播率决定是否进入热门池保底曝光保护期结束还没有起量的作品再自动沉底。这样既不干预算法总体排序又把新创作者的一般供给盘活了。5.4 埋点事件等开发后才补上线第一天发现数据缺失现象上线后要看次日留存数据后台打开发现根本没有“用户滑到第二屏”的数据核心指标只能靠猜。原因是产品部和技术部都把埋点当成了开发过程中的配套没有在PRD阶段就定义出来尤其是信息流内部的细致行为几乎没有埋点方案。解决推荐在PRD末尾增加一张埋点清单不用上百个但至少要包含feed_show信息流刷出时的事件、video_play_start起播事件、video_play_finish完整播完事件、video_click_comment打开评论事件、publish_success发布成功事件、auth_failed审核不通过事件。每一行要写清楚触发时机、上报字段、所属业务模块。设计埋点数据的时机在研发排期前就定下来否则后续做任何一个策略专项都会因数据缺失而补工这是短视频产品最常见的版本延期元凶。5.5 审核误杀正常内容申诉无人管创作者直接弃用现象创作者提交的正常内容被审核误判为违规内容下架但创作者看不到原因后台申诉提交两三天后没有任何反馈创作者因此投诉甚至弃用。原因是审核链路只设计到了“拦截”没有闭环到“召回”拦截信息只停留在审核后台的日志表里连用户前端都查不到。解决PRD里要求给审核状态机补充一个“申诉中”的节点。用户提交申诉后状态从“审核不通过”切到“申诉中”不再显示违规提示申诉单进入人工复审队列团队承诺两小时内响应。人工复审时可以调取机器审核时保存的置信度理由片段比如被判定命中的违规标签和对应的截图帧有效减少重复误判。普通短视频产品的新手期审核误伤比例控制在2%以内是可以做到的但前提是运营后台要能看到拦截作品回到复审的全过程而不是只能按一个“下架”按钮。6. 进阶用法拿一套可量化指标清单验收这份PRD到底写得够不够一份PRD真正的检验不在评审会而在版本上线后的第一周。这个阶段我不建议团队急于看DAU优先看的是四个链路是否都健康。推荐链路盯两个数反馈速度是否在可接受范围以及新内容分发占比是否接近10%。其中一个关键数字是首页推荐流的C位是不是被同一个用户反复创作的内容连续占据如果是则代表保护池没有生效。发布链路主要看上传失败率和转码滞留时长。无线网不稳定断点续传没有做好失败率就很难压进2%以内转码滞留的P50如果超过60秒用户的发布体验就会显著恶化。互动链路关注点赞评论写入成功率要求达到99.9%以上如果写入要同时控制计数和脏数据扩展时会遇到瓶颈。审核链路看两个数人工复审队列积压量不要超过1小时可承受量以及申诉在两小时内的完结率这两个数据决定了创作者对平台的信任度。验证链路核心指标健康阈值推荐健康度起播率、新内容曝光占比起播率大于85%新内容占比10%-20%发布链路上传失败率、转码P50失败率低于2%转码P50低于60秒互动链路点赞评论成功率成功率99.9%以上审核链路复审积压、申诉反馈时效积压小于1小时申诉反馈小于2小时我有两个习惯沉淀到今天还在用第一凡是PRD里涉及策略的条目都会把开关和参数集成到后台配置界面上线上跑一周观察再固化成默认值第二每次评审前都用这套验收清单反向检查自己的章节有没有写到位。这两个习惯让很多早期写错的需求有了后悔药也算是我做过短视频以来最保值的经验了。希望帮到你。本文还有配套的精品资源点击获取
