PRD 写不好，多数时候是"想清楚"的问题而非文笔问题：研发拿到文档还要来回追问，测试不知道做到什么程度算通过。AI 在这里能帮两个忙——把结构补齐，把漏洞提前问出来——前提是需求本身的取舍由产品负责人定，这一步外包不出去。
一份 PRD 在回答什么
合格的 PRD 要让三类人各自拿到答案：研发知道做什么、为什么做；设计知道用户在什么场景下用；测试知道怎么算完成。它最怕含糊，不怕朴素。"提升用户体验"写在文档里等于没写，因为这句话无法验证，也无法据其验收。
AI 能帮上的三件事
其一是补结构：把你漏掉的板块补上，比如绝大多数初稿都会漏"边界与约束"和"不做清单"。其二是找漏洞：边界情况、异常流程、未定义状态，它比你更不容易漏。其三是写初稿：把会议纪要和零散要点整理成规范文档，你在这个底稿上改，比从空白页开始快。
三件事的共同前提，是你已经把要点想得差不多。需求没想清楚就让 AI 写，得到的是一篇格式完整但立场空心的文档，评审会上反而更难收场。
一份 PRD 的六段骨架
- 背景与目标：为什么做、解决谁的什么问题，目标要能验收。
- 用户与场景：谁用、在什么情况下用、高频路径是什么。
- 功能清单：按优先级排列，每个功能注明它解决哪个问题。
- 核心流程：主流程怎么走，每一步的输入输出是什么。
- 边界与约束：明确不做什么、依赖什么、有哪些前提。
- 验收标准：逐条列出可验证的完成定义。
其中"边界与约束"最常被省略，也最值得写：研发追问的多数问题都落在这个区间，写清楚了能省掉评审会上一半的来回。
最有价值的一步：让 AI 当反方
文档写完后，把它粘给 AI，用这样的指令：请扮演一个挑剔的技术评审，找出其中的逻辑漏洞、没定义的边界情况和模糊表述，逐条列出并说明为什么有问题，不要夸我，只挑毛病。这一步比让它帮你写更值钱——它逼你把没想清楚的地方提前补上，而非在评审会上被人当场指出。
反方提问可以追问第二轮：针对挑出的每个漏洞，给出两种改法及其代价。漏洞本身只是问题，两种改法摆在一起，取舍才浮现出来，而这正是评审会上最容易被问住的内容。
把含糊表述改写成可验收
| 常见含糊写法 | 改写方向 | 可验收的标准长什么样 |
|---|---|---|
| 提升用户体验 | 拆成具体交互环节 | 指明哪个环节、达成什么效果，写成可观察的行为 |
| 支持异常处理 | 穷举异常类型 | 每类异常都有对应提示与恢复路径，逐条可测 |
| 性能要好 | 写清场景与口径 | 以双方确认的压测口径为准，写进验收条款 |
| 界面风格统一 | 挂接现有规范 | 注明遵循哪套组件规范，偏差需评审通过 |
AI 很爱写左列这种句子，你要做的是逐条把它逼进右列。判断方法很直接：把这句需求交给测试，如果对方问"那我具体测什么"，说明还没写到位。
它替代不了的部分
有三件事在文档之外。其一，涉及商业机密和未发布功能的内容，喂给公开工具前要想清楚，必要时做脱敏或走企业版。其二，文档再全也替代不了和研发当面确认的那十分钟，尤其涉及技术可行性的部分，写完文档约一次短会对齐，比改三轮文档有效。其三，优先级的取舍是产品负责人的责任：AI 能列出功能清单，但"这个版本做哪个、砍哪个"背后的业务判断，只能你来下。
PRD 写作速查
- 六段骨架：背景、用户场景、功能清单、核心流程、边界约束、验收标准
- 写完先让 AI 挑毛病，再让它给两种改法
- 每条需求都要能回答"测试具体测什么"
- 机密内容先脱敏，再进工具
- 发出前和研发当面过一遍技术可行性
三个常被问到的问题
- 需求经常中途变，PRD 要不要一次写全？：写"当前假设"而非写死。把前提条件单列一节，变更时只改假设和受影响的条目，比整篇重写省力，也方便追溯这次变更影响了哪些功能。
- 小改动也要全套骨架吗？：按比例裁剪，但"边界与约束"和"验收标准"两段不建议删。小需求翻车，多数就翻在这两段被省掉。
- AI 写的 PRD 研发愿意看吗？：研发看的是字段是否齐全、口径是否唯一，文风没人在意。异常流程和验收标准写得可执行，谁起草的没人关心；格式再漂亮，口径含糊照样被退回。
把需求想清楚再动笔的习惯，不只适用于 PRD。写经营总结时同样的逻辑可以参考给合伙人写年度经营总结的版本；做阶段回顾、判断哪些需求值得继续投入，数据与选题的复盘方法里有一套现成的拆法；如果需求涉及商品链路，售后数据的归因思路能帮你把"问题出在哪"写成有依据的需求背景。
