办公效率 编辑复核
项目状态报告与风险升级
把多方更新汇总成进度、依赖、风险和需要决策的事项，让项目状态可以被快速读懂。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名项目运营负责人。请根据真实更新整理一份适合管理层和执行团队同时阅读的状态报告。
输出：整体状态及依据、已完成/进行中/延期的里程碑、依赖与负责人、风险（概率、影响、触发信号、缓解和升级时间）、需要决策的问题、未来 7 天动作。
把没有更新与没有风险区分开；日期、预算和完成率缺失时标记待确认，不补造百分比。
项目目标：{{goal}}
团队更新：{{updates}}
里程碑与截止时间：{{milestones}}
报告读者：{{readers}}HOW TO USE
使用说明
- 要求每条状态都带来源或负责人，避免把同步中的主观感受当作事实。
- 风险升级单只写需要决定的事情，不把所有普通任务都标成高风险。
WHEN IT FITS
适用判断
适合这些情况
- 项目有明确的里程碑和当前进度数据。
- 需要向上级或客户同步，包括坏消息。
- 有需要升级处理的阻塞问题。
换个做法更好
- 你要写的是简短的健康度更新：用《项目健康状态报告》。
- 项目刚启动没有进展：报告没有内容。
- 你要整理的是风险清单：用《项目风险登记册更新》。
FAILURE MODES
常见翻车与修正
- 进度用「基本完成」「即将上线」这类模糊表述。
要求用可核对的口径：完成了哪几项、剩余哪几项、预计什么时间，模糊表述一律替换。
- 把风险写得很轻，读的人以为没事。
要求风险部分写明最坏情况的影响和需要的支持，弱化风险会让升级失效。
- 报告只有现状没有请求，读完不知道要做什么。
补充要求：明确列出需要对方决策或提供支持的事项，以及不处理的后果。
ACCEPTANCE
怎么判断输出合格
- 进度用可核对的具体项目描述，不是模糊表述。
- 风险写明了最坏影响，没有淡化。
- 明确列出了需要对方决策或支持的事项。
- 数据来自实际记录，没有估算填补。
SAFETY BOUNDARY
使用边界
- 风险升级会触发管理层动作，升级前先和相关方对齐事实，避免基于不准确的判断惊动一圈人。
- 客户名称、合同金额和未公开的时间节点在报告流转前确认可见范围。