PRD 交上去那天，评审会开了四十分钟，前三十五分钟都在问文档里没有的东西：断网了怎么办、这个角色能不能删、上线后看哪个数。AI 写的稿子格式挑不出毛病，背景、目标、功能、流程一样不缺，缺的是让开发能动手、让测试能判断的那部分。下面按五处漏项给出补齐顺序，并说明哪两处最贵。
格式齐全解决的是可读性，不是可执行性
模型见过的 PRD 大多来自公开模板，模板教的是章节怎么排，不教规则怎么定。所以它写出来的文档读着很专业，每一节都有内容，但把文档交给一个没参加过需求会的人，他仍然不知道该做什么。
可执行性由三样东西决定：边界写没写清、异常写没写全、完成写没写死。这三样都不在模板的目录里。
五处补齐的先后
| 步骤 | 产出物 | 常见坑 |
|---|---|---|
| 补异常分支 | 一张状态表：空数据、加载中、失败、超时、重复提交、无权限，各写一句界面与系统行为 | 只写「网络异常时提示错误」，没写提示什么、能不能重试、重试几次 |
| 划不做的范围 | 一节「本次不做」，每条附一句为什么不做 | 写成「暂不支持」，没写是这期不做还是永远不做 |
| 写验收口径 | 每条需求后面一句可判真假的话 | 写成「用户可以正常使用」，测试无从下手，上线靠感觉 |
| 定埋点 | 一张事件表：事件名、触发时机、上报参数、去重口径 | 只写「统计点击量」，没写同一用户重复点击算几次 |
| 分角色权限 | 一张角色乘操作的矩阵，标出只读、可编辑、不可见 | 默认所有登录用户权限一致，上线后才发现运营能看到成本价 |
顺序不能乱。异常分支没定，验收口径就写不实，因为验收要覆盖异常路径；权限没分，埋点的事件参数也定不下来，同一个按钮对不同角色可能是两种行为。
异常分支按状态写，不按场景罗列
按「用户可能遇到什么」列，永远列不全，人会漏掉并发、权限变更、后端超时这些不常发生但一定会发生的路径。按系统状态列就收敛了：无数据、有数据、加载中、请求失败、无权限、数据被他人修改，六个状态基本能覆盖一个列表页的全部情形。
每个状态问三句：界面显示什么、用户能做什么、系统记录什么。第三句最常被漏，而它决定了出问题时能不能查。
验收口径要能判真假
检验办法很土：把这句话念给一个没参与需求的人听，问他能不能判断做完没做完。答不上来就是没写清。「响应流畅」判不了，「列表首屏在 4G 网络下 1.5 秒内出现，超过则显示骨架屏」能判。
每条需求至少配一句这样的判断，异常路径也要有。写不出来的，多半说明这条需求本身还没想清楚，该回去问，而不是先写着。
它补不上的两类输入
第一类是业务规则：谁能审批、金额上限多少、什么情况要走特批。这些规则散在制度、口头约定和历史工单里，模型看不到，问它就会得到一个「合理」的答案——通常是行业通用做法，和你们的实际做法不一样，而且写得很像真的，模型为什么会补出不存在的信息是同一个机制。
第二类是历史妥协：这个字段为什么不能改名、这个接口为什么不能动、这个流程为什么多一步。文档里没有，代码注释里也未必有。写 PRD 时漏掉这些约束，开发照着做，改完发现踩了三年前的坑。
它擅长的部分也要用对：把散乱的需求描述整理成结构、把口语转成条目、按模板补齐章节、生成自查清单，这些活它做得又快又稳，提示词里把角色和禁区写死能少一半来回。要让文档跟着需求变更走，还可以让它按固定格式输出条目，交给智能体去比对版本差异，多步任务怎么拆给智能体跑讲的是这条链路。
交出去之前的三分钟自查
翻到功能清单，逐条问三个问题：断网时它显示什么；这个角色能不能做这个操作；上线后看哪个数判断它成了。三条里有一条答不上来，就补上再发。
再翻到「本次不做」，看有没有写清是这期不做还是永远不做。这一句能省掉评审会上最常见的一轮争论。
速查：PRD 五处自查
- 异常：六个状态各写界面、操作、记录三句
- 范围：本次不做，每条附原因和时限
- 验收：一句话能被第三方判真假
- 埋点：事件名、时机、参数、去重口径四件齐
- 权限：角色乘操作的矩阵，别默认权限一致
