需求池乱了，先用 AI 清来源、状态和下一步动作

教程定位

这篇教程解决什么问题

需求池乱起来的时候，最明显的症状不是条目多，而是每条需求都像“可能很重要”。客户反馈、老板临时想法、销售转述、客服工单、技术优化、竞品截图、运营建议、研发顺手记下的问题，全都堆在同一个表里。有人把状态写成“待评估”，有人写“处理中”，有人写“已记录”，还有一批空着。几个月后再打开，团队已经分不清哪些是重复项，哪些已经被版本覆盖，哪些只是问题描述不完整，哪些真的可以拿进评审会。

这篇教程解决的不是“哪个需求优先做”，而是更前置的一步：先把需求池治理到可以讨论的状态。用 AI 根据来源、提交时间、当前状态、责任人和下一步动作，帮你清出重复项、过期项、待澄清项和可进入评审项。它的价值不是替产品经理做判断，而是把一堆混乱记录整理成一张可复核的清理表，让团队知道下一步该问谁、查什么、合并哪几条、关闭哪些明显失效记录。

很多团队会跳过这一步，直接让 AI 给需求打优先级。这个动作很危险。因为需求池里的“需求”并不都处在同一个层级：有的是客户真实场景，有的是客服问题，有的是 Bug，有的是老板提出的方向，有的是研发想补技术债，有的是销售为了推进客户而转述的一句话。材料还没分层，就让 AI 排优先级，输出通常会显得很聪明，却无法负责。

更稳的用法是：要求 AI 只做“清理和分流”，不判断要不要开发。它可以标出疑似重复，提醒状态长期未更新，识别缺少来源或责任人的条目，找出提交时间过久但版本计划已经覆盖的记录，把表格里应该进入需求评审的条目单独列出来。至于是否值得做、什么时候做、投入多少资源、是否进版本计划，仍然由产品负责人结合战略、资源、客户价值和技术成本判断。

最终交付物是一份需求池清理表。表里至少包含：原始需求 ID、标准化标题、来源类型、提交时间、当前状态、责任人、证据摘要、重复关系、是否过期、待澄清问题、下一步动作和清理建议。拿到这张表后，产品运营可以发起补充信息，产品经理可以准备评审材料，研发和客服也能知道哪些记录被合并、哪些还需要补事实。

使用场景

什么情况下最适合用这一套

你可能是产品运营，也可能是产品经理。团队已经运转了一段时间，需求池从最开始的几十条变成几百条。早期大家很积极，任何想法都先记下来：客户在群里抱怨“导出字段太乱”，客服在工单里写“用户找不到退款入口”，销售说“某大客户希望支持批量审批”，老板在周会上提出“要不要做一个行业模板”，研发在改代码时顺手记了“权限模块需要重构”。

这些记录本来都有价值，问题是它们被放进了同一张表，并且长期没人维护字段。来源字段有的写“客户”，有的写“销售反馈”，有的写“群里说的”，有的直接为空。状态字段更乱：待评估、评审中、已排期、暂缓、进行中、done、先记着、客户催、老板关注、研发建议，各种写法混在一起。责任人字段有时写产品经理，有时写提交人，有时写“待定”。下一步动作几乎没有统一格式。

到了版本评审前，团队开始翻需求池，发现几个典型问题：

如果这时直接开评审会，会议很快会被拖进低效讨论。大家会围绕标题猜含义，围绕模糊状态争论是不是已经处理过，围绕“客户很急”追问到底哪个客户、什么时候说的、影响多大。产品经理不是在判断产品方向，而是在现场补台账。

这篇方法适合以下情况：

它不适合用来做最终排期，也不适合把需求一键分成 P0、P1、P2。需求池清理是进入判断前的卫生工作，不是产品决策本身。

