45 需求之坑
把需求视为与用户共同学习的反馈过程，将策略外置并用项目术语表稳定交流边界。
学习目标
- 能把模糊需求拆成可观察场景、假设、边界和用户反馈，而不是直接当作最终规格
- 能用用户协作、策略元数据和项目术语表减少需求、实现与验证之间的翻译损失
- 能在反馈失效、术语冲突和边界副作用出现时记录首个偏差、回退和需求更新
为什么 45 需求之坑值得单独学习
↡把模糊愿望转成可观察场景，通过提问、样例和反馈逐步确认用户真正需要什么的过程。“需求”不是用户一次性递交的完整包裹。提示75“无人确切知道自己想要什么”、提示76“程序员帮助人们理解他们想要什么”和提示77“需求是从反馈循环中学到的”共同指向一个实践：先承认未知，再让未知在可运行样例中变得可观察。
订单撤回功能能暴露这个坑。用户说“随时撤回订单”，可能指待支付取消、已支付退款、已发货拒绝或删除草稿。若开发者直接实现一个按钮，真正的权限、库存、发票、审计和用户提示会在上线后才暴露。
↡让用户、产品、开发、测试和领域专家围绕同一场景共同观察、提问、试验和确认的工作方式。提示78“和用户一起工作以便从用户角度思考”并不要求用户替团队设计系统，而是要求团队把用户目标、操作路径、错误恢复和价值判断放入同一个反馈现场。
先建立直觉：把变化点外置
↡把会变化的策略、规则或选择从稳定流程中分离出来，让项目能在反馈后调整而不重写全部实现。提示79“策略即元数据”提醒团队：哪些字段、规则、阈值或流程可调整，应该被显式记录和观察，而不是藏在代码分支和会议记忆里。
↡记录领域词、状态、动作、例外和拒绝条件的共享词汇表，保证需求、代码和测试使用同一含义。提示80“使用项目术语表”不是要求写一份静态文档，而是让词义变化能够被发现。订单的“取消”“撤回”“退款”必须分别写出触发者、时间、状态和外部副作用。
↡把观察结果反馈给需求模型、更新假设并再次验证的短周期过程，要求记录输入、变化、结果和下一步。Feedback Loop 的产物可以是一个被拒绝的假设、一个更精确的术语、一个新的验收样例或一条回退路径。反馈更快不等于需求更正确，仍要检查用户价值、质量和安全边界。
先预测：产品说“用户可以随时撤回订单”，如果团队只做成功路径演示，最可能遗漏的是付款、库存、权限还是审计？不要先猜结论；列出所有外部副作用，再用一个边界样本和用户协作确认哪条语义属于本次切片。
目录单元到教学证据
45 需求之坑
本 Topic 把提示75至提示80连成一条可失败链：需求发现提出问题，用户协作观察真实路径，策略元数据暴露可变选择，项目术语表固定共同语义，反馈循环更新需求。每个节点都要有对象、条件、所有者、首差和拒绝条件；只复述提示文字不算掌握。
六条提示如何进入实验
| 目录节点 | 实验问题 | 可保存证据 |
|---|---|---|
| 提示75：无人确切知道自己想要什么 | 哪些假设仍未由用户样例确认？ | 假设清单与未知项 |
| 提示76：程序员帮助人们理解他们想要什么 | 团队提供了哪些可运行选项？ | 用户选择与拒绝理由 |
| 提示77：需求是从反馈循环中学到的 | 哪次反馈改变了需求模型？ | 前后版本与首个偏差 |
| 提示78：和用户一起工作以便从用户角度思考 | 用户如何参与真实场景？ | 操作路径和恢复证据 |
| 提示79：策略即元数据 | 哪些规则可以调整而无需改流程？ | 策略字段、版本和阈值 |
| 提示80：使用项目术语表 | 哪些词会让需求与实现分叉？ | 词义、例外和拒绝条件 |
三步需求反馈路径
先发现未知与边界
冻结 2020 年中文第 2 版目录坐标和当前项目基线，列出用户目标、未知假设、外部副作用、权限和不可逆状态。不要把猜测写成验收标准。
需求与用户协作图
需求发现不是问完问题就结束，而是让用户目标、可运行样例和外部约束在同一个边界内逐步收敛。
Feedback Loop 与回退边界
反馈循环必须有可拒绝的条件：用户价值下降、权限越界、库存不一致、审计缺失或术语分叉时，先回退到已知安全状态，再更新假设和范围。
专属案例：订单撤回
产品团队给出一句需求：“用户可以随时撤回订单。”先做 Requirement Discovery：确认订单状态、付款、库存、发票、通知、审计和权限；再进行 User Collaboration，让用户操作一个待支付订单和一个已支付订单；最后把 Strategy Metadata 设为可配置的撤回窗口，并把 Project Glossary 中的“撤回”“取消”“退款”分别定义。
requirements_case:
claim: 用户可以撤回订单
unknowns:
- 已支付订单是否进入退款
- 已发货订单是否允许撤回
- 库存释放和审计如何记录
strategy_metadata:
pending_cancel_window: 30m
feedback: 待支付订单的可运行撤回场景
boundary: 已发货订单拒绝直接撤回
rollback: 发现库存或权限异常时关闭入口并恢复原状态这个案例把提示75至提示80变成一份验证记录：未知是什么，用户如何参与，哪个策略可调整，术语怎样固定，反馈如何更新需求。一次成功演示不能替代失败、边界和用户恢复证据。
选择与拒绝矩阵
| 评审问题 | 选择本 Topic 实践的证据 | 应拒绝当前做法的信号 |
|---|---|---|
| 发现 | Requirement Discovery 把假设转成可观察样例 | 需求文档被当成永远完整的规格 |
| 协作 | User Collaboration 产生用户路径和选择理由 | 用户只在上线后才第一次看到行为 |
| 变化 | Strategy Metadata 外置可调整策略和阈值 | 每次策略变化都要重写稳定流程 |
| 语义 | Project Glossary 记录状态、例外和拒绝条件 | 产品、代码、测试对同一词有不同含义 |
| 反馈 | Feedback Loop 能改变需求并保留回退 | 只演示成功，不保存失败和用户价值 |
常见误区
本章回顾
掌握 45 需求之坑的标志，不是背下提示75至提示80，而是能沿着“用户目标 → 观察 → 试验 → 反馈 → 需求更新”链把模糊要求转成可观察结果。Requirement Discovery 发现未知，User Collaboration 让用户参与，Strategy Metadata 外置变化，Project Glossary 固定语义，Feedback Loop 更新需求；当团队只追求成功演示、隐藏副作用或删除失败记录时，应拒绝当前需求判断。
可验证练习
练习
本组练习覆盖 45 需求之坑、提示75：无人确切知道自己想要什么、提示76：程序员帮助人们理解他们想要什么、提示77：需求是从反馈循环中学到的、提示78：和用户一起工作以便从用户角度思考、提示79：策略即元数据 和 提示80：使用项目术语表，要求把每条提示转成可重放证据。
问题 1： 用户说“随时撤回订单”，第一轮 Requirement Discovery 应确认什么？
问题 2： 撤回窗口从 30 分钟改成 10 分钟，如何避免到处改代码？
问题 3： 产品、开发、测试对“退款”的含义不同，下一步怎么做？
名词解释
名词解释
本章出现的专业名词，用大白话再讲一遍。
- Requirement Discovery
通过提问、样例和反馈逐步确认用户真正需要什么的过程。
- User Collaboration
让参与者围绕同一场景共同观察、提问、试验和确认的工作方式。
- Strategy Metadata
把可变化的策略、规则或阈值从稳定流程中分离出来的记录方式。
- Project Glossary
记录领域词、状态、动作、例外和拒绝条件的共享词汇表。
- Feedback Loop
通过观察、反馈、更新假设和再次验证来逐步修正需求的短周期过程。
前后导航
来源与改写范围
- Pragmatic Programmer 作者页面：核对 45 需求之坑的主题与版本信息。
- 中文目录页面：核对提示75至提示80的公开目录范围。
- 出版社书目信息：交叉核对中文译本出版信息与版本边界。