15 AI质量靠Badcase闭环

专业解读

用用户任务定义质量标准

这张白板图从线上结果进入 Badcase 收集，再经过归因、Prompt 或 RAG 或模型调整、评测回归和上线，形成持续改进的路径。AI 产品经理需要明确产品质量如何影响用户完成工作。一个生成结果可能文字通顺，却缺少必要信息、引用错误材料或者无法进入下一步操作。质量标准应来自具体业务任务，说明用户需要什么结果、哪些信息必须准确、哪些步骤需要确认，以及什么情况下任务不能继续。

质量标准需要转成可以检查的要求。资料整理任务可以检查信息完整性、来源对应关系和结构要求；工具执行任务需要检查参数、权限和实际状态；具有专业影响的内容需要确认责任人与核查流程。产品经理应邀请业务人员参与制定标准，使用真实任务验证标准是否容易理解。不同人员对结果质量判断不一致时，需要讨论具体案例，形成能够共同使用的判断依据。

为每个Badcase保存完整条件

图中的 Badcase 卡片包括场景与输入、预期与实际、问题类型与影响、原因与修正、回归结果。收集问题时应保存足够条件，使团队能够重新检查当时的行为。只记录用户认为结果不好，难以判断问题发生在哪里。任务编号、产品版本、知识版本、模型配置、输入资料和结果内容都可能影响核查，应根据项目需要确定记录范围和读取权限。

问题来源可以是用户反馈、运营观察、测试运行和监控发现。记录人员应保留原有事实，区分实际结果与个人推测。资料不足、引用错误、工具失败和用户误解提示，需要分别说明发生条件。涉及敏感资料的案例应遵守项目资料管理要求，让有职责的人员能够核查，同时控制传播范围。完整记录有助于减少重复询问，也让修正人员能够使用同一组条件验证结果。

根据影响安排处理顺序

问题处理需要考虑用户任务与业务影响。产品经理可以记录问题是否阻断任务、是否影响重要信息、是否涉及权限和是否持续出现。对于具有较高影响的失败，应及时组织检查并明确处理责任。普通表达问题也需要记录，但处理顺序应结合实际影响确定。不能仅根据反馈数量排序，因为某些重要问题可能出现次数不多，却涉及关键操作和专业责任。

安排处理时应检查受影响范围，包括相关用户、任务类型、资料来源和产品版本。团队需要确认问题是否具有共同条件，是否可能影响其他功能，以及当前用户如何继续完成工作。处理清单应说明负责人、目标时间和复验要求。状态变化需要有证据支持，不能把已经提出修正方法直接记录为已经解决。实际完成修正并通过检查之后，才具备关闭问题的依据。

沿着工作流核查问题原因

归因应沿着输入、知识、检索、模型、工具、人工确认和输出逐项检查。资料本身缺失时，需要完善知识来源；检索选择了错误材料时，需要检查查询条件和排序；模型忽略已有依据时，需要检查任务要求与处理配置；工具执行错误时，需要检查参数、权限与状态。产品经理应与相应负责人共同核查，把原因建立在运行记录和可重复结果之上。

同一个表面问题可能有多个原因。例如用户认为回答不完整，可能是输入缺少条件，也可能是检索遗漏材料，或者输出模板没有包含必要字段。团队应使用原有案例检查每个环节，记录能够支持判断的证据。修正位置确定之后，还要检查该修改会影响哪些任务。对于仍然无法解释的问题，应继续保留检查状态，避免用未经验证的判断代替实际原因。

根据原因选择修正方法

白板图列出 Prompt、RAG 和模型三个调整方向。产品经理需要理解各自适用的条件：任务表达与输出要求需要通过 Prompt 明确，资料覆盖和检索质量需要通过 RAG 改善，模型能力与处理配置需要结合实际评测确认。业务流程、界面提示和人工确认也可能需要修改。修正方案应对应已经核查的问题原因，并说明预计改变什么行为以及如何验证。

修改之前，应保留当前有效配置和对应评测结果，明确需要检查的相关案例。修改过程中应控制变更范围，减少多个因素同时变化造成的核查困难。完成之后使用原有失败案例检查目标行为，再使用有关正常案例检查质量是否受到影响。产品经理应关注用户完成任务的结果，研发人员关注处理过程，测试人员核查预期与实际是否一致，共同判断修改是否有效。

建立可以持续使用的评测集

评测集需要包含代表性任务、重要边界和已经确认的 Badcase。每个案例都应说明输入条件、预期结果、判断规则和来源权限。团队可以按场景、问题类型和影响范围组织案例，便于版本变化时选择需要检查的内容。评测结果应记录版本与运行条件，使不同时间的结果具有可比较基础。案例长期未更新时，应检查它们是否仍然代表当前用户工作。

以下表格对应图中的闭环步骤，帮助产品经理明确每次修正需要留下什么证据。表格应与项目的问题清单连接，记录实际负责人和检查结果。评测通过需要由真实运行支持，无法重复的问题也应说明当前证据与尚未确认的条件，便于后续继续核查。

覆盖异常输入和持续运行风险

图中包含幻觉、注入、A/B 和自动化检查的提示。产品经理需要根据实际功能设计异常输入检查，例如资料相互冲突、输入试图改变系统权限、检索结果缺少依据或者工具响应异常。对于无法满足任务条件的情况，应确认系统能够明确提示并停止不允许的操作。异常检查需要与正常任务一起执行，保证保护措施不会阻碍已经授权的工作。

进行版本比较时，应保持任务条件、评测规则和资料范围一致，分别记录质量、时间和费用。结果差异需要结合案例解释，不能仅根据一个平均分数作出判断。自动化检查可以帮助团队重复验证稳定要求，人工检查则用于理解复杂结果和业务影响。两者都应有明确标准，产品经理负责维护判断规则与用户目标之间的联系。

把质量改进连接到产品运营

上线之后，团队需要继续检查问题是否再次出现，以及用户是否能够完成目标任务。监控可以关注失败类型、处理时间、人工修正和结果采用情况，运营可以收集实际工作中的反馈。某项修正在评测集上有效，进入新的资料条件之后仍然需要观察。产品经理应定期整理新增问题和重复问题，检查是否需要更新知识、流程、提示或评测案例。

Badcase 闭环的价值在于让每次问题处理都形成可检查的知识。团队保留发生条件、原因证据、修正方案和回归结果，后续人员能够理解为什么修改以及如何确认有效。产品经理可以据此识别长期质量问题，安排持续改进任务，并向业务负责人说明当前能力范围。问题能够被发现、原因能够被核查、修正能够被验证，AI 产品才能在实际使用中逐步提高可靠性。