用途：让产品需求池保持精简、诚实、可用，而不是堆积好意与负罪感。
主要能力与约束： 卫生方面，要求至少每月审查并删减需求池；90 天未动的条目应重新排优先级或直接关闭；限制池子规模，若浏览超过 15 分钟即过长；应将“可开工”池与“想法停车场”分开；需求池不是承诺，只是排好序的选项。 条目质量方面，每个条目必须有清晰问题陈述、验收标准和粗略工作量估计；可按主题、用户群体、业务影响和状态打标签；前 10 个条目须详细到可立即开工；20 名之后的条目应为史诗或主题，而非细化工单；模糊条目（如“改进仪表盘”）必须细化或关闭。 梳理实践方面，须定期运行 grooming 会议；工程应参与以尽早发现可行性问题；过大条目须拆分到可放入一个迭代；协作估算而非 PM 单方面指派；grooming 须限时 30-60 分钟。 说不方面，对可预见未来不会做的条目应关闭；拒绝请求要有流程：确认、解释、记录；要区分“现在不做”与“永不做”并清楚传达；不应因愧疚或害怕拒绝而堆积条目；应追踪被拒条目的模式，若同一请求反复出现需调查。
反模式：无限池（500+ 无人读）、愧疚池（因重要人物多年前提出而保留）、未梳理迭代（拉入未精炼未估算条目）、活着的 Jira 墓地（无人真正在做的“进行中”项）、愿望清单（无优先级、估算与验收标准）。
使用方式：以 /backlog-management 施加约束到当前对话；或以 /backlog-management <context> 针对所述情境改进需求池实践。
限制：资料未提供具体工具集成、价格、平台或实施步骤，仅给出约束与反模式描述。