AI生成的报告初稿往往语句通顺、结构完整，真正容易出问题的地方在事实、依据和披露环节。这张核查表用于报告对外发布前的复核，按“事实与数据—结论与建议—合规与披露—格式与发布”四段组织检查项，每项写明通过标准、责任人角色、证据材料和记录字段。数据来源不可追溯、关键结论无依据、敏感信息未处理、审批未留痕属于阻断项，任一项不通过都不得发布。
要点总览（TL;DR）
- 核查表按“事实与数据—结论与建议—合规与披露—格式与发布”四段组织，每项写成可判断通过与否的陈述句，并配套通过标准、责任人、证据和记录字段。
- 使用对象分撰写人、数据提供人、复核人、审批人四类角色，介入时点为AI初稿后、人工定稿前、对外发布前三个节点，自检与终审应由不同人员承担。
- 通过标准要可观察、可取证，判定结果限定为通过、不通过、不适用；不适用项需写明理由并留痕，不能默认视为通过。
- 记录字段分基础、检查、责任、证据四组，报告名称、版本号、核查日期、轮次、检查结果、检查人、复核人、证据位置为必填。
- 数据来源不可追溯、关键结论无依据、敏感信息未处理、审批未留痕属于阻断项，未通过不得发布，整改后重新核查并记录轮次。
谁在什么时点使用这张核查表
核查表服务于发布前复核，介入时点必须在发布动作之前。如果报告已经发出再补签核查记录，这张表就失去了拦截作用。使用前先明确四类角色和三个节点，再进入具体检查。
四类角色分别是：报告撰写人，负责初稿内容和自检；数据提供人，负责确认所提供数据的口径与数值；复核人，负责独立检查事实、结论和合规事项；发布审批人，负责最终放行。角色可以按团队规模合并，但自检与终审应由不同人员承担，合并情况需在记录中注明。
三个使用时点对应不同的核查深度：AI生成初稿后，撰写人做第一轮自检，重点处理明显的事实错误和缺失信息；人工定稿前，数据提供人确认数据、复核人检查结论与合规，这一轮是核查的主体；对外发布前，审批人核对阻断项是否全部通过、记录是否完整，然后放行。
| 角色 | AI初稿后 | 人工定稿前 | 对外发布前 |
|---|---|---|---|
| 报告撰写人 | 自检事实与数据、补齐来源标注 | 根据复核意见修改并记录整改 | 确认整改完成 |
| 数据提供人 | — | 确认数据口径、时间范围与数值 | — |
| 复核人 | — | 独立核查结论依据、合规披露、格式 | 复核整改结果 |
| 发布审批人 | — | — | 核对阻断项与记录，签字放行 |
核查表与发布流程的衔接方式是“先自检、再复核、最后审批留痕”。每一轮核查留下结果记录，整改后进入下一轮，轮次编号连续，避免出现无法对应版本的核查结论。
分阶段检查项清单
以下检查项按四个阶段排列，每项写成可判断完成与否的陈述句，编号供记录字段引用。检查时逐项给出“通过、不通过、不适用”三种结果之一。
第一阶段：事实与数据核查（F系列）
- F1 报告中每个关键数字都标注了来源系统、文件或调研记录。
- F2 数据口径（统计范围、计算方法、单位）在正文或注释中写明。
- F3 数据时间范围明确，且与报告声称的统计周期一致。
- F4 正文数字与图表、附表数值一致，抽查样本无差异。
- F5 引用的外部资料标注了出处，且内容与原文含义一致。
- F6 AI生成内容中涉及事实的表述已逐条核对，无凭空补全的信息。
第二阶段：结论与建议核查（C系列）
- C1 每条关键结论在正文中有对应段落、数据或引用支撑。
- C2 结论的适用范围和前提条件已写明，未超出数据覆盖范围。
- C3 建议部分写明了执行动作、责任方和预期结果，可直接落地。
- C4 报告覆盖了任务要求的关键事项，无整段遗漏。
- C5 结论之间无相互矛盾，与前版报告的重大差异已说明原因。
第三阶段：合规与披露核查（P系列）
- P1 报告中的个人信息、客户名称、合同金额等敏感信息已脱敏或取得授权。
- P2 引用第三方图表、数据、图片已确认授权范围，标注方式符合要求。
- P3 按组织要求写明了AI参与生成的范围和环节。
- P4 对外口径与官方表述一致，无未经确认的承诺性表述。
- P5 报告密级和分发范围已标注，与接收对象匹配。
第四阶段：格式与发布核查（R系列）
- R1 报告版本号、日期与文件名一致，旧版本已归档。
- R2 附件、附表齐全，正文引用处与实际附件对应。
- R3 目录、页码、图表编号连续且正确。
- R4 分发名单和发布渠道已确认，与审批范围一致。
- R5 发布记录（时间、渠道、接收方）已登记。
每项检查的通过标准怎么写
通过标准决定检查项能否被真正判定。写法上要满足三点：可观察，检查人能看到具体对象；可取证，能留下截图、链接或文件；有明确判定结果，只能是“通过、不通过、不适用”。类似“数据准确”“结论合理”的表述无法判定，应改写为可核对的动作。
| 检查项 | 通过标准示例 | 判定方式 |
|---|---|---|
| F1 数据来源标注 | 每个关键数字旁标注到具体系统名称或文件名，抽查3处均能定位到源数据 | 逐项查看标注，抽查比对 |
| F4 数字与图表一致 | 抽取正文5个数字与对应图表、附表核对，数值完全一致 | 抽样核对，记录抽查位置 |
| C1 结论有依据 | 每条关键结论可指向正文至少一个段落或一组数据，指向位置写入记录 | 逐条标注对应位置 |
| C3 建议可执行 | 每条建议包含动作、责任方、时间或预期结果三项要素 | 按要素逐条检查 |
| P1 敏感信息处理 | 全文检索客户名称、人名、金额字段，命中项均已脱敏或附授权说明 | 检索加人工确认 |
| R1 版本一致 | 封面版本号、页脚、文件名三处一致，且与审批记录中的版本号相同 | 三处比对 |
“不适用”同样需要判定和记录。例如报告不含第三方图片时，P2可判为不适用，但要在记录中写明理由，由复核人确认。不适用项不能默认视为通过，也不能省略记录，否则后续回溯时无法区分“没查”和“不需要查”。
证据材料与责任人分工
每类检查项都要落到具体的人和可留存的证据上。分工的基本原则是自检、复核、审批分离：撰写人完成自检并提交证据，复核人独立核查并签字，审批人依据记录放行。同一人既自检又终审时，核查的独立性会下降，小团队确需合并角色的，应在记录中注明并由上一级管理者确认。
| 检查项类别 | 责任人 | 证据材料 |
|---|---|---|
| 事实与数据（F系列） | 撰写人自检，数据提供人确认 | 源数据截图或系统链接、数据口径说明、抽查记录 |
| 结论与建议（C系列） | 撰写人整理依据，复核人核查 | 结论与正文段落的对应清单、前版差异说明 |
| 合规与披露（P系列） | 复核人核查，必要时由法务或合规人员确认 | 脱敏前后对照、授权文件、AI参与说明 |
| 格式与发布（R系列） | 撰写人整理，审批人确认分发范围 | 版本记录、附件清单、分发名单、发布登记 |
证据要能定位到具体位置，截图注明页面和日期，链接确保复核人可访问，文件保留版本。证据缺失的检查项按不通过处理，不能以口头确认替代。
当核查表以文档形式在团队内流转时，可以把核查记录放在报告同一协作空间中，让撰写、复核、审批围绕同一份文档完成。ONES 支持基于权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计；ONES Assistant 可基于指定的 Wiki 页面组回答问题并附上引用来源，便于复核人核对结论依据。将核查结果与审批记录保存在 Wiki 页面或工作项中，发布时可直接调取对应版本的记录。
记录字段：核查表要留哪些信息
记录字段的设计目标是：任何一次发布都能回溯到谁在何时、依据什么、对哪一版报告做出了判断。字段分为基础、检查、责任、证据四组，其中标注为必填的字段缺失时，该轮核查视为未完成。
| 字段组 | 字段 | 必填/选填 | 说明 |
|---|---|---|---|
| 基础 | 报告名称 | 必填 | 与发布文件名一致 |
| 基础 | 版本号 | 必填 | 与封面、页脚一致 |
| 基础 | 核查日期 | 必填 | 本轮核查完成日期 |
| 基础 | 核查轮次 | 必填 | 整改后重新核查时递增 |
| 检查 | 检查项编号 | 必填 | 对应F/C/P/R系列编号 |
| 检查 | 检查结果 | 必填 | 通过/不通过/不适用 |
| 检查 | 问题描述 | 不通过时必填 | 写明具体问题和位置 |
| 检查 | 整改状态 | 不通过时必填 | 待整改/整改中/已完成 |
| 责任 | 检查人 | 必填 | 执行该项检查的人员 |
| 责任 | 复核人 | 必填 | 独立复核的人员 |
| 责任 | 审批人 | 发布前必填 | 最终放行人员 |
| 责任 | 完成时间 | 必填 | 各角色完成动作的时间 |
| 证据 | 证据位置或附件链接 | 必填 | 截图、文件或系统链接 |
| 证据 | 备注 | 选填 | 不适用理由、角色合并说明等 |
字段填写应逐项对应，不通过项必须同时有整改状态和证据位置，否则无法判断问题是否闭环。多轮核查时保留历史轮次记录，不覆盖上一轮结果。
阻断项与发布完成条件
阻断项是发布流程中的硬性停止条件，不通过即停止发布，不因进度压力降级处理。以下四类属于阻断项：数据来源不可追溯（F1不通过）；关键结论无正文依据（C1不通过）；敏感信息未处理或未取得授权（P1不通过）；发布审批未留痕（审批人未签字或记录缺失）。
阻断项的处理方式是整改后重新核查：撰写人完成修改，复核人针对该项重新判定，记录中新增轮次编号并保留上一轮的不通过记录。整改只针对问题项，但重新核查时需确认整改未影响其他已通过项。
发布完成条件有两条：全部阻断项判定为通过；非阻断项中的不通过项已登记问题描述和处理计划，并明确责任人与完成时间。满足这两条后，审批人核对记录完整性并签字，发布流程结束。发布后如需修改，按新版本重新走核查流程，不沿用旧版本的核查结论。
常见问题
小团队人手不足，撰写人同时担任复核人，核查表还能用吗？
可以用，但要在记录中注明角色合并情况，并由上一级管理者确认。核查表的基本原则是自检、复核、审批分离，同一人既自检又终审会降低核查的独立性。人手确实不足时，至少保证阻断项由第二人核查，例如数据来源和敏感信息处理这两类，其余非阻断项可由撰写人自检后由管理者抽查。合并角色的说明写入备注字段，便于后续回溯时判断该轮核查的可信度。
AI生成的报告内容在核查时，哪些地方需要重点抽查？
重点抽查三类位置：一是所有关键数字及其来源标注，确认能定位到具体系统或文件；二是涉及事实的表述，逐条核对是否存在凭空补全的信息；三是结论与正文的对应关系，确认每条关键结论都能指向具体段落或数据。AI生成内容语句通顺，问题往往藏在事实和依据层面，抽查时按F系列和C系列检查项逐项判定，抽查位置写入记录。
核查表判为“不适用”的检查项，发布时还需要审批人确认吗？
需要。不适用项要在记录中写明理由，由复核人确认，审批人放行时一并核对。不适用与通过是两种不同结果，省略记录会导致后续回溯时无法区分“没查”和“不需要查”。例如报告不含第三方图片时，P2可判为不适用，但理由和确认人必须留痕。
报告发布后发现问题需要修改，核查流程怎么走？
按新版本重新走核查流程，不沿用旧版本的核查结论。修改后的报告更新版本号，核查轮次重新计数，阻断项全部重新判定，非阻断项中受修改影响的部分重新核查。旧版本的核查记录保留归档，与新版本记录分开存放，避免版本与核查结论错配。
核查记录放在哪里，才能让复核人和审批人方便调取？
把核查记录与报告放在同一协作空间中，撰写、复核、审批围绕同一份文档完成，发布时直接调取对应版本的记录。ONES 支持基于权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计；ONES Assistant 可基于指定的 Wiki 页面组回答问题并附上引用来源，便于复核人核对结论依据。核查结果与审批记录保存在 Wiki 页面或工作项中，版本对应关系更清晰。
