AI答案核验的依据需要覆盖四层：答案引用的原始知识来源、检索与生成环节的可追溯记录、答案与来源的一致性比对结果，以及人工复核的责任记录。本文按“定范围—取证据—逐条比对—定结论—留记录”的顺序，给出一套可执行的核验流程和记录表，适用于研发知识问答、内部规范查询等场景；RAG底层工程调优与模型训练不在本文范围内。核验记录与来源版本的留存，可以借助ONES的文档与工作项管理能力承载。
要点总览（TL;DR）
- AI答案核验的依据分四层：原始知识来源（文档、条目位置、版本与生效状态）、检索与生成记录（问题、召回片段、引用标注）、一致性比对结果（结论点逐条对照来源）、人工复核记录（复核人、时间、结论与遗留风险）。
- 核验对象先分级再取证：对外发布、合规相关、技术决策类答案优先核验；来源缺失、来源过期、多来源冲突的答案一律列为必检，其余按影响面抽检或免检。
- 判定口径统一为三档——有直接来源支撑、需推断才能得出、来源中找不到依据；后两档必须给出改写、补来源或删除的处置，并写入核验记录。
- 角色分工落到交付物：使用方提交核验申请，知识维护方确认来源版本，核验执行人填写核验记录表，发布责任人签字决定发布、改写或撤回。
- 核验完成的判断标准是记录表可复查：每个结论点有来源定位或明确标注无依据，版本状态已确认，判定与处置一一对应，复核人与时间可追溯，遗留风险有跟进人。
核验前先定范围：哪些AI答案必须核验
全量核验会迅速拖垮流程，抽样核验又容易漏掉高风险答案。可行的做法是先按影响面和来源可靠性两个维度分级，把核验资源集中到必须检查的答案上。
按影响面分级
- 高影响：对外发布、合规相关、技术决策类答案。例如对外材料中引用的产品能力说明、涉及数据安全与合规要求的答复、影响架构选型或发布判断的技术结论。这类答案一旦出错，纠正成本高，应逐条核验。
- 中影响：跨团队协作中作为依据流转的答案。例如被写入需求文档、测试方案或项目计划的问答结论。可对关键结论点核验，非关键描述做抽检。
- 低影响：个人查询、探索性提问。例如了解某个术语含义、查找文档位置。可依赖引用来源自行判断，不进入正式核验流程。
按来源可靠性分级
以下三类答案无论影响面高低，都应列为必检：答案未给出任何来源；来源文档已过期或版本状态不明；多个来源对同一问题表述冲突。来源可靠性问题会直接动摇答案的可信度，不能靠答案读起来通顺来抵消。
输出核验对象清单
完成分级后，形成一份核验对象清单，字段包括：答案标识或问题原文、使用场景、影响面等级、来源可靠性标记、是否必检、计划核验时间。清单本身要能回答“这次核验覆盖了哪些答案、为什么排除其余答案”。
核验依据的四个层次与取证方法
四层依据分别回答不同问题：来源层回答“依据出自哪里”，过程层回答“答案是怎么生成的”，比对层回答“答案与来源是否一致”，复核层回答“谁对结论负责”。四层齐全，核验才可复查。
| 层次 | 依据内容 | 取证来源 | 可用标准 | 缺失时处理 |
|---|---|---|---|---|
| 第一层：原始知识来源 | 文档标题、条目位置、版本号、生效或失效状态 | 知识库页面、文档管理系统、版本记录 | 能定位到具体段落，版本与生效状态明确 | 补证；无法补证则降级标注或不予发布 |
| 第二层：检索与生成记录 | 原始问题、召回的知识片段、答案中的引用标注 | 问答工具的回答记录、引用列表 | 能还原问题与召回片段，引用位置可对应 | 重新发起检索并留存记录；无法还原则标注过程不可追溯 |
| 第三层：一致性比对证据 | 关键结论逐条对照来源原文的比对结果 | 核验人比对后填写的判定表 | 每个结论点有明确判定：一致、部分一致、无依据 | 未比对不得进入发布环节 |
| 第四层：人工复核记录 | 复核人、复核时间、结论、遗留风险说明 | 核验记录表、评审记录 | 复核人可识别，结论与处置动作对应 | 无复核记录的答案视为未核验 |
第一层取证时，要记录到段落级位置，仅记录文档标题不足以支撑复查。第二层取证依赖问答工具是否保留回答记录与引用来源；以ONES Assistant为例，其支持基于指定的Wiki页面组回答问题并附上引用来源，核验时可据此回溯召回范围，引用呈现的具体形式以实际界面为准。第三层和第四层由核验人填写，属于人工产出，需要固定字段以便横向比较。
每层依据缺失时，处理方式分三档：能补齐的补证后继续；无法补齐但答案仍需使用的，在答案上做降级标注，说明依据不完整；涉及高影响场景且无法补证的，不予发布。
逐条核验的操作步骤与判定标准
取证完成后，核验的核心动作是把答案拆成可独立判断的结论点，再逐点比对。整段答案笼统判断“基本正确”，无法定位问题，也无法复查。
步骤一：拆解结论点
把答案拆成若干条可以单独判断真假的陈述。例如一条关于研发流程规范的答案，可拆为“某类变更需要几人评审”“评审记录保存在哪个环节”“例外情况如何审批”三个结论点。拆解粒度以“能否单独找到来源支撑”为准。
步骤二：匹配来源片段
为每个结论点找到对应来源片段，记录文档标题、段落位置、版本号。一个结论点对应多个来源时全部记录；找不到对应来源的，如实标注，不用相近内容替代。
步骤三：按统一口径判定
| 判定结果 | 含义 | 典型情形 |
|---|---|---|
| 有直接来源支撑 | 来源原文中有与结论点对应的明确表述 | 规范文档写明评审人数与审批路径 |
| 需推断才能得出 | 来源提供部分信息，结论需要组合或推理 | 来源分别写了评审要求和例外流程，答案将两者合并成一句结论 |
| 来源中找不到依据 | 检索范围内没有支撑该结论的表述 | 答案补充了来源未提及的操作细节 |
步骤四：处置问题结论点
“需推断”的结论点，要么改写为与来源表述一致的说法，要么补充能直接支撑的来源；“无依据”的结论点，优先删除，确有必要保留的须补充权威来源后再发布。处置动作要写进核验记录，与判定结果一一对应。
判定口径需要在团队内统一并形成书面说明，否则同一答案由不同人核验可能得出不同结论。统一口径至少明确三点：什么算“直接支撑”、推断到什么程度可接受、哪些来源具有权威性。
角色分工与交付物
核验责任悬空通常表现为“大家都看过，但没人对结论负责”。把角色、动作和交付物固定下来，每个环节都有明确的交接物。
| 角色 | 主要动作 | 交付物 | 交接时点 |
|---|---|---|---|
| 提问/使用方 | 说明问题背景与答案用途，界定影响面 | 核验申请，含使用场景与影响面等级 | 核验启动前 |
| 知识维护方 | 确认来源版本与生效状态，补充缺失来源 | 来源确认说明，含版本号与状态 | 取证阶段 |
| 核验执行人 | 拆解结论点、比对来源、填写判定 | 核验记录表 | 比对完成后提交审核 |
| 审核/发布责任人 | 复核结论，决定发布、改写或撤回 | 签字确认的核验结论 | 发布前 |
小团队中一人可兼任多个角色，但核验执行人与发布责任人建议分开，避免自己核验自己发布。核验记录表、来源版本信息和复核结论需要保存在可复查的载体上。ONES Assistant可将结果保存为工作项、Wiki页面等内容，团队可以把核验记录作为工作项流转、把来源确认写入Wiki页面，使结论、责任人和时间留存在同一处；具体字段与模板需按团队实际配置设计。
一个完整核验示例
以下为演示情景，用于说明四层依据如何落到一条答案上，不代表真实客户案例。
场景：某团队向AI问答工具提问“代码合并前需要哪些评审”，得到一条包含三个结论点的答案：合并请求需至少一名同模块成员评审；评审意见须在合并前关闭；紧急修复可跳过评审但需事后补录。
结论点拆解与来源定位
- 结论点1“至少一名同模块成员评审”：来源为《研发流程规范》第3.2节，版本v4，生效中。判定为有直接来源支撑。
- 结论点2“评审意见须在合并前关闭”：来源为同一规范第3.4节，版本v4。判定为有直接来源支撑。
- 结论点3“紧急修复可跳过评审但需事后补录”：来源中仅找到“紧急修复可简化评审”的表述，未提及“事后补录”。判定为需推断才能得出。
处置与记录
结论点3改写为“紧急修复可简化评审，具体审批要求以规范第3.5节为准”，并补充第3.5节作为来源；若补充后仍无直接依据，则删除该结论点。最终核验记录表填写为：答案标识、三个结论点、各自来源定位与版本、判定结果、处置动作、核验人、复核人、复核时间、遗留风险（规范第3.5节表述较笼统，建议知识维护方后续细化）。
完成检查：核验记录是否合格
核验结束前，用以下清单逐项确认。任何一项不满足，都说明核验尚未完成。
- 每个结论点都有来源定位，或明确标注“来源中找不到依据”并已处置。
- 所有来源的版本号与生效状态已确认，过期来源已替换或标注。
- 判定结果与处置动作一一对应，没有只判定不处置的条目。
- 复核人与复核时间可追溯，发布责任人的结论已签字。
- 遗留风险已书面记录，并指定跟进人和跟进时间。
这份清单同时可以作为核验记录表的验收标准：记录表能支撑上述五项检查，才算一次真正完成的核验，而不只是答案读起来通顺。
常见问题
AI答案读起来通顺、逻辑自洽，还需要逐条核验吗？
需要。通顺只说明表达连贯，不能证明结论有来源支撑。核验的对象是答案中的每个结论点，而不是整段文字的可读性。一条答案可能大部分表述正确，却在关键数字、审批人数或例外条件上偏离来源，这类偏差恰恰最容易被通顺的表述掩盖。
实际操作中，可按影响面决定核验深度：高影响答案逐条核验，中影响答案核验关键结论点，低影响的个人查询可依赖引用来源自行判断。
来源文档已过期，但答案内容与旧版一致，能否直接通过核验？
不能直接通过。来源过期意味着答案所依据的规则可能已经变化，内容一致只说明答案忠实于旧版，不说明它符合当前有效规范。处理方式有两种：一是由知识维护方确认新版文档中对应条款是否变化，补充新版来源后重新判定；二是无法取得新版来源时，在答案上做降级标注，说明依据版本已过期，并限制其在高影响场景中使用。
涉及合规或技术决策的答案，来源过期且无法补证的，不予发布。
多个来源对同一问题说法不一致时，核验以哪个为准？
先判断来源的权威性与时效性，再决定取舍，并把判断过程写进核验记录。通常优先级为：现行有效的正式规范高于历史版本，正式发布文档高于讨论记录或会议纪要，专项规定高于通用说明。若两个来源都现行有效且确实冲突，应视为知识本身存在问题，提交知识维护方裁定，而不是由核验人自行选择其一。
冲突未裁定前，答案中涉及该点的结论应标注为待确认，暂不进入对外发布或技术决策场景。
小团队人手有限，能否由同一人完成核验和发布？
可以兼任，但建议把核验执行与发布签字分开，至少做到记录上可区分。同一人既比对又签字时，容易把“我看过了”当成核验结论，缺少独立复核的约束。人手紧张时，可让另一名成员只做发布前的记录检查，确认每个结论点都有来源定位、判定与处置对应、遗留风险已记录，检查通过后再签字。
核验记录表、来源版本信息和复核结论需要保存在可复查的载体上。ONES Assistant 可将结果保存为工作项、Wiki 页面等内容，团队可以把核验记录作为工作项流转、把来源确认写入 Wiki 页面，使结论、责任人和时间留存在同一处；具体字段与模板需按团队实际配置设计。
核验记录表需要长期保存吗，保存哪些内容？
建议长期保存，尤其是高影响答案的核验记录。保存内容至少包括：答案标识或问题原文、拆解出的结论点、每个结论点的来源定位（文档标题、段落位置、版本号）、判定结果、处置动作、核验人与复核人、复核时间、遗留风险及跟进人。
保留这些内容的价值在于可复查：当来源更新、答案被再次引用或出现争议时，能快速定位当时的判断依据和责任人。记录可存放在文档页面或工作项中，与来源文档的版本信息放在同一处便于对照。
