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