AI报告生成要真正投入使用，关键在流程和口径：先确定报告类型与读者，再固定数据来源与字段定义，把报告拆成模板骨架和可复用段落，让AI按输入生成初稿，最后由责任人核对数据、补充判断并完成评审归档。本文按“选报告—跑流程—定角色—设模板—做示例—过检查”的顺序，给出一套可执行的方法；报告所需的数据、任务状态与评审记录，可以在ONES等研发管理工具中沉淀。
要点总览（TL;DR）
- 先按产出频率、结构稳定度、数据可得性筛出1–2份首批试点报告，事实汇总型优先，判断主导型暂缓。
- 主流程分五步：定结构与字段、整理数据源与口径、编写提示词与示例稿、AI生成初稿并标注待核实项、人工复核定稿归档，每步写明输入、动作、输出与可验证的完成标志。
- 数据提供方、撰写人、审核人、签发人各司其职，审核与签发不宜由同一人承担，AI生成结果由撰写人确认后才进入审核。
- 模板固定骨架、提示词写明角色、输入清单、输出格式与禁止事项，并要求AI对缺失或不确定内容标注待核实，而不是自行补全。
- 上线前逐项核对口径、版本化、复核责任、敏感信息权限、异常处理和试跑结果，全部通过后先按固定频率运行两到三个周期再扩展。
先定报告清单：哪些报告值得交给AI生成
启动AI报告生成时，先划定范围，避免一开始就覆盖所有报告类型。判断标准可以落在三个维度上：产出频率、结构稳定度、数据可得性。频率高意味着重复投入大，结构稳定意味着模板容易固化，数据可得意味着AI有可靠输入。三项都高的报告，最适合作为首批试点。
可以按下面的方式给现有报告分类：
| 报告类型 | 频率 | 结构稳定度 | 数据可得性 | 建议 |
|---|---|---|---|---|
| 周度进展报告 | 高 | 高（章节骨架固定） | 高（任务状态、迭代数据已有记录） | 首批试点 |
| 月度运营简报 | 中 | 较高 | 中（部分指标需手工汇总） | 第二批，先补齐数据源 |
| 季度经营分析 | 低 | 中 | 中 | 暂缓，判断成分重 |
| 项目复盘报告 | 低 | 低（每次内容差异大） | 低 | 人工主导，AI仅辅助整理素材 |
| 对外披露或合规报告 | 低 | 高 | 高 | 可用AI起草，但须严格人工审核 |
需要区分两类报告：一类是“事实汇总型”，结论由数据直接支撑，AI起草后人工核对数值即可；另一类是“判断主导型”，例如战略复盘、风险定级、资源取舍，结论依赖人的经验与责任，AI适合整理素材和生成结构，判断部分由人完成。把这两类混在一起试点，容易让评审人对AI输出失去信任。
确定首批试点时，为每份报告写明四项信息：报告名称、产出频率、读者与用途、数据来源。读者决定详略与语气，用途决定报告需要支撑什么决策。建议首批控制在1–2份报告，跑通一轮再扩展。
首批AI报告清单可以按下面的字段填写：
- 报告名称：如“XX项目周度进展报告”
- 频率：每周五产出
- 读者与用途：项目组与部门负责人，用于同步进展和暴露阻塞
- 数据来源：项目管理系统中的迭代、工作项状态，以及团队Wiki中的会议记录
- 是否试点：是
核心操作步骤：从数据准备到报告定稿的五步流程
主流程分五步，每一步都明确输入、动作、输出和完成标志。完成标志要可验证，例如“字段口径表经数据提供方确认”，而不是“数据准备好了”这类模糊表述。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、确定报告结构与必填字段 | 报告用途、读者、历史报告样本 | 拆出固定章节骨架，列出每章必填字段与数据项 | 报告结构说明与字段清单 | 结构与字段经报告负责人确认，评审人无异议 |
| 二、整理数据源与口径 | 字段清单、各系统数据入口 | 为每个字段指定来源系统、取数方式、统计口径与责任人 | 字段—来源—口径对照表 | 数据提供方逐项确认口径，无悬空字段 |
| 三、编写提示词模板与示例稿 | 报告结构、字段表、一份历史优质报告 | 编写角色设定、输入清单、输出格式、禁止事项，附示例稿 | 提示词模板与示例稿 | 用同一输入试跑两次，输出结构一致 |
| 四、AI生成初稿并标注待核实项 | 整理好的输入材料、提示词模板 | 生成初稿，要求对缺失或不确定内容标注“待核实” | 带标注的报告初稿 | 初稿章节齐全，待核实项已逐条列出 |
| 五、人工复核、定稿与归档 | 初稿、原始数据 | 核对数值与口径，补充判断与建议，完成评审后归档 | 定稿报告与版本记录 | 复核人签字，版本记录含修改说明与定稿时间 |
第一步的重点是把“报告长什么样”变成书面约定。固定章节骨架之外，明确哪些段落每次都要写、哪些按需出现。字段清单要细到可取值，例如“本周完成任务数”需要说明统计范围是本周状态变更为完成的工作项，还是本周计划内完成的工作项。
第二步决定报告的可信度。字段口径表要写清来源系统、取数时间点、统计范围和责任人。跨系统数据要注明以哪个系统为准，避免同一指标出现两个数值。口径确认后，后续每次生成都沿用同一套定义。
第三步把结构转化为提示词。提示词模板至少包含四部分：角色设定、输入材料清单、输出格式（章节与字段）、禁止事项。禁止事项中明确“不得编造数据，缺失处标注待核实”。附一份历史优质报告作为示例稿，帮助AI对齐语气与详略。
第四步生成初稿时，要求AI对每个数值标注来源字段，对无法从输入中确认的内容单独列出。初稿的完成标准是“可被复核”，而非“可直接发布”。
第五步设置两处人工复核点：数据核对与判断补充。数据核对检查数值、口径和来源；判断补充由报告负责人完成，包括结论、建议和需要决策的事项。定稿后在版本记录中写明修改点、复核人和定稿时间。
角色与交付物：谁提供数据、谁审稿、谁签发
报告生成链路中，责任要落到具体角色，避免出现“AI写的”这类无人负责的表述。AI是起草工具，报告的事实准确性和结论由人承担。
| 角色 | 职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 数据提供方 | 按字段口径表提供或确认数据，说明异常值 | 数据文件或系统取数结果、口径确认记录 | 生成初稿前 |
| 报告撰写人 | 整理输入材料、运行提示词模板、生成初稿并标注待核实项 | 带标注的报告初稿 | 初稿完成后交审核人 |
| 审核人 | 核对数据与口径，检查结论是否有依据，提出修改意见 | 审核意见与修改记录 | 初稿提交后一个工作日内 |
| 签发人 | 确认报告可用于既定用途，对结论与对外表述负责 | 签发确认与定稿版本 | 审核通过后 |
小团队可以合并角色，例如撰写人兼数据整理，但审核与签发不宜由同一人完成，尤其是对外报告。角色合并时要在流程说明中写明，避免后续扩展时职责不清。
AI工具的使用责任归属要单独说明：提示词模板由报告负责人维护，生成结果由撰写人确认后才进入审核环节。审核人发现数据错误时，追溯的是字段口径或输入材料，而不是修改AI输出本身。这样每次错误都能转化为口径表或模板的改进项。
报告所需的任务状态、迭代数据和评审记录如果沉淀在研发管理工具中，取数和留痕会更顺畅。以ONES为例，ONES Assistant可连接ONES Project、ONES Wiki与ONES TestCase，理解项目、工作项、迭代和Wiki页面等工作上下文，并支持根据当前迭代生成项目周报并保存到Wiki；在Wiki页面、附件等知识上下文中，也支持智能文档生成与全局知识检索。这些能力对应的是“输入材料从哪来、初稿存到哪、评审记录留在哪”的管理动作，报告的口径与结论仍由上述角色确认。
提示词与模板设计：让AI输出稳定可用的报告初稿
输出稳定来自两件事：模板骨架固定，提示词把变量说清楚。模板负责“每次都有哪些章节”，提示词负责“这次填什么内容”。
报告模板建议分成固定骨架与可变段落。固定骨架包括报告标题、周期、总体结论、关键进展、风险与阻塞、下期计划；可变段落按报告类型增减，例如周报可加“数据一览”，月报可加“趋势对比”。固定骨架保证评审人每次按同一顺序阅读，可变段落保留业务差异。
提示词模板可以按以下结构编写：
- 角色设定：说明AI是报告起草助手，服务于哪类读者。
- 输入材料清单：逐项列出本次提供的数据、文档和背景说明，并注明每项对应的字段。
- 输出格式：按章节列出标题、必填字段、字数范围或条目数量。
- 禁止事项：不得编造数据；输入中缺失的内容标注“待核实”；不替报告人下结论，结论部分留空或标注“待补充”。
- 示例稿：附一份历史报告，说明哪些部分可模仿、哪些部分需按本次数据替换。
示例稿的使用要克制。示例稿的作用是校准结构与语气，不是让AI照抄内容。提示词中应说明“示例仅用于格式参考，数据与结论以本次输入为准”。
对不确定内容的处理要写进提示词，而不是依赖生成后的人工发现。可以要求AI在初稿末尾附一张“待核实清单”，逐条列出缺失字段、口径疑问和需要人确认的判断。复核人按清单逐项处理，处理结果回填到定稿中。
模板与提示词都要版本化。每次调整字段或章节，记录版本号、调整原因和生效日期。试跑阶段可以保留两三个版本对比输出差异，正式运行后只保留当前版本，历史版本归档备查。
示例：一份周度进展报告的生成过程
以下为演示情景，用于说明流程如何运转，数据为虚构。
输入材料清单与口径。某项目周报的输入包括：本周迭代内工作项的状态变更记录（统计范围为本周期内状态变更为“完成”的工作项）、本周新增与关闭的缺陷数（以缺陷管理系统为准）、团队Wiki中的周会纪要、上周周报定稿。字段口径表注明“完成任务数”不含本周创建并当日关闭的临时任务。
生成的初稿结构与待核实标注。AI按模板输出：本周总体结论、关键进展（按工作项分组）、数据一览（完成任务数、缺陷增减）、风险与阻塞、下期计划。初稿在“风险与阻塞”处标注“待核实：周会纪要提到接口联调延迟，但输入中无对应工作项状态，请确认是否升级为阻塞”；在“下期计划”处标注“待补充：输入未包含下期排期”。
人工补充判断与修改点。撰写人核对数据一览，发现缺陷数统计口径与上月不一致，回退到口径表确认后修正；审核人补充“接口联调延迟”的影响判断，将其列为需要协调的事项；签发人确认总体结论的表述与项目实际状态一致。修改点逐条记入版本记录。
定稿版本与留痕方式。定稿报告标注版本号与定稿日期，版本记录包含：初稿生成时间、待核实项处理结果、审核意见、签发人。报告存入团队Wiki对应项目空间，与本周迭代数据同处一个上下文，便于下期生成时直接引用。
这个示例可以迁移到月报：把输入周期拉长，增加趋势对比段落，待核实清单的重点从“本周异常”转为“月度口径变化”。流程本身不变。
完成检查：上线前逐项确认的清单
正式运行前，用下面的清单逐项核对。每项都要有明确的通过标准，不能只凭印象判断。
| 检查项 | 通过标准 | 确认人 |
|---|---|---|
| 数据口径与来源是否固定 | 每个字段有来源系统、统计范围、取数时点和责任人；跨系统指标已注明以谁为准 | 数据提供方与报告负责人 |
| 模板与提示词是否版本化 | 模板与提示词有版本号、调整记录和生效日期；当前版本唯一 | 报告负责人 |
| 复核点与责任人是否明确 | 数据核对与判断补充两处复核均有指定人；审核与签发不由同一人承担（对外报告必须分开） | 团队负责人 |
| 敏感信息与权限是否受控 | 输入材料不含超出报告读者范围的敏感信息；报告存放位置的访问权限与读者范围一致 | 报告负责人与信息安全接口人 |
| 异常与错误输出的处理方式 | 明确数据缺失、AI输出与事实不符、待核实项未处理完时的处理路径和上报对象 | 审核人 |
| 试跑结果是否达标 | 用同一输入连续试跑两次，章节结构一致，待核实项可逐条追溯，复核耗时在可接受范围 | 撰写人与审核人 |
清单全部通过后，先按固定频率运行两到三个周期，再评估是否扩展报告类型。运行期间记录每次复核发现的问题，按“口径问题、模板问题、输入材料问题”分类，定期回写到口径表或提示词模板中。这样流程会随使用逐步稳定，而不是靠一次设计到位。
如果报告数据与评审记录已经在ONES这类研发管理工具中流转，可以把取数、初稿存放和评审留痕放在同一上下文里，减少材料搬运；ONES Assistant基于权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，适合作为报告链路的承载环节之一。具体启用方式和可用范围，以团队实际开通的模块为准。
常见问题
首批试点选几份报告比较合适，多久可以扩展？
建议首批控制在1–2份报告，优先选频率高、章节骨架固定、关键字段已有系统记录的类型，例如周度进展报告。跑通一轮完整流程（含数据核对、判断补充、签发归档）后，再评估是否扩展。扩展前先看试跑期间复核发现的问题是否已回写到口径表或提示词模板，问题收敛后再增加报告类型，避免同一类错误在多份报告中重复出现。
AI生成的初稿里出现数据错误，应该改输出还是改流程？
先追溯错误来源，再决定改哪里。常见来源有三类：字段口径定义不清、输入材料缺失或过期、提示词未要求标注不确定内容。对应处理分别是更新口径表、补齐输入材料、修改提示词模板。直接修改AI输出只能解决当次问题，下次生成仍会复现。建议在版本记录中记下错误类型，定期按“口径问题、模板问题、输入材料问题”分类回写，让每次错误都转化为流程改进项。
小团队人手有限，角色可以合并吗？
可以合并，但要有边界。撰写人可以兼数据整理，审核人可以兼部分判断补充，但审核与签发不宜由同一人完成，对外报告尤其要分开。角色合并后要在流程说明中写明谁承担哪几项职责，以及合并后由谁做最终确认。团队扩展或报告对外使用时，再按原分工拆开，避免职责随人员变动而悬空。
报告涉及敏感数据时，输入材料要怎么处理？
先按报告读者范围划定可用的信息边界，输入材料不包含超出该范围的敏感内容；报告存放位置的访问权限与读者范围保持一致。使用具备权限体系的知识问答与任务执行能力时，输出过程可追踪、结果可审计，有助于控制信息流向（如ONES Assistant基于ONES权限体系运行）。具体权限粒度和审计日志保留周期，以团队实际开通的模块和配置为准。
试跑两次输出结构一致，是否就可以正式上线？
结构一致只是其中一项。上线前还要确认：每个字段有来源系统、统计范围、取数时点和责任人；模板与提示词有版本号和生效日期；两处复核点均有指定人；敏感信息与权限受控；数据缺失、输出与事实不符、待核实项未处理完时有明确处理路径和上报对象。全部通过后先按固定频率运行两到三个周期，观察复核耗时和问题分布，再判断是否稳定。
