用户故事User Story
你可能会说
先别直接列功能，写清楚是谁遇到了什么问题，解决以后有什么用。
从用户角度简短说明谁需要什么以及为什么需要的需求表达例如，旅行者需要保存未完成的行程，以便换一台设备后继续编辑。用户故事为需求讨论提供起点，但不会替代交互细节、验收标准或技术方案。
也常被叫作用户叙事User Stories故事卡
延伸阅读 · 权威出处
先别直接列功能，写清楚是谁遇到了什么问题，解决以后有什么用。
还不知道谁需要、为什么需要，也无法判断是否完成。
✓ 保存后刷新，内容仍然存在
✓ 换一台设备后可以继续编辑
先说明具体用户：写清哪类人在什么处境中提出需求，不用“所有用户”掩盖不同人的目标和限制。
把功能名称改成用户目标：“保存按钮”是方案，“稍后继续编辑未完成的行程”才是用户希望取得的结果。
继续补充可以检查的条件：故事保持简短，具体范围、异常情况和完成条件再写入 验收标准 Acceptance Criteria 或对应 用户用例 Use Case。
请把“保存行程”整理成用户故事，分别写清目标用户、想完成的事和原因。只使用我已经提供的事实；缺少用户依据或业务规则时列成待确认问题。整理后再补充可以直接检查的验收标准，不要提前决定按钮位置和数据库结构。