AI人工复核机制要解决的是把“哪些AI产出必须由人确认、由谁确认、确认到什么程度、结果如何留痕”写成可执行规则。本文按分级、流程、角色、示例与验证五步展开，帮助团队先划出复核范围，再跑通一条可追溯的复核链路，并用指标判断它是否真的拦住了风险。
要点总览（TL;DR）
- 复核机制从分级表起步：按影响面（对外发布、代码合入、数据变更、内部参考）与可逆性交叉判定，得到抽检、单人确认、双人确认、负责人确认四个等级，把复核人力集中在难以撤回的产出上。
- 流程固定为触发、检查、放行与退回、记录回写四个环节，每个环节有明确输入、动作与输出物；超时提醒并转交备选复核人，不自动放行。
- 角色上区分提出方、复核人、领域负责人与治理归口，复核通过不转移产出正确性责任，提出方仍是第一责任人，并提出方不得复核自己的产出。
- 用代码合入前的AI生成变更示例演示分级、检查、退回与再复核的完整记录过程，同一结构可迁移到文档与数据分析类产出。
- 上线后用复核记录完整率、退回率、平均复核时长、被拦截问题数与漏检复盘验证效果，等级误判、积压或形式化签字出现时触发机制调整。
先定复核等级：哪些AI产出必须人工确认
复核机制从一张分级表起步。分级的目的在于把有限的复核人力放到影响大、难以撤回的产出上，低风险场景保持轻量，避免每一条AI输出都排队等签字。判定使用两个维度：影响面，即产出流向哪里、被谁使用；可逆性，即出错后能否低成本撤回或修正。
影响面可分为四类：对外发布（面向客户、公众的内容与声明）、代码合入（进入主干或生产环境的变更）、数据变更（写入业务库、报表口径或对外数据）、内部参考（供团队内部阅读的分析、草稿与建议）。可逆性分为易撤回、需返工、难以撤回三档。两个维度交叉，得到四个复核等级。
| 复核等级 | 判定条件 | 复核强度 | 复核角色 |
|---|---|---|---|
| L1 常规 | 内部参考类产出，易撤回，错误影响限于个人或小组 | 仅抽检，按周或按月抽取样本 | 产出使用者或小组内指定抽检人 |
| L2 单人确认 | 内部参考但影响面较广，或数据变更中可返工的部分 | 单人确认后放行 | 同领域有经验的成员 |
| L3 双人确认 | 代码合入、对外数据变更，出错需返工但可撤回 | 两名复核人独立确认，意见一致才放行 | 一名同领域成员加一名跨领域成员 |
| L4 负责人确认 | 对外发布、生产环境数据变更、难以撤回的变更 | 领域负责人确认，必要时附例外审批 | 领域负责人，涉及合规时增加治理归口 |
分级表建议固定以下字段，便于逐条填写和后续统计：产出类型、影响面、可逆性、复核等级、复核角色、判定理由。产出类型写具体对象，例如“对外产品公告”“核心服务代码变更”“客户数据报表口径调整”，避免使用“文档”“代码”这类过宽的类别。
同时要明确不进入复核的低风险场景，例如个人用于梳理思路的会议纪要草稿、仅供自己参考的检索摘要、未对外分享的头脑风暴清单。把这些场景写进分级表的排除项，并注明一旦产出被转发到更大范围或用于对外材料，就重新按影响面判定等级。排除项需要定期回看，防止有人借“内部参考”绕过复核。
复核流程怎么跑：触发、检查、放行与退回
分级确定后，流程要回答四个环节的输入、动作与输出：产出如何进入待复核状态、复核人核对什么、结论如何判定、记录如何回写。每个环节都应有明确的完成标志，否则复核容易停在“看过了”这一步。
触发：让产出进入待复核状态
触发条件与分级表绑定。L2及以上产出在提交使用、合入或发布前，必须进入待复核状态；L1产出按抽样计划定期抽取。入口可以统一为一个待复核队列，产出提交人填写产出标识、等级、影响范围与自检结论，提交动作即完成触发。触发环节的输出是一条带状态标记的待复核记录，未完成复核的产出不得进入下一环节。
检查：复核人核对的具体项
检查项按产出类型配置，通用项包括四类：事实依据是否成立，关键结论能否找到支撑材料；引用来源是否可追溯，数据与引文是否对应原始出处；边界条件是否写清，适用范围、前提与例外是否交代；敏感信息是否处理，是否包含不应外泄的客户信息、密钥或个人数据。代码类产出还需检查变更范围是否与描述一致、是否附带测试或验证说明。检查项以清单形式附在复核记录中，逐项勾选并写明结论。
放行与退回：三种判定与记录
复核结论分为三种。通过：检查项全部满足，记录复核人与时间后放行。有条件通过：主体可用，但存在需限期修正的问题，记录修正项、责任人与截止时间，修正完成后由原复核人确认关闭。退回重做：存在事实错误、来源缺失或敏感信息等问题，记录退回原因与需补充的材料，产出回到提交人处修改后重新触发复核。三种结论都要写入复核记录，退回原因使用统一分类，便于后续统计哪类问题最常出现。
记录回写与超时处理
复核意见要回写到产出物本身或其关联记录上，形成“产出—复核—结论”的可追溯链路。回写内容包括产出标识、复核等级、复核人、检查项结论、退回原因、处理结果与时间。超时规则需提前约定：待复核超过约定时限时，系统或流程负责人提醒复核人；连续超时则转交备选复核人，代复核人需具备同等资质，并在记录中注明代复核原因。超时不应自动放行，否则复核形同虚设。
当复核流程需要与研发日常工作项打通时，可以把待复核产出登记为工作项，用状态流转承载“待复核—复核中—有条件通过—已退回—已放行”，复核意见作为记录附在工作项上。ONES 的 AI 研发管理方案说明其基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计；ONES Assistant 可将自然语言指令转化为可追踪的工作，并把结果保存为工作项、Wiki 页面等内容。团队可据此把复核记录与产出放在同一处管理，具体节点配置需结合现有流程确认。
角色与交付物：谁复核、谁负责、留下什么
复核机制常见的失效方式是责任悬空：产出有人生成，却没人对“确认过”负责。角色划分要把提出、复核、批准与治理监督分开，并让每个角色都有明确的交付物。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 提出方 | 生成或整理AI产出，完成自检，提交复核并响应退回意见 | 产出说明、自检结论、修改记录 |
| 复核人 | 按检查项核对事实、来源、边界与敏感信息，给出结论 | 复核记录、退回原因、修正项清单 |
| 领域负责人 | 对L4产出做最终确认，裁定争议与例外 | 确认意见、例外审批单 |
| 治理归口 | 维护分级表与检查项，统计复核指标，组织漏检复盘 | 分级表版本、指标报表、复盘结论 |
复核人与产出使用者的责任需要区分。复核人对“检查项是否核对、结论是否有依据”负责；使用者对“是否在授权范围内使用、是否按复核结论执行”负责。复核通过不转移产出本身的正确性责任，提出方仍是产出质量的第一责任人。这一条要写进机制说明，避免复核成为责任转移的通道。
复核人资质按等级设定：L2复核人需熟悉该领域并有近期同类产出经验；L3、L4复核人需具备相应领域负责人授权。回避规则同样要写明：提出方不得复核自己的产出；与产出存在直接利益关联的人员应回避，改由备选复核人处理。例外审批单用于记录偏离分级或流程的情况，包含例外事由、影响评估、批准人与有效期，例外不应长期化。
复核记录的保留期限与查阅方式需结合组织合规要求确定，并在机制中写明：哪些角色可查阅全量记录、哪些角色仅可查阅与本团队相关的记录、记录到期后的归档方式。查阅权限与产出本身的访问权限保持一致，避免复核记录成为新的信息泄露点。
一个完整示例：代码合入前的AI生成变更复核
以下为演示情景，用于说明分级、流程与角色如何串起来，不代表真实项目数据。
场景设定：某研发小组使用AI辅助生成一段订单状态同步的代码变更，准备合入主干。提出方在提交时填写产出说明：变更涉及订单服务与消息队列的交互逻辑，影响面为代码合入，可逆性为需返工但可回滚。
按分级表判定：代码合入且可回滚，对应L3双人确认。判定理由记录为“进入主干、影响订单主流程、回滚需重新发布”。复核角色为一名订单领域成员和一名消息中间件领域成员。
复核人按检查项核对，发现两个典型问题：变更说明称“仅调整重试次数”，实际改动还包含消息幂等键的生成逻辑，变更范围与描述不一致；新增逻辑缺少对重复消费的处理说明，边界条件未交代。两名复核人结论一致，判定为退回重做，退回原因归类为“变更范围不符”和“边界条件缺失”。
提出方补充幂等处理说明，拆分变更范围并更新描述，重新提交复核。第二次复核中，领域成员确认逻辑与描述一致，中间件成员确认重复消费场景已有覆盖，结论为有条件通过：要求补充一条针对重复消费的验证记录，限期两个工作日内完成。验证记录补充后，原复核人确认关闭，工作项状态更新为已放行，全过程记录保留在工作项上。
该示例可迁移到其他产出类型。文档类产出把“变更范围”换成“结论与引用是否对应”，数据分析类产出把“幂等处理”换成“口径定义与样本范围”，分级判定、检查清单、退回分类与记录回写的结构保持不变。
机制上线后的完成检查与效果验证
机制是否生效，要看它是否稳定运行并拦住问题，签字数量本身说明不了这一点。上线前后可按以下清单逐项核对。
| 阶段 | 检查项 | 通过标准 |
|---|---|---|
| 上线前 | 分级表覆盖度 | 团队主要AI产出类型均已映射到等级，排除项有明确边界 |
| 上线前 | 角色到位 | 各等级复核人已指定，备选人与回避规则已公布 |
| 上线前 | 记录模板可用 | 复核记录字段完整，退回原因分类可直接选用 |
| 运行中 | 复核记录完整率 | 应复核产出均有对应记录，缺失项可定位到具体产出 |
| 运行中 | 退回率与平均复核时长 | 按等级分别统计，异常波动可解释 |
| 效果验证 | 被拦截问题数 | 退回与有条件通过记录中可归类出实际拦截的问题 |
| 效果验证 | 漏检案例复盘 | 事后发现的问题回溯到复核环节，形成改进项 |
指标要按等级分开看。L4产出退回率过低，可能说明复核流于形式；L2产出复核时长持续偏长，可能说明复核人负载过重或分级过严。被拦截问题数需要结合问题严重程度判断，只统计数量容易忽略高风险拦截的价值。漏检案例是验证机制的关键输入：每起事后发现的问题都应回答“当时是否进入复核、检查项是否覆盖、为何未拦住”，并把结论回写到检查项或分级表中。
以下情况应触发机制调整：同一产出类型反复出现等级误判，说明分级条件需要细化；待复核队列持续积压，说明复核人力或等级划分需要重新平衡；复核记录出现大量无具体结论的勾选，说明检查项或复核人资质需要复核；例外审批频繁出现，说明常规流程存在不适用的环节。调整应留下版本记录，注明修改原因与生效时间。
复核机制与AI使用治理的其他环节有明确边界：分级与复核解决“产出使用前的确认”，权限体系解决“谁可以调用哪些数据和工具”，模型侧准确率优化解决“产出本身的质量上限”，事后审计解决“已放行产出的追溯”。复核记录可以作为审计输入，但不应替代权限配置与审计制度。把这几条边界写进机制说明，能避免复核被当成治理的全部。
常见问题
团队刚开始建复核机制，分级表应该先覆盖哪些产出？
建议先覆盖当前AI使用最集中、出错代价最高的两三类产出，例如对外发布材料、进入主干的代码变更和写入业务库的数据变更，把这几类的等级、复核角色和检查项先定下来。内部参考类产出可以先纳入抽检范围，等分级表运行一段时间、排除项边界清晰后，再逐步补齐其他产出类型。一次性铺满所有产出类型，容易让复核人不足的问题提前暴露，机制反而难以维持。
复核人长期不足、待复核队列积压时，应该放宽等级还是增加人手？
先看积压集中在哪个等级。如果集中在L2、L3，优先检查分级是否过严，把影响面小、可逆性高的产出下调等级或改为抽检；如果集中在L4，说明该等级的产出量本身超出负责人可承载范围，需要指定具备同等资质的备选负责人，或把部分L4产出拆分为可分批放行的子项。放宽等级要有依据，记录调整原因和生效时间，避免为了清空队列而把高风险产出降级处理。
复核记录需要保存多久，谁可以查阅？
保留期限和查阅范围要结合组织合规要求确定，并在机制说明中写清。一般原则是：复核记录的查阅权限与产出本身的访问权限保持一致，涉及客户数据或敏感信息的产出，记录只对参与复核和处理的人员开放；治理归口可查阅全量记录用于统计与复盘。到期后的归档方式也要提前约定，避免记录散落在个人手里。这部分属于组织制度设计，具体期限需由合规或法务确认。
复核通过之后产出又出了问题，责任怎么算？
复核人对检查项是否核对、结论是否有依据负责；提出方对产出本身的正确性负责，复核通过不转移这一责任。如果事后发现的问题落在检查项覆盖范围内而复核人未拦住，属于复核执行问题，应进入漏检复盘；如果问题超出检查项范围，说明检查项需要补充，属于机制改进项。把这两种情况分开处理，复盘才能落到具体动作上，而不是笼统追究签字人。
复核流程能不能直接放在现有的工作项管理工具里跑？
可以。把待复核产出登记为工作项，用状态流转承载“待复核—复核中—有条件通过—已退回—已放行”，复核意见作为记录附在工作项上，产出与复核结论就放在同一处，追溯时不必跨系统查找。ONES 的 AI 研发管理方案说明其基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计；ONES Assistant 可将自然语言指令转化为可追踪的工作，并把结果保存为工作项、Wiki 页面等内容。具体状态节点和字段配置需结合团队现有流程确认。
