你为一份用户故事模板而来——「作为…我想…以便…」格式、INVEST 清单、验收标准那一块。它在下面；抄进 Jira、文档、或任何放故事的地方。但要知道它的翻车方式：一个故事用一句话捕住需求，随即就和那个为它正名的产品决策脱了钩。当那个决策变了，故事还赖在 sprint 里，悄悄地造错的东西。Draftlize 给你同样的格式——并让每个故事连到它所依赖的决策。
一个用户故事是分三部分的一句话，加上让它可测试的标准。这就是整份模板——敏捷团队一直用的那个形状。
具体的用户或人物，而不是「用户」。「作为一个在评审路线图的 PM」框定了需求；「作为用户」什么都没框定。角色是让故事对「它服务于谁」保持诚实的东西。
他们想做的事，表达成一种能力，而不是一个 UI。「我想从 spec 里引用一个决策」——而不是「我想要一个下拉框」。长什么样是设计决策；故事讲的是目标。
让它值得做的那个结果。这是团队最爱省、却最重要的部分——它是「这故事到底值不值得做」的检验，也是范围被质疑时第一个要核对的东西。
让它可上线的条件，最好写成 Given/When/Then。这是故事变得可测试的地方。完整范式见专门的验收标准指南。
一个好故事是独立、可协商、有价值、可估算、够小、可测试的。把草稿故事对照这六条，弱的那些（太大、不可测、没价值）会在进 sprint 之前掉队。
走一个例子：作为一个在评审路线图的 PM，我想从 spec 里引用一个决策，以便我不必每个 sprint 都重新解释一遍。
收益从句引用了一个产品决策——「以便」某个目标被服务。但在一张工单里它只是文字，是对一个住在别处的决策的复述。故事和它依赖的决策，是两个碰巧此刻一致、却互不相连的东西。
故事背后的目标变了——你重切范围、重排优先级、砍掉一个人群。故事还赖在 backlog 里，带着它原来的「以便」，指向一个已不成立的理由。没人会在决策一动时重读每一个故事，于是 sprint 悄悄朝着一个过时的「为什么」开工。
标准是对着一份后来变了的 spec 写的。故事说「完成于 X」，spec 现在说 Y，缝隙在评审或 QA 时才浮现——晚、贵，而本可避免，只要标准当初是连到 spec、而不是从它复制来的。
在 Draftlize 里，故事不是孤立的工单——它是一张卡片，其「以便」连到它所服务的那张真实决策卡。收益不被复述，而被引用。打开故事，你能直接走到为它正名的那个决策。
因为链接是真的，改了故事背后的决策，故事自动变 stale——就像构建系统让被改文件的下游全部失效一样。你在一个 sprint 照旧把它们造出来之前，就看到哪些故事刚失去了它们的理由。
当 Claude Code 或 Cursor 经 MCP 拿起一个故事，它也读到相连的决策和验收标准——于是它对着当前的意图实现，而不是一句三个决策之前就失去意义的话。
用户故事用一句话捕住需求，却说不出那个让需求成立的决策何时已经走远。留着这个格式，让「以便」链接到决策，而不只是描述它。
经典模板是「作为 [角色]，我想 [能力]，以便 [收益]」。角色点名它给谁，能力点名目标（而不是 UI），收益点名它为什么值得做。再加上验收标准，让它可测试。
用户故事是从用户视角出发、简短而非正式的需求陈述，意在开启一场对话；用例是对用户与系统之间交互步骤更详细的描述。故事轻量、敏捷，用例更重、更完整。
好故事是独立、可协商、有价值、可估算、够小、可测试的。最常见的失败是：大到无法估算、「以便」里没有清晰价值、或因为没有验收标准而不可测试。
故事陈述需求；验收标准陈述「在什么条件下算完成」，通常写成 Given/When/Then。故事是一眼能看到的为什么与做什么，标准是对「成功」精确、可测试的定义。
用上面的模板，或在 Draftlize 里把每个故事写成连着它所服务决策的卡片——这样决策一动，故事就标 stale，而不是悄悄造错东西。
$5 免费开始