简介一份系统完整的抖音短视频产品需求文档PRD紧扣UGC短视频社区的产品定位从产品背景、用户画像到需求总结均有详细拆解。文档包含产品功能结构图、信息架构图、全局说明、登录页、网络环境、键盘输入、评论框、分享框并梳理登录注册、观看视频、拍摄/上传视频及后台推荐机制等前后端流程同时覆盖首页推荐、附近页面、视频播放区、互动功能区等页面逻辑与交互细节适合产品经理、产品助理以及短视频产品方向的求职者用来参看完整PRD的写法与思考框架。压缩包内共1个PDF文件大小约3.16MB排版完整便于对照阅读。已有189人学习对需要快速掌握短视频类产品需求分析方法的读者具有一定参考价值。1. 产品需求文档抖音短视频动手前先想清三件事产品需求文档抖音短视频这份标题看起来像一份现成的PDF但真正的问题是你手里没有任何内容却要凭空产出一份能让研发、测试、设计直接开工的文档。我见过太多人接到这个任务后第一件事是截图录屏把抖音每个页面抄一遍最后交出一份「带图标的页面说明」评审时被问一句「为什么这个功能要做、优先级凭什么定P0」就哑火。写PRD不是做产品截图集它解决的核心问题是把「我们要做一个像抖音的产品」翻译成「具体做哪些页面、哪些流程、哪些字段、哪些异常态」。目标读者是研发、测试和设计而不是领导。适合谁产品新人练手、团队要复刻短视频模块、或想系统整理一套可复用的需求文档模板的人。动手之前先把「给谁看、写多细、以什么为准」三件事想清楚。2. 先搭信息架构再列功能清单把抖音拆成可复用的模块2.1 信息架构不是画页面框图而是给每个页面一个「唯一任务」很多人写PRD上来就是「首页有什么、搜索页有什么」逐个页面罗列。这样写出来的文档像一本截图字典开发要翻半天才能找到自己负责的模块。我一般会先做一次信息架构梳理把抖音这类短视频产品拆成五个模块消费、创作、关系、个人、配置。每个模块下的每个页面都只允许有一个「唯一任务」。这个唯一任务决定了页面上放什么元素、不放什么元素。模块核心页面唯一任务关键元素消费推荐流首页让用户在10秒内决定「下一条要不要看」沉浸式播放器、点赞/评论/转发、上下滑手势、负反馈入口消费同城页完成有地理意图的发现城市切换、附近视频聚合、地图入口创作拍摄/发布页用最短路径产出并发布一条视频拍摄按钮、道具/模板、发布页表单关系关注/消息维护作者与粉丝之间的连接关注动态流、私信、评论通知个人个人主页管理账号资产与偏好设置作品列表、收藏、数据看板、设置入口为什么先定信息架构而不是先列功能清单因为功能清单是页面堆出来的一旦页面没有唯一任务功能就会互相打架。比如同城页又想推流又想引导关注又想放广告评审时每个需求方都能从自己的角度加需求最后开发工作量翻倍测试用例也不知道以哪个预期为准。信息架构先定下来等于给所有功能划定了归属地一个功能只能属于一个页面一个页面只能服务一个核心任务。如果你发现某个页面有三个核心任务这个页面就应该拆成三个页面。这里有个判断标准我很常用拿掉这个页面用户的核心诉求还能不能完成。如果只是少了一个入口而不是少了任务说明这个页面不重要如果任务被迫转移到别的页面完成说明任务定位错了。抖音首页把关注流和推荐流放在两个Tab而不是一个页面里就是不想让「看关注的人」和「刷推荐」互相干扰。写PRD时把这个逻辑写清楚评审就能少吵一半。2.2 用三类用户故事反推功能点而不是对着竞品截图抄确定信息架构后下一步是反推功能点。常见的偷懒做法是拿抖音现成界面把每个按钮抄成一张功能列表加号、红点、私信、商城……抄完一看什么都想写什么都不深。我习惯先写用户故事从角色出发倒推功能边界。短视频产品至少覆盖三类角色。浏览型用户通勤时打开App目的是消磨五分钟。核心痛点是刷到重复内容、连续几条不感兴趣、画质差卡顿。创作者发完一条视频后想快速知道反馈。核心痛点是无法判断作品为什么没流量、评论负面时不知道该不该回应。互动型用户刷到喜欢的人想关注、看到不当评论想屏蔽举报。核心痛点是操作路径太长会放弃举报后不知道结果。把用户故事转成功能点时每个功能点要能回答三件事输入是什么、处理是什么、输出是什么。以「举报」为例输入是用户点击视频卡片更多按钮处理是弹出举报类型选择页并收集附带信息输出是提交成功状态并能在48小时内收到处理结果。用这种「输入-处理-输出」的方式描述开发才能评估接口和页面改动量测试才知道准备哪些用例。同时功能点一定要标优先级。这里不讨论P0/P1/P2如何定义只说一个实操原则核心路径上的功能才是P0。比如发布成功后立即在个人主页可见属于P0发布成功后显示「作品推广」入口属于P1发布时支持定时发布属于P2。很多PRD把优先级写成「全部都是P0」就等于没有优先级。研发排期时先做P0P2砍掉不影响上线。抖音的PRD同样遵循这个逻辑首版只保发布、推荐、互动三条主路径直播、商城、小程序都是后续版本的事。2.3 需求条目的最小模板编号、描述、验收标准缺一不可信息架构和功能清单都有了接下来把每个功能点写成需求条目。我见过太多PRD里只有一个「标题」加一句「与抖音保持一致」。这句话等于把决定权踢给开发开发按自己理解做完测试也不知道用哪条预期验收最后评审时的口头解释全都变成开发成本。一个需求条目的最小模板应该包含五列。要素内容示例需求编号FEED-001需求标题推荐流视频卡片展示互动数据需求描述用户每次下滑获得新视频卡片时卡片右下角展示点赞数、评论数。数字展示规则超过10000时按「x.x万」折显示不足10000显示完整数字优先级P0验收标准1. 数据与接口返回一致2. 超过10000按「x.x万」格式展示3. 接口无数据时展示「--」不允许出现空白或空指针崩溃需求编号要按模块前缀区分比如消费模块FEED、发布模块PUB、账号模块USR。编号一旦定了就不要改后续变更靠追加版本记录而不是重编号。需求描述要写清楚「在什么条件下、做什么事、输出什么结果」不需要写实现方式但要把边界写死。验收标准尽可能用「可量化」的描述代替「可以正常使用」这种话。比如「举报类型选择页提供6种举报原因」就比「举报原因要完整」好测试。提示需求条目是要进研发排期的不是写给领导看的功能愿景。每个条目写完问自己一句话测试看到这条验收标准能不能直接写出测试用例如果写不出来说明条目还停留在「想法」层面。3. 把核心路径写成需求条目账号、发布、推荐流3.1 注册登录与权限授权把「授权弹窗」写成有状态的流程账号体系是短视频产品的根基没有登录态点赞、评论、关注、创作全都无法落地。注册登录的PRD部分最常见的错误是只写「支持手机号登录」和「支持第三方授权登录」然后就没下文了。这会导致开发不知道验证码有效期多久、不知道登录过期怎么办、不知道第三方授权取消时怎么提示。我一般会把注册登录拆成三个独立的流程条目。第一个是手机号注册登录流程输入手机号 → 获取验证码 → 输入验证码 → 登录成功。这里必须定义验证码的有效期和重新获取间隔。参考值是验证码有效期5分钟60秒内不可重新获取同一手机号每日最多获取10次。第二个是第三方授权登录流程点击微信图标 → 拉起第三方授权 → 授权成功回调 → 绑定手机号或直接登录。这里要写清楚「授权取消」的处理返回登录页并提示「你取消了授权」而不是无响应。第三个是登录态过期处理接口返回401后App弹出重新登录页同时保存未提交的发布草稿避免用户登录后丢失内容。权限授权是另一个必写项尤其是相机和麦克风权限。没有相机权限拍摄页就不能用抖音的常用策略是点击底部加号时同时请求相机和麦克风权限如果用户拒绝不直接退出而是展示一个引导弹窗说明「拍摄视频需要相机权限」并提供「去设置开启」按钮。跳转系统设置后返回App要再次判断权限状态而不是默认用户已经开启。这里需要写一个权限状态表。权限场景触发时机拒绝后的处理相机权限点击底部加号进入拍摄器弹窗提示「拍摄需要相机权限」提供去设置入口麦克风权限点击底部加号进入拍摄器与相机权限一起请求拒绝后录制静音视频但提示「无麦克风权限录制将静音」相册权限点击相册导入按钮拒绝后展示空相册页提供去设置开启入口定位权限进入同城页拒绝后展示「点击选择城市」允许用户手动选择权限需求最容易漏的是「拒绝后再触发」的行为。用户第一次拒绝后下次再点加号弹窗策略是直接跳系统设置还是继续弹App内弹窗我的建议是第一次拒绝后继续弹App内引导窗如果第二次拒绝则后续统一跳转系统设置页不再弹App内窗避免频繁打扰。PRD里把这条写清楚测试就能顺着用户操作路径跑一遍而不是只测一次。3.2 拍摄发布链路从「点加号」到「审核通过」的六个状态拍摄发布是短视频App最重的链路也是PRD里最容易写得乱的部分。乱的原因是这条链路涉及多个页面和多个状态如果没有按状态拆条目开发会漏逻辑。我把发布链路拆成六个状态拍摄初始化、录制导入、效果编辑、发布页填写、上传中、审核反馈。每个状态对应一个需求条目组。拍摄初始化要写清楚点击加号后进入拍摄器默认后置摄像头、默认正常速度、默认开启闪光灯自动模式。录制导入要写清楚最短录制1秒、最长录制15分钟拍摄时长不足1秒时不允许进入下一步支持分段录制每段之间无缝拼接。效果编辑要写清楚滤镜、美颜、道具、配乐的入口位置和可调整参数范围配乐支持搜索和试听。这部分的细节不一定要全部复刻抖音但每条写出来都能让开发直接开工。发布页字段是需求描述的重点我用下面的表格定义字段清单。字段是否必填交互要求标题非必填最多55个字符超出后不响应键盘输入话题非必填支持多个话题最多5个位置非必填默认不显示点击后基于定位展示附近位置列表可见范围必填默认「公开」可选「好友可见」「私密」发布后修改需重新确认同步至第三方非必填开关默认关闭打开后展示授权登录第三方页面发布时间线要明确点击「发布」按钮后视频进入上传队列App右上角显示上传进度条上传过程中退出App重新进入后自动恢复上传上传失败时展示重试按钮重试三次仍失败则保存草稿并提示。上传完成后视频进入审核状态审核通过前视频仅自己可见审核通过后公开展示。审核驳回时要通知用户并告知驳回原因类型内容违规、版权问题、重复发布。有些PRD把「审核中可见性」漏了最后上线时内容审核没通过用户来骂运营很被动。3.3 推荐流页面PRD不写算法写展示与兜底规则推荐流是短视频产品的核心消费页。很多新手写这一块时会写「系统根据用户兴趣推荐视频」这种话然后开发就懵了系统是什么兴趣怎么定义推荐结果是什么形式PRD里不应该出现算法实现方案算法是算法工程师的事PRD只需要写清楚客户端的表现规则和异常处理。推荐流页面的第一组需求条目是交互规则首页进入后默认自动播放第一条视频用户上滑切换下一条视频加载中显示居中loading下划回到上一条恢复上次播放位置播放完成后自动循环播放一半以上用户操作发生在无WiFi环境所以默认非WiFi下播放720PWiFi下播放1080P同时提供「画质选择」入口。第二组需求条目是数据展示视频卡片展示作者昵称、视频描述、话题标签、点赞数、评论数、分享数。超过10000的数字按「x.x万」折叠展示低于10000展示完整数字。第三组需求条目是异常态。推荐流是最容易出线上事故的页面因为网络不稳定时会有各种表现。PRD里至少写四个异常态网络断开时展示「网络不给力」全屏提示并提供一个「点我重试」按钮视频加载失败时播放器区域展示失败图标点击后重新加载重试三次仍失败则跳过该条并加载下一条接口拉取新数据失败时保留当前列表数据并展示一条轻提示「刷新失败请稍后再试」上拉翻页到达底部时展示正在加载动画连续翻页10次无新数据则视为「到底了」展示「没有更多了」。页面状态触发条件展示表现加载中冷启动进入推荐流居中loading动画保持底部Tab可点击加载失败接口无返回或网络断连全屏错误提示提供重试按钮空数据接口返回空列表展示「暂无推荐去关注你感兴趣的人吧」附推荐关注卡片到顶/到底上滑到第一条或下拉到底到顶时展示「已经是最新了」到底时展示「没有更多了」未成年模式当前账号开启未成年保护不展示直播、商城、同城入口推荐频率限制推荐流的另一个坑是「重复内容」。用户连续刷到同一条视频会强烈反感。PRD里不写「算法层面去重」而是写表现层定义同一账号发布的同一条视频在24小时内不重复出现在当前用户的推荐流中不同账号发布的相同素材比如同一段音乐同一套模板允许出现但连续不超过2条。这个标准不完美但它是一个可测试的定义。测试能构造数据验证开发能按规则实现比「智能去重」四个字实用得多。4. 避坑自查写抖音类需求文档最常见的五个翻车点4.1 举报与审核只写了入口没写状态流转现象开发按PRD做完了举报功能用户提交举报后完全不知道后续进展测试追问「审核驳回后用户的作品还在吗」研发和产品面面相觑。原因PRD里只写了「用户可举报」「内容会审核」把状态流转留给了开发自行发挥结果不同端实现不一致。解决在PRD里写一个最小状态机「举报已提交 → 审核中 → 举报成立/举报不成立」。举报成立后对被举报内容做隐藏处理被举报作者收到系统通知展示「作品因审核未通过已移除」并保留48小时申诉入口。审核不成立时用户收到「举报未通过」通知不展示举报人信息。4.2 把「推荐去重」当成一句愿景现象需求评审会上你说「推荐流要智能去重」开发回你「怎么算重做不了」到了测试阶段测试构造了两条同音乐同画面的视频你发现产品行为完全取决于开发心情。原因需求描述停留在用户诉求层面没有落到可执行规则。解决把去重规则写成可验证的表现层定义——同一视频24小时内不重复推荐连续出现的视频中相同封面模板不超过2条用户明确点「不感兴趣」的博主30天内不再出现在推荐流中。每条规则独立编号作为推荐流需求条目的一个验收标准。4.3 数据敏感操作没有联动处理现象用户删除了一条作品但搜索结果页还能看到缓存用户把账号设为「私密」之前公开过的作品仍然能通过链接访问。原因PRD里只做了「删除作品」「设置私密」两个独立需求没有写数据联动。解决每个影响可见性的操作都要在PRD里写一个「联动影响范围」段落。删除作品时同步隐藏推荐流、搜索、关注Tab中的该条内容私密账号开启时所有作品设为「仅自己可见」关闭私密后恢复原可见范围注销账号时要提示「作品和粉丝关系将无法恢复」并给出7天冷静期。这类需求不写上线后就是声明的数据安全风险。4.4 游客态和半登录状态被当成不存在的场景现象测试用「未登录状态」跑核心路径进入首页推荐流没问题但一点赞就跳登录页登录完了又跳回首页顶部用户观看进度丢了。原因PRD默认用户是已登录状态把游客态当作异常态顺带处理。解决新增一个「游客态」角色和已登录态并列写需求。游客态允许浏览推荐流和同城页点赞/评论/关注时弹出登录引导页登录成功后回到原视频位置并保留点赞意图播放进度不丢失游客态不展示个人主页、不展示私信入口。这条加在需求文档开头或账号章节提醒每一个后续需求都要在两种状态下分别验收。4.5 版本兼容与灰度发布要求缺失现象新版发布页新增了「定时发布」字段但线上老版本App还停留旧接口老用户提交作品时新字段为空后端直接把这条数据写成了异常状态导致审核流程卡住。原因需求描述里没有注明版本兼容和灰度范围开发默认所有用户同步升级。解决在重点需求条目末尾增加「兼容要求」一行——定时发布字段由客户端在上传时传入老版本客户端不传该字段后端赋默认值「立即发布」不允许因字段缺失而拒绝写入涉及支付、分享、账号迁移等高影响需求PRD里明确灰度计划比如「新用户全量开启老用户按3%比例灰度观察24小时后再放开」。注意踩坑记录不是写在文档末尾的附录而是写在每个需求条目旁边。开发写代码时看到「兼容要求」四个字就会条件反射地考虑老版本行为比评审会上口头强调十遍都有用。5. 用需求追踪矩阵收尾让评审和排期彻底对齐5.1 一张矩阵表管到上线PRD写完之后最后一步不是发给研发排期而是整理一份需求追踪矩阵。矩阵表的目的是让每个人都能一眼看清需求条目对应哪个开发任务、哪条测试用例、当前处于什么状态。我一般会在PRD定稿后的当天建这张表而不是等到开发完成再补因为评审时的变更记录也要靠它管理。需求编号功能模块对应开发任务对应测试用例当前状态USR-001手机号验证码登录开发登录接口与短信验证码TC-USR-001 验证码有效期TC-USR-002 验证码错误重试开发中USR-002第三方授权登录开发微信授权回调与账号绑定TC-USR-003 授权取消返回登录页待开发PUB-001发布页字段开发发布表单与字段校验TC-PUB-001 标题超长限制TC-PUB-002 发布失败重试已提测FEED-001推荐流互动数据开发推荐流卡片数据展示TC-FEED-001 数字过万折叠TC-FEED-002 接口无数据展示兜底已通过FEED-005推荐流去重规则开发去重过滤逻辑TC-FEED-005 同视频24小时不重复出现开发中矩阵表要随时更新尤其是研发排期变化和测试用例调整的时候。一个需求条目改动了验收标准对应测试用例必须同步改测试跑出一个新缺陷状态栏就要从「已通过」改回「复核中」。这张表不光是给项目经理看的也是给你自己留的后路。上线后如果有人问「为什么这个功能没有实现」你可以直接翻出矩阵表看那条需求的测试用例和开发任务是不是还停留在「待开发」状态而不是凭记忆解释。我最早写的PRD都不做矩阵那时以为自己把需求条目写清楚了就万事大吉。后来一次上线后发现「作品删除但搜索结果还可见」追到源头是删除功能的测试用例没有覆盖搜索列表而我在评审时也没发现这个遗漏。从那以后每份PRD定稿时我都会顺手建一张矩阵把「需求条目」「开发任务」「测试用例」三条线绑在一起。评审判定需求完整性时就问一个问题矩阵里有没有一条需求没有对应开发任务有没有一个开发任务没有对应测试用例两个问题能问住一定还有漏网需求。希望这些流程能帮你少走点弯路写出一份评审能过、开发能估、测试能跑的落地文档。本文还有配套的精品资源点击获取 短视频PRD落地指南：从信息架构到需求追踪矩阵
简介一份系统完整的抖音短视频产品需求文档PRD紧扣UGC短视频社区的产品定位从产品背景、用户画像到需求总结均有详细拆解。文档包含产品功能结构图、信息架构图、全局说明、登录页、网络环境、键盘输入、评论框、分享框并梳理登录注册、观看视频、拍摄/上传视频及后台推荐机制等前后端流程同时覆盖首页推荐、附近页面、视频播放区、互动功能区等页面逻辑与交互细节适合产品经理、产品助理以及短视频产品方向的求职者用来参看完整PRD的写法与思考框架。压缩包内共1个PDF文件大小约3.16MB排版完整便于对照阅读。已有189人学习对需要快速掌握短视频类产品需求分析方法的读者具有一定参考价值。1. 产品需求文档抖音短视频动手前先想清三件事产品需求文档抖音短视频这份标题看起来像一份现成的PDF但真正的问题是你手里没有任何内容却要凭空产出一份能让研发、测试、设计直接开工的文档。我见过太多人接到这个任务后第一件事是截图录屏把抖音每个页面抄一遍最后交出一份「带图标的页面说明」评审时被问一句「为什么这个功能要做、优先级凭什么定P0」就哑火。写PRD不是做产品截图集它解决的核心问题是把「我们要做一个像抖音的产品」翻译成「具体做哪些页面、哪些流程、哪些字段、哪些异常态」。目标读者是研发、测试和设计而不是领导。适合谁产品新人练手、团队要复刻短视频模块、或想系统整理一套可复用的需求文档模板的人。动手之前先把「给谁看、写多细、以什么为准」三件事想清楚。2. 先搭信息架构再列功能清单把抖音拆成可复用的模块2.1 信息架构不是画页面框图而是给每个页面一个「唯一任务」很多人写PRD上来就是「首页有什么、搜索页有什么」逐个页面罗列。这样写出来的文档像一本截图字典开发要翻半天才能找到自己负责的模块。我一般会先做一次信息架构梳理把抖音这类短视频产品拆成五个模块消费、创作、关系、个人、配置。每个模块下的每个页面都只允许有一个「唯一任务」。这个唯一任务决定了页面上放什么元素、不放什么元素。模块核心页面唯一任务关键元素消费推荐流首页让用户在10秒内决定「下一条要不要看」沉浸式播放器、点赞/评论/转发、上下滑手势、负反馈入口消费同城页完成有地理意图的发现城市切换、附近视频聚合、地图入口创作拍摄/发布页用最短路径产出并发布一条视频拍摄按钮、道具/模板、发布页表单关系关注/消息维护作者与粉丝之间的连接关注动态流、私信、评论通知个人个人主页管理账号资产与偏好设置作品列表、收藏、数据看板、设置入口为什么先定信息架构而不是先列功能清单因为功能清单是页面堆出来的一旦页面没有唯一任务功能就会互相打架。比如同城页又想推流又想引导关注又想放广告评审时每个需求方都能从自己的角度加需求最后开发工作量翻倍测试用例也不知道以哪个预期为准。信息架构先定下来等于给所有功能划定了归属地一个功能只能属于一个页面一个页面只能服务一个核心任务。如果你发现某个页面有三个核心任务这个页面就应该拆成三个页面。这里有个判断标准我很常用拿掉这个页面用户的核心诉求还能不能完成。如果只是少了一个入口而不是少了任务说明这个页面不重要如果任务被迫转移到别的页面完成说明任务定位错了。抖音首页把关注流和推荐流放在两个Tab而不是一个页面里就是不想让「看关注的人」和「刷推荐」互相干扰。写PRD时把这个逻辑写清楚评审就能少吵一半。2.2 用三类用户故事反推功能点而不是对着竞品截图抄确定信息架构后下一步是反推功能点。常见的偷懒做法是拿抖音现成界面把每个按钮抄成一张功能列表加号、红点、私信、商城……抄完一看什么都想写什么都不深。我习惯先写用户故事从角色出发倒推功能边界。短视频产品至少覆盖三类角色。浏览型用户通勤时打开App目的是消磨五分钟。核心痛点是刷到重复内容、连续几条不感兴趣、画质差卡顿。创作者发完一条视频后想快速知道反馈。核心痛点是无法判断作品为什么没流量、评论负面时不知道该不该回应。互动型用户刷到喜欢的人想关注、看到不当评论想屏蔽举报。核心痛点是操作路径太长会放弃举报后不知道结果。把用户故事转成功能点时每个功能点要能回答三件事输入是什么、处理是什么、输出是什么。以「举报」为例输入是用户点击视频卡片更多按钮处理是弹出举报类型选择页并收集附带信息输出是提交成功状态并能在48小时内收到处理结果。用这种「输入-处理-输出」的方式描述开发才能评估接口和页面改动量测试才知道准备哪些用例。同时功能点一定要标优先级。这里不讨论P0/P1/P2如何定义只说一个实操原则核心路径上的功能才是P0。比如发布成功后立即在个人主页可见属于P0发布成功后显示「作品推广」入口属于P1发布时支持定时发布属于P2。很多PRD把优先级写成「全部都是P0」就等于没有优先级。研发排期时先做P0P2砍掉不影响上线。抖音的PRD同样遵循这个逻辑首版只保发布、推荐、互动三条主路径直播、商城、小程序都是后续版本的事。2.3 需求条目的最小模板编号、描述、验收标准缺一不可信息架构和功能清单都有了接下来把每个功能点写成需求条目。我见过太多PRD里只有一个「标题」加一句「与抖音保持一致」。这句话等于把决定权踢给开发开发按自己理解做完测试也不知道用哪条预期验收最后评审时的口头解释全都变成开发成本。一个需求条目的最小模板应该包含五列。要素内容示例需求编号FEED-001需求标题推荐流视频卡片展示互动数据需求描述用户每次下滑获得新视频卡片时卡片右下角展示点赞数、评论数。数字展示规则超过10000时按「x.x万」折显示不足10000显示完整数字优先级P0验收标准1. 数据与接口返回一致2. 超过10000按「x.x万」格式展示3. 接口无数据时展示「--」不允许出现空白或空指针崩溃需求编号要按模块前缀区分比如消费模块FEED、发布模块PUB、账号模块USR。编号一旦定了就不要改后续变更靠追加版本记录而不是重编号。需求描述要写清楚「在什么条件下、做什么事、输出什么结果」不需要写实现方式但要把边界写死。验收标准尽可能用「可量化」的描述代替「可以正常使用」这种话。比如「举报类型选择页提供6种举报原因」就比「举报原因要完整」好测试。提示需求条目是要进研发排期的不是写给领导看的功能愿景。每个条目写完问自己一句话测试看到这条验收标准能不能直接写出测试用例如果写不出来说明条目还停留在「想法」层面。3. 把核心路径写成需求条目账号、发布、推荐流3.1 注册登录与权限授权把「授权弹窗」写成有状态的流程账号体系是短视频产品的根基没有登录态点赞、评论、关注、创作全都无法落地。注册登录的PRD部分最常见的错误是只写「支持手机号登录」和「支持第三方授权登录」然后就没下文了。这会导致开发不知道验证码有效期多久、不知道登录过期怎么办、不知道第三方授权取消时怎么提示。我一般会把注册登录拆成三个独立的流程条目。第一个是手机号注册登录流程输入手机号 → 获取验证码 → 输入验证码 → 登录成功。这里必须定义验证码的有效期和重新获取间隔。参考值是验证码有效期5分钟60秒内不可重新获取同一手机号每日最多获取10次。第二个是第三方授权登录流程点击微信图标 → 拉起第三方授权 → 授权成功回调 → 绑定手机号或直接登录。这里要写清楚「授权取消」的处理返回登录页并提示「你取消了授权」而不是无响应。第三个是登录态过期处理接口返回401后App弹出重新登录页同时保存未提交的发布草稿避免用户登录后丢失内容。权限授权是另一个必写项尤其是相机和麦克风权限。没有相机权限拍摄页就不能用抖音的常用策略是点击底部加号时同时请求相机和麦克风权限如果用户拒绝不直接退出而是展示一个引导弹窗说明「拍摄视频需要相机权限」并提供「去设置开启」按钮。跳转系统设置后返回App要再次判断权限状态而不是默认用户已经开启。这里需要写一个权限状态表。权限场景触发时机拒绝后的处理相机权限点击底部加号进入拍摄器弹窗提示「拍摄需要相机权限」提供去设置入口麦克风权限点击底部加号进入拍摄器与相机权限一起请求拒绝后录制静音视频但提示「无麦克风权限录制将静音」相册权限点击相册导入按钮拒绝后展示空相册页提供去设置开启入口定位权限进入同城页拒绝后展示「点击选择城市」允许用户手动选择权限需求最容易漏的是「拒绝后再触发」的行为。用户第一次拒绝后下次再点加号弹窗策略是直接跳系统设置还是继续弹App内弹窗我的建议是第一次拒绝后继续弹App内引导窗如果第二次拒绝则后续统一跳转系统设置页不再弹App内窗避免频繁打扰。PRD里把这条写清楚测试就能顺着用户操作路径跑一遍而不是只测一次。3.2 拍摄发布链路从「点加号」到「审核通过」的六个状态拍摄发布是短视频App最重的链路也是PRD里最容易写得乱的部分。乱的原因是这条链路涉及多个页面和多个状态如果没有按状态拆条目开发会漏逻辑。我把发布链路拆成六个状态拍摄初始化、录制导入、效果编辑、发布页填写、上传中、审核反馈。每个状态对应一个需求条目组。拍摄初始化要写清楚点击加号后进入拍摄器默认后置摄像头、默认正常速度、默认开启闪光灯自动模式。录制导入要写清楚最短录制1秒、最长录制15分钟拍摄时长不足1秒时不允许进入下一步支持分段录制每段之间无缝拼接。效果编辑要写清楚滤镜、美颜、道具、配乐的入口位置和可调整参数范围配乐支持搜索和试听。这部分的细节不一定要全部复刻抖音但每条写出来都能让开发直接开工。发布页字段是需求描述的重点我用下面的表格定义字段清单。字段是否必填交互要求标题非必填最多55个字符超出后不响应键盘输入话题非必填支持多个话题最多5个位置非必填默认不显示点击后基于定位展示附近位置列表可见范围必填默认「公开」可选「好友可见」「私密」发布后修改需重新确认同步至第三方非必填开关默认关闭打开后展示授权登录第三方页面发布时间线要明确点击「发布」按钮后视频进入上传队列App右上角显示上传进度条上传过程中退出App重新进入后自动恢复上传上传失败时展示重试按钮重试三次仍失败则保存草稿并提示。上传完成后视频进入审核状态审核通过前视频仅自己可见审核通过后公开展示。审核驳回时要通知用户并告知驳回原因类型内容违规、版权问题、重复发布。有些PRD把「审核中可见性」漏了最后上线时内容审核没通过用户来骂运营很被动。3.3 推荐流页面PRD不写算法写展示与兜底规则推荐流是短视频产品的核心消费页。很多新手写这一块时会写「系统根据用户兴趣推荐视频」这种话然后开发就懵了系统是什么兴趣怎么定义推荐结果是什么形式PRD里不应该出现算法实现方案算法是算法工程师的事PRD只需要写清楚客户端的表现规则和异常处理。推荐流页面的第一组需求条目是交互规则首页进入后默认自动播放第一条视频用户上滑切换下一条视频加载中显示居中loading下划回到上一条恢复上次播放位置播放完成后自动循环播放一半以上用户操作发生在无WiFi环境所以默认非WiFi下播放720PWiFi下播放1080P同时提供「画质选择」入口。第二组需求条目是数据展示视频卡片展示作者昵称、视频描述、话题标签、点赞数、评论数、分享数。超过10000的数字按「x.x万」折叠展示低于10000展示完整数字。第三组需求条目是异常态。推荐流是最容易出线上事故的页面因为网络不稳定时会有各种表现。PRD里至少写四个异常态网络断开时展示「网络不给力」全屏提示并提供一个「点我重试」按钮视频加载失败时播放器区域展示失败图标点击后重新加载重试三次仍失败则跳过该条并加载下一条接口拉取新数据失败时保留当前列表数据并展示一条轻提示「刷新失败请稍后再试」上拉翻页到达底部时展示正在加载动画连续翻页10次无新数据则视为「到底了」展示「没有更多了」。页面状态触发条件展示表现加载中冷启动进入推荐流居中loading动画保持底部Tab可点击加载失败接口无返回或网络断连全屏错误提示提供重试按钮空数据接口返回空列表展示「暂无推荐去关注你感兴趣的人吧」附推荐关注卡片到顶/到底上滑到第一条或下拉到底到顶时展示「已经是最新了」到底时展示「没有更多了」未成年模式当前账号开启未成年保护不展示直播、商城、同城入口推荐频率限制推荐流的另一个坑是「重复内容」。用户连续刷到同一条视频会强烈反感。PRD里不写「算法层面去重」而是写表现层定义同一账号发布的同一条视频在24小时内不重复出现在当前用户的推荐流中不同账号发布的相同素材比如同一段音乐同一套模板允许出现但连续不超过2条。这个标准不完美但它是一个可测试的定义。测试能构造数据验证开发能按规则实现比「智能去重」四个字实用得多。4. 避坑自查写抖音类需求文档最常见的五个翻车点4.1 举报与审核只写了入口没写状态流转现象开发按PRD做完了举报功能用户提交举报后完全不知道后续进展测试追问「审核驳回后用户的作品还在吗」研发和产品面面相觑。原因PRD里只写了「用户可举报」「内容会审核」把状态流转留给了开发自行发挥结果不同端实现不一致。解决在PRD里写一个最小状态机「举报已提交 → 审核中 → 举报成立/举报不成立」。举报成立后对被举报内容做隐藏处理被举报作者收到系统通知展示「作品因审核未通过已移除」并保留48小时申诉入口。审核不成立时用户收到「举报未通过」通知不展示举报人信息。4.2 把「推荐去重」当成一句愿景现象需求评审会上你说「推荐流要智能去重」开发回你「怎么算重做不了」到了测试阶段测试构造了两条同音乐同画面的视频你发现产品行为完全取决于开发心情。原因需求描述停留在用户诉求层面没有落到可执行规则。解决把去重规则写成可验证的表现层定义——同一视频24小时内不重复推荐连续出现的视频中相同封面模板不超过2条用户明确点「不感兴趣」的博主30天内不再出现在推荐流中。每条规则独立编号作为推荐流需求条目的一个验收标准。4.3 数据敏感操作没有联动处理现象用户删除了一条作品但搜索结果页还能看到缓存用户把账号设为「私密」之前公开过的作品仍然能通过链接访问。原因PRD里只做了「删除作品」「设置私密」两个独立需求没有写数据联动。解决每个影响可见性的操作都要在PRD里写一个「联动影响范围」段落。删除作品时同步隐藏推荐流、搜索、关注Tab中的该条内容私密账号开启时所有作品设为「仅自己可见」关闭私密后恢复原可见范围注销账号时要提示「作品和粉丝关系将无法恢复」并给出7天冷静期。这类需求不写上线后就是声明的数据安全风险。4.4 游客态和半登录状态被当成不存在的场景现象测试用「未登录状态」跑核心路径进入首页推荐流没问题但一点赞就跳登录页登录完了又跳回首页顶部用户观看进度丢了。原因PRD默认用户是已登录状态把游客态当作异常态顺带处理。解决新增一个「游客态」角色和已登录态并列写需求。游客态允许浏览推荐流和同城页点赞/评论/关注时弹出登录引导页登录成功后回到原视频位置并保留点赞意图播放进度不丢失游客态不展示个人主页、不展示私信入口。这条加在需求文档开头或账号章节提醒每一个后续需求都要在两种状态下分别验收。4.5 版本兼容与灰度发布要求缺失现象新版发布页新增了「定时发布」字段但线上老版本App还停留旧接口老用户提交作品时新字段为空后端直接把这条数据写成了异常状态导致审核流程卡住。原因需求描述里没有注明版本兼容和灰度范围开发默认所有用户同步升级。解决在重点需求条目末尾增加「兼容要求」一行——定时发布字段由客户端在上传时传入老版本客户端不传该字段后端赋默认值「立即发布」不允许因字段缺失而拒绝写入涉及支付、分享、账号迁移等高影响需求PRD里明确灰度计划比如「新用户全量开启老用户按3%比例灰度观察24小时后再放开」。注意踩坑记录不是写在文档末尾的附录而是写在每个需求条目旁边。开发写代码时看到「兼容要求」四个字就会条件反射地考虑老版本行为比评审会上口头强调十遍都有用。5. 用需求追踪矩阵收尾让评审和排期彻底对齐5.1 一张矩阵表管到上线PRD写完之后最后一步不是发给研发排期而是整理一份需求追踪矩阵。矩阵表的目的是让每个人都能一眼看清需求条目对应哪个开发任务、哪条测试用例、当前处于什么状态。我一般会在PRD定稿后的当天建这张表而不是等到开发完成再补因为评审时的变更记录也要靠它管理。需求编号功能模块对应开发任务对应测试用例当前状态USR-001手机号验证码登录开发登录接口与短信验证码TC-USR-001 验证码有效期TC-USR-002 验证码错误重试开发中USR-002第三方授权登录开发微信授权回调与账号绑定TC-USR-003 授权取消返回登录页待开发PUB-001发布页字段开发发布表单与字段校验TC-PUB-001 标题超长限制TC-PUB-002 发布失败重试已提测FEED-001推荐流互动数据开发推荐流卡片数据展示TC-FEED-001 数字过万折叠TC-FEED-002 接口无数据展示兜底已通过FEED-005推荐流去重规则开发去重过滤逻辑TC-FEED-005 同视频24小时不重复出现开发中矩阵表要随时更新尤其是研发排期变化和测试用例调整的时候。一个需求条目改动了验收标准对应测试用例必须同步改测试跑出一个新缺陷状态栏就要从「已通过」改回「复核中」。这张表不光是给项目经理看的也是给你自己留的后路。上线后如果有人问「为什么这个功能没有实现」你可以直接翻出矩阵表看那条需求的测试用例和开发任务是不是还停留在「待开发」状态而不是凭记忆解释。我最早写的PRD都不做矩阵那时以为自己把需求条目写清楚了就万事大吉。后来一次上线后发现「作品删除但搜索结果还可见」追到源头是删除功能的测试用例没有覆盖搜索列表而我在评审时也没发现这个遗漏。从那以后每份PRD定稿时我都会顺手建一张矩阵把「需求条目」「开发任务」「测试用例」三条线绑在一起。评审判定需求完整性时就问一个问题矩阵里有没有一条需求没有对应开发任务有没有一个开发任务没有对应测试用例两个问题能问住一定还有漏网需求。希望这些流程能帮你少走点弯路写出一份评审能过、开发能估、测试能跑的落地文档。本文还有配套的精品资源点击获取