AI生成的文档读起来通顺，发布后却常被发现引用打不开、数字对不上、附件缺失或发给了不该看的人。这类问题集中在内容事实、数据口径、敏感信息、版本权限、格式可读性五个方面。下面这份检查清单按发布前、发布中、发布后三个阶段组织，每项给出通过标准、证据和负责人，并把引用缺失、敏感信息外泄风险、版本错误、权限越界设为阻断项。ONES可用于承载检查记录与发布流转，文中在相应环节说明衔接方式。
要点总览（TL;DR）
- AI文档发布检查最易遗漏五类问题：内容事实与引用、数据口径与时间范围、敏感信息与权限、版本与责任人、格式与可读性。
- 检查要按三个时点分开执行：AI初稿完成时粗筛、人工修订后核对一致性、正式发布前做全量核对，越晚发现事实错误返工成本越高。
- 每项检查只给通过、不通过、待确认三种结论，待确认必须指定责任人和时限，超时视为不通过，避免检查流于形式。
- 引用缺失、敏感信息外泄风险、版本错误、权限越界应设为阻断项，未清零不发布；格式细节等可带条件放行，但需书面记录和审批。
- 把检查表建成可勾选的工作项模板，让检查项、证据和签核与文档版本关联，发布后可回溯，也能沉淀为下一份文档的复用模板。
谁在什么时点用这份检查清单
这份清单面向三类角色：文档撰写人、审阅人和发布负责人。撰写人通常是使用AI生成初稿并完成人工修订的人，对内容事实和引用负第一责任；审阅人从业务或专业角度核对结论、数据口径和表述边界；发布负责人决定文档能否发出、发给谁，并对阻断项是否清零做最终确认。角色可以由同一人兼任，但检查动作要分开执行，避免自己写、自己审、自己发一路到底。
触发时点有三个。第一是AI初稿完成时，此时重点核对AI补全的数字、人名、日期、版本号和引用是否存在，属于粗筛；第二是人工修订后，重点核对修改是否引入新的不一致，例如改了结论但没改摘要、换了数据但没更新图表；第三是正式对外或跨团队发布前，做全量核对，包括权限、密级、附件和格式。三个时点各有侧重，不能只在最后一步集中检查，因为越晚发现事实错误，返工成本越高。
检查节奏按文档风险分级。内部日常文档可执行一次性全量核对，由撰写人自查、审阅人抽查关键项；对外发布、涉及经营数据、涉及客户信息或跨部门正式文件，执行加严核对，要求逐项留证、双人复核、发布负责人签核。分级标准建议写进团队规范，避免每份文档临时判断。
| 角色 | 检查时点 | 主要检查项 | 输出 |
|---|---|---|---|
| 文档撰写人 | AI初稿完成 | 事实陈述、引用真实性、AI补全的数字与名称 | 初稿问题清单 |
| 文档撰写人 | 人工修订后 | 修改处与全文的一致性、数据口径、图表同步 | 修订记录与自查结果 |
| 审阅人 | 修订稿提交审阅 | 结论边界、数据来源、表述准确性 | 审阅意见 |
| 发布负责人 | 正式发布前 | 敏感信息、密级与渠道、版本、权限、格式、附件 | 发布签核记录 |
| 发布负责人 | 发布后 | 实际可见范围、链接可用性、问题回退 | 发布确认与更正记录 |
发布前检查项：内容与事实
内容与事实是AI文档最容易出问题的地方，因为AI会以流畅的语气补全它并不掌握的信息。检查的核心不是重读一遍是否通顺，而是逐条确认每个可被质疑的陈述有没有依据。以下检查表可直接用于逐项核对。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 事实陈述有出处 | 每个关键事实能指向来源文档、数据系统或责任人确认 | 来源链接、数据导出文件、确认记录 | 撰写人 |
| 引用与链接真实可用 | 逐条打开验证，标题、作者、日期与正文引用一致 | 打开截图或访问记录 | 撰写人 |
| AI补全的数字、人名、日期、版本号 | 逐条与原始来源比对，无来源的删除或标注待确认 | 比对记录、标注清单 | 撰写人 |
| 结论与建议在授权范围内 | 结论不超出文档定位和发布对象权限，不替其他部门作承诺 | 审阅意见 | 审阅人 |
| 前后表述一致 | 摘要、正文、结论对同一事项的说法一致 | 修订记录 | 撰写人 |
操作上建议先做标记再做核对：把文中所有数字、专有名词、时间、版本号和“据……”“根据……”类表述标出来，形成待核清单，再逐条找来源。没有来源的表述有三种处理方式：补来源、改为不含具体断言的表述、删除。对AI生成的段落，尤其要警惕看似具体却无法追溯的细节，例如精确到小数点的比例、没有出处的行业排名、模糊的“某头部客户案例”。
发布前检查项：数据口径与敏感信息
数据类问题往往在文档内部看不出来，需要跨文档、跨系统比对。敏感信息问题则一旦发出就很难收回，因此这两类检查要放在发布前完成，并把高风险项设为阻断。
| 检查项 | 通过标准 | 证据 | 负责人 | 是否阻断 |
|---|---|---|---|---|
| 统计口径与来源一致 | 指标定义、统计范围、时间范围、单位与数据源一致，并在文中注明 | 数据源说明、口径对照 | 撰写人 | 是 |
| 跨文档同一指标数值一致 | 与已发布文档、报表中的同一指标数值一致，差异有解释 | 比对截图 | 撰写人 | 是 |
| 时间范围标注清楚 | 每个数据都标明统计区间，避免“近期”“目前”等模糊表述 | 文中标注 | 撰写人 | 否 |
| 客户信息与个人信息 | 无未经授权的客户名称、联系人、合同金额等 | 全文检索记录 | 审阅人 | 是 |
| 内部链接与未公开数据 | 外发版本不含内网地址、内部系统截图、未公开经营数据 | 外发版本检查记录 | 发布负责人 | 是 |
| 密级与渠道匹配 | 文档密级与发送渠道、接收范围一致 | 密级标注、发送名单 | 发布负责人 | 是 |
口径检查有一个实用做法：把文档中每个关键指标写成“指标名＋定义＋时间范围＋单位＋来源”一行，集中放在文档末尾或附表中，发布前逐行确认。这样既方便审阅人核对，也方便后续读者理解数据边界。敏感信息检查则建议用关键词检索加人工通读两步：先检索客户名、内部系统名、金额、联系方式等关键词，再通读全文确认没有遗漏的间接信息，例如能反推出客户身份的案例描述。
发布前检查项：版本、权限与格式
文档工程层面的问题不涉及内容对错，却直接决定发布是否有效。发错版本、发错人、附件缺失，都会让前面的内容检查白做。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 版本号与修订记录 | 版本号连续，修订记录写明修改内容和日期，当前文件为最终稿 | 修订记录页 | 撰写人 |
| 文件名规范 | 文件名含文档名、版本、日期，与发布记录一致 | 文件属性截图 | 撰写人 |
| 共享范围与访问权限 | 接收人名单与预期一致，外发链接设置有效期和访问限制 | 权限设置截图 | 发布负责人 |
| 标题层级与编号 | 标题层级连续，表格、图表编号与正文引用一致 | 通读确认 | 撰写人 |
| 目录与页码 | 目录可更新且与正文一致 | 更新后截图 | 撰写人 |
| 附件、图片与嵌入内容 | 每个附件可打开，图片清晰，嵌入的表格和图表在接收端可正常显示 | 接收端预览截图 | 发布负责人 |
格式检查建议在最终导出格式上做，而不是在编辑界面做。导出为PDF或对方使用的格式后，检查目录、页码、图表编号、字体和附件是否正常。权限检查则要区分“文档权限”和“链接权限”：前者看谁能打开文档，后者看链接是否可被转发。对外发布时，建议用带有效期的受限链接，并在发布记录中写明链接失效时间。
通过标准与证据留存
检查流于形式，通常是因为没有统一的判定规则和留证要求。建议每项检查只给三种结论：通过、不通过、待确认。通过指满足通过标准且有证据；不通过指明确不符合，需要修改后重检；待确认指当前无法判断，必须指定责任人和确认时限，不能默认放行。
| 判定 | 适用情形 | 后续动作 |
|---|---|---|
| 通过 | 满足通过标准，证据已留存 | 记录证据位置，进入下一项 |
| 不通过 | 明确不符合标准 | 修改后重新检查，保留两次记录 |
| 待确认 | 来源不明、权限不清、数据待核 | 指定确认人和截止时间，超时视为不通过 |
证据形式按检查项选择：引用类留存链接和打开截图；数据类留存数据源导出文件或比对截图；权限类留存权限设置截图和接收人名单；审阅类留存审阅意见和修改记录。证据统一存放在与文档关联的位置，文件名带上文档名和版本号，保留时长按团队文档管理制度执行，对外发布文档建议至少保留到文档失效后一个完整版本周期。检查记录要与文档版本一一对应，避免出现“检查的是第三稿、发出去的是第四稿”的情况。
阻断项与发布完成条件
阻断项指未清零就不能发布的项目，需要发布负责人明确确认。建议把以下四类设为阻断项：引用缺失或链接不可用；存在敏感信息外泄风险；版本错误或非最终稿；权限越界或接收范围超出授权。这四类问题一旦发出，更正成本高且可能造成实际损失，因此不适用“先发后改”。
可带条件放行的项目包括格式细节、目录页码、非关键表述优化等。带条件放行需要写明遗留问题、责任人和补正时间，并由发布负责人审批。发布完成条件建议统一为：全部阻断项清零；非阻断项要么通过，要么有书面放行记录；发布负责人完成签核；发布记录中写明版本号、接收范围、发布时间和链接有效期。四项齐备才算发布完成。
发布后发现问题的回退流程也要提前约定：发现事实错误或敏感信息泄露时，第一时间撤回或失效链接，通知已接收方，发布负责人在发布记录中登记问题、影响范围和更正版本；更正版本重新走一遍阻断项检查。回退流程写进清单，比事后临时协调更可靠。
用协作平台承载检查记录与发布流转
清单要真正被执行，需要落到团队日常使用的协作工具中，让检查项、证据和签核都能追溯。一种可行做法是把检查表建成可勾选的工作项模板：每个检查项是一个工作项，字段包括通过标准、证据链接、负责人、检查时点和判定结果，阻断项单独标记。文档起草时从模板生成检查任务，撰写人、审阅人、发布负责人各自认领。
文档、审阅记录和发布审批放在同一处关联，可以让“检查的是哪一版、谁签核的、证据在哪”在一个页面内看清。发布状态变化和版本变更保留操作记录，出现问题时能回溯到具体环节。ONES 的文档协作与工作项管理可以承载这类检查模板、审阅流转和发布记录，把检查项、证据和签核关联到同一文档下，便于团队按版本追溯。每次发布结束后，把本次实际使用的检查项和发现的问题回写到模板，下一份文档直接复用，清单会随着团队踩过的坑逐步完善。
常见问题
AI初稿读起来很通顺，是否还需要逐条核对数字和引用？
需要。AI会以流畅的语气补全它并不掌握的信息，通顺与准确是两件事。建议把文中所有数字、专有名词、日期、版本号和“据……”“根据……”类表述标出来，形成待核清单，再逐条找来源。没有来源的表述有三种处理方式：补来源、改为不含具体断言的表述、删除。精确到小数点的比例、没有出处的行业排名、模糊的客户案例，都是需要重点核对的信号。
内部日常文档也要走完整检查流程吗？
可以按风险分级简化。内部日常文档由撰写人自查、审阅人抽查关键项，执行一次性全量核对即可；对外发布、涉及经营数据、涉及客户信息或跨部门正式文件，执行加严核对，要求逐项留证、双人复核、发布负责人签核。分级标准建议写进团队规范，避免每份文档临时判断。无论哪一级，引用真实性和敏感信息这两类阻断项都不应省略。
检查时发现数据来源暂时找不到，能否先发布后补？
不建议。来源不明的数据属于“待确认”，应指定确认人和截止时间，超时按不通过处理。如果该数据属于统计口径或跨文档一致性类阻断项，未确认前不能发布。确实需要先发的，可以删除具体数值或改为不含具体断言的表述，待来源确认后在后续版本补充。发布记录中要写明这一处理，便于回溯。
文档发布后才发现敏感信息，应该怎么处理？
第一时间撤回文档或使外发链接失效，通知已接收方，发布负责人在发布记录中登记问题、影响范围和更正版本。更正版本需要重新走一遍阻断项检查再发布。建议在发布前就用关键词检索加人工通读两步排查：先检索客户名、内部系统名、金额、联系方式等关键词，再通读全文确认没有能反推出客户身份的间接信息。
检查记录保留多久、放在哪里比较合适？
证据统一存放在与文档关联的位置，文件名带上文档名和版本号，保留时长按团队文档管理制度执行，对外发布文档建议至少保留到文档失效后一个完整版本周期。关键是检查记录与文档版本一一对应，避免出现“检查的是第三稿、发出去的是第四稿”。用协作平台把检查项、证据链接和签核记录关联到同一文档下，回溯时不必再翻聊天记录和邮件。
