作为（角色）
补三要素，看故事卡怎样转可排期
编辑角色、目标、收益：右侧故事卡的三要素 chip 逐个点亮，徽章从「草稿」转为「可排期」，验收线索在凑齐后解锁。遮住底部说明，故事卡本身仍能讲清是否能进入实现。
需求便签只有一句「做个上传表单」。在左侧补齐角色、目标、收益：右侧故事卡的三要素 chip 会逐个点亮，凑齐后徽章转为「可排期」并解锁验收线索——结果写在故事卡上，不只是底部说明。
作为＿＿＿＿＿，我想＿＿＿＿＿，以便＿＿＿＿＿。
- 角色
- 目标
- 收益
还缺 角色、目标、收益：不知道为谁做、做完谁受益，就没法定义「完成什么样」。先别急着建表。
已点亮 0/3 要素。补齐角色、目标、收益后，右侧验收线索才会解锁。
故事卡刚教会的规则
故事卡负责谁与为何，验收负责做成什么样。技术方案不能替代左侧收益。
- 三要素缺一不可：少角色不知道为谁做，少目标不知道做什么，少收益不知道为什么值。
- 收益决定验收顺序：故事卡里的「以便」会翻译成右侧的可测线索。
- 角色决定「完成什么样」：换一个角色，验收线索跟着换。
- 技术任务替代不了收益：把「以便」写成「建一张表」，验收会熄灭，范围反而偷跑。
什么时候写用户故事
要把模糊功能变成可排期条目时用；纯技术债不必硬套「作为谁」。
新功能范围不清、多人对「做完」标准不一致、需求只有一句技术指令。
数据库迁移、依赖升级等无直接用户角色的工作，写成任务与验收即可。
从模糊需求问出三要素
拿到「做个上传表单」这种粗需求时，按三步问出角色、目标和收益，再让验收对齐收益。
- 问角色谁最痛、谁会用？锁一个具体用户群（报名学生），而不是「所有用户」。
- 问目标他们要完成什么可观察行为？（上传 jpg/png 封面），不是技术任务（建表）。
- 问收益做完后谁受益、受益在哪？（老师能在列表里认出项目），收益决定验收顺序。
同一上传封面需求：正例与反例
目标都是让老师认出项目。差异在故事卡是否完整、验收线索是否被解锁。
作为报名学生，我想上传 jpg/png 封面（≤2MB），以便老师认出项目。三要素齐全，验收线索自然浮出：格式限制、失败保留、列表可见。
差异：故事卡完整，验收跟着亮，团队知道「做完」长什么样。「做一个上传表单 / 建封面表」——故事卡残缺，验收熄灭，实现却偷偷扩成整套媒体库。
差异：只改一处——用技术方案替换了用户收益。快速自测
「作为报名学生，我想上传封面」还缺什么才能成为完整用户故事？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。