• 同一个客户问题被记录了 5 次，标题不同，但都在说导出字段、筛选条件和下载格式。
• 有些需求 4 个月前提交，当时的版本已经解决了一部分，但状态还停在“待评估”。
• 有些条目看起来像需求，其实是客服问题或配置说明缺失，应该进 FAQ 或客服流程。
• 有些条目只有一句“老板说看板要高级一点”，没有场景、目标用户、业务指标和负责人。
• 有些条目可能真的值得评审，但缺少提交时间、客户数量、影响范围或原始反馈。
• 需求池已经积累到几十条或几百条，字段格式不一致。
• 需求来源混杂，包括客户反馈、客服工单、内部会议、老板想法、销售转述、技术优化和版本计划。
• 状态字段长期没人维护，很多条目停留在“待评估”“进行中”“先记着”。
• 团队准备做版本评审、季度规划或需求复盘，但还没有一张干净的需求池清单。
• 你希望 AI 帮你做整理、归类、合并和补信息提醒，而不是替团队决定优先级。

材料准备

开始前先把材料和边界备齐

让 AI 清理需求池前，先准备五类材料。材料不一定完整，但每类都要标清来源和时间。需求池治理最怕“看起来像事实”的混合文本，例如“客户都需要批量导出，老板也很重视”。这句话同时包含客户反馈和内部判断，如果不拆开，AI 很容易把它写成一个强需求。

第一类是需求池导出。至少包含需求 ID、原始标题、原始描述、提交人、提交时间、来源、当前状态、责任人、关联版本、备注。如果现有表格没有这些字段，也要把现有字段完整导出，不要先人工美化。AI 需要看到混乱本身，才能判断哪些字段需要标准化。

第二类是提交记录。包括表单提交、群消息、客服工单、销售记录、会议纪要、邮件、用户访谈片段。提交记录用来还原需求来源。比如需求池里写“导出功能不好用”，但原始客户反馈是“订单导出后缺少渠道字段，财务每周要手工补”，这两者的清晰度完全不同。

第三类是客户反馈。客户反馈最好保留原话、客户类型、反馈时间、使用场景和影响后果。不要只写“多个客户反馈”。如果确实没有客户原话，可以标成“销售转述”或“客服汇总”，不要让 AI 把它升级成强证据。

第四类是内部会议纪要。老板想法、业务负责人建议、运营会议提出的问题，都可以进入需求池，但必须标成内部来源。内部来源不等于不重要，只是它和客户反馈不是同一种证据。清理时要把“内部想法”“客户问题”“技术债”“客服流程问题”拆开。

第五类是版本计划。包括最近几个版本已经上线的功能、正在开发的事项、确认暂缓的事项、已关闭的旧需求。版本计划能帮助 AI 识别过期项和已覆盖项。比如 3 月提出“支持按部门筛选导出”，5 月版本已经上线部门筛选，但需求池状态还没改，这条就需要标成“疑似已覆盖，待产品确认关闭或补充剩余缺口”。

建议先把材料整理成下面的输入包：

| 材料 | 必要字段 | 用途 | 注意点 | | --- | --- | --- | --- | | 需求池导出 | ID、标题、描述、提交时间、来源、状态、责任人 | 清理主表 | 不要先删掉看似无用的旧记录 | | 提交记录 | 原始文本、提交人、时间、渠道 | 还原证据 | 区分原话、转述和内部判断 | | 客户反馈 | 客户类型、场景、影响、原话 | 判断来源质量 | 不让 AI 推断客户数量和影响范围 | | 内部会议纪要 | 会议时间、提出人、背景、结论 | 识别内部想法 | 不把老板想法写成客户需求 | | 版本计划 | 已上线、开发中、暂缓、关闭 | 识别过期和覆盖 | 只标“疑似”，最终由负责人确认 |

还要提前定义标准字段。至少建议统一这几个：

| 字段 | 推荐选项 | 说明 | | --- | --- | --- | | 来源类型 | 客户反馈 / 客服工单 / 销售转述 / 内部会议 / 老板想法 / 技术优化 / 数据观察 / 版本遗留 | 只描述来源，不代表重要性 | | 清理状态 | 疑似重复 / 疑似过期 / 待澄清 / 可进入评审 / 转客服处理 / 转技术债 / 已覆盖待确认 | 用于治理，不是开发状态 | | 证据强度 | 强 / 中 / 弱 / 未知 | 原话和数据通常更强，转述和猜测更弱 | | 下一步动作 | 合并 / 关闭确认 / 补充信息 / 进入评审 / 转交客服 / 转交研发 / 保留观察 | 表示清理动作，不表示排期 |

