AI生成的周报适合作为初稿，发布前仍需人工核对。核对分两条线：数据线把周报里的每个数字回溯到工作项、版本、缺陷或工时记录，逐项比对口径与截止时间；风险线把每条风险判断还原成事实依据，确认触发条件、影响范围、责任人和应对动作是否成立。两条线核对完成并由项目负责人确认后，再对外发布。下文按准备、数据核对、风险核对、角色分工、示例和发布检查的顺序展开。
要点总览（TL;DR）
- AI生成的周报只作为初稿，发布前要分数据线和风险线两条路径核对，核对完成并由项目负责人确认后再对外发布。
- 核对前先写一页核对说明，固定统计周期、数据截止时点、纳入统计的项目与版本范围，以及数据核对人和风险复核人。
- 数据核对按进度、完成项、缺陷、工时、里程碑五类字段拆分，每个数字标注来源与查询条件，差异区分口径差异与真实错误。
- 风险核对把风险句拆成事实、推断、建议三层，事实层必须能对应到工作项、缺陷或延期记录，等级调整要写明理由。
- 发布前逐项检查数字可回溯、风险有依据、口径已注明、责任人已确认，任一项未通过就回到对应步骤修正。
核对前先做三件事：定口径、定范围、定责任人
核对能否顺利进行，取决于开始比对之前有没有统一基准。AI生成周报时依据的是它读取到的数据和提示词，同一句话在不同统计口径下可能得出不同数字。因此先写一份简短的核对说明，把下面三项固定下来，再进入逐项比对。
定口径：统计周期与数据截止时点
写明周报覆盖的起止日期，以及数据截止到哪一天、哪一刻。例如“本周一 00:00 至周五 18:00，数据截止周五 18:00”。截止时点之后发生的工作项状态变更、缺陷关闭、工时补录，都不计入本期周报。如果周报中引用了累计数据（如项目总进度），要单独注明累计口径的起始时间。
定范围：纳入统计的项目、版本与工作项
列出本期纳入统计的项目和版本，说明哪些工作项类型计入完成项（需求、任务、缺陷是否分开统计），哪些状态视为“已完成”，哪些属于本期新增、哪些是上期结转。范围写清楚，后续发现数字对不上时才能判断是口径差异还是记录错误。
定责任人：数据核对人与风险复核人
指定两名角色：数据核对人负责数字回溯，通常由熟悉工作项和工时记录的项目成员或 PMO 担任；风险复核人负责判断依据，通常由项目负责人或技术负责人担任。两人可以是同一人，但职责要分开写，避免“都看过、都没细看”。
完成标志：形成一页核对说明，包含统计周期、数据截止时点、纳入范围、两名责任人姓名，随周报初稿一起流转。
数据核对：把每个数字回溯到原始记录
数据核对的目标是让周报中每个数字都能回答“这个数从哪来、按什么条件查的”。做法是按字段拆分，逐项回溯，把差异归类后给出处理结论。
按字段拆分周报中的数字
把周报里的数字分成五类，分别核对：
- 进度类：整体完成百分比、各阶段完成情况、计划与实际偏差；
- 完成项类：本期完成的需求数、任务数、关闭的缺陷数；
- 缺陷类：新增缺陷数、修复数、遗留数、按严重程度分布；
- 工时类：计划工时、实际投入工时、人均投入；
- 里程碑类：到期里程碑、延期里程碑、下一里程碑时间。
每个数字标注来源与查询条件
在核对表中为每个数字记录来源系统、查询对象和筛选条件，例如“来源：工作项列表；筛选：项目A、版本V2.3、状态=已完成、完成时间在本周期内”。查询条件写得越具体，复核人越容易独立重查。使用 ONES 这类研发管理平台时，工作项、迭代、缺陷和工时记录本身就在同一套系统中，周报数字可以直接回到对应列表和详情页比对；ONES Assistant 支持根据当前迭代生成项目周报并保存到 Wiki，核对时可以在 Wiki 中打开初稿，对照 Project 中的迭代与工作项记录逐项检查。
比对差异并区分口径差异与真实错误
发现周报值与原始记录值不一致时，先判断差异类型：
| 差异类型 | 典型表现 | 处理方式 |
|---|---|---|
| 口径差异 | 统计范围、截止时间、状态定义与核对说明不一致 | 统一口径后重算，或在周报中注明口径 |
| 真实错误 | 记录缺失、数值抄错、重复计数、漏计 | 以原始记录为准修正周报数字 |
| 无法回溯 | 找不到对应记录或查询条件不明 | 删除该数字，或标注“待确认”并说明原因 |
口径差异不要简单改成“原始记录的值”，而要回到核对说明确认哪个口径是本期约定的。真实错误修正后，在核对表中保留原值、修正值和原因，便于追溯。
完成标志：形成数据核对表，字段包括周报字段、周报值、原始记录值、来源与查询条件、差异原因、处理结论，每个数字都有对应行。
风险判断核对：从结论回到事实依据
AI生成的风险描述往往把事实、推断和建议写在一句话里，读起来顺，但难以判断哪部分有依据。核对时把每条风险句拆成三层，逐层验证。
拆成事实、推断、建议三层
以“由于接口联调延期，支付模块存在上线风险，建议增加测试资源”为例：事实层是“接口联调延期”，推断层是“支付模块存在上线风险”，建议层是“增加测试资源”。三层分开后，核对重点落在事实层是否有记录支撑，推断层的逻辑是否成立，建议层是否可执行。
核对事实层是否有记录支撑
事实层要能对应到具体工作项、缺陷、延期记录或会议结论。检查延期的工作项是否存在、计划完成时间是否确实已过、缺陷是否处于未关闭状态。找不到对应记录的事实描述，应删除或改为待确认，不能保留为确定结论。
检查风险等级与影响范围
风险等级被夸大时，会把正常波动写成严重风险；被遗漏时，则可能漏掉真正影响里程碑的问题。核对时问三个问题：影响的是单个任务还是整个里程碑；触发条件是已经发生还是可能发生；影响范围是否写明了受影响的模块、版本或交付节点。等级调整要在核对清单中写明理由。
确认责任人、应对动作与时间点
每条保留的风险都应有明确的责任人和应对动作，动作要具体到“谁在什么时间前完成什么”，例如“由后端负责人在下周三前完成接口联调并提交测试”。只有“加强关注”“持续跟进”这类表述的，补全为可检查的动作，或降级为观察项。
完成标志：形成风险核对清单，字段包括风险描述、事实依据（对应工作项或缺陷编号）、等级调整及理由、责任人、应对动作与时间点。
角色分工与交付物：谁核对、谁签字、谁发布
核对环节最容易出现的问题是责任悬空：AI生成了初稿，大家都看过，但没人对最终数字和结论负责。用一张对照表把角色、动作和交付物固定下来。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 项目负责人 | 对周报整体结论负责，确认风险等级与应对动作，签字后发布 | 签字确认记录 |
| 数据核对人 | 逐字段回溯数字，标注来源与查询条件，处理差异 | 数据核对表 |
| 风险复核人 | 验证风险事实依据，调整等级，补全责任人与动作 | 风险核对清单 |
| 周报撰写人或 AI 使用者 | 根据核对结论修改初稿，保留修改痕迹 | 修订后的周报 |
发布前留痕包括：核对说明、数据核对表、风险核对清单、修订后的周报，以及项目负责人的确认时间和确认方式（签字、邮件或系统审批记录）。留痕的作用是后续复盘时能回答“当时这个数字依据什么、谁确认的”。ONES 的 AI 能力基于平台权限体系执行知识问答和任务执行，输出过程可追踪、结果可审计，核对记录可以随 Wiki 页面一起留存，便于按项目和周期追溯。
示例：一份周报的核对过程
以下为演示情景，用于说明核对动作如何落地，数字与项目均为虚构。
进度数字的回溯与差异处理
周报初稿写“版本 V2.3 整体进度 78%，本期完成需求 12 个”。数据核对人按核对说明查询：项目 A、版本 V2.3、状态为已完成、完成时间在本周期内，得到完成需求 10 个；整体进度按已完成工作项点数计算为 72%。差异原因分别是：AI 将两个上周完成但本周才关闭的需求计入本期，属于口径差异；进度百分比使用了任务数而非点数，属于口径差异。处理结论：完成需求改为 10 个，进度改为 72%，并在周报脚注注明统计口径。
风险句的事实核对与等级调整
周报初稿写“支付模块存在严重上线风险”。风险复核人拆解后发现，事实层是“接口联调工作项延期 3 天”，推断层是“可能影响支付模块提测时间”，建议层缺失。核对记录显示该工作项已重新排期，新的完成时间仍早于提测节点。处理结论：风险等级由“严重”调整为“中”，影响范围限定为“支付模块提测时间”，补充责任人和应对动作“由后端负责人在本周五前完成联调并通知测试”。
核对后的修改点
修订后的周报共修改四处：完成需求数、整体进度、风险等级、风险描述与应对动作；新增两处脚注说明统计口径和数据截止时点。修改痕迹保留在 Wiki 页面历史中，项目负责人确认后发布。
完成检查：发布前的核对清单
发布前逐项检查，每项都能给出明确的是或否，避免带错发布。
- 周报中每个数字都能在数据核对表中找到对应行，且标注了来源与查询条件；
- 所有差异已归类为口径差异或真实错误，并完成修正或注明；
- 无法回溯的数字已删除或标注“待确认”，没有以确定语气保留；
- 每条风险都有事实依据，能对应到具体工作项、缺陷或延期记录；
- 风险等级与影响范围经过复核，调整理由已记录；
- 每条风险都有明确责任人和可检查的应对动作及时间点；
- 周报正文注明了统计周期、数据截止时点和关键统计口径；
- 数据核对人、风险复核人已完成核对并留下记录；
- 项目负责人已确认整体结论，确认时间与方式已留痕；
- 修订后的周报与核对记录一并归档，可随时追溯。
以上检查全部通过，周报才进入发布环节。若某项未通过，回到对应核对步骤处理，不以“下次注意”代替修正。
常见问题
周报里的数字和系统记录对不上，先改数字还是先查口径？
先查口径。多数不一致来自统计范围、截止时间或状态定义不同，例如把上周完成、本周才关闭的工作项计入本期，或进度按任务数而非点数计算。回到核对说明确认本期约定的口径，再决定是重算周报值还是修正原始记录引用。确认属于记录缺失、抄错、重复计数的真实错误后，才以原始记录为准修改周报数字，并在核对表中保留原值和修正原因。
AI写的风险描述读起来合理但找不到对应记录，怎么处理？
把这条风险句拆成事实、推断、建议三层，重点看事实层能否对应到具体工作项、缺陷或延期记录。找不到支撑的事实描述，删除或改为“待确认”，不要以确定语气保留。如果事实成立但推断层跳跃过大，例如由单个任务延期直接推出整个版本上线风险，应缩小影响范围并调整风险等级，在核对清单中写明调整理由。
核对工作一定要两个人分别负责数据和风险吗？
可以由同一人兼任，但职责要分开写清楚，分别产出数据核对表和风险核对清单。数据核对偏重逐字段回溯和查询条件比对，风险复核偏重事实依据验证和等级判断，两类工作的检查点不同。团队规模较小时由项目负责人兼任风险复核、项目成员负责数据核对即可；关键是发布前有明确的确认人，并留下确认时间和方式。
核对记录需要保留到什么程度，后续复盘才用得上？
至少保留四类材料：核对说明（统计周期、截止时点、纳入范围、责任人）、数据核对表（含来源与查询条件、差异原因、处理结论）、风险核对清单（含事实依据、等级调整理由、责任人与动作）、修订后的周报及负责人确认记录。保留原值与修正值，后续复盘才能回答“当时这个数字依据什么、谁确认的”。使用 ONES 时，周报初稿和核对记录可以随 Wiki 页面留存，按项目和周期追溯。
周报中引用了累计数据，核对时要注意什么？
累计数据要单独注明起始时间和计算方式，例如项目总进度是从立项起算还是从当前版本起算。核对时不能只比对本期增量，还要确认累计口径与上期周报是否一致，避免因口径切换造成进度跳变。如果本期调整了累计口径，应在周报中说明调整原因和影响，并在核对表中记录新旧口径的差异。
