项目经理周报怎么写：进度正常也要说清三处风险

项目周报最常见的场景是这样的：三个里程碑全部按时完成，没有延期，没有事故，团队状态良好，项目经理把这四个字写进周报，发出去，然后开始准备下周，问题在于：「一切正常」这四个字，对老板没有任何决策价值，他看完不知道风险在哪，不知道要不要提前介入，也不知道如果下周开始出问题，现在有没有窗口处理。

项目经理周报的特殊性在于：它是唯一一份「坏消息比好消息更重要」的周报。进度正常只是及格线，风险披露才是交付物。

站内前面写过几篇讲通用周报怎么写的，一篇是 30 分钟用 AI 写完周报：从流水账到老板愿意看的四步法，一篇是 月报、季度总结别写成流水账：用 AI 理数据出结论的四步法，还有 运营周报怎么写 讲的是「数据涨了老板问原因」。「还没发生但可能发生的事」具体要写成什么样？

那几篇解决的共性是「把流水账改成有结论的文档」。项目经理岗多一个约束：不能只报已完成的事，还要报还没解决的隐患。

项目经理周报差在哪

判断项目周报写得对不对，有一个很省事的办法：把周报交给一个没参与这个项目的人看，问他「现在最可能出问题的是什么」。

如果他答不上来，那这份周报没写完，不管进度栏里有多少个「100%」。那这个「最可能出问题」的标准该怎么量化？

这个判据抓住了项目经理周报的本质：它的读者是需要在信息不全的情况下做判断的人。

老板不可能每天问项目进度，他要靠周报建立对项目的判断，所以周报里最重要的不是「我做了什么」，而是「现在什么最脆弱」，这和运营周报正好相反，运营周报的数字是结果，已经发生、无法更改；项目周报的核心信息是还没发生但可能发生的事，这些是唯一还来得及处理的对象。

所以项目周报应该固定成三段：进度怎么说、风险在哪、下周动什么。这三段里哪一段最容易被跳过？

第一段：进度怎么说，只说偏差不说百分比

第一段最常见的问题是堆百分比，「模块 A 完成 85%，模块 B 完成 60%」这种写法信息量很低，因为它把计划和实际混在了一起，而且 85% 这个数没有参照系，进度段真正要说的是偏差，而且要分三种情况说：

• 按计划：一句话带过，写清下个节点是什么、什么时候到
• 有偏差：说清差多少天、原因是什么、追赶方案是什么
• 已延期：说清延期多久、影响哪个下游、什么时候能补回来

第二种和第三种是重点，因为它们才是老板要动手的地方。

如果一个模块这周从 60% 变成 85%，不要只写「推进顺利」，要写清这 25% 里有多少是原计划内的、有多少是加班赶出来的，因为这个差别决定了下周的风险等级，按计划推进的项目下周按计划走就行，透支出来的进度下周会还债，那透支出来的进度要怎么写才不显得像在邀功？

第一段还有一个反直觉的写法建议：把下个里程碑放在这一段的开头。

老板关心的是「下一个要发生什么」，不是「上一个阶段完成了什么」。这个顺序调整不花时间，但能显著改变老板读周报的效率。

第二段：风险在哪，这是真正的交付物

第二段是项目周报里最值钱、也最容易被跳过的部分。

跳过它的写法通常长这样：「项目整体可控，无重大风险」。这句话等于没说，因为它把「有没有风险」和「我知道有哪些风险」混为一谈了。

合格的风险登记要满足三个条件。

第一，风险必须具体到能验证。

「技术风险较高」不是风险条目，「支付接口的限流策略还没拿到对方的书面确认，联调时间可能被压缩」才是，后者可以验证：书面确认拿没拿到，一问就知道。

第二，每条风险要写清楚它影响什么。

只写风险不写影响，老板没法判断要不要出手。「第三方 SDK 版本未定」是风险，「第三方 SDK 版本未定，可能导致两轮联调返工，压缩回归时间 3 天」是完整的风险条目。

第三，每条风险要写清楚应对状态。

已经有人跟进的、要上报决策的、还在观察的，三种状态要分开，混在一起写，老板不知道哪条需要他拍板，风险按这三个维度登记之后，还要按影响大小排序，排序这件事有个实用建议：影响面最大的三条放在周报正文，剩下的进附录，不要在周报里列 20 条风险，那等于没有优先级，那超过三条的应该怎么归？

第三段：下周动什么，要写到人

第三段决定周报有没有决策价值。

含糊的写法是「下周继续推进各模块开发」。这句话的每一个字都是正确的，但它不构成任何承诺，也无法被检验，合格的写法有两个特征。

第一，每条动作要有一个明确的人。

不是「开发继续推进」，而是「小王负责把支付接口的联调环境搭完，周三前可用」。