在提示词里明确告诉 AI：本次任务只做需求池治理，不判断需求优先级，不输出“应该开发/不该开发”，不替团队定版本计划。对于证据不足的条目，只能标“待澄清”；对于可能已被版本覆盖的条目，只能标“疑似过期”或“已覆盖待确认”；对于重复项，只能提出合并建议，不能删除原始记录。

实操流程

按这套步骤把工作跑起来

第一步，先统一来源，不急着改标题。

需求池里最容易混乱的是来源。很多条目标题很像需求，实际上来源完全不同。比如“希望导出更灵活”可能来自真实客户反馈，也可能来自销售觉得客户会需要，也可能是老板看竞品截图后提出的方向。清理时先让 AI 根据原始记录，把每条标成客户反馈、客服工单、销售转述、内部会议、老板想法、技术优化、数据观察或版本遗留。

如果来源无法确认，不要让 AI 猜。统一标成“来源未知，待补充”。来源未知的条目不一定没有价值，但它不能直接进入需求评审。评审会需要讨论的是“有证据的用户问题”，不是“表里躺了很久的一句话”。

第二步，标准化状态字段。

很多需求池的状态字段混着两类东西：一类是需求生命周期状态，比如待评估、评审中、已排期、开发中、已上线、已关闭；另一类是沟通情绪或提醒，比如客户催、老板关注、先记着、再看看。清理时要把它们拆开。

可以要求 AI 把原始状态保留一列，再新增“清理状态”。原始状态不动，避免破坏历史；清理状态用于当前治理。比如：

第三步，识别疑似重复。

重复项不一定标题相同。它们可能说的是同一个问题的不同侧面。例如“导出字段不全”“导出没有渠道字段”“财务导出后要手工补字段”“订单导出筛选太少”，这些可能属于同一个导出能力问题，也可能是两个不同问题：字段缺失和筛选条件不足。AI 可以先做“疑似重复分组”，但不要直接合并。

比较稳的输出方式是：为每组疑似重复给一个合并主题，并列出包含的原始 ID、相同点、差异点、建议保留主记录和需要人工确认的问题。比如“R-021、R-047、R-063 都与订单导出有关；R-021 关注渠道字段缺失，R-047 关注按部门筛选，R-063 关注下载格式，建议合并到‘订单导出字段与筛选优化’主题下，但保留三个子问题等待评审拆分”。

第四步，识别疑似过期。

过期项有几种。第一种是需求已经被版本计划覆盖，但状态没有更新。第二种是需求依赖的业务流程已经变化，比如旧审批流程下的问题在新流程中不存在了。第三种是提交时间很久，来源和责任人都不清楚，也没有后续反馈。第四种是当时针对某个临时活动或客户项目提出，现在活动已结束、项目已关闭。

AI 可以根据提交时间和版本计划标“疑似过期”，但不能替你关闭。更合适的下一步动作是“请责任人确认关闭或补充仍存在的场景”。如果一条需求 6 个月前提交、状态未更新、来源未知、没有客户反馈、相关模块已改版，那么它应该进入“过期确认清单”，而不是继续占据待评审列表。

第五步，识别待澄清项。

待澄清项通常看起来像需求，但缺少关键事实。比如“希望首页更智能”“客户觉得审批不好用”“老板说报表要更高级”“客服说退款流程有问题”。这些条目不应该直接被删除，因为它们可能指向真实问题；也不应该直接进入评审，因为它们缺少场景。

让 AI 为每条待澄清项生成 2 到 4 个澄清问题。问题要具体，围绕来源、场景、影响、频率、现有处理方式和责任人。例如“客户觉得审批不好用”可以追问：哪个客户、哪个角色、哪类审批、最近一次卡在哪里、影响了什么结果、现在如何绕过、是否有工单或原话。

第六步，筛出可进入评审项。

可进入评审不等于应该开发。它只表示这条需求具备基本讨论条件：来源清楚、场景可描述、影响范围有线索、状态不是已覆盖或明显过期、责任人明确、下一步可以进入需求评审会。AI 输出时必须避免写“高优先级”“建议立刻做”“应排入下版本”，而应该写“材料足够进入评审，需由产品负责人判断价值和优先级”。

