文章摘要：本文以“智能审核”需求为例，复盘如何用 Claude Opus 4.8 将一句模糊业务需求拆成可评审、可开发、可测试的方案。文章重点介绍从未知数梳理、状态机建模、验收标准生成，到研发评估、测试点反推和会议纪要整理的完整流程，并提醒需求文档同样需要脱敏，AI 输出只能辅助分析，最终仍需人工复核与专业确认。
前段时间，产品同事在会上丢过来一句话：“我们能不能给后台加一个智能审核，把异常内容先拦一下？”这句话听起来不复杂，但真要落到研发侧，问题马上变多：异常内容指什么？谁来定义规则？误拦怎么办？审核结果要不要可追溯？接口怎么改？历史数据怎么处理？
我这次没有直接让模型“帮我写 PRD”，而是把 Claude Opus 4.8 当成一个需求拆解助手来用。为了减少在不同模型之间来回切换，我把同一份材料放进一个能切换 ChatGPT、Claude、Gemini、Grok 等模型的统一环境里观察输出差异，测试环境是 https://ouai.me；但本文重点只讲 Claude Opus 4.8 在复杂需求分析里的工作流，不做模型排行榜。
这篇文章更适合 CSDN 上的产品经理、研发负责人、后端开发、测试工程师阅读。场景也很具体：把一句模糊业务需求，拆成研发能评估、测试能设计用例、业务能确认边界的需求文档。
一、第一次直接生成 PRD，问题不少
我一开始的 Prompt 很粗：
请根据下面的需求描述，生成一份完整 PRD：
我们希望在后台增加智能审核能力，对异常内容进行识别和拦截。
Claude Opus 4.8 输出的 PRD 结构挺完整，有背景、目标、功能列表、流程图描述、异常处理、验收标准。乍看像那么回事，但细看会发现几个问题：
它会默认“异常内容”已有清晰定义
实际上业务方只给了一个方向，违规、低质、重复、敏感、格式错误都可能被归到异常里。
它会把 AI 审核写成确定性能力
例如“系统自动识别并拦截异常内容”，这句话在评审时很危险。模型判断有误差，业务上必须区分“建议拦截”“人工复核”“直接放行”。
它会遗漏运营和客服的回滚路径
如果内容被误拦，谁能恢复？恢复后是否重新进入审核？是否留痕？这些都不是纯研发问题。
这次输出不是没价值，它的问题在于：太像一份完整文档，但证据链不够。后来我调整了用法，不再让 Claude 一步写完，而是分阶段逼它暴露不确定性。
二、核心模块 1：先拆“需求里的未知数”
我现在处理模糊需求时，第一步不是写文档，而是让模型列未知数。
你是一个资深需求分析师。请不要直接写 PRD。
请基于这句话拆解需求中的未知信息：
“后台增加智能审核能力，对异常内容进行识别和拦截。”
按以下格式输出：
1. 需要业务方确认的问题
2. 需要研发确认的问题
3. 需要测试确认的问题
4. 需要合规或风控确认的问题
5. 如果这些问题不确认，可能导致的上线风险
要求：
– 不要自行假设答案
– 每个问题后说明为什么必须确认
– 优先列出会影响系统设计和验收标准的问题
Claude Opus 4.8 在这一步的表现比较稳，尤其擅长把一句话拆成跨角色问题。例如它会追问：
- 异常内容的类型是否有分级？
- AI 审核结果是强拦截还是弱提示？
- 人工复核是否需要双人确认？
- 审核记录保留多久？
- 误判后的申诉和恢复流程是什么？
- 是否涉及个人信息、合同、医疗、金融等敏感内容？
- 是否需要向用户展示审核原因？
这些问题看起来普通，但在需求评审里非常实用。因为很多项目延期，不是因为代码难写，而是因为一开始没有定义边界。
三、核心模块 2：把“智能审核”拆成状态机
第二步，我会让 Claude 把需求拆成状态流转，而不是继续写自然语言。
请把“智能审核”需求拆成状态机。
已知信息：
– 用户提交内容
– 系统进行 AI 初审
– 部分内容需要人工复核
– 审核结果会影响内容是否展示
请输出：
1. 状态列表
2. 状态之间的触发条件
3. 每个状态允许的操作
4. 每个状态下前台和后台看到的结果
5. 容易遗漏的异常状态
要求：
– 不要把模型判断视为绝对正确
– 必须包含误判、重审、人工恢复、审核超时
这一轮输出比 PRD 初稿更接近研发语言。最后我们沉淀出一版状态：
| pending_ai_review | 等待 AI 初审 | 入队、重试、超时处理 |
| ai_passed | AI 判断可放行 | 展示、进入抽检 |
| ai_suspected | AI 判断可疑 | 转人工复核 |
| manual_passed | 人工通过 | 展示、记录复核人 |
| manual_rejected | 人工拒绝 | 隐藏、通知、记录原因 |
| restored | 误判后恢复 | 留痕、重新展示 |
| review_timeout | 审核超时 | 降级策略、告警 |
这个状态表很关键。它让产品、研发、测试终于能围绕同一张表讨论，而不是各自理解“智能审核”。
四、核心模块 3：让 Claude 生成验收标准，而不是只写功能点
很多需求文档的问题是功能写得多，验收写得少。于是第三步，我让 Claude Opus 4.8 生成验收标准，但加了限制条件。
请基于上述状态机生成验收标准。
要求：
– 按功能验收、异常验收、权限验收、数据留痕、性能与降级分类
– 每条验收标准必须可验证
– 不使用“体验良好”“准确识别”“及时处理”这类模糊词
– 如果需要人工判断，请明确判断角色
它给出的内容经过人工修改后，大概变成这样：
| 功能验收 | 内容提交后必须生成唯一审核记录 |
| 功能验收 | AI 初审结果必须包含建议结果、置信区间、命中规则 |
| 异常验收 | AI 服务超时后进入降级队列，不直接丢弃内容 |
| 权限验收 | 只有审核员和管理员可以修改人工审核结果 |
| 数据留痕 | 每次状态变化必须记录操作人、时间、原因 |
| 降级验收 | AI 服务不可用时，系统应切换到人工待审流程 |
| 复核验收 | 被恢复的内容必须保留原拒绝记录和恢复原因 |
这里要注意，“置信区间”不一定适合所有系统。如果模型服务只返回分类标签，没有分数，就不能强行写进需求。AI 生成的验收标准必须再回到真实接口能力和业务流程里核对。
五、辅助模块 1：用它整理会议纪要，但不要让它替你拍板
需求评审会后，我会把脱敏后的会议纪要交给 Claude，让它整理决议和待确认项。
请整理下面的会议纪要。
输出：
1. 已确认结论
2. 未确认问题
3. 需要谁确认
4. 影响哪些模块
5. 下一步动作和截止时间
要求：
– 不要改写与会者原意
– 对存在分歧的地方标记“未达成一致”
– 不要替任何角色做最终决定
这一步很适合减少会后扯皮。尤其是需求里涉及产品、研发、测试、运营、合规多个角色时，最怕大家会后记忆不一致。
我比较喜欢 Claude Opus 4.8 的一点是，它在长文本整理时不太急着下结论，适合处理会议纪要、需求讨论、评审记录这类材料。但仍然要人工复核，因为它可能把“有人提到过的方案”整理成“已经确认的方案”。
六、辅助模块 2：让研发评估更早介入
需求分析不是产品一个人的事。状态机和验收标准出来后，我会继续让 Claude 生成研发评估清单。
请基于当前需求，生成研发评估清单。
请从以下角度分析：
– 需要新增或修改的接口
– 数据库表或字段变化
– 异步任务和消息队列
– 权限控制
– 日志与审计
– 灰度发布
– 回滚方案
– 可能影响的历史数据
要求：
– 不写具体代码
– 每一项说明需要研发确认的点
– 标出高风险项
这一步的产物不能直接当技术方案，但可以帮助研发提前发现问题。例如：
- 审核记录是否单独建表；
- 内容表是否新增审核状态；
- AI 审核调用是否异步；
- 失败重试是否会导致重复审核；
- 人工复核操作是否需要审计日志；
- 老数据上线后默认处于什么状态；
- 是否需要灰度到部分业务线。
这些问题越早暴露，后面返工越少。
七、辅助模块 3：测试用例从“状态转移”反推
测试同学最有感的一点是：有了状态机，用例就不再只围绕页面按钮写。
请基于审核状态机生成测试点，不要生成完整用例。
要求：
– 覆盖每个状态到其他状态的合法流转
– 标记非法流转
– 覆盖 AI 服务超时、人工复核撤销、误判恢复
– 覆盖不同角色权限
– 输出测试点、前置条件、预期状态
比如 manual_rejected 是否能直接回到 ai_passed？通常不应该。
review_timeout 后是进入人工队列，还是允许内容先展示？这就必须由业务明确。
AI 在这里的价值不是替测试写完所有用例，而是帮助测试从“页面操作”上升到“业务状态正确性”。对审核、订单、支付、库存这类系统尤其有用。
八、我会重点检查 Claude 输出里的三类风险
1. 过度产品化的表达
例如：
系统自动精准识别违规内容。
这种话必须改。更稳妥的写法是：
系统根据审核策略给出风险判断，命中高风险规则的内容进入人工复核或拦截流程。
2. 把建议当成结论
模型可能会写：
建议采用异步审核架构。
这只能算建议。是否异步，要看响应时间、业务容忍度、队列能力、失败补偿机制和研发成本。
3. 忽略责任边界
涉及审核、合规、金融、医疗、政务等场景时，AI 只能辅助整理和初步识别，不能替代专业人员判断。对外展示的审核原因、处罚说明、用户通知，都要经过人工确认。
九、多模型工具怎么用才不变成“看热闹”
我不建议每个需求都拿多个模型跑一遍。真正适合交叉验证的情况是：
- 需求非常模糊，模型可能做出不同假设；
- 涉及合规、风控、权限、审计等高风险模块；
- 文档很长，担心单一模型遗漏细节；
- 输出结果会影响排期、架构或上线策略；
- 团队内部对方案存在明显分歧。
判断一个多模型 AI 工具是否适合需求分析，我主要看这些点：
- 能不能保留同一份上下文；
- 能不能方便复用 Prompt；
- 是否支持长文档和附件；
- 是否方便对比不同模型输出；
- 是否有清晰的数据处理说明；
- 是否能把结果沉淀到团队文档里；
- 是否支持人工复核，而不是只追求生成速度。
交叉验证的目的不是找“谁更聪明”，而是看不同模型会不会暴露不同盲区。
十、数据和合规边界：需求文档也要脱敏
很多人只知道代码和日志要脱敏，其实需求文档也要。尤其是审核、风控、客户管理、医疗、金融、政务相关系统，需求材料里经常包含敏感信息。
不建议直接输入：
- 真实客户名称；
- 用户手机号、身份证号；
- 内部风控规则细节；
- 未公开产品策略；
- 合同金额和报价；
- 医疗记录或诊断内容；
- 政务材料中的个人身份信息；
- 内部系统地址、Token、Cookie。
可以替换成：
客户A
用户U001
订单O001
规则R001
内部系统S1
敏感字段已脱敏
另外，AI 输出不能替代法律、医疗、金融、政务等专业责任判断。它可以帮你梳理问题、补充检查清单、整理文档，但最终确认必须回到专业人员和组织流程。
十一、最后沉淀下来的工作流
这次实践后，我把 Claude Opus 4.8 用在需求分析里的流程固定成了 7 步：
这套流程不复杂，但比“让 AI 直接写完整需求文档”可靠很多。
结尾：复杂需求不要追求一次生成
Claude Opus 4.8 适合处理长文档、复杂需求拆解、会议纪要整理和验收标准生成，但它最适合的位置不是“最终拍板的人”，而是“把混乱信息整理成可讨论材料的人”。
如果你也想在研发团队里引入大模型辅助需求分析，我建议从低风险、可验证的任务开始：列待确认问题、整理会议纪要、生成状态机、补充验收标准。等团队熟悉之后，再把它接入更复杂的需求评审、测试设计和上线风险检查。
真正能落地的 AI 工作流，不是让模型一次写出漂亮文档，而是让每一步输出都能被人确认、被测试验证、被团队复用。
