今天早上你在 Notion 里新建了一个页面，标题写着 "PRD：[功能名称]"。三个小时过去了，标题还是那行字。
你清楚问题，也清楚方案。昨天你已经把整件事跟工程负责人讲了两遍。可一坐下来要把它写成文档，你就卡住了。
这不是思考的问题，这是打字的问题。
公司付钱给产品经理不是让你打字的。你的价值在于判断该做什么、为什么做。PRD 只是一个把这个决策固化下来的产物，让工程、设计和管理层可以基于它推进工作。但在 "想清楚" 和 "写完文档" 之间，几个小时就这么没了。
其实有更快的路径。PRD 是产品经理写的所有文档中，最适合用语音完成的一种。它本质上就是你站在白板前向别人解释一个功能时会说的话。一旦你不再敲 PRD 而是开始口述 PRD，初稿时间会断崖式下降。
没人提的那笔 "PM 写作税"
你写的每一份 PRD，都在和一场会议、一次路线图评审、一个利益相关方的 Slack 讨论争夺时间。真正动笔写的那段时间，往往是从日程里挤出来的半小时，或者晚饭之后的零碎时间。
数字其实挺残酷的。普通人打字速度大约是每分钟 40 个英文单词。普通人说话的速度大约是每分钟 150 个。这中间已经有 3.5 倍左右的差距，还没算上那些让写作更慢的摩擦：退格、改词、为了一句话纠结三遍才肯往下走。
一份 1500 字的 PRD，打字写完要 90 分钟，口述只要 25 分钟左右。思考过程一样，产出一样，变的只是输入方式。
为什么 PRD 天生适合语音
大多数文档都不太适合口述，因为它们要求精确：代码、表格、财务模型。PRD 正好相反，它是叙事型文档。
回想一下你最近写的那份 PRD。"问题" 部分是两段话，解释这件事为什么重要。"方案" 是对功能如何运作的描述。"用户故事" 是 "作为 X，我希望 Y，以便 Z" 这种句式。"边界情况" 是一连串 "当……发生时会怎么样" 的设想。
这些内容没有一项需要键盘的精确度。每一项都是你在会议里会脱口而出的东西。这种格式本来就和产品经理日常沟通的方式高度吻合。
30 分钟搞定 PRD 初稿的工作流
实际有效的流程是这样的： 1. 打开一个空白文档，先把章节标题摆好：问题、方案、用户故事、验收标准、边界情况、不在范围内、待解问题。 2. 一节一节地讲。每一节都像在给刚加入团队的新工程师讲解一样去口述。 3. 讲的时候不要修改。在 "讲述者" 和 "编辑者" 之间来回切换，是最拖慢你节奏的元凶。 4. 把所有章节都口述完之后，再从头到尾通读一遍。打磨语言，把真正不对的地方改掉。 5. 发出去评审。
关键在第三步。如果你一边讲一边停下来改句子，速度优势就没了，你只是换了个姿势继续在打字速度里挣扎。
逐节拆解：PRD 每个部分该怎么口述
有的章节比另一些更好口述。下面是每一节的具体打法。
问题陈述
这是最好口述的一节，纯叙事。你只是在说：哪里出了问题、影响了谁、为什么现在要解决。
就像早会上给新同事做背景介绍那样讲就行。点出用户群体、他们遇到的卡点、关联的指标。不用纠结文笔，那是后面编辑该做的事。
方案概述
像在白板上画草图一样把方案讲一遍。"用户点了这里，看到这个，然后……" 语音特别擅长处理这种内容，因为它就是你本来就会说出口的那种解释。
用户故事
用户故事因为 "作为 X，我希望 Y，以便 Z" 的句式听起来很机械，但只要你愿意贴着这个格式说，是非常适合口述的。一个故事一句话，说完接着下一个。
如果有十个故事，就一口气把十个都讲完。不用一边讲一边编号。让文档编辑器或 AI 清理环节去帮你处理格式。
验收标准
列表是语音口述里最麻烦的部分，但完全可以搞定。两种思路：
第一种，是把每条标准当成一句完整的话讲出来，让 AI 在后期帮你整理成列表。比如这样说："用户应该可以按日期、按用户、按状态筛选结果。筛选状态应该跨会话保留。空状态需要给一个提示。"
第二种，是把项目符号也明确说出来："第一条，按日期筛选。第二条，按用户筛选。第三条，跨会话保留状态。" 哪种说起来不别扭就用哪种。
边界情况
这才是语音真正发光的地方。边界情况就是那种边想边说的内容——讲出来很顺，敲出来反而别扭。"用户离线时会怎样" 或者 "数据已经过期了该怎么办" 这种问题，用嘴说比用键盘敲自然得多。
想到的每一个边界情况都讲出来，哪怕看起来很 "显而易见"。多余的留到编辑环节再删。
不在范围内
三句话，最多四句。语音处理这部分用不了一分钟。
待解问题
这一节被严重低估。大多数 PM 跳过它，是因为不想显得自己没想清楚。别这么做。"待解问题" 恰恰是工程、设计和你的上级帮你抓出还没想透的地方的入口。
语音正好适合写这一节。待解问题就是那种半成形的想法，讲出来挺顺，写出来反而怪沉重。把你心里所有的不确定都讲出来，哪怕你怀疑它们答案显而易见。其中一半会在下一次站会上自行消解，另一半会救你一次发布。
让语气贴合不同章节
PRD 不是用单一语气写的。开头的执行摘要要紧凑、要有战略感。技术细节要精准。"待解问题" 这部分则可以更随意一点。
当你口述时，语气会自然切换。讲战略时你的语言会变正式，讲边界情况时会松弛下来。问题在于大多数语音工具不管你在讲什么，输出的都是同一种扁平转写。
Voicr 的 Smart Rules 正是为这种场景设计的。你可以给文档编辑器设置 "干净、专业的规格文档" 风格，给 Slack 讨论设置 "轻松头脑风暴" 风格，给工程 wiki 设置 "技术清晰" 风格。Voicr 会自动识别当前所在的应用并套用对应的风格，让同一句话在不同地方有不同的落地方式。
针对 PRD，建议设置一条规则：要求干净、专业的行文，去掉口头禅，在你明确示意的地方整理成项目符号列表。你只需要说一次，文档读起来就像你认真写过的一样。
语音也有搞不定的地方
说句实话：PRD 里并不是每个部分都适合用语音。
表格和矩阵还是打字更快。如果你的 PRD 里有功能对比表、权限矩阵或者一份带工作量估算的表格，老老实实敲。
精确的技术字符串也一样，打字更快。API 路径、数据库字段名、版本号——你也可以试着口述（"路径是，斜杠，users，斜杠，ID"），但很别扭。这些直接敲。
图表显然没法口述。在你顺手的工具里画好，再嵌进文档就行。
除此之外——叙事、用户故事、边界情况、决策、理由——语音都更快，而且你不会再因为某个句子怎么措辞才优雅而卡在半路。
思路要切换：先讲出来，再编辑
口述 PRD 的最大收益其实不是字数除以分钟那道数学题。而是你不再一边写一边打磨。
打字的时候你会退格，会把一句话翻来覆去改两遍，会盯着一段 "差不多对" 的话发呆十分钟。PRD 就是死在这里：在草拟和编辑之间的那道缝里，两边都没完成。
口述的时候，你是在交付。说一句话，它落在页面上，你就继续往下走。第一稿肯定比你敲出来的乱，但你把它写完了。一份乱但完整的初稿，比一份精致的半成品有用得多。
初稿一旦存在，编辑就是另一种完全不同、而且快得多的活儿。你常常会发现打磨的时间比口述还长，没关系。打磨一份完整的文档是一份已知量的工作。盯着一张白纸不是。
下一份 PRD 就试试看
挑一份你一直拖着没动的 PRD。打开文档，把章节标题先摆好，从头到尾口述一遍，中途不要编辑。定一个 25 分钟的计时器，看看自己能写出什么。
第一次这么做会觉得别扭。你会担心讲出来的东西不够好。忍住中途修补的冲动，把它讲完就行。
如果你希望口述出来的文字干净到几乎不用再改，Voicr 会自动帮你做这层打磨。在 Mac 上任意位置长按 FN，对着一节内容讲，松开，再把整理好的文字粘进你的文档。它会去掉口头禅、修正语法、在落到剪贴板之前就把思路整理清楚。一份过去要写一下午的 PRD 初稿，现在一口气就能搞定。
你的 PRD 不会自己写出来。但也确实不必再靠敲键盘写。