客户说“希望能批量导出”“这个页面不好用”“最好增加自动提醒”，这些都是反馈线索，不是可以直接排期的需求。真正可执行的需求要说明：谁在什么场景遇到什么问题、现有做法造成什么影响、证据有多强、希望改变什么结果，以及怎样判断功能已经解决问题。AI 适合去重、归类和补字段，但不能因为某位客户声音大就决定优先级。
先保留原始反馈，不要急着改写
整理前保留反馈来源、时间、用户类型、原话和上下文。访谈记录可先用AI整理用户访谈记录的方法提取事实和待验证假设；客服聊天可结合客服对话质检方法区分真实产品问题、客服表达问题和政策限制。
不要把“客户想要批量导出”直接改成“开发批量导出功能”。客户真正的问题可能是月末需要汇总200条订单，目前只能逐条复制；也可能已有导出入口，只是权限或操作说明不清楚。先描述问题，再讨论解决方案。
每条需求卡至少保留9个字段
- 反馈来源：访谈、工单、客服、销售或数据。
- 用户角色：谁在使用，是否有决策或操作权限。
- 使用场景：在什么时间、任务和环境下发生。
- 问题证据：原话、频次、工单号、数据或复现记录。
- 当前做法：用户现在如何绕过问题，成本是什么。
- 目标结果：希望减少什么步骤、错误、时间或风险。
- 方案边界：本次可能做什么，明确不做什么。
- 优先级依据：价值、证据、影响、成本和时机。
- 验收标准：输入、操作、输出、异常和权限条件。
可直接复制的客户需求整理提示词
你是一名客户需求分析助理。请根据我提供的访谈、客服、工单、销售反馈和产品资料，整理客户需求池。你的任务是保留证据、去重归类、补齐场景和形成待评审需求卡，不能编造用户数量、业务价值、实现成本、优先级或验收结果。
产品或服务：[填写]
目标用户与角色：[填写]
原始反馈：[粘贴已脱敏的访谈、客服、工单或销售记录]
当前产品能力：[填写已有功能、权限和限制]
业务目标：[填写本阶段希望改善的指标或任务]
已知数据：[反馈频次、流失、耗时、错误率等]
研发与运营约束：[人员、时间、系统、合规等]
优先级规则：[如有，没有则写待制定]
请输出：
1. 原始反馈清单：来源、时间、用户角色、原话、上下文和证据编号
2. 去重与归类结果：合并了哪些反馈、不能合并的原因和主题分类
3. 问题陈述：用户、场景、当前做法、困难、影响和仍需确认的信息
4. 需求卡：需求名称、目标结果、范围、不包含范围、依赖、风险和证据
5. 优先级评估：用户价值、证据强度、影响范围、实现成本和时机，每项说明依据
6. 验收标准：正常流程、异常流程、权限、数据和边界条件
7. 冲突需求：不同用户角色目标相反时分别列出，不强行合并
8. 待验证假设：需要访谈、数据分析、原型或技术验证的问题
9. 建议下一步：直接进入评审、先做小范围验证、继续补资料或暂缓
处理规则：
- 原始反馈与需求卡分开保留，任何结论都能回到证据编号
- 相似关键词不代表同一问题，只有用户、场景和目标结果一致时才合并
- 用户提出的解决方案不等于最终方案，先还原其要完成的任务
- 没有频次和影响数据时，不得写“高频”“大量用户”或“高价值”
- 实现成本没有研发确认时标记“待评估”，不能凭常识估算工期
- 优先级只能给出建议及依据，最终排序保留给产品和业务负责人
- 涉及隐私、权限、合同、财务和安全时标记专业评审
输出后自检：
- 每条需求是否保留至少一个可追溯证据
- 是否把反馈、问题、需求和解决方案区分开
- 是否错误合并了不同角色或不同场景
- 每项优先级判断是否说明依据和不确定性
- 验收标准是否能通过实际操作或数据验证示例：“增加批量导出”如何进入需求池
原始反馈：最近一个月有6个企业客户在工单中询问批量导出订单，其中4个是财务角色。他们在月末需要汇总100到300条订单，目前只能逐页复制；现有导出功能只对管理员开放。
问题陈述：企业财务在月末对账时需要集中获取订单明细，但当前角色没有导出权限，手工复制耗时且容易漏项。尚未确认管理员是否可以代为导出，也未确认扩大权限是否符合数据安全规则。
需求卡建议：
- 目标结果：允许经过授权的财务角色按时间范围导出其可见订单，不扩大原有数据范围。
- 证据：6条工单、4个财务角色、订单量100到300条；需要补充手工处理耗时。
- 优先级：用户价值和证据强度较高，但权限、安全审计和开发成本待评估，因此进入评审而不是直接排期。
- 验收标准示例：授权财务角色可选择日期范围并导出CSV；导出字段与页面可见范围一致；无权限角色看不到入口；超过数量限制时给出明确提示；每次导出记录操作者、时间和条件。
进入正式产品文档时，可以使用AI写PRD提示词补齐业务规则、流程和验收标准；已经批准后又改变范围，则应进入需求变更流程，不能直接覆盖旧需求。
需求去重时最容易犯的三个错误
- 按功能词合并：“导出慢”和“没有导出权限”都提到导出，但原因和解决方式不同。
- 忽略用户角色：管理员希望看到全量数据，普通员工只应看到授权范围，不能共用一个验收标准。
- 把客服问题当产品需求：用户找不到已有入口时，可能需要更新客服FAQ知识库或操作说明，而不是开发新功能。
需求池的每周维护方法
每周新增反馈先去重，每月复核一次长期未处理需求。需求进入开发、被拒绝或失效时，都应记录决定、时间和依据。高价值但证据不足的需求可以安排小范围访谈或原型测试；长期没有新证据、与当前业务目标无关的需求可以归档，但不要删除原始来源。
需要比较市场现有方案时，可使用AI竞品分析提示词整理事实，但竞品已经提供某功能并不能自动证明本站用户也需要。
AI整理客户需求的失败边界
- 不能把手机号、身份证、订单详情和未脱敏聊天直接上传到第三方AI工具。
- AI无法代表客户确认真实需求，也不能替研发评估技术成本。
- 少量大客户反馈可能商业价值很高，也可能只适用于定制场景，必须由业务负责人判断。
- 涉及权限、资金、隐私、安全和法律要求时，应先完成专业评审再写验收标准。