文章摘要：本文以“智能审核”需求为例，复盘如何用 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 结构挺完整，有背景、目标、功能列表、流程图描述、异常处理、验收标准。乍看像那么回事，但细看会发现几个问题：

1. 它会默认“异常内容”已有清晰定义
   实际上业务方只给了一个方向，违规、低质、重复、敏感、格式错误都可能被归到异常里。

2. 它会把 AI 审核写成确定性能力
   例如“系统自动识别并拦截异常内容”，这句话在评审时很危险。模型判断有误差，业务上必须区分“建议拦截”“人工复核”“直接放行”。

3. 它会遗漏运营和客服的回滚路径
   如果内容被误拦，谁能恢复？恢复后是否重新进入审核？是否留痕？这些都不是纯研发问题。

这次输出不是没价值，它的问题在于：太像一份完整文档，但证据链不够。后来我调整了用法，不再让 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 步：

1. 脱敏材料：处理会议纪要、业务描述、历史问题和样例数据。
2. 拆未知数：先列待确认问题，不急着写 PRD。
3. 建状态机：把模糊流程转成状态、动作和流转条件。
4. 生成验收标准：要求每条标准可验证、可测试。
5. 研发评估清单：提前暴露接口、数据、权限、审计、降级问题。
6. 测试点反推：从状态转移、异常流程、角色权限生成测试点。
7. 人工复核回写：把确认后的内容写回正式 PRD、技术方案和测试计划。

这套流程不复杂，但比“让 AI 直接写完整需求文档”可靠很多。

结尾：复杂需求不要追求一次生成

Claude Opus 4.8 适合处理长文档、复杂需求拆解、会议纪要整理和验收标准生成，但它最适合的位置不是“最终拍板的人”，而是“把混乱信息整理成可讨论材料的人”。

如果你也想在研发团队里引入大模型辅助需求分析，我建议从低风险、可验证的任务开始：列待确认问题、整理会议纪要、生成状态机、补充验收标准。等团队熟悉之后，再把它接入更复杂的需求评审、测试设计和上线风险检查。

真正能落地的 AI 工作流，不是让模型一次写出漂亮文档，而是让每一步输出都能被人确认、被测试验证、被团队复用。