项目周报写不好，通常不是没干活，而是不知道哪些该写进周报。做了十件事，只有三件跟项目目标有关，写进去反而让管理者看不清楚当前状态。反过来，如果每周只写一句”本周持续推进”，团队倒是不累，但项目经理拿着这份周报没法做任何判断：项目还能按时交付吗？哪个里程碑已经偏了？下周要做什么决策？
这份教程从一个真实项目开始——CRM迁移项目——从第一周周报写到验收、再到复盘，看一份周报怎么在项目生命周期里不断演变。
先给结论：一份能决策的周报长什么样
先把结论放在前面，再展开怎么做到的。下面是一份CRM迁移项目第二周的周报摘要：
总体状态：黄。字段确认已完成，但接口文档晚2天，核心测试开始时间由周三顺延至周五；新增历史备注字段尚未完成影响评估。
本周交付：完成字段映射表并由业务负责人确认；完成20条脱敏样本导入，其中18条通过、2条因手机号格式失败。
当前问题：手机号格式不统一。数据负责人7月23日前补充清洗规则并重新导入失败样本。
待决策：是否把历史备注字段纳入本期。产品负责人需在7月23日中午前确认，否则按原范围进入测试。
下周计划：完成核心流程测试、修复失败样本并输出业务验收清单。
这份摘要没有用”进展顺利”掩盖接口延期，也没有把新增字段直接当作确定需求。管理者1分钟内就能判断项目偏离目标的方向和程度。现在回头看看，这份周报是怎么从零散记录里整理出来的。
第一周：从零散记录到结构化周报
CRM迁移项目开始第一周，团队群里的记录是这样的：
- 客户字段已确认
- 接口文档原定周二交付，实际周四收到
- 已完成20条样本导入，发现2条手机号格式错误
- 核心测试尚未开始
- 业务方要求新增历史备注字段
这些记录本身没问题，但直接当成周报发出去，管理者看不出来”接口文档晚两天”对整体进度有什么影响，也看不出来”新增字段”是确定需求还是待讨论。这时候需要一个能把这些零散信息组织成项目状态、里程碑、风险和下周计划的提示词。
把下面7类事实——项目目标、里程碑计划、本周实际进展、交付证据、风险与问题、待决策事项、下周可用资源——整理好，输入以下提示词：
你是一名项目周报整理助理。请根据我提供的真实项目计划和本周记录，生成一份管理者可以快速判断状态、团队可以据此执行的项目周报。不要编造完成度、日期、责任人、测试结果或原因。 项目名称：CRM迁移项目 项目目标与验收标准：完成客户数据从旧系统迁移至新CRM，2000条客户记录完整迁移并通过业务抽检 本周周期：2025年7月14日至7月18日 里程碑计划：字段确认（7月14日已完成）、接口文档（7月15日）、测试（7月16日-7月18日） 本周实际记录：[粘贴任务、会议、测试和交付记录] 风险清单：核心测试尚未开始，测试时间被压缩 问题清单：接口文档晚2天交付；新增历史备注字段尚未评估 待决策事项：是否把历史备注字段纳入本期（产品负责人，7月23日中午前） 下周资源与限制：测试环境可用，业务方需在7月23日前确认字段规则 请输出： 1. 总体状态：绿/黄/红，并用不超过3条事实说明依据 2. 里程碑表：计划日期、当前状态、实际结果、偏差、原因证据、恢复动作 3. 本周完成：交付物、完成标准、验收人或验证证据 4. 风险与问题：分开列出影响、责任人、下一动作和截止时间 5. 待决策事项：背景、可选方案、影响、建议决策人和最晚日期 6. 下周计划：动作、负责人、完成时间、预期输出和依赖 7. 信息缺口：资料不足、状态冲突和需要确认的数字
AI输出的周报就是开头看到的摘要。注意几个关键规则：完成度必须有证据，没有证据时写”待确认”；计划与实际不一致时同时保留，不得只展示较好的一方；每个下周动作必须有负责人、日期和可观察输出。这些规则写在提示词里，比写在团队规范里更容易被执行。
项目周报和个人周报有一个根本区别：个人周报关注个人完成事项，项目周报关注共同目标和交付结果。同一个成员完成了十项工作，如果关键接口仍未交付，项目状态就不能写成正常。建议先用聊天记录转待办清单提示词整理零散进展，再用项目风险清单提示词区分尚未发生的风险与已经发生的问题。
第二周：风险变成问题，周报怎么跟进
到了第二周，上周的”风险——核心测试尚未开始”变成了”问题——测试发现手机号格式不统一，首次导入86条记录失败”。这个变化必须反映在周报里。
很多项目周报的问题在于把风险、问题和待决策事项混在一起写。比如”存在数据格式问题，需要业务确认”——这句话既没有说这是已经发生的问题还是可能发生的风险，也没有说清楚谁在什么时间前确认什么。
正确的做法是严格区分三类事项：
- 风险：尚未发生的可能事件，写清影响范围、当前动作和责任人
- 问题：已经发生的事件，需要处理、有证据、有截止时间
- 待决策：需要谁在什么时间前决定什么，有选项、有影响说明
CRM迁移项目第二周，周报里同时出现了这三类：风险——测试环境可能在7月25日被其他项目占用，需提前确认资源分配；问题——手机号格式不统一导致86条记录导入失败，数据负责人7月23日前补充清洗规则；待决策——是否把历史备注字段纳入本期，产品负责人7月23日中午前确认。
一旦出现范围、日期、成本或验收标准变化，应建立需求变更单并保留影响评估和审批结论。周报只保留管理者需要判断的摘要，不应替代明细记录。障碍已经发生就进入项目问题清单，写清证据、责任人、截止时间和关闭标准。下一期周报再同步两类记录的最新状态。需要计算指标偏差时，可使用AI数据分析报告提示词区分事实和原因假设。
验收阶段：从周报延伸到验收清单
项目经过几周迭代，核心功能开发完成，进入验收阶段。这时候周报里反复提到的”业务验收清单”变成了当前阶段的核心交付物。项目”做完了”不等于”验收通过”——做完表示执行团队认为工作已经结束，验收通过表示交付物满足事先确认的范围和标准，并且有证据、有验收人、有结论。
最常见的验收争议不是功能完全不可用，而是双方对”本次应该交付什么”理解不同。验收前先收集批准后的需求、合同范围、里程碑和所有需求变更单，形成唯一范围基线。未经批准的口头新增要求应单独记录，不能直接混入本次验收标准。
项目验收清单需要以下输入：批准范围、交付物清单、验收标准、测试证据、缺陷台账、遗留事项、验收角色和结论规则。把这些信息交给AI，用以下提示词生成验收清单：
你是一名项目验收资料整理助理。请根据我提供的已批准范围、交付物、验收标准、测试记录和缺陷台账，生成一份可以逐项核对并留痕的项目验收清单。不要编造测试结果、交付版本、缺陷状态、签字人或验收结论。 项目名称：CRM迁移项目 验收阶段与日期：2025年8月1日 批准范围与不包含范围：[粘贴已批准的需求和变更记录] 交付物清单：字段映射表、客户数据导入脚本、20条脱敏样本导入记录 验收标准：2000条客户记录完整迁移、字段映射准确率100%、业务抽检通过率≥99% 测试记录与证据：[粘贴测试用例、结果和截图] 缺陷台账：手机号格式不统一——已修复，复验通过 验收角色：交付人（开发团队）、验证人（数据负责人）、批准人（项目经理）、接收人（业务负责人） 结论规则：[如有] 请输出： 1. 验收概览：范围基线、验收环境、参与角色和建议结论 2. 交付物清单：名称、版本、位置、完整性、接收人和核对结果 3. 验收项目表：需求编号、验收标准、操作步骤、预期结果、实际结果、证据位置和状态 4. 数据与权限检查：数据完整性、权限边界、备份、账号交接和隐私处理 5. 缺陷与遗留事项：严重程度、影响、临时方案、负责人、修复日期和复验方式 6. 结论建议：通过、有条件通过或不通过，并列出事实依据 7. 签字区：交付方、验收方、日期、意见和附件位置的空白字段 8. 待确认问题：标准不明确、证据缺失、范围冲突和需要专业人员判断的内容
举个例子：客服FAQ知识库项目验收时，批准范围是整理最近90天客服咨询，交付120条FAQ。验收记录显示120条中114条字段完整，4条缺少政策来源，2条帮助链接无法打开。抽检20条，18条可根据现行政策直接使用，2条退款时限与最新政策不一致。这时不能直接写”全部完成”，更可靠的结论是”有条件通过”：知识库数量和分类范围满足要求，但6条资料不完整，其中2条涉及退款时限，发布前必须修正。
三种验收结论必须写清边界：通过——批准范围内的标准全部满足，证据完整，没有阻断使用的缺陷；有条件通过——核心目标满足，遗留问题不阻断当前使用，并已有负责人、日期和复验方式；不通过——关键范围未交付、标准无法验证、存在严重缺陷，或证据不足以证明结果。已经发现的问题应进入项目问题清单持续跟踪；验收前仍可能发生的风险，应保留在项目风险清单，不能为了结项直接删除。
项目结束：从周报串起项目复盘
CRM迁移项目验收通过后，下一件事不是直接开新项目，而是做一次完整的项目复盘。项目复盘报告不是在项目结束后写一篇”大家都很努力”的总结，也不是找一个人解释为什么延期。真正有用的复盘要回答五个问题：原目标是什么、实际结果是什么、偏差造成了什么影响、哪些原因已经被证据验证、下一轮要改变什么动作。
项目周报和项目复盘有本质区别：周报用于同步当前状态和下一周动作，复盘报告用于在一个阶段结束后总结机制性经验。周报里写”接口文档晚两天”，复盘还要继续追问：原计划依据是什么、延期从什么时候可见、为什么没有提前处理、以后用什么信号更早发现。
生成复盘前需要准备8类材料：项目目标、基准计划、实际结果、变更记录、问题与风险、关键决策、成员反馈和约束条件。把连续几期的周报作为事实输入，结合以下提示词生成复盘报告：
你是一名项目复盘整理助理。请根据我提供的项目目标、计划、实际结果和证据，生成一份可供团队改进下一轮工作的项目复盘报告。不要编造日期、完成度、原因、责任人、业务收益或改进结果。 项目名称：CRM迁移项目 项目目标与验收标准：2000条客户数据完整迁移，业务抽检通过 原始计划与里程碑：字段确认（7月14日）、接口文档（7月15日）、测试（7月16日-18日）、验收（7月30日） 实际交付结果：8月2日验收通过，首次导入86条记录失败后修正 范围或资源变更：新增历史备注字段，经评估后纳入下一期 问题与风险记录：[粘贴各期周报中的问题清单和风险清单] 关键决策：是否将历史备注字段纳入本期——决定不纳入，产品负责人确认 成员反馈：[粘贴已脱敏反馈] 不可控约束：测试环境7月25日被其他项目占用，延期1天 请输出： 1. 复盘摘要：目标达成情况、最重要偏差、主要影响和下一轮重点 2. 目标对照表：目标、计划值、实际值、差额、证据位置和结论 3. 项目时间线：计划事件、实际事件、变化点和当时可获得的信息 4. 做得有效的事项：具体做法、产生结果、适用条件和保留方式 5. 未达预期事项：事实、影响、临时处理和仍未解决的问题 6. 根因分析：直接原因、机制原因、已验证证据和待验证假设 7. 改进行动表：动作、负责人、截止时间、预期输出、验证指标和复查日期 8. 需要沉淀的资产：SOP、模板、检查表、监控项或知识库更新 9. 待确认问题：资料冲突、缺少证据和必须由负责人判断的内容
数据迁移项目复盘的例子很说明问题：原计划7月30日完成2000条客户数据迁移并通过业务抽检，实际结果8月2日完成，首次导入有86条记录失败。不能直接写”数据同事准备不充分，导致项目延期”——这句话混合了现象、判断和责任，没有说明原计划是否包含数据检查，也没有证据证明延期只由一个人造成。
更可靠的复盘摘要应该这样写：偏差——验收比原计划晚3天，核心功能范围未变化；直接原因——首次导入的86条记录不符合手机号和日期格式规则；机制原因——计划中没有设置正式导入前的样本检查闸门，该结论由里程碑表和会议记录支持；待验证假设——字段规则在需求阶段没有被业务完整确认，需要核对原需求文档和确认记录；改进行动——下一次迁移前5个工作日，由数据负责人提供100条脱敏样本，业务负责人在2个工作日内签字确认字段规则，验证指标为正式导入首次失败率低于1%。
复盘结束后要把结论转成可复用资产：重复流程缺少检查点时，应更新SOP标准作业流程；团队需要固定汇报结构时，可更新项目模板；新发现的风险信号应进入风险清单。如果这是你第一次系统性使用AI辅助项目管理，建议先阅读AI入门指南了解基础方法。
AI写项目文档的三个失败边界
把三篇源文章的失败边界放在一起，可以看到AI在项目管理文档中的共同限制：
第一，AI不能替人判断。AI无法知道团队口头承诺是否有效，也不能判断延期是否可以接受。涉及范围、资源、预算、验收日期和对外承诺时，必须由项目负责人确认。AI无法确认成员陈述是否完整，也不能判断劳动关系、绩效和责任归属。
第二，AI不能代替实际操作。AI无法实际操作系统、测量性能、确认数据完整，也不能代替客户、业务负责人或质量负责人签字。涉及生产环境、付款节点、隐私数据和安全测试时，必须由具备权限和专业能力的人执行。
第三，AI不能凭空生成证据。只提供最终结果而没有原计划时，无法计算真实偏差。”五个为什么”只是追问方法，不代表第五个答案就是真正根因。涉及财务损失、合同违约、安全事故和隐私事件时，应由对应专业负责人参与复盘。
每次使用AI生成项目管理文档后，建议做一个人工核验清单：抽查每个”已完成”是否存在交付物或验收记录；确认红黄绿状态使用了团队统一标准；检查计划日期、实际日期和周报周期是否一致；确认风险、问题和待决策事项没有混为一谈；将下周动作导入任务系统后，检查负责人和日期是否完整。验收完成后，验收结论、遗留事项和附件位置应同时归档，并同步到项目周报或结项记录，确保后续人员知道项目真实状态。