用AI把Epic拆到最小:product-manager-prompts 用户故事系列完全教程-育师

【免费下载链接】product-manager-prompts

A repository of Generative AI prompts for product managers using agents such as ChatGPT, Claude, & Gemini

项目地址：https://gitcode.com/gh_mirrors/pr/product-manager-prompts

product-manager-prompts是一个面向产品经理（PM）的生成式 AI 提示词开源仓库，收录 108 个可直接粘贴进 ChatGPT、Claude、Gemini 的提示词。本文聚焦其中的用户故事（User Story）系列：教你如何把 Epic（大故事）一步步拆到"一个迭代能交付"的最小粒度，并附上 8 步拆分规则和批量循环玩法，新手照抄即可上手。

一、为什么需要"AI 拆 Epic"？

很多团队的 backlog 都是这样的：Epic 一句话写到底、故事大到塞不进 Sprint、估时变成吵架现场。

product-manager-prompts 的思路是：把拆分逻辑写成结构化提示词，让 AI 按固定规则执行——

✅规则先行：8 步拆分检查清单，按顺序判断用哪种拆分方式
✅格式稳定：所有输出统一为 Mike Cohn 的As a / I want / So that+ GherkinGiven-When-Then验收标准，可直接粘进 Jira / ADO
✅越拆越小：拆出的故事若仍不合格，可进入循环继续拆，直到"无可再拆"

二、用户故事系列 6 件套：一张表看懂

文件	干什么用	什么时候用
backlog-epic-hypothesis.md	把 Epic 写成 If/Then 可验证假设	拆分之前，先给 Epic 定靶子
user-story-prompt-template.md	写单条标准用户故事 + 验收标准	从零写故事
user-story-splitting-prompt-template.md	核心：把大故事/Epic 拆小	故事塞不进 Sprint 时
user-story_ai-enhanced_prompt-template.md	AI 功能专用的"障碍感知"故事	故事涉及 AI 行为时
user-story-mapping.md	用户故事地图，画旅程主干	backlog 乱到看不出交付顺序时
story-splitting-loop.md	循环式拆分，拆到无可再拆	一次拆分不够、需要迭代时

💡 每个提示词文件头部都带 HTML 注释（Description / Usage Note / Instructions），先读注释再复制正文，这是仓库的教学设计（见 prompts/README.md）。

三、第一步：先把 Epic 变成"可验证的假设"

拆一个没想清楚的 Epic，只会得到 40 条自洽但错误的小故事。所以系列的第一站是 prompts/backlog-epic-hypothesis.md，它强制 Epic 写成：

If we[为目标用户做什么]，Then we will[达成什么可衡量结果]
配套输出：Tiny Acts of Discovery（低成本验证实验）+ 验证指标 + 待验证假设

把生成的假设文本带上，作为后续拆分的"基准营地"（base camp）。

四、第二步：写一条"工程师不烦你"的用户故事

使用 prompts/user-story-prompt-template.md，粘贴一句粗糙的需求即可冷启动（context 缺失时它最多追问 3 个定向问题）。

输出结构固定为：

As a[角色]，I want to[动作]，so that[结果] Given [前置条件] → When [触发动作] → Then [可观察结果]

两条硬规则值得记住：

一个故事只有一个When、一个Then——需要多个时，提示词会自动标记"拆分信号"，并指向拆分模板（见 user-story-prompt-template.md 的 Acceptance Criteria 规则）。
验收标准写行为，不写实现细节。

五、核心步骤：8 步规则把故事拆到最小

prompts/user-story-splitting-prompt-template.md 是全系列的拆分引擎，内置 Richard Lawrence《Humanizing Work》的拆分评分表，按顺序检查，命中第一条即拆分：

顺序	检查项	拆分方式
1	含多个工作流步骤？	按工作流步骤拆
2	引入业务规则变体？	按规则变体拆
3	数据形态有差异？	按数据变体拆
4	验收标准复杂？	按离散动作/结果拆
5	构建工作量巨大？	按工作量里程碑拆
6	有外部依赖？	按依赖边界拆
7	DevOps 工作量大？	按 DevOps 关键步骤拆
8	都不适用？	提出 Tiny Acts of Discovery（小步探索）

使用时的三个要点：

一次输出多套拆分方案供你对比权衡，而不是一条独木桥
每条拆出的故事仍用标准故事格式渲染，可直接进 backlog
结尾固定给出"风险和取舍 / 待验证假设"两段，防止"拆完了但没人知道代价"

拆不动怎么办？AI 功能场景用增强版

如果你的故事涉及 AI 行为（模型可能出错、用户等待时看到什么、"正确"如何定义），换用 prompts/user-story_ai-enhanced_prompt-template.md。它在 Use Case 里多了一行but [障碍/约束]，并在 STEP 4 自动做"拆分检查"：发现 When/Then 含复合逻辑或混入多个角色时，直接给出 Story A / Story B 的拆分建议。

六、进阶：从一次拆分到循环、批量

拆一次发现故事还是太大？仓库的 loops/ 目录把拆分升级为受控循环（理念见 loops/README.md 的"四条循环纪律"）。

1. 单 Epic 循环拆分→ loops/story-splitting-loop.md

核心是/goal+ 两条/loop命令：

/goal 按拆分评分表把 Epic 拆成大小合适的故事数组 /loop 遍历数组，不合格的继续拆，直到无可再拆 /loop 把稳定的故事逐条渲染成标准格式

它提供了三个层级：Level 0 朴素命令（今天就能跑）→ Level 1 自然语言控制契约（3 次遍历上限、无变化即停、每条幸存故事要汇报原因）→ Level 2 "Just Enough Jinja2" 模板。建议直接用 Level 1 文本，它把"拆 3 轮就停、拆不动就问我"这类护栏都写好了。

2. 整个 backlog 批量拆→ loops/epic-story-batch.md

把"规模失控"关进笼子里：单次最多 10 个 Epic、一次只处理一个、每个 Epic 结束出一张可审计的 Receipt（生成了几条、哪些检查没过、哪些是假设）、中途失败立即停整批。

3. 想要"先出计划再动手"？→ vibes/user-story-splitting-jinja2-loop.md

Phase A 只推导故事清单、Gate 处冻结清单等你批准、Phase B 才逐条成文——10 秒审一份 6 行计划，胜过 10 分钟审 6 条成品故事。

七、3 分钟上手清单

git clone https://gitcode.com/gh_mirrors/pr/product-manager-prompts，打开 prompts/user-story-splitting-prompt-template.md，读头部注释后复制正文粘进 ChatGPT / Claude / Gemini
粘贴你的 Epic 或超大故事；缺 context 时它会追问至多 3 问（拆什么？谁是用户？有什么约束？）
拿到多套拆分方案 → 回复1生成实施顺序、2生成验收测试清单、3转成 MVP/后续/打磨的发布切片

常见疑问

Epic 本身没验证过就拆可以吗？不建议。两个循环文件都明确写了"When NOT to Use"：未验证的 Epic 是"上游的雾"，先跑 backlog-epic-hypothesis.md 或 workshops/problem-framing-canvas-workshop.md。
输出能直接进 Jira 吗？能。所有模板坚持"稳定故事格式"，就是为了跨 Jira/ADO 可搬运（各文件的 Pedagogic Notes 均说明此意图）。
交互模式怎么选？本系列属于"上下文已就绪就直接执行"型，仓库的三种模式定义见 interaction-modes.md。