一条可进入评审的记录通常应该具备：

第七步，生成清理表和行动清单。

最终不要只要一段总结。让 AI 输出两张表：一张是“需求池清理表”，逐条列出标准化结果；另一张是“下一步行动清单”，按责任人汇总需要做的动作。产品运营拿行动清单去追补信息，产品经理拿清理表准备评审，研发和客服知道哪些条目转给自己处理。

第八步，人工复核并回写需求池。

AI 输出后，人工至少检查四件事：重复项有没有误合并，过期项有没有误判，可评审项有没有混入证据不足的记录，待澄清问题是不是能让提交人补得出来。确认后再回写需求池。回写时建议保留原始标题、原始描述和原始状态，新增标准化字段，不要把历史记录覆盖掉。

• 原始状态“客户催”：清理状态可能是“待澄清”，下一步是补客户、场景、影响范围。
• 原始状态“先记着”：清理状态可能是“来源未知，待补充”。
• 原始状态“已排期”：清理状态可能是“与版本计划核对”，下一步是确认是否还在开发范围内。
• 原始状态“done”：清理状态可能是“已覆盖待确认”，下一步是确认是否关闭原需求或拆剩余问题。
• 来源清楚，例如客户原话、客服工单、数据观察或明确内部会议。
• 提交时间和最近更新时间清楚。
• 问题场景清楚，能说明谁在什么情况下遇到什么问题。
• 影响范围至少有线索，例如客户数量、工单数量、业务指标、人工成本或风险后果。
• 当前状态不与版本计划冲突。
• 有责任人可以补材料或参加评审。

输入示例

可以直接参考的输入材料

下面是一份脱敏后的虚构输入。真实使用时可以从需求池导出 30 到 100 条先做试跑，确认规则可用后再扩展到全量。

这个输入样例的关键是把版本计划和原始需求一起给 AI。只给需求池，AI 很难判断某条是否已经被覆盖；只给版本计划，又无法看到旧状态为何没更新。两者合在一起，AI 才能做“疑似过期”和“已覆盖待确认”。

【本次任务】
请帮我清理一批需求池记录。目标是做需求池治理，不是判断需求优先级，也不是决定哪些需求要开发。请只根据来源、提交时间、当前状态、责任人、版本计划和原始反馈，识别重复项、过期项、待澄清项和可进入评审项。

【标准字段】
来源类型：客户反馈 / 客服工单 / 销售转述 / 内部会议 / 老板想法 / 技术优化 / 数据观察 / 版本遗留 / 来源未知
清理状态：疑似重复 / 疑似过期 / 待澄清 / 可进入评审 / 转客服处理 / 转技术债 / 已覆盖待确认
下一步动作：合并确认 / 关闭确认 / 补充信息 / 进入评审 / 转交客服 / 转交研发 / 保留观察

【版本计划】
- 2026-05-12 已上线：订单导出支持按部门筛选，新增渠道字段。
- 2026-06-03 已上线：退款入口从“订单详情-更多”移动到“订单详情-售后”。
- 2026-06-20 开发中：审批列表增加超时标记，预计 2026-07-10 发布。
- 已确认暂缓：自定义首页看板，原因是指标口径未统一。

【需求池导出】
ID: R-021
标题: 订单导出字段不全
描述: 客户说导出后还要手工补渠道字段，财务每周都要处理。
提交时间: 2026-03-18
来源: 客户微信群，客户 A 财务
当前状态: 待评估
责任人: 产品-小林

ID: R-047
标题: 导出要支持按部门筛选
描述: 销售反馈客户 B 想按部门导订单，避免每次导全量。
提交时间: 2026-04-02
来源: 销售转述
当前状态: 客户催
责任人: 空

ID: R-063
标题: 导出格式太难用
描述: 客服工单 4582，用户说下载的表要调整列顺序才能给财务。
提交时间: 2026-06-24
来源: 客服工单
当前状态: 新建
责任人: 产品-小林

