AI参与生成的文档，问题往往藏在“读起来很顺”的表面之下：数字与源数据对不上、参考文献并不存在、引用的制度已经过期、客户名称忘了脱敏，这些遗漏在通读时很难被发现。这份清单按内容准确性、来源与引用、时效与版本、合规与权限、表达一致性、发布与回执六个阶段组织，每项给出通过标准、所需证据和责任人，并单独列出必须修复才能发布的阻断项。评审与发布留痕可以借助ONES这类协作平台承载，具体检查动作仍由人来完成。
要点总览（TL;DR）
- AI文档发布检查最容易漏掉的是“读起来通顺但经不起核对”的问题：关键数字与源数据口径不一致、AI补写的推断被当成事实、参考文献实际不存在。
- 引用核验以“每条引用能点开、打开内容与正文一致”为通过标准；AI生成的文献条目需按标题和作者逐条确认存在。
- 时效与版本要同时看数据截止日期和文档自身版本号，发布前确认接收方拿到的是最新版本。
- 客户信息、个人信息、合同金额未脱敏，内部代号与未公开计划外泄，对外发布缺少审批，是造成实际损失的主要遗漏。
- 事实性错误、敏感信息外泄、无审批对外发布、引用造假四类为阻断项，全部关闭并由作者、复核人、发布责任人留痕确认后方可发布。
谁在什么时点做这份检查
这份清单适用于AI参与生成的各类工作文档，包括需求文档、会议纪要、周报、项目报告、对外说明材料等。它检查的是“文档产出质量”，不负责判断需求本身是否合理、项目风险是否需要上报，那类判断应在文档成稿之前由相应评审完成。
检查由三类角色分工承担。文档作者负责逐项自查并准备证据；领域复核人由熟悉业务或数据来源的同事担任，核对数字、结论与引用；发布责任人确认阻断项全部关闭，并对发布范围与渠道负责。小团队中一人可兼多个角色，但复核人与作者应尽量分开，避免自己核对自己。
检查发生在三个时点：AI初稿完成后做第一轮自查，重点清理推断性表述和可疑引用；定稿评审前做第二轮核对，补齐数字、版本与权限证据；正式发布前做最终确认，只核对阻断项状态和发布信息。三个时点各有侧重，不建议合并为一次通读。
| 时点 | 主要执行人 | 本轮重点 | 产出 |
|---|---|---|---|
| AI初稿完成后 | 文档作者 | 标注AI补写内容、清理明显失实表述、初筛引用 | 自查记录、待核问题清单 |
| 定稿评审前 | 作者＋领域复核人 | 数字与源数据核对、引用逐条打开、版本与时效确认 | 复核记录、证据附件 |
| 正式发布前 | 发布责任人 | 阻断项关闭确认、脱敏与审批记录、发布渠道与受众 | 发布确认与回执 |
内容准确性：数字、事实与结论逐项核对
内容准确性是最容易“看起来没问题”的一类遗漏。AI擅长把不完整的输入补成通顺的句子，补出来的部分读起来自然，却可能没有事实依据。检查时要把“文中出现的每个关键数字和事实”当作待验证项，而不是当作已确认信息。
关键数字包括金额、数量、比例、日期、周期、性能指标等，需逐一与源数据表、系统记录或原始凭证比对，确认口径一致——统计范围、时间区间、单位是否相同。AI补写的推断性表述，如“预计将提升约三成”“业内普遍认为”，应逐句判断：有来源的补上来源，无来源的删除或改为明确的待确认标记。结论部分要回看正文证据，确认每条结论都能在正文找到对应支撑，避免出现正文没提、结论却下了判断的情况。人名、项目名、产品名需与官方名称或通讯录核对，防止AI生成近似但不准确的名称。
| 检查项 | 通过标准 | 所需证据 | 负责人 |
|---|---|---|---|
| 关键数字与源数据一致 | 每个数字可指回源表或系统记录，口径、单位、时间区间一致 | 源表链接或截图、比对记录 | 领域复核人 |
| 推断性表述已处理 | 无来源的推断已删除或标注为待确认，有来源的已注明出处 | 修改前后对照或批注 | 文档作者 |
| 结论与正文证据对应 | 每条结论在正文有对应段落或数据支撑 | 结论—证据对照说明 | 领域复核人 |
| 人名、项目名、产品名准确 | 与通讯录、项目台账或官方名称一致 | 核对记录 | 文档作者 |
来源与引用：出处能不能被追溯
AI生成的参考文献、数据来源和链接是高风险区，可能出现格式规范但实际不存在的条目。检查标准只有一条：每条引用都能点开，打开后的内容与正文表述一致。做不到这一点的引用，要么替换为可核实的来源，要么删除。
具体核对包括：外部链接是否可正常打开、指向页面是否仍为正文引用的那份内容；AI列出的文献、报告、统计数据是否真实存在，作者、标题、年份是否对得上；转述他人观点时是否标明来源，避免把别人的判断写成自己的结论；引用内部资料时，确认引用对象存在且当前读者有访问权限，避免正文引用了接收方打不开的文档。引用核验建议由作者先自查一遍，复核人抽查关键引用。
- 逐条打开链接，记录打开结果与核对结论。
- 对无法打开的引用，替换来源或删除相关表述。
- 对AI生成的文献条目，按标题和作者检索确认存在。
- 内部资料引用注明文档名称与位置，并确认权限范围。
时效与版本：别把过期内容发出去
AI的训练数据和检索材料都可能滞后，文档里引用的制度、流程、价格、产品版本号未必是当前有效版本。检查时要区分两类时间：数据本身的时间口径，以及文档自身的版本状态。
数据截止日期应在文中明确标出，尤其是报告类文档，读者需要知道数字统计到哪一天。引用的制度、流程、报价、版本号需与当前生效版本比对，确认没有被新版本替代；如果引用的是历史版本，要说明引用原因。文档自身的版本号与修订记录应完整，能看出这一版改了什么。发布前确认接收方拿到的是最新版本，避免旧版附件随邮件一起发出。
| 检查项 | 通过标准 | 所需证据 | 负责人 |
|---|---|---|---|
| 数据截止日期已标明 | 文中明确写出统计截止时间 | 文档相应段落 | 文档作者 |
| 引用制度与版本为当前有效 | 与现行版本比对一致，或已说明引用历史版本的原因 | 版本比对记录 | 领域复核人 |
| 文档版本号与修订记录完整 | 版本号连续，修订记录可看出本次变更 | 修订记录页 | 文档作者 |
| 接收方获得最新版本 | 发布附件与归档版本一致 | 发布记录中的版本号 | 发布责任人 |
合规、权限与敏感信息清理
这是最容易造成实际损失的一类遗漏。AI在整理材料时可能把客户名称、联系人、合同金额、内部代号原样带入正文，作者通读时因为“本来就知道”而忽略。检查要按字段类型逐类排查，而不是凭印象判断。
客户信息、个人信息、合同金额、联系方式等敏感字段，对外发布前应脱敏或替换为示例数据，并保留脱敏记录。内部代号、未公开的产品计划、尚未公布的组织调整，需判断是否属于可公开范围，不确定的按不公开处理。发布范围要与文档密级匹配：内部文档发到外部群、公开材料带出内部链接，都是常见事故。对外发布需确认已完成必要审批，审批记录可查。
| 检查项 | 通过标准 | 所需证据 | 负责人 |
|---|---|---|---|
| 敏感字段已脱敏 | 客户名、个人信息、金额等已替换或删除 | 脱敏记录或修改对照 | 文档作者 |
| 内部信息已清理 | 内部代号、未公开计划不在对外版本中 | 清理清单 | 领域复核人 |
| 发布范围与密级匹配 | 接收范围不超过文档允许的传播范围 | 发布范围说明 | 发布责任人 |
| 对外发布审批完成 | 审批记录存在且审批人有权批准 | 审批记录 | 发布责任人 |
在协作平台中承载这类检查时，可以把文档评审、审批与发布放在同一处留痕。ONES Assistant 可基于指定 Wiki 页面组回答问题并附引用来源，其AI能力基于ONES权限体系执行，输出过程可追踪、结果可审计，便于在评审时回看依据；具体评审与发布流程以实际部署为准。
表达一致性：术语、格式与语气统一
AI拼接多段内容后，常见问题是同一概念前后叫法不同、标题层级混乱、中英文混排不规范。这类问题不影响事实正确性，但会削弱文档的可信度，对外材料尤其明显。
检查时先统一术语：同一对象在全文使用同一名称，首次出现可加注全称，后文保持一致。再核对格式：标题层级是否连续、编号是否断档、表格表头与单位是否统一。中英文混排注意空格与标点规范，数字单位统一写法。最后判断语气是否匹配受众，对内周报与对外说明的措辞应有区别。抽查方式可选取开头、中间、结尾各一段，对照全文格式规范核对。
- 建立本文术语表，列出关键概念的标准写法。
- 检查标题层级与编号连续性，修正断档。
- 统一表格格式、单位与小数位。
- 抽查三段内容，确认术语与语气一致。
发布与回执：发出之后还要确认什么
发布动作本身也需要检查，常见问题是“发了但没人收到”或“发到了错误的群”。发布前确认渠道与目标受众匹配，该发邮件的不要只发群消息，该通知到的人不要漏掉。发布后确认文档是否已同步到知识库或归档位置，避免正式版本只存在于个人电脑。
对外文档应设置反馈或勘误渠道，说明读者发现问题后如何反馈。发布回执与接收确认要留存：谁在什么时间通过什么渠道收到哪个版本，关键文档可要求接收方确认。回执记录既是发布完成的证据，也是后续复查和撤回的起点。
| 检查项 | 通过标准 | 所需证据 | 负责人 |
|---|---|---|---|
| 渠道与受众正确 | 发布渠道覆盖全部目标读者，无无关人员 | 发布范围清单 | 发布责任人 |
| 已同步知识库或归档 | 归档版本与发布版本一致 | 归档位置与版本号 | 文档作者 |
| 反馈渠道已设置 | 文中或通知中说明反馈方式 | 发布通知内容 | 发布责任人 |
| 发布回执可查 | 有发布时间、渠道、版本与接收确认记录 | 回执记录 | 发布责任人 |
阻断项与完成条件
并非所有问题都需要拦下发布。把问题分为阻断项和可记录放行项，能让检查有明确终点，也避免小问题拖住整体进度。阻断项是必须修复才能发布的问题，可记录放行项是记录在案后可以带着发布、后续修正的问题。
阻断项包括四类：事实性错误，如关键数字与源数据不符、结论无证据支撑；敏感信息外泄，如客户信息、个人信息、合同金额未脱敏；无审批对外发布，即对外材料缺少必要审批记录；引用造假，即引用的文献、数据来源不存在或与正文不符。这四类问题任一存在，发布即暂停。
可记录放行项包括格式细节、非关键术语不统一、次要引用待补充等，处理方式是在检查表中记录问题、责任人和修正时限，由发布责任人确认后放行。完成条件是：全部阻断项关闭，检查表由作者、复核人、发布责任人签字或系统留痕。发布后保留复查机制，发现问题时按回执记录定位版本与接收范围，必要时发布勘误或撤回。
- 阻断项关闭：逐项附修复证据，由发布责任人确认。
- 放行项记录：写明问题、责任人、修正时限。
- 签字或留痕：三类角色确认，记录随文档归档。
- 复查与撤回：明确触发条件与操作人，回执记录作为定位依据。
常见问题
AI初稿完成后先查什么，能减少后面返工？
第一轮自查的重点是清理明显失实和无法追溯的内容，而不是逐字润色。具体做三件事：把AI补写的推断性表述逐句标出来，有来源的补来源，无来源的删除或标为待确认；把文中出现的数字、人名、项目名列成待核清单，留给复核人比对源数据；把引用链接逐条打开一遍，打不开的先替换或删除。这一轮做完，定稿评审时复核人面对的是已筛过的问题清单，核对效率会明显提高。
复核人和作者是同一个人时，检查还有意义吗？
小团队里一人兼多个角色很常见，自查仍然有价值，但需要补一个外部视角。可以请熟悉数据来源的同事只核对关键数字和引用，不必通读全文；也可以把结论与证据对照说明写出来，让未参与写作的人按对照表抽查。作者自己核对时容易跳过“本来就知道”的信息，客户名称、内部代号这类敏感字段尤其如此，所以脱敏环节建议由不参与写作的人复查一遍。
可记录放行项事后忘了改，怎么避免？
放行项要在检查表里写清三件事：问题描述、责任人、修正时限，并由发布责任人确认后才放行。发布后把放行项单独汇总成一份待办，挂到对应责任人的任务里，到期未改的升级提醒。复查时按发布回执记录定位版本和接收范围，确认修正版本是否已替换到位。放行项长期堆积，说明检查标准或写作流程需要调整，可以在下一次评审时回看。
对外发布的材料，审批应该在哪一步完成？
审批应在正式发布前完成，并且审批人要有权批准该密级和该发布范围的内容。实际操作中，脱敏和内部信息清理先做完，再提交审批，避免审批的是未清理版本、发布的是另一版。审批记录要与发布版本对应，写清版本号和发布渠道。发布后发现需要修改，按回执记录定位已发出的版本，必要时发布勘误并重新走审批。
用协作平台承载检查留痕，需要注意什么？
把评审、审批与发布放在同一处留痕，便于回看依据和定位版本。以ONES为例，ONES Assistant 可基于指定 Wiki 页面组回答问题并附引用来源，其AI能力基于ONES权限体系执行，输出过程可追踪、结果可审计，适合在评审时回看依据；具体评审与发布流程以实际部署为准。选型时重点确认三点：检查记录能否随文档归档、权限是否与文档密级匹配、发布版本能否追溯到具体回执。
