客户甩过来一句”帮我加个批量导出”，你是直接抄进需求池，还是回个”收到”就没下文？真正的扎心场景是：月底排期会上，老板问”这个需求到底多少客户提过、能带来什么价值、什么时候能上线”，你打开需求列表，里面全是一句话需求，一个都答不上来。把客户的话变成能评审、能排期、能验收的需求卡，这才是AI该帮你干的活。
一句话反馈不是需求，先别急着”翻译”
“希望能批量导出””这个页面不好用””最好增加自动提醒”——这些是反馈线索，不是能直接排期的需求。真正可执行的需求要回答五个问题：谁在什么场景遇到什么问题、现在是怎么熬过去的、证据有多强、希望改变什么结果、以及怎么判断功能已经解决了问题。
最常见的翻车：客户说”我想要批量导出”，你直接写”开发批量导出功能”。可客户真正的问题可能是月末要汇总200条订单、现在只能逐条复制；也可能导出入口早就有了，只是权限或操作说明没讲清楚。先还原问题，再谈方案，顺序反了，开发出来的东西大概率没人用。
原始反馈先原样保留，别急着美化
很多团队拿到反馈第一件事就是”提炼”，结果把”财务月底要熬夜对账”提炼成了”需要导出功能”，上下文全丢了。整理前，先给每条反馈留个底：反馈来源、时间、用户类型、原话、上下文。访谈记录可以用AI先做一次结构化整理，提取事实和待验证假设；客服聊天则要区分真实产品问题、客服表达问题和政策限制，三类问题的解法完全不同。
这里有个好用的原则：任何结论都要能回到证据编号。你写”客户希望批量导出”时，得能回答”这句话是哪个客户、哪一天、在哪个工单里说的”。没有这个追溯能力，需求池就是个垃圾桶，评审时谁也说服不了谁。
一条合格需求卡，至少9个字段
字段不是越多越好，但下面这9个，缺任何一个，评审时都会来回扯皮。给个表格对照看：
| 字段 | 填什么 |
|---|---|
| 反馈来源 | 访谈、工单、客服、销售还是数据 |
| 用户角色 | 谁在用，有没有决策或操作权限 |
| 使用场景 | 什么时间、任务和环境下发生 |
| 问题证据 | 原话、频次、工单号、数据或复现记录 |
| 当前做法 | 用户现在如何绕过，成本是什么 |
| 目标结果 | 希望减少什么步骤、错误、时间或风险 |
| 方案边界 | 本次做什么，明确不做什么 |
| 优先级依据 | 价值、证据、影响、成本和时机 |
| 验收标准 | 输入、操作、输出、异常和权限条件 |
注意顺序：先写证据和场景，再谈目标和方案。很多人把”方案边界”写在最前面，先定了”做导出”，结果把真实问题框死了。字段顺序本身就是在训练你”先理解问题、再设计解法”。
可直接复制的客户需求整理提示词
字段框架搭好后，让AI当你的需求分析助理。下面这段提示词把上面9个字段串成一条完整的工作流，粘贴就能用：
你是一名客户需求分析助理。请根据我提供的访谈、客服、工单、销售反馈和产品资料，整理客户需求池。你的任务是保留证据、去重归类、补齐场景和形成待评审需求卡，不能编造用户数量、业务价值、实现成本、优先级或验收结果。 产品或服务：[填写] 目标用户与角色：[填写] 原始反馈：[粘贴已脱敏的访谈、客服、工单或销售记录] 当前产品能力：[填写已有功能、权限和限制] 业务目标：[填写本阶段希望改善的指标或任务] 已知数据：[反馈频次、流失、耗时、错误率等] 研发与运营约束：[人员、时间、系统、合规等] 优先级规则：[如有，没有则写待制定] 请输出： 1. 原始反馈清单：来源、时间、用户角色、原话、上下文和证据编号 2. 去重与归类结果：合并了哪些反馈、不能合并的原因和主题分类 3. 问题陈述：用户、场景、当前做法、困难、影响和仍需确认的信息 4. 需求卡：需求名称、目标结果、范围、不包含范围、依赖、风险和证据 5. 优先级评估：用户价值、证据强度、影响范围、实现成本和时机，每项说明依据 6. 验收标准：正常流程、异常流程、权限、数据和边界条件 7. 冲突需求：不同用户角色目标相反时分别列出，不强行合并 8. 待验证假设：需要访谈、数据分析、原型或技术验证的问题 9. 建议下一步：直接进入评审、先做小范围验证、继续补资料或暂缓 处理规则： - 原始反馈与需求卡分开保留，任何结论都能回到证据编号 - 相似关键词不代表同一问题，只有用户、场景和目标结果一致时才合并 - 用户提出的解决方案不等于最终方案，先还原其要完成的任务 - 没有频次和影响数据时，不得写"高频""大量用户"或"高价值" - 实现成本没有研发确认时标记"待评估"，不能凭常识估算工期 - 优先级只能给出建议及依据，最终排序保留给产品和业务负责人 - 涉及隐私、权限、合同、财务和安全时标记专业评审 输出后自检： - 每条需求是否保留至少一个可追溯证据 - 是否把反馈、问题、需求和解决方案区分开 - 是否错误合并了不同角色或不同场景 - 每项优先级判断是否说明依据和不确定性 - 验收标准是否能通过实际操作或数据验证
用的时候别偷懒直接全贴。不同反馈来源要用不同提示词处理：访谈记录重在提取待验证假设，客服工单重在去重和归类，这个思路可以结合新手入门里整理信息的方法灵活调整。
完整跑一遍：”增加批量导出”如何进需求池
拿真实的批量导出需求，把上面的流程走到底：
原始反馈：最近一个月有6个企业客户在工单中询问批量导出订单，其中4个是财务角色。他们在月末需要汇总100到300条订单，目前只能逐页复制；现有导出功能只对管理员开放。
问题陈述：企业财务在月末对账时需要集中获取订单明细，但当前角色没有导出权限，手工复制耗时且容易漏项。尚未确认管理员是否可以代为导出，也未确认扩大权限是否符合数据安全规则。
需求卡建议：
- 目标结果：允许经过授权的财务角色按时间范围导出其可见订单，不扩大原有数据范围。
- 证据：6条工单、4个财务角色、订单量100到300条；需要补充手工处理耗时。
- 优先级：用户价值和证据强度较高，但权限、安全审计和开发成本待评估，因此进入评审而不是直接排期。
- 验收标准：授权财务角色可选择日期范围并导出CSV；导出字段与页面可见范围一致；无权限角色看不到入口；超过数量限制时给出明确提示；每次导出记录操作者、时间和条件。
注意最后这条验收标准：它没有写”能导出就行”，而是把正常流程、异常流程、权限、数据范围、审计留痕五个维度全包了。评审会能当场拍板，靠的就是验收标准足够具体。进入正式产品文档时，可以让AI帮你写PRD补齐业务规则和流程，参考AI办公工具里的PRD辅助玩法；批准后又改范围，必须走需求变更流程，不能直接覆盖旧需求。
去重时最容易犯的三个错
AI去重很快，但去错方向比不去更糟：
- 按功能词合并。“导出慢”和”没有导出权限”都带”导出”俩字，但一个是性能问题、一个是权限问题，解法天差地别。合并依据是用户、场景、目标结果一致，不是关键词相似。
- 忽略用户角色。管理员希望看全量数据，普通员工只能看授权范围，两者不能共用一个验收标准。合并前先问一句：这两个人干的是同一件事吗？
- 把客服问题当产品需求。用户找不到已有入口，要补的是客服FAQ知识库或操作说明，不是开发新功能。先把”有没有已有功能可以覆盖”查清楚，再决定要不要写需求卡。
需求池要养，不能只建不管
需求池是个活的东西。每周固定花半小时做新增反馈去重，每月复核一次长期未处理需求。需求进入开发、被拒绝或失效时，都要记录决定、时间和依据，不然三个月后没人知道为什么某条需求消失了。高价值但证据不足的，安排小范围访谈或原型测试；长期没有新证据、又和当前业务目标无关的，归档而不是删除，原始来源永远留着。
需要和市场方案做对比时，可以用AI整理竞品信息作为参考，但竞品已经做了某功能，并不自动证明你的用户也需要——证据永远比”别人有”更有说服力。
AI整理客户需求的边界，心里要有数
最后泼几盆冷水，这些场景AI帮不上忙、甚至别碰：
- 手机号、身份证、订单详情、未脱敏聊天记录，一律不要上传第三方AI工具，脱敏是第一步不是可选项。
- AI不能代表客户确认真实需求，也不能替研发评估技术成本，它给的是建议草稿，不是拍板结论。
- 少量大客户的反馈可能商业价值极高，也可能只适用定制场景，这个判断只能由业务负责人做。
- 涉及权限、资金、隐私、安全和法律要求的，先完成专业评审再写验收标准，别让AI替你扛这个责任。
把客户的话变成一张张能评审、能排期、能验收的需求卡，靠的不是AI有多聪明，而是你的字段框架和证据意识。AI负责把100条杂乱反馈整理成10张像样的卡，剩下”为什么是这10条、先做哪张”的决策，永远得人来拍。这套方法里最值钱的部分，恰恰是那些AI替不了的决定。更多需求管理思路可以参考本篇完整的需求池与验收标准框架。