文章摘要本文以“智能审核”需求为例复盘如何用 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_passedAI 判断可放行展示、进入抽检ai_suspectedAI 判断可疑转人工复核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 步脱敏材料处理会议纪要、业务描述、历史问题和样例数据。拆未知数先列待确认问题不急着写 PRD。建状态机把模糊流程转成状态、动作和流转条件。生成验收标准要求每条标准可验证、可测试。研发评估清单提前暴露接口、数据、权限、审计、降级问题。测试点反推从状态转移、异常流程、角色权限生成测试点。人工复核回写把确认后的内容写回正式 PRD、技术方案和测试计划。这套流程不复杂但比“让 AI 直接写完整需求文档”可靠很多。结尾复杂需求不要追求一次生成Claude Opus 4.8 适合处理长文档、复杂需求拆解、会议纪要整理和验收标准生成但它最适合的位置不是“最终拍板的人”而是“把混乱信息整理成可讨论材料的人”。如果你也想在研发团队里引入大模型辅助需求分析我建议从低风险、可验证的任务开始列待确认问题、整理会议纪要、生成状态机、补充验收标准。等团队熟悉之后再把它接入更复杂的需求评审、测试设计和上线风险检查。真正能落地的 AI 工作流不是让模型一次写出漂亮文档而是让每一步输出都能被人确认、被测试验证、被团队复用。
