客户产品建议很多，Agent 怎样合并同一诉求并保留不同使用条件

客户产品建议很多时，Agent 可以提出哪些反馈属于同一诉求、哪些只是词语相似，并保留各自使用条件。归并的目标是让产品人员看清需求，不是让模型自动决定开发排期。本文用十四条合成反馈建立需求池映射，不将客户建议当作已经批准的项目变更。

每条反馈先保存原始身份

为每条反馈保留来源编号、产品版本范围、使用角色和原话，客户身份采用受控代号。重复转发的同一反馈可以关联来源，但不同客户独立提出同类问题仍要保留各自证据。不要因为合并后有一条主需求，就删除其他来源，后续核对影响范围还需要它们。没有版本或使用条件时标未知，不把资料缺口补成默认情境。

从要完成的事比较相似性

“希望导出”可能分别指当前筛选结果、全部历史或附带附件，技术动作相同而业务产物不同。先提取用户问题、期望结果和限制，再判断可归到同一主诉求还是需要子项。Atlassian 的功能请求资料强调问题与上下文，支持先理解任务而非只看功能词。相似度可以产生候选，但不能直接作为自动合并的依据。

为合并和拆分写理由

一条需求可以关联多个反馈，同时保留版本、范围和权限限制。条件互相冲突时可在主需求下列子项，或者保持独立，不能为了减少列表长度抹掉差异。客户建议的具体实现方案与其问题分开保存，产品人员可能选择另一种办法解决。归并记录写谁核对、采用什么依据，允许以后拆回原记录，不把一次模型判断变成不可逆清理。

十四条样例展示同词异义与同义异词

FB-01、FB-02 都想保存当前筛选结果，可以作同一诉求候选；FB-03 要全部历史、FB-04 要附件，需要保留不同范围。FB-05、FB-06 词语不同却涉及同一版本识别问题；FB-07 是权限问题，不合并成搜索不好用。后续样例包含旧版本、同源转发、不同角色与缺上下文，附件逐条给出候选归属和核对点，不只写一份抽象规则。

归并后再看支持证据，别拿行数当票数

同一客户多次转发不自动增加独立支持对象，多个角色也可能描述同一事件。汇总时说明按反馈、客户还是任务计数，无法可靠去重就不宣称支持人数。样本只反映已经收集的反馈，不代表未发声用户都没有需要。产品优先级还要看影响、依赖和业务目标，本篇材料不自动生成承诺日期或对外功能路线图。

让需求池更新有版本和退出状态

新反馈到来后保留新增、关联和更正记录，已实现功能也要检查是否真的解决原问题。仅发布一个同名按钮不代表需求已满足，验证应回到预期产物与限制。被暂缓或不采纳的需求记录理由和复议条件，不能从库里消失。后续若进入具体客户项目，再走范围确认，不把公共需求池归并结果直接写进合同或交付清单。

合成样例与判断边界

反馈编号	合成反馈	关键条件	候选归属	归并判断	核对点
FB-01	想保存当前筛选后的表	当前筛选范围	NEED-EXPORT-FILTER	主诉求候选	核对输出字段
FB-02	把现在看到的结果带走	当前视图	NEED-EXPORT-FILTER	同义候选	确认不是全历史
FB-03	希望导出全部历史	全历史	NEED-EXPORT-HISTORY	单独范围	权限与体量另核对
FB-04	导出时带上全部附件	附件	NEED-EXPORT-ATTACH	保留子项	不等于只导表
FB-05	不知道哪份资料最新	版本识别	NEED-VERSION	主诉求候选	有效状态来源
FB-06	旧文件经常被当成现行	版本识别	NEED-VERSION	同义候选	适用场景是否一致
FB-07	找到了但打不开文件	访问权限	NEED-ACCESS	不并到搜索	确认授权入口
FB-08	搜索不到已批准资料	检索范围	NEED-SEARCH	独立候选	是否有权访问
FB-09	旧版本页面希望增加提示	仅旧版本	NEED-VERSION-OLD	保留版本条件	现行版本是否已解决
FB-10	转发FB-01同一原消息	同源	NEED-EXPORT-FILTER	来源关联	不当独立支持客户
FB-11	管理人员需看跨项目汇总	管理角色	NEED-CROSS-PROJECT	独立范围	授权范围不同
FB-12	执行人员只看自己任务	个人任务	NEED-MY-TASK	不与跨项目合并	任务边界不同
FB-13	希望更方便一些	上下文不足	待澄清	暂不合并	请提供具体工作样例
FB-14	已实现的导出缺一列	现有功能缺口	NEED-EXPORT-FIELD	关联但保留缺口	检查原预期字段

下载完整合成记录与可填写表。实际使用需替换为获授权材料并保留来源、未知状态及人工确认；表中分类不代表真实业务统计或已在目标环境验证。

相关方法见选题重复检查，更多任务见业务场景专题。如需定制，可在咨询入口提交脱敏输入、既有分类口径和希望交付的材料，先确认任务范围与复核方式。