用 AI Agent 做需求分析，先把用户反馈、现有规则和待确认信息分开，再让 AI 整理问题、拆解任务和提出追问，最后由产品负责人确认范围与优先级。AI 适合帮助梳理材料和发现遗漏；一份看起来完整的报告，并不意味着其中的业务判断已经成立。
以“购物车功能优化”为例，可以用墨刀 AI 整理产品需求文档，把零散反馈转为可讨论的需求初稿。先保留反馈来源，再整理业务规则，随后用页面和验收条件解释要改什么。这样团队接到的会是一组具体问题与决定，而不是一段“优化购物体验”的宽泛口号。
先收窄范围：购物车要解决哪一种问题
购物车涉及选品、数量、库存、促销和结算，不能把所有不满意都归结为界面不好看。先确定本轮分析的起点和终点：用户已经把商品加入购物车，本轮只研究选择商品到进入结算的过程，不讨论推荐算法、商品详情和支付渠道。
下面四条为练习材料，用于演示如何分析，不代表实际访谈或业务数据。正式项目可以换成客服记录、访谈摘录和操作观察；提交前移除姓名、联系方式和订单等不必要的个人信息。
| 材料编号 | 原始内容 | 当前能知道什么 |
|---|---|---|
| F01 · 用户反馈 | “我只勾选了两件商品，但看不出下面总价是不是这两件的。” | 勾选范围和金额关系表达不清；尚不能断定金额算错 |
| F02 · 用户反馈 | “数量改成三件后，到结算才说库存不够。” | 库存提示出现的位置或时机有问题；具体库存同步机制未知 |
| F03 · 操作观察 | 用户进入购物车后，先逐个点开灰色商品，再返回删除。 | 失效原因与处理入口可能不清楚；原因仍需核对 |
| B01 · 本轮已确认规则 | 只计算已勾选且可购买的商品；失效商品不能结算。 | 可用于检查页面和金额逻辑，不需要由AI补写 |
F01 不能直接写成“总价计算错误”；F02 也不能直接证明系统库存更新慢。先保留原意，再列出可能原因：信息层级、提示时机、规则未说明或真实系统异常。下一步根据问题性质补操作记录或询问业务，避免把未经确认的猜测交给研发实现。
第一步：整理输入，让 Agent 知道哪些是事实
不要只输入“写一份购物车优化 PRD”。这类指令很容易得到常见功能集合，例如优惠券、满减和推荐商品，却没有解决当前反馈。将目标、范围、材料与输出要求放在同一次任务里，要求保留编号和未知信息。
任务：分析购物车中“选择商品到进入结算”的体验问题。
目标：用户能看清本次选购内容、金额和无法结算的原因。
材料：粘贴 F01、F02、F03、B01 的原文。
已确认规则：仅计算已勾选且可购买商品；失效商品不能结算。
暂不分析：支付渠道、推荐算法、商品详情、促销机制重构。
请输出：
1. 按“原始反馈—用户任务—可能问题—待确认信息”整理材料。
2. 区分已确认事实、可能原因和方案建议，每条保留材料编号。
3. 不补造访谈、用户占比、库存逻辑、活动规则或收益数字。
4. 先列影响任务完成的问题，再列需要补充的业务问题。
5. 对缺失信息提出具体追问，暂不替业务作决定。
AI 生成结果后，先检查材料有没有被改写过头。例如将 F03 归纳为“所有用户无法删除失效商品”就扩大了原观察范围；应改成“这次观察中，用户没有直接找到处理入口”。把这种差异明确指出，要求基于原文重新整理，而不是仅要求“分析更深入”。
第二步：把问题拆成规则、界面与依赖
分析结果需要能回答三个问题：用户在哪一步受阻，哪些信息已经确定，还有什么必须由业务或技术确认。下面给出基于练习材料可得到的拆解；“建议”仍要讨论，不能混进已确认规则。
| 问题与来源 | 可以先提出的方案 | 还需要确认的依赖 |
|---|---|---|
| 选中商品与金额对应不清 · F01/B01 | 突出已选数量；合计旁说明计算范围；未选商品不计入合计 | 是否有运费、税费或活动金额另行计算；当前页面是否已含这些项 |
| 数量变化后才发现库存不足 · F02 | 数量变更处显示库存不足反馈，并提供调整入口 | 库存何时校验、何时重新获取；是否有预售或限购规则 |
| 失效商品原因与处理入口不清 · F03/B01 | 按失效原因展示说明；在当前区域提供删除等操作 | 失效类型有哪些；是否允许恢复或替换；批量处理规则 |
例如“库存不足”不是一个只需要设计红色提示的需求。如果库存只在结算时取得，页面方案就必须说明等待与返回后的处理；如果数量修改时可以校验，反馈位置又不同。先把依赖记录出来，再和研发确认校验时机，避免原型画了实时库存却没有实现条件。
让 AI 提出能直接回答的追问
“请确认库存规则”太宽泛，可以改为：“用户把数量从 2 改为 3 时，系统是否已有可用库存？若接口失败，是否允许继续结算？进入结算前是否再次校验？”这些问题分别影响提示、禁用和后续恢复，业务与研发也更容易明确回答。
继续分析 F02，不重写整份文档。
请将待确认项拆成具体问题：
- 数量变化时，库存来自哪里，是否需要发起校验？
- 校验过程中按钮和金额如何显示？
- 库存不足、校验失败、价格变化分别如何处理？
- 进入结算前是否再次确认，失败后返回哪一位置？
每个问题说明它会影响哪个页面状态，并留出负责人和答复位置。
在得到答复前，不假设系统具有实时库存。第三步：整理成可以讨论的需求条目
有了问题和依赖，再把已确认部分写成需求条目。一条条目至少说清触发、界面变化和验收条件，保留材料来源。不要用“提升购物体验”“智能处理库存”替代具体行为。
| 条目 | 输入与预期行为 | 可以怎样检查 |
|---|---|---|
| C01 · 已选商品与金额关系 | 用户勾选或取消商品后，已选数量和合计同步反映当前可购买商品；金额范围有明确说明 | 未选商品不计入；只选一件和取消全部时的数量、金额表达一致 |
| C02 · 失效商品处理 | 显示可识别的失效原因；提供对应操作，不让用户为理解原因反复进入详情页 | 失效商品不能进入结算；删除后列表和计数更新；无可购买商品时说明下一步 |
| C03 · 库存异常反馈 | 先确定校验时机和失败规则，再在对应环节提供数量调整与重试入口 | 依据确认后的规则，分别检查等待、库存不足和接口失败，不能共用“购买失败”一句话 |
C03 依赖尚未确认，因此可以进入问题讨论，但暂不把“实时校验库存”写成已承诺的开发范围。相比之下，C01 的金额范围说明和选中关系已有 B01 可支撑，可以先检查当前原型是否把规则表达清楚。
第四步：给优先级写理由，不让 Agent 随意打分
优先级要结合问题影响、发生范围、实现依赖和本轮目标。在没有真实频次、损失或工作量数据时，不应让 AI 编出 RICE 分数或收益百分比。可以先把问题分为“阻止任务完成”“可能引起误解”“体验增强”，再记录调整优先级所需的信息。
在这个练习中，如果确认失效商品仍可进入结算，这是与 B01 冲突的任务错误，应优先处理；如果行为正确但原因看不懂，则优先改善说明和处理入口。库存反馈是否需要先改，要看它是否真实造成结算阻断，以及改动是否依赖后台接口，不能只凭一句反馈作全局判断。
- 本轮可以先做：澄清合计计算范围、展示失效原因、让处理入口靠近问题位置。实施前仍需核对当前页面，避免重复已有能力。
- 先补信息再决定：库存校验时机、促销叠加和价格变化处理。把负责人、需要的材料和决定时间列清楚。
- 暂不纳入：重建推荐系统、添加积分商城等与这次材料无直接关联的功能，放到另一个问题范围再评估。
若团队需要量化排序，先补实际数据来源、观察范围和研发估算，再让 AI 帮忙整理。数字有了依据以后才有比较意义；“很多用户反馈”或“预计转化大幅提升”不能替代这些输入。
第五步：从需求条目继续做原型和评审
先选择 C01 与 C02 中已经确认的部分，让 AI 生成或修改购物车页面：展示已选商品、合计说明、失效原因和处理入口。随后补空购物车、全部未选和全部失效等状态。C03 则先保留问题说明，等规则确认后再做对应交互。
评审时给每个参与者一项具体任务：只买其中两件商品并说明合计范围；找到一件失效商品并处理；在库存不足时说明下一步。记录卡住的位置和他们的理解，再回到需求条目修正。这里关注的是方案能否被理解和操作，不是请大家泛泛评价页面好不好看。
如果确认要新增“价格变化需重新确认”，先更新规则，再补提示内容、确认操作和返回路径。同步文档与原型时沿用需求编号，避免文档说需确认、页面却直接进入结算。更具体的映射方式，可参考需求文档转原型图的步骤。
拿到 AI 分析结果后，重点核对这几处
来源是否还在：每个问题能否找到原始反馈或确认规则；缺来源的结论先列为待验证。条件是否被省略：某次观察不等于所有用户，未找到入口也不等于功能不存在。方案是否超范围：新增功能要能解释与本轮任务的关系。未知是否被补成事实：特别注意价格、库存、权限和效果数字。
最后交付给团队的可以是一份需求初稿、对应原型和待确认问题列表。每条待确认项写明具体问题与负责人；已确认条目写明状态和验收方法。下一次补充资料时，要求 AI 只更新受影响的条目和流程，不要每次把整份文档重新生成一遍。
从一组真实反馈开始，在墨刀 AI完成第一轮材料整理，再按问题、依赖与需求条目逐步推进。若已经有明确需求，只想整理文档章节和格式，可继续阅读AI 生成需求文档的方法，把分析结论接到后续协作中。
