Claude Opus 4.8 遗留系统需求拆解：会议纪要变可评审方案
有一次接到一个不太讨喜的需求：把一套跑了好几年的内部审批系统改造成“统一流程中心”。业务方给了三份材料：一份 40 多页的会议纪要、一份旧 PRD、几张流程截图。看起来像需求分析，实际更像考古。字段名不统一、流程节点前后矛盾，还有不少“沿用现有逻辑”“按原规则处理”这种只有老同事才懂的话。
这次主要用 Claude Opus 4.8 做长文档拆解和需求归纳。重点不是工具对比，而是复盘它在复杂需求分析里怎么用得更稳。
这篇更适合产品经理、研发负责人、架构师、测试工程师一起看。尤其是那种需求资料很多、业务规则很绕、但团队又急着进入评审的场景。
一开始以为只是“让 AI 总结文档”
最初做得比较粗暴：把脱敏后的 PRD 和会议纪要丢进去，让 Claude 帮忙“总结需求并输出技术方案”。
结果并不差，甚至很顺。它能把背景、目标、用户角色、主要流程写得很完整。但评审时问题来了：测试同学问“异常审批退回后，重新提交走原节点还是回到发起节点？”后端同学问“历史单据迁移后，原审批状态怎么映射？”产品同学又补了一句：“其实财务复核规则不是所有部门都一样。”
这时才发现，AI 写出一份漂亮文档并不难，难的是发现原始需求里的空洞、冲突和隐含规则。对遗留系统改造来说，最有价值的不是“总结”，而是“把不能直接开发的地方暴露出来”。
后来把任务拆成了三层：先抽实体，再拆流程，最后生成评审材料。
核心模块一：先让 Claude 抽“业务对象”，不要急着写方案
遗留系统的需求文档里，经常混着很多叫法：申请单、流程单、审批单、报销单、任务单，有时候指的是同一个对象，有时候又不是。
所以第一步不让 Claude 写方案，而是让它做业务对象归一化。
使用的 Prompt 类似这样：
你是企业软件需求分析助手。下面是脱敏后的旧 PRD、会议纪要和流程说明。
请先不要写技术方案，只做业务对象梳理。
输出：
1. 文档中间出现的业务对象列表；
2. 每个对象的别名、字段、状态、关联对象；
3. 哪些对象可能是同一个概念但叫法不同；
4. 哪些字段含义不清，需要业务确认；
5. 不要补充文档中没有出现的规则。这一轮输出很有用。它把“审批单”和“流程实例”区分开，也指出“审批状态”和“单据状态”在文档里被混用。
比如它会整理成这样：
| 对象 | 可能别名 | 关键字段 | 疑点 |
|---|---|---|---|
| 申请单 | 审批单、业务单据 | 申请人、部门、金额、状态 | 状态枚举不完整 |
| 流程实例 | 流程单、审批流程 | 当前节点、审批人、流转记录 | 是否一单一流程未说明 |
| 审批任务 | 待办、节点任务 | 处理人、处理动作、处理时间 | 加签后任务归属不清 |
| 审批规则 | 流程规则、财务规则 | 部门、金额区间、审批链 | 部门差异规则缺证 |
这一步对后续开发很关键。很多系统改造翻车，不是因为代码写错，而是因为大家讨论时用的是同一个词，脑子里想的却不是同一个对象。
核心模块二：把流程拆成“正常路径 + 异常路径 + 状态机”
第二步才进入流程。这里没有让 Claude 直接画大而全的流程图，而是让它先拆路径。
请基于上一步的业务对象，整理审批流程。
要求：
1. 区分正常路径、异常路径、人工干预路径；
2. 每个节点写清楚触发条件、输入、输出、状态变化；
3. 如果文档只写了“退回”“撤回”“驳回”，请不要合并，分别列出疑点；
4. 输出一个状态流转表；
5. 标记每条规则的来源：旧 PRD / 会议纪要 / 流程截图。这个 Prompt 有两个关键点：一是强制区分路径。很多需求文档只讲 happy path，但真实系统里，退回、撤回、转交、加签、超时、作废才是最容易出问题的地方。二是要求标记来源。没有来源的规则，不能直接进入开发。
Claude Opus 4.8 在长文档一致性上表现比较适合这类任务。它能记住前面提到的对象定义，再把流程节点和状态变化关联起来。但仍然不会把它的输出当最终事实，而是把它当成“评审前的结构化草稿”。
一个比较实用的状态流转表如下：
| 当前状态 | 触发动作 | 下一状态 | 规则来源 | 待确认 |
|---|---|---|---|---|
| 草稿 | 提交 | 审批中 | 旧 PRD | 是否允许空附件提交 |
| 审批中 | 主管通过 | 财务复核中 | 流程截图 | 金额阈值是否影响节点 |
| 审批中 | 主管退回 | 待修改 | 会议纪要 | 重新提交后回原节点还是首节点 |
| 财务复核中 | 驳回 | 已驳回 | 旧 PRD | 驳回后能否重新发起 |
| 审批中 | 发起人撤回 | 已撤回 | 会议纪要 | 已审批节点是否保留记录 |
这张表比一段自然语言说明更适合评审。产品、开发、测试都能围绕它补规则。
核心模块三：让 AI 生成“问题清单”，而不是替团队拍板
第三步是觉得最有价值的一步：让 Claude 专门找问题。
请审查以上业务对象和流程表，输出需求评审问题清单。
分类包括：
1. 业务规则冲突；
2. 字段定义不清；
3. 状态流转缺失；
4. 权限边界不明确；
5. 历史数据迁移风险；
6. 测试用例需要覆盖的高风险场景。
要求：
- 每个问题都说明来自哪段材料；
- 不要自行给最终答案；
- 优先列出会影响开发估时、数据库设计、接口设计和测试范围的问题。这一步可以把“AI 总结文档”变成“AI 辅助评审”。
它通常会产出一些很实际的问题：
- 旧系统存在“部门负责人代审”，新系统是否继续支持？
- 审批人离职或组织架构调整后，历史流程如何展示？
- 已归档单据是否允许管理员更正字段？
- 金额变更后是否重新计算审批链？
- 移动端审批与 PC 端审批的权限是否完全一致？
- 历史单据迁移时，旧状态如何映射到新状态？
- 流程规则调整后，对已发起但未结束的单据是否生效？
这些问题不一定都要在第一期解决，但必须被看见。否则开发完成后再补，成本会高很多。
辅助模块一：把输出转成研发能用的接口草案
需求评审过一轮后，会让 Claude 基于确认后的对象和流程，生成接口草案。注意是草案，不是最终 API。
请根据已确认的业务对象和状态流转，生成接口草案。
输出：
1. 接口名称；
2. 请求方法；
3. 核心入参；
4. 核心出参；
5. 权限要求；
6. 失败场景；
7. 需要后端确认的问题。
不要编造具体数据库字段，不要假设未确认的鉴权系统。它可以生成类似这样的结构：
| 接口 | 方法 | 用途 | 风险点 |
|---|---|---|---|
/workflow/applications | POST | 创建申请单 | 草稿与提交是否分离 |
/workflow/applications/{id}/submit | POST | 提交流程 | 提交时是否锁定字段 |
/workflow/tasks/{id}/approve | POST | 审批通过 | 并发审批冲突 |
/workflow/tasks/{id}/reject | POST | 驳回 | 驳回后状态映射 |
/workflow/applications/{id}/timeline | GET | 查询流转记录 | 历史记录展示范围 |
这里的价值不是让 AI 替架构师设计接口，而是快速形成讨论底稿。后端可以基于它补鉴权、幂等、事务边界和异常码；前端可以提前判断页面交互是否缺接口；测试可以同步拆用例。
辅助模块二：测试用例生成要绑定状态机
测试同学最怕的不是没有用例，而是用例覆盖不到真实风险。审批系统尤其如此。
把状态流转表丢给 Claude，让它只围绕状态机生成测试用例：
请基于以下状态流转表生成测试用例。
要求：
1. 覆盖正常流转、退回、驳回、撤回、重复提交、并发审批；
2. 每条用例包含前置条件、操作步骤、预期结果；
3. 标记优先级 P0 / P1 / P2；
4. 不要生成与流程无关的泛泛用例；
5. 输出接口测试和页面测试两个视角。AI 生成的测试用例不能直接照搬，但它能提醒团队别漏掉边界场景。比如：同一审批任务被两个人同时处理；审批过程中申请人修改金额；审批人无权限访问非本人任务；流程配置变更后，历史单据继续按旧规则流转；移动端撤回后，PC 端列表状态是否同步。这些都是实际项目里很容易出问题的地方。
辅助模块三：用“证据等级”减少 AI 幻觉
Claude 的长文档能力不错，但它仍然可能把合理推断写得像事实。做法是给每条结论加证据等级：
请为每条需求结论标注证据等级：
- A：原文明确说明；
- B：多处材料可相互印证；
- C：根据上下文推断，需人工确认；
- D：材料缺失，不能作为开发依据。
请把 C 和 D 单独列成评审问题。这个方法很简单，但能显著降低误用风险。尤其是遗留系统改造，很多规则都来自“大家以为一直是这样”。AI 如果把这些经验性说法写进正式文档，很容易造成误导。
固定的工作流
经过几轮项目实践，把 Claude Opus 4.8 用在需求分析里的流程固定成了这样：
- 材料脱敏：去掉客户名称、真实账号、内部地址、合同编号、敏感截图；
- 对象抽取：统一业务名词，识别别名和字段疑点；
- 流程拆解：拆正常路径、异常路径、状态流转；
- 规则溯源：每条规则标记来自哪份材料；
- 问题清单：专门找冲突、缺口和待确认项；
- 接口草案：生成可讨论的 API 和权限边界；
- 测试视角复核：围绕状态机补高风险用例；
- 人工评审：产品、研发、测试共同确认后再进入排期。
这里面最重要的不是 Prompt 写得多复杂，而是顺序。先对象，再流程，再问题，再方案。不要一上来就让模型写最终文档。
常见误区
1. 把“总结得很顺”当成“需求已经清楚”
AI 很擅长把混乱材料写成通顺文本，但通顺不代表准确。需求分析要看规则是否可执行、边界是否明确、状态是否闭合。
2. 让 AI 直接替业务决定规则
比如“退回后回到哪个节点”“历史流程是否按旧规则展示”，这些不是模型该决定的。AI 可以列选项和影响，但最终要业务和技术负责人确认。
3. 忽略脱敏
会议纪要、截图、接口文档里经常包含真实姓名、手机号、客户名称、内部系统地址、Token、合同条款等信息。输入模型前必须脱敏。能用占位符表达的，就不要放真实数据。
4. 不做原文追溯
需求文档最终要能回到来源。否则评审时一句“这条规则哪里来的”，整份文档的可信度都会下降。
边界：Claude 适合做什么，不适合做什么
结合这次使用，对 Claude Opus 4.8 的定位是：
适合：长文档阅读和归纳；多份材料之间的规则对齐；业务对象抽取；流程和状态机整理；需求评审问题生成；技术方案初稿和测试用例草案。
不适合直接承担：最终业务规则拍板；法务、金融、医疗等专业责任判断；未验证的接口设计定稿；生产代码直接上线；对外承诺性文档。
如果涉及金融、医疗、政务、合同、客户数据等场景，还要保留人工审核链路。AI 可以辅助整理材料，但不能替代专业人员确认结论。
结尾：把 AI 放在“评审前整理”这个位置
现在更愿意把 Claude Opus 4.8 当成需求评审前的结构化助手，而不是“自动写 PRD 的工具”。它最有价值的地方，是把一堆会议纪要、旧文档、截图和口头规则，整理成对象表、状态表、问题清单和接口草案。
如果团队刚开始尝试，可以先选一个低风险场景：比如内部工具改造、历史流程梳理、接口文档重写。不要一上来就让 AI 直接产出最终方案。
比较稳的原则是：让 AI 暴露问题，让人决定规则；让 AI 生成草案，让团队做评审；让 AI 提高整理效率，但不要把它当最终责任人。这样用下来，它确实能减少很多重复劳动，也能让需求评审更早暴露真正的问题。