用户故事格式
"作为 X，我想要 Y，以便 Z" 格式及何时用它 vs. job-stories。
为什么
用户故事格式迫使作者依次说出用户、需求和价值。"以便"子句是防止功能工厂行为的关键：如果你说不清价值，这功能大概不值得造。格式也让估时更易，因为每个故事是一单位用户可见行为，而非一单位工程工作。不写"以便"子句的团队常造出能用却不解决任何可测问题的功能。
何时使用
把 PRD 拆成可构建单元时。每条 5 分钟。当"用户"是系统或价值是情感时改用 job-stories。
如何做
1. 开头："作为 [具体用户角色]" - 不要"作为用户"——说出角色（管理员、访客、计费所有者） 2. 需求："我想要 [可观察能力]" - 必须是用户能看或能做的事，非实现细节 3. 价值："以便 [可测结果]" - 填不出说明故事没准备好——回 PRD 4. 加验收标准子列表（Given/When/Then 或要点） 5. 只有有了验收标准才估时——无标准 = 无估时
示例
✓ 作为计费所有者，我想要下载所有发票的 CSV 以便我和会计软件对账。 验收： - 50 张发票时 CSV 下载 < 3 秒 - CSV 列匹配 QuickBooks 导入 schema ✗ 作为用户，我想要一个仪表盘。 （无角色、无价值、无验收标准——不是故事）
常见问题
- ⚠每条都写"作为用户"——角色重要，因为管理员的需求和访客的需求是不同功能。
- ⚠把实现写进需求子句（"我想要 Redis 缓存"）——故事应描述用户得到什么，而非你怎么造。
最佳实践
- ✓先写"以便"子句再倒推——从价值开始能防止"找问题的方案"式故事。
- ✓故事小到一个迭代能完成；跨 3 个迭代的是 epic，需拆解。