PRD写作的工程化方法：从模糊需求到可验证规格的完整路径
一、PRD为什么是一个工程问题？
PRD（Product Requirement Document）的传统写法是叙事性的。"用户想要X功能，所以我们做Y"。这种方式在需求简单时够用，但面对复杂系统时，叙事性PRD是Bug的源头。
问题出在"歧义"上。同样的句子，"用户点击按钮后显示结果"，不同工程师的理解可能截然不同。技术Leader看到的是异步加载+骨架屏，前端认为是简单页面跳转，后端以为是文件下载。当代码写完后发现理解不一致，返工成本是指数级的。
工程化的PRD不接受歧义。它把需求表述转化为可验证、可测试、可度量的规范。核心方法是将PRD拆解为三个层次：用户故事（Why）→功能规格（What）→验收条件（How to verify）。
二、从叙事到结构的转化方法
graph TB A[用户原始需求] --> B[结构化拆解] B --> C[用户故事层] B --> D[功能规格层] B --> E[非功能需求层] C --> F[验收标准] D --> F E --> F F --> G[可执行测试用例] G --> H{测试通过?} H -->|是| I[需求交付] H -->|否| J[反馈修正] J --> B转化过程的核心操作是"歧义识别"。以下是工程化PRD的规范模板片段：
story: id: "US-042" as_a: "社区认证用户" i_want: "批量导出三个月内的交易记录" so_that: "完成月度财务核对" specification: input: - field: "date_range" type: "enum['1m','3m','6m','custom']" default: "3m" validation: "custom时须提供start_date和end_date" - field: "format" type: "enum['csv','excel','pdf']" default: "csv" behavior: - "点击导出按钮后，前端发起POST /api/export" - "后端异步生成文件，返回job_id" - "前端轮询GET /api/export/{job_id}/status" - "完成后展示下载链接，30分钟后过期" edge_cases: - "三个月内无交易：返回空文件并提示用户" - "数据量>10万条：拆分为多个1万条的文件" - "导出过程中用户关闭页面：继续后台生成" error_handling: - "生成超时(>60s)：返回超时错误" - "存储空间不足：提前检查并提示管理员" acceptance_criteria: - criteria: "非登录用户访问导出API返回401" test_type: "automated" - criteria: "三个月内1000条数据导出耗时<10秒" test_type: "performance" - criteria: "CSV文件编码为UTF-8 BOM，能被Excel直接打开" test_type: "automated"这种结构化PRD的效益是双重的。工程师拿到的是无歧义的接口契约，测试团队可以直接根据acceptance_criteria编写测试用例。一张表格就把"沟通"变成了"执行"。
三、验收条件的编写规范
验收条件是工程化PRD的灵魂。好的验收条件满足三个原则：
flowchart LR A[验收条件质量检查] --> B{可自动化?} B -->|否| C[重新设计] B -->|是| D{可度量?} D -->|否| C D -->|是| E{边界覆盖?} E -->|否| F[补充边界用例] E -->|是| G[验收条件合格]可自动化：每一条验收条件都必须能转化为自动化测试。如果写不出对应的测试代码，说明需求本身不够清晰。例如"用户体验良好"不是验收条件，"页面首次内容绘制时间<1.5秒，交互时间<3秒"才是。
可度量：避免模糊形容词。"系统响应快"不能验收，"P99延迟<200ms"才能。一个实用的做法是用数字替代所有形容词。
边界覆盖：正常路径的验收条件只占实际场景的20%。真正的Bug出在边界条件：空输入、超大数据量、并发操作、网络中断。每条用户故事至少配备两个边界验收条件。
四、与技术实现的耦合解耦
工程化PRD的最大陷阱是"写得像技术方案"。PRD应该描述"做什么"而不规定"怎么做"。以下是一个对照：
| 不好的描述 | 好的描述 |
|---|---|
| 使用Redis缓存用户信息 | 用户信息查询延迟<50ms |
| 用WebSocket推送消息 | 新消息在1秒内通知到在线用户 |
| 数据库加个索引 | 搜索响应时间降低到200ms以内 |
| 上CDN | 静态资源在国内各地多加载时间<500ms |
工程师需要知道的是性能目标和行为约束，不是技术方案。把"怎么做"留给工程师，PRD只约束可观测的输出。
五、总结
- 三元结构：用户故事(Why)→功能规格(What)→验收条件(Verify)，叙事需求转化为结构化规格
- YAML化PRD：用结构化格式定义输入、行为、边界和错误处理，消除自然语言歧义
- 验收三原则：可自动化（必须能转化为代码测试）、可度量（拒绝形容词）、边界覆盖（正常路径+异常路径）
- 与技术解耦：PRD约束"做什么"和性能指标，不约束"怎么做"
- 左移测试：验收条件在PRD阶段就写好，测试工程师根据它编写用例，实现需求→测试闭环
