制定AI用例审核规则，核心是把“谁来审、审什么、按什么标准判、审完留下什么”固化成可执行的分级机制。规则应覆盖用例来源标记、风险分级、必填字段、检查项清单、角色职责与记录留存，并以抽检和缺陷回溯验证有效性。本文适用于测试负责人或质量管理者建立审核机制，范围限于用例审核环节，不涉及测试脚本执行与模型训练。
要点总览（TL;DR）
- AI用例审核规则的核心是分级机制：按用例来源、业务影响范围、是否涉及资金权限合规划分L1至L3，不同等级对应不同审核深度与审核人层级。
- 建规则按五步推进：盘点用例来源与缺陷分布、定义字段与检查项、设定通过/退回/升级三类判定与时限、确定记录留存位置、试运行抽检校准并发布版本。
- 字段表解决信息齐全性，检查项清单解决内容成立性；AI生成用例额外必查事实性错误、与现有用例重复、超出需求范围的臆造场景。
- 测试负责人判断用例质量与可执行性，业务方判断业务正确性，研发判断技术前提，升级评审由质量负责人裁定。
- 规则发布后用抽检漏判率与漏测缺陷回溯验证有效性，退回率异常时分别排查判定口径与审核执行情况，并按版本管理修订。
先定审核范围与分级：哪些AI用例必须审
审核规则的第一层判断是范围与等级。所有进入用例库的AI生成用例都应带来源标记，但审核深度按风险区分，避免对低风险用例投入与核心交易同等的人力。分级依据建议取三个维度：业务影响范围（是否涉及核心流程、对外接口）、覆盖模块（是否涉及资金、权限、合规相关功能）、以及用例来源与生成方式（AI整段生成、AI改写人工用例、人工编写仅用AI润色）。
分级结果直接决定审核深度与审核人层级。下表可作为团队起草规则时的判定模板，具体阈值按业务实际情况调整。
| 等级 | 判定条件 | 审核深度 | 审核责任人 |
|---|---|---|---|
| L1 高风险 | AI整段生成，且涉及资金、权限、合规或核心交易流程 | 逐项核对全部检查项，业务方确认需求覆盖，研发确认环境前提，双人复核 | 测试负责人 + 业务/需求方 + 研发 |
| L2 中风险 | AI生成或改写，覆盖一般业务功能，不涉及资金与权限 | 核对必填字段与核心检查项，测试负责人判定，业务方抽查确认 | 测试负责人，业务方按比例抽检 |
| L3 低风险 | AI仅用于措辞润色，或覆盖非核心、展示类功能 | 核对必填字段与重复用例，单人审核 | 用例作者自检 + 测试负责人快速确认 |
范围边界需要在规则中写明：本规则只管用例审核，不管测试脚本编写、自动化框架选型与模型训练效果评估。用例进入执行阶段后的失败分析与缺陷流转，按既有缺陷管理流程处理，审核规则只负责放行前的质量把关。
核心答案与操作步骤：从分级到放行的五步流程
把规则建起来可以按五步推进，每步都有明确输入、动作、输出与完成标志，避免规则停留在原则描述。
第一步：盘点用例来源与缺陷分布
输入是现有用例库和近几个版本的缺陷记录。动作是统计AI生成用例占比、这些用例关联的缺陷数量与类型，找出漏测集中出现的模块。输出是一份覆盖对象清单，标明哪些模块、哪些来源的用例纳入审核。完成标志是清单经测试负责人确认，且每个模块都有明确的纳入或暂不纳入理由。
第二步：定义审核字段与检查项清单
输入是第一步的覆盖对象清单和团队现有用例模板。动作是把必填字段、检查项、AI生成用例的额外检查整理成可勾选的清单，并写明每项的判定口径。输出是字段表与检查项清单（详见下一节）。完成标志是任意一名审核人拿清单即可独立完成一次审核，不需要口头补充解释。
第三步：设定判定结论与处理时限
输入是检查项清单。动作是定义通过、退回修改、升级评审三类结论的触发条件，并为每类设定处理时限与责任人。例如退回修改要求作者在两个工作日内修订并重新提交，升级评审要求业务方在一个工作日内给出意见。输出是判定规则说明。完成标志是三类结论都有可对照的触发条件，不存在“视情况而定”的模糊表述。
第四步：确定审核记录留存位置与追溯要求
输入是判定规则。动作是明确审核记录写在哪里、记录哪些字段、保留多久。记录至少包含用例编号、来源标记、需求关联、审核等级、审核人、审核时间、判定结论与退回原因。输出是记录模板与存放位置说明。完成标志是任取一条已放行用例，都能查到完整审核轨迹。
第五步：试运行与抽检校准
输入是前四步的全部产物。动作是选择一个迭代或一个模块试运行，期间由测试负责人对已放行用例做抽检，记录误判与漏判情况，据此调整检查项与分级阈值。输出是试运行报告和规则第一版。完成标志是抽检结果达到约定标准，规则以版本号形式发布。
审核字段与检查项清单怎么设计
字段与检查项决定审核动作能否逐项勾选。字段解决“这条用例信息是否齐全”，检查项解决“这条用例内容是否成立”，两者分开设计，判定时先查字段再查内容。
| 类别 | 项目 | 必填/选填 | 判定口径 |
|---|---|---|---|
| 字段 | 用例编号 | 必填 | 全局唯一，与用例库编号一致 |
| 字段 | 来源标记 | 必填 | 标明AI生成、AI改写或人工编写，注明使用的生成方式 |
| 字段 | 需求关联 | 必填 | 关联到具体需求条目，无关联需说明原因 |
| 字段 | 前置条件 | 必填 | 环境、账号、数据状态可被他人复现 |
| 字段 | 预期结果 | 必填 | 可观察、可判定，避免“正常显示”这类描述 |
| 字段 | 优先级 | 必填 | 与需求优先级和风险等级一致 |
| 字段 | 测试数据说明 | 选填 | 涉及边界值或特殊数据时填写 |
检查项清单建议覆盖以下内容，每项给出通过与否的判定标准：
- 需求覆盖完整性：用例步骤能对应到需求条目中的每条验收点，缺失的验收点需说明由哪条用例覆盖。
- 步骤可执行性：每一步都有明确操作对象和操作动作，不含“进行相关配置”这类无法执行的表述。
- 预期结果可判定性：结果能被观察或查询验证，涉及数值、状态、提示文案的写明具体内容。
- 数据与边界条件：涉及输入范围的用例覆盖有效值、无效值与边界值，数据来源可获取。
- 重复用例识别：与现有用例比对，步骤与预期结果高度重合的合并或标注引用。
AI生成用例还需额外核对三项：事实性错误，如引用了不存在的接口、字段或页面；与现有用例重复，AI容易在相似需求下产出近似用例；超出需求范围的臆造场景，即用例描述了需求中并未要求的行为。这三项是AI生成内容最常见的质量问题，建议在清单中单独列出并标为必查。
角色分工与交付物：谁审、审到哪一步
审核链上每个角色承担不同判断，交接物明确才能避免责任悬空。下表给出角色、动作与交付物的对应关系，交接时点按审核等级确定。
| 角色 | 动作 | 交付物 | 交接时点 |
|---|---|---|---|
| 用例作者 | 提交前按字段表自检，补全来源标记、需求关联与预期结果 | 字段齐全的用例及自检记录 | 提交审核前 |
| 测试负责人 | 按检查项清单逐项核对，给出通过、退回或升级判定 | 审核记录与判定结论 | 收到用例后按等级时限完成 |
| 业务/需求方 | 确认需求覆盖完整性与业务规则正确性，重点看AI生成场景是否符合真实业务 | 业务确认意见 | L1用例必审，L2按比例抽检 |
| 研发 | 确认技术可行性与环境前提，识别用例中不存在的接口或字段 | 技术确认意见 | L1用例在放行前确认 |
分工的关键是让每个角色只对自己能判断的部分负责：测试负责人判断用例质量与可执行性，业务方判断业务正确性，研发判断技术前提。升级评审的触发条件建议写清楚，例如业务方与测试负责人意见不一致、或用例涉及合规要求时，提交到质量负责人裁定。
示例：一条AI生成用例的完整审核过程
以下为演示情景，用于说明规则如何运行。某电商系统新增优惠券叠加规则，测试人员用AI生成了一条用例：验证用户同时使用满减券与折扣券下单时，订单金额按最优组合计算。
分级结果：该用例由AI整段生成，涉及资金计算，判定为L1高风险，需测试负责人、业务方与研发三方审核。
逐项核对过程：字段检查发现来源标记与需求关联齐全，但预期结果写为“订单金额正确”，无法判定，记为不通过。检查项核对发现步骤中未说明两张券的领取状态与有效期，前置条件不完整；AI还额外生成了一个“优惠券可跨账号共享”的场景，而需求中并无此规则，属于臆造场景。需求覆盖方面，满减券与折扣券的叠加顺序有对应验收点，但用例未覆盖叠加后触发退款时的金额回退，业务方确认为覆盖缺口。
判定结论：退回修改。作者补充具体金额计算示例与券状态前置条件，删除臆造场景，增加退款回退步骤，两个工作日内重新提交。复审时测试负责人核对修改项，业务方确认业务规则，研发确认涉及的计价接口存在，判定通过并放行。
记录留存示例：用例编号 TC-2024-0871，来源标记为AI生成，关联需求 REQ-1132，审核等级 L1，审核人分别为测试负责人、业务方、研发，审核时间与判定结论逐条记录，退回原因写明“预期结果不可判定、前置条件缺失、存在臆造场景、退款场景未覆盖”。
审核记录、用例状态与需求关联需要在工具中承载，才能保证追溯不断链。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，可基于项目与工作项的真实上下文回答问题并执行后续操作；其AI能力基于ONES权限体系运行，输出过程可追踪、结果可审计。团队可以把审核结论、退回原因与需求关联记录在对应的用例与工作项上，使审核轨迹与需求、缺陷数据保持在同一处可查。
规则落地后的完成检查与迭代
规则发布不等于生效，需要用抽检和缺陷回溯验证它是否真的拦住了问题。
抽检方面，测试负责人按周期对已放行用例抽样复核，抽检比例按团队规模与缺陷密度设定，缺陷密度高的模块提高比例。抽检发现应拦未拦的问题，记为规则漏判；发现放行后被误退回的，记为误判。两类结果分别统计，作为调整检查项的依据。
缺陷回溯方面，定期把漏测缺陷与对应模块的已放行用例对照，判断缺陷是否本可被现有检查项发现。若多条漏测缺陷指向同一类检查缺失，说明检查项需要补充；若缺陷集中在AI生成用例的臆造场景上，说明额外检查的执行不到位，应排查审核人是否逐项勾选。
退回率异常也需要排查方向：退回率过高，先看检查项判定口径是否过严或表述模糊，再看作者自检是否流于形式；退回率过低，则要警惕审核走过场，可通过抽检结果交叉验证。
规则应有版本号，修订触发条件建议包括：抽检漏判率超过约定阈值、出现因用例缺失导致的线上问题、需求类型或业务范围发生明显变化、审核角色发生调整。每次修订记录变更内容与生效时间，旧版本归档备查。
规则验收可用以下清单逐项核对：
- 分级判定表已发布，每个等级都有判定条件、审核深度与责任人。
- 字段表与检查项清单可逐项勾选，判定口径无模糊表述。
- 通过、退回、升级三类结论均有触发条件与处理时限。
- 测试、业务、研发的职责与交接物已明确，升级路径可执行。
- 审核记录字段完整，任取一条用例可查到审核轨迹。
- 试运行抽检达到约定标准，规则已按版本发布。
- 抽检与缺陷回溯的周期、责任人、修订触发条件已写入规则。
常见问题
AI生成用例和人工用例的审核标准要分开吗？
建议共用一套字段表与基础检查项，再为AI生成用例增加额外必查项。基础检查项如需求覆盖完整性、步骤可执行性、预期结果可判定性，对两类用例同样适用；AI生成用例则要额外核对事实性错误、与现有用例重复、超出需求范围的臆造场景。分开设计的好处是审核人不用维护两套清单，同时AI生成内容的高发问题有专门拦截点。
团队规模小、审核人力有限时，分级可以简化吗？
可以简化等级数量，但不宜取消分级。人力有限时可将L1与L2合并为“需复核”，L3保留单人快速确认，关键是每个等级仍有明确的判定条件、审核深度与责任人。另一种做法是降低L2的抽检比例，把人力集中到涉及资金、权限、合规的用例上。抽检比例与修订周期按团队规模与缺陷密度设定，没有统一标准。
审核记录应该记在用例文档里还是单独建表？
两种方式都可以，判断标准是能否从一条已放行用例反查到完整审核轨迹。记录至少包含用例编号、来源标记、需求关联、审核等级、审核人、审核时间、判定结论与退回原因。若团队已在研发管理工具中管理用例与需求，把审核结论与退回原因记录在对应的用例与工作项上，可以让审核轨迹与需求、缺陷数据保持在同一处可查，减少跨文档核对成本。
试运行多久、抽检多少条才能判断规则有效？
建议以一个迭代或一个模块为试运行周期，抽检覆盖该周期内已放行的全部L1用例，L2与L3按比例抽样。判断有效的依据是抽检中应拦未拦的漏判情况是否在可接受范围，以及退回原因是否集中在少数几类可修正的问题上。若漏判集中在同一检查项，先调整该项判定口径再延长试运行，不必急于发布正式版本。
规则发布后业务方参与度下降怎么办？
先确认业务方的审核动作是否被写成了可执行的交接物，例如只需确认需求覆盖清单与业务规则正确性，而非通读全部用例。若交接物本身模糊，业务方容易以“没时间”退出。其次检查升级评审路径是否真的被使用过，长期不触发的路径往往说明规则设计脱离实际。必要时把业务确认设为L1用例放行的前置条件，使参与成为流程节点而非倡议。
