AI生成的项目周报在发出前，人工复核应覆盖四类内容：事实与数据是否与系统记录一致，进度与里程碑表述是否准确，风险与结论是否有依据，对外表述与敏感信息是否合规。复核以可核验的证据为准，数据字段逐项对数，判断类内容由责任人确认。建议按“先对数、再看表述、最后查口径”的顺序推进，任一阻断项未通过，周报不发出。
要点总览（TL;DR）
- AI生成的项目周报发出前，人工复核按“先对数、再看表述、最后查口径”的顺序推进，覆盖事实数据、进度风险、结论依据、对外合规四类内容。
- 复核按角色分工：数据提供人核对量化字段与标识信息，项目负责人确认里程碑、风险与结论，文档复核人把关敏感信息、格式与收件范围。
- 数据类字段以源系统记录为唯一依据，AI输出只作待核对草稿；源系统中找不到对应记录的数字应删除或标注待确认。
- 数据错误、风险漏报或弱化、敏感信息外泄、里程碑状态明显不符、结论缺乏依据属于阻断项，未修复不发出；措辞与格式细节可记录为观察项后放行。
- 放行由文档复核人留下书面结论与确认时间，退回重生成或人工改写后需对改动部分做二次复核。
谁在什么时点复核这份周报
复核不是一个人从头看到尾，而是按内容性质分给三类角色，各自对自己能提供证据的部分负责。角色不清时，最容易出现“都看过了、但没人对数”的情况。
| 角色 | 负责范围 | 复核时点 | 产出 |
|---|---|---|---|
| 数据提供人 | 任务完成数、工时、缺陷数、版本号、负责人姓名等可对数的事实字段 | 周报生成后第一时间，通常为发出前一个工作日 | 数据核对结论，标注差异项与正确值 |
| 项目负责人 | 里程碑状态、延期说明、风险与阻塞项、结论与建议 | 数据核对完成后，发出前半天 | 判断类内容的确认意见，补充遗漏风险 |
| 文档复核人 | 格式模板、对外口径、敏感信息、署名与收件范围 | 前两轮完成后，发出前最后一道 | 放行或退回结论，记录复核留痕 |
时间安排上，建议在周报固定发出时点前预留一个完整工作日作为复核窗口。数据提供人先完成对数，项目负责人再确认判断类内容，文档复核人最后把关口径与格式。若周报在临近下班时才生成，复核容易被压缩成快速浏览，此时宁可顺延发出，也不要用未核对的版本占位。
复核结果按三种状态记录：通过、修改后通过、退回重生成。修改后通过需注明改了哪几处；退回重生成需写明退回原因，例如数据源缺失或统计周期错误，便于下一期避免同类问题。
第一轮：数据与事实核对清单
这一轮只处理能对数的内容，不讨论措辞好坏。AI生成周报时，量化字段和标识信息是最容易与源系统产生偏差的部分，逐项核对比通读全文更可靠。
| 检查项 | 通过标准 | 证据来源 | 负责人 |
|---|---|---|---|
| 任务完成数、进行中数量 | 与项目管理系统当前状态一致，差异为零或有说明 | 工作项列表按状态筛选 | 数据提供人 |
| 工时投入 | 统计周期内工时合计与工时记录一致，单位统一为小时或人天 | 工时报表 | 数据提供人 |
| 缺陷数与缺陷分布 | 新增、关闭、遗留数量与缺陷管理系统一致，按严重程度分布可复算 | 缺陷列表与统计视图 | 数据提供人 |
| 日期与版本号 | 迭代起止日期、发布版本号与迭代配置一致 | 迭代设置页 | 数据提供人 |
| 负责人姓名与角色 | 姓名拼写正确，角色与当前分工一致，无已离项人员 | 项目成员列表 | 数据提供人 |
| 引用事项真实性 | 周报提到的每个任务、缺陷、文档均真实存在，状态为最新 | 逐条打开对应条目核对 | 数据提供人 |
| 统计口径一致性 | 统计周期、单位、去重规则与上期周报相同，口径变化有注明 | 上期周报与本期统计说明 | 数据提供人 |
核对时以源系统记录为唯一依据，AI输出只作为待核对的草稿。遇到源系统中找不到对应记录的数字，处理方式是删除或标注“待确认”，不保留原数字再补解释。统计口径尤其需要留意：同一指标如果这期按自然周、上期按迭代周期统计，数字本身没错，但对比结论会失真，应在周报中注明口径变化。
第二轮：进度、风险与结论的表述复核
数据对上之后，进入判断类内容的复核。这一轮的重点是AI有没有把“看起来正常”写成“确实正常”，以及结论是否有事实支撑。判断类内容由项目负责人确认，文档复核人不替代业务判断。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 里程碑状态 | 每个里程碑的完成、进行中、延期状态与实际进度相符，延期项有原因说明 | 里程碑计划与实际完成记录 | 项目负责人 |
| 延期说明 | 延期天数、影响范围、补救措施具体，未用“略有延迟”等模糊表述带过 | 迭代燃尽图与变更记录 | 项目负责人 |
| 风险与阻塞项完整性 | 团队已知风险均已列入，无漏报；风险描述包含触发条件与影响 | 风险登记表、站会记录 | 项目负责人 |
| 风险表述强度 | 高风险未被弱化为“需关注”，低风险未被夸大为阻塞 | 风险等级评定记录 | 项目负责人 |
| 结论与建议的依据 | 每条结论能对应到具体数据或事项，无凭空推断 | 周报正文与源数据对照 | 项目负责人 |
| 责任归属表述 | 问题描述指向事项与流程，未写成对个人的评价 | 周报措辞通读 | 项目负责人 |
风险漏报和弱化是这一轮最需要警惕的问题。AI倾向于根据已有数据做归纳，对尚未记录在系统里的风险没有感知，因此项目负责人需要对照站会、群聊和口头沟通中提到的阻塞，确认周报是否覆盖。结论部分则逐条追问“这个判断是从哪个数字或哪件事推出来的”，推不出来的结论应删除或改为待确认事项。
第三轮：对外表述与合规检查
周报如果只在项目组内传阅，这一轮可以简化；一旦涉及跨部门、客户或管理层外发，信息边界和格式就需要单独把关。这一轮由文档复核人执行，重点不在内容对错，而在能不能发、发给谁。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 敏感信息 | 无不宜外发的客户名称、合同金额、未公开计划或人事信息 | 逐段通读，对照外发范围 | 文档复核人 |
| 数据权限 | 引用的数据均在收件人可见范围内，未摘录受限报表内容 | 权限配置与收件人名单比对 | 文档复核人 |
| 格式与模板字段 | 标题、周期、项目名称、必填字段齐全，与团队模板一致 | 团队周报模板 | 文档复核人 |
| 署名与发送范围 | 署名正确，收件人与抄送名单符合约定，无遗漏关键干系人 | 发送名单 | 文档复核人 |
外发场景下，建议把“是否包含客户可识别信息”作为固定检查项，而不是依赖临时判断。格式问题通常不阻断发出，但署名和收件范围错误会影响周报能否被正确的人看到，应与敏感信息一并作为发出前必须确认的项。
阻断项与放行条件
复核发现的问题分两类处理：阻断项必须修复后才能发出，观察项记录后可随周报放行并在后续跟踪。分类标准提前约定，可以避免每次复核都临时争论某个问题算不算严重。
阻断项包括：量化数据与源系统不一致且未更正；已知风险漏报或被明显弱化；包含不宜外发的敏感信息；里程碑状态与实际进度明显不符；结论缺乏事实依据且可能误导决策。观察项包括：措辞可优化、格式细节偏差、非关键字段表述不够具体、可补充的背景说明。
放行由文档复核人做最终确认，确认方式是在周报文档上留下复核结论和确认时间，避免口头放行。退回重生成或人工改写后，改动部分需要二次复核，重点核对改动是否引入新的数据错误或表述偏差；只复核一次即放行的做法，在改写幅度较大时容易留下盲区。
把复核清单落到协作流程里
清单只有嵌进日常协作流程才会被真正执行。可以把复核动作拆成带截止时间的工作项，指派到对应角色，让复核状态和周报发布状态联动。
具体做法上，周报生成后创建一条“周报复核”工作项，按数据核对、表述复核、合规检查拆成子任务，分别指派给数据提供人、项目负责人和文档复核人，截止时间设在发出前。周报文档与本期迭代、风险条目建立关联，复核人打开文档即可跳转到源数据核对，减少在多个系统间来回查找。
复核意见写在文档评论中，逐条对应检查项，形成可追溯记录；通过状态回写到周报发布流程，未完成复核的周报在流程上无法进入发送环节。ONES Assistant 支持根据当前迭代生成项目周报并保存到 Wiki，也能基于项目、工作项、迭代和 Wiki 页面等真实工作上下文回答问题，复核人可以在同一套权限体系内完成对数与确认，输出过程可追踪。对于需要区分阻断项与观察项的团队，可以把阻断项设为工作项的必填结论字段，让放行判断有据可查，而不是停留在口头确认。
常见问题
周报在临近下班时才生成，复核时间不够怎么办？
建议顺延发出，不用未核对的版本占位。复核窗口通常需要预留一个完整工作日：数据提供人先完成对数，项目负责人再确认判断类内容，文档复核人最后把关口径与格式。时间被压缩时，可以只保留阻断项检查，即数据一致性、风险完整性、敏感信息和里程碑状态，把措辞优化、格式微调等观察项记录后随下期处理，但阻断项不能跳过。
AI生成的周报里有些数字在源系统中找不到对应记录，应该怎么处理？
以源系统记录为唯一依据。找不到对应记录的数字，处理方式是删除或标注“待确认”，不保留原数字再补解释。如果该数字属于关键指标，应作为阻断项处理，由数据提供人确认正确值后再发出；如果是背景性描述中的数字，可标注待确认并列入观察项跟踪。
只在项目组内传阅的周报，合规检查可以省略吗？
可以简化，但不宜完全省略。组内传阅时，敏感信息与数据权限的检查范围可以收窄，格式与模板字段仍建议快速核对。一旦周报涉及跨部门、客户或管理层外发，敏感信息、数据权限、署名与收件范围都需要单独把关，其中署名和收件范围错误会影响周报能否被正确的人看到，应与敏感信息一并作为发出前必须确认的项。
退回重生成后，改动幅度不大，还需要二次复核吗？
需要，重点核对改动部分是否引入新的数据错误或表述偏差。改写幅度较大时只复核一次容易留下盲区，二次复核的范围可以限定在改动段落及其引用的数据，不必全文重读。二次复核的结论同样要留痕，与首次复核记录放在一起，便于追溯。
复核任务怎样在ONES里指派和留痕？
可以把“周报复核”建成一条工作项，按数据核对、表述复核、合规检查拆成子任务，分别指派给对应角色并设截止时间。周报文档与本期迭代、风险条目建立关联，复核人打开文档即可跳转核对源数据；复核意见写在文档评论中逐条对应检查项，通过状态回写到发布流程。ONES Assistant 支持根据当前迭代生成项目周报并保存到 Wiki，也能基于项目、工作项、迭代和 Wiki 页面等真实工作上下文回答问题，复核可在同一套权限体系内完成，输出过程可追踪。