ID: R-088
标题: 首页要更智能
描述: 老板周会提到竞品首页有很多卡片，我们也要高级一点。
提交时间: 2026-05-30
来源: 内部会议
当前状态: 先记着
责任人: 产品-小周

ID: R-102
标题: 退款入口找不到
描述: 客服反馈近两周 9 个用户问退款入口在哪里。
提交时间: 2026-06-01
来源: 客服汇总
当前状态: 待评估
责任人: 产品-小何

ID: R-118
标题: 审批状态不清楚
描述: 客户 C 运营主管说，超过 24 小时的审批没人提醒，活动排期容易卡住。
提交时间: 2026-06-18
来源: 客户访谈
当前状态: 评审中
责任人: 产品-小周

ID: R-139
标题: 权限模块重构
描述: 研发建议把老权限逻辑重构，否则后续字段权限不好做。
提交时间: 2026-06-21
来源: 技术优化
当前状态: 进行中?
责任人: 研发-小许

ID: R-151
标题: 客户希望审批更快
描述: 销售说客户很急，希望我们赶紧优化审批。
提交时间: 2026-06-25
来源: 销售转述
当前状态: 老板关注
责任人: 空

【希望输出】
1. 需求池清理表：逐条输出 ID、标准化标题、来源类型、证据摘要、原始状态、建议清理状态、重复关系、是否疑似过期、待澄清问题、责任人、下一步动作。
2. 重复项分组：只标疑似重复，不要直接删除。
3. 过期项确认清单：说明为什么疑似过期，交给谁确认。
4. 可进入评审项清单：只说明材料足够进入评审，不要判断优先级。
5. 待澄清项清单：给出需要补问的问题。
6. 不要输出 P0/P1/P2，不要判断哪个需求应该开发。

提示词

可复制使用的提示词

下面这段提示词可以直接复制。把方括号里的内容替换成你的真实材料。

如果你的需求池很大，不建议一次粘 800 条。可以先按来源或模块切分，例如先清理“订单导出”“审批流”“客服售后”三个模块，各跑一遍规则，再合并清理结果。第一次使用时也可以只抽 30 条，让产品运营和产品经理一起检查 AI 是否按你的字段口径在工作。

你是一名谨慎的产品运营助手，正在帮助我做需求池治理。

本次任务只做清理，不做产品判断：
- 不判断需求是否应该开发。
- 不输出优先级、排期、版本建议。
- 不把老板想法、销售转述、客服问题和客户反馈混成同一种需求。
- 不删除原始记录，只提出清理建议。
- 对证据不足的条目，标为待澄清。
- 对可能已被版本覆盖的条目，标为疑似过期或已覆盖待确认，并说明需要谁确认。

请根据以下材料清理需求池：

【需求池导出】
[粘贴需求池表格或若干条记录，包含 ID、标题、描述、提交时间、来源、状态、责任人、备注]

【原始提交记录和客户反馈】
[粘贴表单、工单、客户原话、销售记录、会议纪要片段，并标明来源和时间]

【版本计划】
[粘贴已上线、开发中、暂缓、关闭的版本事项]

【清理规则】
1. 标准化来源类型：客户反馈 / 客服工单 / 销售转述 / 内部会议 / 老板想法 / 技术优化 / 数据观察 / 版本遗留 / 来源未知。
2. 保留原始状态，同时新增建议清理状态：疑似重复 / 疑似过期 / 待澄清 / 可进入评审 / 转客服处理 / 转技术债 / 已覆盖待确认。
3. 疑似重复只能提出分组和合并建议，不能直接删除。
4. 疑似过期必须说明依据，例如提交时间过久、版本已覆盖、业务流程变化、缺少后续反馈。
5. 待澄清项必须给出具体补问问题。
6. 可进入评审项只表示材料足够讨论，不表示应该开发。
7. 如果无法判断，请明确写“无法判断，需要人工确认”，不要编造原因。

请按以下结构输出：

A. 清理概览
- 总记录数
- 疑似重复组数
- 疑似过期条数
- 待澄清条数
- 可进入评审条数
- 需要责任人补充的信息

B. 需求池清理表
请用表格输出：
ID | 标准化标题 | 来源类型 | 证据摘要 | 原始状态 | 建议清理状态 | 重复关系 | 是否疑似过期 | 待澄清问题 | 责任人 | 下一步动作

