AI报告审阅解决的是报告产出环节的质量把关问题：把AI嵌入从起草到发布的固定环节，让它承担结构完整性、数据一致性、表述规范等可核对的初筛，事实与结论仍由报告责任人确认。本文给出四步流程、角色分工、可填写的审阅规则表字段和一份落地检查清单，审阅任务与状态流转可在ONES中承载。
要点总览（TL;DR）
- 先定范围与口径：按固定读者、可核对数据、出错风险三个条件筛选纳入报告，把审阅拆成结构完整性、数据一致性、表述规范、引用可追溯四类检查项。
- 执行走四步：提交前自检与材料齐备、AI初筛、人工确认事实数据与结论、发布放行与留痕，每步都有输入、动作、输出和完成标志。
- 角色分工按交接物推进状态：起草人交材料包，AI审阅执行人交待确认清单，领域确认人交修改清单与修订稿，发布责任人交放行记录。
- 规则表是初筛依据，字段包含检查项、判定标准、证据位置、严重级别、处理动作、适用报告类型和版本，按版本管理并随重复问题补充。
- 验收看六项：规则表覆盖与版本、初筛记录完整、人工确认可查、放行角色正确、异常返工有记录、周期复盘有动作。
AI报告审阅先定什么：报告范围与审阅口径
启动AI报告审阅前，先回答两个问题：哪些报告纳入，审阅哪些内容。范围不清，AI初筛就会变成“让AI随便看看”，输出无法核对，也无法判断是否完成。
纳入与不纳入的报告类型
纳入判断可以按三个条件筛：报告有固定读者和发布渠道；内容包含可核对的数据或引用；出错会造成对外承诺、资源决策或合规风险。满足两条以上，适合纳入。一次性内部备忘、纯创意草稿、需要大量主观判断的战略论述，可以先不纳入，避免审阅成本高于收益。
| 报告类型 | 是否纳入 | 主要理由 |
|---|---|---|
| 项目周报、月度进展报告 | 纳入 | 数据口径固定，读者稳定，适合规则化初筛 |
| 对外发布的行业分析、客户交付报告 | 纳入 | 对外承诺与引用准确性要求高 |
| 季度经营分析、预算说明 | 纳入 | 数据一致性与结论支撑需要逐项核对 |
| 内部会议备忘、个人工作草稿 | 暂不纳入 | 读者范围小，审阅成本高于风险 |
| 战略方向论述、创意提案初稿 | 暂不纳入 | 以主观判断为主，AI初筛难以给出可核对结论 |
四类审阅口径
审阅口径建议拆成四类，每类给出可核对的判定标准和证据位置，AI初筛才有稳定依据。
- 结构完整性：报告是否包含约定的章节，如背景、方法、数据、结论、下一步；缺失章节要指出位置。
- 数据一致性：正文数字与表格、图表、附录是否一致；同一指标在不同章节的口径是否统一；合计与分项是否对得上。
- 表述规范：术语是否统一，时间、单位、百分比写法是否一致，是否存在含糊承诺或未定义缩写。
- 引用可追溯：外部数据、政策、竞品信息是否标注来源和时间；引用内容与原文意思是否一致。
谁定口径、写在哪、多久更新
口径由报告归口负责人牵头制定，领域确认人参与补充专业检查项，发布责任人确认放行标准。口径写成一份独立的审阅规则表，与报告模板放在同一知识空间，版本号随规则表更新。建议每季度复核一次；报告类型新增、数据口径调整、出现重复返工问题时立即更新。每次更新记录变更内容和生效日期，避免不同批次报告使用不同标准。
核心操作步骤：从AI初筛到发布放行
流程分四步，每步都有明确的输入、动作、输出和完成标志。四步走完，报告才进入发布环节。
步骤一：提交前自检与材料齐备
输入：报告初稿、数据底稿、引用来源清单、适用的审阅规则表版本。动作：起草人按规则表逐项自检，补齐缺失章节和数据来源，确认图表与正文使用同一版数据。输出：自检记录和齐备的材料包。完成标志：规则表中标记为“提交前必查”的条目全部通过，材料包无缺项。
步骤二：AI初筛
输入：材料包、规则表、报告类型对应的提示词模板。动作：AI审阅执行人把规则表转成结构化提示词，按四类口径逐项检查，要求AI对每个问题给出位置、原文摘录、判定依据和建议处理动作。提示词组织建议分三段：角色与任务说明、规则表条目、输出格式要求。输出格式固定为待确认清单，每条包含检查项编号、严重级别、证据位置和AI判断。输出：AI初筛待确认清单。完成标志：规则表中所有适用条目都有对应输出，清单条目可定位到原文。
步骤三：人工确认事实、数据与结论
输入：AI初筛待确认清单、报告初稿、原始数据。动作：领域确认人逐条核对，对每条标注采纳、修改或驳回，并写明理由；涉及数据和结论的条目必须回查原始来源。AI判断与人工判断不一致时，以人工结论为准并记录分歧原因。输出：确认后的修改清单和修订稿。完成标志：清单中每条都有处理结论，高严重级别条目全部关闭或经发布责任人同意保留。
步骤四：发布放行与留痕
输入：修订稿、确认后的修改清单、自检记录。动作：发布责任人按放行清单核对：高严重级别问题是否关闭、引用是否可追溯、版本号与日期是否正确，确认后放行。输出：放行记录，包含报告版本、审阅轮次、参与角色和遗留问题。完成标志：放行记录归档，报告进入发布渠道。
角色与交付物：谁提交、谁初筛、谁放行
角色边界清楚，AI输出才不会被当成最终结论。四个角色各有交接物，交接物同时是状态推进的依据。
| 角色 | 主要职责 | 交接交付物 | 交接后状态 |
|---|---|---|---|
| 报告起草人 | 完成初稿与提交前自检，补齐材料 | 材料包、自检记录 | 待初筛 |
| AI审阅执行人 | 维护提示词模板，执行AI初筛，整理待确认清单 | AI初筛待确认清单 | 待人工确认 |
| 领域确认人 | 核对事实、数据与结论，逐条给出处理结论 | 修改清单、修订稿 | 待放行 |
| 发布责任人 | 按放行清单核对并确认发布 | 放行记录 | 已发布 |
责任归属要写进流程说明：AI初筛结果只作为待确认线索，事实与结论的准确性由领域确认人负责，最终发布决定由发布责任人负责。AI审阅执行人对初筛的完整性和可追溯性负责，包括规则表版本是否正确、清单是否覆盖全部适用条目。出现因AI漏检导致的问题，复盘时检查规则表和提示词是否需要补充，不把责任简单归到执行人个人。
审阅规则表怎么写：字段与示例
规则表是AI初筛的依据，字段设计要让每条规则都能被核对、被执行。建议包含以下字段：
- 检查项：规则名称，如“正文与表格数据一致”。
- 判定标准：什么情况算通过、什么情况算问题，尽量写成可观察的条件。
- 证据位置：问题应定位到哪里，如章节号、表格名、页码或段落。
- 严重级别：高、中、低。高对应必须修改后才能发布的问题。
- 处理动作：发现问题后由谁做什么，如“退回起草人补充来源”。
- 适用报告类型：标明该条规则适用于哪些报告，避免全量套用。
- 版本与生效日期：记录规则变更，便于追溯。
一条完整填写示例：检查项为“引用来源可追溯”，判定标准为“外部数据、政策或竞品信息须标注来源名称与发布时间，正文引用与来源原文意思一致”，证据位置为“引用所在段落及脚注”，严重级别为“高”，处理动作为“缺少来源的由起草人补充；来源与原文不符的退回修改并记录”，适用报告类型为“对外发布类、经营分析类”。
规则表按版本管理：每次修改生成新版本号，旧版本保留只读；报告提交时记录所用规则表版本，审阅记录中可回查当时的标准。规则表条目不宜一次求全，先从高频问题起步，每轮审阅后把重复出现的问题补成新条目。
用ONES承载审阅流程与留痕
流程跑起来后，需要一处地方同时存放报告文档、审阅任务和状态记录，避免审阅意见散落在聊天工具和邮件里。ONES可以承载这条链路：报告在Wiki页面中起草和版本管理，审阅任务以工作项形式关联到对应报告，状态按“待初筛—待人工确认—待放行—已发布”推进。
具体做法上，起草人在Wiki中完成报告并提交自检记录；AI审阅执行人基于页面内容执行初筛，把待确认清单整理为工作项下的检查条目，每条附证据位置和严重级别；领域确认人在工作项中逐条回复处理结论，修改在Wiki页面留版本记录；发布责任人核对后更新状态并归档放行记录。ONES Assistant可理解项目、工作项和Wiki页面等上下文，基于相关数据和团队知识回答问题并执行后续操作，例如根据当前迭代生成项目周报并保存到Wiki，减少页面切换和重复录入；其输出过程可追踪、结果可审计，便于把AI初筛环节纳入同一套记录。实际可用范围以部署与权限配置为准。
评审意见与修改的闭环靠状态和关联关系保证：每条意见对应一个检查条目，条目关闭需要处理结论和修改后的版本号；报告状态只有在高严重级别条目全部关闭后才能进入“待放行”。这样，审阅过程、AI输出和人工结论都留在同一处，复盘时可以直接回查。
完成检查：这套机制是否真的跑起来了
机制是否落地，不看流程文档写得多完整，看以下条目能否逐项核对通过。建议每月抽查一次，每季度全面复核。
- 规则表覆盖与版本：主要报告类型都有对应规则表，规则表有版本号和生效日期，报告记录中能查到提交时使用的版本。
- 初筛记录完整：每份纳入审阅的报告都留有AI初筛待确认清单，清单条目能定位到原文位置。
- 人工确认可查：清单中每条都有采纳、修改或驳回的结论和理由，高严重级别条目有回查原始来源的记录。
- 放行角色正确：放行记录由指定发布责任人完成，放行前高严重级别问题已关闭或经同意保留。
- 异常与返工有记录：AI漏检、人工误判、重复返工都有记录，并能对应到规则表或提示词的更新。
- 周期复盘有动作：每季度复核规则表，新增或修订条目有变更记录，下一批次报告已使用新版本。
抽查时如果发现某份报告只有AI输出、没有人工确认记录，说明流程在交接环节断了，应回到角色职责和状态设置上修正，而不是增加更多检查项。机制跑顺的标志是：审阅轮次稳定、返工原因可归类、规则表随问题持续更新。
常见问题
报告类型多、审阅人力有限，怎么分批纳入AI审阅？
按风险与频率排序，先纳入读者固定、数据口径稳定、出错影响大的报告，例如项目周报、对外交付报告和经营分析。一次性备忘、创意草稿可以暂缓。每纳入一类，先跑两到三轮，观察AI初筛清单中有效条目与误报的比例，再决定是否扩展到下一类。规则表条目也从高频问题起步，逐步补充，避免一次性铺开导致审阅流于形式。
AI初筛给出的判断和领域确认人不一致时怎么处理？
以人工结论为准，同时记录分歧原因。分歧本身是有价值的输入：如果AI漏检，检查规则表条目是否表述过宽或证据位置不明确；如果AI误报，检查判定标准是否缺少可观察条件。分歧记录积累到一定数量后，集中修订规则表和提示词模板，并在下一批次报告中验证效果。这样处理既保证当前报告的准确性，也让规则表持续收敛。
审阅记录要保留到什么程度才算可追溯？
至少保留四类记录：提交时使用的规则表版本号、AI初筛待确认清单（含检查项编号、证据位置、严重级别）、每条清单条目的人工处理结论与理由、放行记录（含报告版本、审阅轮次、参与角色和遗留问题）。涉及数据和结论的条目，还要能回查到原始来源。记录与报告版本关联存放，复盘时可以直接定位到当时的标准和判断依据。
规则表多久更新一次，更新后旧报告怎么办？
建议每季度复核一次；出现报告类型新增、数据口径调整或重复返工问题时立即更新。每次更新生成新版本号，旧版本保留只读。已经发布的报告不追溯重审，但审阅记录中保留当时使用的版本号，便于事后核对。更新后要确认下一批次报告已使用新版本，避免新旧标准混用。
审阅流程在ONES中怎么和报告文档关联起来？
报告在Wiki页面中起草并保留版本记录，审阅任务以工作项形式关联到对应报告，状态按“待初筛—待人工确认—待放行—已发布”推进。AI初筛的待确认清单整理为工作项下的检查条目，每条附证据位置和严重级别；领域确认人在工作项中逐条回复处理结论，修改回到Wiki页面留版本。ONES Assistant可理解项目、工作项和Wiki页面等上下文，基于相关数据和团队知识回答问题并执行后续操作，输出过程可追踪、结果可审计，实际可用范围以部署与权限配置为准。
机制运行一段时间后，怎么判断该收紧还是该简化？
看两个信号：审阅轮次是否稳定、返工原因是否可归类。如果同一类问题反复出现，说明规则表条目需要补充或判定标准需要写得更具体；如果大量条目长期无问题、人工确认环节只是形式性通过，说明检查项过细或范围过宽，可以合并条目或缩小纳入范围。调整的依据来自审阅记录，不靠主观感觉。
