功能需求与工作流 —— 把行为写到无歧义

本课导读

进入 PRD 的正文主体：功能需求（定义预期的产品行为）和工作流与边界情况（记录用户流程与各场景下的异常）。这两部分是工程师读得最细、来回翻得最多的地方，也是歧义的重灾区。本课两件套：需求条目的写法（含 user story 格式及其局限），以及一套边界情况的系统枚举法——让"啊这个没想到"在写文档时就发生，而不是在上线前夜。预计 40 分钟。

功能需求：条目化、可检验、可追溯

功能需求（Feature requirements）的职责一句话：定义预期的产品行为和功能——注意是"行为"（系统在什么条件下做什么），不是实现（用什么技术做到）。三条格式纪律：

1. 一条一个行为，编号管理。"FR-3：单次导出上限 500 篇，超出时提示分批导出"——编号让评审意见、测试用例、变更记录都能精确锚定到条目；"如上所述"式的散文需求无法被引用，也就无法被验收
2. 三纪律继续生效：正面写（说系统做什么）、具体写（数字和条件明确）、客观写（不用"快速""友好"等品味词）。写完自查每条是否可检验——测试能不能对着它直接写用例？
3. 标注优先级：沿用 MoSCoW，直接在条目上标 Must/Should/Could——排期紧张时砍哪条，文档里已有答案，不用再开一次会

user story：好用的开头，不够的结尾

行业里常见把需求写成 user story 格式："作为〔角色〕，我想要〔行为〕，以便〔价值〕"。它的价值是强迫你写全"谁 + 干嘛 + 图什么"——正好接住上一课的角色和场景。但要清醒它的局限：story 是需求的标题，不是需求的全部。"作为学习者，我想批量导出笔记，以便迁移到自己的工具"——工程师读完仍然不知道：格式是什么？上限多少？导出中断怎么办？所以成熟的写法是 story 当帽子，条目化的行为定义当身体：

Story：作为学习者，我想批量导出全部笔记，以便迁移到自己的复习工具。

• FR-1（Must）：用户在笔记页可发起全量导出，产物为 zip 包
• FR-2（Must）：zip 内每篇笔记为独立 .md 文件，文件名取笔记标题，非法字符替换为下划线
• FR-3（Should）：导出进行中显示进度，可取消；取消不产生部分文件

工作流：主流程只是及格线

工作流（Workflows）部分先画主流程（happy path）：用户一步步顺利走完的路径，用编号步骤或流程图表达。这部分人人会写——真正的分水岭在后半句："exception conditions across scenarios"，各场景下的异常。

边界情况：系统枚举法

"想到哪写到哪"是边界情况的头号敌人。给你一张六问清单，对每个主流程逐一过筛：

六问	在问什么	导出功能的例子
空了呢？	数据为零/字段为空	一篇笔记都没有时，导出入口置灰还是可点？
爆了呢？	极值/超限	500 篇上限触发时提示什么？单篇 10MB 的超长笔记呢？
断了呢？	网络/服务中断	导出到一半断网，重试还是作废？有没有部分文件泄出？
重了呢？	重复/并发操作	连点三次导出按钮，排队、合并还是拒绝？
没权呢？	权限/登录态	登录过期后点导出，报错还是先引导重新登录？
悔了呢？	中途取消/回退	取消导出后系统处于什么状态？（接结构层：撤销优于确认）

每个异常写两样东西：触发条件 + 系统行为（用户看见什么、数据处于什么状态）。处理方案的裁决标准直接用结构层的三级预案：能预防的预防（上限做成分页导出，"爆了"就不存在）、能挽回的给撤销、只能报错的说人话并给出路。

✍️ 练习

练习 1：把 story 写成身体

给这条 story 补出条目化需求（至少 4 条，带编号和 MoSCoW 标注）："作为学习者，我想给写错的 Quiz 答案做标记，以便复习时优先重做错题。"

✅ 参考答案

• FR-1（Must）：Quiz 提交后，答错的题目自动标记为"错题"，无需用户手动操作
• FR-2（Must）：复习页新增"错题"筛选，默认按最近答错时间倒序
• FR-3（Should）：同一题再次答对后，错题标记自动清除；清除记录保留在答题历史中
• FR-4（Could）：错题可手动"忽略"（不再进入错题列表），可在设置中恢复
• FR-5（Won't 本期）：错题导出为 Anki 卡片——已有整卡导出通道，暂不重复建设

对照检查：每条是否可检验（测试能直接写用例）？是否只说行为不说实现（没出现"加一张错题表"这类数据库语言）？FR-1 的"自动标记"是不是替用户做掉了最高频决定（框架层的默认值思维）？

练习 2：六问扫一个真实流程

选你产品里（或常用产品里）一个三步以上的流程（发帖、下单、上传……），用六问清单逐一过筛，写出至少 5 个边界情况的"触发条件 + 系统行为"。写完标注：哪几个是你以前从没想过的？

✅ 参考思路

以"上传头像"为例：空（不选文件直接点确定 → 按钮应禁用而不是报错，预防级处理）、爆（20MB 原图 → 前端压缩后上传并告知，而非拒绝）、断（上传中断网 → 保留旧头像，提示重试，绝不出现半张图）、重（连点上传 → 后一次覆盖前一次，进行中禁用按钮）、权（登录过期 → 保存现场，重新登录后继续）、悔（上传成功想换回 → 是否保留历史头像？这一问常暴露一个没人定义过的产品决策）。

普遍规律：六问里"悔了呢"和"重了呢"最常挖出没人定义过的产品决策——它们不是技术问题，是 PRD 作者的职责。

📝 随堂测验

随堂测验0 / 5 题正确

1. 功能需求条目要编号（FR-1、FR-2……）的原因是？

A显得正式B让评审意见、测试用例、变更记录能精确锚定到条目——散文式需求无法被引用，也就无法被验收C方便统计工作量D编号越多绩效越好

2. user story 格式的正确定位是？

A有 story 就够了，工程师会自己脑补细节Bstory 是需求的帽子（谁+干嘛+图什么），身体仍需条目化的行为定义——格式/上限/异常 story 里都没有Cstory 已过时，不要使用Dstory 只适合敏捷团队

3. 边界情况的“六问清单”是？

A谁、何时、何地、为何、如何、多少B空了呢、爆了呢、断了呢、重了呢、没权呢、悔了呢——对每个主流程逐一过筛C能用吗、好用吗、爱用吗D前端、后端、数据库、网络、安全、性能

4. 每个边界情况必须写清的两样东西是？

A责任人和工期B触发条件 + 系统行为（用户看见什么、数据处于什么状态）C出现概率和风险等级D竞品的处理方式

5. 关于边界情况的枚举深度，正确的度是？

A越多越好，穷尽一切可能B六问过筛 + 评审补一轮即可冻结——目标是消灭可预见的意外，为千年一遇做三层防护是另一种范围蔓延C只写主流程，异常交给客服D让测试自己想

本课小结

• 功能需求 = 行为定义：一条一个行为、编号管理、MoSCoW 标注；三纪律（正面/具体/客观）+ 可检验自查
• story 当帽子，条目当身体——标题不能替代正文
• 工作流：主流程是及格线，边界情况才是分水岭（驾校路线 vs 真实路况）
• 六问枚举法：空了呢/爆了呢/断了呢/重了呢/没权呢/悔了呢，每个写"触发条件 + 系统行为"
• 处理方案用三级预案裁决；枚举要封顶，别为千年一遇建三层防护

下一课写 PRD 的"工程接口"：依赖、验收标准、成功指标——决定这份文档能不能顺利变成排期、测试和复盘的部分。