AI生成的研发报告在例会前被发现结论与数据不符，处理顺序应是先冻结版本，再把结论拆成可核对的判断句，回到数据源重算口径与取数区间，用原始明细逐条验证。确认问题出在数据口径、取数范围、聚合逻辑还是生成表述后，再决定改数据或改结论，并在例会前完成一次独立复核与留痕。本文按症状界定、原因排查、修正处置、验证预防四步展开，适用于报告已生成、即将用于项目例会和决策的场景。
要点总览（TL;DR）
- 先冻结报告版本并留存原始数据快照，再把结论逐条拆成可核对的判断句，避免边改边乱。
- 按“口径—取数—聚合—生成”顺序排查：口径看时间区间与分母，取数看明细总数与抽查，聚合看均值中位数混用，生成看程度词与因果是否超出数据支持。
- 修正时先改数据再改结论：口径与取数问题重算指标并同步正文图表附录，表述问题加限定条件、补样本量、删无依据因果。
- 例会前由未参与生成的人员独立重算关键结论，并检查正文、图表、附录三者一致；把口径定义与数据截止时间写入附注。
先判断问题出在哪一层：症状与影响范围
发现结论与数据不符时，第一反应往往是直接改结论，但更稳妥的做法是先界定异常类型和影响面。同一份报告里，口径问题、取数问题和生成表述问题经常同时出现，如果混在一起改，容易改错地方，也说不清改了什么。
常见的症状有三类：同一指标在正文、图表、附录中前后不一致；结论方向与数据相反，例如数据下降而结论写增长；关键风险在数据中已有信号，报告中却没有出现。这三类症状指向的问题层级不同，需要分别记录。
问题来源可以按三层划分。数据层指原始数据缺失、重复或跨系统未对齐；口径层指统计区间、分母、去重规则不一致；生成层指AI在表述时放大了程度、误连了因果或省略了限定条件。先给每条异常标注疑似层级，再进入验证，能避免把口径问题当成结论问题处理。
报告用途决定修正深度。用于项目例会的报告，重点是把关键结论和支撑数据对齐，能当场解释差异；用于决策的报告，还需要补齐口径说明、样本范围和不确定性描述。时间窗口同样重要：例会前可用的时间有限，应优先处理影响决策判断的结论，其余标注待确认。
这一步的交付物是一份清单，至少包含：受影响结论原文、对应数据源、疑似问题层级、影响程度、计划验证方式。清单按结论逐条列，不按章节列，便于后续逐条闭环。
逐条排查：原因假设与排除证据
排查的核心是用证据区分假设，而不是凭经验下判断。建议按“口径—取数—聚合—生成”的顺序验证，因为前一层的问题会传导到后一层，先排除上游能减少无效排查。
假设一：统计口径不一致
重点核对时间区间、分母和去重规则。例如报告写“本月缺陷率下降”，需确认分子分母是否取自同一时间窗口，缺陷数是否按创建时间还是关闭时间统计，重复提交的缺陷是否去重。验证方法是找到口径定义文档或取数说明，用同一份原始数据按报告口径和标准口径各算一次，比较差异。若两次结果不同且差异能解释结论偏差，即可确认口径问题。
假设二：取数范围缺失或重复
重点核对是否漏项目、漏状态、跨系统未对齐。例如统计“全部迭代交付率”时只取了部分项目，或把已取消的工作项计入完成数。验证方法是导出取数明细，按项目、状态、时间逐项核对总数与报告总数是否一致，并抽查若干条记录回溯到源系统。总数对不上或抽查发现错漏，说明取数范围有问题。
假设三：聚合与计算逻辑偏差
重点核对均值与中位数、累计与当期的混用。例如用平均值描述交付周期，被少数长周期项目拉高；或把累计投入工时当作当期投入。验证方法是按不同聚合方式重算同一指标，观察结论方向是否改变。若换一种合理聚合方式结论就反转，说明原结论对聚合方式敏感，需要在报告中说明。
假设四：生成环节的表述放大或因果误连
当数据本身无误、口径也一致，但结论措辞超出数据支持范围时，问题在生成层。典型表现是把“相关”写成“导致”，把“部分样本”写成“整体趋势”，把“小幅波动”写成“显著改善”。验证方法是把结论句拆成主语、判断词和程度词，逐项对照数据能支持的范围；找不到支撑的程度词和因果连接，就标记为表述问题。
| 原因假设 | 验证证据 | 排除方法 |
|---|---|---|
| 统计口径不一致 | 口径定义文档、两种口径的重算结果 | 按标准口径重算后差异消失，则排除 |
| 取数范围缺失或重复 | 取数明细、总数核对、源系统抽查记录 | 明细总数与报告一致且抽查无误，则排除 |
| 聚合与计算逻辑偏差 | 不同聚合方式的重算结果 | 更换合理聚合方式后结论方向不变，则排除 |
| 生成表述放大或因果误连 | 结论句与数据支持范围的逐项对照 | 每个程度词和因果连接都有数据支撑，则排除 |
排查完成后，在对照表中标注“已排除”和“待确认”。待确认项要写明还缺什么证据、由谁补充，避免带着未验证的假设进入修正。
修正处置：改数据还是改结论
修正动作取决于排查结论：口径和取数问题要改数据并重算，表述问题要改结论措辞。两类修改的顺序是先修数据、再改结论，因为数据变化会影响结论的表述边界。
口径与取数问题的修正包括：统一时间区间、分母和去重规则；补齐遗漏的项目或状态数据；按修正后的口径重算受影响指标，并同步更新正文、图表和附录。重算后如果结论方向改变，需要重写结论句，而不是保留原句只换数字。
结论表述问题的修正包括：给结论加上适用条件，如时间范围、样本范围、统计口径；补充样本量，说明结论基于多少项目或多少条记录；删除没有数据支撑的因果表述，把“导致”改为“同期出现”或直接删除因果连接。修正后的结论应能被一条数据明细直接支撑。
修改过程要保留原始版本和修改记录。动手前先备份原报告和原始数据快照，记录修改人、修改时间、修改内容和修改依据。涉及覆盖原报告、批量改数等破坏性操作时，先确认备份可用，并设定停止点：一旦发现修改范围超出清单，暂停操作，重新核对影响面。
用于对外或决策的报告，修正后需由未参与生成和修改的人员确认。确认人重点看三件事：修改是否覆盖了清单上的全部受影响结论、修改依据是否可追溯、结论措辞是否与修正后的数据一致。确认通过后再定稿。
在团队协作层面，可以把受影响结论清单转为可追踪的工作项，把修正说明和复核意见沉淀在报告所在的知识库页面中。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能基于项目、工作项和 Wiki 页面等上下文回答问题并执行后续操作；ONES 基于自身权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计。这类能力适合承载“结论清单—修正记录—复核确认”的流转，具体配置方式以团队实际使用为准。
验证与复发预防：例会前怎么确认改对了
修正完成不等于可以上会。例会前至少完成两项验证：交叉复核和一致性检查。
交叉复核是换人按同一口径独立重算关键结论。复核人不看修正过程，只拿口径定义和原始数据重算，比较结果是否与修正后报告一致。关键结论建议全部复核，次要结论可抽查。复核人应独立于报告生成和修正环节，避免同一思路下的盲区被延续。
一致性检查是确认正文结论、图表、附录数据三者对齐。常见遗漏是正文改了数字、图表没更新，或附录口径说明还是旧版本。检查时以修正后的数据为准，逐项对照三处表述，发现不一致立即回改。
把口径定义、取数脚本或查询条件、数据截止时间写入报告附注，是防止下次争议的基础动作。附注不需要很长，但要能让另一位同事据此复现关键数字。附注模板可包含：指标名称、统计区间、分母定义、去重规则、数据来源系统、数据截止时间、取数人。
长期防复发可以建立生成后的人工复核清单，明确复核责任人和复核时点。清单至少覆盖：结论是否有数据支撑、程度词是否超出数据范围、因果表述是否有依据、正文图表附录是否一致、口径附注是否完整。复核时点建议设在报告定稿前和例会前各一次。
复发信号包括：同一指标再次出现前后不一致、结论方向与趋势图相反、新报告缺少口径附注、复核意见连续两次指向同类问题。出现这些信号时，应回查取数脚本和口径定义是否被改动，并把下次复核时点提前到报告生成后立即执行。
完成上述步骤后，报告可以带着修改说明和复核记录进入例会。会上如被问到结论依据，能直接指向数据明细和口径附注；会后再出现新的数据，也能按同一流程快速定位问题层级，而不必从头重来。
常见问题
报告已经用于例会并对外发出，事后才发现结论与数据不符，应该怎么补救？
先确认已发出的版本和影响范围，列出受影响的结论及对应的数据源，按“口径—取数—聚合—生成”顺序快速定位问题层级。对外版本应发布更正说明，写明原结论、修正后结论、差异原因和修正依据；内部同步更新报告版本并保留原版本备查。若涉及决策依据，建议在更正说明中附上关键数据明细和口径定义，便于接收方复核。
AI生成的报告里，结论和数据分别来自不同系统，复核时以哪个为准？
以能复现的原始数据为准，不以报告中的二次汇总为准。复核时先确认每个指标的数据来源系统和取数时间，再按报告口径从源系统重新取数计算。如果两个系统对同一指标的定义不同，需要在报告附注中说明采用哪个系统、为什么采用，以及差异对结论的影响。无法对齐的指标应标注待确认，不直接写入结论。
修正后结论方向变了，原来的图表和附录需要全部重做吗？
不需要全部重做，但受影响的部分必须同步更新。先按修正后的数据重算指标，再逐项检查正文结论、图表和附录三处是否一致。图表只需更新数据系列和标注，附录重点更新口径说明和数据截止时间。未受影响的章节可以保留，但应在修改记录中注明哪些部分未改动、依据是什么，避免复核时误判为遗漏。
团队没有专职数据人员，如何做独立复核？
独立复核的关键是换人、按同一口径重算，不要求专职岗位。可以安排未参与报告生成和修正的同事，拿着口径定义和原始数据，独立重算关键结论并比较结果。复核人只需关注三件事：重算结果是否与报告一致、结论措辞是否超出数据支持范围、正文图表附录是否对齐。复核记录写明复核人、复核时间和结论，附在报告修改说明中即可。
用ONES Assistant辅助生成报告时，如何让复核过程可追溯？
可以把受影响结论清单转为工作项，把修正说明和复核意见记录在报告所在的知识库页面中。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能基于项目、工作项和 Wiki 页面等上下文回答问题并执行后续操作；ONES 基于自身权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计。具体配置方式以团队实际使用为准。
