编写AI报告草稿的关键，是把“写”拆成可控的四步：先锁定报告对象、读者与结论口径，再准备事实输入，然后用结构化提示让AI按章节骨架生成初稿，最后由人逐项核对事实与结论。AI承担成文与改写，人负责事实与判断；草稿的完成标志是每个结论都能追溯到输入证据，可以直接进入评审。ONES可承载输入材料、待确认项与评审交接，本文围绕文档产出展开。
要点总览（TL;DR）
- 先把报告骨架定下来：读者是谁、一句话核心结论、章节清单和口径说明，再交给AI扩写。
- 输入按数据、进展、问题、证据四类整理，按章节归位并标注来源与时间，缺失项显式写“待补”。
- 提示包含角色、读者、章节骨架、输入材料、输出格式、字数六项要素，先生成提纲再逐章扩写。
- 初稿先核对事实再改写表达，重点查口径替换、时间错位、名称错误和结论超出证据。
- 送评审前逐项检查：结论可追溯、口径一致、待确认项已列出、章节完整、表达可用。
先定报告骨架：对象、读者与结论口径
在打开任何AI工具之前，先把报告骨架写出来。骨架决定了AI生成的内容是否可用，也决定了评审者能否快速判断报告是否回答了该回答的问题。骨架的产出物是一份简短的结构说明，包含四项：读者是谁、一句话核心结论、章节清单、口径说明。
读者决定详略和术语。写给部门负责人的周报，重点在结论、偏差和需要的支持；写给跨团队评审的专项报告，需要交代背景、方法和数据口径。同一份事实材料，面向不同读者时保留的细节不同，这一点要在骨架里写清楚，否则AI容易按通用模板铺陈。
先写一句话核心结论，再拆章节。核心结论是对“这份报告要回答什么问题”的直接回答，例如“本迭代核心功能按期交付，性能指标未达目标，需在下个迭代安排专项优化”。有了这句话，章节围绕支撑或解释它来组织，AI扩写时也不容易跑题。
章节骨架通常包含五块：背景与目标、进展与数据、问题与偏差、原因分析、下一步动作与责任人。不同报告类型可以增减，例如月度经营报告增加指标对比，项目复盘增加决策回顾。骨架里同时标注每章的口径说明，比如数据统计截止时间、指标定义、进展状态的判定标准。
需要区分两类内容：需求判断与风险判断属于专业分析工作，有各自的方法和责任人，不在本文展开。骨架中如果出现“评估某需求优先级”“判断某风险等级”这类章节，应明确标注由对应角色提供结论，AI只负责把已有结论写成文字。
准备事实输入：让AI有据可写
AI生成的内容质量取决于输入的事实密度。输入准备的目标，是让每一段生成文字背后都有可核对的事实，而不是让AI根据常识补全。输入材料按四类整理：数据、进展、问题、证据。
- 数据：指标数值、统计口径、统计时间范围、对比基准。每个数字注明来源系统或报表名称。
- 进展：已完成事项、进行中事项、状态变化，注明对应的工作项、版本或里程碑。
- 问题：已发生的问题、影响范围、当前处理状态、责任人。
- 证据：会议结论、评审记录、测试结果、客户反馈原文等可以支撑判断的材料。
输入按章节归位。骨架里每一章对应一组输入材料，整理时直接按章节分组，避免生成阶段再让AI自行分配。每条输入标注来源和时间，例如“数据来自迭代燃尽图，截至本周五”“问题来自周三评审会议纪要”。来源和时间是后续人工核对的主要依据。
缺失项显式标注为待补。某章缺少数据时，在输入清单里写“待补：性能测试结果，负责人张某，预计下周二提供”，不要留空让AI推测。AI对空白处的处理方式是补写合理内容，这类内容在评审时最难被发现，也最容易造成事实错误。
输入颗粒度到可核对的事实。“进展顺利”不是可核对的输入，“核心接口联调完成，剩余两个边缘场景待验证”才是。整理输入时把形容词换成动作和状态，AI生成时就有具体内容可写，人工核对时也有明确对象可比对。
核心操作步骤：用结构化提示生成初稿
提示的质量决定初稿的可用程度。一个可复用的报告草稿提示包含六项要素：角色、读者、章节骨架、输入材料、输出格式、字数要求。六项写全，AI的输出范围就被限定在可核对的区间内。
第一步，写提示。角色写“你是负责撰写项目进展报告的技术项目经理”，读者写“面向研发负责人和产品负责人”，骨架直接粘贴S1产出的章节清单，输入材料按章节粘贴S2的清单，输出格式写明“按章节输出，每章先给结论句再展开，数据和事实后用括号标注来源编号”，字数写明总量和每章大致篇幅。完成标志是提示中六项要素齐全，且输入材料与章节一一对应。
第二步，先生成提纲。让AI只输出各章的一句话要点和拟使用的事实编号，不展开正文。这一步的作用是检查AI对输入的理解是否与骨架一致，发现章节错位或事实误用时，改提示的成本远低于改全文。完成标志是提纲中每个要点都能对应到输入清单中的条目。
第三步，逐章扩写。确认提纲后，按章节分别要求AI扩写，每章生成后立即比对输入材料。逐章生成的好处是单章出错时影响范围可控，也便于不同章节由不同接口人先看一遍。要求AI在引用数据处保留来源位置标记，例如“（来源：迭代燃尽图）”，方便后续核对。
第四步，处理不确定内容。提示中明确要求：输入材料未覆盖的内容，标注“待确认”并说明缺什么，不得自行补写。生成后检查所有“待确认”标记，逐条转给对应责任人。完成标志是初稿中不存在无来源的事实陈述。
以下是一份可直接改用的提示模板：
| 要素 | 填写内容 |
|---|---|
| 角色 | 你是负责撰写〔报告类型〕的〔岗位〕，熟悉〔业务领域〕 |
| 读者 | 报告读者为〔角色〕，关注〔决策点〕 |
| 章节骨架 | 粘贴S1的章节清单与口径说明 |
| 输入材料 | 按章节粘贴S2的输入清单，保留来源与时间标注 |
| 输出格式 | 按章节输出；每章先结论后展开；事实后标注来源编号；未覆盖内容标注“待确认” |
| 字数 | 全文约〔N〕字，各章篇幅按〔比例或字数〕分配 |
角色与交付物分工
把成文和事实核对分开，是保证草稿质量的组织前提。四个角色各管一段，交接时点明确，避免出现“AI写完没人认账”的情况。
| 角色 | 职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 报告负责人 | 确定读者、核心结论与章节骨架，裁定口径争议 | 报告骨架与口径说明 | 输入整理开始前 |
| 数据与业务接口人 | 提供数据、进展、问题与证据，确认事实准确性 | 按章节归位的输入清单，含来源、时间、待补标记 | 提示编写前；初稿生成后复核本人负责章节 |
| 编写者 | 编写提示、执行分步生成、整理初稿格式 | 提示模板与首版初稿 | 初稿完成后交评审者 |
| 评审者 | 核对事实、口径与结论，判断是否可发布 | 带核对标记的评审意见 | 评审会上或评审截止日前 |
交接的关键在于输入清单和初稿都带着来源标记流转。接口人复核时对照自己提供的材料，评审者核对时对照输入清单，报告负责人只需处理口径争议和结论表述。在ONES中，输入材料可沉淀在Wiki页面，待确认项可转为工作项指派给责任人，评审意见随页面版本留存，交接过程有记录可查。
人工校对与改写：把初稿变成可评审稿
初稿生成后，人工处理分两轮：先核对事实，再改写表达。两轮分开做，避免边读边改导致核对遗漏。
第一轮逐条核对。数字、时间、名称、来源逐项与输入清单比对，重点检查三类高频错误：统计口径被替换（如把累计值写成当期值）、时间范围错位（如把上周数据写成本周）、名称不准确（如项目名、版本号、责任人写错）。每个结论追问一句“输入材料里哪条支撑它”，找不到支撑的结论要么补证据，要么删除或改为待确认。
第二轮统一表达。检查术语是否全文一致，同一对象在不同章节用同一名称；检查结论是否超出输入证据的范围，例如输入只说明“测试通过率下降”，初稿写成“质量明显恶化”就属于超出；删去“显著提升”“全面优化”这类没有具体对象的表述，换成动作和结果，例如“接口平均响应时间从320ms降至210ms”。
改写完成后，把仍需业务确认的段落集中标记，列成待确认清单，注明每项的责任人和确认时限。可评审稿的状态是：事实已核对、表达已统一、待确认项已列出且不影响主干结论。如果待确认项涉及核心结论，草稿应先回到报告负责人处定口径，再送评审。
示例：一份周度进展报告草稿的生成过程
以下为演示情景，用于说明各步骤的对应关系。
骨架。读者为研发负责人与产品负责人；核心结论为“本周核心功能开发完成，联调进度落后两天，需协调测试资源”；章节为背景、本周进展、数据、问题与偏差、下周计划。
输入归位。进展章输入“登录模块开发完成，订单模块完成80%，来源：工作项状态，截至周五”；数据章输入“本周关闭工作项23个，新增18个，来源：迭代报表”；问题章输入“联调环境不稳定，影响两天，责任人李某，来源：周四站会记录”；下周计划章输入“完成订单模块开发，启动集成测试”。
提示与生成。按S3模板填写六项要素，先生成提纲，确认“联调落后”对应问题章而非进展章，再逐章扩写。AI在数据章引用工作项数量时保留了来源标记，在问题章写出了影响范围，但对“需协调测试资源”只写了“建议关注资源”，未给出具体动作。
人工修改。核对时发现初稿把“关闭23个”写成“完成23个功能”，属于口径替换，改回工作项口径；把“建议关注资源”改为“申请测试工程师1名支援集成测试，责任人王某，下周三前确认”；在问题章补充联调环境不稳定的具体表现，来源为站会记录原文。修改原因集中在两类：事实口径和动作具体化。
可迁移的规律。骨架先行、输入带来源、逐章生成、核对口径与动作，这四点在月度报告、专项评审报告、复盘报告中同样适用，区别只在章节构成和读者关注点。
完成检查：草稿可以送评审的判断标准
送评审前逐项勾选，全部通过再提交。任何一项不通过，回到对应步骤处理。
| 检查项 | 通过标准 |
|---|---|
| 结论可追溯 | 每个结论都能在输入清单中找到对应证据，无来源的表述已删除或标为待确认 |
| 数据与时间口径一致 | 全文统计口径、时间范围、指标定义统一，与骨架中的口径说明一致 |
| 待确认项已列出 | 所有待确认内容集中成清单，含责任人、确认时限，且不涉及未定的核心结论 |
| 章节完整 | 骨架中的章节全部具备，读者可据此做出评审要求的决策 |
| 表达可用 | 术语统一，空泛表述已替换为具体动作与对象，格式与字数符合使用场景 |
这份检查表同时适用于人工撰写和AI辅助生成的草稿。AI参与后，检查重点前移到事实追溯和口径一致，因为成文速度和表达通顺度已不是主要瓶颈，事实错误和结论越界才是评审中最常被退回的问题。
常见问题
输入材料不齐时，是先让AI写还是先补材料？
先补关键材料，再生成草稿。判断标准是这份材料是否支撑核心结论：支撑核心结论的数据和证据缺失时，草稿写出来也要推翻重来；只影响次要章节的材料可以边写边补，但在输入清单里显式标注“待补”，写明缺什么、责任人是谁、预计何时提供。
把待补项直接交给AI猜测，生成的内容看起来完整，评审时却最难被发现，也最容易造成事实错误。草稿里保留“待确认”标记，比补一段看似合理的内容更安全。
AI生成的报告初稿，评审时最常被退回的问题是什么？
常见的有三类：一是口径被替换，例如把累计值写成当期值、把工作项数量写成功能数量；二是结论超出输入证据，输入只说“测试通过率下降”，初稿写成“质量明显恶化”；三是动作不具体，只写“建议关注资源”，没写申请什么资源、由谁负责、何时确认。
这三类问题都出在事实和判断层面，与文字是否通顺关系不大。核对时对每个结论追问一句“输入材料里哪条支撑它”，找不到支撑的就补证据、删除或改为待确认。
报告负责人和评审者的职责怎么区分？
报告负责人在生成之前定骨架：读者是谁、核心结论怎么表述、章节怎么构成、口径争议怎么裁定。评审者在初稿之后核对事实、口径与结论，判断这份报告能否发布或进入下一环节。
两者容易混淆的地方是结论表述。评审者可以指出某句结论超出证据，但结论怎么改、口径怎么定，仍由报告负责人裁定。待确认项如果涉及核心结论，草稿应先回到负责人处定口径，再送评审。
同一套提示模板能复用到月度报告、专项评审报告吗？
六项要素的结构可以复用，内容需要按报告类型调整。角色和读者随报告变化；章节骨架按报告类型增减，例如月度经营报告增加指标对比，项目复盘增加决策回顾；输入材料的四类划分不变，但每类具体条目不同；输出格式和字数按使用场景设定。
可迁移的规律是骨架先行、输入带来源、逐章生成、核对口径与动作这四点，区别只在章节构成和读者关注点。
在ONES中做AI报告草稿，输入材料和待确认项放在哪里？
输入材料可以沉淀在ONES Wiki页面，按章节组织并保留来源与时间；待确认项可以转为工作项指派给责任人，明确确认时限；评审意见随页面版本留存，交接过程有记录可查。ONES Assistant可结合项目、工作项、迭代和Wiki页面等上下文回答问题并执行后续操作，结果可保存为工作项或Wiki页面。
具体到报告骨架、字数与引用格式的可控程度，官网资料未作说明，实际使用时可先小范围试用确认。