C. 疑似重复分组
每组包含：
- 合并主题
- 涉及 ID
- 相同点
- 差异点
- 建议保留主记录
- 需要人工确认的问题

D. 疑似过期或已覆盖待确认清单
每条包含：
- ID
- 疑似过期依据
- 关联版本或业务变化
- 建议确认人
- 确认后可能动作

E. 待澄清清单
每条包含：
- ID
- 缺少的信息
- 建议向谁补问
- 具体补问问题

F. 可进入评审清单
只列出材料基本完整、可以进入评审讨论的条目。不要给优先级，不要建议排期。

输出样例

AI 应该输出到什么程度

下面是基于前面输入样例的一段输出示范。实际项目里可以要求 AI 输出完整表格，这里只截取几条展示判断方式。

| ID | 标准化标题 | 来源类型 | 证据摘要 | 原始状态 | 建议清理状态 | 重复关系 | 是否疑似过期 | 待澄清问题 | 责任人 | 下一步动作 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | R-021 | 订单导出缺少渠道字段 | 客户反馈 | 客户 A 财务原话，财务每周导出后需手工补渠道字段 | 待评估 | 已覆盖待确认 | 与 R-047 同属导出能力主题 | 是，2026-05-12 版本已新增渠道字段 | 确认客户 A 当前是否仍缺字段，是否还有其他字段缺口 | 产品-小林 | 关闭确认或补充剩余缺口 | | R-047 | 订单导出按部门筛选 | 销售转述 | 销售转述客户 B 需要按部门导订单 | 客户催 | 已覆盖待确认 | 与 R-021 同属导出能力主题 | 是，2026-05-12 已上线按部门筛选 | 确认客户 B 的需求是否已被新版本满足，是否还缺权限或默认筛选 | 待补责任人 | 关闭确认 | | R-063 | 导出列顺序适配财务交付 | 客服工单 | 工单 4582，用户下载后需调整列顺序给财务 | 新建 | 可进入评审 | 与 R-021/R-047 相关但不是同一问题 | 否 | 补充工单数量、是否多个客户重复出现、当前手工调整耗时 | 产品-小林 | 进入评审前补充影响范围 | | R-088 | 首页看板卡片方向待定义 | 内部会议 | 老板基于竞品观察提出首页更高级 | 先记着 | 待澄清 | 无 | 否，但关联“自定义首页看板已暂缓” | “高级”具体指什么角色、什么任务、什么指标；是否与已暂缓事项重复 | 产品-小周 | 补充信息 | | R-102 | 退款入口可发现性问题 | 客服工单 | 近两周 9 个用户询问退款入口位置 | 待评估 | 已覆盖待确认 | 无 | 是，2026-06-03 版本已移动退款入口 | 新入口上线后同类咨询是否下降；是否需要 FAQ 或入口文案优化 | 产品-小何 | 关闭确认或转客服处理 | | R-118 | 审批超时无人提醒 | 客户反馈 | 客户 C 运营主管提到超过 24 小时无人提醒，影响活动排期 | 评审中 | 可进入评审 | 与 R-151 疑似相关 | 否，关联开发中审批超时标记 | 确认 2026-07-10 版本是否覆盖提醒对象和场景 | 产品-小周 | 进入评审或与开发中事项核对 | | R-139 | 权限模块技术重构 | 技术优化 | 研发提出老权限逻辑影响字段权限扩展 | 进行中? | 转技术债 | 无 | 否 | 明确技术债负责人、影响范围、是否与近期字段权限需求相关 | 研发-小许 | 转交研发 | | R-151 | 审批优化诉求待还原 | 销售转述 | 销售称客户很急，希望优化审批，但缺少客户、场景和原话 | 老板关注 | 待澄清 | 与 R-118 疑似相关 | 否 | 哪个客户、哪个角色、哪类审批、卡住在哪里、是否与超时提醒相同 | 待补责任人 | 补充信息 |

这一段输出里，有几个细节值得注意。

第一，AI 没有把 R-021 和 R-047 直接删除，而是标成同属导出能力主题，并要求确认是否被 5 月版本覆盖。这样可以避免把客户仍然存在的剩余问题误关掉。

