AI人工复核机制的核心，是按AI输出的风险等级与置信度把结果分流：低风险且高置信的自动通过，中风险进入抽样复核，高风险或低置信的必须由指定角色逐条复核并留痕。本文给出一份可直接参照填写的示例方案，覆盖分级规则、复核角色、字段表、流转状态和一次完整走查，并说明如何迁移到缺陷分级、需求评审、代码审查等研发场景。文中情景为演示设定，非真实客户案例。
要点总览（TL;DR）
- AI人工复核机制按风险等级与置信度交叉分流：低风险高置信自动通过，中风险抽样复核，高风险或低置信强制逐条复核并留痕。
- 示例方案包含风险分级规则、分流矩阵、角色分工、复核记录字段表、状态流转和一次缺陷分级走查，可直接参照填写。
- 关键设计取舍：高风险不因置信度高而放行，高风险复核人必须具名指定，复核结论与修改说明分开记录。
- 迁移到需求评审、代码审查、测试用例生成时，替换风险维度与复核重点，分流矩阵结构和留痕要求保持不变。
- 适用前提是AI输出辅助判断、由人定责；对外发布、合规审批或触发不可逆动作的场景需重构复核流程。
示例要解决什么问题：复核机制的目标与判定口径
这份示例方案要控制三类典型风险。第一类是误判：AI把严重缺陷判成一般缺陷，或把高影响需求变更判成低影响，导致资源错配。第二类是越权输出：AI在未被授权的情况下生成对外内容、触发状态变更或给出超出使用范围的建议。第三类是责任不清：输出出了问题，找不到是谁确认的、依据是什么、改过哪里。
围绕这三类风险，示例设定三个治理目标：高风险输出零自动放行；每一次人工复核都能追溯到人、时间和结论；复核工作量控制在团队可承受的范围内，避免全量复核拖慢交付。三个目标之间存在张力，分级分流正是用来平衡它们的手段。
判断复核机制是否有效，可以用四个可观察指标。指标口径需结合团队实际设定，下表给出示例取值方式。
| 指标 | 定义 | 示例观察方式 |
|---|---|---|
| 复核覆盖率 | 实际进入人工复核的输出占应复核输出的比例 | 按周统计强制复核与抽样复核的实际执行数，对照规则应复核数 |
| 复核一致率 | 复核结论与AI原始建议一致的比例 | 一致率高说明AI在该场景可信度较好；过低需检查AI输出质量，过高需检查复核是否流于形式 |
| 复核耗时 | 从进入待复核到给出结论的平均时长 | 按风险等级分别统计，高风险应设更短的时限 |
| 升级率 | 复核后驳回升级到裁决人的比例 | 持续偏高说明分级规则或AI输出与业务判断偏差较大 |
这四个指标组合使用才有意义。只看覆盖率会诱导团队把复核做成走过场，只看耗时又会牺牲复核质量。示例建议按周观察、按月复盘，把指标变化与规则调整关联起来。
完整示例：一份AI输出分级复核方案
以下为一份已填写的示例方案，场景设定为某研发团队使用AI辅助缺陷严重程度分级。方案包含分级规则、分流矩阵、角色分工、记录字段、状态流转和一次完整走查，可直接参照填写到自己的场景中。
风险分级规则
示例按影响范围与可逆性两个维度划分三档风险。影响范围指输出错误会波及多少对象，可逆性指错误被发现后能否低成本纠正。
| 风险等级 | 影响范围 | 可逆性 | 示例情形 |
|---|---|---|---|
| 高 | 跨模块、跨团队或影响对外交付 | 纠正成本高，可能已产生连锁动作 | 核心链路缺陷定级、对外发布内容、涉及合规判断的输出 |
| 中 | 单模块内，影响本迭代排期 | 可在当轮内纠正 | 一般功能缺陷定级、需求优先级建议 |
| 低 | 局部、仅影响记录或展示 | 随时可改，无连锁影响 | 缺陷描述润色、标签补全、相似缺陷归并建议 |
置信度与风险交叉的分流矩阵
置信度只作为分流参考，与风险等级交叉决定处理方式。示例将置信度分为高（AI给出明确依据且历史一致率较好）、中（有依据但存在歧义）、低（依据不足或场景少见）三档。
| 风险等级 \ 置信度 | 高置信 | 中置信 | 低置信 |
|---|---|---|---|
| 高风险 | 强制逐条复核 | 强制逐条复核 | 强制逐条复核，并升级裁决人确认 |
| 中风险 | 抽样复核（示例比例20%） | 强制逐条复核 | 强制逐条复核 |
| 低风险 | 自动通过，留记录 | 抽样复核（示例比例10%） | 抽样复核（示例比例30%） |
矩阵中高风险行不因置信度高而放行，这是示例的硬约束。抽样比例是示例取值，团队可根据复核人力和历史一致率调整，但调整需记录在规则版本中。
角色分工
| 角色 | 职责 | 示例人选 |
|---|---|---|
| AI输出责任人 | 发起AI输出、确认场景与输入完整、对输出进入复核流程负责 | 提出分级建议的测试或开发人员 |
| 复核人 | 按规则逐条或抽样复核，给出结论与修改说明 | 模块负责人或资深测试 |
| 升级裁决人 | 处理驳回升级、规则争议和跨模块冲突 | 测试负责人或项目负责人 |
高风险输出的复核人必须具名指定，示例中按模块预先绑定到具体人员，避免出现无人认领或任意人顺手点通过的情况。
复核记录字段表
| 字段 | 填写要求 | 示例值 |
|---|---|---|
| 输出编号 | 唯一标识本次AI输出 | AI-2024-0317-014 |
| 场景 | AI输出所属业务场景 | 缺陷严重程度分级 |
| 风险等级 | 按分级规则填写 | 高 |
| 置信度 | AI给出的置信档位 | 中 |
| 复核结论 | 通过 / 修改后通过 / 驳回升级 | 修改后通过 |
| 修改说明 | 结论为修改或驳回时必填，说明改了什么、为什么 | AI建议“一般”，调整为“严重”，因该缺陷导致主流程不可用 |
| 复核人 | 具名填写 | 张×× |
| 时间 | 给出结论的时间 | 2024-03-17 15:40 |
流转状态
示例状态为：待复核 → 复核中 → 通过 / 修改后通过 / 驳回升级。驳回升级后进入裁决人处理，裁决结果回写记录并关闭。自动通过的输出同样保留记录，状态直接标记为通过并注明“自动通过”，便于事后抽查。
一次完整走查：缺陷严重程度分级
演示情景：测试人员提交一条缺陷，描述为“支付回调偶发失败，重试后仍失败”。AI读取缺陷描述与关联日志，给出建议“严重程度：一般，置信度：中”。
- AI输出责任人确认场景为缺陷分级，风险等级按规则判为高（涉及支付核心链路），提交复核。
- 系统按矩阵将高风险中置信输出置为强制逐条复核，指派给支付模块具名复核人。
- 复核人核对日志与影响面，认为主流程不可用，将严重程度改为“严重”，复核结论填“修改后通过”，修改说明写明依据。
- 记录回写缺陷工作项，状态流转为修改后通过，缺陷按“严重”进入修复排期。
- 周复盘时该条记录进入高风险样本抽查，用于校准AI在该场景的一致率。
在这个走查中，复核记录、状态流转和责任人分派需要落在团队日常使用的工作项与文档里。ONES Assistant 可连接 ONES Project、ONES Wiki 与 ONES TestCase，把自然语言指令转化为可追踪的工作，例如创建缺陷、更新状态并通知项目负责人；ONES 的 AI 研发管理方案说明其基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计。团队可以把复核结论和修改说明记录在对应工作项中，让复核动作与缺陷处理保持同一条链路。
逐项解释：每个设计选择为什么这样定
为什么用风险分级而不是全量复核。全量复核能最大化安全，但复核人力是有限资源，全量复核会让复核人疲劳，反而降低对高风险输出的注意力。示例把复核资源集中到高风险与低置信输出上，用抽样覆盖中低风险，是在复核成本与风险敞口之间取平衡。可改动点是分级维度和抽样比例，不可省的是高风险必须逐条复核这条底线。
为什么置信度只作分流参考、不单独决定放行。AI的置信度反映的是模型自身判断的确定性，与业务影响无关。一个高置信的错误判断同样可能造成严重后果。因此示例中置信度只影响中低风险的处理方式，高风险行不受置信度影响。可改动点是置信档位的划分方式，不可省的是高风险与置信度解耦。
为什么高风险必须指定具名复核人。任意人认领容易出现两种情况：一是无人认领导致积压，二是顺手通过导致复核失效。具名绑定把责任落到人，也便于统计个人复核耗时与一致率。可改动点是绑定粒度（按模块或按人轮值），不可省的是高风险输出必须有明确责任人。
为什么复核结论与修改说明分开记录。结论是分类结果，便于统计升级率和一致率；修改说明是判断依据，便于事后追溯和规则校准。两者合并会导致统计口径混乱，也会让复核人用一句“已改”代替说明。可改动点是说明的必填条件，不可省的是修改或驳回时必须留下依据。
驳回升级的触发条件与责任归属。示例设定三种触发：复核人与AI建议分歧且涉及高风险、复核人认为规则本身不适用、跨模块影响无法在模块内判断。触发后由升级裁决人处理，裁决结果回写原记录，责任归裁决人。可改动点是触发条件的细化，不可省的是升级路径必须有人兜底。
可迁移规律：换到其他研发场景怎么改
这套示例的通用结构是：定义风险维度 → 划分风险等级 → 与置信度交叉形成分流矩阵 → 指定角色 → 设计记录字段 → 定义状态流转。换场景时替换的是风险维度和复核重点，矩阵结构与留痕要求保持不变。
| 场景 | 风险维度替换为 | 复核重点 | 字段增减 |
|---|---|---|---|
| 缺陷分级 | 影响范围、可逆性 | 严重程度是否与影响面匹配 | 增加关联缺陷、影响模块 |
| 需求评审 | 需求变更影响面、关联系统数 | 变更是否遗漏关联系统、优先级是否合理 | 增加关联需求、影响系统清单 |
| 代码审查 | 改动范围、是否触及核心链路 | 核心链路改动是否有足够测试与回滚方案 | 增加变更文件数、核心链路标记 |
| 测试用例生成 | 覆盖缺口、用例可执行性 | 生成用例是否覆盖关键路径、步骤是否可执行 | 增加覆盖需求编号、可执行性判定 |
迁移时需同步调整三件事。角色方面，复核人从模块负责人换成对应场景的把关人，例如代码审查由核心链路的资深开发复核。字段方面，按上表增减，同时保留输出编号、风险等级、置信度、复核结论、修改说明、复核人、时间这七个基础字段。规则版本方面，每次调整分级维度或抽样比例都要记录版本，避免规则漂移后无法解释历史结论。
迁移中容易忽略的是置信度的可比性。不同场景下AI置信度的含义可能不同，示例建议每个场景单独观察一致率，不跨场景直接比较置信档位。
适用边界：这套示例在什么条件下需要调整
示例的适用前提是：AI输出用于辅助判断，最终由人定责；输出影响范围在团队内部，纠正成本可控；团队有明确的模块负责人可以承担复核角色。满足这些前提时，方案可按示例直接填写。
以下情形需要重构而非微调。AI输出直接对外发布，例如面向客户的公告或对外文档，此时复核不能只靠抽样，需要增加发布前审批环节。涉及合规审批的输出，例如涉及数据合规或资质判断，复核人需具备相应授权，分级规则要与合规流程对齐。AI输出直接触发不可逆动作，例如自动关闭缺陷或自动合并代码，应改为先产生建议、由人确认后再执行。
复核人力不足时，示例建议的降级做法是：优先保证高风险逐条复核，中风险抽样比例下调并记录下调原因，低风险改为事后抽查。降级期间需提高升级率与一致率的观察频率，一旦高风险复核出现积压，应暂停相关场景的AI自动分流，回到全量人工处理。降级是临时措施，需设定恢复条件。
这套示例处理的是AI使用环节的复核治理，与全平台权限体系、账号安全治理、模型训练与微调治理是不同层面的工作。权限体系决定谁能看到和触发AI能力，模型治理决定AI本身的质量，复核机制决定单次输出是否可放行。三者需要配合，但不应互相替代。示例落地后建议按周观察四个指标，按月复盘规则有效性，每季度检查一次分级维度是否仍匹配业务变化。
常见问题
复核人力不足时，这套分级复核方案应该先砍哪一部分？
优先保住高风险逐条复核这条底线，再调整中低风险的处理方式。示例给出的降级顺序是：中风险抽样比例下调并记录下调原因，低风险改为事后抽查，高风险仍逐条复核。降级期间提高升级率与一致率的观察频率；一旦高风险复核出现积压，暂停相关场景的AI自动分流，回到全量人工处理。降级属于临时措施，需要事先写明恢复条件，例如复核积压清零并稳定观察一段时间后恢复原比例。
AI置信度在不同场景下能直接比较吗？
不建议跨场景直接比较。置信度反映的是模型对自身判断的确定性，不同业务场景下它的含义和分布可能不同，同一个档位在缺陷分级和需求评审中对应的实际可靠程度未必一致。示例的做法是每个场景单独统计复核一致率，用一致率校准该场景的置信档位划分，再决定抽样比例。跨场景只比较复核结论层面的指标，例如升级率和复核耗时。
复核记录应该记在哪里，才能和后续处理连起来？
记录应落在承载该业务对象的工作项或文档上，让复核动作与后续处理保持同一条链路。以缺陷分级为例，复核结论、修改说明、复核人和时间回写到缺陷工作项，状态流转也在同一处体现，事后抽查和一致率统计可以直接从工作项数据里取。ONES Assistant 可连接 ONES Project、ONES Wiki 与 ONES TestCase，把自然语言指令转化为可追踪的工作，例如创建缺陷、更新状态并通知项目负责人；ONES 的 AI 研发管理方案说明其基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计。具体字段与状态如何配置，需结合团队实际使用方式核验。
自动通过的输出还需要留记录吗？
需要。自动通过的输出同样保留记录，状态标记为通过并注明“自动通过”，目的是支持事后抽查和规则校准。如果自动通过完全不留痕，一旦后续发现某类输出误判率上升，就无法回溯影响范围，也无法判断是分级规则过宽还是AI输出质量下降。留记录的成本很低，可以在记录中省略修改说明等仅复核环节才需要的字段。
规则调整后，历史复核结论还能解释得通吗？
取决于是否做了规则版本记录。每次调整分级维度、置信档位划分或抽样比例，都应记录版本和生效时间，历史记录按当时的规则版本解释。缺少版本记录时，同一风险等级在不同时期的含义会漂移，统计一致率和升级率时容易出现口径混乱。示例建议把规则版本作为复核记录之外的独立台账维护，复盘时对照版本变化看指标波动。
