需求池 427 条，最近半年动过的不到三分之一 · 「进来了没人清、历史需求没人敢删」—— 每一条都是不敢碰的存量
本页展示的是「应该怎么跑、每一步看什么、交付什么」，用的是真实业务格式的脱敏构造数据， 不宣称已接入客户生产系统，也不承诺任何效率提升百分比。 案例设定：驭数科技（虚构）清淤日：江晓接手需求池的第二年 —— 累计 427 条，状态「待评估」的 190 多条，最早的一条是 2023 年的「支持 IE 浏览器」。她想过清理，但每一条都要读、都要判断、都要问「当时谁提的」—— 一天清了 11 条就放弃了。沈知行在季度会上说：「需求池是个仓库还是个垃圾场，取决于有没有人清淤。」
注意标橙色那一份 —— 05_需求管理员离职交接记录.txt。它交接记录 · 2024-Q4，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。
短是因为「沉积判定规则、复活信号识别、政治敏感度提示」都在能力包里。产品经理只要把现状导出扔进来。
江晓把需求池全量、发版记录、客户对照、重复簇、离职交接记录全部扔进来 —— 清淤的判断一半在池子里，一半在池子外的对照数据里。
| 层 | 条数 | 判定 | 动作 |
|---|---|---|---|
| 待评估 · 超 6 个月无动静 | 96 | 沉积 | 归档建议（逐条附理由） |
| 待评估 · 半年内有互动 | 94 | 观察 | 保留 · 下季度再看 |
| 已实现未销账 | 12 | 销账 | 对照发版记录逐条关闭 |
| 已拒绝 · 有复活信号 | 11 | 复活 | 进入复活评估（旧决策对照） |
| 重复簇内 | 52 | 合并 | 7 组合并建议（含 1 个 bug 拆分） |
| 427 条全覆盖 | 动作涉及 265 条 | — | 保留 320 · 归档 96 · 复活 11 |
分层先于判断 —— 「96 条沉积」不是印象是计数。清淤报告的说服力来自分母：427 条全量重读，一条都没偷偷跳过（剔除规则与剔除量全部在案）。
| 沉积原因 | 条数 | 典型样例 | 入池标准修订建议 |
|---|---|---|---|
| 提出客户已流失 | 35 | IE 浏览器（2023） | 入池时登记客户在册状态 |
| 已被新版覆盖 | 28 | 旧报表样式类 | 发版时销账动作进发布检查清单 |
| 环境类一次性问题 | 19 | 某型号扫码枪临时适配 | 环境类问题走工单不走需求池 |
| 无来源无法评估 | 14 | 来源栏空白的口头需求 | 无来源不正式入池（RQ-01 规则） |
| 合计 | 96 | — | 4 条标准修订建议 |
96 条归档建议按成因分四类 —— 每类对应一条入池标准的修订。清淤的终点不是池子变干净，是同样的垃圾以后进不来。
| 复活候选 | 旧状态 | 复活信号 |
|---|---|---|
| 批量导入 | 被拒 2 次 | CX-02：华正续约卡点，郑海洋已承诺 Q3 |
| 离线巡检模式 | 缓行 | 提出人流失但场景被新承诺激活 |
| 数据导出（主需求） | 已拒绝 | RQ-01 六处来源 + 前提变更（API 延期） |
| 其余 8 条 | — | 各自的复活信号详见附表 |
11 条复活建议里，前 3 条直接关联续约与在册客户 —— 清淤的价值排序：复活建议 > 归档建议 > 销账 —— 因为归档省的是注意力，复活救的是钱。
| 敏感原因 | 条数 | 处理建议 |
|---|---|---|
| 提出人是陈默的关系客户 | 4 | 归档前口头知会销售总监 |
| 提出客户在续约谈判期 | 3 | 归档暂缓至续约落定 |
89 条常规归档走批量确认、7 条敏感单列 —— 清淤清出政治事故比不清还糟。这一档是「历史需求没人敢删」的真实原因：不是不敢删需求，是不敢删「关系」。
| 指标 | 本季 | 下季基线 |
|---|---|---|
| 池内总量 | 427 → 331 | 目标 ≤ 350（新增入池收紧） |
| 待评估沉积率 | 45% | 目标 ≤ 20% |
| 销账完成 | 12/12 | 发布检查清单含销账项 |
| 标准修订 | 4 条 | 入池门槛生效后新沉积可望减半 |
报告的最后一栏是「下季基线」—— 清淤从一次性运动变成季度例行：每季度的归档/复活/销账三个数字进趋势线。需求池的健康度和体重一样，一次清淤不算数，持续监测才算。
答不上来的问题，比答得漂亮的问题更能决定这场演示的结果
返回场景引入页，可查看完整案例背景、演示步骤与提示词