第二，R-063 虽然也和导出有关，但它关注的是列顺序和财务交付格式，不一定能被“渠道字段”和“部门筛选”覆盖，所以应该保留为可评审候选，而不是简单并入旧导出需求。

第三，R-088 是老板想法，不是客户反馈。它可以存在，但需要澄清“高级一点”到底对应什么角色和任务。没有澄清前，不应该进入需求评审。

第四，R-118 可以进入评审，不代表必须开发。它只是材料相对完整，并且与开发中事项有关，需要核对版本是否覆盖场景。

第五，R-151 不能因为写了“客户很急”和“老板关注”就升级为高优先级。它缺少客户、角色、场景和原话，只能待澄清。

人工验收

人要怎么检查和改到可用

AI 输出后，人工复核比生成本身更重要。需求池清理会影响后续评审入口，如果这里把条目误关、误合并或误升级，后面会浪费更多时间。

第一，检查来源有没有被抬高。销售转述不能写成客户原话，客服汇总不能写成多个客户强需求，老板想法不能写成市场趋势，研发建议不能写成用户痛点。如果 AI 在证据摘要里出现“客户普遍希望”“用户强烈要求”“明显需要”这类判断，要改回具体来源和原始证据。

第二，检查状态有没有被混用。清理状态不是开发状态。“可进入评审”不等于已排期，“已覆盖待确认”不等于已关闭，“待澄清”不等于不重要，“转技术债”不等于产品不用关心。建议在需求池里保留两套字段：原始状态和清理状态。原始状态记录历史，清理状态服务当前治理。

第三，检查重复项有没有过度合并。AI 很擅长发现相似词，但相似不等于同一个需求。“导出字段缺失”和“导出速度慢”都属于导出模块，但一个是字段配置问题，一个可能是性能问题。“审批状态不清楚”和“审批权限不合理”都属于审批模块，但前者是状态可见性，后者是流程和权限规则。合并时要看场景、对象和后果，而不是只看模块名。

第四，检查过期项有没有误关。版本计划说“已上线”不代表所有相关需求都解决了。一个版本可能只覆盖了部分场景。比如“退款入口移动到售后”解决的是入口位置，但如果用户仍然不知道退款条件，客服问题可能转为 FAQ 或文案问题。人工要确认“已覆盖的是哪一部分，剩余问题是什么”。

第五，检查待澄清问题是否可执行。好的澄清问题应该能让提交人、客服、销售或产品在 10 到 20 分钟内补信息。不要写“请确认用户真实需求是什么”这种大问题。可以写“请补充客户名称或类型、反馈时间、原话、使用角色、发生频率、当前绕行方式、影响后果”。

第六，检查可评审项有没有越界成优先级。评审会前的清理表可以说“材料完整，可以进入评审讨论”，但不应该说“建议下个版本做”。优先级要结合目标、资源、机会成本、客户价值和技术复杂度，这些通常不在需求池原始导出里，不能由清理任务直接得出。

第七，回写时保留痕迹。不要把 AI 的标准化标题直接覆盖原始标题。建议新增字段：标准化标题、来源类型、证据强度、建议清理状态、重复组、下一步动作、清理备注、清理时间、清理人。这样之后如果有人追溯，仍然能看到原始记录怎么来的。

一个实用的人工复核顺序是：

1. 先看所有“已覆盖待确认”和“疑似过期”，避免误关。
2. 再看所有“疑似重复”，确认哪些能合并主题，哪些要拆开。
3. 接着看“可进入评审”，确认材料是否真够讨论。
4. 最后把“待澄清”按责任人分配出去，限定补充时间。

失败反例

这些失败反例要提前避开

反例 1：把清理任务做成优先级排序。

错误做法是把需求池导出给 AI，然后要求：“请帮我按 P0、P1、P2 排序，并告诉我下版本做哪些。”AI 很可能会根据标题里的紧急词、客户数量、老板关注、描述长度来排序，输出看起来很像产品结论。但它并不知道公司目标、技术成本、商业价值、客户分层和版本资源。更糟的是，需求池里很多条目本身还没清楚来源和状态，排序只会把混乱包装成确定性。

