简介这是一份围绕抖音短视频App撰写的完整产品需求文档PRD适用于产品经理、交互设计师和产品新人作为写作范式与功能设计参考。资源包内为单个PDF文件大小3.16MB方便直接阅读或导入笔记工具。文档开篇为文档属性随后从产品简介、目标用户、需求总结、产品结构、产品功能结构图、产品信息架构图、全局说明等模块入手拆解了登录页面、网络环境、键盘输入、评论框、分享框的具体交互并给出前端登录/观看/拍摄上传流程、后台视频推荐机制以及首页推荐页、附近页面的逻辑图。其中特别细化了手机验证码、第三方授权、手机密码三种登录方式的规则如验证码倒计时、手机号位数限制、未登录状态触发跳转登录等对视频播放区的点击暂停/滑动切换、互动功能区的点赞评论分享权限也做了明确说明可作为撰写同类短视频产品PRD的参考蓝本。该资源已有190人学习浏览适合需要快速理解抖音产品页面结构或产出竞品分析文档的读者。1. 「产品需求文档抖音短视频.pdf」是什么一份需求契约不是产品愿景「产品需求文档抖音短视频.pdf」这个文件躺在项目群里时它代表的不是一段产品想法而是整个短视频项目开工前唯一的需求契约。产品经理把它交出去研发要看清楚系统要实现哪些行为测试要能从中列出用例设计要能找到交互边界运营要能理解后台规则。问题在于很多 PRD 花了大篇幅描述界面长什么样却说不清一个按钮按下后系统该做什么、失败时该怎么办。这份笔记按我写短视频产品需求文档的固定路数从拆解功能边界到搭建需求骨架再把交互异常流、数据指标与验收口径、版本管理串起来讲清楚怎么把「做一个短视频产品」变成一份能直接评审、能照着开发、能用于验收的 PDF。适合刚接短视频项目、正在写需求或者马上要主持评审的人。2. 拆需求边界先把抖音短视频拆成目录再动手写 PRD我拿到这个标题时的第一反应不是打开文档编辑器而是先做一次需求拆解。因为 PRD 最怕的就是想到哪写到哪最后交付的功能和产品对不上。拆解的素材不需要什么内部资料客户端公开版本、运营策略和常见竞品结构足够支撑一份需求框架。2.1 PRD 的四类读者研发在读约束测试在读条件一份 PRD 发出去至少有四种人用不同方式读它。研发寻找的是模块边界、接口约定和数据字段他们不会有耐心读完十页产品愿景测试逐条找可执行用例每个描述都要翻译成「前置条件 操作 预期结果」设计关注中间态与异常态是否合理比如加载、空状态、权限拒绝运营关注后台配置入口和审核规则。这决定了 PRD 的组织方式按功能模块组织而不是按页面组织。因为同一个页面往往承载多个模块按页面写会让跨模块引用变得很痛苦。我一般把页面当成功能的容器在需求描述里标注「所在页面 首页」而不是把首页单独开一章。这样做还有一个好处当短视频信息流首页同时包含推荐流、搜索入口、消息入口时每个功能可以独立迭代评审时只挑变更的模块看不用整篇重读。2.2 把公开的产品结构拆成功能清单一张表完成初版目录拆解分三步。第一步遍历客户端主 Tab 与核心页面写下模块名称。第二步给每个模块补三个字段用户价值、依赖的数据、主要风险。第三步标注优先级形成下面这样的初版目录。这张表写完后PRD 的章节顺序基本就定了。模块子模块核心逻辑优先级对应 PRD 章节视频信息流推荐流上下滑切换、预加载、上滑加载下一条P03.2视频播放播放器自动播放、暂停、续播、清晰度切换P03.3拍摄发布拍摄相机/相册权限、拍摄时长、发布流程P03.3互动点赞评论点赞、评论列表、用户P13.2搜索关键词搜索综合搜索、热搜词、搜索联想P13.2消息通知通知列表互动通知、私信P23.2个人主页作品与资料作品列表、粉丝、关注P13.4内容审核发布审核后台配置、机审 人审P13.4优先级不是拍脑袋是项目资源和核心路径倒推出来的。首版如果只有 3 个前端和 2 个后端P0 也只能放信息流、播放、拍摄与发布其余全部往后排。拆解的意义是让取舍有依据而不是让 P0 越长越好。拆解关注的不是界面长什么样而是每个模块给用户提供什么价值、依赖哪些数据字段、有什么风险。2.3 功能矩阵表每一行都是一个可评审的需求模块清单出来后继续往下拆一层得到功能矩阵。矩阵是 PRD 的最小需求单位每行一个功能点包含用户动作、系统响应和优先级。矩阵编号功能点用户动作系统响应优先级F-01下拉加载刷新首页下拉重新请求推荐列表并替换前 N 条P1F-02上滑切换视频上滑暂停当前播放、播放下一条并预加载第三条P0F-03点赞双击画面更新计数、动画、触发埋点P0F-04分享点击分享按钮拉起分享面板结果回传P1F-05发布完成点击发布上传视频、显示审核状态、进入个人页P0这张矩阵直接决定工作拆分。后端按「用户动作 系统响应」拆接口前端按「页面 交互」排任务测试按「优先级 异常流」写用例。每个功能点在矩阵里只有一行但在正文里会展开成需求描述、异常流、埋点与验收四部分。矩阵写完后检查一件事把 P0 功能从头到尾走一遍主流程如果某一步走不通说明矩阵缺行。这一步做扎实后面每一章只是往里填内容。3. 从标题到正文PRD 的骨架模块与各章节写法目录和矩阵就位后PRD 正文不能凭感觉自由发挥。我习惯每一版正文都按同一个套路排先给背景与名词解释再按功能模块给出需求表、交互异常流、埋点与权限。套路重复不丢人丢人的是每个模块写得都不一样评审时研发找不到对应条款。3.1 头部信息与名词解释先堵住版本和口径的坑每个 PRD 文件头必须有一张信息表。团队里最不缺的就是那种文件名一样、内容完全不同的文档「产品需求文档抖音短视频.pdf」如果不带版本号发出去第二天就分不清谁是最新版。文件内第一页放这张表字段填写示例说明文件编号PRD-Douyin-2024-001团队内唯一编号版本V1.2每次修改递增修改日期2024-05-12和修订记录对应作者PM-xx问题联系人评审人Dev-xx / QA-xx / UI-xx写明谁看过哪一版关联文档设计稿链接、接口文档链接防止到处找资源文件名建议用「产品-模块-版本-日期」的格式同名 PDF 覆盖是团队协作最常见的灾难。有了版本号至少能分辨哪份是最新。标题「产品需求文档抖音短视频.pdf」作为归档名没问题但团队内流转时建议在文件属性中写入修订历史或者直接在第一屏放修订记录表。名词解释紧随信息表。短视频行业的指标名词没有统一标准同一个「完播率」在不同团队有完全不同口径。PRD 里第一次出现的指标词必须在名词解释里定义。下面这张表可以直接抄进你的文档名词定义完播播放进度达到视频总时长的 95%有效播放播放时长 ≥ 2 秒且无拖动行为VV一次有效播放计数DAU自然日内启动 App 且有活跃行为的用户数研发不会因为你写得细而烦躁会因为你让他猜而烦躁。名词解释就是用来堵住「我以为」的。3.2 功能需求正文用一行式表格替代八股文功能需求表是 PRD 的主体。一个需求一行不要写成长篇小说。表头固定为需求编号、模块、优先级、需求描述、验收口径。需求编号模块优先级需求描述验收口径FR-01推荐流P0当用户上滑时系统暂停当前视频请求并播放下一条视频同时预加载第三条上滑后 500ms 内出现下一条封面弱网时显示加载态FR-02播放器P0当用户点击暂停时播放器停留当前帧再次点击恢复停止再播放后进度不跳变FR-03点赞P0当用户双击视频内容区时调用点赞接口按钮高亮并计数 1重复双击只产生一次请求需求描述的核心是「状态前置 动作 结果」。「加载速度要快」这句是废话要改成「弱网条件下上滑后 500ms 内显示新视频封面」。研发能执行的是可测的条件与结果。每条再逼自己写一个例外分支比如「视频源不可用时展示重试文案并在 3 秒后自动重试一次」主流程只写一条道走到头的需求评审时必被挑刺。注意需求描述里出现的每个条件都必须可测试。「快」「流畅」「体验好」这类词在评审时会被打回。3.3 交互细节表与异常流矩阵断网、弱网、重复点击都要有答案短视频产品的交互大部分发生在播放器与信息流上交互细节表要把操作、位置、反馈、数据变化写全。操作位置预期反馈状态/数据变化单击暂停/恢复视频画面播放/暂停图标反馈播放状态切换双击点赞视频画面点赞动画、红心浮起点赞数 1埋点上报上滑信息流当前视频停播新视频进入播放播放位置重置下拉首页顶部加载刷新动画列表刷新异常流矩阵是评审最容易吵起来的地方。开发每个人都自带一套「系统默认行为」你不写他就按自己习惯来。常见兜底逻辑场景预期表现兜底逻辑上滑后新视频加载失败显示重试按钮3 秒后自动重试 1 次仍失败提示「网络不给力」播放中网络断开停止缓冲保留当前帧网络恢复自动续播相机权限拒绝提示需要权限引导去设置开启快速连续双击点赞只取最后一次状态前端做防抖服务端做幂等分享到外部 App 后返回回到原播放位置不重置播放进度我一般要求 P0 模块必须列满五个异常场景测试才能正向反向都覆盖。宁可在文档里多写三行控制默认行为也不要在评审现场被集体投票决定。3.4 埋点、权限与兼容性把边界写死发布以后少背锅权限矩阵要写用途和拒绝策略。短视频拍摄产品的相机权限不是隐私协议是功能前提。权限矩阵表权限用途拒绝时策略相机拍摄视频拒绝后展示引导开启页允许继续浏览麦克风录制声音拒绝后可拍无声视频需提示相册上传已有视频拒绝后不能发布不能替换封面定位推荐个性化内容可选拒绝不影响核心功能兼容性部分写最低支持系统版本、屏幕适配范围刘海屏 / 全面屏、弱网与前后台切换。短视频场景前后台切换很关键App 切到后台再回来播放器要恢复原进度而不是重新开始。埋点参数的所有枚举值要写死来源字段只允许「推荐页 / 搜索页 / 个人页 / 外部分享」不允许研发自定义字符串。这类细节写清楚发布以后少背很多锅。4. 数据指标口径与验收标准让 PRD 里的每个需求都能被量化短视频 PRD 最容易暴露的一个问题是数据指标只出现在运营文档里不在需求文档里。没有指标体系的需求验收时只能凭感觉上线后只能靠吵架。产品经理写 PRD 时就把指标定义好数据团队、研发和测试才能在同一套语言里工作。4.1 核心指标口径完播率、人均时长这些词先定公式再谈增长指标不是越多越好。首版短视频产品盯住几个核心指标就够逐个写清口径、公式和备注。下面这张表可以直接作为文档模板指标口径定义公式备注DAU自然日内启动 App 且产生一次有效播放计活跃且播放人数排除仅打开未播放人均观看时长总有效播放时长 / DAU分钟时长口径含循环播放完播率播放进度 ≥ 95% 的次数 / 播放事件次数按视频维度拖动跳过不计为完播互动率每次播放对应的点赞 评论 分享事件数互动事件数 / 有效播放数反映讨论热度口径里最坑的是分母。比如完播率分母到底是「播放事件数」还是「观影人次」分子是「视频播放完」还是「用户看完」统计结果差 30% 很正常。所有指标在名词解释里定义所有公式要写到能直接让算法同学复现。还要写明统计周期按自然日还是按视频发布时间做版本对比时按版本号过滤。否则数据对不上时产品说埋点错、前端说测试环境脏、后端说统计口径不同指标就成了黑匣子。4.2 事件埋点表把每个指标绑定到具体事件与参数指标是结果埋点事件是原始数据。PRD 里必须放一张事件表把每个指标挂到事件名上。埋点表里的字符串就是研发代码里的字符串大小写都要统一。事件名触发时机关键参数上报条件video_play进入播放video_id, source, scene, duration播放开始后立即上报video_play_finish播放完成video_id, play_duration, net_type达到完播阈值video_click_like点赞成功video_id, like_status接口返回成功video_share分享面板确认video_id, share_channel用户点击确认分享video_slide上滑/切换video_id, from_video_id, action每次切换上报参数的值要写枚举或类型不能只写「相关参数」。上报条件要写明是立即上报还是批量补报。去重策略也要写清楚比如同一用户在同一个视频同一会话内重复触发只记一次。我一般要求埋点表放在 PRD 对应功能模块的附录位置评审时逐条过。每个指标至少对应一个事件每个事件的参数里必须能算出对应指标的分子分母。注意埋点事件名一旦发布到线上就不能改名必须改名时另起新事件这条规则直接写进 PRD 的埋点附录。4.3 验收标准把「功能正常」改成「条件 预期结果」验收标准由产品给出测试把它翻译成用例。每一条都要写前置条件、操作步骤、预期结果形成下面这样的表验收编号需求编号前置条件操作步骤预期结果AC-01FR-014G 弱网进入首页上滑 5 次每次都有封面加载不白屏文案可读AC-02FR-02正常网络播放 30 秒后退出再进入从退出前位置续播AC-03FR-03游客账号双击点赞点赞数 1再双击取消数据恢复写验收标准有一个很好用的句式「如果前置条件当操作那么结果」。如果某条验收读都读不通说明需求描述还缺东西。验收表要留到做版本迭代时继续使用每版有新增就追加有过期的就标记废弃这样版本与版本之间的差异能直接对照。5. 避坑PRD 从初稿到评审的 5 条踩坑记录只列骨架不写路径的 PRD基本都要返工。这一章写我实际踩过的坑每一条都是评审现场真实发生过的对话。5.1 把 UI 描述当需求写开发回你一句「这是设计稿不是需求」现象需求表里写「头像在左上角圆形点击进入个人主页」。UI 说这是老版本设计开发说没法估时测试说你没写进入之后展示什么。原因把视觉当需求只写了动作没写结果和边界。PRD 里描述长相的部分应该交给设计稿需求文本要表达系统行为。解决写作模板改为「当用户点击头像时系统跳转至该用户个人主页若用户已注销展示空状态页并提供返回按钮」。PRD 管行为设计稿管长相两者职责分开评审才能对事不对人。5.2 主流程太顺异常流靠猜评审现场只带了主链路现象评审时测试问断网怎么办PM 临时回答「就显示系统默认的吧」这等于把需求决定权交给了运气。还有一次开发问「连点两次点赞是不是要发两次请求」屋里没人答得上来。原因只画了主流程一条道没逐节点追问失败。开发可以现场编测试可以现场补但上线后出问题的是用户。解决给自己立一个规则P0 功能至少列五个失败场景——网络断开、接口超时、权限拒绝、连续点击、后端返回异常状态码。把主流程每一步编号逐个问「如果第 N 步失败呢」异常流很快能补齐。5.3 埋点与指标口径没对齐完播率成了玄学现象上线后完播率异常高排查发现前端在播放进度到达 50% 时就开始上报「播放完成」。数据虚高了整整一倍运营看了一周才发现问题。原因埋点事件表和指标定义在 PRD 里各写各的没有人核对映射关系。前端同学按自己的理解触发上报指标定义和数据采集成了两套逻辑。解决评审时用一张映射表把指标和事件对应起来完播率绑定 video_play_finish参数必须含播放时长。如果前端做不到精确判断约定由后端根据播放心跳计算前端只传进度加一句「以服务端计算为准」就能堵住争议。5.4 截图代替需求描述需求成了一座没人敢动的黑匣子现象需求文档里贴了几十张高保真原型正文却只有一句「参考截图」。开发照着做改版时没人知道为什么这里有个角标也没人敢动它。原因图片承载不了条件分支。同一个位置在登录态、未登录态、无网络态可能有三种显示一张截图讲不清。解决截图只放在「原型参考」一栏需求描述必须能脱离截图独立判断。在表格里写清楚四种状态分别怎么显示默认态、加载态、空态、异常态。截图是辅助文字是依据。这也是给后来人留后悔药。5.5 版本号缺失开发拿旧文档上线团队互相甩锅现象产品更新了需求但 PDF 文件名没变有人从旧链接下载上线后逻辑和验收的不一致。开发说是按文档做的产品说文档已经改了最后发现大家看的是两份不同文档。原因没有修订记录没有版本归档目录文件名一样导致覆盖。PDF 一旦发出去就不能当草稿继续改要改就升版本号这是文档管理的基本纪律。解决文档首屏放修订记录表字段为版本、日期、修改人、变更点、关联需求编号文件名按「产品-模块-V1.2.docx」命名。评审通过后转 PDF 归档PDF 只能看不能改新版发出后旧版移到 archive 目录。6. 评审对照清单与 PDF 输出最后一个能落地的工作流PRD 写完到评审之间我还会固定做两件事把 Markdown 维护的文档导出成 PDF 归档用一张对照清单卡评审。全程用 Markdown 写 PRD 是推荐做法原因是 Git 能对文本做差异对比评审后每一处修改都有据可查而 docx 做差异对比非常痛苦。导出 PDF 用 pandoc 一条命令搞定pandoc prd.md -o prd.pdf \ --pdf-enginexelatex \ -V mainfontNoto Sans CJK SC \ -V geometry:margin2.5cm \ -V numbersectionsxelatex 是处理中文字体的 PDF 引擎mainfont 指定系统中文字体名macOS 下可换成 PingFang SCgeometry 设置页边距避免 PDF 打印或投屏时内容太贴边numbersections 自动给章节编号省得手工维护序号。评审时用下面这张清单逐项打勾检查项重点通过标准功能矩阵P0 主流程从进入到退出能走完一条完整用户路径交互异常流断网/弱网/权限每个 P0 需求至少 5 个异常场景埋点事件指标映射每个指标都能找到对应的事件与参数验收口径可测性每条验收可朗读为「如果…当…那么…」版本状态最新编号评审人确认手里文档版本号一致我自己的教训是文档写得快不难难的是每次改完都更新版本号。哪怕只是改了一个标点也发一个新版本因为团队里总有人从旧链接下载。需求评审的意义不只是把文档念一遍而是让所有人在同一份最新文档上对齐。如果你正在写这份「产品需求文档抖音短视频.pdf」建议从第二章的拆解表开始而不是直接写正文。把功能矩阵立起来后面每章只是往里填内容评审翻车概率会小很多。希望帮到你。本文还有配套的精品资源点击获取