建立AI人工复核机制，关键是把AI输出按风险分级，为每一级设定复核角色、触发条件、判定字段和留痕要求，再用抽检与偏差复盘让机制持续运转。本文按“定对象—定流程—定角色—跑示例—做运行—验收”的顺序，给出一套可直接落地的做法，适用于研发团队在引入AI辅助编码、文档生成、数据分析等场景时的治理需要。
要点总览（TL;DR）
- 复核范围按影响面与可逆性分级：代码合入、生产数据变更、对外发布、客户承诺等高风险动作强制复核，内部草稿类低风险输出可抽样复核或免复核并定期回检。
- 落地按五步走：登记AI场景与输出类型、设定强制/抽样/异常三类触发、指派具名复核人与回避规则、统一通过/修改/驳回判定并强制填理由、按最小字段集归档追溯。
- 复核人与AI使用者必须分离，高风险场景增加第二复核人；复核记录需能反查到具体输出、复核人、时点、判定与理由。
- 机制上线后用抽检、复核一致率与驳回率观察、偏差复盘会维持有效性，并定期调整复核级别与退出条件；ONES 的 AI 研发管理方案基于权限体系运行，输出过程可追踪、结果可审计，可承载复核记录与状态流转。
先定复核对象：哪些AI输出必须过人
复核范围不能一刀切。全部复核会拖慢交付，完全不复核则风险失控。可行的做法是按“影响面”和“可逆性”两个维度给AI输出分级，再据此确定复核强度。
影响面看输出会波及谁：只影响个人或小组内部，还是会影响外部客户、生产环境、对外发布内容。可逆性看错误能否低成本撤回：草稿、内部讨论材料容易撤回；代码合入、数据变更、对外承诺一旦发出，纠正成本高甚至不可逆。
| 风险等级 | 典型AI动作 | 影响面 | 可逆性 | 复核级别 |
|---|---|---|---|---|
| 高 | 代码合入、生产数据变更、对外发布内容、客户承诺与报价、安全相关配置 | 外部或生产环境 | 低，纠正成本高 | 强制复核，必要时二次复核 |
| 中 | 需求文档初稿、测试用例生成、内部技术方案、分析报告 | 团队或项目内部 | 中，可修改后重发 | 强制复核或按比例抽样复核 |
| 低 | 会议纪要整理、内部问答、草稿润色、知识检索结果 | 个人或小组 | 高，随时可撤回 | 抽样复核或免复核，定期回检 |
高风险动作的复核要求应写死：未经复核不得进入下一环节，例如代码不得合入主干、数据变更不得执行、对外内容不得发布。低风险动作可以免复核，但要设定免复核条件，比如输出仅用于内部参考、不进入任何交付物、不对外发送，并保留定期回检的安排，防止免复核范围被悄悄扩大。
分级结果要落到一张清单上，逐条写明AI动作、影响面、可逆性、复核级别和责任人。这张清单是后续流程、角色和验收的共同依据，新增AI场景时先入清单再上线。
核心步骤：从触发到归档的复核流程
复核流程要能回答五个问题：什么情况下触发复核、谁来复核、按什么标准判定、判定结果怎么记录、记录怎么追溯。下面五步按顺序执行，每步都有明确的输入、动作、输出和完成标志。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、登记场景与输出类型 | AI工具清单、业务动作清单 | 逐项登记AI在哪个环节使用、产出什么类型的输出、流向谁 | AI使用场景登记表 | 全部在用AI场景已登记，无遗漏 |
| 二、设定触发条件 | 风险分级清单 | 为每类输出指定强制复核、抽样复核或异常触发 | 触发规则表 | 每个场景都能对应到一种触发方式 |
| 三、明确复核人资质与回避 | 角色清单、人员资质记录 | 指定每类场景的复核人，写明资质要求和回避情形 | 复核人指派表 | 每个场景有具名复核人及备份人 |
| 四、定义判定与理由 | 复核检查项 | 统一通过、修改、驳回三类判定，规定每类必须填写理由 | 判定标准与理由模板 | 复核人能用同一套口径给出判定 |
| 五、归档与追溯 | 复核过程记录 | 按最小字段集归档，关联到具体输出与工作项 | 复核记录档案 | 任一输出可反查到复核人、时点与判定 |
触发条件分三类。强制复核对应高风险动作，每次都必须过人；抽样复核对应低风险批量输出，按设定比例抽取；异常触发用于AI置信度低、输入异常、结果与历史偏差较大的情况，即使属于低风险也要临时升级复核。三类触发要写在同一张规则表里，避免执行时各说各话。
判定统一为通过、修改、驳回三类。通过表示输出可直接使用；修改表示方向可用但需人工调整后使用；驳回表示输出不可用，需重新生成或人工重做。三类都必须填写理由，理由字段是后续抽检和偏差复盘的主要素材，不能留空或用“没问题”敷衍。
角色与交付物：谁复核、谁负责、留什么证据
复核机制失效最常见的原因是责任悬空：大家都以为别人在看。解决办法是把角色、职责和交付物一一对应，每个角色都知道自己交什么、交给谁。
| 角色 | 核心职责 | 交付物 |
|---|---|---|
| AI使用者 | 提交AI输出及输入上下文、自检说明，对提交内容的真实性负责 | 提交记录、自检说明 |
| 复核人 | 按检查项核对输出，给出判定与理由，异常时发起升级 | 复核记录、判定理由、升级单 |
| 场景负责人 | 对本场景的复核规则、复核人指派和结果质量负责 | 场景规则说明、复核人指派记录 |
| 治理归口角色 | 维护分级清单与触发规则，组织抽检和偏差复盘 | 分级清单、抽检报告、复盘结论 |
复核人与AI使用者必须分离，高风险场景建议增加第二复核人。复核人需具备对应业务资质，例如代码复核人应熟悉该模块，对外内容复核人应有权判断合规性。涉及复核人自身产出时应当回避，改由备份复核人处理。
复核记录的最小字段集建议包含：场景与输出标识、AI原始建议、输入上下文摘要、复核人、复核时点、判定结论、判定理由、升级记录。字段不必多，但每一项都要能支撑事后追溯：给定一条AI输出，能查到谁在什么时候、依据什么做出了什么判定。
在研发管理工具中承载这套记录会更顺畅。ONES 的 AI 研发管理方案基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计；复核记录、判定状态与抽检任务可以挂在工作项和文档上流转，与代码合入、需求评审等环节衔接，减少另建台账的负担。
示例：一次代码合入前的AI复核怎么走
以下为演示情景，用于说明机制如何运行，不涉及具体团队的真实数据。
场景：开发者使用AI生成一段接口校验代码，准备提交合入主干。该动作属于高风险，触发强制复核。
- AI使用者提交内容与自检说明：附上AI原始建议、需求背景、自检结论（如已本地运行、已核对接口字段），并在工作项中标记“待复核”。
- 复核人按检查项核对：检查逻辑正确性、边界条件处理、是否引入安全风险、是否符合团队编码规范、测试是否覆盖。
- 给出判定与理由：若发现问题但方向可用，判定为“修改”，理由写明具体问题和修改建议；若逻辑错误或存在安全隐患，判定为“驳回”，理由写明原因；若无问题，判定为“通过”。
- 异常升级：复核人无法判断或发现影响面超出预期时，提交升级单，由场景负责人或第二复核人二次复核，升级过程和结论一并记录。
- 归档与抽检：复核记录关联到该工作项，字段包括输出标识、复核人、时点、判定、理由。该记录进入后续抽检样本池，治理归口角色按周期回看判定质量。
这个示例的关键在于：复核不是口头确认，而是留下可查的记录；判定不是简单通过或打回，而是带理由的结构化结论；异常有明确的升级出口，不会卡在单个复核人手里。
让机制持续有效：抽检、偏差复盘与调整
机制上线只是开始。复核容易流于形式，表现为复核人快速点“通过”、理由栏空白、抽检从不执行。需要用运行规则把机制拉回正轨。
抽检对象的选择方法：高风险场景按固定周期全量回看或高比例抽检；低风险免复核场景按比例随机抽取；对判定为“通过”的记录重点抽检，因为漏判往往藏在这里。抽检比例结合组织风险偏好设定，风险越高比例越高。
观察口径建议用三个指标：复核一致率，即抽检结论与原复核判定一致的比例；驳回率，即判定为驳回的占比，过低可能意味着复核走过场；返工率，即复核后仍需重做或二次修改的比例。指标按周期统计，看趋势而非单次数值。
偏差复盘会的输入包括抽检发现的问题记录、驳回与升级案例、指标变化；输出包括规则调整建议、复核人培训需求、场景分级修订。复盘结论要落到具体动作和责任人，下次复盘时回看落实情况。
复核级别与触发条件需要定期调整：新增AI场景及时入清单；连续抽检无问题的低风险场景可维持或降低复核强度；出现漏判的高风险场景应提高复核级别或增加二次复核。同时设定退出条件，例如某场景停止使用AI或输出不再进入交付物时，从清单中移出并停止复核安排。
完成检查：机制是否可用的验收项
机制是否建立完成，可以用下面这份清单逐项核对。全部满足即可认为机制可用，未满足的项要明确补做责任人和时间。
| 验收项 | 核对要点 | 通过标准 |
|---|---|---|
| 分级清单覆盖度 | 是否覆盖全部在用AI场景 | 无未登记场景，每项有复核级别 |
| 记录可追溯 | 复核记录能否反查到具体输出与判定人 | 任取一条输出可查到复核人、时点、判定与理由 |
| 高风险强制复核 | 高风险场景是否全部强制复核 | 无绕过复核进入下一环节的通道 |
| 抽检与复盘安排 | 是否已排定周期与责任人 | 有明确的抽检比例、周期和复盘召集人 |
| 异常升级路径 | 升级出口是否明确 | 复核人无法判定时有指定升级对象和时限 |
| 角色与回避 | 复核人与使用者是否分离 | 每个场景有具名复核人、备份人及回避规则 |
验收通过后，机制进入常态运行。建议每季度回看一次分级清单和触发规则，结合抽检结果和业务变化做修订，让复核强度始终与真实风险匹配。
常见问题
团队规模小、复核人力有限，怎么在不拖慢交付的前提下落实复核？
优先保证高风险动作的强制复核，把复核资源集中在代码合入、生产数据变更、对外发布和客户承诺这几类不可逆或影响外部的输出上。中低风险场景可以先采用抽样复核，按固定周期抽取一定比例回看，而不是逐条过人。
复核人不必专职，可以由场景内熟悉该模块的成员兼任，但要指定备份人，避免复核人请假时流程卡住。抽检比例和周期属于组织自定参数，建议从较低比例起步，根据漏判情况再调整。
复核人判定“通过”但事后发现漏判，责任怎么界定，机制要怎么改？
责任界定看两点：复核人是否按检查项完成了核对并留下理由，以及该检查项是否覆盖了出问题的风险点。如果检查项本身缺失，属于规则设计问题，由场景负责人修订检查项；如果检查项存在但复核人未执行，属于执行问题，纳入培训和抽检重点。
机制层面的改法是：把这次漏判案例作为偏差复盘的输入，评估是否需要提高该场景的复核级别、增加二次复核，或把该风险点补进检查项。复盘结论要落到具体动作和责任人，下次复盘时回看落实情况。
低风险场景免复核后，怎么防止免复核范围被逐步扩大？
免复核要有明确条件，例如输出仅用于内部参考、不进入任何交付物、不对外发送，并把条件写进分级清单。清单之外的新增场景先登记再上线，不能由使用者自行判断是否免复核。
同时保留定期回检安排，对免复核场景按比例随机抽取，重点看输出是否仍然停留在内部参考用途。一旦发现输出进入交付物或对外发送，该场景应重新定级并恢复复核。
复核记录用什么承载比较合适，需要另建一套台账吗？
不必另建台账。复核记录的关键是能关联到具体输出和工作项，并支持事后反查。如果团队已经在用研发管理工具，可以把复核记录、判定状态和抽检任务挂在工作项和文档上流转，与代码合入、需求评审等环节衔接。
ONES 的 AI 研发管理方案基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，适合承载这类记录。具体字段和流转方式需结合团队现有工具配置确定。
机制运行一段时间后，什么情况下可以降低或取消某个场景的复核？
可以参考连续多个周期的抽检结果：该场景抽检未发现漏判、复核一致率稳定、驳回率处于合理区间，且业务用途没有变化，可以考虑降低复核强度，例如从强制复核改为抽样复核。
取消复核要更谨慎，通常适用于场景停止使用AI，或输出不再进入交付物、不再对外发送的情况，此时从分级清单中移出并停止复核安排。任何调整都应记录调整依据和生效时间，便于后续回看。