正确做法是先问：“哪些条目来源不清、状态不清、疑似重复、疑似过期、待澄清、可进入评审？”等需求池清理干净后，再由产品负责人进入真正的优先级判断。

反例 2：看到重复就直接删除。

错误做法是让 AI 合并相似需求，并把重复项删掉。比如 R-021 写“导出字段不全”，R-047 写“按部门筛选导出”，R-063 写“导出格式太难用”，AI 可能全部归为“导出优化”，然后建议保留一条、删除两条。这样会丢掉细节：字段缺失、筛选条件和格式适配可能对应不同用户、不同场景、不同开发成本。

正确做法是标“疑似重复分组”，保留原始 ID，写清相同点和差异点。只有产品负责人确认它们确实是同一问题后，才在需求池中建立主从关系或合并主题。

反例 3：把过期项当成已关闭。

错误做法是看到版本计划里已经上线相关功能，就让 AI 把旧需求全部改成“已完成”。比如 5 月版本上线了“部门筛选”，需求池里所有导出相关需求都被标成完成。但客户可能还缺字段顺序、导出格式、权限范围或默认模板。版本覆盖的是一个功能点，不一定覆盖需求背后的全部场景。

正确做法是标“已覆盖待确认”或“疑似过期”，并要求责任人核对：旧需求是否完全满足，是否还有剩余缺口，是否需要拆出新需求，是否可以关闭。

反例 4：把“客户很急”当成强证据。

错误做法是把销售记录里的“客户很急”“大客户催了”“老板关注”直接写成可评审甚至高优先级。紧急感是线索，不是完整需求。没有客户、角色、场景、影响和原话，就无法判断这到底是一个真实用户问题，还是销售推进中的表达。

正确做法是把这类条目标成“待澄清”，补问：哪个客户、哪个角色、什么场景、最近一次发生在什么时候、当前怎么绕过、影响了什么业务结果、有没有原始记录。

反例 5：把客服问题全都转成产品需求。

错误做法是看到很多客服工单，就全部写进需求评审。客服工单里有些确实反映产品问题，有些只是用户不知道入口、帮助文档不清楚、配置流程没有说明、客服话术不一致。全部转成产品需求，会让需求池越来越胖。

正确做法是区分“产品改动”“客服流程”“FAQ 文档”“配置指导”“已上线功能的认知问题”。比如退款入口找不到，如果新入口已经上线且咨询量下降，可能应该转客服知识库；如果咨询量没有下降，则需要继续评审入口可见性或文案问题。

主题边界

它和相邻主题的区别

这篇讲的是需求池清理，不是需求优先级评估。优先级评估要看公司目标、用户价值、收入影响、技术成本、战略方向和机会成本；需求池清理只回答“这条记录是什么来源、现在是什么状态、是否重复、是否过期、还缺什么信息、能不能进入评审”。前者是产品判断，后者是信息治理。

它也不是用户访谈分析。用户访谈分析通常处理一批访谈记录，从中提取主题、行为模式、动机和未满足需求。需求池清理处理的是一张已经积累过的需求台账，里面混有客户、内部、客服、销售和技术来源。它的重点不是挖洞察，而是让台账重新变得可用。

它也不是客服工单归因。客服工单归因会分析问题原因、责任模块、解决路径和服务流程；需求池清理只判断某条客服来源的记录是否应该保留在需求池、转客服处理、补充信息或进入评审。

它也不是版本规划。版本规划要决定做什么、不做什么、什么时候做、投入多少人、和哪些目标绑定。需求池清理最多把可评审项准备好，把疑似过期项清出来，把待澄清项分配责任人。它不应该直接把需求塞进版本。

它还不同于技术债梳理。技术债梳理关注代码结构、架构风险、维护成本和工程演进。需求池里如果出现“权限模块重构”这样的技术优化，可以被识别并转交研发或技术债台账，但不能强行包装成客户需求。

一句话收口：需求池乱了，不要急着问 AI “哪些最重要”。先问它“哪些记录不干净”。当来源、状态、重复、过期、待澄清和可评审都摆清楚后，产品经理才有条件做真正的判断。