夜雨聆风AI 项目管理实战 · 第2篇 · 需求管理
AI 需求评审助手
砍掉 30% 无效需求，项目不再无限膨胀
需求三维评估 · 歧义自动识别 · 隐性依赖分析
优先级矩阵 · 评审会 AI 辅助 SOP
系列第2篇需求评审范围管控
项目延期的真正元凶，往往不是执行慢，而是需求范围失控。
产品说「这个需求很简单」，研发估了两天，评审时大家觉得没问题，最后做了两周还没完——因为没人在一开始就追问：这个需求的边界在哪里？依赖哪些其他模块？如果不做会怎样？
这篇给出 AI 需求评审工作流，从源头控制项目范围，让每一条进入开发的需求都是值得做的、定义清晰的、成本明确的。
01 需求范围失控的三个根源 |
R1 | 「简单需求」没有定义边界 「做个导出功能」——导出什么格式？多少条数据？要不要分页？支持筛选吗？这些问题没问清楚，研发做到一半发现方向不对，返工成本 3 倍于原始估算。 |
R2 | 隐性依赖没有暴露 「新增权限控制」——依赖用户体系改造，而用户体系改造还没开始。这条需求排进了本迭代，但实际上根本做不了，直到开发动手才发现依赖缺失。 |
R3 | 低价值需求占用高成本资源 一个「锦上添花」的 UI 优化需求，占用了核心研发 3 天——而这 3 天本可以用来完成真正影响用户体验的功能。没有价值评估，资源就会被低优先级需求消耗。 |
02 · 核心框架 需求三维评估框架 价值 × 成本 × 风险，三维定位每条需求 |
每条需求进入评审前，先用三维框架定位它：
1=锦上添花 | |||
1=>20人天 | |||
1=依赖复杂高风险 |
| 综合分 = 业务价值×0.40 + 实现成本×0.35 + 风险低×0.25 # 综合分 ≥ 4.0 → 本迭代必做 # 综合分 3.0–4.0 → 本迭代选做，视资源 # 综合分 < 3.0 → 推迟或砍掉 |
✅ 实测效果：用这套框架评审一个 30 条需求的迭代计划，平均会有 8–10 条（约 30%）被推迟或砍掉，剩下的 20 条质量更高，交付成功率显著提升。
03 AI 需求歧义识别：完整提示词 把需求描述喂给 AI，自动找出所有模糊点 |
| ## 需求描述 ## 任务 请对以上需求做完整的歧义识别，输出以下内容： 【1. 边界模糊点】 需求描述中，哪些地方没有明确边界？ 格式：「[模糊表达]」→ 需要澄清：[具体问题] 【2. 隐性假设】 这个需求暗含了哪些前提条件？如果前提不成立会怎样？ 【3. 缺失的验收标准】 「做完」的标准是什么？怎么判断这个需求已经满足？ 请给出 Given/When/Then 格式的验收标准建议（至少 3 条） 【4. 需要向业务方确认的问题清单】 按优先级排序，最多 5 个问题 ⚠️ 原则：宁可多问，不要假设。一个没问清楚的问题，会在开发阶段产生 5 倍的返工成本。 |
实际示例
| 【边界模糊点】 「导出」→ 需要澄清：什么格式？Excel / CSV / PDF？ 「订单」→ 需要澄清：所有状态的订单，还是特定状态？ 【隐性假设】 · 假设用户有权限查看所有被导出的订单（权限体系是否已支持？） · 假设导出是同步的（数据量大时是否需要异步 + 邮件通知？） 【验收标准建议】 Given 用户已选择 100 条订单 When 点击导出 Then 30 秒内下载 Excel 文件，包含所有选中订单的完整字段 Given 用户选择超过 1000 条 When 点击导出 Then 提示「导出数量超限，最多支持 500 条」 【待确认问题】 1. 导出文件格式（Excel/CSV 二选一，还是都要？） 2. 单次最大导出量限制 3. 需要包含哪些字段（全部还是可自定义？） |
04 · 关键能力 隐性依赖分析：找出「做不了」的需求 |
隐性依赖是排期计划最大的破坏者——需求看起来独立，但实际上依赖另一个还没完成的模块。AI 可以系统性地把这些依赖挖出来：
| ## 当前需求 ## 已有系统模块：[列出当前系统的主要模块] ## 本迭代其他需求：[列出同迭代的其他需求] ## 请分析： 1. 这个需求依赖哪些已有模块？这些模块是否已经支持所需能力？ 2. 这个需求和本迭代其他需求是否有执行顺序依赖？ 3. 是否依赖外部系统/第三方服务？这些依赖是否已确认可用？ 4. 如果某个依赖不满足，这个需求能否拆分为「可独立完成的部分」？ 输出：依赖清单 + 依赖风险评级（高/中/低）+ 建议处理方式 |
⚠️ 建议在每次迭代评审会前，用这个提示词扫描所有需求。平均每个迭代能提前发现 2–3 个「看起来可以做但实际上做不了」的依赖问题，避免开发到一半才暴露。
05 需求优先级矩阵：让老板一眼看懂取舍 |
把所有需求按「业务价值」和「实现成本」放入四象限，老板和项目经理可以快速做资源决策：
高价值 · 低成本 立刻做 ✅ 这里的需求是黄金需求——高ROI，优先排进本迭代，不要犹豫。 | 高价值 · 高成本 拆解后做 ⚡ 价值高但成本高，需要拆分成小需求，逐步交付，避免一次性吃太多资源。 |
低价值 · 低成本 有空再做 📋 成本低但价值也低，放进 Backlog，迭代有余量时再做，不要占用核心资源。 | 低价值 · 高成本 直接砍掉 ❌ 成本高但价值低，这类需求是项目的「毒药」——消耗资源却不带来价值，坚决放弃。 |
优先级矩阵生成提示词
| 以下是本迭代的需求列表，请按「业务价值（1–5）× 实现成本（1–5）」 对每条需求进行评分，并归类到四象限： 输出格式： | 需求名称 | 业务价值 | 实现成本 | 综合分 | 象限 | 建议 | |---------|---------|---------|-------|------|------| 最后给出：本迭代建议做的需求清单（按优先级排序） 以及：建议推迟或砍掉的需求 + 理由 |
06 · 落地SOP AI 辅助评审会 SOP 2小时评审会浓缩到45分钟 |
会前 | AI 预处理：歧义识别 + 依赖分析 + 优先级评分 项目经理把需求列表喂给 AI，跑完三个提示词，把结果整理成评审材料，提前发给参会人。会议上只讨论「AI 标记的高风险项」，不要逐条过所有需求。 |
会中 | 只讨论三类需求 ① 需要澄清的歧义点（AI 标记的问题清单）② 依赖风险高的需求（是否本迭代能满足依赖）③ 价值争议需求（象限判断有分歧的）。其他需求按 AI 评分直接确定。 |
会后 | AI 生成评审纪要 + 迭代计划 把会议结论喂给 AI，生成：本迭代确认需求清单（含验收标准）、推迟需求清单（含原因）、待确认问题跟进人。15 分钟内完成，发给所有相关人。 |
总结 需求管控的本质 |
AI 需求评审不是替代人的判断，而是把那些「应该问但忘了问」的问题强制前置——这才是从源头控制项目范围、控制项目成本的正确方式。 |
