第4章：需求描述与用户故事 — 结构化模板与验收表达

需求描述是PRD中最容易被误解和敷衍的字段。多数产品经理习惯用“用户需要一个登录功能”这种模糊表达，导致开发反复确认、测试用例缺失、验收无据可依。本章从用户故事标准格式出发，提供一套可直接填入字段的结构化描述模板，让需求从“一句话”变成“可执行、可验证”的完整单元。

4.1 用户故事标准格式（As a… I want… So that…）

业界最通用的需求载体是用户故事，其结构看似简单，但每个分句都有严格的职责边界：

4.2 结构化描述模板 — 从一句话到完整字段

仅靠一句话的用户故事不足以驱动开发与验收。在PRD字段中，需要将用户故事扩展为结构化描述模板，覆盖前置条件、业务规则、验收要点三个维度。

4.3 用户故事与结构化模板的映射关系

很多团队认为用户故事和PRD字段是两套东西，实际上它们是同一需求在不同粒度下的表达。下表展示如何从一句话用户故事映射到结构化模板的每个字段：

在实际撰写时，先写出用户故事的三段式骨架，再逐句展开填充模板，最后补充验收标准，这是当前主流互联网公司普遍采纳的“三段填充法”。

4.4 验收标准如何从用户故事中生长

验收标准不是凭空编造，而是从用户故事的每个分句中抽取出可验证的条件。以下是从同一个用户故事生长出的验收清单：

4.5 用户故事结构化流程

下面这张流程图展示了从原始需求到完整结构化描述模板的转换路径，包含角色绑定、场景锚定、逻辑展开、价值量化、验收推导五个关键步骤：

整个流程强调不可跳跃：跳过角色锚定直接写逻辑，会导致权限遗漏；跳过价值量化直接写验收，会导致验收项与业务目标脱节。每步的输出都是下一步的输入。

4.6 避坑清单与自检要点

• 把用户故事写成了系统功能： “As a 系统，I want 返回错误码” — 用户故事的主角必须是真实用户角色或业务角色，系统行为应放在详细逻辑或验收标准中。
• So that 写成技术方案： “So that 我可以在API中传递token” — 应改为“So that 我可以安全地访问我的订单数据”。
• 一个故事包含多个需求： “I want 筛选、导出、打印订单” — 应拆分为三个独立用户故事，每个故事对应独立的验收标准。
• 验收标准重复需求描述： “系统应能筛选订单” — 验收标准必须具体到条件、操作、预期结果三者齐全。

4.7 交付物模板：用户故事结构化卡片

在PRD中，建议每个需求以“卡片”形式呈现，便于开发与测试直接取用。以下为模板结构，可直接复制到文档中：

以上模板可直接嵌入PRD的需求明细章节。每张卡片对应一个用户故事，开发与测试按卡片字段逐项执行，不再需要在需求文档和沟通记录之间来回翻找。