AI缺陷分类要真正落地，前提是先把缺陷单的字段和判定口径定清楚，再让AI给出建议值、由人工确认后写入。本文按字段设计、实施步骤、角色分工、端到端示例和效果校验五部分展开，适合正在建设缺陷管理机制的测试与质量团队参考，文中会自然说明ONES在缺陷字段配置与流转确认环节的承载方式。
要点总览（TL;DR）
- 先固定缺陷单的字段与判定口径：缺陷类型、严重程度、所属模块设为必填，优先级和责任团队可由模块映射推导，枚举值命名统一并配判定说明。
- 实施分四步：抽取历史缺陷清洗标签、按维度选择规则引擎或文本分类模型或大模型提示、在提交环节以建议值呈现、人工确认后回写并保留建议与最终值对照。
- 角色分工要闭环：质量负责人定义口径并裁定争议，提交人与模块负责人确认修正，研发与平台角色负责接入、指标汇总和迭代。
- 效果校验看三个指标：分维度准确率、人工修改率、误分回流率；上线初期每周抽样不少于三十条，口径变更后用同一评估集做回归验证。
- 口径未定稿、评估样本不足、缺少人工确认环节时，AI结果只作参考展示，不直接写入缺陷单正式字段。
先定分类口径：缺陷单需要哪些字段和判定规则
AI分类的质量上限由分类口径决定。字段含义模糊、枚举值重叠时，模型只能学到互相矛盾的标签。开始收集样本之前，先把缺陷单的字段体系固定下来，形成一份团队共同认可的判定规则表。
常用分类维度与判定依据
缺陷分类通常围绕五个维度展开。每个维度都要写清判定依据，并明确维度之间是互斥还是可以并存。
| 维度 | 典型枚举值 | 判定依据 | 关系说明 |
|---|---|---|---|
| 缺陷类型 | 功能错误、界面显示、性能问题、兼容性、数据问题、需求理解偏差 | 按缺陷表现出的直接现象归类，以复现步骤中第一个异常点为依据 | 单选，互斥 |
| 严重程度 | 致命、严重、一般、轻微 | 按对业务可用性的影响判定：核心流程中断为致命，主要功能受阻为严重，有替代路径为一般，体验瑕疵为轻微 | 单选，互斥；与优先级分开判定 |
| 优先级 | 紧急、高、中、低 | 按修复排期的紧迫性判定，结合发布节点与影响范围 | 单选；与严重程度可以不一致，例如轻微问题在发布前也可能紧急 |
| 所属模块/功能 | 按产品功能树取值 | 按缺陷触发位置对应的功能模块判定，跨模块问题归入主要受影响模块 | 单选为主，必要时可加关联模块字段 |
| 责任团队 | 按研发团队或服务划分 | 按模块归属映射到责任团队，由模块负责人确认 | 单选，通常由所属模块推导 |
必填与选填的划分
必填字段控制在AI能够稳定判断的范围内。缺陷类型、严重程度、所属模块建议设为必填，这三项直接决定分派和排期；优先级和责任团队可以由模块映射推导，设为选填或自动带出。枚举值命名要统一，避免“严重/高”“一般/普通”混用，同一含义只保留一个值，并给每个值配一句判定说明，作为标注和复核的共同依据。
用历史缺陷反推口径
口径不必从零起草。抽取近半年到一年的历史缺陷，按现有字段做一次分布统计，重点看三类问题：同一现象被标成不同类型、严重程度与优先级长期混用、模块归属集中在少数几个值上。把争议样本挑出来，由测试负责人组织一次规则评审，逐条确定归属，把结论写回规则表。口径冲突处理完后，规则表才算可用，后续标注和模型评估都以这一版为准。
核心操作步骤：从样本准备到AI建议写入缺陷单
口径确定后，实施过程分为四步。每一步都有明确的输入、动作、输出和完成标志，便于按阶段验收。
步骤一：抽取历史缺陷并清洗标签
输入是历史缺陷库和已评审的规则表。动作包括：按模块和时间范围抽取缺陷，剔除描述过短、无复现信息、重复提交的记录；按规则表重新核对标签，把与口径冲突的旧标签修正或标记为待定；将样本按时间切分为训练集和评估集，评估集保留近期缺陷以贴近当前业务。输出是一份带标签的样本集和一份标签修正记录。完成标志是评估集标签经测试负责人抽检确认，冲突样本已处理完毕。
步骤二：选择实现方式
三种方式适用条件不同，可以组合使用。
| 方式 | 适用条件 | 优点 | 局限 |
|---|---|---|---|
| 规则引擎 | 字段取值可由关键词、模块路径、提交入口等结构化信息直接判断 | 结果可解释、维护成本低 | 对描述自由、表述多样的缺陷覆盖不足 |
| 文本分类模型 | 历史样本量充足，标签分布相对均衡，分类维度固定 | 对表述变化适应性好，可批量处理 | 需要持续标注和迭代，新类型出现时需补充样本 |
| 大模型提示 | 样本量有限，或需要同时输出分类与判定理由 | 启动快，能处理长描述和上下文 | 结果存在波动，需要固定提示模板并做抽样校验 |
常见做法是先用规则处理模块归属这类结构化判断，再用模型处理缺陷类型和严重程度这类需要理解文本的维度。输出是一份实现方案说明，写清每个维度由哪种方式给出建议。完成标志是方案在评估集上跑通，并记录基线表现。
步骤三：接入提交与流转环节
输入是实现方案和缺陷提交页面。动作是把分类服务接入缺陷创建环节，在提交人填写标题和描述后，以“建议值”形式展示类型、严重程度和模块建议，并附上判定依据，例如命中的关键词或相似历史缺陷。建议值不直接覆盖提交人已填内容，只作为可采纳的选项呈现。输出是带建议值的缺陷提交界面。完成标志是提交人能看到建议及其依据，且可以一键采纳或忽略。
步骤四：人工确认与回写
输入是带建议值的缺陷单。动作是由提交人或模块负责人确认或修改分类，确认后写入正式字段；系统保留原始描述、AI建议值和最终值三者的对应关系，供后续分析。输出是分类完成的缺陷单和一份建议与最终值的对照记录。完成标志是每条缺陷都有明确的确认人，对照记录可用于统计修改率。
在ONES中，缺陷作为工作项承载字段与状态流转，ONES Assistant可基于项目和工作项上下文执行创建缺陷、更新状态等操作，使建议生成与确认动作落在同一条缺陷记录上，便于追溯。
角色与交付物：谁定义口径、谁确认结果、谁维护模型
AI缺陷分类涉及三类角色，职责边界不清时最容易出现口径无人拍板、误分无人处理的情况。下表给出职责与交付物对照。
| 角色 | 主要职责 | 交付物 | 交接节点 |
|---|---|---|---|
| 测试负责人/质量负责人 | 定义分类口径，组织规则评审，裁定争议样本，审批口径变更 | 缺陷分类字段与判定规则表、口径变更记录 | 规则表评审通过后移交实施；口径变更时通知标注与模型维护方 |
| 缺陷提交人 | 提交时核对AI建议，按实际情况采纳或修改，补充必要上下文 | 确认后的缺陷单字段 | 提交环节完成确认 |
| 模块负责人 | 复核本模块缺陷的分类，修正误分，反馈典型误分样本 | 模块内误分修正记录、典型误分样本 | 缺陷流转至模块时完成复核 |
| 研发与平台角色 | 接入分类服务，维护建议展示与回写逻辑，汇总修改率与误分数据，迭代规则或模型 | 接入方案、指标看板、模型或规则迭代记录 | 按迭代周期向质量负责人提交效果报告 |
交接的关键在于形成闭环：模块负责人反馈的误分样本进入样本池，平台角色定期用新样本评估并调整规则或提示模板，质量负责人确认口径是否需要同步修订。ONES的AI能力基于权限体系执行任务，输出过程可追踪、结果可审计，这一特性有助于把确认与修正记录保留在缺陷单上，减少口头交接造成的信息丢失。
示例：一条缺陷从提交到分类确认的完整过程
以下为演示情景，用于说明各环节的判断方式。
提交人填写缺陷：标题为“订单提交后页面一直转圈，约十秒后才显示成功”，描述中附有操作步骤、浏览器版本和一段录屏，提交入口为Web端订单模块。
AI给出建议：缺陷类型为“性能问题”，依据是描述中出现“一直转圈”“约十秒”等响应时间表述，且与历史同类缺陷文本相似；严重程度建议“严重”，依据是订单提交属于核心流程，但最终能够成功；所属模块建议“订单-提交”，依据是提交入口与描述中的操作路径。同时给出备选类型“功能错误”，提示若确认存在提交失败则改判。
提交人确认时判断：订单最终提交成功，问题表现为响应慢，采纳“性能问题”和“严重”；考虑到当前处于大促前的发布窗口，将优先级手动调为“紧急”，这一项AI未给建议。模块负责人复核时确认模块归属正确，并在备注中记录“响应时间超过阈值，需排查接口耗时”。
最终写入缺陷单的字段为：类型“性能问题”、严重程度“严重”、优先级“紧急”、模块“订单-提交”、责任团队“交易研发”。这条记录同时保留了AI原始建议与人工修改项，其中优先级的人工调整说明了一个可复用规律：发布窗口期的时间敏感问题，优先级需要人工结合排期判断，不宜完全依赖模型。
完成检查：如何验证分类效果并控制误分
分类机制上线后，需要用固定口径的指标持续验证，并设置明确的阻断条件，避免误分扩散。
指标取数口径
| 指标 | 取数口径 | 观察重点 |
|---|---|---|
| 准确率 | 抽样样本中AI建议值与最终确认值一致的条数 ÷ 抽样总条数，按维度分别统计 | 哪个维度最弱，是否需要补充规则或样本 |
| 人工修改率 | 最终值与AI建议值不一致的缺陷数 ÷ 有AI建议的缺陷总数 | 修改集中在哪些值上，是否存在系统性偏差 |
| 误分回流率 | 流转后被模块负责人改判的缺陷数 ÷ 已确认缺陷数 | 提交环节确认是否流于形式 |
抽样复核建议
上线初期建议每周抽样一次，每个分类维度抽取不少于三十条，覆盖各枚举值和主要模块；运行稳定后可调整为每两周或每月一次，并在口径变更、模型迭代、业务大版本发布后临时加抽。复核由测试负责人或指定的质量角色执行，结论记录在案。
口径变更后的回归验证
枚举值增删、判定依据调整、模块结构调整都会影响分类结果。每次变更后，用同一评估集重新跑一遍，对比变更前后的准确率和修改率；若指标明显下降，先回退变更或补充样本，再重新上线。
阻断项
出现以下情况时，不宜让AI结果直接写入缺陷单：分类口径尚未评审定稿；评估样本不足，无法判断各维度表现；提交或流转环节缺少人工确认步骤。这些条件下，AI建议只能作为参考展示，正式字段仍由人工填写。
ONES建议先梳理研发流程、现有数据与高频协作问题，再确定AI能力的应用范围，这一顺序与本文“口径先行、建议加确认”的路径一致。缺陷分布等数据也可通过ONES Assistant生成分析，为口径调整和效果复盘提供依据。
常见问题
历史缺陷的旧标签和现行口径冲突，应该改标签还是保留原样？
建议修正后再入样本，而不是直接沿用旧标签。具体做法是：按现行规则表逐条核对，能明确归属的直接改正；一时无法判断的标记为待定并单独存放，不进入训练集和评估集。修正过程要留下记录，写明原值、新值和判断依据，这份记录本身就是口径评审的输入。若冲突集中在某几个枚举值上，说明规则表本身还需要再讨论一轮，先改口径再改标签。
样本量不多时，能不能直接用大模型做缺陷分类？
可以，但要把定位放在建议值上。样本有限时，规则引擎能处理模块归属这类结构化判断，大模型提示适合处理缺陷类型和严重程度这类需要理解文本的维度，启动快、能处理长描述。需要注意的是大模型输出存在波动，应固定提示模板，并在评估集上记录基线表现，上线后按周抽样比对建议值与最终确认值。样本积累到一定规模、标签分布相对均衡后，再考虑引入文本分类模型。
提交人经常直接采纳AI建议不做核对，误分回流率偏高怎么办？
先看误分集中在哪些维度。若集中在严重程度和优先级，通常是判定依据写得不够具体，需要把“核心流程中断为致命”这类规则细化到可对照的现象描述。若集中在模块归属，检查功能树与责任团队的映射是否过期。流程上可以要求提交人在采纳建议时补充一句判断理由，模块负责人复核时重点看被直接采纳的记录。误分回流率本身反映的就是提交环节确认是否流于形式，把它纳入周度复盘比单纯强调“要认真核对”更有效。
分类口径调整后，之前已经确认的缺陷需要重新分类吗？
不需要全量重刷，但要区分两种情况。枚举值增删或判定依据调整时，用同一评估集重新跑一遍，对比变更前后的准确率和修改率，指标明显下降就先回退或补样本。历史缺陷保持原分类，在口径变更记录中注明生效时间，统计指标时按时间段分别取数，避免新旧口径混在一起比较。若变更影响的是分派和排期所依赖的字段，可以对未关闭的缺陷做一次定向复核，已关闭的缺陷保留原值即可。
缺陷分类服务接入后，怎么和现有的缺陷流转状态配合？
建议把分类确认放在缺陷创建到进入处理之间。提交人填写标题和描述后看到建议值，确认或修改后缺陷才进入待分派状态，这样模块负责人拿到的是已经过一轮确认的记录。ONES中缺陷作为工作项承载字段与状态流转，ONES Assistant可基于项目和工作项上下文执行创建缺陷、更新状态等操作，建议生成与确认动作可以落在同一条缺陷记录上，便于追溯。具体状态节点如何设置，需要结合团队现有的流转规则确定。
