在一次迭代评审前夕，产品同事发来了一份长达 18 页的 PRD，里面混杂着用户故事、页面规则、后台配置、异常流程以及几段会议纪要。核心问题并非文档篇幅过长，而是许多规则隐藏在自然语言描述中：同一个字段在不同章节中的叫法不一致，退款状态与风控状态之间存在相互影响。后端、测试、运营团队坐在一起研读了半小时，大家都觉得“大致理解了”，但没有人敢直接进入排期。
随后，我对这份文档进行了一次 AI 辅助拆解实验。本文的重点并非模型排行对比，而是记录一套以 Claude Opus 4.8 为核心的需求拆解工作流：如何将一份混乱的 PRD 转化为接口清单、状态机、测试点以及待确认问题清单。这套方法不能替代产品评审，也无法替研发团队完成最终设计，但能显著降低“读文档读到思维混乱”的认知成本。
这份 PRD 的混乱根源在哪里
原文档的业务背景是一个电商售后场景：用户提交退款申请后，系统需要根据订单状态、商品类型、风控结果以及人工审核结果，来决定是自动通过、进入审核流程、直接拒绝还是要求补充材料。
文档中存在几个典型问题：
- “退款中”“待审核”“处理中”等术语在不同页面中混用，缺乏统一标准；
- 后台配置项被夹杂在页面说明中，没有单独罗列；
- 异常流程分散在 4 个不同章节，查找困难；
- 产品仅提到“高风险订单需人工审核”，但未明确定义高风险的具体来源；
- 部分规则来自会议纪要中的补充说明，并未出现在正式 PRD 表格中；
- 测试同事关心的边界条件基本未被列出。
如果完全依靠人工逐字阅读，当然也能完成。但每次评审都会出现类似对话：
“这个状态指的是订单状态还是退款单状态？”
“这条规则是否仅适用于虚拟商品？”
“审核被拒绝后，用户能否重新提交申请？”
“后台开关关闭时，存量单据应该怎么处理？”
Claude Opus 4.8 在此类任务中的核心价值，并非直接“给出答案”，而是将这些散落的问题集中暴露出来，让团队在评审前就能清晰看到风险点。
核心模块一：先让模型做“目录重排”，而非急于生成方案
很多人使用大模型拆解 PRD 时，第一步就会问：
请根据下面 PRD 生成技术方案。这种做法很容易翻车。因为模型会根据自身经验补齐许多原文并未提及的内容，最终呈现出一份看似完整的方案，但其中混杂着事实、推测和幻觉。
一个更稳妥的做法是：第一轮只让 Claude 做“结构重排”。
你是一个研发侧需求分析助手。
请阅读下面 PRD，不要新增原文没有的规则，只做结构化整理。
输出格式：
1. 业务目标：用 3～5 条概括；
2. 涉及角色：用户、客服、审核员、系统任务等；
3. 涉及对象：订单、退款单、商品、风控结果、后台配置；
4. 原文明确写出的规则；
5. 原文隐含但不确定的规则，标记为“待确认”；
6. 文档中术语不一致的地方；
7. 可能影响研发设计的缺失信息。
限制：
- 不要写技术方案；
- 不要设计数据库；
- 不要补充接口字段；
- 所有不确定内容必须标注“待确认”。这一轮输出中最有价值的部分，通常不是“业务目标”，而是“术语不一致”和“待确认问题”。
例如，模型会整理出：
| 问题 | 原文位置 | 风险 |
|---|---|---|
| “退款中”和“处理中”是否属于同一状态 | 页面说明、消息通知章节 | 影响状态机设计 |
| 高风险订单的来源未明确 | 风控规则章节 | 影响接口依赖 |
| 审核拒绝后是否允许重新提交 | 异常流程章节未说明 | 影响用户操作闭环 |
| 后台开关关闭后存量单据如何处理 | 配置说明缺失 | 影响灰度和回滚策略 |
拿着这张表去开评审会，效率远高于让大家直接翻 18 页文档。
核心模块二：把 PRD 拆成“状态机”，再谈接口设计
售后、审批、风控、工单类需求中，最容易出问题的是状态管理。接口字段可以后续补充，但状态流转如果早期没有讲清楚，后续的测试用例、数据修复、运营后台都会受到影响。
第二轮，我会让 Claude Opus 4.8 只关注状态机。
请基于上面的 PRD 整理退款单状态机。
要求：
1. 只使用原文出现过或可以明确对应的状态；
2. 如果状态命名不统一，请列出候选命名并给出统一建议；
3. 输出状态、触发动作、前置条件、后置结果；
4. 标出不确定或缺失的流转；
5. 不要设计接口，不要设计数据库。
输出表格字段：
当前状态 | 触发事件 | 条件 | 下一个状态 | 发起方 | 待确认点得到的结果可以直接作为评审材料的一部分：
| 当前状态 | 触发事件 | 条件 | 下一个状态 | 发起方 | 待确认点 |
|---|---|---|---|---|---|
| 已创建 | 提交退款申请 | 普通订单，未触发风控 | 待处理 | 用户 | 是否需要库存校验 |
| 待处理 | 风控识别 | 高风险 | 待人工审核 | 系统 | 高风险来源未定义 |
| 待人工审核 | 审核通过 | 审核员确认 | 退款通过 | 审核员 | 是否通知用户 |
| 待人工审核 | 审核拒绝 | 材料不完整或不符合规则 | 退款拒绝 | 审核员 | 是否允许重新提交 |
| 待处理 | 后台开关关闭 | 自动审核关闭 | 待人工审核 | 系统 | 存量单据如何处理 |
注意，不能把模型输出当作最终状态机。它只是将 PRD 中的状态关系“摊平”展示。真正的状态名称和流转规则，还需要产品、研发、测试团队共同确认。
核心模块三：从状态机反推接口清单，而非让模型凭空设计 API
状态机清晰之后，再拆解接口会稳妥得多。
第三轮 Prompt：
请根据已确认的状态机，整理研发需要评估的接口清单。
要求：
1. 不要生成完整代码；
2. 不要编造具体 URL；
3. 只输出接口用途、调用方、被调用方、输入信息、输出信息、异常情况；
4. 如果某个字段来源不明确，请标记“待确认”；
5. 区分前台用户接口、后台审核接口、系统内部接口。
输出格式：
接口场景 | 调用方 | 被调用方 | 需要输入 | 需要返回 | 异常与边界 | 待确认这一步得到的不是最终 OpenAPI 文档，而是一份“接口评审清单”。
| 接口场景 | 调用方 | 被调用方 | 需要输入 | 需要返回 | 异常与边界 | 待确认 |
|---|---|---|---|---|---|---|
| 用户提交退款申请 | 前端 | 售后服务 | 订单 ID、退款原因、凭证 | 退款单 ID、当前状态 | 重复提交、订单不可退 | 凭证是否必填 |
| 查询退款进度 | 前端 | 售后服务 | 退款单 ID | 状态、审核原因、预计处理时间 | 单据不存在、无权限 | 是否展示内部拒绝原因 |
| 人工审核退款 | 审核后台 | 售后服务 | 退款单 ID、审核结果、备注 | 审核后状态 | 并发审核、状态已变更 | 审核备注是否必填 |
| 获取风控结果 | 售后服务 | 风控服务 | 订单 ID、用户 ID、商品类型 | 风险等级、命中原因 | 超时、结果为空 | 是否需要降级策略 |
研发评审时，这张表比“请后端评估一下接口”更具可操作性。后端可以补充技术方案，测试可以补充测试用例，产品可以填补规则空白。
辅助模块一：让模型生成测试点，但必须附带来源
需求拆解完成后，通常会让模型生成一版测试点。这里有一个小技巧：要求每条测试点都关联到具体的状态或规则来源。
请基于上面的状态机和接口清单生成测试点。
要求：
1. 按正常流程、异常流程、权限、并发、配置开关、通知展示分类；
2. 每条测试点必须关联一个状态流转或接口场景；
3. 对依据不足的测试点标记“推测，需确认”；
4. 不要生成与需求无关的泛泛测试项。输出示例：
| 分类 | 测试点 | 关联依据 | 备注 |
|---|---|---|---|
| 正常流程 | 普通订单提交退款后进入待处理 | 提交退款申请接口、已创建 -> 待处理 | 需确认是否自动通过 |
| 异常流程 | 风控服务超时时是否进入重试或人工审核 | 获取风控结果接口 | 需求未明确 |
| 并发 | 两个审核员同时审核同一退款单 | 人工审核退款接口 | 需要后端加幂等或状态校验 |
| 配置开关 | 自动审核关闭后新单是否进入人工审核 | 后台开关规则 | 存量单据待确认 |
| 权限 | 非审核员不能访问审核接口 | 审核后台接口 | 权限规则需补充 |
测试同事不一定直接照单执行，但可以基于这张表补充测试用例，尤其是异常路径和并发场景。
辅助模块二：做一次“幻觉检查”
Claude Opus 4.8 对长文档的整理能力较为稳定，但仍然可能把经验性内容写得像事实。因此，有必要增加一轮反向检查：
请审查你前面输出的内容，找出可能不是 PRD 原文明确支持的结论。
输出：
1. 可能来自推测的内容；
2. 需要原文证据的内容；
3. 建议向产品确认的问题；
4. 如果没有依据，请明确说明“原文未说明”。这一步非常关键。例如，模型可能会默认：
- 审核拒绝后发送站内信；
- 高风险订单进入人工审核；
- 风控超时走降级策略；
- 后台配置支持灰度发布；
- 审核记录需要审计日志。
这些在真实系统中确实很常见，但如果 PRD 中没有写明，就不能当作已确认需求。技术方案中可以建议，但必须标注为“待确认”或“设计建议”。
辅助模块三：用多模型交叉验证，但不要变成投票
面对复杂需求时，偶尔可以将同一份结构化结果交给另一个模型进行审查。目的不是比较谁“更强”，而是让不同模型从不同角度发现潜在问题。
一个比较实用的 Prompt：
你是需求评审中的挑错者。
请检查下面的状态机、接口清单和测试点，重点找：
1. 状态流转矛盾；
2. 遗漏的异常路径；
3. 接口职责不清；
4. 测试点与需求不一致；
5. 可能需要产品确认的问题。
不要重写整份方案，只输出问题清单。多模型交叉验证的意义在于扩大视角，而不是少数服从多数。最终判断仍然要回到 PRD 原文、业务负责人确认以及研发设计约束。
我会保留的人工决策环节
这套流程跑下来，确实能节省不少时间，但关键决策仍然需要人工来拍板：
- 状态命名：必须由研发和产品统一，避免后端、前端、运营后台各叫各的；
- 接口边界：哪些能力放在售后服务，哪些依赖风控服务，需要架构师判断；
- 异常策略：超时、重试、降级、补偿不能仅看 PRD，还要结合系统现状；
- 测试优先级：模型能列出很多点，但版本周期有限，优先级需要人工排列；
- 对外文案：退款原因、拒绝说明、通知内容涉及用户理解和合规要求，不能随意生成。
AI 最擅长的是“整理、暴露矛盾、生成初稿、提醒遗漏”。真正要落实到系统实现，还是要靠团队评审。
数据与安全边界
在公司场景中处理 PRD、接口文档、会议纪要时，脱敏是基础操作。通常需要先替换以下内容：
- 客户名称、供应商名称；
- 真实订单号、手机号、邮箱、身份证号；
- 内部系统域名、IP、数据库表名；
- 未公开的产品策略；
- 合同、价格、风控规则细节；
- 员工姓名和内部组织信息。
可以保留的是抽象后的业务对象和规则结构，例如“订单 ID”“用户 ID”“风控等级”“审核结果”。如果涉及金融、医疗、政务、教育等高敏场景，AI 输出只能作为辅助整理，最终仍需由专业人员审核把关。
一套可复用的 PRD 拆解流程
最后，将这次实践经验压缩成一个标准流程，适合产品、研发、测试团队共同使用：
- 原文脱敏：先替换敏感信息；
- 目录重排：让模型整理业务目标、对象、角色、规则和缺失点；
- 术语对齐：找出同义状态、字段名不一致的问题；
- 状态机整理：输出状态、事件、条件、下一个状态；
- 接口清单：只列接口场景和输入输出，不急着写代码；
- 测试点生成：按正常、异常、权限、并发、配置开关分类；
- 幻觉检查：让模型标出推测内容；
- 人工评审：产品确认规则，研发确认方案，测试确认覆盖；
- 沉淀模板：把确认后的状态机、接口清单、测试点放回项目文档。
结尾：别让 AI 替你拍板，但可以让它先把问题摊开
Claude Opus 4.8 这类模型在长文档需求分析中确实有实用价值，尤其适合处理 PRD、会议纪要、接口说明混杂在一起的情况。它能帮你把散落的信息整理成状态机、接口清单和测试点，也能提前暴露许多“评审会上迟早会吵起来”的问题。
但它的边界也很清晰：模型不了解你们系统的历史技术债，不清楚线上已有多少存量数据，也不知道某个字段背后是否连着客服流程、财务流程或合规要求。
因此，一个务实的建议是：从一个低风险、可验证的需求开始尝试。不要直接让 AI 写完整技术方案，而是先让它做结构化整理和问题清单。只要在 Prompt 中明确“不要新增规则”“不确定就标待确认”“输出可评审表格”，它就能成为一个不错的需求分析助手。最终能否进入开发阶段，仍然要回到原始资料、团队评审和人工责任链上。