AI报告草稿模板是一张先定骨架、再交给AI补内容的空白表：把报告目的、读者、范围与周期、结论摘要、关键进展、数据与证据、风险与依赖、下一步行动、待确认事项等字段固定下来，填写时先写事实与数据，再让AI扩写表述，最后人工核对数字与结论。本文直接给出一张可复制的空白表，并配套字段说明、必填选填规则、一份完整填写示例和维护方法，方便团队拿来即用。
要点总览（TL;DR）
- AI报告草稿模板的核心是“先定骨架、再让AI补写”：用报告目的、读者、范围与周期、结论摘要、关键进展、数据与证据、风险与依赖、下一步行动、待确认事项等字段固定结构。
- 必填字段按“缺了读者就看不懂或无法行动”判定：报告名称、报告目的、读者、范围与周期、结论摘要、关键进展、下一步行动；其余字段按报告类型裁剪。
- 适合交给AI的是表述层工作，如改写书面语、压缩结论、统一句式；数字、结论、风险定级和责任归属必须人工定稿并回查来源。
- 周报、项目阶段报告、复盘报告可保留同一套字段名，只调整内容口径，比新增字段更利于跨报告对比。
- 模板维护要给字段进出设标准并记录版本，字段名调整时同步更新字段说明、必填选填表和示例。
可复制的AI报告草稿空白模板
下面这张表分为两个区域：报告头信息区负责交代“谁在什么背景下写给谁看”，正文区负责承载“发生了什么、依据是什么、接下来做什么”。表格最后一列是AI提示词栏位，填写时把该行已确认的事实粘贴给AI，让它按指定口径扩写，避免AI在缺少输入的情况下自行补造内容。
| 区域 | 字段名 | 填写提示 | 示例占位 | AI提示词栏位 |
|---|---|---|---|---|
| 头信息 | 报告名称 | 项目/团队+报告类型+周期 | 【项目名】第【N】周周报 | — |
| 头信息 | 报告目的 | 一句话说明这份报告要推动什么决定或同步什么信息 | 同步本周进度，确认下周上线范围 | — |
| 头信息 | 读者 | 写明主要读者及其关注点 | 项目组、业务方负责人 | — |
| 头信息 | 范围与周期 | 覆盖的项目、模块与时间区间 | 【项目名】支付模块，【起】至【止】 | — |
| 头信息 | 编制人与日期 | 草稿责任人、成稿日期 | 【姓名】，【日期】 | — |
| 正文 | 结论摘要 | 3–5条，先给结论再给依据 | 本周完成【X】，上线风险集中在【Y】 | 把下列要点压缩为3条结论，每条不超过40字：【粘贴要点】 |
| 正文 | 关键进展 | 按工作项列完成情况，写清“做了什么、到什么状态” | 【工作项】已完成联调，待验收 | 将下列进展改写为书面表述，保留状态词：【粘贴进展】 |
| 正文 | 数据与证据 | 数字、图表来源、文档或工作项链接 | 缺陷关闭率【X%】，来源：【系统/文档】 | — |
| 正文 | 风险与依赖 | 只记录已识别的问题与外部依赖，写影响与当前应对 | 【依赖方】接口延期，影响【范围】 | 将下列风险描述整理为“影响+应对”句式：【粘贴】 |
| 正文 | 下一步行动 | 动作+责任人+时间点 | 【姓名】于【日期】前完成【动作】 | 把下列待办改写为“动作+责任人+时间”格式：【粘贴】 |
| 正文 | 待确认事项 | 需要读者拍板或补充信息的问题 | 【问题】需【角色】确认 | — |
| 正文 | AI扩写说明 | 记录本次使用了哪些提示词、哪些段落由AI生成 | 结论摘要与进展表述由AI扩写，数据人工核对 | — |
复制时建议保留表头与“填写提示”列，正式成稿前删除提示列和示例占位列，只留下字段名与内容，报告会更干净。头信息区与正文区分开的好处是：头信息基本稳定，可以做成固定抬头；正文区随周期变化，便于逐次替换。
每个字段写什么：字段说明与填写口径
模板能否用得好，关键在于区分三类内容：事实、数据、判断。事实是“发生了什么”，数据是“用什么衡量”，判断是“这意味着什么”。三者的填写责任不同，交给AI的边界也不同。
| 字段 | 定义与填写口径 | 内容类型 | 常见错误 | 可否交给AI扩写 |
|---|---|---|---|---|
| 报告名称 | 让人一眼看出对象、类型与周期 | 事实 | 只写“周报”，无法检索 | 可让AI按命名规则生成候选 |
| 报告目的 | 说明报告要推动的动作，如同步、决策、评审 | 判断 | 写成“汇报工作”这类空话 | 人先定，AI可润色 |
| 读者 | 列出主要读者及各自关注点 | 事实 | 只写“领导”，不写关注点 | 人填写 |
| 范围与周期 | 明确项目、模块与起止时间 | 事实 | 范围含糊，读者误以为覆盖全部 | 人填写 |
| 结论摘要 | 先结论后依据，3–5条，每条一个意思 | 判断 | 把进展复述一遍当结论 | AI可压缩表述，结论由人定稿 |
| 关键进展 | 按工作项写“做了什么、到什么状态” | 事实 | 只写“推进中”，没有状态 | AI可改写为书面语，事实由人提供 |
| 数据与证据 | 数字须带口径、时间与来源 | 数据 | 数字无来源、口径不一致 | 人提供并核对，AI不生成数字 |
| 风险与依赖 | 写影响范围与当前应对，不写猜测 | 事实+判断 | 把担忧写成已发生的问题 | AI可整理句式，判断由人确认 |
| 下一步行动 | 动作、责任人、时间点三要素齐全 | 事实 | 只有动作，没有责任人和时间 | AI可格式化，责任人由人指定 |
| 待确认事项 | 写明问题、需要谁确认、期望时间 | 判断 | 把已决事项也列进来 | 人填写 |
适合交给AI的主要是表述层工作：把零散记录改写为完整句子、压缩结论摘要、统一“影响+应对”“动作+责任人+时间”的句式、按读者调整语气。必须人工定稿的是数字、结论、风险定级和责任归属，因为这些内容一旦被AI“顺”得过于流畅，反而容易掩盖口径不一致或依据缺失。一个实用做法是：AI扩写完成后，逐条回查数据与证据字段，确认每个数字都能在来源中找到对应记录。
必填与选填：按报告类型裁剪字段
必填字段的判定标准是：缺少它，读者无法理解报告在说什么或无法据此行动。按这个标准，报告名称、报告目的、读者、范围与周期、结论摘要、关键进展、下一步行动属于必填；数据与证据、风险与依赖、待确认事项、AI扩写说明属于选填，按报告类型和读者需要决定是否保留。
| 字段 | 必填/选填 | 周报 | 项目阶段报告 | 复盘报告 |
|---|---|---|---|---|
| 报告名称 | 必填 | 保留 | 保留 | 保留 |
| 报告目的 | 必填 | 保留 | 保留 | 保留 |
| 读者 | 必填 | 保留 | 保留 | 保留 |
| 范围与周期 | 必填 | 保留 | 保留 | 保留 |
| 结论摘要 | 必填 | 保留 | 保留 | 保留 |
| 关键进展 | 必填 | 保留 | 保留 | 改为“关键过程与结果” |
| 数据与证据 | 选填 | 按需，指标类周报建议保留 | 建议保留 | 建议保留 |
| 风险与依赖 | 选填 | 有则填，无则写“无新增” | 建议保留 | 改为“问题与原因” |
| 下一步行动 | 必填 | 保留 | 保留 | 改为“改进措施” |
| 待确认事项 | 选填 | 有则填 | 建议保留 | 按需 |
| AI扩写说明 | 选填 | 按团队要求 | 按团队要求 | 按团队要求 |
周报追求轻量，字段控制在必填项加少量选填即可，避免每周为填表耗费过多时间；项目阶段报告面向评审或决策，数据与证据、风险与依赖通常需要保留，结论摘要要能支撑阶段判断；复盘报告的字段重心从“下一步做什么”转向“为什么这样、以后怎么改”，可以把关键进展改写为关键过程与结果，把风险与依赖改写为问题与原因，把下一步行动改写为改进措施。裁剪时保留字段名不变、只调整内容口径，比新增字段更利于跨报告对比。
填写示例：一份填好的AI报告草稿
以下为演示情景，项目名称、数字与结论均为虚构，仅用于说明字段写法，不作为真实案例引用。
| 字段 | 填写内容 |
|---|---|
| 报告名称 | 星河项目第12周周报 |
| 报告目的 | 同步本周开发进度，确认下周联调范围与上线风险 |
| 读者 | 项目组全体、业务方负责人（关注上线时间） |
| 范围与周期 | 星河项目支付模块，第12周（周一至周五） |
| 编制人与日期 | 示例编制人，第12周周五 |
| 结论摘要 | 1. 支付模块核心流程开发完成，进入联调；2. 联调依赖的测试环境本周内可交付；3. 上线时间暂按原计划，待联调结果确认。 |
| 关键进展 | 支付下单与回调两个工作项已完成开发并自测通过；对账工作项完成70%，剩余部分待联调数据。 |
| 数据与证据 | 本周关闭缺陷12个，新增缺陷5个，缺陷关闭率约70%，数据来源为项目缺陷记录；自测用例执行记录见测试文档。 |
| 风险与依赖 | 测试环境交付时间若晚于周三，联调窗口将压缩约两天，影响上线前回归；当前应对为提前准备联调脚本，环境到位后立即执行。 |
| 下一步行动 | 示例开发负责人于下周二前完成联调脚本准备；示例测试负责人于下周三前确认环境可用；示例项目负责人于下周五前给出上线时间结论。 |
| 待确认事项 | 对账口径是否沿用上一版本，需业务方负责人在下周一前确认。 |
| AI扩写说明 | 结论摘要与关键进展由AI根据上述事实扩写，数字与结论经人工核对。 |
对比AI扩写前后的差异可以看出边界：填写人先写下“下单和回调开发完了，自测过了；对账做了七成，等联调数据”这类口语记录，AI将其改写为“支付下单与回调两个工作项已完成开发并自测通过；对账工作项完成70%，剩余部分待联调数据”，表述更完整但事实未变。结论摘要同样如此，AI把三条要点压缩成短句，而“上线时间暂按原计划”这一判断由填写人确认后才保留。数字部分全程由人从缺陷记录中摘取并核对，AI没有参与生成。
当报告的数据与进展来自工作项、迭代和文档时，草稿的填写可以更省力。ONES Assistant 能理解项目、工作项、迭代和 Wiki 页面等上下文，并可根据当前迭代生成项目周报保存到 Wiki；团队把工作项状态和文档记录维护在日常协作中，报告草稿的事实与数据字段就有了可追溯的来源，AI扩写也建立在真实上下文之上，减少反复补充背景的环节。
模板的调整与维护方法
模板用久了容易出现两种问题：字段只增不减，填表负担越来越重；或者长期不更新，与实际报告需求脱节。维护的核心是给字段的进出设定判断标准，并留下变更记录。
- 新增字段的判断：连续两个以上报告周期出现“现有字段装不下”的情况，且该信息影响读者决策，才考虑新增；只出现一次的临时需求，先写在待确认事项或备注中。
- 合并字段的判断：两个字段长期由同一人填写、内容高度重叠，或读者反馈“看一处就够”，可以合并，合并后保留更具体的字段名。
- 删除字段的判断：连续三个周期该字段为空或只写“无”，且没有读者引用，可以删除；删除前确认没有下游流程依赖该字段。
- 版本与变更记录：模板文件标注版本号与生效日期，每次变更记录“改了什么、为什么改、影响哪些报告类型”，旧版本保留可查，避免历史报告口径无法对照。
- 定期复盘检查点：每季度或每完成一轮报告周期后，抽查若干份成稿，检查必填字段是否齐全、AI扩写说明是否填写、数据与证据是否可回溯、读者是否提出过字段相关的疑问，据此决定下一版调整。
维护时还要注意模板与填写规范的同步：字段名一旦调整，字段说明表、必填选填对照表和示例都要一起更新，否则新成员会按旧口径填写。把模板文件、字段说明和一份最新示例放在同一位置管理，变更时同步修订，能让模板在团队中稳定使用，而不是每次换人就要重新解释一遍。
常见问题
模板里的AI提示词栏位，正式成稿时要不要保留？
建议不保留。AI提示词栏位是填写阶段的辅助工具，用来记录该行事实交给AI时使用的指令，方便复核哪些内容由AI扩写。正式成稿前删除提示列与示例占位列，只留字段名与内容，报告会更干净。若团队需要留痕，可把提示词记录移到单独的“AI扩写说明”字段或内部备注中，不放进对外报告正文。
同一份模板能同时用于周报和复盘报告吗？
可以共用字段名，但内容口径要调整。周报侧重本周进展与下周行动，字段保持轻量；复盘报告的重心转向原因与改进，可把“关键进展”按“关键过程与结果”填写，把“风险与依赖”按“问题与原因”填写，把“下一步行动”按“改进措施”填写。保留字段名不变、只改内容口径，历史报告之间仍可对照；如果两类报告差异过大，也可以维护两个版本，但需在版本记录中注明适用场景。
AI扩写后数字对不上，应该怎么排查？
先回到“数据与证据”字段逐条核对：每个数字是否带口径、时间与来源，来源能否在系统或文档中找到对应记录。常见原因是填写人给AI的输入本身口径不一致，或AI在改写时把约数写成了确定值。处理办法是让AI只改写表述、不接触数字，数字由人从原始记录摘取后直接填入；扩写完成后逐条回查，确认无误再定稿。若发现来源缺失，先补来源，再讨论数字是否成立。
团队多人填写同一模板，怎么保证口径一致？
把模板文件、字段说明表和一份最新填写示例放在同一位置管理，新成员按示例对照填写。字段名一旦调整，三处同步更新，避免有人按旧口径填写。可以在每轮报告周期后抽查若干份成稿，检查必填字段是否齐全、数据是否可回溯、读者是否提出过字段相关疑问，把共性问题写进下一版字段说明。口径分歧较大的字段，在说明表中补一条正例和一条反例，比口头解释更有效。
报告草稿的数据来自工作项和文档时，有什么省力的做法？
把工作项状态、迭代进展和文档记录维护在日常协作中，填写草稿时直接引用，减少临时翻找和补充背景。ONES Assistant 能理解项目、工作项、迭代和 Wiki 页面等上下文，并可根据当前迭代生成项目周报保存到 Wiki，报告草稿的事实与数据字段因此有可追溯的来源。需要说明的是，模板字段结构与填写口径仍由团队自行确定，AI生成的内容需按本文的边界人工核对数字与结论。