第二，每条动作要有一个可检验的完成标准，「优化性能」不可检验，「首屏加载时间降到 2 秒以内」可检验，这两条合起来，周报才从「报告」变成「承诺」，老板下周翻到这条的时候会直接问一句「首屏降到 2 秒了吗」，这一问就是项目管理的抓手。

项目经理周报有个特点：它同时是向上汇报和向下布置。

老板看的是风险和节点，团队看的是下周谁做什么。所以第三段写的时候要同时满足两方视角，篇幅上可以比前两段长，那如果本周确实什么都没风险、什么都在按计划走，第三段写什么？

这是最难处理的情况。正确答案是写前置条件：把「为了让计划继续成立，下周必须完成的三件事」写清楚。那「前置条件」和「本周风险」在写法上有什么区别？

比如「下周没有风险，但要保住进度，需要周三前拿到测试环境的账号，否则周三的联调安排要顺延」。

这样写等于把风险提前登记到下周，而不是等到出问题再解释。

三个最容易翻车的地方

一、把所有风险都写成「已解决」

项目经理周报有个很隐蔽的倾向：倾向于把风险写掉，因为写了风险就要负责，于是出现「已通过沟通解决」「已与相关方达成一致」这类表述，但下周同一个问题又出现，那要判断一条风险是不是真的消失了，问什么最快？

判断标准很简单：这条风险是真的消失了，还是只是没人再提？

如果上周写「测试环境不稳定」，本周写「已解决」，那要问一句：解决动作是什么，是谁做的，验证过几次。

写不出来就说明风险还在，只是被标记成了已解决，这类问题对项目的伤害比风险本身大，因为它会让团队形成「风险可以随便关闭」的判断。

二、把问题写成项目组的

项目周报里最没信息量的一句话是「沟通成本较高」。那把「沟通成本高」写具体，应该具体到什么程度？

这句话指向的是自己，没有指向任何可以改的东西，改成可指认的写法：「第三方对接涉及 5 个部门，目前只有 2 个部门给了明确时间表，另外 3 个的口头承诺存在延期风险」。

后一种写法的价值在于，它把「沟通难」这个抽象问题变成了「催 3 个部门给时间表」这个具体动作。

一个判断标准：风险条目里如果出现「加强」「推进」「提高」这类词，就说明它还没写完。因为这三个词没有对应的完成标准。

三、把周报写成团队日志

项目周报最容易写成流水账的原因是：它涉及的人和事太多，写作者倾向于按时间顺序把事情记下来。

流水账的特征很明确：按时间排序、以人名为中心、每条只有事实没有判断。

判断是不是流水账，有一个简单办法：把所有条目里的人名去掉，看还剩下什么，那把条目里的人名去掉之后，应该剩下什么才不算流水账？

如果剩下的全是「完成了 A，推进了 B，参加了 C」，那这就是团队日志。

团队日志可以写，但不能当周报。周报必须有取舍，只留老板需要做判断的那些。

怎么让 AI 帮你把这三段填起来

项目经理周报最费时间的不是写，是把散落在各处的进度和风险汇总起来。那偏差天数为什么要让 AI 来算？

这个环节可以交给 AI，但要先把结构定死，否则它会帮你把风险写没了，第一步，把本周的进度数据按统一格式整理出来，每个任务一行，字段是：任务名、计划完成度、实际完成度、计划完成时间、实际完成时间、负责人。

然后让 AI 只做一件事：算出每个任务的偏差天数并排序。

这一步不要让它写结论，只要数字。因为偏差天数是最难自己算准的东西，也是最容易被漏掉的，第二步，让它基于偏差和你的补充信息，输出风险登记的初稿，每个风险必须包含：具体描述、影响什么、当前应对状态，这一步你要盯着，因为它最容易出现「已通过沟通解决」这类空话。

第三步，把你确认过的风险和下周动作喂回去，让它按三段结构生成周报正文，并要求「不得把未确认的风险标记为已解决」。

提示词可以直接用下面这段：

最后一步必须自己读一遍，重点读第二段，AI 帮你省下的时间是算偏差和整理格式，判断哪条风险是真的、哪条可以关闭，依然是你自己的活，而且这一步恰恰是不能省的，因为风险判断错误的责任在任何工具上都是你的。

一份可以直接照抄的检查清单

写完别急着发，用这五条过一遍。

有没有一个明确的偏差数字，没有就补上。

下个里程碑是不是放在进度段开头，不是就调位置，每条风险能验证吗，追不到具体动作就重写，每条风险的影响被量化了吗，只写「有影响」就补上，下周每条动作都有负责人和完成标准吗，缺一个就补上。

这五条里最容易不过关的是第三条和第五条。

项目周报真正的失败不是写得不好看，是老板看完之后不知道现在该不该出手。

站内还有一篇 运营周报怎么写，两者的区别可以一句话说完：运营周报是向上解释已经发生的事，项目周报是向上暴露还没发生但可能发生的事。