下载PM面试必备PRD模板（中文版）：从0到1写产品需求文档
一句话总结
PRD不是简历的装饰品，而是面试官验证你能否"替团队想清楚"的试金石。大多数人把PRD写成产品说明书，本质上是在用执行者的姿态应聘决策者的岗位。真正能通过面试的PRD，核心判断只有一条：它必须让面试官在120秒内相信，这个产品如果明天交给你，团队不会掉坑里。不是写得多，而是写得让工程师愿意看、让设计师能动手、让老板敢签字。
适合谁看
这篇文章写给三类人，但每类人看到的东西应该不同。
第一类是正在冲击L4-L6 PM岗位的候选人。你可能在字节、美团、拼多多做执行PM，想跳槽到更扁平的组织做独立产品负责人；或者你在咨询公司、投行、技术岗，想通过PRD证明自己"像"一个PM。你的核心痛点不是不会写，是不知道面试官用哪把尺子量你的PRD。我见过一个候选人在某大厂三轮面试都挂了，不是PRD写得差，是他在每一轮都给了不同的人"不同的产品愿景"——面试官一交叉验证，直接出局。
第二类是刚晋升或即将晋升的执行层PM。你的老板突然让你"写个PRD看看"，这本质上是一次述职预演。不是考核你的文档能力，是考核你的决策链条是否完整。有个场景很典型：某候选人在现公司写了两年PRD，面试时却被问"如果你只能保留这个PRD的30%，你会砍哪70%"。她愣了十秒，因为从来没被这样问过。这个问题的答案不是裁剪技巧，是她从未真正拥有过这个产品的决策权。
第三类是面试官和 hiring manager。你可能在组建团队，想要一个统一的评估标准。这篇文章的反面价值在于：它暴露了大量候选人的真实水平，帮你把"会写文档"和"会定义产品"区分开。我在hiring committee里见过太多case，候选人的PRD结构工整、术语准确，但追问一句"如果开发周期砍半，你保留什么功能"，答案立刻散架。这不是面试技巧问题，是产品思维的结构性缺陷。
三类人有一个共同盲区：把PRD当成"写"的问题，而不是"想"的问题。这个判断是本文一切内容的前提。
为什么PRD是面试的暗门槛
面试官不会告诉你，但PRD的筛选逻辑从来不是线性的。
表面流程是：你提交一份作品，面试官阅读、打分、进入下一轮。实际流程是：面试官在收到PRD的前30秒就已经在心里贴了标签——"这个人做过事"还是"这个人只会说"。剩下的时间都是在找证据印证这个第一印象。这不是偏见，是效率。一个L6 PM岗位可能有200份申请，面试官没有义务逐字阅读。
关键判断在这里：PRD的核心功能不是展示你有多了解产品，而是展示你有多了解"不确定性"。
一个真实的debrief场景。某硅谷S公司的L5 PM岗位，三位面试官对同一候选人的PRD评价分裂。A面试官（工程背景）认为PRD"技术可行性分析扎实，但用户场景模糊"；B面试官（产品背景）认为"用户洞察精彩，但落地路径不清晰"；C面试官（设计背景）认为"视觉描述过多，决策逻辑缺失"。Hiring manager最后问了一个问题："如果这三个人说的都是对的，这个PRD的问题在哪？"
答案是：这个PRD试图讨好所有人，因此没有得罪任何人。但产品决策的本质就是得罪人——资源有限时，你选择服务谁、放弃谁，这才是PRD应该暴露的判断。
另一个insider场景来自某中国头部互联网公司的hiring committee。一位候选人的PRD写了一个极其完整的社交功能模块，从需求背景到数据埋点，40页。HC讨论时，一位资深总监问："如果明天这个产品的DAU下降30%，你PRD里的哪个假设会先崩溃？"候选人没有想过这个问题。他的PRD里有17个数据指标，但没有一个是他愿意为之下注的"核心假设"。最终这个候选人被标记"执行能力强，独立决策待观察"，降到L4录用，base从预期的220K降到165K，RSU package少了40%。
这两个场景的共同点：面试官不是在审查你的PRD格式，是在用你的PRD做压力测试。格式可以学，压力测试的反应模式学不了——它暴露的是你真实的决策层级。
PRD的隐藏结构：不是文档结构，而是决策结构
市面上所有PRD模板都在教你"写什么"，但没人教你"先想什么"。
这不是模板的问题，是认知顺序的问题。大多数候选人拿到模板，从上到下填空：背景、目标、用户、功能、数据、排期。填完觉得"完成了"。但面试官看到的，是一个从未被质疑过的决策链条——你的背景假设从哪里来？目标为什么是这个数字？用户画像和业务目标之间的gap如何弥合？
真正的PRD写作顺序是反过来的：先找到那个"如果错了，一切都会崩塌"的核心假设，然后围绕它组织所有内容。
一个具体的内部方法论。某L7 PM在面试培训中分享过他的PRD写作 ritual：动笔之前，先写三句话——"我认为的用户，在场景下，会因为原因，选择方案而不是替代方案，如果验证失败，我会在时间点用指标确认。"这三句话如果通不过他自己脑子里的"杠精测试"，他不会打开文档。
这个方法的精髓在于：它强迫你在写任何功能描述之前，先暴露自己的脆弱性。不是"这个功能很好"，而是"这个功能可能不好，但我目前认为这是最优解，因为"。
对比两个版本：
BAD版本（常见错误）：
> 背景：随着Z世代用户增长，平台需要提升年轻化内容占比。
> 目标：6个月内将Z世代用户渗透率提升15%。
> 功能：新增" Youth频道"，包含短视频、直播、社区三大模块。
这个版本的决策链条是断裂的。"随着Z世代用户增长"是一个不可证伪的宏观叙事，"提升15%"是拍脑袋的数字，"新增频道"是解决方案的早产。面试官无法判断：如果Z世代渗透率提升不是你的核心矛盾呢？如果15%达不成，是目标错了还是执行错了？如果 Youth频道 做不起来，有没有Plan B？
GOOD版本（同一题目的重构）：
> 核心假设：我们观察到18-24岁用户的人均消费时长比25-30岁用户低40%（数据），但次日留存率反而高12%。这意味着存在一个"高兴趣低表达"的沉默群体，当前产品形态过度服务于高表达用户，正在系统性驱逐沉默用户。
> 验证方式：在3个月内，通过A/B测试验证"降低创作门槛"比"提升内容消费效率"更能提升该群体的7日留存。
> 若假设失败：若7日留存无显著变化，则转向验证"内容匹配算法"假设，放弃"创作工具"路线。
这个版本的决策密度完全不同。它暴露了一个具体的数据矛盾（时长低但留存高），给出了一个可证伪的假设（创作门槛>消费效率），设定了明确的验证机制（A/B测试，3个月，7日留存），并准备了失败后的转向路径。面试官即使不同意这个假设，也能判断这个人的思考方式是结构化的、可协作的。
从0到1的实战拆解：一个PRD的诞生过程
不要从"写"开始，要从"被质疑"开始。
这是我的建议流程，但更重要的是背后的判断逻辑。
第一步：找到你的"反方辩友"。
在动笔之前，找一个人——最好是工程师或设计师——把你打算写的东西讲一遍。不是征求意见，是让他攻击你。某候选人的做法是：每次写PRD前，约一位工程师朋友喝咖啡，让对方用"这不可能"作为开场白，持续15分钟。他发现，80%的漏洞在这个阶段就会暴露。剩下的20%，面试官也问不出来。
一个真实的对话片段：
> 候选人：我想做一个AI自动归类用户反馈的功能。
> 工程师朋友：这不可能。你们的反馈量级是多少？
> 候选人：每天大概500条。
> 工程师朋友：那用关键词规则就够了，AI是过度设计。而且你们的反馈分类标准稳定吗？
> 候选人：不太稳定，运营团队每个月都改。
> 工程师朋友：那AI训练都来不及。你确定问题是"归类效率"而不是"归类标准"吗？
这段对话的价值不是让候选人放弃AI方案，是逼他重新定义问题。最终他的PRD变成：第一阶段用规则引擎+运营审核建立稳定分类标准，第二阶段在标准稳定后引入AI辅助。这个版本在面试中被追问时，他能清晰解释"为什么不是一步到位"。
第二步：用"电梯测试"定义核心一页。
假设你只有一页A纸，一个完全不认识你的人，30秒看完后要理解你的产品判断。这一页放什么？
不是产品架构图——架构图是给自己看的。不是用户旅程——旅程是给设计师看的。这一页应该只有三个元素：一个被精准定义的问题、一个被明确量化的机会、一个被大胆假设的解决方案。
某成功通过Google L5面试的候选人分享过他的"一页纸"：
> 问题：企业微信客户群中，销售平均需要7次触达才能转化，但前3次触达的内容重复度高达80%，导致客户在第4次前流失率67%。
> 机会：若将前3次触达标准化、个性化，预计可将转化周期缩短至4次，按当前客单价计算，单销售年产能提升$120K。
> 假设：销售不愿用标准化模板，不是因为模板不好，是因为"个性化修改"的成本高于"从头写"的成本。解决方案不是更好的模板，是"一键生成60%个性化内容+人工调整40%"的混合工作流。
这一页纸的每一个数字都经得起追问。"7次触达"从哪来？"80%重复度"怎么统计？"67%流失率"是整体还是分段？这位候选人的准备深度是：他把原始数据、统计方法、样本偏差都准备了，但只放在附录。主文档保持锋利，备档保持厚实。
第三步：功能描述的"生死线"写法。
功能描述不是"系统支持"，而是"当用户处于状态时，系统通过方式，帮助用户达成目标，若失败则"。
BAD版本：
> 功能1：用户可设置消息提醒时间。
> 功能2：系统支持多设备同步提醒设置。
GOOD版本：
> 触发条件：用户在睡前场景（22:00-00:00访问APP）设置次日提醒。
> 系统行为：默认推荐基于用户历史起床时间的智能时段（算法说明见附录），用户可一键确认或手动调整。
> 异常处理：若用户未开启系统通知权限，在设置完成页弹出引导而非提前阻断；若引导后仍拒绝，记录至"权限流失"漏斗，供运营跟进。
> 成功指标：设置完成率>60%，实际触发率>设置完成率的80%（即用户设置后确实收到并响应）。
GOOD版本的区别在于：它暴露了一个具体场景（睡前）、一个默认策略（智能推荐）、一个异常分支（权限拒绝）、一个验证标准（两层漏斗）。面试官可以沿着任何一条线追问下去，而候选人已经准备了答案。这不是过度准备，是思考完整性的自然结果。
面试官怎么看你的PRD：四轮面试的考察地图
PRD不会只在一轮出现，但每一轮的读法不同。不理解这个，会准备错方向。
第一轮：Recruiter Screen（30分钟）
Recruiter不是技术背景，但她有一个 checklist。她的核心判断是：这个人的表达是否自洽？有没有明显的逻辑断裂？
一个真实的recruiter反馈："候选人提到'提升用户粘性'，我追问'粘性怎么定义'，他说'就是多用'。这种回答我会标记，但不决定通过。我会看他在后续面试中是否自己修正。"
判断：第一轮不是淘汰轮，但会留下"档案标签"。你的PRD如果被问到某个概念，必须给出同一套定义，不能前后矛盾。
第二轮：PM Peer Interview（45-60分钟）
这一轮是真正的PRD压力测试。面试官会选一个你PRD中的点，纵深追问"为什么不是另一种做法"。
一个经典的追问场景：
> 面试官：你提到用"个性化推荐"提升留存，为什么不是"编辑推荐"？
> 候选人（常见错误）：因为个性化是趋势，编辑成本高。
> 面试官（继续追问）：那如果一个千人规模的内容团队，编辑成本可以摊薄呢？
> 候选人（开始慌张）：那……可能也需要考虑。
这个回答的问题不是结论错误，是候选人从未真正比较过两个方案。他的"个性化推荐"是一个默认选项，不是被选择的结果。
GOOD版本的回答：
> 我们内部试过编辑精选，数据是首页CTR提升15%，但7日留存无变化。拆解后发现，编辑精选的内容消费深度更高（单篇停留+22%），但覆盖品类收窄（-40%），导致用户发现"这里只有我想看的某类内容"而非"这里懂我"。个性化推荐的核心价值不是CTR，是品类多样性带来的长期留存。如果团队规模支持，我会建议"编辑把控调性+算法扩大覆盖"的混合模式，而非二选一。
这个回答的判断力在于：它展示了一个被证伪的实验（编辑精选的留存失败）、一个结构化的归因（品类多样性>单篇深度）、一个升级后的方案（混合模式而非非此即彼）。面试官即使偏好编辑模式，也会认可这个人的思考框架。
第三轮：Cross-functional Interview（45分钟，工程师或设计师）
这一轮考察的是PRD的可协作性。不是看你写得多好，是看团队拿到这个PRD后能否有效工作。
工程师的典型问法："这个需求里，哪一部分如果砍掉，对产品核心价值影响最小？"这是在测试你的优先级是否真实——很多候选人的"优先级P0/P1/P2"是随便写的，从未真正承受过取舍的痛苦。
设计师的典型问法："这个用户场景里，情绪高点和低点分别在什么时候？"这是在测试你的用户理解是否足够具象，能支撑设计决策。
第四轮：Hiring Manager / Director（45-60分钟）
这一轮回到战略层面，但问的往往是PRD之外的东西。
一个真实的HM问题："你的PRD写得很完整，但如果回到6个月前，你会用更轻量的方式验证这个假设吗？"
这个问题的陷阱在于：它假设你的PRD是"重的"，而你需要么承认"是的，我可以更轻"，要么辩护"这个复杂度是必要的"。两种回答都可以，但必须是真实的——因为HM会追问细节，编造的回答撑不过三个回合。
另一个HM常用的压力测试："如果你的直接下属写了这个PRD，你的反馈是什么？"
这是在考察你的自我认知和团队管理能力。回答"我觉得写得很好"会显得缺乏批判性；回答"我会让他重写"会显得缺乏授权意识。好的回答往往从具体细节切入："我会在部分追问更多数据支撑，在部分建议先做一个更轻量的实验，但整体上我会让他主导这个方向，因为他比我更了解。"
准备清单
- 建立你的"反方辩友"机制：动笔前至少找一位工程师或设计师，用15分钟攻击你的核心假设。记录被问住的三个问题，它们就是你PRD的漏洞。
- 准备一页"电梯PRD"：一页A纸，包含一个被精准定义的问题、一个被量化的机会、一个被假设的解决方案。确保30秒内可以讲清。
- 系统性拆解面试结构：PM面试手册里有完整的Google/FB/字节等大厂PM面试实战复盘可以参考，特别是关于"如何在PRD中暴露决策链条"的部分。注意不是背诵框架，是理解每个框架背后的考察意图。
- 为PRD中的每个数字准备"考古笔记"：数据来源、统计口径、可能的偏差、如果数据错了你的结论怎么变。这些放在附录，但脑子要清楚。
- 准备三个"如果失败"的Plan B：核心假设被证伪后的替代路径。面试官不一定会问，但问了答不出是致命的。
- 模拟一次"交叉验证"：找两个不了解你项目的朋友，分别告诉他们你的产品方向，一周后让他们复述。如果两个人说的不一样，你的PRD叙事有问题。
- 建立你的"决策档案"：每次写PRD时，记录一个"我当时为什么没选另一个方案"的笔记。面试时被问到，你能调出当时的真实思考，而不是现场编。
常见错误
错误一：把PRD写成"产品说明书"而非"决策记录"
BAD版本：
> 本功能支持用户上传图片，支持JPG/PNG格式，单张不超过5MB。
GOOD版本：
> 用户上传图片的场景中，我们曾因支持格式过多导致客户端崩溃率上升（详见2023-Q3事故复盘）。因此本阶段限定JPG/PNG，5MB限制基于当前90%用户素材的体积分布（数据附录A）。若未来WebP占比超过30%，将启动格式扩展评估。
区别：BAD版本是一个无争议的执行指令；GOOD版本暴露了一个历史决策（为什么限制）、一个数据依据（5MB从哪来）、一个未来触发条件（什么时候重新评估）。面试官从中学到的不是"这个产品有什么功能"，是"这个人做决策时考虑了什么、放弃了什么、准备了什么后路"。
错误二：用"用户可能想要"代替"用户真正做"
BAD版本：
> 用户希望有一个更方便的收藏功能，以便快速找到之前感兴趣的内容。
GOOD版本：
> 用户行为数据显示，当前收藏入口的平均使用路径深度为4.2步，而收藏后的7日内回访率仅12%。用户访谈中，3/5人将收藏描述为"存档就忘了"，而非"稍后阅读"。因此本方案的核心不是"更方便的收藏"，是"收藏后的唤醒机制"。
区别：BAD版本是伪需求——"更方便"是一个无法验证的形容词。GOOD版本用行为数据（路径深度、回访率）和定性研究（访谈引用）重构了问题定义。面试官可以不同意"唤醒机制"的方案，但无法质疑这个问题的真实性。
错误三：逃避"如果资源减半"的取舍问题
BAD版本（被问到时的典型反应）：
> 如果只有一半资源，我们可能会延期一些非核心功能，保证核心体验。
GOOD版本：
> 如果资源减半，我会砍掉第三阶段的数据看板功能。原因是：第一、二阶段的核心假设是"用户愿意创作"，数据看板是"创作者愿意持续创作"的验证工具；若前两个阶段失败，第三阶段无意义。同时，我会把原定第三阶段的1.5个月工程师资源，转投到第一阶段的A/B测试加速上，以提前2周验证核心假设。这是我在PRD附录3中的备选方案。
区别：BAD版本是逃避——"非核心功能"是什么？没有定义。GOOD版本展示了真实的优先级判断（第三阶段数据看板）、资源重分配的逻辑（加速验证>完善基础设施）、以及事先准备（附录3的备选方案）。这种回答在面试中会显著加分，因为它展示了"在约束条件下做决策"的核心能力。
FAQ
Q：我没有真实的产品经验，PRD可以写虚构项目吗？
可以，但虚构项目的风险在于你无法承受"当时为什么没选B"的追问。一个真实的替代方案是：选一个你深度使用的产品，写一份"如果我是PM，我会怎么做"的逆向PRD。关键不是真实性，是思考深度。某成功转行的候选人，PRD写的是"豆瓣小组如果我来重做"。他在面试中被追问"你为什么假设小组管理员愿意用新工具"，他能够回答："我潜伏了12个小组，观察了47天的管理员行为，发现"。这种基于真实观察的虚构，比空泛的"假设用户需要"有力得多。但警惕一个陷阱：不要选你太热爱的产品，因为你会 inability to kill your darlings——面试官让你砍功能时，你会情感上无法割舍。选一个你关心但不爱上的产品。
Q：PRD需要写到什么详细程度？功能描述要到交互层级吗？
不是"越详细越好"，而是"详细到能支撑面试官的追问，但不冗余到掩盖核心判断"。一个实用的标准是：如果你的PRD超过15页，问自己"哪一页如果删掉，面试官会问'为什么没写'"；如果你的PRD少于5页，问自己"哪一部分面试官会假设我没想而实际我想了"。一般来说，核心假设和验证逻辑需要最详细（占30%篇幅），用户场景需要具体但不必穷尽（占25%），功能描述需要精确到可追问但不必到PRD内部级别（占30%），风险和备选方案需要诚实暴露（占15%）。交互细节、视觉规范、API定义，这些在面试PRD中通常过度准备——它们展示的是执行能力，而面试考察的是决策能力。有一个例外：如果你面试的是增长或策略PM，数据埋点和实验设计需要更详细，因为那是你的核心工具。
Q：面试官不认同我的产品方向，怎么办？
这是最常见也最需要准备的情况。首先要判断：他是真的不认同，还是在测试你的防御能力？一个信号是：如果他给出了具体的替代方案并追问其优劣，这通常是测试；如果他反复说"我觉得这个方向不对"但没有展开，这可能是真实的不认同，也可能是压力测试。无论是哪种，错误的回应是立刻放弃立场（"您说得对，我可能没考虑清楚"）或顽固防御（"我觉得我的方向是对的"）。正确的回应结构是："我理解您的担忧，具体来说是在方面的顾虑。我的核心假设是，支撑这个假设的数据/观察是。如果我理解对了，您的替代方案在方面有优势，但在方面可能需要的额外假设。我没有足够信息否定您的方案，但基于当前信息，我坚持原判断的原因是。如果入职后发现有误，我会在时间点用方式验证并调整。"这个回应的精妙之处在于：它既展示了倾听（理解具体担忧）、又展示了坚持（核心假设和数据）、又展示了开放（在什么条件下改变）、还展示了执行纪律（验证机制和时间点）。面试官很难对一个"知道自己可能错、但现阶段有充分理由坚持、且准备了纠错机制"的候选人说不。这不是话术，是真实的决策成熟度。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。